What AI assurance means

AI assurance is the work of measuring, evaluating, and communicating evidence about the trustworthiness of an AI system. That includes whether the system performs as intended, what limitations and risks it has, and how those risks are being managed.

The phrase describes a process, not a single test or a promise that a system cannot fail. A team makes a claim about an AI system, chooses evidence that can support that claim, evaluates the result, and records what remains uncertain. The claim might be about accuracy, safety, security, fairness, reliability, human oversight, or continued use after a change.

AI assurance asks whether the evidence is strong enough to support the use of the system, given its purpose and risks.

Definition informed by the UK Department for Science, Innovation and Technology's Introduction to AI Assurance.

That leads to practical questions:

  • Does the system work as expected for the people who will use it?
  • Which inputs or situations cause problems?
  • Are the important risks understood?
  • Do the safeguards and human review steps work?
  • What happens after a model, prompt, data source, or integration changes?
  • What evidence supports continued use?

Why organizations need AI assurance

AI systems can introduce risks that do not appear in the same form in conventional software. A language model may produce a confident but unsupported answer. A model may behave differently for different groups. A retrieval system may bring in the wrong source. An agent may reach a correct answer through an unacceptable sequence of tool calls.

Depending on the system, teams may need to examine non-deterministic output, hallucinations, bias, data quality, drift, prompt injection, weak explanations, or long agent workflows. No AI system has every one of these risks. The point is to identify the risks that follow from the intended use.

A meeting summarizer and a system used in healthcare, lending, employment, cybersecurity, or a physical process should not receive identical review. The possible harm, affected people, data, level of human control, and ability to recover all change the assurance work.

The NIST AI Risk Management Framework provides a way to think about risk across the AI lifecycle. Assurance turns that risk discussion into evidence that people can inspect and act on.

Where software testing fits

Software testing is one of the main contributors to AI assurance because it turns expectations and risks into observable conditions. Testers already work with requirements analysis, risk-based testing, test design, negative testing, boundary testing, regression testing, test reporting, and evidence evaluation.

Those skills still apply when AI is part of the system. The questions change in useful ways. More than one response may be acceptable. Model behavior may vary. Different user groups may receive different results. A system can return a useful answer while citing evidence it was not allowed to use. An AI agent can reach the right outcome through a route that violates a permission or approval rule.

AI assurance may require several forms of evaluation. NIST's ARIA evaluation guidance describes a combination of Model Testing, Red Teaming, and User Testing. Each answers a different kind of question. Model tests can examine performance under defined conditions. Red teaming can look for harmful or unexpected behavior. User testing can reveal how the system behaves in real use and how people interpret its output.

For a practical starting point, see What Is AI Testing? and How to Test LLM Applications. The page on hallucination testing shows how one specific AI risk becomes a set of testable questions.

AI assurance and AI governance

Governance and assurance are related, but they do different work. Governance sets policies, responsibilities, limits, and decision processes around AI. Assurance supplies evidence about whether systems and controls meet those expectations.

Imagine that governance requires human review before a high-impact AI decision is accepted. Assurance asks whether the review step happens, whether reviewers see the information they need, whether they catch important errors, and whether the records show what happened. The policy is the expectation. The review records and test results are part of the evidence.

This is why governance work benefits from people who understand how to test AI systems. Read Why AI Governance Needs People Who Understand AI Assurance for the organizational side of that relationship.

What counts as assurance evidence?

Good evidence supports a specific claim. If a team says the system is accurate enough for its intended use, the evidence should show how accuracy was measured, on which data, under which conditions, and where the result does not hold. If the team says a guardrail works, the evidence should include attempts to bypass it and the system's response.

If the team says human review reduces risk, it should be able to show whether reviewers receive useful information and catch the errors that matter. A policy statement alone cannot answer that question.

Evaluation evidenceRepeatable test results, acceptance criteria, known failure modes, red-team findings, and user-testing results.
Control evidenceSecurity checks, access rules, human-review results, approvals, incident records, and change records.
Lifecycle evidenceRegression results, production monitoring, reevaluation after changes, and analysis of new failure patterns.
Decision evidenceKnown limitations, the intended scope, accepted residual risks, and the reasoning behind continued use.

This is not a universal checklist. Evidence is useful when it matches the claim and the risk. NIST's TEVV-Athlon work reflects the need to evaluate different kinds of AI systems, including machine learning systems, LLMs, multimodal systems, and agents.

How much assurance is enough?

Assurance should be proportionate to risk. A low-risk internal use case may need a smaller set of checks than a system whose failure could affect health, income, employment, privacy, safety, or access to an important service.

Start by asking what happens when the system is wrong, who is affected, how easy the failure is to detect, and how difficult recovery will be. Add the system's data sensitivity, reach, external interfaces, level of autonomy, and human approval points. Those answers help a team choose evidence that fits the decision.

The UK guidance on AI assurance makes the same point. Low-risk use cases may rely on a smaller range of techniques, while higher-risk use cases may need a stronger combination of techniques. That is familiar territory for testers. Risk-based testing has always meant spending more effort where failure matters more.

AI assurance continues after release

Evidence ages. Models change. Prompts change. Retrieval sources change. APIs change. Providers update models. Users find situations the original team did not test. Production data exposes behavior that was not visible in a controlled evaluation.

Assurance therefore continues after release through regression testing, monitoring, incident analysis, and reevaluation after meaningful changes. A system may need new tests when its model version changes, when a policy source is updated, when a tool permission expands, or when real use reveals a new failure mode.

The AI RMF treats risk management as a lifecycle activity rather than a launch gate. The work of testing and evaluating AI systems also continues as systems and their contexts change. A useful assurance record explains what was tested, what was observed, what changed, and what the team decided to do about it.

Who works on AI assurance?

AI assurance is shared work. Depending on the system, it can involve testing and QA, engineering, cybersecurity, privacy, risk, legal, governance, product, domain experts, and management. Testers do not own every part of assurance, and a testing credential does not replace expertise in another discipline.

Testers bring a useful way of working. They turn requirements into measurable conditions, look for failure paths, compare expected and actual behavior, retest after changes, document evidence, and challenge assumptions. They can also help teams distinguish a result that looks plausible from a result that supports the claim being made.

That role matters across AI systems. It includes the software around a model, the model's behavior, the data and retrieval layer, the safeguards, the human workflow, and the production signals that show what happens after release. The recent articles on AI agent testing gaps, misleading evidence for agents, and testing agent guardrails show why the path from model output to real-world effect needs attention.

Where AI Assurance Pro fits

ASTQB AI Assurance Pro is a testing-focused path within the broader AI assurance field. It brings together three certifications: ISTQB Foundation Level, ISTQB AI Testing, and ISTQB Testing with Generative AI.

Those three areas cover software testing fundamentals, testing AI-based systems, and using generative AI within software testing while understanding its associated risks. This gives software quality professionals a defined foundation for contributing to AI assurance work.

The designation does not cover every part of AI assurance. It does not replace legal, privacy, security, governance, management, product, or domain expertise. It also does not prove that a person can prevent every AI failure. It is evidence of assessed knowledge across a specific testing-focused body of knowledge.

To see the designation's structure and requirements, read What Is ASTQB AI Assurance Pro?. For a broader view of the three exams, see The Three Required Certifications.