AI Act als Pipeline: Wie Art. 9 bis 15 zu CI/CD-Artefakten werden

1. Der Stand im November 2026

Die KI-Verordnung (EU) 2024/1689 ist seit dem 1. August 2024 in Kraft und gilt in Stufen [1]. Im November 2025 schlug die Kommission mit dem Digital Omnibus vor, den Beginn der Hochrisiko-Pflichten an die Verfügbarkeit von Normen und Leitlinien zu knüpfen und dafür späteste Stichtage festzulegen. Parlament und Rat einigten sich am 7. Mai 2026 vorläufig [3]. Die Änderungsverordnung (EU) 2026/1744 wurde am 8. Juli 2026 erlassen, am 24. Juli im Amtsblatt veröffentlicht und trat am 27. Juli 2026 in Kraft [2]. Statt der Kopplung an Normen stehen nun feste Daten im Gesetz.

Entwicklungsteams bleiben damit gut zwölf Monate bis zum Stichtag für Anhang III. Das klingt großzügig, bis man eine Konformitätsbewertung, zwei Modell-Releases und den Aufbau eines Qualitätsmanagementsystems einplant.

Bei Redaktionsschluss sind drei Punkte offen. Die Leitlinien der Kommission zur Einstufung nach Art. 6 liegen seit dem 19. Mai 2026 nur als Entwurf vor [4]. Harmonisiert ist bisher nur das Qualitätsmanagement. EN 18286:2026 wurde mit dem Durchführungsbeschluss (EU) 2026/2274 am 14. Oktober 2026 im Amtsblatt veröffentlicht, weitere Normen nennt der Beschluss nicht [5]. Und Leitlinien zum Plan für die Beobachtung nach dem Inverkehrbringen, mit einer freiwilligen Vorlage, muss die Kommission erst bis zum 2. September 2027 veröffentlichen (Art. 72 Abs. 3 in der neuen Fassung). Wer jetzt baut, richtet sich nach dem Gesetzestext und muss nachsteuern, sobald Normen erscheinen.

Für Bestandssysteme gilt Art. 111 Abs. 2: Hochrisiko-Systeme, die vor dem Stichtag in Verkehr gebracht oder in Betrieb genommen wurden, fallen nur dann unter die Verordnung, wenn ihre Konzeption danach erheblich geändert wird. Teams, die monatlich nachtrainieren, müssen deshalb vor allem eine Frage der Abgrenzung klären. Legen Sie im Änderungsmanagement fest, was bei Ihnen als erhebliche Änderung gilt, und lassen Sie die Pipeline das bei jedem Release prüfen.

2. Warum eine Pipeline besser ist als ein Dokument

Nach Art. 11 muss die technische Dokumentation vor dem Inverkehrbringen erstellt und danach aktuell gehalten werden, nach Art. 18 ist sie zehn Jahre aufzubewahren. Ein Modell, das jeden Monat neu trainiert wird, macht ein Word-Dokument jeden Monat falsch. In diesem Takt hält nur eine Dokumentation Schritt, die der Build selbst erzeugt, versioniert und zusammen mit dem Modellartefakt ablegt.

Das Prinzip kennen Sie aus der Softwarelieferkette, etwa von SBOM, signierten Artefakten und reproduzierbaren Builds. Bei KI kommt dreierlei hinzu. Daten werden zum versionierten Eingangsartefakt, Evaluationsergebnisse zum Freigabekriterium und Laufzeit-Logs zur Pflichtausgabe.

3. Art. 9: Risikomanagement als Code

Für Entwicklerinnen und Entwickler ist Art. 9 Abs. 8 eine der wichtigsten Vorschriften im Hochrisiko-Kapitel. Danach wird anhand vorab festgelegter Metriken und Wahrscheinlichkeitsschwellen getestet, die zur Zweckbestimmung passen. Genau das leistet ein Eval-Gate. In der Praxis liegt dafür ein Risikoregister als YAML-Datei neben dem Code, hier am Beispiel einer Vorauswahl von Bewerbungen nach Anhang III Nr. 4:

# risk-register.yaml (Beispiel)
- id: R-07
  risiko: Bewerbungen mit Lücken im Lebenslauf werden systematisch schlechter eingestuft
  massnahme: Lücken-Merkmal entfernt, Fälle unter Score 0,7 gehen an die Sachbearbeitung
  test: eval/subgroups.py::recall_cv_gap
  metrik: recall
  schwelle: 0.90
  konfidenz: 0.95

Ein Linter im ersten Pipeline-Schritt bricht ab, wenn ein Eintrag keinen Test oder keine Schwelle hat. Das klingt bürokratisch, verhindert aber einen typischen Mangel von Risikoanalysen, nämlich Risiken, die benannt und nie geprüft werden.

