Ask what an AI agent should log and almost every answer you find was written by a security architect. The lists are competent and they are all the same list: identity, action, timestamp, source address, token, result. That is what a SIEM needs to detect an intrusion. It is a poor match for what a regulator will ask you to produce, and the overlap is smaller than most teams assume.
Six frameworks currently say something about what records an AI system has to keep: the EU AI Act, India's DPDP Act and Rules, DIFC Regulation 10, Singapore's Model AI Governance Framework for Agentic AI, the NIST AI Risk Management Framework, and ISO/IEC 42001. None of them publishes a schema. Each demands something specific of a record, sometimes by naming a field, more often by imposing a duty that cannot be discharged without one. What follows takes each in turn, extracts what it needs from a single log entry, and assembles the union into one field list with the citation behind every field.
Three attributions circulate widely and are wrong. Article 12 of the EU AI Act sets no retention period; it is a design duty on the provider, and the six-month floor comes from Articles 19(1) and 26(6). The four fields itemised in Article 12(3) apply only to remote biometric identification systems, not to high-risk systems generally. And India's one-year log retention is described almost everywhere as a single duty in a single rule, when the DPDP Rules 2025 contain two of them, in different rules, for different purposes, with different shapes.
What does the EU AI Act require an AI agent's audit trail to contain?
Article 12 requires high-risk AI systems to record events automatically across their lifetime, at a level of traceability appropriate to the intended purpose. It names four specific fields, but only for remote biometric identification. Retention of at least six months comes from Articles 19(1) and 26(6).
The Act splits the obligation in a way that matters if you are both building and running an agent. Article 12 is a design requirement on the provider: the system must technically allow automatic recording of events. Article 19(1) puts retention on the provider for logs under its control. Article 26(6) puts an independent retention duty on the deployer for the logs under theirs. A team that ships an agent to enterprise customers carries the first and third in different deployments, and the second for its own hosted instances.
For most high-risk systems the Act declines to name fields. Article 12(2) instead sets a functional test in three parts: the logs must enable identification of situations where the system may present a risk under Article 79(1) or undergo substantial modification, must facilitate post-market monitoring under Article 72, and must support the deployer's monitoring of operation under Article 26(5). That is a reconstruction standard. If a regulator asks why the agent did what it did in a given run, and your logs cannot answer, you have not met Article 12 regardless of how many events you captured.
Article 12(3) is the only place the Act itemises. For systems under Annex III point 1(a), the logging capability must at minimum record the period of each use with start and end date and time, the reference database checked against, the input data that produced a match, and the identification of the natural persons involved in verifying the result under Article 14(5). Presenting these four as the universal AI Act field list is a mistake, and a common one. They are the right starting point for everything else, because they are the legislature's own worked example of what traceability appropriate to purpose looks like, but they bind only that category.
The Annex III timeline moved. Regulation (EU) 2026/1744 deferred those high-risk obligations to 2 December 2027, with Annex I to 2 August 2028. The deadline picture for agents is more mixed than the deferral headlines suggest, and the content of the logging duty did not change when the date did.
What must an Indian deployer log under the DPDP framework?
Section 8(5) of the DPDP Act 2023 requires a Data Fiduciary to protect personal data with reasonable security safeguards. Rule 6(1) of the DPDP Rules 2025 turns that into a baseline that includes logging, and Rule 6(1)(e) fixes retention of logs and the associated personal data at one year.
The purpose clause matters more than the number. Rule 6(1)(c) requires visibility over access to personal data through logs, monitoring and review, specifically so that unauthorised access can be detected, investigated and remediated. Rule 6(1)(e) then requires the logs and the personal data they relate to be kept for a year for the same purposes. Read together, they set a standard your log has to meet rather than a period it has to survive: an entry that records that something happened, without recording enough to investigate it, satisfies neither.
The second one-year duty sits in Rule 8(3), and the two are routinely collapsed into one. Rule 8 governs erasure, but its third sub-rule cuts across that: without prejudice to the erasure obligations above it, a Data Fiduciary must retain the personal data, associated traffic data and other logs of a processing operation for a minimum of one year from the date of processing, for the purposes specified in the Seventh Schedule, after which it must erase them unless another law requires longer.
The two are not interchangeable. Rule 6(1)(e) exists so that unauthorised access can be detected and investigated, and it is a floor with no ceiling. Rule 8(3) exists so that the data is available for lawful government requests, and it is a floor and a ceiling together. The forty-eight hours' notice before erasure that gets attached to both is neither: it is Rule 8(2).
For an agent, the consequence is that a single retention setting will not satisfy the Rules. An entry held indefinitely on a Rule 6 rationale can breach Rule 8(3) at the same time, because 8(3) requires erasure once its window closes. And the Rule 8(2) notice generates two logged events rather than one. The erasure is an event. The notice that preceded it, and the timestamp proving the interval, is a second event, and it is the one teams forget to record.
The rest of the regime pulls in the same direction. Rule 7 requires breach intimation on aggressive timelines. Rule 14 requires a working grievance mechanism, which for an agent means a person can contest an outcome and reach someone. Rule 15 conditions cross-border transfer. Rules 3 and 5 to 16 commence on 13 May 2027 under Rule 1(4) of the gazette, G.S.R. 846(E), so this is a design window rather than a live exposure, which is the more useful way to read it. The fuller case that DPDP is conduct regulation for agents, not only a privacy statute, sits alongside this one.
What evidence does DIFC Regulation 10 require an autonomous system to produce?
Regulation 10.2.2 requires a Deployer or Operator to produce, on request, evidence of the system's compliance with applicable audit and certification requirements, evidence of the algorithms that cause the system to seek human intervention, and a register covering use cases, recipients, lawful bases and transfer safeguards.
Regulation 10 is the most demanding of the six on this point, and it is demanding in an unusual way. The others ask you to keep records. Regulation 10 asks you to produce evidence, on request, to affected parties and to the Commissioner. Those are different engineering problems. Records can sit in cold storage; evidence has to be retrievable, intelligible to a non-specialist, and defensible when someone disputes it.
Three of the evidence duties are about the same mechanism seen from three angles. Regulation 10.2.2(d) requires evidence of the algorithm that makes the system seek human intervention where processing may have an unfair or discriminatory impact on a Data Subject, together with a risk and impact assessment. Sub-paragraph (e) requires the equivalent where personal data must be accessed by or for competent government authorities. Sub-paragraph (f) requires it again where processing may result in non-compliance with Regulation 9. A single well-designed escalation event, recorded with its trigger, satisfies all three. Three separately bolted-on approval flows satisfy none of them cleanly.
Regulation 10.2.2(g) is the register, and it is closer to a schema than anything else in the six. It asks for use cases and the necessity and proportionality of the processing, how Data Subjects can access information held in the system under Articles 32 to 40 of the DIFC Data Protection Law, whether the system is used solely to make automated decisions, which third parties and requesting authorities the data reaches under stable arrangements, the lawful bases relied on under Articles 10 and 11, the contractual obligations of joint controllers and processors, and where those third parties sit with the safeguards for exporting to them. Sub-paragraph (h) then adds anything else the Commissioner asks for to demonstrate compliance.
Regulation 10.3.1(c) supplies the field most agent stacks lack. A system must ensure that its processing of personal data is explainable to Data Subjects and other stakeholders "in non-technical terms, with appropriate supporting evidence." Evidence attached to an explanation, at the point the explanation is given, is not something a token log produces. Regulation 10.3.5 completes the loop by letting a Data Subject complain against the outcome of the processing, which is the moment your trail either answers or does not. What Regulation 10 asks an AI system to produce deserves its own treatment, including the redaction allowance for intellectual property in the closing words of 10.2.2.
What does Singapore's agentic framework add to the trail?
IMDA published the Model AI Governance Framework for Agentic AI on 22 January 2026. It is voluntary. It asks that each agent carry a traceable identity linked to an accountable human, and that agent actions remain traceable and controllable through identity management and access controls scoped to the task.
Two fields come almost entirely from this document. The first is the agent's own identity, distinct from the service account it runs under. IMDA is direct that identity management has to extend to agents so that individual agent behaviour can be tracked and accountability located, and equally direct that this is unsettled ground where current authorisation systems, built around static scopes and single human principals, do not fit. The second is the authorisation the agent held when it acted. An agent that could have called six tools and called one is a different risk record from an agent that could only ever call one.
The framework also asks organisations to keep human-in-the-loop review effective over time in spite of automation bias, which is a records question in disguise. A checkpoint that is always approved within two seconds is visible in a log and invisible in a policy document. The framework's four dimensions read against a working agent map more closely onto operational reality than anything else a regulator has published.
What does the NIST AI RMF add?
NIST AI RMF 1.0 states outcomes rather than fields. MANAGE 4.1 asks for post-deployment monitoring plans that include mechanisms for capturing user input, appeal and override, decommissioning, incident response, recovery and change management. Each of those is an event, and an event nobody recorded cannot later be evidenced.
The contribution here is a category, not a column. MEASURE 2.4 asks that deployed system behaviour be monitored, and MEASURE 2.8 asks that risks to transparency and accountability be examined and documented. But it is the phrase "appeal and override" in MANAGE 4.1 that names the gap. Almost every agent log records what the agent did. Very few record what a person did about it afterwards: the challenge raised, the decision reversed, the compensating action taken, the part that could not be undone. That asymmetry is the single most common defect I see, and it is the one that hurts most in a dispute, because the question in a dispute is rarely what the system did. It is what you did once you knew.
What does ISO/IEC 42001 add?
ISO/IEC 42001:2023 treats records as management-system evidence rather than as a field list. Annex A control A.6.2.8 addresses the recording of AI system event logs. Clause 7.5 governs documented information, including its identification, availability and protection. The standard supplies discipline over records rather than their contents.
That discipline is worth more than it sounds. Clause 7.5 requires documented information to be available where needed and protected against loss of integrity, which is the closest any instrument in this set comes to saying your log has to be defensible as well as present. A.7.5 covers data provenance, which is why the sources an agent consulted belong in the entry rather than in a separate retrieval log. Clause 9.1 on monitoring and evaluation and Clause 10.2 on nonconformity and corrective action both assume records exist that make an issue traceable to its cause. ISO clause text is licensed, so the descriptions here are paraphrase; the standard itself is at iso.org.
What field list satisfies all six frameworks?
Seventeen fields cover every records demand across the six frameworks. Twelve are named, in terms, in at least one instrument. Four follow from a duty that cannot be discharged without them. One is required by none of them and is here anyway.
Rows marked derived are the weaker claims. In each of those the duty is express and the field is my reading of what discharging it takes, which is a reading you are entitled to disagree with. The last row is a different case again, dealt with at the end.
Seventeen rows: twelve named in an instrument, four derived, one required by none
Four of these are the ones production agent stacks reliably miss: agent identity, authorisation scope, human checkpoint status, and the reversal record. All four are cheap to capture at write time and close to impossible to reconstruct afterwards, which is the worst combination of properties an evidence field can have.
The human checkpoint field carries more weight than its single row suggests. Article 12(3)(d) reaches it only through Article 14(5), the four-eyes rule for biometric identification, but Article 14 as a whole is where the design pressure sits once Annex III obligations bind, and what Article 14 actually asks of an agent is not satisfied by a review queue nobody reads. Recording that a checkpoint was met is easy. Recording enough to show it was meaningful is the real requirement.
How long must an AI agent's audit trail be retained?
Six months minimum under EU AI Act Articles 19(1) and 26(6), for providers and deployers respectively, on logs under their control. One year under DPDP Rule 6(1)(e), and a second one-year window under Rule 8(3) that is a ceiling as well as a floor. DIFC Regulation 10 sets no period and requires production on request instead.
These are floors and they behave like floors. Both EU provisions defer to any Union or national law that sets a longer period, and both name data protection law in particular. Financial institutions fold the logs into the documentation they already keep under Union financial services law. Sectoral rules routinely run longer than either number.
The awkward part is that the floors point in opposite directions from the minimisation instinct. DPDP Rule 6(1)(e) requires the personal data associated with a log to be retained alongside it for the year, which sits uncomfortably beside storage limitation under GDPR and beside the erasure duty in Rule 8(1). Rule 8(3) pulls both ways at once, mandating a year and then mandating erasure. The workable answer is to stamp each entry with the retention class that governs it and let the longest applicable floor control, rather than applying one global period and discovering later that a purge job destroyed the evidence for an open matter. Retention that is not classified per entry becomes a compliance failure at exactly the moment you need the record.
Does an AI agent's audit trail have to be tamper-evident?
No instrument in this set uses the word. The EU AI Act, the DPDP Rules and DIFC Regulation 10 all require records to be kept or produced, and none specifies integrity protection for the record itself. ISO/IEC 42001 Clause 7.5 comes closest.
Clause 7.5 is not close. It asks that documented information be protected against loss of integrity, which is a records-management instruction about backups and access control, not a statement that a log must be able to prove its own history.
I have put the field in the list anyway, and the reason is evidential rather than regulatory. In any proceeding where these records are produced, the party producing them also controls the store they came from. A log that the producing party could have edited, with no way to show that it did not, is weak evidence in exactly the situation it exists for. Chaining entries so that each commits to the one before, writing append-only, and anchoring the chain head somewhere the operator does not control all make later modification detectable. None of that makes a record tamper-proof, and any vendor telling you otherwise is describing a threat model that does not include themselves.
Whether a regulator will read Article 12's traceability duty, or Rule 6's detection and investigation purpose, as implying integrity protection is genuinely open. The textual argument is available in both, since a record that can be silently modified does not support investigation and does not establish traceability. I have not seen either tested, and I would not build a compliance case on it. I would build the integrity marker anyway, because the cost is a hash per entry and the alternative is discovering the gap during a dispute.
Truveil scores AI agents across transparency, accountability, data trust and reversibility against these six frameworks, and produces the evidence described here.