EU AI Act in 90 Tagen: Mapping-Tabelle Artikel → Krasper-Raigate-Feature

TL;DR. Der EU AI Act ist kein Zukunftsproblem mehr — die Hochrisiko-Pflichten sind in Kraft, und die meisten Unternehmen, die 2023–2024 LLMs lässig ausgerollt haben, stehen heute auf der falschen Seite von Artikel 9 bis 15. Dieser Beitrag ist ein Arbeits-Mapping: jeder Artikel, was er operativ tatsächlich verlangt, und wie eine transparente KI-Governance-Schicht wie Krasper Raigate ihn adressiert. Außerdem ein 90-Tage-Plan in drei Phasen für Teams, die spät dran sind.

Inhalt

1. Die Compliance-Uhr, die längst hätte laufen sollen
2. Risikoklassifizierung — wo LLM-Nutzung tatsächlich landet
3. Ein 90-Tage-Plan in drei Phasen
4. Das Mapping auf einen Blick
5. Pflichten vor dem Deployment (Art. 9, 10, 11)
6. Operative Pflichten (Art. 12, 13, 14)
7. Qualitätspflichten (Art. 15)
8. Die Betreiber-Sicht (Art. 26)
9. Was 90 Tage tatsächlich liefern
10. Quellen und der eigentliche Wortlaut

1. Die Compliance-Uhr, die längst hätte laufen sollen

Der EU AI Act trat am 1. August 2024 in Kraft. Die wichtigen Daten für jedes Unternehmen, das LLMs produktiv einsetzt:

• 2. Februar 2025 — Verbote unannehmbarer Risiken treten in Kraft, plus Pflichten zur KI-Kompetenz von Mitarbeitenden.
• 2. August 2025 — Pflichten für General-Purpose-AI-Modelle (GPAI) und deren Anbieter treten in Kraft.
• 2. August 2026 — der Großteil der Hochrisiko-Pflichten tritt in Kraft, einschließlich des vollen Gewichts von Art. 9 bis 15.
• 2. August 2027 — Hochrisiko-Pflichten gelten zusätzlich für KI als Sicherheitskomponente von Produkten unter anderer EU-Regulierung.

Die naive Lesart: Hochrisiko-Pflichten liegen noch in der Zukunft. Die realistische Lesart: Compliance-Evidenz ist rückwärtsgerichtet. Wenn eine Behörde 2027 einen Vorgang öffnet, fragt sie, wie die Governance 2026 aussah — und Sie müssen Aufzeichnungen vorlegen, keine Versprechen. Die Compliance-Uhr, die hätte laufen sollen, ist nicht der Tag, an dem die Pflichten beißen, sondern der Tag, an dem sich die Kontrollen belegen lassen.

Genau deshalb ist ein 90-Tage-Plan überhaupt plausibel: Der größte Teil der Arbeit ist Instrumentierung und Evidenz, nicht das Schreiben eines neuen Policy-Frameworks. Steht eine transparente Governance-Schicht, ist ein Großteil der Evidenz bereits Nebenprodukt normalen Verkehrs.

2. Risikoklassifizierung — wo LLM-Nutzung tatsächlich landet

Erste Frage: Ist ein konkreter Anwendungsfall unter dem Act als Hochrisiko klassifiziert? Der Entscheidungsbaum:

Die meisten Unternehmens-LLM-Deployments fallen in eine von zwei Kategorien. Hochrisiko wenn der Use Case in Anhang III steht: HR/Bewerber-Screening, Kreditscoring, Bildung und Prüfungsbewertung, Betrieb kritischer Infrastruktur, Strafverfolgung, Migration und Asyl, Justizentscheidungen. Begrenztes Risiko wenn die KI mit Menschen interagiert (Kundendienst-Chatbot, Content-Generator für Endnutzer). General-Purpose-Modelle, die in eine der Kategorien integriert werden, erben deren Pflichten.

Der Fehler: anzunehmen, "wir nutzen ChatGPT nur intern für Produktivität" lande in der Minimalrisiko-Kategorie. Sobald diese interne Nutzung Output zurück in eine Hochrisiko-Entscheidung speist — eine Bewerber-Shortlist, ein Kreditscore, eine Triage von Kundenforderungen — hängen die Hochrisiko-Pflichten auch am LLM.

3. Ein 90-Tage-Plan in drei Phasen

Drei Phasen, je dreißig Tage, mit expliziten Lieferobjekten:

Die Phasen sind sequentiell, weil die Artefakte voneinander abhängen. Kontrollen lassen sich nicht instrumentieren, bevor klar ist, welche Use Cases zu kontrollieren sind. Ein System lässt sich nicht dokumentieren, bevor die Kontrollen stehen. Und Sign-Off auf Dokumentation gibt es nicht, bevor die Verantwortlichen das System ratifiziert haben.

