Key takeaways
- AI assurance is the process of measuring, evaluating and communicating whether an AI system does what it claims. It produces evidence, not opinions.
- Assurance, audit, conformity assessment, certification and accreditation are five different things, and confusing them is the fastest way to buy the wrong service.
- Under the EU AI Act, most high-risk providers assess their own systems internally, so an AI assurance process is not preparation for the conformity assessment. It is the conformity assessment.
ISO/IEC 42001certifies your management system.ISO/IEC 42006:2025governs the bodies allowed to issue that certificate, and almost no vendor explainer mentions it.- A dated certificate cannot describe a model that was retrained last week, which is why assurance has to run continuously rather than annually.
What AI assurance actually means
The UK government’s official guidance defines AI assurance as “the process of measuring, evaluating and communicating” the trustworthiness of an AI system. Each of those three verbs is doing work, and skipping any one of them is where most programmes fail.
Measuring means gathering data about how the system behaves: accuracy across subgroups, failure modes, latency under load, behaviour on inputs it was never trained for. Evaluating means judging those measurements against a benchmark that someone outside your team recognises, whether that is a standard, a regulatory threshold or a documented internal risk appetite. Communicating means putting the result in front of the people who need it, in a form they can act on and, if necessary, challenge.
The distinction that matters most is between assurance and trustworthiness. Trustworthiness is a property you claim about a system. Assurance is the process that makes the claim checkable. An organisation can have a genuinely well built model and no assurance at all, because nobody can demonstrate the quality to a third party. The reverse is also true, and more dangerous: a thick pile of documentation that no measurement supports.
This is why AI assurance sits inside AI governance rather than alongside it. Governance decides what the organisation will and will not do with AI, who is accountable, and what thresholds apply. Assurance is the evidence-producing machinery that tells you whether those decisions are actually holding in production.
Assurance, audit, certification and conformity assessment are not the same thing
Almost every article on this topic uses these terms interchangeably. They are not interchangeable, and the differences determine who you hire, what you get and whether a regulator will accept it.
| Term | What it is | Who performs it | What it produces | Legally required? |
|---|---|---|---|---|
| Assurance | The umbrella process of measuring, evaluating and communicating trustworthiness | Anyone: internal teams, customers, independent providers | Evidence and a substantiated claim | No, but it is how you satisfy things that are |
| Audit | One mechanism inside assurance: a structured examination against defined criteria | Internal audit, or an external audit firm | An audit report with findings | Sometimes, under sector rules |
| Conformity assessment | The EU regulatory procedure demonstrating a product meets legal requirements before it goes to market | The provider itself, or a notified body | A declaration of conformity and CE marking | Yes, for high-risk systems under the EU AI Act |
| Certification | Third-party attestation that a management system meets a standard | An accredited certification body | A certificate with an expiry date | No, voluntary |
| Accreditation | Verification that the certification body is competent to certify | A national accreditation body | Accreditation of the certifier | Applies to the certifier, not to you |
The practical consequence is that a certificate against ISO/IEC 42001 does not discharge an EU AI Act obligation, and a conformity assessment does not make your AI governance mature. They answer different questions for different audiences. An AI audit is one instrument you use to generate AI assurance evidence, and the quality of that evidence depends heavily on how auditable the system was designed to be in the first place. Retrofitting auditability after deployment is expensive and usually incomplete.
The assurance toolkit: seven mechanisms and what each one proves
The UK guidance sets out a toolkit of AI assurance mechanisms. The useful way to read it is not as a menu of activities but as a list of evidence artefacts, because the artefact is what survives the meeting.
- Risk assessment identifies what could go wrong and how badly. Artefact: a risk register with owners, likelihood, severity and treatment decisions.
- Impact assessment looks outward at effects on people, rights and equality. Artefact: a documented assessment naming affected groups and mitigations.
- Bias audit examines inputs and outputs for unfair disparities. Artefact: subgroup performance metrics with the fairness definition used stated explicitly. Read more on AI bias and how the measurement choice shapes the answer.
- Compliance audit checks adherence to policies, regulations and contractual commitments. Artefact: a control-by-control finding log.
- Conformity assessment demonstrates a product meets specified legal requirements before market entry. Artefact: technical documentation plus a declaration of conformity.
- Formal verification uses mathematical methods to prove a system satisfies a specification. Artefact: a proof, with its assumptions written down. Rare outside safety-critical contexts, and only as strong as the assumptions.
- Model performance testing measures the system against benchmarks and thresholds. Artefact: dated test results tied to a specific model version. This is where AI benchmarking practice does the heavy lifting.
Notice that six of the seven produce a document whose value decays over time. That decay is the central operational problem in AI assurance, and it is handled well in a mature AI risk management programme and badly everywhere else.
Who provides AI assurance: first, second and third party
AI assurance is classified by who performs it, and independence changes what a claim is worth.
First-party assurance is self-assessment. The team that built the system evaluates it. This is fast, cheap, deeply informed and structurally conflicted. Second-party assurance is performed by a party with a commercial interest, typically a customer assessing a supplier during procurement. Third-party assurance is performed by an independent provider with no stake in the outcome, which is the only variety that carries weight with a regulator or a sceptical buyer.
Why the third-party market is still immature
The UK’s Trusted Third-Party AI Assurance Roadmap, published in September 2025, put numbers on this. The UK third-party AI assurance market comprised roughly 524 companies worth about GBP 1.01 billion in 2024, with a projection of GBP 18.8 billion by 2035 if the obstacles clear.
Those obstacles are worth naming, because they explain why buying AI assurance today is harder than it should be. The roadmap identifies a quality-standards gap (existing AI certifications largely lack accreditation), a talent shortage spanning machine learning, law, ethics and standards, restricted information access (providers will not hand over training data or model internals), and too few forums for developing continual assurance techniques.
The response sequences three quality-assurance models: professional certification for individual practitioners first, then process certification, then firm accreditation. A GBP 11 million AI Assurance Innovation Fund and a consortium chaired by BCS support the work. The signal for buyers is simple: for the next few years, verify the credentials of whoever you engage, because the market has not yet standardised what a competent AI assurance provider looks like.
How AI assurance feeds the EU AI Act evidence chain
This is where most AI assurance guidance stops short, and it is the part that determines legal exposure.
Article 43 of the EU AI Act sets out two conformity assessment routes for high-risk AI systems. The first is internal control under Annex VI, which does not involve a notified body at all. The second, under Annex VII, involves a notified body assessing both the quality management system and the technical documentation.
Which route applies is not a choice for most providers. For high-risk systems in Annex III point 1, covering biometrics, the provider may choose between the two. For Annex III points 2 to 8, covering critical infrastructure, education, employment, essential services, law enforcement, migration and administration of justice, the internal control route applies. A narrow exception makes the market surveillance authority act as the notified body where systems are put into service by law enforcement, immigration or asylum authorities, or by EU institutions.
The implication deserves stating plainly. For the large majority of high-risk AI systems, nobody external is coming to inspect the system before it goes to market. The provider signs the declaration itself. That means your internal AI assurance process is not preparation for the conformity assessment. It is the conformity assessment, and the only thing standing between a signed declaration and a false one is the quality of your own evidence.
That evidence then flows into a chain of downstream obligations: the Annex IV technical documentation, the EU declaration of conformity, CE marking, registration in the EU database, and ongoing post-market monitoring. Each link consumes artefacts the AI assurance process is supposed to have produced. Getting the documentation requirements right early is what makes the rest tractable, and the broader regulatory landscape adds parallel duties in other jurisdictions.
What the Digital Omnibus deferral actually buys you
The timeline changed. The Digital Omnibus entered into force on 27 July 2026 and, according to the European Commission, high-risk rules for standalone Annex III systems now apply from 2 December 2027, while rules for AI embedded in regulated products under Annex I apply from 2 August 2028.
General applicability and the transparency obligations were not deferred and took effect on 2 August 2026. So the correct reading is not that high-risk compliance was cancelled. It is that providers received additional time precisely because the standards and tooling were not ready. Organisations that treat the interval as build time will have a working evidence pipeline when the date arrives. Organisations that treat it as a reprieve will be assembling three years of documentation retrospectively, which is exactly the failure mode the deferral was meant to prevent.
Standards turn AI assurance into something a regulator will accept
The UK guidance puts it bluntly: “without standards we have advice, not assurance”. A measurement only means something if the yardstick is one other people recognise.
Three layers matter. ISO/IEC 42001 specifies the AI management system, the organisational machinery for governing AI across its lifecycle. Beneath it, ISO/IEC 42006:2025, published on 7 July 2025 by ISO/IEC JTC 1/SC 42, sets requirements for the bodies that audit and certify an AI management system, building on ISO/IEC 17021-1. This is the layer nearly every explainer omits, and it answers the question a buyer should always ask: who certified the certifier, and against what competence criteria?
Above both sits the harmonised-standards mechanism. Under Article 40 of the EU AI Act, conformity with a harmonised standard published in the Official Journal grants a presumption of conformity with the corresponding legal requirement. The European standardisation bodies have drafts in preparation under mandate M/593; they are not yet citable as harmonised ENs, and until they are published, providers carry the burden of arguing their own methods sufficient. For measurement vocabulary, the NIST AI Risk Management Framework remains the most widely used common language, particularly its Measure function. A side-by-side comparison of the frameworks helps when deciding which to anchor on.
Point-in-time certificates versus continuous AI assurance
A certificate carries a date. A model carries a version, and the version changes.
This is the structural tension in AI assurance that traditional compliance never had to face. A financial control tested in March behaves the same way in September. A model retrained on three months of fresh data may not. Distribution shift, concept drift, an updated foundation model underneath your application, a changed prompt, a new data source: any of these can invalidate a test result without anyone filing a change request.
The EU AI Act’s answer is post-market monitoring, a standing obligation to track how the system performs in the field and to act on what that surfaces. The concept of substantial modification does similar work, defining when a change is large enough to require reassessment. Both point in the same direction: AI assurance is a continuous function, and an annual audit is a snapshot that was already stale by the time it was signed.
Practically, this means instrumenting the system so that evidence regenerates on a schedule rather than on a project. Performance metrics on a recurring cadence, drift detection with defined thresholds, and a route from a detected anomaly to a documented decision. Incident reporting closes the loop by turning failures into recorded, traceable events rather than folklore.
Building an AI assurance operating model
The unit of AI assurance is the evidence artefact, and a workable operating model is mostly a question of keeping five fields attached to every one of them: the claim it supports, the control it satisfies, the artefact itself, the owner, and the date it was produced. If any field is missing, the artefact will not survive scrutiny.
Ownership follows the three-lines model reasonably well. The first line, the teams building and running AI systems, produces the evidence. The second line, risk and compliance, defines what evidence is required and checks it exists. The third line, internal audit, independently tests whether the first two are doing their jobs. The Institute of Internal Auditors positions internal audit explicitly as an assurance provider over AI, validating the internal controls used to manage AI risk.
A workable minimum artefact set covers the risk register, test and evaluation results tied to model versions, data documentation covering provenance and known limitations, human oversight records showing that reviewers actually reviewed, a change log, and an incident log. The Alan Turing Institute’s Safety Self-Assessment and Risk Management Template, part of its publicly licensed AI Ethics and Governance in Practice series, is a credible free starting point. It organises safety around performance, reliability, security and robustness, which maps closely onto the accuracy, robustness and cybersecurity duties in Article 15.
The test of the model is simple. Pick a claim your organisation makes about an AI system, then try to trace it to a dated artefact with an owner. Most organisations discover the trace breaks within two steps, and that gap is what an AI compliance programme exists to close.
FAQ
What is AI assurance?
AI assurance is the process of measuring, evaluating and communicating whether an AI system is trustworthy. Measuring gathers data on how the system behaves, evaluating judges that data against a recognised benchmark, and communicating puts the result in front of the people who need to act on it. The output is evidence that a claim about the system can be checked by someone other than the team that built it.
Is AI assurance the same as an AI audit?
No. An audit is one mechanism within assurance, a structured examination against defined criteria that produces a report with findings. AI assurance is the broader process that also includes risk and impact assessment, performance testing, monitoring and the communication of results. You can run a continuous AI assurance programme with occasional audits inside it, but an audit on its own is a point-in-time snapshot rather than an assurance capability.
Does the EU AI Act require third-party AI assurance?
Mostly no. Article 43 routes high-risk systems in Annex III points 2 to 8 through internal control under Annex VI, with no notified body involved. Only Annex III point 1 systems, covering biometrics, give the provider a choice of using a notified body, with a narrow exception where a market surveillance authority acts as one. In practice this makes self-assessment the norm, which raises rather than lowers the bar on internal evidence quality.
Which standards support AI assurance?
ISO/IEC 42001 defines the AI management system. ISO/IEC 42006:2025 sets requirements for the bodies that audit and certify against it. The NIST AI Risk Management Framework supplies a widely used measurement vocabulary. Under Article 40 of the EU AI Act, harmonised standards published in the Official Journal will confer a presumption of conformity, though the relevant European drafts are not yet published as harmonised ENs.
Who can perform AI assurance?
Internal teams, customers, and independent providers all can, and the label matters. First-party assurance is self-assessment, informed but conflicted. Second-party assurance is carried out by a commercially interested party such as a procuring customer. Third-party assurance is independent and carries the most weight externally. Because the provider market is still consolidating, verify credentials and methodology directly rather than relying on a certification logo.
How often should AI assurance be repeated?
As often as the system changes, which for most machine learning systems means continuously rather than annually. Tie evidence regeneration to triggers: a model retrain, a change in the underlying foundation model, a new data source, a drift threshold breach, or a reported incident. Calendar-based reassessment alone will leave you defending a certificate that describes a version of the system no longer in production.
Conclusion
AI assurance is less a project than a habit: producing evidence continuously so that any claim about a system can be substantiated on the day someone asks. The organisations that will handle the next few years comfortably are not the ones with the thickest policy documents. They are the ones that can trace a claim to a dated artefact, name its owner, and show when it was last re-validated.
The deferred EU deadlines, December 2027 for standalone high-risk systems and August 2028 for embedded products, are build time. The obligations did not shrink, and the self-assessment route means the quality of your internal evidence is the only real control. Start by picking one high-risk system and tracing a single claim end to end. The gaps you find will tell you what your assurance programme actually needs.