Validating AI for GxP in Life Sciences: Why the Old Test Script Doesn’t Fit
How to think about IQ/OQ/PQ, model performance testing, and human-in-the-loop controls when the software you’re validating doesn’t give the same answer twice.
Life sciences and medtech companies are starting to ask their AI vendors a question that traditional computer system validation was never built to answer: how do you prove software works when it isn’t supposed to behave the same way every time? That question comes up constantly across two use cases we keep seeing:
Both are human-in-the-loop (HITL) by design, because GxP and quality system regulations demand defensibility, and because the real problem in each case is coverage, not speed. Most of this data is never fully reviewed today, not just reviewed slowly.
The designs are sound. The validation plan is where teams get stuck, because the standard playbook, a fixed set of scripted test cases each with one expected output, assumes deterministic software. A model that scores anomalies or retrieves and summarizes complaint records isn’t deterministic. It’s probabilistic, and it changes as it’s retrained. Here’s how to adapt.
Split the system into two validation tracks
The instinct to validate the AI system as one monolithic thing is the first thing to resist. Most of what you’re actually deploying is ordinary, deterministic software wrapped around one non-deterministic component.
The deterministic shell includes data ingestion, the workflow that routes every flagged item or query result to a human reviewer, the control that blocks auto-resolution, audit trail capture, e-signatures, and access permissions. This behaves the same way on every run, so it can be validated with conventional scripted test cases, the IQ/OQ/PQ approach your quality team already knows, or FDA’s more recent risk-based Computer Software Assurance (CSA) methodology.
The probabilistic core is the model that actually scores anomalies or retrieves and summarizes records. Feed it a borderline lab value or complaint narrative today and a slightly different distribution of training data next quarter, and the confidence score or the retrieved result can shift even though nothing about your intent changed. A fixed pass/fail script can’t capture that, you need performance-based validation instead.
Keep these two tracks separate in your validation plan. Trying to force the model into a scripted-test format either produces a document nobody believes or, worse, a false sense of confidence.
How to actually test the model
Performance-based validation replaces input X produces output Y with given a representative dataset, the model meets a pre-defined performance threshold. In practice, that means:
Seeded / golden dataset testing
Build a test set with known, intentionally seeded issues, out-of-range labs, missing values, date inconsistencies, protocol deviations, or mis-tagged complaint and CAPA records, mixed with known-clean records. Measure sensitivity/recall (did it catch the seeded issues?) and the false-positive rate (specificity) against acceptance thresholds you set in advance, not a single expected output per input.
Edge-case and unscripted testing
Plan for expert-led exploratory testing with boundary and unusual inputs, on top of scripted cases, you cannot pre-script every anomaly pattern or every complaint phrasing a live dataset will eventually contain.
Explainability testing
For a sample of flags or query results, confirm the system surfaces enough rationale, which field, which record, which rule or pattern, for a human reviewer to actually adjudicate it rather than rubber-stamp it.
HITL control verification
This is the most safety-critical test for a design like this. Explicitly test that no item can be auto-closed and no query result feeds a decision without a captured human sign-off, user ID, timestamp, rationale, and that overrides or rejections are logged with the same rigor.
Drift monitoring and revalidation triggers
Define upfront what performance drop, say, recall falling below a set threshold, triggers retraining or revalidation, then test that the monitoring actually fires. This turns validation from a one-time event into a continuous control.
Change control for model updates
When the model is retrained or a new data source is added, a new trial, a new complaint intake channel, target the revalidation at the changed component rather than restarting from scratch, but define in advance what counts as a change that triggers this.
The regulatory ground to stand on
None of this is a solo interpretation. There’s a growing, if still-forming, body of guidance to anchor a validation plan to, and it differs slightly depending on which use case you’re building for.
The Good Machine Learning Practice (GMLP) guiding principles, published jointly by FDA, Health Canada, and the UK’s MHRA (2021, with a companion transparency guidance in 2024), give ten principles for AI/ML used across the device product lifecycle.
FDA’s Quality Management System Regulation (QMSR), which replaced the legacy Quality System Regulation effective February 2, 2026, aligns US device quality requirements with ISO 13485:2016, the QMS an audit/complaint AI assistant would sit inside. ISO 14971 risk management, supplemented by AI-specific guidance like AAMI TIR34971:2023, is the relevant risk framework layered on top.
FDA’s Computer Software Assurance final guidance (issued September 24, 2025, and superseded by revised guidance February 3, 2026) maps directly onto this use case, since CSA is explicitly scoped to production and quality system software under 21 CFR Part 820, exactly the software category CSA was written for.
One caveat worth stating plainly in a formal validation plan: none of the guidance above is a single unified AI regulation. Each document is scoped to a specific product type or software category, so a plan spanning both a clinical study assistant and a QMS assistant should cite the framework that actually matches each component, rather than treating one guidance document as blanket coverage for the whole system.
The takeaway
Validating an AI-driven anomaly detector or QMS query assistant doesn’t mean throwing out the discipline of computer system validation, it means applying it in two different modes at once. Ordinary scripted testing still covers the workflow, the audit trail, and the controls that keep a human in the loop. Performance-based testing, with pre-defined thresholds, seeded datasets, drift monitoring, and documented change control, covers the model itself. Get that split right, and results may vary stops being a validation blocker and becomes just another parameter you’ve already planned for.