4. Das Mapping auf einen Blick

Das kompakte Mapping für die operativen Artikel:

• Art. 9 — Risikomanagement-System. Verlangt: Risiken über den gesamten Lebenszyklus identifizieren, bewerten und mindern. Proxy liefert: Asset-Register mit Risikoklasse pro System; periodischer Review-Workflow mit Entscheidungsdatensätzen.
• Art. 10 — Daten-Governance. Verlangt: Trainings-, Validierungs- und Testdaten erfüllen Qualitätskriterien; Provenienz und Bias geprüft. Proxy liefert: für Inferenz-Governance — durchsetzen, dass Daten, die das Unternehmen Richtung Drittanbieter verlassen, Datenschutzregeln erfüllen, mit Policy-Gates vor Weiterleitung.
• Art. 11 — Technische Dokumentation. Verlangt: Compliance-belegende technische Doku, für Behörden verfügbar. Proxy liefert: Policy-Bundles, Audit-Trails und Evaluations-Reports — exportierbar als Compliance-Paket.
• Art. 12 — Aufzeichnungspflichten. Verlangt: automatische Event-Aufzeichnung zur Nachvollziehbarkeit der Funktionsweise. Proxy liefert: Audit-Events pro Aufruf, hash-verkettet manipulationssicher; append-only.
• Art. 13 — Transparenz / Information an Betreiber. Verlangt: klare und angemessene Information über Fähigkeiten, Grenzen und Zweckbestimmung. Proxy liefert: System-Doku in der Governance-UI; Trace-Endpoints, die zeigen, welche Policy auf welchen Aufruf wirkte.
• Art. 14 — Menschliche Aufsicht. Verlangt: Aufsicht ermöglichen; Menschen müssen Outputs interpretieren und eingreifen können. Proxy liefert: Freigabe-Workflows mit SLA-Fristen; Override-Kontrollen; "diese Entscheidung wurde getroffen / überschrieben durch [Principal]" explizit im Audit.
• Art. 15 — Genauigkeit, Robustheit, Cybersicherheit. Verlangt: angemessene Niveaus erreichen und halten. Proxy liefert: Evaluations-Framework für regelmäßige Tests; Cybersicherheits-Kontrollen direkt im Proxy (fail-closed, signierte Policy-Bundles, rollen-gesteuerte Rückwege).

Die nächsten Abschnitte gehen jeden Artikel operativ durch — was er praktisch verlangt, wo die Pflicht operativ landet, und was konkret steht, wenn die Governance-Schicht richtig ausgerollt ist.

5. Pflichten vor dem Deployment (Art. 9, 10, 11)

Art. 9 — Risikomanagement

Der Act verlangt ein Risikomanagement-System, nicht eine einmalige Risikobewertung. Der Unterschied zählt: Ein System ist ein dokumentierter Prozess, der über den Lebenszyklus der KI durchgehend läuft, mit Reviews, die durch Zeit oder wesentliche Änderung ausgelöst werden.

Operativ ist der Kern ein Asset-Register: Jedes KI-System ist ein registrierter Eintrag mit definierter Risikoklasse (Niedrig / Mittel / Hoch / Kritisch), definiertem Owner, definiertem Abhängigkeitsgraphen (welche Datasets fließen rein, welche nachgelagerten Systeme konsumieren den Output) und definiertem Review-Takt. Bei wesentlicher Änderung — neue Modellversion, neue Datenquelle, neuer Deployment-Kontext — wird automatisch ein Review ausgelöst und eine frische Entscheidung dokumentiert.

Was eine Behörde fragen wird: "Zeigen Sie mir die Risikobewertung für dieses KI-System, wie sie vor acht Monaten stand." Was Sie liefern müssen: einen versionierten Datensatz aus dem Asset-Register mit zeitgestempelten Entscheidungen, der Begründung und den Personen, die unterzeichnet haben.

Art. 10 — Daten-Governance

Für Trainingsdaten setzt der Act Kriterien zu Relevanz, Repräsentativität, Fehlerfreiheit und statistischer Verzerrung. Die meisten Unternehmen, die LLMs einsetzen, trainieren keine eigenen Modelle — Art. 10 hat trotzdem Zähne, denn die Daten, die Ihre Anwendungen an ein Drittanbieter-Modell schicken, sind selbst eine Governance-Frage.