# .gitlab-ci.yml (Auszug, Beispiel)
stages: [risk-lint, data-check, train, eval-gate, docs, release]

risk-lint:
  stage: risk-lint
  script: python tools/risk_lint.py risk-register.yaml

data-check:
  stage: data-check
  script: python tools/data_contract.py --dataset data/v2026.11 --datasheet out/datasheet.md

eval-gate:
  stage: eval-gate
  script: python eval/run.py --register risk-register.yaml --report out/eval-report.json
  # Abbruch, wenn eine Untergrenze des Konfidenzintervalls unter der Schwelle liegt

docs:
  stage: docs
  script: python tools/build_annex_iv.py --model-sha256 "$MODEL_SHA256" --out out/annex-iv/
  artifacts:
    paths: [out/]

4. Art. 10: Daten-Governance und das Datenblatt

Art. 10 Abs. 2 bis 4 verlangt dokumentierte Verfahren zu Herkunft, Aufbereitung, Annahmen, möglichen Verzerrungen und Datenlücken sowie Datensätze, die relevant, hinreichend repräsentativ und so weit wie möglich fehlerfrei und vollständig sind. Gebru und Kollegen haben dafür das Format „Datasheets for Datasets“ entwickelt, das 2021 in den Communications of the ACM erschienen ist [6]. Das Datenblatt entsteht am besten im Datenschritt der Pipeline. Herkunft und Lizenz stammen aus den Metadaten, Verteilungen pro relevanter Gruppe aus den Daten selbst und bekannte Lücken aus einer gepflegten Datei im Repository.

Für LLM-Anwendungen, die kein Modell trainieren, sondern ein fertiges Modell mit Prompts und Abruf nutzen, ist Art. 10 Abs. 6 entscheidend. Die Qualitätsanforderungen gelten dann nur für die Testdatensätze. Damit unterliegt Ihr Evaluationsdatensatz der Daten-Governance und braucht eine Versionierung, ein eigenes Datenblatt und einen Nachweis, dass er die Einsatzbedingungen abbildet.

Der Omnibus hat die Regel zu besonderen Kategorien personenbezogener Daten aus Art. 10 Abs. 5 gestrichen und als neuen Art. 4a vor die Klammer gezogen [2]. Anbieter dürfen solche Daten verarbeiten, soweit es zur Erkennung und Korrektur von Verzerrungen unbedingt erforderlich ist, und diese Möglichkeit gilt jetzt auch für andere KI-Systeme. Die DSGVO gilt daneben weiter. In der Pipeline bedeutet das einen eigenen Speicher und einen eigenen Zugriffspfad, die Löschung nach der Prüfung und eine Begründung der Erforderlichkeit im Datenblatt.

5. Art. 11 und 13: Dokumentation aus derselben Quelle

Anhang IV listet, was in die technische Dokumentation gehört, von der allgemeinen Beschreibung über Entwicklungsprozess und Datenanforderungen bis zu Metriken, Risikomanagement und Änderungen im Lebenszyklus. Die Modellkarte nach Mitchell und Kollegen deckt davon einen guten Teil ab, etwa Zweck, Trainings- und Evaluationsdaten, Metriken pro Untergruppe und bekannte Grenzen [7]. Das Paket entsteht in einer eigenen Stufe aus Modellkarte, Datenblatt, Evaluationsbericht, Risikoregister, Architekturdiagramm und Änderungsprotokoll und wird über den SHA-256-Hash an genau ein Modellartefakt gebunden. KMU und kleine Mid-Caps dürfen nach dem Omnibus eine vereinfachte Form nutzen, die die Kommission bereitstellen soll [2].

Die Gebrauchsanweisung nach Art. 13 muss unter anderem das Maß an Genauigkeit samt Metriken sowie Robustheit und Cybersicherheit angeben, gegen die das System getestet wurde (Art. 13 Abs. 3 Buchst. b Ziff. ii). In der Praxis laufen Handbuch und Testbericht auseinander, sobald jemand eine Zahl von Hand abschreibt. Erzeugen Sie den Abschnitt mit den Kennzahlen deshalb aus dem Evaluationsbericht, und lassen Sie das Release scheitern, wenn beide nicht übereinstimmen.

6. Art. 12: Ein Logging-Schema für zwei Gesetze

Art. 12 verlangt, dass Hochrisiko-Systeme Ereignisse über ihre gesamte Lebensdauer automatisch aufzeichnen können, insbesondere um Risikosituationen und wesentliche Änderungen zu erkennen, die Beobachtung nach dem Inverkehrbringen zu ermöglichen und den Betrieb zu überwachen. Anbieter und Betreiber bewahren die Logs mindestens sechs Monate auf (Art. 19, Art. 26 Abs. 6). Eine harmonisierte Norm für das Logging gibt es noch nicht.

