Nine Contract Clauses Your AI Vendor Will Refuse to Sign

Draft EU GMP Annex 11 clause 7.5 lists nine things a contract with a service provider is expected to do. Item viii asks for "an exit strategy by which the regulated user may retain control of system data". Item ix asks the parties to agree "on the process for release of new system versions and on the regulated user's possibility to test these prior to release". Read those two against the published lifecycle policy of any hosted large-language-model API and the negotiation ends before it starts.

That changes the register of the argument. Self-hosting versus a hosted API is usually a debate about cost, latency and how nervous your security function is. Clause 7.5 turns it into a line in a supplier assessment: the contract content the inspectorate has drafted, the vendor's published position, the gap, the compensating control.

Two caveats. The draft is a draft. And clause 7.5 is narrower than most people quote it as being: it bites where you rely on a service provider's or an internal IT department's qualification and/or operation of a system. "Vendor" appears in clauses 7.1, 7.2, 7.4 and 9.9 but not in 7.5.

What draft clause 7.5 actually lists

The left-hand column paraphrases the consultation version published by the European Commission on 7 July 2025 (draft Annex 11 PDF, clause 7.5, page 5). The right-hand column is my assessment of what a hosted model API delivers against it.

Note what the draft does not do. Searching the full 19-page consultation PDF on 30 August 2026, the glossary defines "regulated user", "computerised system", "qualification" and "migration" but carries no definition of "supplier", "service provider" or "vendor", and the word "cloud" appears once, in the introduction. A nine-item contract specification for service providers that never defines the term will generate findings turning on classification, and whoever writes your supplier categorisation SOP decides whether clause 7.5 reaches your model API at all.

Which instrument actually binds you on 30 August 2026

The 2011 text is four sentences on suppliers (Annex 11, clause 3); the draft is a full section. Anyone saying Annex 11 "requires" a data exit strategy today is quoting a consultation document as law. Anyone dismissing the draft is ignoring that the GMP/GDP Inspectors Working Group and the PIC/S Committee wrote it, and that the consultation closed nearly eleven months ago.

Get the AI Act sequencing right too. The deferral of the high-risk regime is no longer a proposal: Regulation (EU) 2026/1744 of 8 July 2026 was published in the Official Journal on 24 July 2026 and has applied since 27 July 2026. Prohibited practices, the Article 4 literacy duty and the general-purpose AI obligations are already live; Annex III high-risk obligations start on 2 December 2027.

Clause 7.5(ix) is the one that fails: testing a version prior to release

Here is what the four platforms publish, checked on 30 August 2026.

Every one of those is an overlap after the new version ships. None is what clause 7.5(ix) asks for on its most natural reading, that you test a version before release. On the looser reading, before release into your validated environment, a pinned snapshot plus a deployment set never to auto-upgrade does satisfy it, and I would argue that in an inspection. What it does not survive is the follow-up: is that in the contract? A documentation page is not a contract term, and Microsoft's FAQ answers "Can I get an exception to extend a model's retirement date?" with "No. Retirement dates aren't extendable."

Your requalification schedule is therefore set by a calendar you cannot appeal. Microsoft sets generally available model retirement at 18 months from launch, programmatically, at launch, and at 12 months for generally available models from Anthropic, DeepSeek, Fireworks and Mistral AI. Anthropic's deprecation page shows what 60 days looks like: claude-opus-4-1-20250805 was deprecated on 5 June 2026 and retired on 5 August 2026. Inside a validated application, that is 61 days to select a replacement, re-run performance qualification against pre-registered acceptance criteria, assess the change and close the record.

A quieter trap sits in Amazon Bedrock's lifecycle documentation: "existing customers may lose access to Legacy models after 15 days of inactivity". A validated system that runs quarterly can lose its qualified model between executions with nothing having changed on your side. You also cannot create new provisioned throughput for a Legacy model, so the capacity guarantee under a validated workload disappears exactly when you need stability.

Clause 7.5(viii): an exit strategy for data you can export and a model you cannot

Item viii is narrower than it first reads. It asks for an exit strategy "by which the regulated user may retain control of system data": data, not function. For prompts, completions, embeddings, evaluation sets and audit-trail records that is a solved engineering problem, and draft clause 17.5 gives the acceptance criterion, that archived data and metadata be retrievable "in a format which allows searching and sorting".

