How AI action logging supports compliance in regulated industries.
Short answer. An AI action log ties one governed action (an AI action that went through approval) to an identity, the sources it read, the model that processed it, and the proposal. It also ties in the human decision, the operation that executed and the state left behind, each with a timestamp and a policy version. A chat transcript shows what was said. An application log shows what the software did. Only the action log gives an auditor a record to sample.
Regulated organisations already know what a good log looks like for a payment or a privileged access grant. An AI worker that can send, post or change a record needs the same record behind it.
What is an AI action log, and how does it differ from a chat transcript or an application log?
Three different records get called “the AI log” inside an organisation. A chat transcript captures the conversation: what the user typed, what the model returned. It has no fixed structure and no binding to a system of record, so it says nothing about whether the model’s suggestion touched real data.
An application log is built for engineers. It records requests, errors, latency and service health so a developer can debug an outage. It rarely names the human who approved anything.
An AI action log is a third thing, built to reconstruct one governed action end to end. A colleague, an auditor or a regulator who was not in the room can rebuild the story from the record alone. That is the discipline we set out in how to prove AI controls to an auditor. A policy describes what should happen. The log is what actually happened.
What fields does an AI action log need, at minimum?
Nine fields cover the chain from identity to consequence. Miss one and a link in the chain goes unverifiable.
| Field | Why it is needed | Where it comes from |
|---|---|---|
| Identity | Ties the action to one accountable identity, distinct from a shared login | The identity and access management system, and the permission grant behind it |
| Sources retrieved | Shows exactly what information the AI could see, so a wrong or leaked answer can be traced back to its source | The retrieval or connector layer for that run |
| Model route (which AI model service receives your data, and where it runs) Shows which model or endpoint processed the request, and whether content left your infrastructure |
The model gateway configuration in force for that run | |
| The proposal | Records the exact content produced, so intent can be judged from what was actually shown | The AI’s output as displayed to the approver, captured verbatim |
| The decision | Binds a named human’s approval or rejection to the exact proposal shown to them | The approval workflow’s own decision record |
| The executed operation | Confirms what ran matched what was approved | The system of record’s own transaction log |
| The resulting state (what the system looked like right after) Lets a reviewer verify nothing happened beyond the approved action |
A read of the target system taken after execution | |
| Timestamps | Establishes sequence, so approval precedes execution, and starts the retention clock | The logging system’s clock, synchronised across services |
| Configuration or policy version | Explains why two similar runs behaved differently, and lets a decision be reproduced | The version-controlled store for prompts, permissions and policy |
I would start by checking the decision field against the proposal field. A log that shows a decision without the literal proposal behind it leaves an auditor guessing what was actually approved.
What makes a log tamper-evident, and who should hold custody of it?
A log an administrator can quietly edit after the fact carries no more weight than a claim. Tamper evidence means entries are appended, never overwritten, and each one is checksummed or chained so a later change to an earlier record is detectable. Write-once storage, or an append-only table with no update permission granted to any account, reaches the same outcome without cryptographic chaining.
Custody matters as much as the mechanism. If the only copy sits inside a vendor’s product with no way to export the raw record, custody sits with the vendor, whatever the contract says about ownership. We set out the same test for the platform as a whole in what is a sovereign AI platform. Ask who can read the logs and whether you can retrieve them without the vendor’s support desk.
Separation of duties applies to the log too. The account that produced the actions being logged should not also hold permission to delete the entries describing them.
How long do regulated organisations need to keep AI action logs?
The EU AI Act sets three linked duties for high-risk AI systems. Article 12 requires the system to technically allow automatic recording of events over its lifetime, supporting risk detection, post-market monitoring and operational oversight. Article 19 requires providers to keep those logs for a period appropriate to the system’s purpose, of at least six months. Article 26(6) places the matching duty on deployers, requiring them to keep the logs under their control for at least six months, unless other Union or national law sets a longer period. See Article 12, Article 19 and Article 26 on the Commission’s AI Act Service Desk. We cover the wider set of deployer duties, and how the Digital Omnibus moved the high-risk compliance dates without touching Article 26, in EU AI Act deployer obligations after the Digital Omnibus.
In US healthcare, the HIPAA Security Rule’s audit controls standard at 45 CFR 164.312(b) applies to covered entities and business associates. It requires them to “implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.” The standard sets no retention period of its own. The separate documentation duty at 45 CFR 164.316(b)(2) covers the policies, procedures and documentation behind a control. Those records must be kept for six years from creation, or from when they were last in effect, whichever is later. Whether audit logs themselves fall under that six-year duty is a question for your compliance reviewer, who should set the log retention period and record the reasoning. Treat that as the floor for records of how your audit controls actually ran, and confirm the exact scope with counsel.
None of these provisions names a log format. They assume you can produce the full record, on request, when someone asks.
How does an auditor actually sample an AI action log?
An auditor does not read the whole log. They pick a period, select a handful of governed actions from it, ideally including at least one rejection, and ask for the full chain behind each: identity, sources, proposal, decision, execution, resulting state. A log that answers this cleanly for five actions is stronger evidence than an unverified assurance that logging runs on every action.
The rejection sample catches a weak implementation. A demonstration usually shows an approval. Ask the log for a rejected proposal and a separate read of the source system confirming nothing changed, the same test we set out in human approval workflows for AI agents.
What should never go into the log?
The instinct to log everything works against you. A log that captures full document contents, unredacted personal data or credentials becomes a second copy of your most sensitive data. The log store may then have broader read access than the source system it describes.
Log which document was retrieved and leave its full text in the source system. Log which record was updated and the specific field under approval, and leave the rest of that record’s contents out. Keep authentication secrets, API keys and full payment card or government ID numbers out of the log entirely. Your privacy reviewer should set this minimisation rule before the log ships. Waiting for an audit to ask what it now exposes is too late.
How do you test whether your logging actually works?
- Run one real governed action end to end, and pull every field in the table above from the live system as it actually behaves.
- Reject a second action and confirm the log shows the rejection, then read the source system directly to confirm nothing changed.
- Try to edit or delete a completed log entry using the access your own administrators hold. If you can do it quietly, so can anyone else with the same access.
- Export the log for one action to a file outside the system that produced it, and confirm the export matches the live record field for field.
- Hand the export to a colleague who was not in the run and ask them to reconstruct what happened. Note anything they cannot answer from the record alone.
Step five is the real test. If a colleague cannot rebuild the story, an auditor will not manage it from a summary either.
Questions buyers ask.
Is a chat transcript enough to prove an AI action was controlled?
No. A transcript shows what was said. It does not show who approved the action or what changed afterward. An auditor needs the decision bound to the exact proposal and a resulting-state check, neither of which a transcript captures.
How long should we keep AI action logs if we operate in both the EU and the US?
Keep the longest period that applies to any system or jurisdiction you operate in. EU AI Act Article 26 sets a six-month floor for deployers of high-risk systems; HIPAA’s documentation duty runs six years, and your compliance reviewer decides whether your logs fall under it. Confirm the exact scope with your compliance reviewer; one rule rarely covers every system.
Can a vendor’s platform logs satisfy our own compliance obligation?
Partly. You can rely on a vendor’s logs for the model route and execution record, but you still need your own record of who at your organisation approved or rejected each proposal. Confirm before you buy that the vendor’s raw logs export on request.
Does encrypting the log make it tamper-evident?
Not by itself. Encryption stops someone without the key from reading the log; it does not stop an authorised administrator from quietly rewriting an entry. Tamper evidence needs append-only storage or entry-level checksums in addition to encryption at rest.
This is the same evidence discipline behind the twelve tests in the Agentic AI Procurement Handbook, and what I check first when a regulated organisation asks whether its AI logging would survive an audit. Handvantage builds Vantage Workspace, a self-hosted AI workspace built so that AI actions go through human approval and leave a record, so weigh my view accordingly. This is an evaluation method, not legal advice. Your own counsel and compliance function should confirm which retention periods apply to your organisation.
For the evidence set an auditor will ask you to assemble from these logs, see How to prove AI controls to an auditor on the workspace site.
Josh Olayemi · Founder, Handvantage · September 2026 · About the author
