Evidence, not attestation: making AI controls auditable

A regulated organisation adopting AI is now in scope of several regimes that were written independently and overlap awkwardly. ISO/IEC 42001 asks whether you operate a management system for AI. The NIST AI RMF asks whether you can map, measure and manage the risk of each system. DORA asks about operational resilience and, pointedly, about your dependence on a small number of critical third parties. A client’s due-diligence questionnaire asks all of it again in its own vocabulary.

Answering each separately is how assurance functions end up spending a quarter producing documents. The alternative is to accept that these regimes mostly want the same small set of facts, and to build the estate so those facts fall out of it.

The facts every regime wants

Across the frameworks, the recurring questions reduce to about six:

1. What AI systems do you have? Including the ones procured as a feature of something else, which is where the inventory usually fails.
2. What data does each one process, at what classification, and where does it go?
3. Who approved it, against what criteria, and when is that decision revisited?
4. What can it do? Its permissions, its tools, its blast radius.
5. How would you know it had gone wrong, and what happened the last time it did?
6. What is your dependence on the provider, and what happens when the provider changes, degrades or withdraws the model?

Every one of those can be answered from running systems rather than from a questionnaire, and answers that come from running systems are the only ones that stay true.

Make the control point the evidence source

The inventory question is a good example. Maintained as a register, it is stale within a month and everybody knows it. Derived from a mandatory AI gateway, the provider contracts and the procurement pipeline, it is a query. And the gap between those two lists is probably the most useful finding you will produce this year.

The same holds elsewhere:

• Data flow comes from gateway routing policy and its logs, not from a diagram someone drew during design.
• Approval comes from the pipeline: a system reaches production because a gated assessment passed, and the record of that gate is the evidence.
• Permissions and blast radius come from the identity platform and the tool definitions, which are the authoritative statement of what an agent may do.
• Provider dependence comes from the gateway’s model routing, which already knows which applications would stop working if a given provider went dark.

Evidence produced this way costs nothing extra at audit time, because the control was always producing it. Evidence produced by attestation costs a fortnight of somebody’s quarter, every quarter, and demonstrates only that the fortnight was spent.

Model change is the resilience risk people miss

DORA-shaped thinking about third parties translates to AI more directly than it first appears, with one twist. The classic concerns all apply: concentration, substitutability and exit. A handful of providers, deep integration, and switching costs that are real once prompts, evaluations and tooling have been tuned around one model’s behaviour.

The twist is that the dependency changes underneath you without an outage and without a contract event. A provider deprecates a version, adjusts a safety layer, or ships an update, and a system that passed its assessment six months ago now behaves differently in ways no availability monitor detects. Version pinning where the provider offers it, an evaluation suite that runs against the production configuration on a schedule, and a tested route to an alternative model for anything business-critical are the practical controls. The exit plan should name the alternative and the last date it was exercised, because one that has never been run is a paragraph, not a plan.

What to write down

Documentation still has a job. Keep it to the things that genuinely cannot be derived: the risk appetite, the classification rules, the approval criteria, the accountable roles, and the decisions taken with their rationale. These are short, they are stable, and they are what a regulator or a client’s architect actually reads.

Everything else should be a query against a system that would have to be running anyway. That is the difference between a management system that survives its second year and a folder of documents that was accurate on the day it was approved.