Wie weist man gegenüber Revision und Audit nach, was ein KI-Tool getan hat?

Mit einem Nachweis pro Änderung, der fünf Fragen beantwortet. Welches Tool in welcher Version hat gehandelt, auf welchen Auftrag mit welchen Grenzen, was wurde geändert, was wurde mit welchem Ergebnis validiert, und wer hat freigegeben. Git beantwortet nur die dritte Frage. Teams, die alle fünf beantworten, führen ein strukturiertes Beleg-Artefakt pro KI-Run, gespeichert beim Code - das Muster kennen Auditoren aus Build-Provenance und Change-Management.

Welche Regulierung verlangt konkret einen Audit-Trail für KI-Code?

Keine der hier geprüften Primärquellen nennt einen „KI-Code-Audit-Trail“ wörtlich. NIS2 Artikel 20 und 21 behandeln Leitungsaufsicht, Lieferkettensicherheit und sichere Entwicklung; die Produkthaftungsrichtlinie behandelt Software als Produkt und gilt für Produkte, die nach dem 8. Dezember 2026 in Verkehr gebracht oder in Betrieb genommen werden. Diese Pflichten auf einen Run-Record abzubilden ist eine Control-Design-Entscheidung, keine Aussage, dass das Gesetz genau dieses Format verlangt.

Reicht die Git-Historie nicht?

Git hält fest, was sich geändert hat und wer committet hat. Nicht, was der Auftrag war, was das Tool anfassen durfte, welche Validierung lief, was sie fand und wer das Ergebnis geprüft hat. Commit-Messages und PR-Kommentare enthalten Bruchstücke davon, unstrukturiert und uneinheitlich. Für einen Auditor ist das der Unterschied zwischen Beweis und Archäologie.

Welche Felder enthält ein brauchbarer Audit-Trail-Eintrag?

Das Arbeitsset: Zeitstempel; Tool- und Modell-Version; der schriftliche Auftrag inklusive Grenzen; Umfang der Änderung (Dateien, Diff-Statistik); gelaufene Validierungen mit Ergebnis, inklusive bewusst Übersprungenem; offene Unsicherheiten; und der freigebende Mensch. Maschinenlesbar, ein Eintrag pro Run, beim Repository gespeichert. Teams mit Prüfberichten pro Run bekommen das als Nebenprodukt statt als Projekt.

Müssen wir offenlegen, welcher Code KI-generiert ist?

AI Act Artikel 50 enthält Transparenzpflichten für bestimmte interaktive oder synthetische Inhalte; er schafft keine allgemeine Herkunftskennzeichnung für einzelne Quellcodezeilen gewöhnlicher kommerzieller Software. Diese begrenzte Lesart gilt zum 16. Juli 2026 und ist kein universelles Rechtsurteil. Verträge, Branchenregeln oder interne Richtlinien können eigene Provenance-Pflichten setzen; das bewerten Justiziariat und verantwortliche Control-Owner.

Wie fangen wir an, ohne den Ozean zu kochen?

Beginnt mit einer begrenzten Änderungsklasse: Agent-Runs, die Code ändern. Benennt Owner für Auftrag, Run-Record, Prüf-Receipt, Freigabe und Aufbewahrungslink. Pilotiert die Kette in einem Repository und lasst interne Revision, Legal und Records Management prüfen, ob Integrität, Zugriff und Aufbewahrung zu den geltenden Kriterien passen.

Audit-Trails für KI-generierten Code

Zuletzt aktualisiert: 2026-07-16Lesezeit ca. 4 Min.

Ein Audit-Trail für KI-generierten Code hält pro Änderung fest, was kein Git-Log enthält: welches Tool gehandelt hat, auf welchen schriftlichen Auftrag, was sich geändert hat, was mit welchem Ergebnis validiert wurde und wer freigegeben hat. Er ist ein Engineering-Control-Muster, kein rechtlicher Safe Harbour: Die datierte Quellenzuordnung unten trennt Primärpflichten von der redaktionellen Ableitung und nennt, was jedes verknüpfte Artefakt belegen kann und was nicht.

Inhalt

Warum die Frage plötzlich in Audits auftaucht

