Everyone Is Watching Annex 22. But Your Next Inspection Will Still Start With Annex 11.

Everyone is watching Annex 22.

That is understandable. It is the new AI annex. It is where the language on intended use, model validation, test data, explainability, confidence, human oversight and ongoing operation is being shaped for GMP manufacturing environments.

EMA's 30 June-1 July 2026 workshop made that even clearer. The question is no longer whether AI will touch GMP. It already is. The question is how regulators, manufacturers and inspectors will define the guardrails for using it responsibly.

But if I were sitting with a VP of Quality this quarter, I would not start the conversation with the model.

I would start with Annex 11.

Not because Annex 22 is unimportant. It is very important.

But because AI does not arrive in a GMP organisation as a clean, isolated model. It arrives through computerised systems, workflows, interfaces, records, reports, dashboards, documents, permissions, audit trails, supplier updates and operational shortcuts that already exist.

That is where the real inspection risk sits.

The risk is not only that an AI model gives a poor answer. The risk is that the organisation cannot reconstruct the human, system and data path behind how that answer was used.

And that is an Annex 11 problem before it is an Annex 22 problem.

Why This Article Now

The European Commission's consultation package brought together revised Chapter 4, revised Annex 11 and the proposed new Annex 22 on Artificial Intelligence.

That matters because the three documents are not separate conversations.

Chapter 4 deals with documentation and records.
Annex 11 deals with computerised systems.
Annex 22 deals with AI models embedded in or connected to those systems.

Most commentary stops there: Annex 11 is the systems annex, Annex 22 is the AI annex, pair them and move on.

That is accurate.

It is also not where the real work is.

For a Quality leader, the more useful question is this:

Before we approve AI in a Quality process, can we prove that the underlying system, data, workflow and evidence model are already inspection-ready?

In my experience, that is where most programmes will struggle.

Not because people are careless. Not because teams do not understand compliance. But because digital Quality environments are rarely as clean as they look from a steering committee slide.

A Veeva Vault QMS environment may be validated, but are the workflows still aligned to the live process?

A QualityDocs library may be controlled, but is the metadata good enough to support reliable retrieval, training impact and inspection response?

An audit trail may be enabled, but is it reviewed in a way that detects meaningful GMP risk?

A supplier may be qualified, but does the agreement actually support release management, inspection support, evidence access and exit strategy?

An interface may be working, but can the business explain which data is authoritative, which transformations occur, and what happens when transfer fails?

AI will not hide those questions. It will make them louder.

The VP Quality Question Is Not "Can We Use AI?"

That question is too broad.

The better question is:

Can we defend the use of AI in a specific GMP process, using approved data, within a controlled workflow, with clear human accountability and retrievable evidence?

That is the level at which Quality leaders need to think.

An AI tool that summarises a deviation is not the same as an AI model that classifies a batch risk.

An AI assistant that drafts an investigation narrative is not the same as an AI model that recommends release action.

An AI search layer over controlled documents is not the same as an AI workflow that routes CAPAs or predicts recurrence.

The intended use drives everything.

It drives the GxP impact.
It drives the validation approach.
It drives the data requirements.
It drives the review controls.
It drives the evidence expectations.
It drives whether the use belongs in production at all.

That is why I would not let an AI governance discussion begin with a vendor demo.

I would begin with the decision point.

Where, exactly, does the AI output enter the Quality process?

Is it preparing, prioritising, recommending, classifying, approving, executing or simply retrieving?

Those are very different risk profiles.

Ten Questions I Would Ask Before a VP Quality Approves Quality AI

If a Quality leadership team asked me where to begin, I would use these ten questions.

Not as a theoretical compliance checklist.

As a practical inspection-readiness test.

1. What is the exact intended use?

"AI for deviations" is not an intended use.

"Generate a first-pass summary of approved deviation record content for investigator review" is closer.

"Classify deviation criticality and recommend CAPA pathway" is something else entirely.

The intended use needs to define the process boundary, the user, the input data, the output, the decision point and the level of human review.

If that cannot be written clearly, the use case is not ready for validation.

2. Is the AI preparing work, influencing work or making a decision?

