On this page 10 sections
An audit trail for an AI system records, per request, the exact input, the retrieved sources, the model and prompt versions, the output, the decision or action taken, and any human override, tied together by one correlation ID and held under a stated retention period. The test of a good trail is simple: can you reconstruct why the system said what it said to a specific person on a specific day, six months later, without the engineer who built it.
Most systems we are asked to look at can answer “what did the model output” and nothing else. That is a log, not a trail.
Key takeaways
- Log the versions, not just the content. An output without the model version, prompt hash and retrieved sources cannot be reproduced or explained.
- Logs of decisions about people are personal data. They carry a retention limit, an access right and a deletion obligation, and the trail has to be designed to honour all three.
- European courts have said what “meaningful information about the logic” means: the procedure and principles actually applied to this person’s data. A trail that cannot produce that is not defensible.
- The EU AI Act sets a six-month minimum retention for high-risk system logs. Those obligations were deferred to December 2027, but the design has to exist before the deadline, not on it.
- Human overrides are the most valuable records in the trail and the ones least often captured.
Who this applies to
Anyone running a system that answers, classifies, routes, scores or decides on behalf of the company: a support agent, a document pipeline, a lead scorer, a triage system, a recruiting filter, an internal assistant with access to personal records.
The obligations scale with what the system does. A system that summarises public documents needs the engineering half of this article, so it can be debugged. A system that affects people, their access to a service, their money, their job, needs all of it, because someone will eventually ask why, and the person asking may be a regulator.
This is not legal advice. The legal sections below name the rules as they stand in September 2026 and say when to involve counsel.
Why the usual log is not enough
The standard application log records that a request came in, that a model was called, that a response went out, and how long it took. It is built for uptime, and it answers uptime questions.
The questions an AI system gets asked are different.
- “Why did the bot tell this customer the refund window was 60 days when the policy says 30?”
- “This applicant says they were rejected by a machine. Were they, and on what basis?”
- “The output changed on Tuesday and nobody deployed anything. What happened?”
- “The regulator wants to know which of this person’s data was used and how.”
Each of those needs a record that the uptime log does not hold: the prompt as it was at the time, the documents the model actually saw, the model version the vendor served, the rules that ran before and after the model, and whether a person touched the result. The mechanics of the “changed on Tuesday” case are covered in the provider changed the model, what broke. The trail is what lets you answer it in ten minutes rather than a week.
What to record, stage by stage
| Stage | Record | Why it is needed |
|---|---|---|
| Request | Correlation ID, timestamp, channel, the input as received, the authenticated identity if any | Reconstruct what the person actually asked |
| Pre-processing | Redactions applied, classification, rules that fired before the model | Prove a topic rule or a filter ran |
| Retrieval | IDs and versions of every passage retrieved, their scores, the permission filter applied | Show which sources the answer was drawn from, and that the person was allowed to see them |
| Model call | Provider, model identifier and version, system prompt hash, prompt template version, parameters, token counts | Reproduce the call; explain a change in behaviour |
| Output | The raw output, and the output after post-processing | Separate what the model said from what the system showed |
| Decision or action | The rule or threshold applied, the resulting decision, any external action taken and its result | Show the logic that turned an output into a consequence |
| Human involvement | Who reviewed, what they saw, what they changed, and when | Evidence of meaningful oversight; the most valuable record in the trail |
| Feedback | Corrections, complaints, later reversals, linked by the same ID | Close the loop; feed the evaluation set |
Three design rules make this work.
One ID through everything. Every stage writes the same correlation ID. Without it, reconstruction is a join across five systems by timestamp, and timestamps drift.
Hash the large, store the reference. The system prompt may be four thousand tokens. Store its hash and version per request, and store the full text once per version. The same applies to retrieved documents: store the ID and version, keep the document store versioned, and the content is recoverable without copying it a million times.
Record versions the vendor does not tell you about. Provider APIs return a model identifier, and behind an alias that identifier can change. Log the exact identifier from the response, not the alias you requested, so the trail shows the day the vendor moved you.
The legal floor in 2026
The trail has to satisfy three bodies of rules, and they pull in different directions. The engineering answer above is the same regardless; the retention and access rules differ.
Data protection: the log is personal data
Where a system processes data about an identifiable person, the trail is itself personal data. Under the GDPR that brings the accountability principle in Article 5(2), which means being able to demonstrate compliance, not merely be compliant, and it brings the access right in Article 15, which means the person can ask for the record.
For decisions taken solely by automated means, Articles 13, 14 and 15 require “meaningful information about the logic involved” and the significance and envisaged consequences. The Court of Justice of the EU settled what that phrase means on 27 February 2025 in Dun & Bradstreet Austria (C-203/22): the controller must explain the procedure and principles actually applied, in a way that lets the person understand which of their personal data was used and how. Handing over the algorithm is not enough, and neither is a generic description. The court also held that a trade secret does not justify a blanket refusal; the controller must give the material to the supervisory authority or court, which balances the interests.
A trail that records only the output cannot meet that standard. A trail that records the inputs, the retrieved data, the rules and the thresholds can. The companion piece, automated decisions and the right to human review, covers when Article 22 applies and how the UK rewrote it in 2026.
The same law that requires the record also limits it. Data minimisation and storage limitation mean the trail holds what is needed for the stated purpose, for a stated period, and no longer. That is the tension: the engineering instinct is to keep everything forever, and the legal position is that you may not. The resolution is a retention schedule per record type, written down.
The EU AI Act: logging as a product requirement
For high-risk systems, those listed in Annex III, which includes credit scoring, recruitment and access to essential services, Article 12 requires the provider to build in automatic logging over the system’s lifetime, and Article 26(6) requires the deployer to keep the logs the system generates for at least six months, or longer where other law requires. Article 86 gives a person affected by a high-risk system’s decision the right to a clear and meaningful explanation of the system’s role in it.
The dates moved this summer. The Digital Omnibus regulation, Regulation (EU) 2026/1744, entered into force on 27 July 2026 and deferred the high-risk obligations for Annex III systems from 2 August 2026 to 2 December 2027, and for AI embedded in products covered by EU product safety law to 2 August 2028. The transparency obligations in Article 50, including telling people they are dealing with an AI system, were not deferred and have applied since 2 August 2026.
A deferral is not a cancellation. A system being built now that will be in service in December 2027 needs the logging designed in now, because retrofitting per-request version capture into a system that never had it is a rewrite of the request path.
The United States: sector rules and a moving state picture
There is no federal equivalent of Article 22. Two things are worth knowing.
New York City’s Local Law 144 has required, since July 2023, an independent bias audit of automated tools used in hiring and promotion decisions, with the audit summary published and candidates notified. The audit needs the trail: selection rates by category, which means the decision record has to carry the outcome and the demographic data the audit method requires, handled under its own restrictions.
Colorado repealed its 2024 AI Act before it took effect and replaced it in May 2026 with Senate Bill 26-189, a disclosure-and-rights framework for automated decision-making technology that takes effect on 1 January 2027. The detail is still being written into rules. The direction across states is the same: disclose, keep a record, let the person contest.
Retention, in one table
| Record | Keep for | Reason |
|---|---|---|
| Full request and output, decisions about people | Six months minimum where the AI Act applies; otherwise the shortest period that covers your complaint and appeal window | Article 26(6); accountability |
| Model, prompt and source versions | For as long as any decision made with them is still contestable | Reproducibility |
| Human override records | Same as the decision they modified | Evidence of oversight |
| Requests with no personal data, debugging only | Thirty to ninety days | Minimisation |
| Evaluation sets derived from the trail | Indefinitely, once anonymised or built from consented cases | They are the asset |
Write the schedule down, put the deletion job under the same monitoring as the rest of the system, and test that deletion actually deletes. A trail that claims a six-month retention and holds three years of records is worse in front of a regulator than one that honestly says it keeps everything, because it shows a control that does not work.
What we insist on, and where it costs us
We will not ship a system that affects people without the override record. The pushback is always the same: the reviewers are busy, capturing what they saw and what they changed adds a step, and the product owner wants the queue cleared. We hold the line because the override record is the only evidence that human involvement was real rather than a rubber stamp, and that distinction is the whole legal question when a decision is challenged. A review queue where people approve 400 items an hour is not oversight, and the trail will show it. Better to know that from your own data than from a complaint.
We also refuse the “log everything, decide later” design that most engineering teams propose, because “later” never comes and the retention exposure grows monthly. Every record type gets a period on the day it is created.
The design choice that costs us the most time in reviews is logging the vendor’s returned model identifier rather than the requested alias. It looks pedantic until the day the output changes and nobody deployed anything. Then it is the difference between a ten-minute answer and a week of guessing. See prompt regression testing for what to run when that day comes.
When this is not worth it
When the system makes no decision about anyone. A model that summarises public documents for internal use needs versions logged so it can be debugged, and nothing else in this article. Do not build a personal-data retention regime for a system that holds no personal data.
Below meaningful volume. A system that handles thirty requests a week can be audited by reading them. Build the correlation ID and the version capture, skip the retrieval-score storage and the automated retention tooling until the volume justifies it.
When the review is theatre. If the plan is for a person to approve every output at a rate that makes reading impossible, the override record will prove that oversight was nominal. Either design real review, with sampling and time, or accept that the decision is automated and meet the rules for that. Recording fake oversight is worse than recording none.
When the vendor holds the trail. Some hosted platforms keep the log and expose it only through their interface. That can be acceptable for a low-stakes system, but check that you can export it, that the retention is yours to set, and that it survives cancelling the contract. If it does not, the trail is not yours.
Frequently asked questions
Do we have to log the full prompt on every request?
No. Log the template version and a hash of the rendered prompt, plus the variables that filled it. The full text is recoverable from the template store. The exception is user input, which is recorded as received, because it cannot be reconstructed from anything else.
The logs contain customer personal data. Can we still use them to improve the system?
Yes, within limits. Using the trail to build an evaluation set is a purpose you should name in your privacy notice, and the set should be minimised and anonymised where it can be. Building an eval set from real tickets covers the method. Do not use consumer-tier AI tools to do the analysis; that puts the data into a training pipeline.
What counts as a human override?
Any change a person makes to what the system would have done: editing an answer before it is sent, reversing a decision, reclassifying a document, or approving an action that the rules had held. Record what they saw before and after, not just that they touched it.
Should the trail be tamper-evident?
For a system whose records may be challenged, yes, and it is cheap: append-only storage, or a hash chain over the records, so that a deleted or altered entry is detectable. It is not needed for a debugging log.
How do we answer an access request from the trail?
Filter by the person’s identity, pull each decision record with its inputs, sources, rules and outcome, and produce the explanation the Dun & Bradstreet judgment describes: which of their data was used and how the result was reached. If the trail is designed as above, that is a query. If it is not, it is a project, and the statutory deadline is one month.
Does any of this apply if we only use a hosted chatbot from a vendor?
Yes. You are the deployer. The vendor may generate the log, but the duty to keep it, to answer the person and to demonstrate oversight is yours. Check what the vendor exposes before you need it.
Next step
If a complaint or an access request would send your team into the raw logs by hand, the AI evaluation and QA engagement starts by reconstructing a sample of real decisions from what you already record, which shows exactly which of the eight stages are missing.
Related: Automated decisions and the right to human review · Your provider changed the model - what broke · RAG permissions: stopping the assistant leaking documents · What belongs in an AI acceptable use policy