Generative AI is entering GxP documentation, SOP assistants, and deviation workflows — while regulation catches up via Annex 22. Most companies are prepared for neither.
This page is evidence under How we work. AI is not a field on the domain map but a step that appears in several fields.
Why act now
EU GMP Annex 22 supplements Annex 11 (Computerised Systems) with ML-specific requirements. It covers AI systems that influence GxP-relevant decisions — regardless of whether the system is marketed primarily as AI. Section 1 of the draft expressly excludes Generative AI and Large Language Models from its scope; such models should not be used in critical GMP applications.
Regulatory status
Lead time pays off: the draft expects controls for the independence of test data. Where they are split from a complete pool before training, those involved in development and training must never have had access to them — that cannot be established after the fact.
CORE REQUIREMENTS (DRAFT)
Risk-based classification of all AI/ML systems by intended use and decision depth
Demonstrable data quality: provenance, representativeness, and bias analysis of training data
Explainability: model decisions must be traceable and documentable for qualified personnel
Continuous monitoring: model performance tracked, drift detected and documented on an ongoing basis
Human oversight: critical GxP decisions require human control — no fully automated operation
Requirements based on the July 2025 consultation document; the numbering is our own and not a structure of the draft. Changes possible until the final version.
What is at stake
TRIGGER
Regulatory inspection or internal audit
FINDING
AI system in GxP process — not validated, no audit trail
Mandatory immediate revalidation
Production stoppage or batch hold
Reputational damage and follow-up inspections
The Significon approach
Use-case assessment
Which AI systems are GxP-relevant? Which are not?
Risk classification
GAMP5 category, decision depth, impact analysis
Validation plan
Test strategy, data quality, explainability concept
Implementation & test
IQ/OQ/PQ, bias tests, audit trail setup
Monitoring & review
Drift detection, periodic review, revalidation
We start with an assessment — a structured 60-minute workshop in which we jointly identify all AI systems in your GxP processes, prioritize them, and develop a concrete action plan. No engagement required.
The fundamental questions
LLMs can barely be validated for their functionality — they are non-deterministic and internally unauditable. Those who deploy AI anyway must find a different answer: not "what does the model do" but "what does the process ensure".
01
Only once proof is provided that risks are known, assessed, and controllable through appropriate measures. This is not a declaration of intent — it is an auditable proof that must exist before deployment.
02
AI must not make quality-determining decisions on its own. The human-in-the-loop approach must be technically enforced and traceable — not through internal agreements that can be bypassed in operation.
03
Through process design that structurally produces the proof — not through retrospective documentation of an already running system. The process is validated, not the model.
The key concept
Risk management becomes more important — not to reduce effort, but to make AI use possible in the first place. Proof that risks are known and understood is the entry ticket. Those who cannot provide it must not start.
First, the process must be fully understood and specified. Then the system that implements it. Only then does AI come — as an element within an already validated step, not as the driver of process design.
A human-in-the-loop based on agreements that can be bypassed in operation is not HITL. It must be technically enforced and traceable in the audit trail — who saw, evaluated, and approved which AI output, and when.
Clear roles and responsibilities in the organisation. Complete, consistent documentation. If these foundations are not solid: garbage in, garbage out — regardless of how good the AI architecture is. This is the most frequently underestimated core problem.
Validated by Design requires a tool that technically implements and versions process logic, HITL gates, and evidence strategy. Camunda is one tool that does this, and the one we use for it — a choice, not a necessity.
The result: The LLM is not validated — which is barely possible for non-deterministic models. Instead, the process is designed to structurally produce and make validity traceable. Conformity emerges through architecture, not through end-of-line control.
Why Significon
| Criterion | Typical approach | Significon |
|---|---|---|
| Validation start | After the system goes live | Integrated into deployment planning |
| Documentation | Retrospective, often incomplete | Lifecycle-parallel, audit-ready |
| AI specifics | Generic CSV templates | Validation adapted to ML characteristics |
| Monitoring | Optional, project-dependent | Mandatory component, aligned with the Annex 22 draft |
| Regulatory basis | Annex 11 applied by analogy | Annex 11 + draft Annex 22 + EU AI Act |
In the use-case assessment we jointly identify all AI systems in your GxP processes, prioritize action needs, and define a concrete next step. No commitment, no follow-on pitching.