This distinction matters.

In a GMP context, AI that prepares a draft for human review is usually easier to govern than AI that changes a record, routes a workflow or triggers an action.

For many Quality use cases, the safest design pattern is simple:

AI prepares. Humans decide. Validated systems execute.

That may sound conservative. It is also practical.

It lets Quality gain productivity without pretending that probabilistic tools should become autonomous GMP decision-makers overnight.

3. Which system is the record of truth?

Most AI initiatives fail this question quietly.

The demo works because the model can access documents, records or extracts. But the inspection question is different.

Which system owns the approved record?
Which version was used?
Which metadata travelled with it?
Was the record effective at the time?
Was it superseded?
Was it training-relevant?
Was it tied to a specific product, site, process or market?

In Quality, context is not decoration. It is control.

4. Can we trace the output back to approved source data?

For Quality AI, traceability cannot be an afterthought.

If an AI assistant summarises a deviation, the user should know which record content it relied on.

If it drafts an investigation narrative, the reviewer should see what source material shaped the draft.

If it answers a question over QualityDocs, the answer should be grounded in effective, approved documents, not outdated drafts, retired SOPs or loosely indexed PDFs.

This is where many organisations need to strengthen the data and metadata layer before they strengthen the model layer.

5. What happens when the AI is wrong?

This is one of the most important questions.

Not "how do we make AI perfect?" That is the wrong standard.

The better question is: what happens when the AI output is incomplete, misleading, overconfident or simply not useful?

Can the user reject it?
Can they edit it?
Is the edit captured?
Is the final decision clearly human-owned?
Can repeated poor outputs be trended?
Is there a route for escalation or model/use-case review?

A controlled process is not one where nothing ever goes wrong.

A controlled process is one where failure modes are anticipated, detected and handled.

6. Is the audit trail meaningful enough?

Turning on an audit trail is not the same as having an inspection-ready audit trail strategy.

For AI-supported workflows, the audit trail question becomes more nuanced.

You may need to know:

• who requested the AI output
• what record or document set was used
• whether the output was accepted, edited or rejected
• who made the final decision
• whether the output influenced a GMP decision
• whether the source data changed afterwards
• whether the use case stayed within approved boundaries

If the organisation cannot reconstruct the sequence, it should be very careful about claiming the workflow is controlled.

7. Has the role model kept up with the process?

Access control is one of the least glamorous parts of digital Quality.

It is also one of the most inspection-relevant.

AI makes role design more important, not less.

Who can invoke the AI capability?
Who can see the underlying records?
Can the AI retrieve restricted information across product, site or market boundaries?
Can contractors access outputs?
Can system administrators alter prompts, actions or retrieval scopes?
Who approves those changes?

A weak permission model becomes a larger issue when AI can surface, combine or summarise information faster than a user could manually retrieve it.

8. Is supplier control strong enough for AI-enabled features?

Many regulated companies are comfortable qualifying a SaaS supplier once and then relying heavily on the vendor's platform release process.

That may be workable for standard platform functionality.

AI-enabled features need more deliberate governance.

Before enabling an AI capability, Quality should understand the supplier's control boundary.

What can the vendor change?
How are model, prompt, retrieval or agent-action changes communicated?
What evidence is available?
Can the feature be tested in a non-production environment?
Can the customer restrict intended use?
Can the vendor support inspection questions?
What happens if the feature is withdrawn or materially changed?

Responsibility for GMP use does not move to the vendor just because the feature is vendor-delivered.

9. Do SOPs and training actually reflect how people will use the tool?

This is where adoption and compliance often meet.

If users treat AI as an unofficial shortcut, the risk grows outside the quality system.

If the SOP says one thing but the daily behaviour says another, the inspection story becomes fragile.

Quality teams need to define the permitted use, prohibited use, review expectation, documentation requirement and escalation route.

Training should not simply say "use the AI responsibly."

It should show users what good use looks like, where the boundary sits, and which decisions remain human-owned.

10. Can we build the evidence pack before go-live?

This is the final test.

Before enabling AI in a GMP Quality workflow, a VP of Quality should be able to ask for an evidence pack.

