Audit Trail

What an Audit Trail is

An audit trail is the record an AI system or workflow keeps of each run. It holds the input, what the model returned, what was approved and by whom, and what changed downstream. It is what lets any single run be reconstructed after the fact.

The idea is simple, and the test is plain: pick one run from last month and ask what happened. If the answer can be found, there is a trail. If the only answer is “it probably did what it usually does”, there is not.

This page covers what the record holds, how it differs from a chat transcript, who it makes accountable, what it shows when a case goes wrong, how light it can be for a smaller organisation, and where the EU AI Act turns it from good practice into a duty.

A Chatbot keeps a transcript, a Workflow keeps a record

The workflow article draws the line this page rests on. A chatbot answers a person in a conversation and stops. An AI workflow is started by an event, runs a defined sequence of steps across your systems, and leaves a record of what it did.

The article puts the difference in one sentence: a chatbot keeps a transcript, and a transcript shows what was said, not what was done. A transcript tells you what a person asked and what the tool replied. It does not tell you which record was changed, which email was sent, who looked at the result or whether anyone approved it.

That is why the record is the fifth of the article’s five tests. The other four ask what starts the workflow, where the result lands, where a decision is made and what happens on failure. The fifth asks what is kept after a run.

What the record holds

The article lists four things, and each one answers a different question.

The input says what the workflow was given. Without it, nobody can tell whether a wrong result came from the data or from the model.

What the model returned says what the AI step produced before anyone touched it. This is the part a transcript does keep, and it matters most when it is compared with the final outcome.

What was approved, and by whom, says where a person stepped in. The article treats this as the link between the record and accountability. A decision with no named approver has no one to answer for it.

What changed downstream says what actually happened in the connected systems: the record updated, the message sent, the payment queued. This is the half a chatbot never has, because a chatbot does not act on other systems.

Together they make a run reconstructable. The article says a real workflow can reconstruct any single run after the fact, which is what makes it auditable, and what lets a named person be accountable for it.

Reconstructing a single run

Reconstruction is the point of the whole record, and it is worth being concrete about what it allows.

It lets a manager answer a customer who asks why something happened. It lets the person who owns the workflow find where a mistake entered, whether at the input, in the model’s answer, at the approval or in the system that received the result. And it lets the business show a regulator, an auditor or a client what the workflow did, without relying on memory.

It also changes how mistakes are fixed. Without a record, a failure is a rumour: someone remembers it went wrong, and nobody knows why. With one, the same failure points to a step, and the fix can be made at that step and not guessed at.

Who Answers for the record

A record with no owner is a pile of data. The article’s test is that a real workflow answers with a specific system, a named owner and a log. The three belong together.

The ownership article makes the same point from the other side. When nobody owns an AI tool, there is no agreed route for reporting a problem and no record showing what the tool was doing. It asks for a one-page record of each tool: what it is for, who uses it and what data it reaches, with the next review date on it.

That one-page record and an audit trail are two different things, and both are useful. The one-page record describes a tool. The audit trail records what a workflow did on a particular run. The same article adds a warning that applies to both: a rule that says “a person should check the output” is a hope, not a control. The record has to say who checks and how often.

What the record shows when a case goes wrong

Every workflow meets cases it was not built for. The exception handling page covers what a workflow should do with them: name an owner, a queue or a notification, and say whether the action is reversed or held.

The audit trail is where that design shows up afterwards. The running cost article gives an invoice example. A workflow reads supplier invoices and checks them against the purchase order. A mismatched amount goes to a named person in finance every time, while a clean match is only sampled. Governance in that example is a log of what was read, what was matched and who approved each exception.

That log answers the awkward questions. Which invoices were flagged? Who approved the exception on this one? Was the clean match that turned out wrong one of the sampled ones? None of those can be answered from a chat window.

Keeping it light

The running cost article names governance as the fifth part of a workflow’s running cost: records of what the workflow did, controls on who can change it, and a plan for when it goes wrong. The cost source it draws on groups these as governance and risk, naming audit logs, access controls, compliance and incident response.

For a smaller organisation, the article says this can be light: a log, a named owner and a human in the loop on the risky steps. For a regulated one it is a real line of work. Either way, it says, it is cheaper to design in than to bolt on after an incident.

That last point is the practical argument. A log added at the design stage is a few decisions about what to keep. A log added after something has gone wrong is a reconstruction exercise with half the facts missing. The human in the loop page covers the person the record names, and the AI governance page covers the wider framework it sits in.

Logs and the EU AI Act

For most everyday business tools, keeping a log is good practice and not a legal duty. The ownership article says the monitoring, log-keeping and oversight duties apply to deployers of high-risk AI systems, and that most everyday tools are not in that category.

Where they do apply, the article says a deployer must monitor the system, keep its logs for at least six months, assign competent people to oversee it, and inform the provider and the authorities of a serious incident. The article also says the compliance deadline for stand-alone high-risk systems has moved to 2 December 2027, which is a reason to decide the owner before it arrives.

Which systems count as high-risk is a separate question. The high-risk AI system page covers it, and this page is not legal advice. The practical point is that a business which already keeps a sensible record of its workflows is not starting from nothing if a duty arrives.

Why a ban leaves no record

There is a second reason the record matters, and it comes from the banning article. When a business bans AI tools, use does not stop. It moves to personal accounts. The article says use on a company-approved tool can be reviewed, logged and improved, while use on a personal account on a personal phone leaves no record anywhere the business runs.

The risk has not gone down, and the visibility has. That is the description of shadow AI the article gives. An audit trail only exists for work that happens inside the business’s own tools. Providing approved tools is therefore a precondition for any record at all.

A worked example

An illustration, not a case study. A business uses an AI workflow to sort incoming customer emails into categories and draft a reply for a person to approve. The log keeps, for each email, the text received, the category the model chose, the draft it wrote, the name of the person who approved or changed the draft, and the time the reply was sent.

A customer complains that they received an answer meant for a different question. The owner opens the log for that email. The category was wrong, the draft followed from it, and the approver passed it without changing it. The fix has two parts: the category rules are corrected, and the approver is reminded what the approval step is for. Neither fix would have been found from a transcript.

Mix-ups worth avoiding

Four confusions come up often enough to name. The first is treating a chat transcript as an audit trail, when it shows what was said and not what was done. The second is treating the trail as an AI audit, which is the site’s diagnostic of a whole business and a different thing. The third is keeping logs with no named owner, so nobody reads them. The fourth is assuming the duty to keep logs applies to every AI tool, when the six-month duty applies to deployers of high-risk systems.

How we use it

The banning article shows why the record depends on approved tools: use on a company-approved tool can be reviewed, logged and improved, while use on a personal account leaves no record anywhere the business runs. The ownership article sets out the log-keeping duty a deployer of a high-risk system carries.

When an AI audit maps a process, what is recorded after a run is one of the things it asks. If you are not sure what your workflows keep, a discovery call is a quick way to find out.

Sources

• How to tell a real AI workflow from a chatbot with extra steps: the record as the fifth test, what it holds and reconstructing a run.
• How much does an AI workflow actually cost to run?: governance as a running cost, the light version and the invoice example.
• What happens when nobody owns the AI you have rolled out?: the one-page record, the deployer’s duties and the six-month log.
• Why banning AI tools at work does not work: approved tools being reviewable and loggable, personal accounts leaving no record.
• AI audit and exception handling: the site’s own audit and what a failure path looks like.