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 nennt „KI-Code-Audit-Trail“ wörtlich – die Anforderung setzt sich aus Nachbarpflichten zusammen. NIS2 (in Deutschland über das seit Dezember 2025 geltende Umsetzungsgesetz) verlangt gesteuerte, dokumentierte Entwicklungs- und Lieferketten-Risiken; die neue Produkthaftungsrichtlinie behandelt Software ab Dezember 2026 als Produkt, womit „wir können zeigen, wie das gebaut und geprüft wurde“ zur Verteidigungsposition wird; ISO-27001- und TISAX-Audits fragen, wie Tooling mit Repository-Zugriff kontrolliert wird. Branchenregeln (DORA, IEC 62304, Automotive SPICE) fordern Nachvollziehbarkeit ausdrücklich.

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?

Stand Juli 2026 gibt es keine allgemeine Rechtspflicht, KI-generierten Code in gewöhnlicher kommerzieller Software zu kennzeichnen – die Transparenzpflichten des AI Act zielen auf KI-Systeme, die mit Menschen interagieren, nicht auf Code-Herkunft. Interne Nachvollziehbarkeit ist eine andere Frage: Zu wissen, welche Änderungen von welchem Tool kamen, macht Incident Response, Lizenzprüfung und Audits erst arbeitsfähig. Ob konkrete Verträge oder Branchenregeln in eurem Fall Offenlegung verlangen, ist eine Frage ans Justiziariat.

Wie fangen wir an, ohne den Ozean zu kochen?

Fangt an, wo das Risiko sitzt: bei Agent-Runs, die Code ändern. Verlangt einen schriftlichen Auftrag pro Run, erfasst Diff-Umfang und Validierungsergebnisse in einem strukturierten Eintrag und speichert ihn beim Code. Diese eine Gewohnheit macht aus eurer volumenstärksten, am wenigsten bezeugten Änderungsquelle die bestdokumentierte – und es ist der Teil, nach dem Auditoren zuerst fragen, weil ihn später niemand rekonstruieren kann.

Compliance

Audit-Trails für KI-generierten Code

Zuletzt aktualisiert: 2026-07-02Lesezeit 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. Die Anforderung setzt sich aus mehreren Richtungen gleichzeitig zusammen – NIS2-Aufsichtspflichten, die neue Produkthaftung für Software, ISO- und Branchen-Audits – und landet beim selben Artefakt: strukturierte Belege pro Run, gespeichert beim Code.

Inhalt

Warum die Frage plötzlich in Audits auftaucht

Rechtsstand: 2. 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“. Der Druck setzt sich zusammen: Seit Dezember 2025 stellt das deutsche NIS2-Umsetzungsgesetz Entwicklungs- und Lieferketten-Risiken für rund 29.500 Unternehmen unter dokumentierte Leitungs-Aufsicht. Ab Dezember 2026 behandelt die neue Produkthaftungsrichtlinie Software – eigenständig oder als Service – als Produkt mit verschuldensunabhängiger Haftung; „wir können zeigen, wie das gebaut und geprüft wurde“ wird damit Verteidigungsposition statt Kür. Und Zertifizierungs-Audits stellen inzwischen die konkrete Frage: Was fassen eure KI-Tools an, und wer hat es geprüft? Bei nur 48 % konsequenter KI-Code-Prüfung lautet die ehrliche Antwort in den meisten Organisationen heute: Das kann niemand sagen.

Was der Trail festhalten muss – und wo Git endet

Frage	Was festzuhalten ist	Hält Git das?
Wer/was hat gehandelt?	Tool, Modell und Version; auslösender Mensch	Teilweise – Committer, nicht Tool-Identität
Auf welchen Auftrag?	Der schriftliche Auftrag: Ziel, Grenzen, Akzeptanzkriterien	Nein
Was hat sich geändert?	Dateien, Diff-Umfang, Migrationen, neue Dependencies	Ja – Gits Heimspiel
Was wurde geprüft?	Gelaufene Validierungen, Ergebnisse, Übersprungenes samt Grund	Nein
Wer hat freigegeben?	Reviewer/Freigebender, Entscheidung, Zeitstempel	Teilweise – PR-Approvals, falls eure Plattform sie aufbewahrt

