Nachweisbarkeit
EU AI Act für Eigenentwicklung: die Pflichten, die Ihre Architektur betreffen.
Die Risikoklassen sind schnell gelesen. Interessant wird es dort, wo aus einer Pflicht eine Anforderung an die Bauform wird: automatische Protokollierung, nachvollziehbare Datenherkunft, erklärbare Entscheidungen. Diese Seite behandelt genau diesen Teil.
Die Einstufung ist Papier. Die Protokollpflicht ist Architektur.
Die meisten Unternehmen, mit denen wir sprechen, haben ihre KI-Anwendungsfälle bereits eingeordnet. Was danach passiert, ist der eigentliche Aufwand: Ein Hochrisikosystem muss über seine Laufzeit hinweg automatisch protokollieren, was es getan hat, und diese Protokolle müssen aufbewahrt werden. Nicht als Debug-Log, sondern als Nachweis.
Dazu kommt die Datenseite. Wenn ein Modell auf Ihren Geschäftsdaten arbeitet, muss nachvollziehbar sein, welche Daten in welchem Zustand hineingeflossen sind. Systeme, die nur den aktuellen Zustand speichern, können das nicht: Sie wissen nicht mehr, wie ein Datensatz zum Zeitpunkt der Entscheidung aussah.
Und schließlich die Aufsicht: Eine menschliche Kontrollinstanz braucht etwas zum Kontrollieren. Ohne festgehaltenen Entscheidungskontext bleibt „human oversight“ eine Zeile im Konzept.
Von der Pflicht zur Architekturanforderung.
Auszug aus den Pflichten für Hochrisikosysteme und für Anbieter, die in eigener Software KI einsetzen.
| Pflicht aus dem AI Act | Was das System können muss | Was Sie vorlegen |
|---|---|---|
| Automatische Protokollierung über den Lebenszyklus (Art. 12) | Jeder Modelllauf erzeugt einen Eintrag mit Eingabe-Referenz, Modellversion, Ergebnis und Zeitpunkt — unveränderlich. | Der vollständige Vorgang zu einem einzelnen Fall, Monate später und ohne Entwicklerhilfe abrufbar. |
| Aufbewahrung der Protokolle (Art. 19) | Protokolle liegen getrennt vom veränderbaren Anwendungszustand und überstehen Migrationen. | Nachweisbare Aufbewahrung über den gesetzlich geforderten Zeitraum. |
| Daten-Governance (Art. 10) | Datenherkunft und Datenstand sind rekonstruierbar — welcher Datensatz galt zum Entscheidungszeitpunkt. | Der Zustand der Eingangsdaten zum Stichtag, nicht der heutige Stand derselben Tabelle. |
| Technische Dokumentation (Art. 11, Anhang IV) | Modellversionen, Prompts, Parameter und Datenquellen sind versioniert und einem Release zugeordnet. | Welche Version welche Entscheidung getroffen hat — belegt, nicht erinnert. |
| Transparenz gegenüber Betroffenen (Art. 13, Art. 50) | Die für eine Entscheidung ausschlaggebenden Faktoren werden mit dem Ergebnis gespeichert. | Eine verständliche Begründung, die zur gespeicherten Historie passt. |
| Menschliche Aufsicht (Art. 14) | Eingriffe, Freigaben und Überstimmungen durch Menschen sind selbst Ereignisse im System. | Nachweis, dass Aufsicht stattgefunden hat — nicht nur, dass sie vorgesehen war. |
Umsetzungssicht, keine Rechtsberatung. Welche Pflichten für Sie gelten, hängt von Rolle (Anbieter, Betreiber) und Risikoklasse ab; die Anwendungszeitpunkte sind gestaffelt.
Was in AI-getriebener Entwicklung neu dazukommt.
Nicht nur das Modell im Produkt. Auch die Art, wie Software heute entsteht.
Kontext ist ein Produktionsartefakt
Prompt, Systemkontext und Modellversion bestimmen das Ergebnis so stark wie Code. Wer sie nicht versioniert, kann eine Entscheidung von letztem Quartal nicht mehr reproduzieren.
Herkunft von Änderungen
Wenn ein erheblicher Teil des Codes maschinell entsteht, wird die Frage „wer hat das entschieden“ zur Frage „was hat diese Änderung ausgelöst und wer hat sie freigegeben“. Das gehört in die Nachweiskette.
Beschleunigte Auslieferung ohne Belegkette
Mehr Releases pro Woche sind nur dann kein Risiko, wenn jede Änderung ihre Herkunft mitbringt. Sonst wächst die Rekonstruktionslücke schneller als die Produktivität.
Weniger Übergaben, weniger Nebenprodukte
Kleine Teams ohne Rollenübergaben erzeugen nebenbei weniger Dokumentation. Was früher als Nebeneffekt entstand, muss jetzt im System entstehen.
Wie wir das bauen.
Belegbarkeit ist billiger, wenn sie Teil des ersten Entwurfs ist.
1 — Entscheidungspunkte benennen
Wir identifizieren die Stellen, an denen ein Modell etwas entscheidet oder vorbereitet, das jemanden betrifft. Nur diese brauchen die volle Nachweiskette.
2 — Entscheidung als Ereignis
Ergebnis, Eingangsdaten-Referenz, Modellversion und Begründung werden als ein unveränderlicher Vorgang festgehalten — nicht als Feld, das der nächste Lauf überschreibt.
3 — Aufsicht sichtbar machen
Freigabe, Korrektur und Ablehnung durch Menschen werden mitgeschrieben. Damit wird aus einer Prozessvorgabe ein Nachweis.
4 — Auswertbar für Fachbereich und Prüfer
Eine Sicht, die ohne SQL-Kenntnisse beantwortet, was in einem konkreten Fall passiert ist. Wenn diese Sicht fehlt, wird jede Anfrage zum Ticket.
Wann das passt — und wann nicht.
Passt, wenn
- KI in einem Prozess entscheidet oder vorentscheidet, der Menschen oder Verträge betrifft
- ein Kunde oder Prüfer nach Erklärbarkeit und Protokollen fragt
- ein KI-Pilot produktiv gehen soll und an der Nachweisfrage hängen bleibt
- ein neues System entsteht, in dem KI von Anfang an vorgesehen ist
Passt nicht, wenn
- Sie eine Konformitätsbewertung oder Zertifizierung brauchen
- Sie Rechtsberatung zur Risikoeinstufung suchen
- es um reine Modellqualität geht — dafür gibt es bessere Spezialisten
- KI nur als Schlagwort im Projektantrag steht
Häufige Fragen
- Betrifft uns der AI Act, wenn wir nur ein fremdes Modell per API nutzen?
- Möglicherweise als Betreiber. Die Pflichten unterscheiden sich von denen eines Anbieters, aber Protokollierung und menschliche Aufsicht landen häufig trotzdem bei Ihnen — weil Ihre Software den Kontext liefert, nicht das Modell.
- Reicht es, die Prompts und Antworten zu speichern?
- Als Anfang ja. Belastbar wird es, wenn auch der Datenstand zum Entscheidungszeitpunkt und die Modellversion dazugehören. Sonst lässt sich der Fall später nicht reproduzieren.
- Ist das nicht einfach gutes Logging?
- Gutes Logging ist die halbe Miete. Der Unterschied liegt in der Unveränderlichkeit und darin, dass fachliche Entscheidungen als solche festgehalten werden — nicht als Nebenprodukt eines technischen Aufrufs.
- Was, wenn wir noch gar keine KI im Produkt haben?
- Dann ist jetzt der günstigste Zeitpunkt. Die genannten Anforderungen sind dieselben, die auch ohne KI im Audit gefragt werden. Nachrüsten ist der teure Weg.
Quellen
Alle Artikelverweise beziehen sich auf den veröffentlichten Verordnungstext.
Bevor der Pilot produktiv geht: Ist er belegbar?
Der Nachweisfähigkeits-Check prüft in zehn Fragen, ob Ihr System die Fragen beantwortet, die danach kommen.