Not a 300-page validation binder for the sake of tradition.

A clear, risk-based evidence pack that shows:

• intended use
• GxP impact assessment
• process map
• data/source map
• supplier assessment
• configuration or feature settings
• access model
• validation rationale
• test evidence
• human review controls
• audit trail strategy
• SOP and training impact
• monitoring and periodic review plan
• change control triggers
• known limitations

If that pack does not exist, the organisation is not approving AI.

It is approving a future remediation project.

What This Means for Veeva Vault Quality

For many Navata clients and buyers, this discussion will not be abstract. It will land inside Veeva.

Vault QMS.
QualityDocs.
Training.
Change Control.
Complaints.
Audits.
Supplier Quality.
Deviations and CAPA.
Reports and dashboards.
Integrations into ERP, MES, LIMS or analytics layers.

That is where Annex 11 readiness becomes very practical.

A Veeva implementation can be technically sound but still operationally weak if the evidence model is not maintained after go-live.

The workflow may be live, but do users follow it consistently?

The lifecycle may be configured, but does it still match the approved business process?

The object model may support the process, but is the metadata disciplined enough to support AI retrieval?

The reports may be useful, but were they validated based on their actual use?

The audit trail may exist, but does the review procedure identify meaningful risk?

The system may have gone through validation, but is release management still controlled as the platform evolves?

These are not theoretical concerns. They are exactly the kind of gaps that appear when a system moves from project mode to operating model.

And AI will increase the pressure on that operating model.

If a future Veeva Quality capability helps summarise a complaint, draft deviation content, query records or assist triage, the organisation will still need to answer the same core questions:

What was the intended use?
What data was accessed?
Was the output advisory or decision-supporting?
Who reviewed it?
Was the final decision human-owned?
Was the use captured?
Can the path be reconstructed?
What changed when the platform was updated?

That is not anti-AI. That is how AI survives inspection day.

That is why AI readiness in Veeva is not just a feature-readiness question.

It is a Quality architecture question.

The Mistake I Would Avoid

The mistake I would avoid is building an "AI governance framework" that lives outside the actual Quality system.

That is tempting.

It gives the organisation a new committee, a new policy, a new intake form and a few impressive slides. It may even satisfy the first steering committee review.

But it does not solve the operating problem.

AI governance has to connect back into the same mechanisms Quality already relies on:

• process ownership
• risk management
• validation
• supplier management
• change control
• document control
• training
• audit trail review
• periodic review
• deviation and CAPA
• inspection readiness

Otherwise, AI becomes a parallel system of promises.

And parallel systems rarely perform well under inspection.

The better approach is to bring AI into the Quality system deliberately. Not slowly for the sake of slowness. Deliberately.

Define the use.
Classify the risk.
Map the data.
Control the workflow.
Validate the behaviour that matters.
Train the users.
Monitor the process.
Keep the evidence retrievable.

That is how AI becomes operationally useful without becoming inspection debt.

Final Verdict

Annex 22 deserves the attention it is getting.

But Quality leaders should not wait for the final Annex 22 wording before acting.

The readiness work is already visible in Annex 11.

If the organisation cannot explain its system requirements, data lineage, supplier controls, audit trail review, access model, validation evidence, cybersecurity posture, backup and restore approach, and lifecycle governance, then AI will not fix the problem.

It will expose it.

For a VP of Quality, the practical question is not:

"Are we allowed to use AI?"

The better question is:

"Can we reconstruct and defend how AI was used inside a controlled Quality process?"

That question starts with Annex 11.

And for companies running Veeva Vault Quality, QualityDocs or connected digital Quality platforms, it starts with the evidence model already sitting underneath today's workflows.

AI in Quality will not be won by the organisation with the most impressive model.

It will be won by the organisation that can prove the system around the model is controlled.

This analysis draws on the European Commission’s consultation package for revised EU GMP Chapter 4, revised Annex 11, and the new Annex 22 on Artificial Intelligence; EMA’s June–July 2026 Annex 22 workshop materials; and practical experience implementing and governing validated Quality systems in regulated life sciences. Views expressed are personal and do not represent any employer or client.