An AI audit trail must let a stranger explain a past decision without asking anyone to remember it. Record the input, the context the system saw, the exact model and prompt versions, every tool call, the raw and final output, the threshold and any human review. Keep it append-only, and treat it as a store of personal data.
The test to design against
Picture a customer disputing a decision a year from now. Since then the model has changed twice, the prompt has been reworded and the search index rebuilt. Could you demonstrate what the system saw, what it did and why it answered as it did?
If any step depends on a colleague's memory, the log is not an audit trail.
Twelve fields
| Field | What to store | Why it matters |
|---|---|---|
| Request ID and time | A unique ID and a timestamp for the request and for each stage | Links the entry to incidents and to other systems |
| Raw input | The submission exactly as received | Settles disputes about what was provided |
| Context | Retrieved passages with document IDs, or computed features with values | A wrong answer often traces to the wrong context |
| Model version | Provider, model name and the provider's own version string | Identifies the artefact that produced the answer |
| Prompt version | An ID that resolves to the exact prompt text | Prompts change more often than models |
| Index or data snapshot | An ID for the retrieval index or feature set in force | The same query returns different passages after a rebuild |
| Settings | Temperature, limits, tool list in force | Needed to attempt a repeat run |
| Tool calls | Each call, its parameters, the result and any retry | Shows the system's actions in sequence |
| Raw output | The output before any post-processing | Separates a model fault from a formatting fault |
| Final result | What the user or downstream system received | Records the outcome |
| Score and threshold | The confidence value and the cut-off applied | A score is meaningless without its cut-off, and cut-offs change |
| Human review | Reviewer, time, decision, and any override with a reason | An override is the most useful record the system produces |
A debug log is a different thing
The two answer opposite questions.
| Debug log | Audit trail | |
|---|---|---|
| Question | What is failing at this moment? | What took place on that date, and for what reason? |
| Time span | Hours to days | Years |
| Retention | Deleted on a rolling basis | One stated period, kept to |
| Shape | Whatever an engineer found useful | One schema, all fields, every entry |
| Edits | Pruned freely | Append-only |
Teams discover the gap late. The complaint lands after the debug logs have rotated away and after the provider has withdrawn the model that gave the answer.
Versioning fails without anyone noticing
A log line that says "model v4" is useless if v4 has been overwritten. Keep the thing the ID points to:
- the model, or the provider's version identifier and a record of when it was retired;
- the prompt wording, word for word;
- the retrieval index, or a pointer to a snapshot of it;
- the settings in force.
A registry of models and prompts is therefore part of the audit design. It gives the log its meaning. Retrieval beyond the demo describes how the retrieval side is built.
What reproducibility can and cannot promise
Best case, you can run the decision again and get the same result. Fixed settings and retained artefacts make that realistic, and it deserves engineering effort.
Sometimes it cannot be done. A provider can withdraw a model version, and some systems give different answers on each run. In that case, keep a full record of events and of the material the system reasoned from, and say plainly what cannot be repeated. Claiming reproducibility and failing a challenge does more damage than an accurate list of what you kept.
The log holds personal data
If the system handles personal data, so does its trail. It carries the same duties as the system itself: access control, retention limits, erasure requests and residency rules.
A common fault is a logging pipeline set up for debugging that collects prompts and inputs in a place the main design would reject, for example a third-party monitoring service hosted in another country. Apply the same data boundary to the log as to the system. DPDP and AI systems covers the duties that follow.
Retention periods that apply
No single rule sets one period for AI logs. These texts set floors that bear on them:
| Source | What it requires | Applies to |
|---|---|---|
| CERT-In Directions, 28 April 2022 | Logs of ICT systems kept securely for a rolling 180 days, within Indian jurisdiction | Entities covered by the Directions |
| DPDP Rules 2025, Rule 6(1)(e) | Logs and personal data kept for one year to detect and investigate unauthorised access, unless another law says otherwise | Data fiduciaries, from mid-May 2027 |
| DPDP Rules 2025, Rule 8(3) | Personal data, traffic data and logs of processing kept for at least one year for the Seventh Schedule purposes | Data fiduciaries, from mid-May 2027 |
| EU AI Act, Article 26 | Deployers of high-risk systems keep the automatically generated logs for a period suited to the purpose, at least six months | Deployers of high-risk systems in the EU |
Sector rules, such as those for lending and insurance, often require decisions to be defensible for longer. Balance them against the DPDP expectation that data is erased once its purpose ends. State one period, tie it to one purpose and apply it consistently.
Article 12 of the same Regulation also requires high-risk systems to allow automatic recording of events over their lifetime. The field list above is a reasonable starting design for that duty.
An illustrative entry
The example below is invented to show the shape. It is not a client record. A lender's document-check agent reads a bank statement and returns a verdict. One entry would hold:
- the request ID and the time the statement arrived;
- the statement file as received, stored by reference;
- the three passages the agent retrieved from the credit policy, with their document IDs and the index snapshot;
- the model identifier, the prompt ID and the settings;
- the two tool calls the agent made, one of which failed and was retried;
- the raw answer and the final verdict sent to the loan system;
- a confidence score just under the review threshold, so the case went to a person;
- the reviewer's name, the time and her decision to override, with the reason she typed.
A year later, anyone can open that entry and see why the case reached a person and why she changed the outcome. No engineer needs to be found.
Who reads the trail
Different people open the log for different reasons, and the design should serve each.
| Reader | Question | Needs |
|---|---|---|
| Compliance officer | Did we follow policy on this case? | Policy passages retrieved, thresholds, reviewer decisions |
| Auditor | Was the control in force and working? | Settings by date, evidence of review, no gaps |
| Engineer | Why did quality change last month? | Version and index changes by date, scores per release |
| Customer-facing staff | What do we tell this customer? | A short, plain reason drawn from the record |
Build one store and give each reader a view of it. Do not build four logs.
Tamper evidence
An audit trail that anyone can edit proves nothing. Write entries to an append-only store, restrict who can delete, and chain each entry to the previous one with a hash so a gap or edit shows. Keep the keys and the hash checks outside the team that runs the application.
Build it first
Adding an audit trail to a live system means working out which version of what was running during a period nobody recorded. Most of the time that is impossible. In regulated sectors the trail decides whether a system can go live at all. The other controls are in AI governance for regulated Indian companies. The review fields are explained in human-in-the-loop design.
Questions to put to a vendor
If a vendor supplies the model or the platform, ask for written answers to these:
- Can we export every field in the table, in bulk, in a stated format?
- How long do you keep model versions after you retire them?
- Where is the log stored, and who can read it?
- Can we set our own retention period and have deletion proved?
- What do you keep from our prompts, and can you turn that off?
Answers that depend on a premium tier belong in the cost comparison.
Questions teams ask
How big does the log get?
Estimate entries per day, multiply by the average size of context and output, then by the retention period. Context is the largest field, so store passage IDs and a snapshot reference, and keep the text in a versioned store.
Can we mask personal data in the log?
Yes, and often should. Mask or tokenise what the audit does not need, and keep the mapping under tighter access.
Does a vendor's dashboard count as an audit trail?
Only if you can export every field above, keep it for your stated period and hold it in an allowed location.
Where Brihat fits
Brihat Infotech's AI agents and automation service delivers a full action audit trail, and its MLOps work covers prompt versioning and a model and prompt registry. Start a conversation.