AI Audit Trail Checklist: What to Log When AI Takes Action

An AI audit trail is a record that lets someone who was not in the room reconstruct an AI-assisted action from start to finish: who asked, what the AI saw and proposed, which rule it was checked against, who approved it, and what changed as a result. Ordinary application logs rarely answer all five. This checklist sets out the fields we think every consequential AI action should leave behind, and how they line up with the logging rules regulated teams in India and the EU already face.

It is written for compliance leads and engineering leads who have to agree on the same record.

Why aren’t ordinary logs enough?

Application logs are built for debugging. They tell an engineer that a request failed at 14:02. An auditor needs something different: evidence of authority. The question we described in Your AI Copilot Can’t Save You From an Audit is “who was in charge when the AI acted?”, and a stack trace cannot answer it.

AI adds two complications. The same input can produce different outputs, so you need to keep what the model actually said, not just what it was asked. And the action is often split across systems: a model proposes, a person approves, a separate service executes. If those three pieces live in three logs with no shared identifier, nobody can join them up later.

What do the rules already require?

Several frameworks already expect logs, even if none of them hands you a schema.

• EU AI Act. Article 12 requires high-risk AI systems to “technically allow for the automatic recording of events” over their lifetime. For certain biometric systems it spells out minimum content, including the period of each use, the input data that led to a match, and the identity of the people who verified the results (Article 12). Providers must keep those logs for at least six months (Article 19), and so must deployers, for the logs under their control (Article 26). Following the Digital Omnibus on AI, most high-risk obligations now apply from 2 December 2027 for stand-alone systems (Hunton, 2026).
• India, CERT-In directions (2022). Covered entities must keep logs of their ICT systems “securely in India for a rolling period of 180 days”, report specified cyber incidents within six hours, and synchronise clocks with the National Informatics Centre or National Physical Laboratory time servers (Linklaters, 2022).
• India, DPDP Rules 2025. Data fiduciaries must retain personal data, associated traffic data and processing logs for at least one year from the date of processing, for the purposes listed in the Rules (AMS Shardul, 2025).
• RBI FREE-AI report (2025). The committee recommended AI incident reporting and audit processes for regulated entities, along with AI inventories and board-approved AI policies (Khaitan & Co, 2025). The recommendations are not binding on their own, but they show where supervisors are looking.

Check which of these apply to you with your counsel. Our AI governance guide for regulated industries covers them in more depth.

The checklist: what should each AI action record?

We group the fields into six stages. One shared action ID should run through all of them.

1. Identity and context

• [ ] Action ID, unique, carried through every system the action touches.
• [ ] Requester: the person or service account that started it, with their role at the time.
• [ ] On whose behalf, if an agent acts for a user or a team.
• [ ] Timestamp from a synchronised clock, in an international format, with time zone.
• [ ] Application and version: which product, environment and release.

The OWASP Logging Cheat Sheet frames this as being able to answer “when, where, who and what” for every event (OWASP).

2. The model call

• [ ] Model provider, model name and version.
• [ ] Prompt or template version, and a reference to the exact input (or a hash of it, if the input holds personal data).
• [ ] Data sources retrieved: which documents or records the AI was given.
• [ ] The model’s output, as returned, before any post-processing.
• [ ] The proposed action, in structured form: “update record X, field Y, from A to B”.

3. The policy check

• [ ] Policy and rule version evaluated.
• [ ] Result: allowed, denied, or needs approval.
• [ ] Reason: which rule triggered.
• [ ] What happened on error. If the check failed or timed out, the record should show that the action stopped. That fail-closed behaviour is part of what we mean by non-bypassable governance.

4. Human approval

• [ ] Named approver, not a shared account or “admin”.
• [ ] What they were shown when they approved: the proposal, the evidence, the policy result.
• [ ] Decision and time: approved, rejected, edited, or timed out (a timeout should count as a rejection).
• [ ] Edits the approver made to the AI’s proposal.

The EU AI Act asks deployers to assign oversight to people “who have the necessary competence, training and authority” (Article 26). The approval record is how you show you did.

5. Execution and outcome

• [ ] What actually ran, which may differ from what was proposed.
• [ ] Before and after state of anything changed, or a reference to it.
• [ ] Result: success, partial, failed, rolled back.
• [ ] Downstream effects: messages sent, payments triggered, records shared.

6. Integrity and access

• [ ] Tamper evidence: each record linked to the previous one, for example in a hash chain, so edits or deletions are detectable.
• [ ] Write-once storage, or a copy moved to read-only storage quickly.
• [ ] Access log for the audit trail itself: who read it and when.
• [ ] Retention period set to the longest rule that applies to you.

OWASP recommends tamper detection, copying logs to read-only media “as soon as possible”, and monitoring both access to logs and signs that logging has stopped (OWASP).

What should you not log?

An audit trail that leaks data creates a new risk. OWASP lists data that should not be written directly to logs, including session identifiers, access tokens, passwords, encryption keys, database connection strings, sensitive personal data and payment card data. Where you need them, mask, hash or encrypt them first (OWASP).

For AI specifically, decide up front whether full prompts and outputs go in the trail or in a separate, more tightly controlled store referenced by ID. Prompts often contain whatever personal data the user typed. The DPDP retention duty above applies to processing logs too, so the trail is itself personal data to be governed.

How do you test an audit trail?

Pick a real AI-assisted action from last week and ask someone outside the team to reconstruct it using only the trail. They should be able to answer, in writing and within an hour:

1. Who started it, and with what authority?
2. What did the AI see, and what did it propose?
3. Which rule applied, and what did it decide?
4. Who approved it, and what were they shown?
5. What changed, and can it be undone?

Any question they cannot answer is a missing field. Repeat the exercise each quarter, and after any change to models, policies or approval flows.

How we approach it

Every QUAICU delivery writes to an append-only, hash-chained ledger with a named approver for consequential actions. The full model is on our trust page, and our page for regulated teams explains how it fits sectors that answer to a regulator. If you want to test your current trail against this checklist, talk to us.

Sources

• EU AI Act, Article 12: Record-keeping
• EU AI Act, Article 19: Automatically generated logs
• EU AI Act, Article 26: Obligations of deployers
• Hunton Andrews Kurth, EU Digital Omnibus on AI enters into force (2026)
• Linklaters, India’s CERT-In cyber security directions (2022)
• AMS Shardul, Enforcement of the DPDP Act and notification of the DPDP Rules
• Khaitan & Co, ERGO on the RBI FREE-AI framework (Aug 2025)
• OWASP Logging Cheat Sheet