Validate AI systems used in GxP-regulated processes.
Model cards, evaluation sets, deterministic guardrails, HITL policies, drift monitoring and template fallbacks — the Annex 22 assurance stack, delivered as a service. Covers GenAI copilots, ML classifiers, predictive maintenance models, and agentic systems used in GMP, GCP or GLP operations.

Validating AI in a GxP process means proving it is fit for a bounded intended use and keeping it so as the model changes. That requires a held-out evaluation set, thresholds set before testing, human decision on anything consequential, drift monitoring in production, and a documented fallback. The draft EU Annex 22 sets the expectations; it has not yet been adopted.
Outcomes you can expect
- Annex 22-aligned AI assurance package
- Model card + eval set + drift plan
- HITL policy + template fallback
AI Validation Services (Annex 22) is delivered by our validation & compliance services practice. Where it saves time, the team uses our products: GxP Copilot for validation lifecycle work and TraceDraft for clinical documentation.
Explore related capabilities: Computer System Validation (CSV), Computer Software Assurance (CSA), FDA 21 CFR Part 11 Compliance, EU Annex 11 & Annex 22 Compliance.
Why AI in GxP Environments Requires a Different Validation Framework
Traditional computer system validation under GAMP 5 assumes a deterministic system: the same input produces the same output, consistently and verifiably. AI systems — particularly large language models and machine learning classifiers — are probabilistic: the same input may produce different outputs depending on temperature settings, model version, context, and inference configuration. This non-determinism is not a defect; it is how AI works. But it means that the traditional IQ/OQ/PQ framework, applied unchanged, does not provide adequate assurance for AI-generated outputs in a GxP context.
EU GMP Annex 22 on Artificial Intelligence is the EU's first GMP annex written specifically for AI. It was published as a consultation draft in July 2025 and is not yet in force, so it is not a requirement you can be cited against today — but it is the clearest statement of where the EU is heading, and it is worth designing towards. As drafted it calls for documented AI governance covering intended use, limitations, training data, model governance, performance benchmarking, human oversight, and a plan for managing AI behaviour change over time. FDA's emerging AI/ML guidance for pharma and medical devices points in the same direction. AI used in a GxP context must be validated — but with an assurance framework designed for AI's characteristics, not a repurposed CSV template.
The Six-Element Annex 22 Assurance Stack
Cybroscape's AI validation practice is built around the six elements the Annex 22 draft sets out. First, the model card: a structured document describing the AI model, its intended use, its training data basis, what it is and is not approved for, and its known limitations. Second, the evaluation benchmark: a frozen, versioned test set of representative inputs with expected outputs, scored against defined acceptance criteria, that gates every model release. Third, deterministic guardrails: programmatic constraints that prevent out-of-scope or non-compliant outputs regardless of what the AI generates.
Fourth, the human-in-the-loop policy: a documented and workflow-enforced governance structure ensuring that qualified humans review and approve AI-generated outputs before they are used in GxP decisions. Fifth, drift monitoring: a defined programme for detecting when the AI's behaviour changes over time — through model updates, distributional shift in inputs, or infrastructure changes — and a defined response when drift exceeds a threshold. Sixth, the template fallback: a documented alternative process that maintains GxP operations when the AI is unavailable or performing below the acceptable threshold. We deliver all six elements as a structured service.
GAMP 5 Classification of AI Systems
AI systems used in GxP contexts are not exempt from GAMP 5 classification. A SaaS AI validation platform like GxP Copilot, where the AI capability is a configurable component of a hosted application, is Category 4. A bespoke AI model trained on proprietary data to perform a regulated function — such as a process analytical technology prediction model or a safety signal classifier — is Category 5. The classification determines the depth of the validation package: Category 4 requires OQ of the AI's configured behaviour; Category 5 requires the full software development lifecycle evidence including training data governance, model selection rationale, and validation study design.
The validation of an AI system also extends to its data pipeline: the training data must be documented as to source, preparation, and bias assessment. The validation dataset must be independent of the training data. The test set used for the benchmark must be frozen and version-controlled so that performance can be compared across model releases. Cybroscape delivers the full validation documentation chain for both Category 4 and Category 5 AI systems, including the model lifecycle management documentation that enables ongoing regulatory compliance as the model evolves.
HITL Policy: Enforced by Workflow, Not Just by SOP
Human-in-the-loop governance is the most common gap in current GxP AI implementations. Most organisations have an SOP stating that AI outputs must be reviewed by a qualified person before use. Very few have a system that enforces this — that physically prevents an AI-generated output from entering a GxP record without a documented human review. The difference matters in practice: SOPs can be bypassed under time pressure; workflow controls cannot.
Our HITL policy design specifies not just what human review must occur but how the system enforces it — what roles can approve AI outputs, whether authors can approve their own AI-generated content, what the review record must contain, and what happens when a reviewer rejects the AI output. Where the GxP system does not natively enforce HITL, we design the compensating controls — access controls, approval routing, mandatory review steps — that make the policy operationally real rather than procedurally aspirational.
Drift Monitoring and the AI Model Change Control Process
An AI model is not static after deployment. The underlying model may be updated by the vendor. The input distribution may shift as the operational context evolves. The model's outputs may degrade gradually without any single obvious failure. Drift monitoring is the programme that detects these changes before they result in GxP compliance failures. It requires a defined set of sentinel inputs — representative cases with known expected outputs — evaluated against the deployed model on a defined schedule. When the model's performance on sentinel inputs falls below a defined threshold, the drift monitoring programme triggers a formal assessment.
AI model updates in a GxP context are change control events. The vendor's release notes do not satisfy the change control requirement — the organisation must evaluate the impact of the model change on its specific AI use case, run the updated model against the frozen benchmark, document the result, and communicate the change through the QMS before deploying the update in the production GxP environment. Our AI managed services programme provides ongoing drift monitoring and change control support for AI systems in production, maintaining the Annex 22 assurance posture between major validation events.
Sources
Primary documents referred to on this page, from their official publishers.
- EudraLex Volume 4: EU Good Manufacturing Practice guidelines · European Commission
- Consultation on EU GMP Chapter 4, Annex 11 and draft Annex 22 (Artificial Intelligence) · European Commission
- ISPE GAMP 5 Guide, Second Edition · ISPE
See it on your own system.
Bring a URS or a system. We show you the validation package it produces.
- We reply within one business day
- We run your URS live on the call
- You get a clear plan and scope