Make the controls deterministic rather than the model. A regulator asks who authorised an action, on what evidence, and whether an unauthorised one was prevented. Those answers come from enforced permissions, a required human approval, and a complete record of each run, none of which depend on the model behaving identically twice.
The obligation is about control, not repeatability
It is tempting to read non-determinism as automatically non-compliant. Most frameworks do not require that a system produce the same output twice. They require that risk is assessed, that access is controlled, that consequential decisions have accountable owners, and that what happened can be reconstructed.
Human processes are non-deterministic too. Two analysts reviewing one file may reach different conclusions, and that has never made the process unauditable. What makes it auditable is that each conclusion has a named owner, a recorded rationale, and evidence attached. An agentic system can meet the same standard, and can meet it more consistently than a human process because the recording is automatic rather than remembered.
So the design question is not how to make the model deterministic. It is which parts of the system must be deterministic, and the answer is the controls around it.
Put the determinism where it is checkable
- Permissions. Enforced by the system being called, not by the agent. A request outside authority is refused underneath, so the refusal happens the same way every time regardless of what the model asked for.
- Approval before consequence. A named human records approval or rejection with a reason before any consequential action. Risk tier decides who may approve. This is the control that turns a probabilistic proposal into an accountable decision.
- Separation of proposal and execution. The component that acts is not the component that reasons, so an approved action executes exactly as approved.
- An append-only record. Actor, reason, evidence, artifact, model version, and cost for every run, written where it cannot be quietly edited.
Those four are deterministic and testable. You can demonstrate each one to an auditor by attempting a violation and showing the refusal, which is far stronger evidence than a claim about model behaviour.
What to expect to be asked, and what evidence answers it
Expect questions about accountability, access, and reconstruction rather than about model internals. Who is responsible for this decision. How do you know the agent could not see restricted data. Show me a specific action and tell me why it was taken. Show me a case where the system refused.
Each of those is answered by a record, and the last one matters more than teams expect: a system that has never refused anything has not demonstrated a control. Refusals are evidence, so they belong in the log alongside successes. How you audit what an agent did covers reconstructing a single decision from that record.
Evaluations play a supporting role rather than a starring one. They are evidence that behaviour was assessed before release, and they should be stored per version. They are not a guarantee, and presenting them as one tends to invite the harder question. What evals actually catch is the honest framing.
Frequently asked questions
Can we claim an agentic system is fully auditable?
You can claim each action is reconstructable, if the record genuinely holds actor, reason, evidence, and artifact. Avoid claiming the model is explainable in the sense of a decision tree, because that is not what these systems are. The defensible claim is about the trail and the controls, and it is stronger than an explainability claim you cannot support.
Does a human approval on every action defeat the purpose?
It depends where the effort actually sits. Most of the cost in these workflows is assembling context and drafting, not deciding. If an agent does the assembly and a person decides in moments with the evidence attached, the workflow is faster and the accountability is unchanged. Approval becomes a bottleneck only when it is applied to actions that carry no consequence.
How do we handle a model version changing underneath us?
Treat it as a release. Pin the version you validated, record which version each run used, re-run evaluations before adopting a new one, and keep the previous version available to fall back to. Then a behaviour change is a change you made deliberately, with evidence, rather than something that happened to you.