Rechtsstand: 16. Juli 2026. Dieser Artikel beschreibt Regulierung zur Orientierung - er ist keine Rechtsberatung; was eure Auditoren akzeptieren, entscheiden sie und euer Justiziariat.

Kein einzelnes Gesetz sagt „führt einen KI-Code-Audit-Trail“. Die relevanten Pflichten haben verschiedene Geltungsbereiche. NIS2 Artikel 20 und 21 behandeln Leitungsaufsicht sowie risikobasierte Lieferketten- und sichere Entwicklungsmaßnahmen. Die Produkthaftungsrichtlinie nimmt Software in den Produktbegriff auf und gilt nach ihrer Berichtigung 2026 für Produkte, die nach dem 8. Dezember 2026 in Verkehr gebracht oder in Betrieb genommen werden.

Keine Quelle schreibt das Record-Format dieser Seite vor. Die Zuordnung unten ist ein begrenztes Control-Design, das ein verantwortlicher Owner gegen Rechts-, Vertrags- und Audit-Kriterien prüfen muss.

Rechtsanker und Schlussgrenze

Scope: EU-NIS2, EU-Produkthaftung, AI Act und BSI/ANSSI-Tool-Empfehlungen; konkrete nationale, sektorale, vertragliche und Audit-Anforderungen sind separat zu prüfen.
Stand: 16. Juli 2026
Methode: Wir trennen den Wortlaut der Primärquelle von der redaktionellen Zuordnung eines per-Run Records als technische Control. Jede Schlussfolgerung nennt ihre Grenze.
Primäranker: NIS2 Art. 20/21: Management-Aufsicht plus risikobasierte Supply-Chain- und sichere EntwicklungsmaßnahmenNIS2 - Richtlinie (EU) 2022/2555 (englisch) · 2026-07-16
Produkthaftung: Software als Produkt; Richtlinie gilt für Produkte nach dem 8. Dezember 2026EU-Produkthaftungsrichtlinie 2024/2853 - Berichtigung 2026 (englisch) · 2026-07-16
AI Act Art. 50: Transparenz für bestimmte interaktive oder synthetische Outputs; keine allgemeine Code-Zeilen-KennzeichnungEU AI Act - Verordnung (EU) 2024/1689 (englisch) · 2026-07-16
Coding-Assistent: Generierten Code prüfen und durch Entwickelnde reproduzierenBSI/ANSSI - Empfehlungen zu KI-Programmierassistenten (englisch) · 2026-07-16
Nicht abgeleitet: Keine Aussage, dass ein bestimmtes Record-Format gesetzlich vorgeschrieben oder von jedem Auditor akzeptiert ist
Kein Safe Harbour und keine Vermutung, ein Record beweise Fehlerfreiheit, Kausalität oder Compliance
Keine pauschale Pflicht, gewöhnlichen kommerziellen Quellcode als KI-generiert zu kennzeichnen
Grenzen: Nationale Umsetzung, Sektorregeln, Verträge und konkrete Audit-Kriterien können zusätzliche oder andere Artefakte verlangen
Aufbewahrungsdauer und Zugriffsrechte hängen vom geltenden System und der Risikoklasse ab
Ein Record ist nur so verlässlich wie seine Integrität, Vollständigkeit und unabhängige Prüfung

Keiner der Anker verlangt wörtlich einen „KI-Code-Audit-Trail“; das Artefakt ist eine redaktionelle Control-Antwort auf getrennte Pflichten.

Was der Trail festhalten muss - und wo Git endet

Artefakt, Owner und Beweisgrenze

Ein Trail ist eine verknüpfte Record-Kette; kein einzelnes Artefakt beweist die ganze Änderung.
	Auftrag	Run-Record	Prüf-Receipt	Freigabe	Aufbewahrungslink
