AI assurance and AI governance
AI assurance is the evidence that a system does what it was specified to do, and the means to check that claim later. It requires inspectable outputs, an audit of which sources were used, a record of where human review was applied, and a cost to serve that can be justified against the commercial value created. AI governance is the wider set of decisions about who is accountable. Assurance is how those decisions are demonstrated.
What is AI assurance?
Assurance is not a document produced after delivery. It is a property designed into the system: the ability to show, at any point, what was produced, from what, under which specification, and with what human involvement.
The systems that deliver automation and intelligence must remain maintainable from an accountability, cost and interpretability perspective. Assurance is the discipline that keeps them so.
What is AI governance, and how does it differ?
Governance is the set of decisions about who may build what, on which data, under which constraints, and who answers for the result. Assurance is the evidence that those decisions were honoured.
Governance without assurance is a policy nobody can check. Assurance without governance is a set of logs nobody is accountable for. The two are written together, before a build begins.
What makes an architecture accountable?
- outputs that can be inspected, not only sampled;
- a record of which sources were used, and which version of each;
- a record of where human review was applied, and what it changed;
- a stated quality threshold, and the evidence that it is being met;
- a refresh schedule for the evidence the system relies on; and
- a cost to serve that can be set against the commercial value.
Each of these is cheap to build in and expensive to retrofit. That is the argument for specifying them before anything is built.
How is assurance evidenced in practice?
By keeping four records, and by keeping them automatically rather than on request.
The output record: what was produced, when, and under which version of the system. The source record: which evidence was drawn on, from where, and how current it was at the time. The review record: which gates fired, who reviewed, what they changed, and what they let through. The specification record: which version of the use case definition was in force, including the quality threshold and the list of things the system is gated from supporting.
Together these answer the question that is actually asked when something goes wrong, which is not whether the model was good but whether the process was followed. A system that can answer it in an afternoon is maintainable. A system that requires a reconstruction is not. None of this is exotic. It is ordinary record-keeping applied to a component that happens to be statistical, and it is why assurance is an architectural question rather than a modelling one.
How is cost to serve justified?
By stating it and comparing it. A system carries an inference cost, a maintenance cost, a review cost and the cost of the evidence it depends on. Set against that is the commercial value it creates, expressed in the same terms as the rest of the diagnostic.
Where the comparison does not hold, that is a finding. Some steps are cheaper left with a person, and saying so is part of the work.
When is assurance designed?
Before anything is built, alongside the specification of the use case: what it must support, what it must be gated from supporting, the quality threshold it must meet, the evidence it relies on, how often that evidence must be refreshed, where human review is required, and what assurance gates and audit trails are needed.
Assurance added afterwards can only describe the system. Assurance designed at the outset can constrain it.
Common questions
-
What is AI assurance?
The evidence that a system does what it was specified to do, and the means to check that claim later. In practice it is four records kept automatically rather than on request: what was produced, from which sources, under which specification, and with what human review.
-
What is governance in AI?
The set of decisions about who may build what, on which data, under which constraints, and who answers for the result. Governance sets the rules. Assurance produces the evidence that they were followed.
-
Can you give an example of an AI governance policy?
A short document naming, for each class of use case, which data may be used, which architectures are permitted, who approves a deployment, what must be gated from automation, what quality threshold applies, and where human review is mandatory. A policy that cannot be checked against a system's own records is a statement of intent rather than a policy.
-
How do you develop AI governance?
Start from the use cases rather than from a framework. Specify one properly, note every decision the specification forced, and generalise those decisions into rules. Governance written before any use case exists tends to be either unenforceable or so broad that it prevents work without reducing risk.
-
What is the 30 per cent rule in AI?
It is a heuristic rather than a rule, used loosely to suggest that only a minority of a process, often put at around a third, is genuinely amenable to automation. The proportion is not a constant and we do not treat it as one. How much of a process will yield to specification is established by mapping it, and it varies widely between operations.
-
Is AI assurance the same as an audit?
No. An audit is a formal engagement performed against a standard by an appointed party. Assurance here means the architectural properties that make such an engagement possible, and the ordinary evidence a business needs in order to stand behind its own outputs.
-
Does assurance require explainable models?
It requires interpretable systems, which is a weaker and more achievable requirement. You need to know what evidence was used and where judgement was applied. That is a property of the architecture around the model as much as of the model itself.
-
What about regulated processes?
The specification names what the use case must be gated from supporting. Regulated determinations are frequently placed on that list, and the step stays with a person.
-
How does this interact with on-premise deployment?
Directly. Where the model runs on your own infrastructure, the audit trail, the evidence store and the review record can all sit inside the same boundary, and the audit trail is yours.