EU AI Act in der Praxis: Wie sieht Nachweispflicht in Code aus (Ed25519 statt Word-Dokumente)?

Das Missverständnis

Viele Compliance-Projekte zum EU AI Act enden in einem Ordner: Risikobewertung, Verfahrensbeschreibung, Rollenmatrix. Das ist notwendig – aber es beantwortet nicht die Frage, die ein Prüfer am Ende stellt: Was hat das System an diesem Tag mit diesem Vorgang getan, und woher wissen Sie das?

Art. 12 verlangt für Hochrisiko-Systeme automatische Protokollierung über die gesamte Lebensdauer, Art. 14 menschliche Aufsicht, Art. 26 die Aufbewahrung der Logs durch den Betreiber. Ein Log, das der Betreiber selbst jederzeit ändern kann, ist dafür ein schwacher Beleg.

Die Entscheidung: Nachweise als Artefakte

ATF erzeugt Nachweise bei der Ausführung und versiegelt sie mit einer asymmetrischen Identität (Ed25519, EVIDENCE_SIGNING_KEY). Der öffentliche Schlüssel liegt als JWKS unter /.well-known/atf-evidence-jwks.json. Wer prüft, braucht kein Geheimnis und keinen Zugang zur Plattform.

Pflicht	Artefakt in ATF
Art. 12 – Protokollierung	Hash-verkettetes Audit-Log mit signierten Ankern; Debug-Trace mit flow_version und flow_digest
Art. 13 – Transparenz	Erklärkarte pro Antwort: Modell, Quellen, Policy-Entscheidungen, Routing
Art. 14 – menschliche Aufsicht	Freigabe-Entscheidungen inkl. Timeout als Audit-Einträge, fail-closed
Art. 15 – Robustheit	Eval-Historie, Red-Team-Posture-Score, Produktions-Gates
Art. 50 – Kennzeichnung	AI_DISCLOSURE=header|field als maschinenlesbare Markierung
DSGVO Art. 17	Signierter Löschbeleg über alle Dienste

So sieht das im Code aus

Ein Evidence Bundle bindet eine Ausführung an Eingaben (bereits PII-maskiert), Policy-Entscheidungen, Quellen und Antwort. Inhalts-Hash und Signatur stehen im Umschlag:

{
  "bundle": { "version": 1, "executionId": "8e8b46df-…", "card": { "flowId": "refund-agent", "…": "…" } },
  "contentHash": "sha256:…",
  "algorithm": "ed25519",
  "kid": "e3bWHJM6PWuIanrPNdmBuUHHsJjr2WYsGRCNbghINNE",
  "signature": "…"
}

Geprüft wird offline, mit einem eigenständigen Werkzeug:

$ atf-verify --bundle evidence-bundle.json --jwks https://atf.example/.well-known/atf-evidence-jwks.json
  algorithm:    ed25519
  content hash: VALID
  signature:    VALID
RESULT: VALID

Dasselbe Werkzeug prüft Decision-Receipts (COSE_Sign1 mit Merkle-Inklusionsbeweis gegen einen signierten Tree-Head), Löschbelege, Flow-Release-Receipts und Audit-Exporte samt Ankern. Exit-Code 0 heißt verifiziert, 1 heißt Manipulation – maschinenlesbar für Ihre eigenen Prüfpipelines.

Warum Ed25519 und nicht HMAC

Ein HMAC-signierter Nachweis lässt sich nur mit demselben Geheimnis prüfen, mit dem er erstellt wurde. Wer prüfen kann, kann also auch fälschen. Für einen externen Prüfer ist das wertlos. Ed25519 trennt beides: Der Betreiber signiert, alle anderen prüfen. ATF verzweigt dabei strikt nach dem deklarierten Algorithmus – es gibt keinen stillen Rückfall auf HMAC.

Was ATF nicht für Sie erledigt

Die Rolle (Anbieter oder Betreiber), die Hochrisiko-Einstufung, die Risikobewertung, Schulungen nach Art. 4 und die Information Betroffener bleiben Ihre Aufgabe. ATF liefert dafür Vorlagen (DSFA, Verarbeitungsverzeichnis), ein Artikel-Mapping und ein generiertes Dossier – und die Belege, auf die sich all das stützt.

Der Unterschied zum Ordner: Diese Belege entstehen automatisch, bei jeder Ausführung, und sie lassen sich nicht nachträglich schönschreiben.