Evidence assembled after the fact is justification, not control

Every company that uses AI agents to run regulated processes will eventually get a simple question from its auditors: why was this case decided this way?

The question is simple. The answer reveals, within minutes, whether the company has control over its AI agents or only a narrative about having that control.

Two paths that look identical in the workflow — but are not

Path A — evidence reconstructed. Only after the questions arrive does someone open the agent's records, cross-reference the system logs, hunt for approvals in email, ask IT which model versions were running, and assemble a file. It takes days. Sometimes it works out.

Path B — evidence generated in real time. The audit records already exist before the questions, because the operation produces them as a by-product of execution. Answering takes minutes, and there will probably be fewer follow-up questions, as the reports are of higher quality.

In the workflow, the two paths are identical: there is a policy, there is an owner, there are records. The difference only shows up under pressure — and that is when it gets expensive.

?The auditor's question: why was this case decided this way?

Path A · evidence reconstructed

1. Policy
2. →Owner
3. →Operation
4. →?The auditor's question: why was this case decided this way?
5. →Open the agent's records
6. →Cross-reference the system logs
7. →Hunt for approvals in email
8. →Ask IT which model versions ran
9. →Assemble a file
10. →Days. Sometimes it works out.

Path B · evidence generated in real time

1. Policy
2. →Owner
3. →Operation
4. →?The auditor's question: why was this case decided this way?
5. →Answer
6. →Minutes.

The record is created with the operation

What has to be in the audit trail

A set of audit records that stands up to serious questioning carries these items, per unit of work:

1. The input — what reached the AI agent: tasks, flows, and processes.
2. The decision — what the agent did, in what order, and why.
3. The authority invoked — which rule in the matrix authorized those actions.
4. The data sources consulted — where the information used came from.
5. The human intervention — who approved what, and when.
6. The cost — what that unit of work consumed: AI tokens, infrastructure, person-hours.
7. The outcome — accepted, corrected, or rejected.

1. Input
2. Decision
3. Action
4. Outcome

Unit-of-work record

Key: unit-of-work ID

• Inputs
• Decisions
• Authority invoked
• Data sources queried
• Human interventions
• Costs
• Outcomes

Stored in chained batches, signed with the client's key

1. Batch 1

   Signed · hash of the previous one

3. Batch 2

   Signed · hash of the previous one

5. Batch 3

   Signed · hash of the previous one

7. Next batch
8. Changed? The chain flags it

Reconstructing those items after the fact is hard not because the data is missing, but because it lives in different systems, on different clocks, with no key tying it to the same unit of work. The missing link is almost always the same: the connection between the decisions and the data sources and circumstances that produced them.

Only one company in ten produces audit trails of that quality. That is not merely a maturity detail: it is the line between answering immediately and negotiating deadlines with auditors, regulators, and litigants.

What should happen before any question comes up

This discussion tends to be treated as a compliance topic, to be handled later. The data shows it is already an operational, day-to-day matter:

And most companies start from a weaker position than the narrative suggests:

AI agents nobody registered are agents with no owner, no declared authority, and no audit trail. They do not show up in the inventory precisely because nobody is watching them — and that is what produces the incidents nobody can explain afterward.

Two more numbers complete the picture:

Almost nobody automatically blocks out-of-scope AI agent actions, and only one in five has a formal process to decommission and retire agents. Both ends of the lifecycle — what AI agents may do, and when they stop operating — are left open.

Before production

1. 01UnderstandAn end that is rarely covered
2. →02Specify
3. →03Plan

In production

4. 04Production
5. →05Steady state
6. →06Revalidate

Revalidate · every quarter

End of life

7. 07DeactivateAn end that is rarely covered

Why human gates matter more than they seem to

A human gate that approves a task after the fact is not control: it is merely a justification. In litigation it works against whoever signed it, because it shows the control existed on paper but not in practice.

A human gate that works has three properties:

• It blocks. If the approval does not happen, the action does not happen. An alert that can be ignored is not a gate, it is a notification.
• It is recorded where the decision is. Approval by email or chat does not attach to the unit of work unless someone links it by hand.
• Its authority is declared in advance. Whoever approves needs to know, in writing, up to what value and under what conditions an approval may be given.

A gate	Not a gate
Blocking gateWithout approval, the action does not happen.	Alert that can be ignoredA notification.
Approval before the actionControl.	Approval after the factJustification, and in litigation it weighs against whoever signed.

The pattern behind this is called positive enumeration: an AI agent may do only what is listed, and whatever is not listed is forbidden by definition — not by policy. The difference between "should not do" and "cannot do" is the difference between trusting and verifying.

One profession that shows the whole problem

The gap between usage and rules is easy to see in one field:

Heavy usage, thin guidance. That is the combination that produces the worst possible outcome: the technology is already in the workflow, but the organization has not decided what is acceptable. When something goes wrong there is no prior standard to appeal to — only opinions formed after the fact. For lawyers, that can turn into a legal scandal, with press coverage.

And rollbacks are already the rule, not the exception:

What to do, in the right order

1. Take inventory. Find what is already running, especially what nobody cataloged or made official.
2. Name a human owner for each instance of each AI agent. Not a department: a person.
3. Declare authority in writing and in the processing rules, by positive enumeration, before production.
4. Instrument from day one. Evidence collected after the fact is reconstruction; evidence collected in real time is the record itself.
5. Define how to switch each agent off before officially switching it on.

None of these steps requires new technology. All of them require a management decision before deployment — which is, in the end, what separates the companies that scale from the companies that roll back projects.

The seven disciplines that organize this are in Method, and the layer that sustains those disciplines in operation is AInda Controle, our control layer.