Accountable Owner	Product-/Change-OwnerRedaktionelle Control-Zuordnung · 2026-07-16	Engineering-OwnerRedaktionelle Control-Zuordnung · 2026-07-16	Control-Owner oder unabhängiger ReviewerRedaktionelle Control-Zuordnung · 2026-07-16	Benannte accountable RolleRedaktionelle Control-Zuordnung · 2026-07-16	Repository-/Records-OwnerRedaktionelle Control-Zuordnung · 2026-07-16
Belegt	Beabsichtigtes Ziel und GrenzenRedaktionelle Control-Zuordnung · 2026-07-16	Tool, Scope und beobachtete ÄnderungRedaktionelle Control-Zuordnung · 2026-07-16	Befehl, Ergebnis und ZeitpunktRedaktionelle Control-Zuordnung · 2026-07-16	Wer welche Entscheidung wann trafRedaktionelle Control-Zuordnung · 2026-07-16	Zuordnung zu Code-Version und Retention-OrtRedaktionelle Control-Zuordnung · 2026-07-16
Belegt nicht	Nicht, dass die Umsetzung korrekt istRedaktionelle Control-Zuordnung · 2026-07-16	Nicht die Autorschaft jeder ZeileRedaktionelle Control-Zuordnung · 2026-07-16	Nicht Fehlerfreiheit oder ComplianceRedaktionelle Control-Zuordnung · 2026-07-16	Nicht unabhängige AssuranceRedaktionelle Control-Zuordnung · 2026-07-16	Nicht die rechtlich ausreichende AufbewahrungsdauerRedaktionelle Control-Zuordnung · 2026-07-16

Ein Trail ist eine verknüpfte Record-Kette; kein einzelnes Artefakt beweist die ganze Änderung.

Die Lücke ist strukturell, kein Git-Mangel: Versionskontrolle protokolliert Ergebnisse, nicht Aufträge und Prüfungen. Commit-Messages und PR-Threads halten Bruchstücke - unstrukturiert, uneinheitlich und verstreut über Plattformen, die womöglich nicht Teil eurer Aufbewahrung sind. Für einen Auditor ist das der Unterschied zwischen Beweis und Archäologie.

Den Trail aufbauen, ohne ein Bürokratie-Projekt zu starten

Ein schriftlicher Auftrag pro KI-Run. Ziel, Grenzen, Kriterien - in prüfbarer Form. Das ist der Auftrag, auf den der Trail zurückverweist.
Ein strukturierter Eintrag pro Run. Tool und Version, Diff-Umfang, Validierungen mit Ergebnis, Übersprungenes, Unsicherheiten, Freigebender - maschinenlesbar, als Nebenprodukt des Workflows erzeugt, nicht hinterher abgetippt. Wie sich solche Einträge verketten lassen, damit später erkennbar bleibt, dass niemand nachträglich daran gedreht hat, steht unter Run-Eintrag und Digest-Kette.
Beim Code gespeichert. Das Repository ist der eine Ort, der Lebensdauer und Aufbewahrung des Codes teilt - Trails in Chat-Threads und Ticket-Kommentaren überleben keine Tool-Migration.
In der Richtlinie verankert. Eine Zeile in eurer KI-Coding-Richtlinie, die sagt: Agent-Änderungen tragen Belege - damit der Trail eine Regel ist und keine Gewohnheit, die unter Termindruck erodiert.

Die BSI/ANSSI-Empfehlungen zeigen in dieselbe Richtung: Assistenten-Output als ungeprüften Input behandeln - und seine Prüfung sichtbar machen.

Wo Reality Graph ansetzt

Genau dieses Artefakt erzeugt Reality Graph von Haus aus: Jeder KI-Coding-Run wird gegen seinen schriftlichen Auftrag verifiziert, und das Ergebnis - Änderungen, Validierungen, Resultate, Übersprungenes, offene Punkte - landet in einem Prüfbericht, gespeichert beim Code, local-first. Ob dieser Nachweis einem konkreten Auditor oder einer konkreten Regulierung genügt, bewerten diese und euer Justiziariat - Reality Graph liefert die Dokumentation, nicht das Urteil.

Ein verknüpfter Trail liefert

Auftrag, Änderung, Prüfung und Entscheidung pro Run
Benannte Owner je Artefakt
Zeit- und Versionsbezug
Einen Startpunkt für Incident- und Audit-Fragen

Er liefert nicht

Eine gesetzliche Pflichten-Checkliste
Ein universell akzeptiertes Format
Fehlerfreiheit oder Compliance
Herkunft für historischen Code ohne Records

Records machen Entscheidungen prüfbar; sie ersetzen weder Prüfung noch Urteil.

