Logs and traces
Detailed technical output: requests, timings, errors, the internal steps of a model call.
- Sampled, rotated, often deleted in days
- Editable by whoever runs the system
- Structure changes with the code
- Read when something breaks
Guide · AI governance
The AI audit trail: what to record for each AI step, how to seal it, and how long to keep it.
Who or what acted, on whose behalf, with which model and inputs, what it did, who approved it — written once, sealed, and kept as long as the law asks.
Logs help engineers fix systems. An audit trail lets someone outside the team reconstruct a decision months later and trust that the record has not been changed. This guide covers what an AI audit trail must capture for models and agents, how tamper evidence works, how retention rules combine, and what the EU AI Act, US record-keeping rules and NIST controls expect.
Updated · 7 sources
One audit recorda single agent step, written once and sealed
Actorthe person, or the agent and whom it acted for
Eventtool call, decision, value edit, approval, sign-off
Timea clock time with its offset from UTC
Targetwhich record, document or system changed
Model and versionand the version of the agent’s instructions
Inputs and sourceswhat it was given and what it retrieved
Outcomethe value before and after; success or refusal
Seala hash over the entry and the one before it
What is an AI audit trail?
An AI audit trail is a chronological, append-only record of what AI systems and the people around them did: each model or agent action, its inputs and sources, the model and configuration version, the outcome, and every human review, edit or approval — with who, what, when and on whose behalf. Unlike an application log, it is kept as evidence: complete, protected from change, tamper-evident and retained for as long as the applicable rules require.
Definitions
An AI audit trail compared with logs and traces.
Most AI stacks already produce logs and traces. They answer an engineer’s question — why did this fail? An audit trail answers an auditor’s question — who did what, and can I rely on this record? The same event can feed both, but the requirements differ.
Audit trail
The evidential record of actions and decisions: who, what, when, to which record, with what result.
- Complete — every recorded action
- Append-only and tamper-evident
- Stable fields that answer fixed questions
- Kept for the retention the law sets
Why did the run fail or slow down?Question it answersWho decided, on what basis, and was it allowed?
Best effortCompletenessEvery recorded action, or a known gap
Can be rewritten or purgedChangeCorrections are new entries; the original stays
Engineering and operationsReadersRisk, compliance, auditors, regulators
The layers of evidence around an AI system
01
Governance evidenceapprovals to release, evaluation results, configuration versions
before use02
Decision recordoutputs, human reviews, edits, sign-offs on business records
audit trail03
Run traceeach agent step: plan, tool calls, results, retrieved sources
audit trail04
Access recordwho signed in, which data they read or exported
audit trail05
Infrastructure logsrequests, errors and timings for operations
logsContent
What an AI audit trail should record for each step.
NIST SP 800-53 sets the classic content of an audit record in control AU-3: what happened, when, where, from what source, with what outcome, and who was involved. For AI, each of those needs a little more precision — and three fields that classic logs never had.
| AU-3 element | Classic system log | AI model or agent step |
|---|---|---|
| Type of event | Sign-in, file read, setting changed | Model call, tool call, decision, value edit, approval |
| When | Time stamp | Time stamp in UTC or with its offset; step order within the run |
| Where | Host or application | Project, workflow, agent and run identifier |
| Source | Process or address | The agent, the person it acted for, and what triggered it |
| Outcome | Success or failure | The output or change made — before and after values — or the refusal |
| Identity | User account | The person who reviewed, approved or overrode, separate from the agent |
Three fields an AI audit trail adds
- Model and configuration versionwhich model, which version of the instructions, tools and sources — so a decision can be tied to what was approved
- Inputs and evidencethe input, the documents retrieved and the source of each extracted value, or a fingerprint of them where content must not be copied
- The human decisionwho accepted, edited, rejected or signed the output, and the meaning of the signature
Integrity
Tamper evidence: how a hash chain makes a quiet edit visible.
NIST asks that audit information be protected from unauthorized modification and deletion, and offers cryptographic integrity as an enhancement. A hash chain is the common way to do it: each entry carries a fingerprint of itself and of the entry before, so changing one breaks every link after it.
- Write once
Entries are only ever appended. The store refuses updates and deletes.
- Link
Each new entry stores the hash of the entry before it.
- Seal
A cryptographic hash, such as SHA-256, is computed over the entry’s content and that link.
- Keep the head
Copy the latest seal somewhere the system’s operators cannot reach — a ticket, an inspection file.
- Verify
Recompute every seal from the start; the first mismatch names the entry that was changed.
EditableIndependently verifiable
12345
- Plain tableAnyone with write access can change history without trace.
- Access-controlled logFewer people can change it; nothing shows if they do.
- Append-only storeWrite-once storage or database rules refuse edits — the non-rewriteable route in SEC rules.
- Hash-chained trailAny change to a past entry breaks the chain at that point.
- Chain with an outside anchorA seal kept elsewhere proves the whole history up to it — the idea behind public append-only logs such as Certificate Transparency.
Evident, then prevented. A hash chain shows that a record changed; it does not stop the change. Pair it with append-only storage, separate duties for whoever runs the store, and a routine verify — then a change is both hard to make and impossible to hide.
How long to keep it
How long to keep an AI audit trail.
There is no single number. The AI law sets a floor, the record-keeping law of your sector usually sets a longer period, and privacy law pushes back against keeping personal data longer than needed. The longest applicable duty for each record type wins, and a legal hold suspends deletion.
Which rule sets the retention for an AI audit record?
A sector record-keeping law appliesKeep the audit trail at least as long as the business record it describes — banking, securities and life-sciences rules usually run for years.
Only the EU AI Act appliesFor high-risk systems, keep logs for a period appropriate to the purpose, and no less than six months.
Entries contain personal dataKeep the evidence, minimise the content: store references or fingerprints of prompts where you can, and restrict who may read them.
A dispute or investigation is openPlace a legal hold; deletion waits until it is released, and the release itself is recorded.
What is asked
What regulators expect from an AI audit trail.
The rules below were written for different industries and eras, but they converge on the same four properties: automatic, complete, attributable and unalterable without trace.
Requirements that shape an AI audit trail
- EU AI Act, Art. 12High-risk AI systems must technically allow automatic recording of events over their lifetime, so risks, substantial modifications and operation can be traced. High-risk duties apply from 2 December 2027 for Annex III uses.
- EU AI Act, Art. 12(3)For remote biometric identification, a set minimum: the period of each use, the reference database, the input that matched, and the people who verified the result.
- 21 CFR 11.10(e)Secure, computer-generated, time-stamped audit trails of entries and actions that create, modify or delete electronic records; changes must not obscure what was recorded before.
- SEC Rule 17a-4(f)Electronic records kept with a complete time-stamped audit trail of every modification and deletion, the identity of who made it, and enough to re-create the original — or in a non-rewriteable, non-erasable format.
- NIST SP 800-53, AU-9 and AU-10Protect audit information from unauthorized access, modification and deletion; use cryptography for integrity; provide evidence an individual or a process acting for them performed an action.
Agents raise the bar on attribution. When an agent acts for a person, the record has to show both: the agent that took the step and the person on whose authority it ran. Without that, non-repudiation in the NIST sense — evidence of who performed an action — fails for every automated step.
On Botminds
How Botminds keeps an AI audit trail you can verify.
The Botminds audit trail is append-only at the database, sealed entry by entry with a hash chain, and checked on demand by a verify call that names the first entry that does not match — for every recorded change by every person and every agent.
integrity
Sealed on write
Each entry stores the previous entry’s hash and a SHA-256 seal over its own content, set by the database itself.
proof
Your own seal
Keep the chain’s latest seal in an inspection file or a ticket; a later verify proves every entry before it.
agents
Every agent run
Each step of each run is streamed, kept and replayable.
review
Three feeds
Project, workspace and platform feeds, filtered by who, what and when, exported as CSV or JSON.
timeline
A document’s whole story
One timeline joins stage moves, value edits, agent runs, re-extraction and indexing.
evidence
Signatures and holds
E-signatures bound to exactly what was signed; preservation holds make every delete path refuse until release.
See the design in AI governance on Botminds, and the Academy lessons on audit and compliance and observability.
Questions people ask
AI audit trail: common questions.
The technology behind itAI governanceAudit, signatures, access and proof→What is an AI audit trail?
An AI audit trail is an append-only, tamper-evident record of what AI systems and the people around them did — each model or agent action, its inputs and sources, the model and configuration version, the outcome, and every human review or approval — kept as evidence for the period the rules require.
What is the difference between an audit trail and an audit log?
The terms overlap. In practice, logs are technical output kept for troubleshooting, often sampled and short-lived; an audit trail is the evidential record of actions and decisions, complete, protected from change and kept for a set retention period.
Does the EU AI Act require an audit trail?
For high-risk AI systems, yes in substance: Article 12 requires automatic recording of events over the system’s lifetime for traceability, and Articles 19 and 26(6) require providers and deployers to keep the logs under their control for at least six months, unless other law sets otherwise.
How long should AI logs be kept?
The longest applicable rule for each record type: the EU AI Act sets a six-month floor for high-risk systems, sector rules such as SEC Rule 17a-4 run to years, and FDA Part 11 ties audit trails to the life of the records. Privacy law argues for minimising personal data in them.
What makes an audit trail tamper-evident?
Each entry carries a cryptographic hash over its content and the previous entry’s hash, so changing any entry breaks the chain from that point. Keeping the latest hash outside the system lets anyone verify the whole history up to it.
Should prompts and AI outputs be stored in the audit trail?
Enough to reconstruct the decision should be. Where prompts carry personal or confidential data, store references or fingerprints, restrict who may read the content, and set its retention with your privacy team.
How do you audit an AI agent’s decisions?
Reconstruct the run: the request and who made it, the agent’s plan, each tool call and its result, the sources it read, what it changed, and who approved. Then check each step against the agent’s granted tools and the approvals your policy required.
How does Botminds keep an AI audit trail?
Every recorded change by people and agents is appended to a hash-chained trail the database protects from edits. A verify call names the first entry that does not match, every agent run is kept and replayable, and feeds export as CSV or JSON.
Sources
- Regulation (EU) 2024/1689 (EU AI Act), Articles 12, 19 and 26 — EUR-Lexeur-lex.europa.eu
- European Commission: AI Act application datesdigital-strategy.ec.europa.eu
- NIST SP 800-53 Rev. 5: Security and Privacy Controls (AU family)csrc.nist.gov
- 21 CFR 11.10: Controls for closed systems (FDA Part 11)law.cornell.edu
- 17 CFR 240.17a-4: Records to be preserved by broker-dealers (SEC)law.cornell.edu
- RFC 6962: Certificate Transparency (append-only Merkle-tree logs)rfc-editor.org
- Regulation (EU) 2016/679 (GDPR), Article 5 storage limitationeur-lex.europa.eu
Read next
EU AI Act for AI agentsRisk classes, provider and deployer duties, and the dates that apply→AI governance frameworkRoles, inventory, risk tiers, controls and monitoring — mapped to NIST and ISO→SR 11-7 and generative AIModel risk guidance, its 2026 replacement, and how banks govern LLMs and agents→All guidesEvery explainer, by topic→
See it on
your own work.
Bring one process and its documents. We’ll show you the agents, the controls and the record, running on your data.