What no exit strategy retains is the model. When a hosted version retires, the function that produced every historical output is gone and you cannot re-derive an output to investigate a deviation two years later. That is why audit-trail design matters more here than for a LIMS: the full prompt, the model identifier and version string, the configuration and the output must be captured as records at the time. Bedrock leaves one door open, in that after EOL requests fail "unless there is a private arrangement between you and the provider for continued access". In a negotiation for a GxP-critical use, that is the sentence to push on.

Clause 7.5(iv): what "conditions for supplier audits" buys you

Draft clause 7.2 tells you to conduct "an audit or a thorough assessment" according to risk and criticality; clause 7.5(iv) asks you to agree its conditions in the contract. Hyperscalers satisfy audit obligations with third-party reports rather than site visits, and say so: AWS's GxP systems whitepaper describes reassessing its capabilities "typically by reviewing the latest materials available through AWS Artifact (i.e. AWS certifications and audit reports)". The same substitution is familiar from GDPR Article 28(3)(h), where processors offer ISO 27001 and SOC 2 Type II instead of controller-conducted audits.

Two things follow. Agreeing that the audit condition is a documentation review is a legitimate risk-based outcome under clause 7.2, provided your risk assessment says so in writing and the criticality justifies it. And check the vintage of the vendor evidence. That same whitepaper, cited in many pharma qualification packages, now opens with a banner reading "This whitepaper is for historical reference only. Some content might be outdated and some links might not be available." A supplier assessment leaning on a superseded document is a finding waiting to be written.

Clause 9.9: your signature goes on the vendor's documentation

Draft clause 9.9 is the sentence for anyone who thinks a vendor validation pack closes the question. Qualification and validation documentation "may be provided by a service provider, a vendor or an internal IT department in parts or in whole. However, the regulated user is fully accountable and should carefully review and authorise the use of the documentation." You must then judge whether it covers the implemented version and supports GMP and your processes as-is, or whether parts must be repeated by you.

Draft Annex 22 clause 2.2 says the same for models: documentation should be available and reviewed by the regulated user "irrespective of whether a model is trained, validated and tested in-house or whether it is provided by a supplier or service provider". Note also the scope line governing all of it. Generative AI and large language models fall outside draft Annex 22, and "such models should not be used in critical GMP applications". If your supplier qualification is for an LLM in a critical GMP application, the contract clauses are your second problem.

The same model, different retirement dates on each platform

One detail breaks most change-control processes: the same model carries different lifecycle dates on different platforms, each set governing its own. claude-sonnet-4-20250514 was retired on the Claude API on 15 June 2026; on Amazon Bedrock, anthropic.claude-sonnet-4-20250514-v1:0 entered Legacy on 14 April 2026 with an EOL date of 14 October 2026. Four months apart, same weights. AWS puts it plainly: "For Amazon Bedrock usage, only the dates on this page apply."

If your validated application can route to more than one platform, your change-control triggers must track each calendar separately and your periodic review must state which one the qualified configuration used. Draft clause 14.2 lists "contracts and key performance indicators (KPI) with vendors and service providers" as a periodic-review scope item alongside changes to platform and infrastructure.

What this means in practice

Run the supplier assessment for whichever model API sits closest to a GxP process against the nine items as a gap list, not a pass/fail: which items you can obtain, which you are substituting a control for, and who approved the substitution. That document is worth more in an inspection than a signed agreement covering three of the nine.

Add the vendor's lifecycle calendar to your change-control triggers, with a named owner and a lead time. Sixty days does not cover requalifying a GxP-critical system needing a fresh independent test set, executed protocols and a QA-approved report, so the trigger fires on the deprecation announcement, not the retirement date, and the risk assessment should say in advance what happens if the replacement fails acceptance criteria mid-window.

Decide the classification before an inspector does: is your model API a vendor under clause 7.2 or a service provider under clause 7.5, and why. There is no glossary definition to hide behind.

Then price it. The clauses you cannot obtain get absorbed by your own controls: pinned versions, a full prompt-and-output audit trail, human review of every model-influenced write to a regulated record, and a requalification budget recurring every 12 to 18 months per hosted model rather than once per system. That recurring cost, not the licence fee, decides whether a self-hosted open-weights model in your own qualified environment is cheaper for a given use. A model you host does not retire until you retire it, and clause 7.5(ix) stops being a negotiation you lose.