Ein transparenter Governance-Proxy setzt die Inferenz-Lesart von Art. 10 durch: Jeder Request wird vor dem Verlassen des Netzwerks geprüft, sensible Daten werden gemäß Policy redigiert oder blockiert, und die Entscheidung wird geloggt. Der Proxy ersetzt nicht die Trainings-Daten-Governance des Anbieters, aber er belegt, was der Betreiber getan hat, um den durchfließenden Datenfluss zu kontrollieren.

Art. 11 — Technische Dokumentation

Anhang IV listet, was die technische Doku abdecken muss: allgemeine Beschreibung des KI-Systems, Designspezifikationen, Datenanforderungen, Trainingsmethodik (wo zutreffend), Validierungs- und Testverfahren, Metriken für Genauigkeit und Robustheit, Cybersicherheits-Maßnahmen und Systemarchitektur.

Für Betreiber: ein Compliance-Paket pro KI-System mit allen Abschnitten — und nach Möglichkeit generiert statt handgeschrieben. Audit-Trails, Policy-Versionen und Evaluations-Reports sind Evidenz — kein Narrativ. Das Narrativ wickelt sich um die Evidenz; tragend ist die Evidenz.

6. Operative Pflichten (Art. 12, 13, 14)

Art. 12 — Aufzeichnungspflichten

Art. 12 ist der Artikel, der leise verändert, wie KI-Systeme gebaut werden müssen. Er verlangt automatisches Logging, das die Funktionsweise nachvollziehbar macht. Der Standard, auf den Aufsichten praktisch konvergieren: manipulationssichere, append-only, rekonstruierbare Logs.

Genau hier kommt ein hash-verketteter Audit-Trail ins Spiel. Jeder gegovernete LLM-Aufruf produziert ein Audit-Event. Jedes Event referenziert den Hash des Vorgängers. Jede nachträgliche Änderung bricht die Kette mechanisch nachweisbar. Eine nächtliche Integritätsprüfung läuft die Kette von einem bekannten Anker vorwärts ab; jeder Bruch erzeugt automatisch einen Incident.

Beispiel-Audit-Event mit expliziten Artikel-Referenzen:

Das Feld compliance_refs macht den Audit-Trail für Aufsichten brauchbar. Fragt eine Behörde nach Evidenz zu Art. 14 Aufsicht, fragt man den Audit-Store nach Events, deren compliance_refs EU_AI_ACT_ART_14 enthält, und legt sie als Beleg vor.

Art. 13 — Transparenz gegenüber Betreibern

Art. 13 verpflichtet Anbieter von Hochrisiko-KI, Betreibern klare und angemessene Information zu liefern. Auf Betreiber-Seite die spiegelbildliche Pflicht: diese Information korrekt zu konsumieren — wissen, was das System kann und nicht kann, wo seine Grenzen liegen und wo die Grenzen der Zweckbestimmung sitzen.

Ein Governance-Proxy trägt zur Transparenz bei, indem er Per-Aufruf-Traces verfügbar macht — was wurde gesendet, was kam zurück, welche Policy galt — und systemweite Metadaten (Modellversion, Policy-Bundle-Version, gültige Redigierungsstrategie) auf jedes Audit-Event surface't. Transparenz ist kein einzelnes Dokument, sondern eine Menge abfragbarer Eigenschaften des Systems.

Art. 14 — Menschliche Aufsicht

Art. 14 ist einer der operativ konkretesten Artikel. Er verlangt, dass natürliche Personen das KI-System effektiv beaufsichtigen, Outputs verstehen, eingreifen und Entscheidungen verwerfen oder überschreiben können. "Natürliche Personen" umfasst Personal des Betreibers und je nach Kontext betroffene Endnutzer.

Operative Form von Aufsicht: ein Freigabe-Workflow, der unter definierten Bedingungen auslöst, ein SLA, wie schnell ein Genehmigender reagieren muss, ein Audit-Datensatz darüber, wer was wann genehmigt hat, und ein klarer Override-Pfad. Ein Request, der eine Hochrisiko-Bedingung erfüllt, wird bis zur Freigabe gehalten; ein autorisierter Mensch entscheidet erlauben oder blockieren, die Entscheidung wird mit Identität dokumentiert. Reagiert kein Mensch innerhalb des SLA, wird der Request standardmäßig blockiert — Fail-Closed gilt auch für Aufsicht, nicht nur fürs Scannen.

7. Qualitätspflichten (Art. 15)

Art. 15 — Genauigkeit, Robustheit, Cybersicherheit

Art. 15 schließt den Kreis. Frühere Artikel decken ab, was das System tun soll; Art. 15 deckt ab, wie gut es das tatsächlich tut und wie widerstandsfähig diese Leistung ist.

Drei Unterpflichten:

