Wie Scanaras Regeln entstehen und verifiziert werden

Diese Seite richtet sich an Entwickler und Compliance-Verantwortliche, die beurteilen wollen, wie verlässlich Scanaras Regeln sind. Jede Regel führt auf einen Artikel, Absatz und Buchstaben der KI-Verordnung zurück, und ein Regel-Release muss sechs Prüfungen bestehen. Der letzte Abschnitt nennt, was die Zahlen nicht messen.

Gemessen am 9. September 2026.

Wie Regeln entstehen

Scanaras Regel-Pipeline verarbeitet den Text der Verordnung (EU) 2024/1689 in der geänderten Fassung und verankert jede Regel an ihrem exakten Artikel, Absatz und Buchstaben. Eine einzige Zuordnungsdatei ordnet jeder Pflicht eines von drei Ergebnissen zu: im Code erkennbar, in einem Richtliniendokument prüfbar, oder nicht maschinell erkennbar und einem geführten Assessment überlassen.

Die Release-Prüfkette

Das Regelwerk durchläuft sechs Prüfstufen nacheinander, von groben Strukturprüfungen bis zum exakten Abgleich mit bekannter Sollausgabe. Alle sechs Stufen laufen in Scanaras CI-Pipeline.

L2.5

Katalog-Konsistenz

Prüft, dass Artikelkatalog, Pflichten-Mapping und etwaige Überlappungs-Unterdrückungsregeln miteinander synchron bleiben.

L1/L2

Korpus-Struktur

Strukturprüfungen über den Regelkorpus: Artikelabdeckung, keine doppelten Muster, vollständige Metadaten, gültige Enum-Werte, eindeutige Regel-IDs und Grenzen für Stub-Regeln.

Pflichtenbezogene Fixtures

Für jede im Code erkennbare Pflicht muss ein Positiv-Fixture mindestens einen Fund auslösen und ein Negativ-Fixture null Funde — in jeder unterstützten Sprache.

KPI-Schwellenwerte

17 Schwellenwerte zu Abdeckung, Vollständigkeit und Determinismus — siehe Tabelle unten.

Golden Snapshots

Ein exakter Abgleich jedes Befunds mit einem festgeschriebenen Sollergebnis, für die 27 Testanwendungen mit einem Golden Snapshot, festgelegt auf eine bestimmte Regelversion.

Remediation-Prüfung

Bestätigt, dass ein unbehandeltes Fixture einen unerfüllten Fund auslöst und dasselbe Fixture mit angewandter empfohlener Abhilfemaßnahme als erfüllt erkannt wird.

Wie Scanara Dokumentation mit OPA und Rego auswertet

Scanaras dokumentenbasierte Prüfungen laufen auf Open Policy Agent (OPA). OPA prüft technische Dokumentation gegen Pflichten der Verordnung (EU) 2024/1689. Das ist ein Policy-as-Code-Ansatz: deklarative Regeln und deterministische Auswertung, sodass dasselbe Dokument jedes Mal dasselbe Ergebnis liefert. Das läuft parallel zu Scanaras Code-Scan. Code-Scanning prüft, was der Code tut. OPA prüft, was die Dokumentation sagt.

Jede Dokumentationsdatei durchläuft dieselben Schritte. Zuerst parst Scanara die Datei und erkennt ihre Sprache (8 EU-Sprachen werden unterstützt). Dann normalisiert Scanara die Datei zu einem strukturierten Eingabedokument: Abschnitte, Überschriften, extrahierter Text. OPA wertet dieses strukturierte Dokument gegen ein kompiliertes Rego-Policy-Bundle aus.

Scanara generiert diese Regeln aus einer kanonischen Zuordnung zwischen dem Artikeltext der Verordnung (EU) 2024/1689 und maschinell prüfbaren Anforderungen. Keine Regel wird pro Repository von Hand geschrieben. Jede Regel lässt sich bis zu einem konkreten Artikel, Absatz und Buchstaben zurückverfolgen. Die Auswertung erzeugt einen Befund je Pflicht: erfüllt, fehlend oder teilweise erfüllt. Diese Befunde fließen zusammen mit den Code-Befunden in den Compliance-Bericht ein.

