Skip to main content

KI-Verordnung-Compliance in Ihrer CI/CD-Pipeline

Was die Verordnung verlangt und eine CI/CD-Pipeline belegen kann, drei Pipeline-Stufen, wie das GitHub Merge Gate von Scanara funktioniert und wo regelbasierte Scans enden.

Die Verordnung verlangt kein CI/CD. Anbieter von Hochrisiko-KI-Systemen müssen die technische Dokumentation aktuell halten (Artikel 11) und vor dem Inverkehrbringen oder der Inbetriebnahme testen (Artikel 9 Absatz 8). Sie müssen außerdem ein Qualitätsmanagementsystem betreiben (Artikel 17). Eine Pipeline kann Nachweise für diese Pflichten liefern.

Diese Pflichten gelten ab 2. Dezember 2027 (Anhang III) und ab 2. August 2028 (Anhang I). Artikel 2 nennt Ausnahmen. Geldbußen betragen bis zu 15 Mio. EUR oder 3 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist (Artikel 99 Absatz 4). Nächster Schritt: Ordnen Sie jede Pipeline-Stufe dem Artikel zu, den sie belegt.

Eine Pipeline kann diese Pflichten belegen; über die Konformität entscheidet sie nicht

  • Technische Dokumentation bleibt aktuell (Artikel 11)

    Die technische Dokumentation wird vor dem Inverkehrbringen oder der Inbetriebnahme erstellt und auf dem neuesten Stand gehalten. Sie enthält mindestens die Angaben nach Anhang IV. Ein Pipeline-Schritt kann prüfen, ob die geforderten Dokumente existieren und sich zusammen mit dem Code ändern.

  • Tests laufen vor dem Inverkehrbringen oder der Inbetriebnahme (Artikel 9 Absätze 6 bis 8)

    Getestet wird jederzeit während der Entwicklung und auf jeden Fall vor dem Inverkehrbringen oder der Inbetriebnahme, anhand vorab festgelegter Metriken und probabilistischer Schwellenwerte, die zur Zweckbestimmung passen. Test-Stufen der Pipeline mit festen Schwellenwerten liefern datierte Ergebnisse.

  • Das Qualitätsmanagement umfasst die Änderungskontrolle (Artikel 17 Absatz 1)

    Das Qualitätsmanagementsystem dokumentiert Entwurfskontrolle, Qualitätskontrolle der Entwicklung, Test- und Validierungsverfahren sowie den Umgang mit Änderungen. Pipeline-Protokolle und Review-Regeln können diese Schritte festhalten.

  • Wesentliche Veränderungen erfordern eine neue Konformitätsbewertung (Artikel 43 Absatz 4)

    Eine Veränderung eines Systems nach dem Inverkehrbringen, die die ursprüngliche Konformitätsbewertung nicht vorsah und die Konformität mit den Anforderungen des Abschnitts 2 beeinträchtigt oder die Zweckbestimmung ändert, ist eine wesentliche Veränderung (Artikel 3 Nummer 23). Eine Pipeline kann Änderungen am Modell oder an der Zweckbestimmung zur menschlichen Prüfung markieren. Ob eine Änderung wesentlich ist, entscheidet sie nicht. Bei Systemen, die nach dem Inverkehrbringen weiterlernen, sind Änderungen, die bei der ursprünglichen Bewertung vorab bestimmt und nach Anhang IV Nummer 2 Buchstabe f dokumentiert wurden, keine wesentlichen Veränderungen (Artikel 43 Absatz 4).

Drei Pipeline-Stufen, die zu diesen Pflichten passen (unser Vorschlag)

Die Verordnung nennt keine Pipeline-Stufen. Diese Aufteilung legt schnelle Prüfungen auf jeden Pull Request und den vollständigen Scan vor die Veröffentlichung.

Stufe 1: Prüfungen beim Pull Request

Laufen bei jedem Pull Request und geben Entwicklern schnelles Feedback.

  • Code-Scan: Regelbasierte statische Analyse markiert KI-Komponenten und fehlende Muster, zum Beispiel KI-Operationen ohne Protokollierung. Sie erkennt nur Standardmuster gängiger ML-Frameworks.
  • Dokumentenprüfung: Richtlinienregeln prüfen, ob die geforderten Dokumente existieren und die geforderten Abschnitte enthalten. Sie prüfen, ob Inhalt vorhanden ist, nicht ob er wahr oder gut ist.
  • Risikoklassen-Vermerk: Prüfen Sie, ob die Risikoklassifizierung des Systems festgehalten ist und bei Änderungen von Code oder Zweckbestimmung überprüft wird. Die Klassifizierung selbst ist eine menschliche Entscheidung (Artikel 6).

