Nineteen Pages, Seventeen Chapters: The Annex 11 Revision Clauses That Cost Money

On 30 August 2026 the binding rule for computerised systems in EU GMP is still the 2011 Annex 11: five pages, seventeen numbered clauses, operative since 30 June 2011. The proposed replacement published for consultation on 7 July 2025 runs to 19 pages across 17 sections, with a glossary. The consultation closed on 7 October 2025. Nothing has been adopted, and the European Commission consultation page still lists all three drafts, Chapter 4, Annex 11 and Annex 22, as a closed response period with no successor text.

Most of the extra 14 pages is codification. Inspectors already expect password rules, restore tests and access reviews, and the draft writes down what they were asking for anyway. Four clauses are different. They do not ask you to document a control you have; they ask you to buy one you do not have, or to staff a review you do not currently staff. Clause 7.5(ix) requires the contract with your service provider to agree the release process for new system versions and your ability to test them before release. Clause 12.8 moves audit trail review in front of batch release, and 12.6 requires it to be done by someone not involved in the activity. Clause 9.8 goes the other way and hands time back.

There is also a defect in the package worth knowing before you build a data model around it. Draft Chapter 4 clause 4.63 sets out data integrity principles "(i.e. ALCOA ++)" and its glossary defines ALCOA++ as including traceable. Draft Annex 11 clause 2.4 invokes "the ALCOA+ principles" and its glossary defines ALCOA+ without traceable. Same drafting groups, same publication date, two different acronyms.

What is binding on 30 August 2026, and what is not

The distinction matters commercially, because a consultant who cites draft clause numbers as requirements will get a purchase order and then lose the room in the first inspection debrief.

Binding today: Annex 11 (2011). Its supplier clause, 3.1, requires only that "formal agreements must exist between the manufacturer and any third parties" with "clear statements of the responsibilities of the third party". Its audit trail clause, 9, asks for "consideration ... based on a risk assessment" of building in a record of GMP-relevant changes and deletions, reviewed "regularly". Its periodic evaluation clause, 11, is four lines long.

Draft, not binding: the 7 July 2025 revision, its 17 sections and every clause number in this article. Also draft: Annex 22 on artificial intelligence, published the same day. EMA's GMP/GDP Inspectors Working Group ran a further multistakeholder workshop on 30 June and 1 July 2026 and states it "is still considering the implications of the stakeholder consultation results". A drafting group still gathering expert input on guardrails in July 2026 is not one about to publish.

Separately binding, and often confused with this: Regulation (EU) 2026/1744, the Digital Omnibus on AI of 8 July 2026, published in the Official Journal on 24 July 2026, which moved the AI Act's high-risk application dates to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I product-embedded ones. It did not touch GMP. Prohibited practices, Article 4 AI literacy, Article 50 transparency and the general-purpose AI obligations are live now, and run in parallel with Annex 11 rather than instead of it.

Clause 7.5(ix): the right to test the vendor's next version

Draft 7.5 lists nine things the contract with a service provider, or the approved procedure with an internal IT department, must do. Eight are recognisable from any decent quality agreement: scope, applicable procedures and regulations, reporting and SLAs, audit conditions, inspection support, issue resolution, security communication, and an exit strategy by which the regulated user retains control of system data.

Item (ix) is the new one: the contract "agrees on the process for release of new system versions and on the regulated user's possibility to test these prior to release."

Read that against how software is delivered in 2026. A multi-tenant SaaS platform ships to every tenant on the vendor's cadence, and its economics depend on not maintaining per-customer branches. A hosted model API is worse, because the unit that changes is the model. Published vendor policies grant notice, not a test right: Anthropic's model deprecation documentation commits to at least 60 days' notice before retiring a publicly released model, which tells you when your validated configuration disappears, not when you may test its replacement.

