AI Assurance UK: Evidence Packs for Boards and Buyers

AI Assurance Is an Evidence Discipline

An AI policy states what an organisation intends to do. An AI assurance pack shows what a particular system did, which controls operated, what was tested, what failed, and who accepted the remaining risk.

That distinction matters because assurance is not another name for governance. The UK government’s Introduction to AI assurance defines assurance as measuring, evaluating and communicating whether an AI system meets relevant criteria. Its purpose is justified trust: confidence supported by evidence, rather than confidence created by a supplier presentation or a successful demo.

The UK landscape is becoming more concrete. The Department for Science, Innovation and Technology updated its AI Management Essentials guidance in February 2026. AIME gives organisations a baseline self-assessment across internal processes, risk management and communication, but DSIT is explicit that it is not product evaluation, formal certification or proof of legal compliance. In January 2026, UKAS granted the first UK accreditation for ISO/IEC 42001 certification, creating a credible route to independent assessment of an organisation’s AI management system. In June, Ofgem opened a live call for input on AI assurance in energy, focused on how systems should be tested, evaluated and governed.

The direction is clear: leaders should ask for system-level evidence, not simply an enterprise policy.

Start With an Assurable Claim

“Safe”, “fair” and “accurate” are aspirations, not useful assurance claims. They do not identify the system boundary, affected people, operating conditions, measurement method or acceptable result.

The government’s roadmap to an effective AI assurance ecosystem adapts five elements from established assurance practice:

• a three-party relationship between the responsible party, assurance practitioner and assurance user;
• an identifiable subject matter;
• suitable criteria against which it can be assessed;
• sufficient, appropriate evidence; and
• a conclusion that communicates the assurance obtained.

Apply those elements before collecting documents. A useful claim register looks like this:

Compare that with “our AI is safe”. The narrow claim can be challenged, tested and refreshed. The broad one cannot.

Build the Pack Around the System, Not the Model

A production AI system includes data pipelines, retrieval, prompts, models, tools, permissions, people and the business process around them. A model card alone cannot demonstrate that the deployed service is controlled.

A practical evidence pack should contain ten connected records.

1. Purpose, scope and prohibited use

State the business objective, intended users, people affected, deployment geography, allowed actions and explicit exclusions. Record the conditions under which the system must stop or fall back. Include a process map showing where AI changes an outcome—not merely where an API is called.

2. Ownership and decision rights

Name the business owner, technical owner, data owner, security contact, risk reviewer and incident commander. Define who can approve launch, change thresholds, accept risk, pause the service and authorise a restart. “The AI team” is not an accountable owner.

3. System and change record

Record model and embedding versions, prompts, retrieval configuration, tools, hosting regions, suppliers, safety settings and release identifiers. Link each material change to approval and regression results. The NCSC’s Guidelines for secure AI system development cover secure design, development, deployment, operation, logging, monitoring and update management; the evidence pack should make those activities inspectable.

4. Data and knowledge lineage

For every material source, record origin, purpose, licence or permission, owner, collection date, transformation, quality checks, retention, deletion route and access controls. Document derived attributes and sensitive inferences, not only raw fields. Where data quality is material, the ISO/IEC 5259 family now provides specific standards for data-quality measures, data-quality management and governance.

5. Impact, risk and threat assessment

Identify affected groups, foreseeable misuse, failure severity, security threats, privacy impacts, equality impacts and routes to redress. Connect each risk to a control, owner and verification method. ISO/IEC 23894:2023 provides AI-specific risk-management guidance; NIST’s Generative AI Profile adds risks and suggested actions for generative systems.

6. Evaluation design and results

Preserve the test-set version, sampling method, labels, metrics, thresholds, results, failure slices and known limitations. Include ordinary cases and boundary cases: incomplete records, contradictory evidence, policy changes, adversarial instructions, accessibility needs and protected or vulnerable groups where relevant. Report confidence intervals or sample counts; a percentage without a denominator is weak evidence.