Stufe 2: Merge Gate

Eine Prüfung vor dem Merge, die nicht konforme Änderungen aufhalten kann.

  • Grenzwerte für Befunde: Legen Sie Grenzwerte für kritische und hohe Befunde fest. Im blockierenden Modus schlägt die Prüfung fehl, wenn ein Scan die Grenzwerte überschreitet.
  • Befunde zu Artikel 5 und Artikel 14: Ein Code-Scan zeigt weder Absicht noch Kontext. Ein Mensch prüft jeden Befund, der auf eine verbotene Praxis (Artikel 5) oder fehlende menschliche Aufsicht (Artikel 14) hindeutet.
  • Änderungen an der Dokumentation: Prüfen Sie, ob sich die Dokumentation nach Anhang IV im selben Pull Request ändert wie der Code, den sie beschreibt.

Stufe 3: Scan vor der Veröffentlichung

Ein vollständiger Scan des Release-Kandidaten.

  • Vollständiger Scan: Ein kompletter Code- und Dokumenten-Scan. Der Dokumenten-Scan unterstützt acht Sprachen: EN, DE, FR, IT, ES, NL, PL und PT.
  • Dossier-Entwurf: Scanara entwirft Dokumente nach Anhang IV und Anhang V aus Ihren Angaben und Bewertungsantworten. Die automatische Befüllung ist teilweise; den Rest schreiben und prüfen Sie selbst.
  • Nachweis-Schnappschuss: Bewahren Sie den Scan-Bericht beim Release-Eintrag auf, damit Sie zeigen können, was wann geprüft wurde.

So funktioniert das GitHub Merge Gate von Scanara

Scanara empfängt GitHub-Pull-Request-Ereignisse, scannt die Änderung und meldet das Ergebnis als GitHub-Check-Run. Im Nur-Bericht-Modus wird eine fehlgeschlagene Prüfung als neutral gemeldet. Im blockierenden Modus schlägt die Prüfung fehl.

Das Merge Gate funktioniert nur mit GitHub. Geplante Scans gibt es noch nicht; Scans laufen auf Anforderung und bei Pull Requests.

Was die Scans prüfen und wo sie enden

Die Abdeckung ist teilweise. Im Stand vom 24. August 2026 haben 77 von 174 erfassten Pflichten Code-Regeln, verteilt auf 43 Artikel, und 23 haben Dokumentenregeln, verteilt auf 23 Artikel. Die Zuordnung stammt aus der Zeit vor den Änderungen durch die Verordnung (EU) 2026/1744, zum Beispiel den Artikeln 4a, 60a und 75a bis 75d. Die übrigen Pflichten erfordern Bewertungen und menschliche Arbeit.

Code-Regeln

  • Artikel 5: verbotene Praktiken

    Regeln markieren Code-Muster, die auf eine verbotene Praxis hindeuten können. Ob eine Praxis verboten ist, hängt von Zweck und Kontext ab, die der Code nicht zeigt.

  • Artikel 9: Risikomanagement

    Regeln markieren KI-Entscheidungspunkte ohne erkennbaren Code für Risikobewertung oder Validierung.

  • Artikel 10: Daten und Daten-Governance

    Regeln markieren Trainings-Pipelines ohne erkennbare Datenqualitätsprüfungen.

  • Artikel 12: Aufzeichnungspflichten

    Regeln markieren KI-Operationen ohne erkennbare Protokollierung.

  • Artikel 14: menschliche Aufsicht

    Regeln markieren Entscheidungspfade ohne erkennbaren Eingriffspunkt für Menschen, etwa eine Übersteuerung oder ein Stoppverfahren.

  • Artikel 15: Genauigkeit und Robustheit

    Regeln markieren fehlende Modellvalidierung und fehlende Genauigkeitsmetriken.

Dokumentenregeln

  • Abschnitte der technischen Dokumentation (Artikel 11)

    Die Regeln von Scanara legen acht erforderliche Abschnitte für die technische Dokumentation fest, die auf Anhang IV beruhen, und prüfen, ob sie vorhanden sind. Sie prüfen, ob Inhalt vorhanden ist, nicht ob er gut ist.

  • Betriebsanleitungen (Artikel 13)

    Prüft, ob Betriebsanleitungen vorhanden sind und die geforderten Abschnitte enthalten.

  • EU-Konformitätserklärung

    Prüft, ob die Erklärung die in Anhang V aufgeführten Angaben enthält.

  • Acht Sprachen

    Der Dokumenten-Scan unterstützt EN, DE, FR, IT, ES, NL, PL und PT.

