Annex 11 Chapter 7 already covers your AI vendor

Why this is the obligation people miss

AI tends to arrive differently from other regulated software. A traditional system comes through procurement, with a supplier assessment because somebody in Quality insisted. AI often arrives as a feature inside a tool you already license, or as a service a team signed up for because it solved a problem that week.

Neither route triggers the supplier process, so the assessment does not happen. And because Annex 22 is visibly in draft, it is easy to conclude the obligations are forthcoming rather than present.

They are present. If the AI output supports a GMP activity, the system is a computerised system, its provider is a supplier, and Annex 11 Chapter 7 applies to the relationship. supplier qualification is the practice, and the assessment is usually less work than the conversation about whether it is required.

The four things an agreement has to cover

The workshop report's key messages on this topic are specific. Supplier agreements must address responsibilities, evidence, configuration and change control.

Responsibilities. Which party is accountable for what, written down rather than assumed. For a hosted AI service the split is rarely intuitive, and the areas that get missed are model governance and change notification rather than uptime.

Evidence. What the supplier will actually show you, and about which version. A vendor who asserts their testing is comprehensive and will show you nothing has given you a claim, not evidence — and the honest treatment is to record that you could not obtain it and test accordingly.

Configuration. What you configured, which remains yours without exception, and what the supplier controls. Your intended use lives in the configuration and no supplier evidence reaches it.

Change control. The hard one for AI, covered below.

Change visibility is where AI differs

This is the substantive difference between an AI supplier and a conventional software supplier, and the report identifies it: where there is limited visibility of supplier changes, regulated users need to be part of change control and have visibility over control logic.

A conventional SaaS vendor changes the application on a release schedule you can usually see. A model reached through a vendor service can change behaviour without any version number moving — retrained, re-tuned, or swapped underneath an unchanged interface. Your validated state then has a dependency you neither control nor observe.

So the questions to settle before signing are narrower and sharper than the usual cloud set. Will you be told when the model changes, as distinct from when the application changes. Is there a notice period. Can you defer, or test in an environment that receives the change first. What regression evidence will they provide. If the honest answers are no, the mitigation is monitoring with a defined response rather than a pretence of control — and that needs to be a documented decision. Model change and revalidation covers the triggers.

When you cannot audit the supplier

Physical audit of a major cloud or AI provider is generally not available, and asking for their test scripts signals inexperience. The report records a workable answer: use documented evidence such as certifications and compliance information — NIS2, SOC 2 and the ISO 27000 series were named, alongside European framework suitability — then assess alignment with your own requirements. If the provider cannot meet them, another option should be chosen.

That last clause is the part with teeth. Supplier assessment is only a control if a negative result can change the decision. An assessment that was always going to conclude in favour of the platform somebody has already bought is documentation, not diligence.

Note what certifications do and do not establish. ISO 27001, SOC 2 and ISO/IEC 42001 say something real about how an organisation runs itself. None of them says the software does what your intended use requires. They support the supplier assessment; they do not substitute for validation. cloud & SaaS validation

Accountability does not transfer

The report states it plainly: the regulated user remains accountable even when using third-party AI or cloud services.

This is worth repeating inside organisations, because the opposite assumption is common and comfortable. A vendor can make compliance easier or harder. They cannot take on the obligation, and in an inspection it is your quality system being examined, not theirs.

The practical form of that accountability is being able to answer, about someone else's model, what it is approved for and what it is not, what evaluation gates its releases, what safeguards sit on its outputs, how drift is monitored, and what happens when it is unavailable. A vendor who can answer those with documentation has thought about it; one who answers with enthusiasm has not, and you will be the one explaining the gap. Annex 22 assurance is our own published position, because the question is fair to ask of us too.

What Annex 22 may add

Not a replacement. The report suggests Annex 22 may be influenced to cross-reference Annex 11 for cybersecurity and outsourced activities while adding targeted AI-specific considerations — and explicitly notes that duplication of Annex 11 should be avoided.

Candidate additions named include definitions for shared responsibility, third-party AI provider, regulated user accountability, supplier evidence and change visibility, with industry expectations covering supplier qualification, agreements, certifications and evidence, documented responsibilities and continuous monitoring.

All of which is recognisable. If you build the supplier file Annex 11 Chapter 7 already requires, and add model governance and change visibility to it, you are substantially ready for whatever the final text says. That is a better position than waiting, and it is available now.

supplier qualification and EU Annex 11 & Annex 22 readiness are the practices, what EMA's Annex 22 workshop report says covers what else the workshop report said, and book a demo if you want an existing AI supplier file reviewed.