7. Human control and redress

Show where a person approves, overrides, contests, reverses or stops an outcome. Preserve the information available to reviewers, their authority, training and service target. Test the route from a real user interface—not just the policy describing it.

8. Live monitoring

Define leading signals, outcome measures, alert thresholds and response owners. Useful measures can include unsupported-answer rate, unauthorised-action attempts, permission failures, override rate, complaint rate, escalation resolution time, cost per successful outcome and drift by question or customer segment. Choose measures from the actual harm model; do not copy a generic dashboard.

9. Incidents, exceptions and accepted risk

Keep incident timelines, affected records, containment, customer remediation, root cause, corrective action and retest evidence. Log control exceptions with an owner and expiry date. Risk acceptance should name the person accepting it and the evidence they reviewed.

10. Supplier evidence

Record what the supplier proves, what it merely asserts and which controls remain yours. Include service versions, security material, evaluation scope, data-use terms, retention, subcontractors, change notification, model-retirement terms, exportable logs and incident obligations.

Use an Evidence Register, Not a Folder of PDFs

A pack becomes auditable when every claim points to current evidence. Use a register with at least these fields:

A zero observed failure rate is not proof that failure is impossible. State the test scope, sample size and residual uncertainty. Evidence should be attributable, time-stamped, versioned and reproducible. Where logs contain personal or confidential data, retain the minimum necessary evidence and apply appropriate access and retention controls.

Separate Self-Assessment, Audit and Certification

These terms are often blurred:

ISO/IEC 42001 specifies requirements for establishing and continually improving an AI management system. Accredited certification can strengthen confidence in management controls, but it should not be marketed as a universal safety certificate for every deployed model.

Ask Better Questions When Buying AI

Procurement should request evidence that matches the intended workflow:

• Which exact model, configuration and system boundary were evaluated?
• Which populations, languages, file types and failure conditions were included?
• What were the denominators, thresholds and unresolved failures?
• Can we reproduce tests or export the required logs?
• How are prompt, model, tool and safety-setting changes communicated?
• How quickly do deletions and permission revocations propagate?
• Which incidents must be disclosed, and within what period?
• Which controls are operated by the supplier, customer or another subcontractor?
• What evidence remains available if the model is retired or the contract ends?

A generic responsible-AI brochure answers none of these questions.

The same evidence should cover knowledge retrieval and operating economics. Use the enterprise RAG audit for retrieval claims and the production AI cost guide for unit economics.

Give the Board a Decision View

The board does not need every trace, but it does need a truthful route into the evidence. A one-page view should show:

Review cadence should follow risk and change. Security incidents and harmful actions need immediate response; operational measures may be reviewed weekly; representative quality samples monthly; purpose, suppliers and residual risk quarterly. Any material change to model, data, permissions, prompt, policy or workflow should trigger targeted reassessment regardless of the calendar.

A 30-Day Route to a Defensible Pack

Days 1–5: inventory the system, map the workflow, name owners and define the first five narrow claims.

Days 6–10: choose criteria, thresholds and assurance users; map AIME, ISO/IEC 42001, NIST AI RMF and sector obligations only where relevant.

Days 11–18: assemble lineage, configuration, risk, supplier and human-control records; identify missing evidence rather than filling gaps with narrative.

Days 19–24: run reproducible evaluation, permission, abuse, reversal and incident exercises. Preserve configurations, results and failures.

Days 25–27: have someone outside the delivery team challenge the claims, evidence sufficiency and conclusions.

Days 28–30: publish the evidence register, board view, open actions, accepted risks and next review triggers.

The strongest assurance pack is not the largest. It is the one in which a decision-maker can move from a material claim to suitable criteria, current evidence, a qualified conclusion and a named owner without relying on the original project team’s memory. That is how AI governance becomes testable—and how trust becomes deserved.