Notice of retirement and a right to pre-release testing are different products. The first lets you plan a revalidation. The second lets you refuse a release. If the draft is adopted as written, every renewal of a GMP SaaS or AI service contract becomes a negotiation over three things: a staging tenancy running the candidate version, a defined window between candidate availability and production cutover, and a named right to withhold cutover on your tenant. Vendors price all three, because all three cost them engineering. It is the same negotiation as the contract clauses AI vendors will not sign without a fight, with 7.5(ix) turning it from good practice into an audit finding.

The budget lines are a second environment on the vendor's bill, a regression suite maintained against a moving target, and the internal time to run it inside the window you negotiated. None of that follows from the 2011 text.

Clause 12.8 and 12.6: the audit trail review moves in front of batch release

Section 12 of the draft has ten subsections. Two of them change the operating model.

12.8, timeliness. "Audit trail reviews should be conducted in a timely manner according to the risk of the process reviewed. The audit trail review should be conducted prior to batch release, unless the risk of a later detection of any unwarranted changes can be justified."

12.6, independence. "Audit trail reviews should be conducted by personnel not directly involved in the activities covered by the review (a peer review)."

And 12.10, which is the one QPs will feel: audit trail reviews with direct impact on release "should be available to the QP at the time of batch release."

Put those together and the default inverts. Most sites today run a periodic audit trail review monthly or quarterly, performed by the system owner or the process area itself, disconnected from disposition. Under the draft, review before release is the default and a later cycle is the exception you justify in writing, in a risk assessment an inspector will read.

Two mitigations survive, both in the text. Clause 12.7 says reviewing all entries "may not be effective" and that reviews should target deliberate or unintentional changes to critical processes and data, verifying the recorded reason. Clause 12.4 requires the system to make review sortable and searchable on who, what, when and why, or exportable to a tool that is. Together they licence an exception-based review over a filtered slice, not skipping it.

Do the arithmetic with your own numbers, because no public figure exists for the cost of a pre-release audit trail review. Monthly batch count, times the GMP systems whose trails touch disposition, times the review minutes your procedure will demand, then apply 12.6: none of those minutes may come from the person who ran the process. In a QC lab with one analyst per technique, peer independence is not a scheduling problem, it is a recruitment problem.

What each new clause actually costs

Periodic review goes from one paragraph to 12 named inputs

The 2011 clause 11 lists what evaluations "should include, where appropriate": functionality, deviations, incidents, problems, upgrade history, performance, reliability, security, validation status. It is one sentence and it is routinely satisfied by a two-page report.

Draft 14.2 names 12 inputs in two groups. Changes since the last review cover hardware, software, configuration, platform, infrastructure and interfaces (i), the documentation that should reflect them (ii), and the combined effect of multiple changes across systems, with undocumented changes to be identified, for instance by configuration auditing (iii). Follow-up on supporting processes runs from previous audit and inspection actions through audit trail and access reviews, security incidents, SLAs and vendor KPIs, backup and restore testing, archival, data integrity assessments, and changes to regulatory requirements (iv to xii).

Item (iii) is the expensive one. Detecting undocumented changes "by means of configuration auditing" means holding a machine-readable baseline of the approved configuration and diffing production against it. Few organisations do this across their validated estate, and no procedure alone produces it. Clause 14.3 adds a risk-justified frequency and a final review at retirement, closing the gap where a decommissioned system's data quietly loses its owner.

For any system whose behaviour changes without a change request, which is what a machine-learning component is, the periodic review is where drift surfaces, and where it has to reconcile with the continuous monitoring and revalidation triggers a deployed GxP model needs.

Clause 9.8: the one clause that hands budget back

Almost every commentary on this draft is a list of new burdens. Clause 9.8 is the exception, and it legitimises something quality units already do informally and badly. Validation should be completed and reported before a system is taken into use. Then: "Conditional approval to proceed to taking a system into use may be granted where certain acceptance criteria have not been met, or deviations have not been fully addressed." The conditions: a documented assessment showing the deficiencies will not affect product quality, patient safety or data integrity, the conditional approval stated explicitly in the validation report, and close follow-up of outstanding actions to plan.