Checkliste zur Umsetzung

  • Fügen Sie dem Pull-Request-Workflow einen Code- und Dokumenten-Scan hinzu.
  • Beginnen Sie im Nur-Bericht-Modus und prüfen Sie die Befunde.
  • Legen Sie Grenzwerte für kritische und hohe Befunde fest und wechseln Sie dann in den blockierenden Modus.
  • Verlangen Sie eine menschliche Prüfung jedes Befunds, der Artikel 5 oder Artikel 14 berührt.
  • Bewahren Sie den Scan-Bericht bei jedem Release-Eintrag auf.
  • Markieren Sie Änderungen an Modell, Trainingsdaten oder Zweckbestimmung zur Prüfung als mögliche wesentliche Veränderungen (Artikel 43 Absatz 4).
  • Führen Sie vor jedem Release den vollständigen Scan erneut aus und aktualisieren Sie die Dokumentation nach Anhang IV.
  • Halten Sie die technische Dokumentation im Repository neben dem Code und aktualisieren Sie sie im selben Pull Request.

Ausnahmen, ältere Systeme und Obergrenzen für Geldbußen

Die Verordnung gilt nicht für KI-Systeme, die ausschließlich für militärische Zwecke, Verteidigungszwecke oder Zwecke der nationalen Sicherheit verwendet werden (Artikel 2 Absatz 3). Sie gilt nicht für KI-Systeme, die eigens und allein für die wissenschaftliche Forschung und Entwicklung entwickelt und in Betrieb genommen werden (Artikel 2 Absatz 6), und nicht für Forschung, Tests und Entwicklung vor dem Inverkehrbringen oder der Inbetriebnahme, außer für Tests unter Realbedingungen (Artikel 2 Absatz 8). KI-Systeme unter freien und quelloffenen Lizenzen sind ausgenommen, außer wenn sie als Hochrisiko-KI-Systeme in Verkehr gebracht oder in Betrieb genommen werden oder unter Artikel 5 oder 50 fallen (Artikel 2 Absatz 12). Natürliche Personen, die ein System im Rahmen einer rein persönlichen und nicht beruflichen Tätigkeit verwenden, sind nicht als Betreiber gebunden (Artikel 2 Absatz 10). Für Hochrisiko-Systeme im Zusammenhang mit Produkten nach Rechtsvorschriften des Anhangs I Abschnitt B, etwa Kraftfahrzeugen, Luftfahrt, Eisenbahn, Schiffsausrüstung, land- und forstwirtschaftlichen Fahrzeugen und Maschinen, gelten nur Artikel 6 Absatz 1, Artikel 60a und die Artikel 102 bis 112. Die Artikel 57 bis 59 gelten nur, soweit diese Rechtsvorschriften die Anforderungen übernehmen (Artikel 2 Absatz 2).

Hochrisiko-Systeme, die vor dem Geltungstermin in Verkehr gebracht oder in Betrieb genommen wurden, erfasst die Verordnung erst nach erheblichen Konzeptionsänderungen. In jedem Fall treffen Anbieter und Betreiber von Hochrisiko-KI-Systemen, die bestimmungsgemäß von Behörden verwendet werden sollen, die erforderlichen Maßnahmen zur Einhaltung bis zum 2. August 2030 (Artikel 111 Absatz 2).

Bei KMU gilt für jede Geldbuße der niedrigere Prozentsatz oder Betrag als Obergrenze (Artikel 99 Absatz 6). Für kleine Midcap-Unternehmen (Artikel 3 Nummer 14b) gilt dieselbe Obergrenze für Geldbußen nach Artikel 99 Absätze 4 und 5 (Artikel 99 Absatz 6a). Die Stufe mit 15 Mio. EUR umfasst auch die Pflichten von Anbietern und Akteuren nach Artikel 25 Absätze 2 und 4 (Artikel 99 Absatz 4 Buchstabe da).

Als Nächstes lesen: Audit-Trails, regelbasiertes Scannen und technische Dokumentation

Scanara bereitet Nachweise aus Ihren Repositorien vor

Scanara liest Ihre verbundenen GitHub-Repositorien und führt regelbasierte Scans auf gängige KI- und Machine-Learning-Muster durch. Unübliche Codemuster kann es übersehen. Getrennt davon erzeugt es aus Vorlagen und Ihren Antworten in der Bewertung Dokumentationsentwürfe als Nachweise für Ihre Compliance-Arbeit. Die Einstufung entscheiden Sie.