Verification asks whether a system was built to its specification. Validation asks whether it meets its user needs and intended use. A device can be fully verified and still fail validation if its requirements missed user needs, and a model adds causes of its own. Its behaviour depends heavily on its training data, the correct output for an individual input is often impossible to define in advance, and there is high uncertainty about how it will behave on inputs nobody tested. Validation of AI in a regulated setting has to carry on after release instead of ending at go-live.
Validation versus verification in the regulators’ own words
The engineering definitions come from IEEE-STD-610. Verification evaluates whether the products of a development phase satisfy the conditions set at the start of that phase. Validation evaluates whether the software satisfies its specified requirements, during or at the end of development. Put informally, verification confirms you “built it right” against the developers’ plans, and validation confirms you “built the right thing” for the stakeholders’ intended use.
The regulatory texts say the same thing in their own terms:
| Verification | Validation | |
|---|---|---|
| Question | Did we build it to specification? | Did we build what the intended use needs? |
| EU GMP Annex 11 draft revision | Confirmation, through objective evidence, that specified requirements have been fulfilled | Proving that a process leads to the expected results; for a computerised system, demonstrating fitness for its purpose |
| FDA 21 CFR 820 / ISO 13485:2016 (medical-device design controls) | Objective evidence that specified requirements have been fulfilled | Objective evidence that the requirements for a specific intended use can be consistently fulfilled |
| ISO 9000:2015, as quoted by NIST | (NIST quotes only the validation definition) | Objective evidence that the requirements for a specific intended use or application have been fulfilled |
| What it is checked against | The previous phase’s outputs: requirement, design, code | User needs and intended uses, in the real or simulated use environment |
FDA’s General Principles of Software Validation points out that the Quality System regulation treats the two as separate and distinct terms, whereas many software engineering textbooks use them interchangeably or merge them into “VV&T”. A test report showing that every requirement passed is verification evidence. On its own it does not show fitness for intended use.
AI adds a vocabulary trap of its own. In machine learning, “validation” has an established meaning of its own: ML model validation. That meaning is distinct from validation in the V&V sense, and it produces a flood of irrelevant results when the two are searched together. The EU’s draft Annex 22 separates the data used for “development, training or validation of the model” from independent test data. When someone on a project says a model “has been validated”, ask which of the two meanings they intend.
Where IQ, OQ and PQ sit between the two
EU GMP Annex 15 defines each of them as documented verification. Installation Qualification verifies that the system as installed complies with the approved design. Operational Qualification verifies that it performs as intended across its anticipated operating ranges. Performance Qualification verifies that it performs effectively and reproducibly against the approved process and specification. PIC/S guidance maps them onto the requirement layers: OQ is user acceptance testing against the functional specification, and PQ tests the system in its operating environment against the User Requirements Specification. PIC/S tells inspectors to look for qualification testing linked to acceptance criteria, PQ versus URS.
PIC/S also warns that for critical or complex systems, the verification testing done at the IQ, OQ and PQ stages provides “only a limited level of assurance” that the system reliably does what it claims.
The 2011 Annex 11 requires that the application be validated and the IT infrastructure qualified, and it asks manufacturers to justify their protocols and acceptance criteria from their own risk assessment. The draft revision points to Annex 15’s general principles. FDA’s guidance explicitly recommends no specific life cycle model or technique. We read these texts together as permission to fit the structure to the risk. TechnoLynx’s assessment is that running the full IQ/OQ/PQ protocol set on every AI system by default is, in many cases, a misallocation of months of engineering and quality effort. GAMP 5, revised as its Second Edition in 2022, exists to decide how much validation effort a system’s risk to product quality and patients justifies. Validation is a lifecycle from requirements to decommissioning, covered in our computer system validation lifecycle and risk-based validation with GAMP 5 articles.
Why a fully verified AI model can still fail validation
A device can be completely verified and still fail validation if its requirements were incomplete, incorrect or did not capture user needs. AI adds causes of its own that are characteristic of the technology.
SEBoK’s guidance on systems with AI elements keeps the high-level V&V definitions unchanged and says that AI needs approaches beyond those used for conventional systems. Engineers surveyed by Ishikawa and Yoshioka (2019) named the attributes that break conventional checking:
- No oracle. It is hard or impossible to state the correct output for each input, so the expected result a test case depends on is missing.
- Imperfection. An AI system cannot be 100% accurate.
- Untested inputs. Behaviour on inputs outside the test set is highly uncertain, and slight input changes can cause radical output changes.
- Data dependency. Behaviour depends heavily on the training data, and no guarantee says when a dataset is “large enough” to cover the operational space.
A further failure sits one level up. A systematic review of AI validation methods found that validating only the ML model may be inadequate, and that the question to ask is what is being validated: the model or the complete system it runs in. Conventional testing also has a ceiling. Testing every function and every line of code still does not make a program 100% correct. NIST adds that risks measured in a laboratory before deployment may differ from those that emerge in real operational settings. Taken together, these points mean that a passed test suite is a statement about the code and the test data. Validation is a statement about the intended use the model will actually serve.
Which controls answer drift, weak training data and confident wrong output in a model?
The risk-based controls map onto AI risks through two prior decisions: a precise intended use, and a risk level set from it. The continuous-validation framework starts every AI validation with an intended use statement covering what the system does, who uses it, what decisions it informs and what a wrong output would cause. The risk level set from that statement then defines both the validation extent and the monitoring requirements for the system’s whole life. The same architecture can be negligible risk in document classification and high risk when it informs batch disposition.
| AI-specific risk | How it shows up | Risk-based control that addresses it |
|---|---|---|
| Data, concept and performance drift | Production inputs diverge from the validated baseline, the input-output relationship shifts, or accuracy declines over time | Drift metrics with thresholds, review frequencies and escalation procedures set before deployment; a tiered response from logging to targeted tests to revalidation or pausing the system |
| Training-data quality and coverage | Behaviour reflects gaps or bias in the data; the operational space is not covered | Data validation as its own V&V activity: file, import, domain, transformation, aggregation and business validation; a characterised input sample space including rare variations and biased inputs |
| Leakage between training and test | Test results overstate performance on new data | Technical or procedural controls that keep test data out of development, training and ML validation; stratified test data covering all subgroups |
| Inputs outside the design scope | The model handles cases it was never trained for | Input restrictions that limit what the system handles autonomously; monitoring whether production inputs stay within the sample space |
| Confident wrong output with no oracle | Plausible output that no individual test could have flagged | Metamorphic testing, which addresses the oracle problem; output restrictions against known-dangerous actions; human intervention where the system cannot detect its own errors |
| Unclear acceptance bar | Performance is argued after the results are in | Acceptance criteria defined by a process subject matter expert and approved before testing begins, which may differ by subgroup |
Hallucination needs a plain caveat. No cited source names hallucination; the nearest are the oracle and imperfection problems. FDA’s Computer Software Assurance guidance lets additional controls elsewhere in the quality system reduce the impact of a software failure, and therefore the assurance rigour it needs.
One question this mapping depends on belongs to another page. Deciding whether a system falls under GxP at all is covered under GxP systems classification.
Validation after release: drift, triggers and change control
A model that was accurate when validated can lose production AI reliability as the world it describes changes. For AI, then, the question is not only what to validate but when. The systematic review found initial validation emphasised over continuous validation in the literature. Only 14 of the 90 papers it analysed described any continuous validation method. The same gap appears outside research. Dolin et al. (2025) cite a review finding that only 9% of FDA-registered AI-based healthcare tools include a post-deployment surveillance plan.
Annex 11’s draft revision requires systems to be validated before use and kept in a validated state throughout their lifecycle. For AI, the guidance describes these parts of continuous validation, covered in validating AI/ML under GAMP 5:
- Monitoring. Performance metrics and input drift are monitored regularly, as the Annex 22 draft expects, with metrics defined for drift in the input data. Failure monitors alert when the system or its components behave suspiciously.
- Predefined triggers. ISPE calls the belief that any drift triggers full revalidation “one of the most common misconceptions”. Minor drift within limits is logged, moderate drift gets targeted tests, and major drift or retraining means revalidating the affected scope or pausing the system.
- Change control. The model, the system it runs in and the process it supports go under change control before deployment. Any decision not to retest after a change has to be fully justified.
- Traceable decisions. Decisions to revalidate or not have to be traceable, with supporting evidence retained in an audit trail.
Measuring performance degradation needs post-deployment labels, and those are often delayed, costly or unavailable. Label-free tests can compare input distributions directly, so input drift can be checked while labels are still pending.
FDA’s software validation guidance already states the principle: whenever software changes, its validation status has to be re-established. The process side of that principle, change control and periodic review after go-live, is covered in our GxP validation explainer.
The V&V evidence engineering hands to quality
A vendor or IT department supplies evidence, and the regulated user remains fully accountable. Annex 11’s draft revision lets a vendor, service provider or IT department supply validation documentation. The regulated user remains fully accountable, has to review and authorise it, and has to decide whether parts should be repeated. FDA’s CSA guidance was written for medical device production and quality system software. For the record, FDA recommends:
- the intended use of the feature, function or operation;
- the result of the risk-based analysis;
- a description of the testing conducted, and the issues found (deviations, defects, failures);
- a conclusion declaring the software acceptable for its intended use, with the resolution of any issues.
FDA’s worked example also records who performed the testing and when.
For a model, Annex 22’s draft and NIST’s framework add three items. First, the acceptance criteria, approved before testing began. Second, a description of the test set showing that it represents the conditions of expected use, together with the test methodology. Third, the documented limits on how far the results generalise beyond the conditions the model was developed under. Annex 11’s draft expects the evidence in the form of executed test scripts and, where relevant, screen captures. For model testing, our view is that the equivalent is a versioned, re-runnable evaluation tied to the exact model and dataset hashes.
NIST’s AI Risk Management Framework describes separating the people who build models from the people who verify and validate them as best practice. FDA’s software validation guidance notes that self-validation is extremely difficult. It favours independent evaluation for higher-risk applications, by a third party or by internal staff not involved in the design.
What a validated state means for a model
NIST’s framework expects the limits of generalisability to be documented. It also expects clear responsibility for the mechanisms that supersede, disengage or deactivate a system whose outcomes stop matching its intended use. The draft Annex 22 asks all relevant parties to cooperate on AI models used in GMP. Annex 15 requires computerised systems to be validated under Annex 11. Until the final text settles the details, the test of a GxP AI validation file is a practical one: whether it can show, on any given day, why the team still believes the model is fit for its intended use, and what they would do the day that stops being true.