Die fünf Fragen, die ein KI-Code-Audit-Trail beantwortet – Git beantwortet von Haus aus nur eine davon (Stand: Juli 2026).

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.
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 Audit-Trail pro Run gibt euch

Antworten auf die fünf Auditor-Fragen, pro Änderung
Incident Response, die weiß, welches Tool was angefasst hat
Eine Verteidigungsposition, während Software-Haftung anzieht
Belege als Nebenprodukt statt als Nacharbeit

Er gibt euch nicht

Eine Pflichten-Checkliste – die Pflichten setzen sich fallweise zusammen
Eine Garantie, dass jeder Auditor das Format akzeptiert – fragt eure
Herkunftsnachweise für Code aus der Zeit vor dem Trail
Einen Ersatz für die Verifikation selbst – er protokolliert Prüfungen, er ist keine

Wenn diese Grenzen zu eurem Team passen:

Early Access sichern So funktioniert es

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 nennt „KI-Code-Audit-Trail“ wörtlich – die Anforderung setzt sich aus Nachbarpflichten zusammen. NIS2 (in Deutschland über das seit Dezember 2025 geltende Umsetzungsgesetz) verlangt gesteuerte, dokumentierte Entwicklungs- und Lieferketten-Risiken; die neue Produkthaftungsrichtlinie behandelt Software ab Dezember 2026 als Produkt, womit „wir können zeigen, wie das gebaut und geprüft wurde“ zur Verteidigungsposition wird; ISO-27001- und TISAX-Audits fragen, wie Tooling mit Repository-Zugriff kontrolliert wird. Branchenregeln (DORA, IEC 62304, Automotive SPICE) fordern Nachvollziehbarkeit ausdrücklich.
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?: Stand Juli 2026 gibt es keine allgemeine Rechtspflicht, KI-generierten Code in gewöhnlicher kommerzieller Software zu kennzeichnen – die Transparenzpflichten des AI Act zielen auf KI-Systeme, die mit Menschen interagieren, nicht auf Code-Herkunft. Interne Nachvollziehbarkeit ist eine andere Frage: Zu wissen, welche Änderungen von welchem Tool kamen, macht Incident Response, Lizenzprüfung und Audits erst arbeitsfähig. Ob konkrete Verträge oder Branchenregeln in eurem Fall Offenlegung verlangen, ist eine Frage ans Justiziariat.
Wie fangen wir an, ohne den Ozean zu kochen?: Fangt an, wo das Risiko sitzt: bei Agent-Runs, die Code ändern. Verlangt einen schriftlichen Auftrag pro Run, erfasst Diff-Umfang und Validierungsergebnisse in einem strukturierten Eintrag und speichert ihn beim Code. Diese eine Gewohnheit macht aus eurer volumenstärksten, am wenigsten bezeugten Änderungsquelle die bestdokumentierte – und es ist der Teil, nach dem Auditoren zuerst fragen, weil ihn später niemand rekonstruieren kann.

Weiterlesen

ComplianceISO 27001, TISAX & BSI: KI-Coding zertifiziertKeiner der Standards verbietet KI-Tools – beide verlangen, dass sie im ISMS leben. Das Control-Mapping fürs Audit, die strengere TISAX-Datenbrille und die BSI/ANSSI-Empfehlungen.ComplianceNIS2 und Haftung für KI-CodeSeit Dezember 2025 muss die Geschäftsleitung Entwicklungsrisiken billigen und überwachen – die Box, in der ungeprüfter KI-Code sitzt. Die Pflichten, die Haftungsschichten nach dem AILD-Rückzug und was man dokumentiert. Noch keine Rechtsprechung.Alle ArtikelDie ganze Sammlung – 43 belegte, datierte Guides zur Prüfung von KI-generiertem Code.