What an Audit Trail Should Contain If a Regulator Ever Asks

Somebody asks you to explain a decision your software made eight months ago. If your audit trail only says "agent updated record", you have nothing to give them. A useful audit trail records what the agent saw, what it produced, who approved it and what happened next.

Rules on this differ by country, sector and regulator, so check what applies to you rather than assuming. What follows is the practical minimum that makes any of those conversations survivable.

The fields to record on every action

Treat each agent action as one row. For that row, keep:

• A stable identifier for the action, so anything referring to it points at the same thing forever
• Timestamp with timezone, recorded once at the source rather than at each hop
• Which agent ran, and which version of it
• Which model answered, including the version or build identifier
• The trigger: a person clicked something, a schedule fired, or another system called in
• The named person on whose behalf it ran, if anyone
• What records it read, listed by identifier
• What it produced, stored in full rather than summarised
• What action followed, and against which record
• The outcome: succeeded, failed, or rejected

Most tools give you some version of this list. The gaps are usually in the same three places.

The three fields most tools quietly omit

One: what the agent was actually shown. Logs often record the user's request but not the material the system pulled in around it. If the agent read six documents and three of them were out of date, that is the explanation you need. Without the retrieved set, you can see the answer but never work out why it was wrong.

Two: what the agent declined to do. Refusals, low confidence responses and hand backs to a human rarely get logged, because nothing happened. Those are exactly the events that show your controls working. An audit trail full of successes proves nothing about your guardrails.

Three: what the human changed. Plenty of systems record that an approval happened. Far fewer record what the approver edited before approving. The difference between "approved unchanged" and "approved after rewriting half of it" tells you whether your review step is real. Keeping a record of who approved what is only half the job if the edits are not kept beside it.

An audit trail that records only successful actions cannot show that your controls work. Log the refusals, the retrieved inputs and the human edits, because those three are what an outside reader will ask about.

Retention, access and integrity

A log nobody can trust is decoration. Three practical points.

Keep entries append only. If an operator can edit history, the record proves nothing. Corrections go in as new entries that reference the old one.

Decide how long you hold each field, and write it down. Full inputs and outputs may carry personal data, and holding them forever creates a different problem from the one you were solving. Retention periods vary by jurisdiction and by the kind of data, so take advice rather than copying a number from a blog.

Control who can read the trail. An audit log of HR actions contains the HR data. Access to it should be narrower than access to the systems it describes, not wider.

Make it readable by a person

The test is not whether the data exists. It is whether somebody who was not there can reconstruct one action in ten minutes. The weekly version of the same habit is reading the agent's work log.

Try it. Pick a decision from last quarter and answer these without asking a colleague:

• What was the agent asked to do, and by whom?
• What information did it have in front of it?
• What did it produce, word for word?
• Who approved it, and did they change anything?
• What happened in the systems downstream?

If any answer requires reading raw logs from three services and joining them by hand, your trail exists but does not work.

Where a single set of records helps

Most audit gaps come from stitching. The task tool logs the task, the HR tool logs the leave, the AI tool logs the prompt, and nothing joins them. When somebody asks why an agent scheduled work for a person who was away, the answer sits in three systems with no shared key.

SicherOne runs project management, HR and AI agents on one set of records, which means an agent action and the records it touched sit in the same place. Private models can be self hosted where data handling rules require the model to stay inside your own environment.

A short checklist to run this month

• Pick one agent action from your logs at random
• Try to answer the five questions above using only what you stored
• Note every question you could not answer
• Add those fields before you add another agent, then fold the check into a quarterly AI audit you can run yourself

Regulators, auditors and unhappy customers all ask the same thing in different words: show me what happened. The work is boring and it is much cheaper to do before somebody asks.