• Genauigkeit. Das System muss angemessene Genauigkeitsniveaus für seinen Zweck erreichen, und die Mess-Metriken müssen in der technischen Doku deklariert sein.
• Robustheit. Das System muss gegen Fehler, Ausfälle und Inkonsistenzen widerstandsfähig sein — auch gegen adversarielle Inputs und Out-of-Distribution-Daten.
• Cybersicherheit. Das System muss so konzipiert und entwickelt sein, dass es über den Lebenszyklus angemessene Cybersicherheit bietet.

Operativ landet das auf drei Komponenten. Ein Evaluations-Framework fährt regelmäßige Test-Suiten gegen das deployte System und produziert Genauigkeitsberichte, gebunden an Modell- und Policy-Bundle-Version. Ein Drift-Monitor beobachtet Produktiv-Traffic auf Verteilungs-Shifts, die Genauigkeitsaussagen entwerten würden. Eine Cybersicherheits-Baseline schließt den Proxy selbst ein: Fail-Closed-Defaults, signierte Policy-Bundles, rollen-gesteuerte Rückwege, mTLS für Ost-West-Service-Traffic, Lieferketten-Attestierung der Deployment-Artefakte.

8. Die Betreiber-Sicht (Art. 26)

Die meisten der oben beschriebenen Pflichten zielen auf Anbieter von Hochrisiko-KI-Systemen. Art. 26 ist der Betreiber-Artikel: Die Organisation, die ein Hochrisiko-KI-System nutzt, hat eigene Pflichten — Nutzung gemäß Zweckbestimmung, Betriebsmonitoring, menschliche Aufsicht sicherstellen, Logs mindestens sechs Monate aufbewahren, schwere Vorfälle Behörden melden.

Für eine Organisation, die ein Drittanbieter-LLM in einen Hochrisiko-Workflow integriert, ist das die spiegelbildliche Variante zu Art. 9–15. Der Anbieter haftet für das Modell. Der Betreiber haftet für das, was er mit dem Modell tut. Der Audit-Trail der Governance-Schicht ist die primäre Evidenzbasis des Betreibers für Art. 26.

9. Was 90 Tage tatsächlich liefern

Neunzig Tage reichen, um von keiner belastbaren Compliance-Position zu einer belastbaren Position für eine LLM-nutzende Organisation, die nicht für den AI Act vorgeplant hat zu kommen. Sie reichen nicht, um eine maßgeschneiderte Governance-Plattform von Grund auf zu bauen — deshalb nutzt fast jeder erfolgreiche 90-Tage-Rollout eine fertige, transparente Governance-Schicht.

Was Sie nach 90 Tagen — gut gemacht — haben:

• Vollständiges Inventar der KI-Use-Cases, klassifiziert nach Risikoklasse
• Governance-Schicht, die Art. 9, 10, 13 im Produktiv-Traffic durchsetzt
• Audit-Trail, der Art. 12 erfüllt — hash-verkettet manipulationssicher
• Freigabe-Workflows für Art. 14 Aufsicht
• Evaluations-Baseline für Art. 15 Genauigkeits- und Robustheits-Reporting
• Compliance-Paket, das Auditoren, internem Risiko-Komitee oder Kunden-Procurement übergeben werden kann

Was Sie nach 90 Tagen nicht haben: ein erledigtes Problem. Die Pflichten des Acts sind kontinuierlich. Sinn der 90 Tage ist, sie zu starten.

10. Quellen und der eigentliche Wortlaut

Der vollständige Text der Verordnung (EU) 2024/1689 ist im Amtsblatt der EU veröffentlicht und auf EUR-Lex frei verfügbar. Die in diesem Beitrag referenzierten Artikel:

• Art. 5 (Verbotene KI-Praktiken)
• Art. 6 und Anhang III (Hochrisiko-KI-Systeme)
• Art. 9 (Risikomanagement-System)
• Art. 10 (Daten und Daten-Governance)
• Art. 11 (Technische Dokumentation)
• Art. 12 (Aufzeichnungspflichten)
• Art. 13 (Transparenz und Information an Betreiber)
• Art. 14 (Menschliche Aufsicht)
• Art. 15 (Genauigkeit, Robustheit, Cybersicherheit)
• Art. 26 (Pflichten der Betreiber von Hochrisiko-KI-Systemen)
• Art. 50 (Transparenzpflichten für Anbieter und Betreiber bestimmter KI-Systeme)

Den eigentlichen Wortlaut zu lesen dauert länger als jede Zusammenfassung — auch diese. Für die Teile, die eine Deployment-Entscheidung material verändern, gibt es keinen Ersatz.