Annex 11 does not tell you to buy a validated system. It tells you to prove, in your own environment and for your own process, that the computerised system does what you claim it does — and keeps doing it after the vendor ships the next update. That distinction is where most compliance trouble starts, because teams treat “the supplier validated it” as if it discharged their obligation. It doesn’t. EU GMP Annex 11 is the section of the European Union’s Good Manufacturing Practice guidelines that governs computerised systems used in regulated pharmaceutical activities. It applies whenever a computerised system replaces a manual operation that affects product quality, patient safety, or data integrity. The rule is short — a few pages — but its interpretation drives a large share of the engineering and documentation work in any pharma software project. When AI and machine-learning components enter the picture, the short text starts asking questions the original 2011 revision never anticipated. What does EU GMP Annex 11 actually require? Annex 11 is principles-based, not prescriptive. It does not list approved products or mandate specific technologies. Instead it defines outcomes the manufacturer must be able to demonstrate. The recurring theme is fitness for intended use, proven and maintained. The clauses cluster into a handful of obligations that matter in practice: Risk management across the lifecycle. Validation effort must be scaled to the risk the system poses to patient safety, product quality, and data integrity. A system that controls sterilisation cycles is not documented the same way as one that schedules meeting rooms. A documented supplier relationship. If you rely on a vendor, you need a quality agreement and evidence — an audit, a certificate, or documented assessment — that the vendor’s own development and quality practices are adequate. Reliance is allowed; blind reliance is not. Validation with a documented rationale. The manufacturer must hold current documentation showing the system was validated for its intended use, including a defensible account of why the chosen test coverage is sufficient. Data integrity controls. Accurate, complete, legible, and durable records, with the ability to produce clear printed or exportable copies for inspection. Audit trails. For GMP-relevant data, the system must record who did what, when, and — where changes are made — the previous value. Audit trails must be reviewed, not merely captured. Access control and electronic signatures. Authority levels enforced, identity established, and signatures that carry the same weight and permanence as handwritten ones. Change and configuration management. Changes are controlled, assessed for impact, and re-validated proportionally. Business continuity. If the system fails, the process must survive — through documented manual procedures or redundancy — without losing data or product. None of these are exotic. What trips teams up is that Annex 11 expects them to be demonstrable on demand, not merely present in principle. Why “the vendor validated it” is the most common Annex 11 mistake The single most frequent failure we see is the assumption that a purchased, “GMP-ready” or “21 CFR Part 11 compliant” system arrives pre-validated. It does not. Validation under Annex 11 is a statement about your intended use in your process. A vendor can validate that a feature works as specified; only you can validate that the feature does the job your quality system depends on. This maps directly onto the categorisation logic that most European pharma teams already use through GAMP 5. The amount and shape of the evidence you owe depends on how much of the system is standard, configured, or custom-built — a judgement we work through in detail in how to classify and validate AI/ML software under GAMP 5 in GxP environments. A configurable system with your own workflow logic layered on top carries more of your own validation burden than an off-the-shelf calculation, and far more than a locked appliance. The correct framing is a division of evidence, not a transfer of responsibility. The supplier’s assessment covers the platform’s baseline behaviour; your validation covers configuration, integration, data flows, and the specific decisions your process makes with the system’s output. When an inspector asks how you know the system is fit for purpose, “the vendor said so” is not an answer they accept — and it is not one the guideline permits. Annex 11 obligations by system risk: a working rubric Because Annex 11 scales effort to risk, the practical question is never “is this validated?” but “how much evidence does this system, at this risk level, require?” The table below is a planning rubric we use to shape the initial scope of a computerised-system validation. It is a starting frame, not a substitute for a documented risk assessment. Obligation Low risk (indirect quality impact) Medium risk (quality-affecting, human-reviewed output) High risk (direct control, autonomous or safety-critical) Risk assessment Documented rationale, lightweight Formal functional risk assessment Full FMEA-style assessment, revisited on change Validation depth Verify configuration + intended use Functional + integration + data-flow testing Above, plus challenge/edge-case and failure-mode testing Audit trail Capture; periodic review Capture; routine documented review Capture; reviewed as part of batch release Supplier evidence Documented assessment Assessment + quality agreement Audit or equivalent deep assessment Change control Standard change process Impact assessment + partial re-validation Impact assessment + targeted re-validation + regression check Business continuity Documented manual fallback Tested fallback procedure Redundancy or validated failover, tested periodically The risk classification itself is the decision that governs everything downstream. Getting it wrong in the conservative direction wastes months on documentation nobody will ever read; getting it wrong in the permissive direction leaves a gap an inspector will find. This is the same tension that plays out in the choice between a streamlined, assurance-led approach and exhaustive scripted testing, which we treat separately in when to use CSA versus full CSV for AI systems in pharma. Where AI and machine learning strain the text of Annex 11 Annex 11 was written for deterministic software. A traditional computerised system, given the same input, produces the same output every time — which is exactly what makes its validation tractable. You define the intended use, test against it, lock the configuration, and control change. Machine-learning components break several of those assumptions at once. Consider a vision model performing automated visual inspection on a filling line — a use case we cover in depth in how computer vision replaces manual visual inspection in pharmaceutical quality control. The model is not a fixed algorithm you can read line by line; it is a set of learned weights whose behaviour on unseen inputs is characterised statistically, not proven exhaustively. Annex 11’s audit-trail clause assumes a system state you can inspect and a change you can attribute. A model retrained on new data is a change — but the “previous value” and the causal chain are harder to express than an edited field in a database. Three specific tensions recur when this issue arises in practice: Intended use has to be pinned to a version. The validated artefact is not “the model” but a specific frozen version with a documented training set, evaluation protocol, and performance envelope. Retraining is a change-control event, not routine maintenance. Test coverage becomes a statistical argument. You cannot enumerate all inputs. The defensible position is a representative, risk-weighted evaluation set with documented acceptance criteria — reported as an operational measurement against that named test set, not as an open-ended claim of accuracy. The audit trail must capture the pipeline, not just the UI. For a learning system, data provenance, model version, and configuration together form the record that matters. If your audit trail only logs the front-end action, you have not captured the GMP-relevant event. These are not reasons to keep AI out of regulated manufacturing. They are the reasons that determine whether an AI deployment holds up under inspection or collapses at the first data-integrity question. The broader question of what GxP compliance genuinely demands of AI software — beyond Annex 11 specifically — is the subject of what GxP compliance actually requires for AI software in pharmaceutical manufacturing, and it is the layer most vendor claims quietly skip. Reading the audit-trail clause correctly Audit trails are where paper compliance and real compliance diverge most sharply. Annex 11 requires that changes to GMP-relevant data be recorded with the operator, the timestamp, and the prior value, and — critically — that these trails be reviewed. Capturing an audit trail nobody reads satisfies the letter and fails the intent. In our experience across life-sciences engagements, the recurring gap is not missing logging but missing reviewability. A system that writes millions of low-value events into an undifferentiated log has technically produced an audit trail and practically produced noise. The engineering task is to make the GMP-relevant events distinguishable, filterable, and reviewable at batch-release cadence without a human reading everything. That is a design decision made early, not a report generated late — and it is far cheaper to build in than to retrofit after a finding. The same reviewability principle scales beyond pharma manufacturing into any regulated workflow where the record is the product of the system’s decisions; the boundary between what a “compliant” label covers and what you still have to engineer is drawn out in what makes an AI or video workflow HIPAA- or GxP-ready — and what it doesn’t. FAQ Does EU GMP Annex 11 apply to systems hosted in the cloud or by a third party? Yes. Annex 11 applies to the computerised system regardless of where it runs. Outsourcing the infrastructure or the software does not outsource the obligation. You need a documented agreement defining responsibilities, evidence that the provider’s practices are adequate, and assurance that data integrity, access control, and continuity requirements are met in the hosted environment. Is a “21 CFR Part 11 compliant” or “GMP-ready” product automatically Annex 11 compliant? No. Those labels describe capabilities the product can support — such as audit trails and electronic signatures — not a validation of your intended use. Annex 11 compliance is a property of how the system is configured, integrated, and validated within your specific process. The vendor’s evidence covers the platform baseline; your validation covers everything you build on top of it. How does Annex 11 handle machine-learning systems that change over time? Annex 11 treats a validated computerised system as something with a controlled, known configuration. A machine-learning model must therefore be pinned to a specific frozen version, with its training data, evaluation protocol, and performance envelope documented as the validated artefact. Retraining is a change-control event requiring impact assessment and proportional re-validation, not routine maintenance. What does Annex 11 require for audit trails specifically? For GMP-relevant data, the system must record who made a change, when, and the previous value, in a way that cannot be altered without trace. Just as importantly, audit trails must be reviewed — capturing them without a review process satisfies the wording but not the intent. Good design makes the GMP-relevant events distinguishable and reviewable at batch-release cadence rather than burying them in undifferentiated logging. What changes once you test this yourself Annex 11 rewards teams that treat it as an engineering specification rather than a documentation exercise. The clauses about risk, validation, audit trails, and change control are all asking the same underlying question: can you demonstrate, on demand, that this system does what your process depends on it doing? For deterministic software that question has a mature answer. For learning systems it is still being negotiated — the guideline was written for software that behaves the same way twice, and models do not. The practical starting point is not the model or the tooling. It is the risk assessment that decides how much evidence you owe, followed by an honest division of that evidence between what your supplier can prove and what only you can. Get that division wrong and no amount of validation activity afterwards will close the gap an inspector is trained to find.
