How do you prove to auditors what an AI tool did in your codebase?

With a per-change record that answers five questions. Which tool and version acted, on what task with which boundaries, what changed, what was validated with which result, and who approved it. Git answers only the third question. The teams that answer all five keep a structured evidence artifact per AI run, stored with the code - the pattern auditors already know from build provenance and change management.

Which regulations actually demand an audit trail for AI code?

None of the primary sources reviewed here names an 'AI code audit trail' verbatim. NIS2 Articles 20 and 21 address management oversight, supply-chain security and secure development. The Product Liability Directive treats software as a product and applies to products placed on the market or put into service after December 8, 2026. Mapping those duties to a per-run record is a control-design choice, not a statement that law requires this exact format.

Isn't git history enough?

Git records what changed and who committed - it does not record what the task was, what the tool was allowed to touch, what validation ran, what it found, or who reviewed the result. Commit messages and PR comments hold fragments of this, unstructured and inconsistently. For an auditor, that is the difference between evidence and archaeology.

What fields does a usable audit trail entry contain?

The working set: timestamp; tool and model version; the written task including boundaries; scope of the change (files, diff stats). Validations run and their results, including what was skipped; open uncertainties; and the human who approved. Machine-readable, one record per run, stored with the repository. Teams that keep evidence reports per run get this as a byproduct instead of a project.

Do we have to disclose which code is AI-generated?

AI Act Article 50 sets transparency duties for specified interactive or synthetic content; it does not create a general source-line label for ordinary commercial code. That scoped reading is current to July 16, 2026, not a universal legal conclusion. Contracts, sector rules or internal policy may impose separate provenance duties, which counsel and accountable control owners must assess.

How do we start without boiling the ocean?

Start with one bounded change class: agent runs that modify code. Assign owners for the task, run record, validation receipt, approval and retention link. Pilot the chain on one repository, then ask your internal audit, legal and records owners whether its integrity, access and retention fit the applicable criteria.

Compliance

Audit Trails for AI-Generated Code

Last updated: 2026-07-164 min read

An audit trail for AI-generated code records per change what no git log holds: which tool acted, on what written task, what changed, what was validated with which result, and who approved. It is an engineering control pattern, not a legal safe harbour. The dated source map below separates the primary duties from the editorial inference and states what each linked artifact can and cannot establish.

Contents

Why the question suddenly arrives in audits

Legal status: July 16, 2026. This article describes regulation for orientation - it is not legal advice; what your auditors accept is their call and your counsel’s.

No single law says “keep an AI code audit trail”. The relevant duties have different scopes. NIS2 Articles 20 and 21 address management oversight and risk-based supply-chain and secure-development measures. The Product Liability Directive includes software in its product definition and, after its 2026 corrigendum, applies to products placed on the market or put into service after December 8, 2026. Neither source prescribes this page’s record format. The mapping below is a bounded control design that an accountable owner must test against the actual legal, contractual and audit criteria.

Legal anchors and inference boundary

Scope: EU NIS2, EU product liability, the AI Act and BSI/ANSSI tool guidance; assess concrete national, sector, contractual and audit requirements separately.
Status: 16 July 2026
Method: We separate primary-source text from the editorial mapping of a per-run record as a technical control. Every inference states its boundary.
Primary anchors: NIS2 Articles 20/21: Management oversight plus risk-based supply-chain and secure-development measuresNIS2 - Directive (EU) 2022/2555 · 2026-07-16
Product liability: Software treated as a product; directive applies to products after 8 December 2026EU Product Liability Directive 2024/2853 - 2026 corrigendum · 2026-07-16
AI Act Art. 50: Transparency for specified interactive or synthetic outputs; no general source-line labelEU AI Act - Regulation (EU) 2024/1689 · 2026-07-16
Coding assistant: Generated code should be checked and reproduced by developersBSI/ANSSI - AI coding-assistant recommendations · 2026-07-16
Not inferred: No claim that a specific record format is legally required or accepted by every auditor
No safe harbour and no inference that a record proves correctness, causation or compliance
No general duty to label ordinary commercial source code as AI-generated
Limitations: National implementation, sector rules, contracts and concrete audit criteria may require additional or different artifacts
Retention and access depend on the applicable system and risk classification
A record is only as reliable as its integrity, completeness and independent review

None of the anchors literally requires an ‘AI-code audit trail’; the artifact is an editorial control response to separate duties.

What the trail must record - and where git ends

Artifact, owner and proof boundary

A trail is a linked record chain; no single artifact proves the whole change.
	Task	Run record	Validation receipt	Approval	Retention link