That is a written route to go live with open items. A site that currently holds a go-live for three weeks over two cosmetic test failures gets a defensible alternative costing one impact assessment. Note what it is not: it is not a route past a failed test of a data integrity control, because the assessment must conclude no impact on data integrity, and an audit trail defect fails that on its face.

The cloud chapter that is not there

Secondary summaries of this draft routinely promise new cloud and SaaS requirements. Search the document and the picture is thinner.

I searched the draft Annex 11 PDF on the Commission's consultation page (document 40231f18-e564-4043-94de-c031f813d38b, 19 pages, dated 7 July 2025), text-extracted on 30 August 2026. The word "cloud" occurs once, in the introduction, as a reason for the revision. No section is headed cloud, hosting or software as a service. The strings "artificial intelligence" and "machine learning" do not occur at all: AI is routed to Annex 22, which draft Chapter 4 cross-references explicitly and Annex 11 never mentions.

What governs a hosted system is section 7, which never uses the word cloud and applies word for word to an internal IT department, plus section 15 on security. The two clauses that bite a SaaS deployment are 7.5 and 7.4, the latter requiring that documentation for every activity in the annex "is accessible and can be explained from their facility". That is a higher bar than a vendor audit report in a shared folder, and it fails when the only person who understands the qualification evidence works for the vendor. For an AI service the same clauses do most of the work, which is why the practical questions about what binds an AI system under GxP today resolve to supplier management and audit trails more often than to anything AI-specific.

ALCOA+ or ALCOA++? The same package says both

Draft Annex 11 clause 2.4 states that data integrity is important and that it is defined by "the ALCOA+ principles". Its glossary defines ALCOA+ as attributable, legible, contemporaneous, original and accurate, with additional emphasis on complete, consistent, enduring and available. No traceable.

Draft Chapter 4 clause 4.63 introduces its data integrity table as "Basic data integrity principles (table 1) applicable to both paper and electronic systems (i.e. ALCOA ++)" and its glossary defines ALCOA++ with complete, consistent, enduring, available and traceable.

Both were published on 7 July 2025 by the same joint working group, in the same package. EMA's 2023 guideline on computerised systems in clinical trials has used ALCOA++ since it became effective on 10 September 2023, so the direction is not in doubt. The drafting is.

Do not wait for it to resolve. Traceable requires a record to carry its own provenance chain, from raw acquisition through every transformation to the reported result. Retrofitting that is a schema change and a migration; building it in now is a design decision. If the final text lands on ALCOA+, you have over-delivered on one attribute. If it lands on ALCOA++, you are not re-platforming a LIMS in a remediation window.

What this means in practice

The Monday version, in order of lead time rather than importance.

Pull the contract renewal calendar first. Every GMP service agreement expiring in the next 18 months takes 7.5(ix) language at no incremental cost, because you are negotiating anyway; adding it mid-term costs a variation. Ask for a defined pre-release test window, a staging instance running the candidate version, and a right to defer cutover on your tenant. Expect to lose the third with large platform vendors and to be offered a longer notice period instead. Record what you asked for and what you got: that is your risk assessment when the clause becomes binding.

Cost the audit trail review before you design it. Draft 12.6 plus 12.8 is a staffing model, and the item most likely to be found late. Run the arithmetic on one product family, with real batch cadence and a real systems list, and find out whether peer independence exists at all in your smallest labs. If it does not, the answer is cross-site reviewers or a documented justification under the 12.8 exception, and both take longer to build than a procedure revision.

Build the configuration baseline. Draft 14.2(iii) asks you to detect undocumented changes. An exported, version-controlled configuration baseline per validated system is useful the day you have it, and it is the only thing that stops the periodic review being an exercise in asking people whether they changed anything. While you are there, write traceable into your data integrity standard and let the drafting groups catch up.

Who signs: the system owner proposes, QA approves the review procedure and the 12.8 risk justification, and procurement owns 7.5(ix) but will not know to ask unless quality writes the clause. What goes wrong: sites treat the draft as a documentation exercise, revise their SOPs against it, and find at adoption that the two clauses no document satisfies are the contract right they did not negotiate and the reviewer they do not employ.