FAQ

Wie weist man gegenüber Revision und Audit nach, was ein KI-Tool getan hat?: Mit einem Nachweis pro Änderung, der fünf Fragen beantwortet. Welches Tool in welcher Version hat gehandelt, auf welchen Auftrag mit welchen Grenzen, was wurde geändert, was wurde mit welchem Ergebnis validiert, und wer hat freigegeben. Git beantwortet nur die dritte Frage. Teams, die alle fünf beantworten, führen ein strukturiertes Beleg-Artefakt pro KI-Run, gespeichert beim Code - das Muster kennen Auditoren aus Build-Provenance und Change-Management.
Welche Regulierung verlangt konkret einen Audit-Trail für KI-Code?: Keine der hier geprüften Primärquellen nennt einen „KI-Code-Audit-Trail“ wörtlich. NIS2 Artikel 20 und 21 behandeln Leitungsaufsicht, Lieferkettensicherheit und sichere Entwicklung; die Produkthaftungsrichtlinie behandelt Software als Produkt und gilt für Produkte, die nach dem 8. Dezember 2026 in Verkehr gebracht oder in Betrieb genommen werden. Diese Pflichten auf einen Run-Record abzubilden ist eine Control-Design-Entscheidung, keine Aussage, dass das Gesetz genau dieses Format verlangt.
Reicht die Git-Historie nicht?: Git hält fest, was sich geändert hat und wer committet hat. Nicht, was der Auftrag war, was das Tool anfassen durfte, welche Validierung lief, was sie fand und wer das Ergebnis geprüft hat. Commit-Messages und PR-Kommentare enthalten Bruchstücke davon, unstrukturiert und uneinheitlich. Für einen Auditor ist das der Unterschied zwischen Beweis und Archäologie.
Welche Felder enthält ein brauchbarer Audit-Trail-Eintrag?: Das Arbeitsset: Zeitstempel; Tool- und Modell-Version; der schriftliche Auftrag inklusive Grenzen; Umfang der Änderung (Dateien, Diff-Statistik); gelaufene Validierungen mit Ergebnis, inklusive bewusst Übersprungenem; offene Unsicherheiten; und der freigebende Mensch. Maschinenlesbar, ein Eintrag pro Run, beim Repository gespeichert. Teams mit Prüfberichten pro Run bekommen das als Nebenprodukt statt als Projekt.
Müssen wir offenlegen, welcher Code KI-generiert ist?: AI Act Artikel 50 enthält Transparenzpflichten für bestimmte interaktive oder synthetische Inhalte; er schafft keine allgemeine Herkunftskennzeichnung für einzelne Quellcodezeilen gewöhnlicher kommerzieller Software. Diese begrenzte Lesart gilt zum 16. Juli 2026 und ist kein universelles Rechtsurteil. Verträge, Branchenregeln oder interne Richtlinien können eigene Provenance-Pflichten setzen; das bewerten Justiziariat und verantwortliche Control-Owner.
Wie fangen wir an, ohne den Ozean zu kochen?: Beginnt mit einer begrenzten Änderungsklasse: Agent-Runs, die Code ändern. Benennt Owner für Auftrag, Run-Record, Prüf-Receipt, Freigabe und Aufbewahrungslink. Pilotiert die Kette in einem Repository und lasst interne Revision, Legal und Records Management prüfen, ob Integrität, Zugriff und Aufbewahrung zu den geltenden Kriterien passen.

Weiterlesen

BelegKI-Code-PrüfberichteAuftrag, Änderungen, Validierung mit Ergebnis, bewusst Übersprungenes und Offenes - pro Run festgehalten und beim Code gespeichert. Struktur und ein gekennzeichnetes Beispiel.GovernanceKI-Coding-GovernanceKontrollen, Workflows, Freigaben und Belege, mit denen ein Team KI-Coding-Tools einführt, ohne Engineering-Verantwortung zu verlieren - samt der Grenzen jedes Bausteins.Alle ArtikelDie ganze Sammlung - 58 belegte, datierte Guides zur Prüfung von KI-generiertem Code.

Quellen

Wollt ihr sehen, wie euer letzter Agenten-Run ausgesehen hätte?

Zugang anfragen