Das Beispiel unten zeigt das Muster, vereinfacht für die öffentliche Dokumentation. Der Produktiv-Regelsatz ist größer und behandelt zusätzlich mehrere Dokumentensprachen und die Gewichtung nach Schweregrad.

package eu_ai_act.example.article_11

# Illustrative pattern only — simplified for public documentation.
# Scanara's production ruleset is larger and also handles several document
# languages and severity weighting.

default satisfied := false

# A document satisfies this (illustrative) Article 11 check when its parsed
# sections include the required topic, with non-empty content.
satisfied if {
	some section in input.document.sections
	section.topic == "risk_management_process"
	count(trim_space(section.content)) > 0
}

finding := {
	"article": "11",
	"obligation": "technical_documentation.risk_management_process",
	"status": "satisfied",
} if satisfied

finding := {
	"article": "11",
	"obligation": "technical_documentation.risk_management_process",
	"status": "missing",
	"severity": "high",
} if not satisfied

Im Stand vom 24. August 2026 decken automatische Regeln 66 von 113 Artikeln ab (etwa 58 %). Code-Regeln decken 43 Artikel ab, Dokument-Regeln 23, in 8 EU-Dokumentensprachen. Die übrigen Artikel werden über geführte Assessments und erzeugte Dokumentation behandelt oder betreffen Behörden statt Betreiber. Die Zahlen sind ein Stichtagswert und ändern sich mit jedem Lauf der Regelgenerierung. Die Befunde beider Engines fließen in den Compliance-Bericht ein, und jeder Befund lässt sich auf ein tatsächliches Scan-Ergebnis zurückführen, nicht auf eine selbst ausgefüllte Checkliste.

Aktuell gemessene Werte

Metrik	Schwellenwert	Aktuell
Von der Regel-Pipeline erfasste Artikel (119 in der Verordnung)	100%	100%
Echte-Pattern-Abdeckung code-fähiger Artikel	100%	100%
Dokument-/Richtlinien-Artikel mit OPA-Abdeckung	100%	100%
Im Code erkennbare Pflichten mit mindestens einer Regel	100%	100%
Regeln mit Risikostufen-Metadaten	100%	100%
Regeln mit Akteurs-Metadaten	100%	100%
Regeln mit strukturierter Abhilfe-Anleitung	100%	100%
Streuung der Regelanzahl über die 12 unterstützten Sprachen	≤ 1	0
Doppelte Regel-IDs	0	0
Stub-Regeln (ohne Code-Pattern) je Artikel	≤ 1	0
Bestehende L4-KPI-Schwellenwerte	17/17	17/17

Was diese Zahlen nicht messen

Die 100 %-Werte bei der Artikelabdeckung bedeuten, dass die Regel-Pipeline jeden Artikel erfasst; sie bedeuten nicht, dass jeder Artikel automatisch geprüft wird. Diese Kennzahlen messen Abdeckung, Vollständigkeit und Determinismus: wie viel der Verordnung zugeordnet ist und wie konsistent die Pipeline über Sprachen und Releases arbeitet. Es gibt keine Kennzahl für Precision, Recall oder Falsch-Positiv-Rate, weil dafür ein von Menschen gelabeltes Referenzkorpus nötig ist, das Scanara nicht hat. Der strukturelle Beleg gegen Falschmeldungen ist dieser: Jedes Negativ-Fixture pro Pflicht muss null Funde liefern, und eine eigene Testanwendung mit minimalem Risiko, bei der alle Regeln für Hochrisiko, KI-Modelle mit allgemeinem Verwendungszweck und begrenztes Risiko unterdrückt sind, muss ebenfalls null Funde liefern.

Scanara erkennt die Lücken in Code und Dokumenten, die seine Regeln abdecken. Eigene, nicht standardmäßige oder verschleierte Codeteile kann es übersehen, und ein bestandener Scan bedeutet nicht, dass eine Organisation die Vorgaben einhält. Einstufung und rechtliche Auslegung bleiben bei Ihnen und Ihrer Rechtsberatung.