Accountable owner	Product/change ownerEditorial control mapping · 2026-07-16	Engineering ownerEditorial control mapping · 2026-07-16	Control owner or independent reviewerEditorial control mapping · 2026-07-16	Named accountable roleEditorial control mapping · 2026-07-16	Repository/records ownerEditorial control mapping · 2026-07-16
Establishes	Intended goal and boundariesEditorial control mapping · 2026-07-16	Tool, scope and observed changeEditorial control mapping · 2026-07-16	Command, outcome and timeEditorial control mapping · 2026-07-16	Who made which decision and whenEditorial control mapping · 2026-07-16	Link to code version and retention locationEditorial control mapping · 2026-07-16
Does not establish	Not that implementation is correctEditorial control mapping · 2026-07-16	Not authorship of every lineEditorial control mapping · 2026-07-16	Not correctness or complianceEditorial control mapping · 2026-07-16	Not independent assuranceEditorial control mapping · 2026-07-16	Not legally sufficient retention durationEditorial control mapping · 2026-07-16

A trail is a linked record chain; no single artifact proves the whole change.

The gap is structural, not a git flaw: version control records outcomes, not mandates and checks. Commit messages and PR threads hold fragments - unstructured, inconsistent, and scattered across platforms that may not be part of your retention. For an auditor, that is the difference between evidence and archaeology.

Building the trail without a bureaucracy project

One written task per AI run. Goal, boundaries, criteria - checkable form. This is the mandate the trail refers back to.
One structured record per run. Tool and version, diff scope, validations with results, skips, uncertainties, approver - machine-readable, generated as a byproduct of the workflow, not typed up afterwards. How such records can be chained so a later reader can tell they were not edited afterwards is described under the run record and its digest chain.
Stored with the code. The repository is the one place that shares the code’s lifetime and retention - trails in chat threads and ticket comments do not survive tool migrations.
Anchored in policy. A line in your AI coding policy that says agent changes carry evidence - so the trail is a rule, not a habit that erodes under deadline pressure.

The BSI/ANSSI recommendations point the same direction: treat assistant output as unverified input, and make its checking visible.

Where Reality Graph fits

This artifact is what Reality Graph produces natively: each AI coding run is verified against its written task, and the outcome - changes, validations, results, skips, open points - lands in an evidence report stored with the code, local-first. Whether that record satisfies a specific auditor or regulation is their assessment and your counsel’s - Reality Graph supplies the documentation, not the verdict.

A linked trail provides

Task, change, check and decision per run
Named owners for each artifact
Time and version linkage
A starting point for incident and audit questions

It does not provide

A legal-duty checklist
A universally accepted format
Correctness or compliance
Provenance for historical code without records

Records make decisions reviewable; they replace neither checking nor judgement.

FAQ

How do you prove to auditors what an AI tool did in your codebase?: With a per-change record that answers five questions. Which tool and version acted, on what task with which boundaries, what changed, what was validated with which result, and who approved it. Git answers only the third question. The teams that answer all five keep a structured evidence artifact per AI run, stored with the code - the pattern auditors already know from build provenance and change management.
Which regulations actually demand an audit trail for AI code?: None of the primary sources reviewed here names an 'AI code audit trail' verbatim. NIS2 Articles 20 and 21 address management oversight, supply-chain security and secure development. The Product Liability Directive treats software as a product and applies to products placed on the market or put into service after December 8, 2026. Mapping those duties to a per-run record is a control-design choice, not a statement that law requires this exact format.
Isn't git history enough?: Git records what changed and who committed - it does not record what the task was, what the tool was allowed to touch, what validation ran, what it found, or who reviewed the result. Commit messages and PR comments hold fragments of this, unstructured and inconsistently. For an auditor, that is the difference between evidence and archaeology.
What fields does a usable audit trail entry contain?: The working set: timestamp; tool and model version; the written task including boundaries; scope of the change (files, diff stats). Validations run and their results, including what was skipped; open uncertainties; and the human who approved. Machine-readable, one record per run, stored with the repository. Teams that keep evidence reports per run get this as a byproduct instead of a project.
Do we have to disclose which code is AI-generated?: AI Act Article 50 sets transparency duties for specified interactive or synthetic content; it does not create a general source-line label for ordinary commercial code. That scoped reading is current to July 16, 2026, not a universal legal conclusion. Contracts, sector rules or internal policy may impose separate provenance duties, which counsel and accountable control owners must assess.
How do we start without boiling the ocean?: Start with one bounded change class: agent runs that modify code. Assign owners for the task, run record, validation receipt, approval and retention link. Pilot the chain on one repository, then ask your internal audit, legal and records owners whether its integrity, access and retention fit the applicable criteria.

Keep reading

ProofEvidence ReportsWhat was intended, what changed, what was validated, what was skipped, what remains uncertain - recorded per run and stored with the code. Structure and a labeled sample.GovernanceAI Coding GovernanceThe controls, workflows, approvals, and evidence a team needs to adopt AI coding tools without losing engineering accountability - and where each building block has limits.All articlesThe whole collection - 58 cited, dated guides on verifying AI-generated code.

Sources

Want to see what your last agent run would have looked like?

Request access