If Annex 22 becomes technology-neutral, the compliance task changes shape. Under a categorical exclusion you argue about what your model is. Under a risk-based framework you demonstrate a control strategy — and EMA's workshop report is explicit that this is where the drafting group's remaining concerns lie.
That makes the control strategy the thing worth building now, because unlike a classification argument it does not become worthless when the scope moves. This is what the published material indicates it has to contain, and where most organisations are currently short.
Intended use is the foundation, and it is usually missing
Every framework in this space starts here and most implementations skip it. The report lists documented intended use first among the themes that emerged across all six workshop sessions.
A usable intended use statement says what the system is for, what it is explicitly not for, what inputs it accepts, what it produces, who reviews the output, and what happens when it is unavailable. The negative scope is the part that gets omitted and the part that matters: a system described only by what it does will be used for adjacent tasks nobody assessed, because it appears to work on them.
This is also what makes validation possible at all. You cannot demonstrate fitness for intended use without a statement of intended use, which is why a large number of AI pilots cannot be validated — not because the technology is unsuitable, but because nobody wrote down what it was for. The AI intended-use statement
ICH Q9 is the framework, not a new one
The workshop's emphasis was the application of ICH Q9 quality risk management principles. That is worth noting because it means the expectation is not a bespoke AI methodology — it is the risk management framework you already operate, applied to a case with unfamiliar failure modes.
The practical consequence is that your AI risk assessment should look like a risk assessment: hazards identified, probability and severity considered, detectability accounted for, controls specified, residual risk accepted by someone with the authority to accept it. What changes is the hazard list. A model can be confidently wrong, degrade silently as inputs shift, or behave differently after a vendor updates it without telling you.
The report also records that participants emphasised uncertainty, complexity, model influence and detectability as important considerations when evaluating AI systems in GMP activities. Those four are a more useful starting point than a generic severity score, and the four factors for judging AI risk in GMP works through them.
Controls that are effective rather than documented
The conclusion in the report turns on the effectiveness of the controls applied throughout the lifecycle. Effectiveness, not existence — and that distinction is where most AI control strategies would struggle.
A human review step that exists in a procedure is documented. A human review step the system enforces, where output cannot reach an approved state without a qualified signature, is effective. The test is simple enough to run: try to use the output without review. If you can, the control is procedural.
Deterministic guardrails are the other category worth separating out. A probabilistic model wrapped in checks that are themselves deterministic — a value must fall in a range, a reference must resolve, a field must match a controlled vocabulary — gives you a system whose worst case is bounded even though the model is not. That is the shape of mitigation the workshop was convened to discuss, and it is the reason a generative model can be defensible in a place a bare model would not be.
Risk-proportionate oversight
The report's phrase is risk-proportionate human oversight, and the proportionality runs in both directions.
Low-risk, high-volume output does not need every item reviewed by a qualified person, and pretending otherwise produces a control that is nominal — if a reviewer must approve several hundred items a shift, review is rubber-stamping and everyone involved knows it. High-risk output needs review that is genuinely possible: a named role, authority to reject, enough context to judge, and time to use it.
The asymmetry worth measuring is the cost of rejection against the cost of acceptance. If accepting is one click and rejecting requires a justification, a reassignment and a conversation, the system has a thumb on the scale and automation bias will do the rest. why human-in-the-loop can't be a footnote and Human-in-the-Loop reviews go into the design.
Lifecycle, because approval is a moment and risk is continuous
Validation and lifecycle management was one of the six topics, and the report lists lifecycle validation and monitoring among the common themes. The requirement is straightforward to state and routinely absent in practice.
Monitoring needs a defined measure, a defined frequency, a threshold decided in advance, and a named owner. Without a threshold set before you have operational data — which feels arbitrary, and should be done anyway — monitoring produces a chart somebody glances at and nobody acts on.
Re-qualification triggers matter as much. A model reached through a vendor service that updates underneath you has a dependency you do not control, and the only honest mitigations are detection and a defined response. Model change and revalidation covers the triggers, and the AI validation test set the evaluation set that gates a release.
The fallback, which is not optional
Every framework in this area asks what happens when the AI is switched off, and the answer has to be a path people have actually used rather than a documented intention.
Run it once, deliberately, before go-live, and record that you did. Organisations that skip this discover during an outage that the fallback depends on a template nobody has maintained since the AI arrived — and in a GMP context the obligation does not pause because a model is unavailable.
Accountability and suppliers
Clear accountability and supplier oversight both appear in the report's list of common themes, and the supplier position recorded there is firm: the regulated user remains accountable even when using third-party AI or cloud services, and Annex 11 Chapter 7 was considered applicable and sufficient at a principle level.
So the control strategy has to cover what your supplier does, with evidence rather than assurance — supplier qualification, agreements that address responsibilities, configuration and change control, and continuous monitoring. Where physical audit of a major cloud provider is impractical, the recorded answer was documented evidence such as certifications and compliance information, assessed against your own requirements, with the option of choosing another provider if they cannot meet them. Annex 11 Chapter 7 and your AI vendor and supplier qualification
A control strategy that would survive the question
Assembled, the set is not exotic. Documented intended use with explicit negative scope. A risk assessment under ICH Q9 that accounts for uncertainty, complexity, model influence and detectability. Acceptance criteria defined before evaluation, against a held-out set that gates releases. Deterministic guardrails bounding the worst case. A named human review role at an enforced gate, proportionate to risk. Monitoring with a pre-set threshold and an owner. Re-qualification triggers for model and vendor change. An exercised fallback. Supplier evidence, assessed and recorded.
None of it depends on the final text of Annex 22, which is the point. AI validation services is the practice, Annex 22 assurance is how we hold our own product to it, and book a demo if you want a use case assessed against this set.
Where to go next
Explore GxP Copilot for AI-native validation, TraceDraft for source-traceable clinical documentation, or book a demo to see either on your own data.