ISO 42001 Annex A.6.2.4: Define AI Verification and Validation Criteria

What control A.6.2.4 requires in practice

Control A.6.2.4 asks the organisation to define and record the verification and validation measures for an AI system and to set the criteria for using them. Verification asks whether the system was built to specification; validation asks whether it is suitable for its intended use. Annex B, as guidance, includes testing methods and tools, selection of test data that represents the intended domain of use and release criteria. It also suggests evaluation criteria covering risks to individuals, groups and society, reliability and safety requirements including acceptable error rates, responsible-use objectives, operational factors such as data quality and their acceptable ranges, whether the people affected can interpret outputs and how often evaluation is repeated. It addresses what to do when criteria cannot be met, including reconsidering the intended use, and recording mechanisms for poor performance caused by known factors.

Choose criteria before interpreting results

Annex B.6.2.4 connects evaluation with testing methods, representative data, release criteria, responsible objectives and operating factors. It also considers whether people can interpret outputs appropriately and what happens when criteria are not met. The guidance must be considered, with tailored implementation allowed under B.1.

As an original planning method, state the claim an evaluation is intended to support. Identify which conditions and populations the evidence needs to represent and what a failure would mean. This makes the result more useful than collecting an attractive performance percentage without a defined decision.

Why AI verification and validation criteria matter

A strong test result is only reassuring if it answers the question that matters to the business. Testing that favours easy cases, unrepresentative data or the wrong measure produces confidence that evaporates in operation. Defining criteria in advance prevents results from being interpreted to suit the outcome and gives management a clear basis for a release decision. It also protects the organisation when a client asks what the system was tested against and why that was sufficient. Where a criterion cannot be met, the guidance encourages a considered response, such as narrowing the use, instead of releasing quietly. This discipline reduces production incidents, complaints and costly retrofits.

How to implement control A.6.2.4

State what each evaluation is meant to prove before looking at any results. Where you rely on a supplier's evaluation, ask what it covered and decide whether your own conditions of use need further checks before you accept it.

1. For each important requirement or risk, write the claim the evaluation should support.
2. Choose test methods and tools, and explain why they suit the task and the risks involved.
3. Select test data that represents the conditions, users and edge cases of intended use, and record how and by whom it was chosen.
4. Set acceptance criteria, including error tolerances and the operating ranges within which they apply.
5. Include checks on whether the people who rely on outputs can interpret them properly.
6. Decide what happens when criteria are missed: redesign, restrict use or accept with authorised conditions.
7. Define when evaluation repeats, based on risk and on the findings of impact assessment, and keep the results.

Illustrative IT example: routine questions dominate testing

Illustrative construction example: users misunderstand a correct output

A construction planning tool produces a forecast with uncertainty information. Technical testing confirms that the information is displayed as designed. Project managers nevertheless interpret the forecast as a firm commitment and omit the qualification when communicating with subcontractors.

Evaluation needs to consider how relevant people interpret and act on the output, not only whether the display works. Suitable user evidence can reveal the gap. The response may involve the interface, instructions, training or intended use; the team should investigate rather than assume one solution is sufficient.

Examine the system as well as its components

A component can meet a criterion while the combined workflow fails. Data preparation, interfaces and human review can change the practical result. Connect evaluation with design documentation so important assumptions and interfaces are understood.

Choose measures suitable to the task and consequence. There is no universal minimum accuracy percentage in this control. Different uses may require different operating ranges and evidence. Explain acceptable limitations without using them to disguise failure against the intended purpose.

Respond to unmet criteria

If the system cannot meet the documented evaluation criteria, the guidance points toward reconsidering or managing deficiencies in use, requirements and impacts. A failed test should lead to a reasoned decision, not repeated testing until a favourable sample appears.

Possible responses include changing the design, narrowing the use, improving evidence or addressing a relevant control. These are options to evaluate. Management approval does not make an unsupported technical claim true, and a revised criterion needs a defensible basis.

Evidence and common weaknesses