/17AI Logs, Records & Evidence
A practical guide to the AI Act’s high-risk logging and retention concepts, and the difference between a normal app log and useful evidence.
Intermediate
12 min
Open +
AI Logs, Records & Evidence
A practical guide to the AI Act’s high-risk logging and retention concepts, and the difference between a normal app log and useful evidence.
Intermediate
12 min
For high-risk AI, the Act does not treat traceability as a nice dashboard feature. Article 12 requires technical logging capability. Articles 19 and 26 address keeping automatically generated logs when they are under the provider or deployer’s control. The useful design question is simple: can you reconstruct what happened later?
Leave knowing / Design an evidence trail that can answer real questions
The law in normal words
Logging is about traceability, not hoarding everything.
Article 12 says high-risk AI systems must technically allow automatic recording of events over the lifetime of the system, with logging that supports an appropriate level of traceability.
Article 19 says providers of high-risk AI systems keep automatically generated logs that are under their control for an appropriate period of at least six months, unless another applicable law says otherwise. Article 26 places a similar log-retention duty on deployers for logs under their control.
That does not mean every organisation should dump prompts, personal data, secrets, model outputs and internal reasoning into one giant log forever. Retention, privacy, security and purpose still matter.
A useful record answers a future question without creating a new data leak today.
What useful evidence answers
Think in questions, not log lines.
What happened?
Which output, action, event, or transformation is being discussed?
When?
When did the relevant event occur, and what ordering or sequence can be established?
Which system?
Which AI system, workflow, environment, or version was involved?
Can we verify it?
Can the record be checked later without relying on the same model to explain or certify itself?
Log vs evidence
A log line and an evidence record are not the same thing.
| Normal application logging | Evidence-oriented record |
|---|---|
| Optimised for debugging and operations | Optimised for later verification and review |
| May be mutable or rotated quickly | Should make later tampering or ambiguity easier to detect |
| Often contains verbose payloads | Can use bounded metadata and cryptographic commitments instead of copying sensitive content |
| Usually trusted because your own system wrote it | Should be designed for a reviewer who may not simply trust your system |
| Answers “why is the app broken?” | Answers “what can we prove happened?” |
Evidence design
A useful minimum record.
A stable system or workflow identifier.
A timestamp or trustworthy event-ordering mechanism.
A bounded event type or capture point.
A cryptographic commitment to the relevant content or artifact where appropriate.
An idempotency or stable request identifier so retries do not invent duplicate history.
A clear visibility or access scope.
A retention rule that respects the actual legal and privacy context.
A verification path that does not require a model to declare itself correct.
Official sources
We simplify the map here. For a real legal decision, use the law, current guidance and qualified counsel.
Where Paper Trail fits
Available now / Not a compliance certificate
If the question is “what happened?”, keep the receipt.
Paper Trail is being built to keep bounded runtime evidence around supported AI-system activity so a team can inspect what happened later. It does not decide your AI Act role, classify your system, or certify compliance.
Paper Trail is still a private preview. Only capabilities that are actually available are presented as available.
Notes / Subscribe
Get the next note.
No schedule. No content calendar. A note goes out only when there is something worth understanding.