AI assurance is the process of measuring, evaluating and communicating whether an AI system can be trusted. It uses specific techniques, such as risk assessment, impact assessment, bias audit and conformity assessment, applied against a standard. This guide is for organisations that use AI rather than build it: what assurance involves, who does it, and where to start.
That definition is the UK government's, from the Department for Science, Innovation and Technology (opens in a new tab) in February 2024, and it is worth reading twice. Measure, evaluate, communicate. Nothing in it says “certify”, nothing says “policy”, and nothing says “the vendor promised”. Assurance is something you do to an AI system, and then something you can show a Board, a customer or a regulator. If your organisation has adopted AI tools and has never done any of the three, the honest position is that you have AI, and you have no assurance about it. The place most organisations start is an AI risk assessment (opens in a new tab), and the rest of this guide explains why.
What AI Assurance Means
Assurance is an old idea applied to a new subject. The DSIT introduction (opens in a new tab) puts it this way: assurance is the process of measuring, evaluating and communicating something about a system or process, documentation, a product or an organisation, and in the case of AI it measures, evaluates and communicates the trustworthiness of AI systems. Accountants have done it to financial statements for as long as there have been auditors. Cyber security has done it to networks for decades, which is most of what a penetration test or an ISO 27001 audit is. AI assurance is the same discipline pointed at models, the data they learn from, the decisions they make and the people on the receiving end.
The word that does the work is “trustworthiness”. It is not the same as “accuracy”, and it is not the same as “secure”. The UK's framework defines it through five cross-sectoral principles, set out in the same DSIT document: safety, security and robustness; appropriate transparency and explainability; fairness; accountability and governance; contestability and redress. An AI system can be accurate and unfair. It can be secure and impossible to contest. Assurance is how you find out which of the five you have and which you are missing.
The Techniques of AI Assurance
Six techniques do most of the work, and they are not interchangeable. DSIT's introduction lists them, and the table below is the essential vocabulary for the rest of this guide.
| Technique | What it asks | When it is used |
|---|---|---|
| Risk assessment | What could go wrong with this AI, including bias, privacy and reputational harm | Before deployment and on material change; the entry point for most organisations |
| Impact assessment | What wider effects the system has on the environment, equality, human rights and data protection | Alongside the risk assessment for systems affecting people |
| Bias audit | Whether the data going in, or the decisions coming out, are unfairly skewed | Recruitment, lending, pricing, any decision about individuals |
| Compliance audit | Whether the system and the organisation follow internal policy, external regulation and the law | Periodically, and on request from a customer or regulator |
| Conformity assessment | Whether the product or system meets a specified requirement, before it goes to market | Products and systems sold or deployed at scale |
| Formal verification | Whether the system provably satisfies a requirement, using mathematical methods | Narrow, high-consequence systems; rare in general business use |
Source for the six and their descriptions: DSIT, Introduction to AI assurance (opens in a new tab), 12 February 2024 (he “when it is used” column is a writer's reading, not DSIT's).
The one line from that document that should be on a slide in every boardroom is this: without standards we have advice, not assurance. A technique on its own produces an opinion. A technique applied against a standard, whether that is ISO/IEC 42001, a sector regulation or a documented internal policy, produces evidence. That distinction is the whole difference between AI assurance and AI consultancy, and it is the reason the government's programme spends so much of its effort on standards.
Who Does AI Assurance
Assurance is done by three kinds of party, and the third is the one that carries weight. DSIT's roadmap (opens in a new tab) of September 2025 names them: firms developing AI systems, firms deploying AI systems, and third-party AI assurance providers, who it says have a particularly important role in independently verifying the quality and trustworthiness of AI systems.
If you build AI, you do first-party assurance on your own product. If you buy and deploy AI, you do second-party assurance on your supplier and on how you use the thing. Third-party assurance is when someone with no stake in the answer checks either of those. It is the same structure as financial audit: the finance team prepares the accounts, the Board reviews them, and an auditor who does not work for either signs them off. Nobody accepts the first two as a substitute for the third, and the same is becoming true of AI.
The UK is building the third-party layer now rather than assuming it exists. The roadmap's actions include a consortium developing a voluntary professional code of ethics, a skills and competencies framework for AI assurance, and three pathways it is exploring to raise quality: professionalisation, certification of assurance processes, and accreditation. It also records that UKAS is piloting accreditation for organisations providing certification of AI management systems against ISO/IEC 42001 (opens in a new tab). How ISO/IEC 42001 relates to the ISO 27001 certificate most organisations already hold is its own subject (opens in a new tab).
How to Get Started With AI Assurance
Start with the AI you already have, not the AI you might buy. Most organisations reading this are deployers, not developers, and the first three steps are the same for all of them.
The first is an inventory. You cannot assure what you cannot list, and the list is longer than the IT department thinks, because the tools arrived through browser sign-ups rather than procurement. Finding the AI nobody approved (opens in a new tab) is a job in itself.
The second is a risk assessment, in the DSIT sense of the word: for each AI use, what could go wrong, for whom, and how badly. 2-sec's AI risk assessment (opens in a new tab) covers data access, integrations, supplier dependencies, oversight of outputs and governance controls, and ends in a prioritised list of what to fix. That list is the first piece of assurance evidence most organisations will ever hold. It is also the point at which the exercise stops being abstract, because the register will contain at least one tool that has been given access it should never have had.
The third is a policy with a working system behind it. An AI policy (opens in a new tab) that nobody can evidence is advice, in DSIT's sense. A policy that sets out who may use what, for which purposes, with what checks, and that produces records when it is followed, is the start of a management system. That is the shape the government's free AI Management Essentials (opens in a new tab) self-assessment tool takes: ten sections across internal processes, managing risks and communication, aimed in particular at start-ups and SMEs that develop or use AI.
After those three, assurance becomes specific to what the AI does. A recruitment tool needs a bias audit. A customer-facing model needs testing for prompt injection (opens in a new tab) and for what it will say under pressure. A system that makes decisions about individuals needs an impact assessment and a route for people to contest the outcome. None of that is exotic. It is the six techniques in the table, chosen to fit the risk.
How AI Assurance Builds on What You Already Have
An organisation holding ISO 27001 or Cyber Essentials already owns a third of the evidence, and does not know it. The asset register, the supplier due diligence, the access control records and the incident process that an ISMS produces are exactly the artefacts an AI risk assessment asks for first. What is missing is the AI-specific layer on top: which of those assets are models or model-backed tools, what data they were given, what decisions they influence, and who is accountable (opens in a new tab) for the answers. That is a gap assessment, not a new programme, and it is the reason ISO/IEC 42001 (opens in a new tab) was written to sit on the same structure as ISO 27001 rather than beside it.
The trap is assuming the existing controls have been applied to the AI, when they have usually been applied around it. A supplier questionnaire that was never sent to the chatbot vendor. An access review that lists the shared drive but not the assistant connected to it. Same controls, different asset, no record. Closing that is most of what getting started looks like for a deployer, and it is cheaper than anything the assurance market will sell you afterwards.
What to Ask a Third-Party AI Assurance Provider
Ask what standard the work is applied against, and what evidence it produces, before anything else. The government's roadmap is explicit that the third-party market does not yet have a settled profession behind it: a voluntary code of ethics, a skills and competencies framework and the accreditation pathways are all listed as things DSIT is building, not things that exist. Until they do, the buyer has to do the checking.
Three questions separate assurance from advice. Which of the six techniques is being applied, and against which standard, regulation or policy. What the deliverable is, and whether it would satisfy a customer's auditor or a regulator rather than only a Board. And who is independent of whom: a provider that also sells you the AI, or the controls around it, is doing first-party work whatever the invoice says. Anyone who cannot answer all three plainly is selling a document.
Common Mistakes in AI Assurance
The mistakes are predictable, and most of them come from treating one piece of the process as the whole. Five come up repeatedly.
Treating a Policy as Assurance
A policy is a statement of intent, and assurance is evidence that the intent is met. The two are routinely confused because a policy is the easiest artefact to produce and the easiest to show a customer. It measures nothing, evaluates nothing, and communicates only that someone wrote a document. Keep the policy. Do not mistake it for the audit.
Treating the Supplier's Assurance as Your Own
Your AI vendor's certificate covers their system, not your use of it. A model that has been assessed for bias on the vendor's data has not been assessed on yours, and a tool that is secure in the vendor's reference architecture is not secure once your staff have connected it to a shared drive. Second-party assurance exists precisely because first-party assurance stops at the vendor's front door.
Treating Security Testing as the Whole Job
Security is one of the five principles, not all five. A penetration test of an AI application tells you whether it can be broken into or manipulated. It tells you nothing about whether its decisions are fair, whether they can be explained, or whether anyone can appeal them. Cyber security firms, this one included, have to be honest that a secure model can still be an unacceptable one.
Waiting for a Law to Require It
There is no single UK AI statute to wait for, and the assurance market is being built without one. The pressure arrives from customers, insurers, public sector procurement and sector regulators, and it arrives as a question in a tender rather than a fine. The organisations that can answer it are the ones that started before they were asked.
Confusing Certification With Assurance
Certification is one output of assurance, not a synonym for it. ISO's own explainer (opens in a new tab) states that certification for ISO/IEC 42001 is voluntary and that ISO does not certify organisations; independent certification bodies do, and since July 2025 ISO/IEC 42006 (opens in a new tab) sets the requirements those bodies must meet. A certificate says a management system met a standard on the day of the audit. Assurance is what the management system does on the other 364.
Where AI Assurance Is Going in the UK
The UK government has decided to treat AI assurance as an industry to grow, and the numbers say it has already started. DSIT's market study (opens in a new tab) of November 2024 estimated 524 firms supplying AI assurance goods and services in the UK, 84 of them UK-based specialists, generating an estimated £1.01 billion and employing an estimated 12,572 people, with the specialised market having the potential to reach £6.53 billion by 2035.
The same study was frank about the obstacles: limited understanding of AI assurance on the demand side, a lack of quality infrastructure on the supply side, and differing frameworks and terminology across sectors and jurisdictions. Its four responses were an AI assurance platform as a one-stop shop, AI Management Essentials as a free baseline, the roadmap to trusted third-party assurance, and a terminology tool for responsible AI. The roadmap, when it came in September 2025, added £11 million of funding for the development of innovative AI assurance mechanisms.
Read those two documents together and the direction is not subtle. Standards first, then a profession, then accreditation of the people applying the standards. It is the same arc information security went through, compressed into a few years, and an organisation that already lives inside ISO 27001 or Cyber Essentials will recognise every step of it.
FAQs About AI Assurance
What Is AI Assurance in Simple Terms?
AI assurance is checking that an AI system can be trusted, and being able to show the evidence. In the UK government's definition it means measuring, evaluating and communicating the trustworthiness of AI systems, using techniques such as risk assessment, bias audit and compliance audit, applied against a standard.
Is AI Assurance Mandatory in the UK?
Not by a single AI law. Obligations arrive through existing regulation, sector regulators, customer contracts and procurement, and the government's programme is built on voluntary standards, a free self-assessment tool and a third-party assurance market rather than a statutory requirement.
Is AI Assurance the Same as an AI Audit?
No. An audit is one assurance technique among several. DSIT lists compliance audit and bias audit as two specific techniques; risk assessment, impact assessment, conformity assessment and formal verification are others. “AI audit” is often used loosely to mean any of them, which is one reason the government commissioned a terminology tool.
Do I Need ISO 42001 to Do AI Assurance?
No. ISO/IEC 42001 is a standard for an AI management system, and certification against it is voluntary. It gives assurance work a recognised standard to be applied against, which is what turns advice into evidence, but the techniques in this guide can be applied against internal policy or sector regulation without it.
What AI Assurance Looks Like When It Is Working
Working assurance is boring, and that is the point. There is a list of the AI in use. Each item on it has been assessed for what could go wrong, and someone owns the answer. The policy matches what people actually do, and produces records when they do it. The high-risk uses have been tested by someone who does not work for the vendor, and the results have been read by someone who does not work in IT. When a customer, an insurer or a regulator asks, the evidence exists before the question does.
Most of what is sold as AI assurance is a document. What actually counts is the evidence behind it. If you would like a straight view of how much of that evidence your organisation holds today, feel free to get in touch (opens in a new tab). The first conversation is short, and it usually ends with a list rather than a proposal.