Für LLM-basierte Systeme eignen sich die Semantic Conventions von OpenTelemetry für generative KI als Gerüst [8]. Sie definieren Attribute wie gen_ai.request.model, gen_ai.response.model, gen_ai.usage.input_tokens und gen_ai.tool.name. Alle haben noch den Status „Development“ und können sich ändern. Legen Sie deshalb die Version fest und kapseln Sie die Namen in einer eigenen Bibliothek. Ein Ereignis kann so aussehen:

{
  "timestamp": "2026-11-08T09:14:22Z",
  "system_version": "bewerbungs-screening 3.4.1",
  "model_sha256": "9f2c0e7d41ab",
  "gen_ai.operation.name": "chat",
  "gen_ai.request.model": "screening-modell-2026-10",
  "gen_ai.response.model": "screening-modell-2026-10",
  "gen_ai.usage.input_tokens": 1843,
  "gen_ai.usage.output_tokens": 212,
  "input_ref": "store://eu-central/inputs/7c1e",
  "subject_pseudonym": "p_4a91d2",
  "risk_flags": ["R-07"],
  "oversight": { "action": "override", "role": "recruiting", "reason_code": "gap_explained" },
  "retain_until": "2027-05-08"
}

Über die Qualität entscheiden zwei Details. Logs mit vollem Prompt-Text sind ein Datenschutzproblem. Speichern Sie deshalb Verweise auf getrennt gesicherte Eingaben und pseudonymisierte Kennungen. Pseudonymisierte Logs sind allerdings nicht anonym, sie bleiben personenbezogen und brauchen ein Löschkonzept. Außerdem schickt ein Contract-Test im Integrationsschritt Testanfragen durch das System und prüft, ob jedes Pflichtereignis mit allen Pflichtfeldern ankommt. Sonst fallen Lücken im Logging, das nur in Produktion läuft, erst beim Audit auf.

7. Art. 14: Aufsicht, die sich testen lässt

Art. 14 Abs. 4 beschreibt, was die Aufsichtsperson können muss. Sie muss Fähigkeiten und Grenzen des Systems verstehen, sich des Automatisierungsbias bewusst sein, die Ausgabe richtig deuten, sie übergehen und das System über eine Stopptaste oder ein ähnliches Verfahren anhalten können. Jede dieser Fähigkeiten wird im Produkt zu einer Funktion, und jede Funktion bekommt einen Test.

Konkret zeigt die Oberfläche die Unsicherheit des Modells an, eine Übersteuerung ist mit zwei Klicks möglich und landet mit Begründungscode im Log, und ein Notschalter per Feature-Flag schaltet auf manuellen Betrieb um. Der End-to-End-Test betätigt diesen Schalter bei jedem Release.

Im Betrieb lohnt sich ein Blick auf die Quote der Übersteuerungen. Liegt sie bei null, prüft vermutlich niemand. Liegt sie bei 40 %, stimmt etwas mit dem Modell nicht. Beides gehört in den Plan zur Beobachtung nach dem Inverkehrbringen nach Art. 72.

8. Art. 15: Genauigkeit, Robustheit und Cybersicherheit als Gates

Das Eval-Gate prüft die Genauigkeit pro relevanter Untergruppe und mit Konfidenzintervall. Ein Recall von 0,91 auf 300 Testfällen hat ein 95-%-Intervall von ungefähr 0,87 bis 0,94. Liegt die Schwelle bei 0,90, fällt dieses Modell durch, obwohl der Punktwert darüber liegt. So steht es im Register, und so entscheidet die Pipeline.

Die Robustheit testen Sie mit gestörten Eingaben aus dem Einsatzkontext, etwa mit Tippfehlern, anderen Dateiformaten, fehlenden Feldern und bei Text auch mit Umformulierungen. Für Systeme, die nach dem Inverkehrbringen weiterlernen, verlangt Art. 15 Abs. 4 Maßnahmen gegen Rückkopplungsschleifen. In der Pipeline ist das ein Vergleich gegen einen eingefrorenen Referenzdatensatz bei jedem Nachtraining.

Für die Cybersicherheit nennt Art. 15 Abs. 5 ausdrücklich Datenvergiftung, Modellvergiftung, präparierte Eingaben zur Umgehung des Modells sowie Angriffe auf die Vertraulichkeit. Prompt Injection gehört bei LLM-Anwendungen als präparierte Eingabe in diese Liste. Wie ein Prüfplan dafür aussieht, beschreibt unser Red-Teaming-Leitfaden. Neu durch den Omnibus ist Art. 42 Abs. 3: Fällt ein Hochrisiko-System unter den Cyber Resilience Act und sind die Voraussetzungen von dessen Art. 12 Abs. 1 erfüllt, gilt es hinsichtlich der Cybersicherheitsanforderungen aus Art. 15 als konform [2] [9].