Computerized systems validation (CSV) is the documented process of proving that a computerised system consistently performs as intended and complies with the GxP requirements that apply to it. Regulators look at whether the system is demonstrably in a continuously controlled state, not at the size of validation binders.

This is the practical reason pharma engineering teams need to understand validation themselves.

Computer system validation in pharma, and the part that falls to engineering

Validation under GAMP 5 is a lifecycle activity. It starts with system concept and continues through retirement, not as a test campaign at the end of implementation. A computerised system stays compliant only while it is actively managed: selection, implementation, operation, controlled change and retirement. Validation has to show the system is fit for its intended use in the specific GMP process it supports, not for every function it technically offers.

The division of work below is our judgement rather than a rule. For AI models, the EU’s draft Annex 22 asks process experts, QA, data scientists, IT and consultants to cooperate closely, with defined responsibilities and appropriate access. For Category 5 software, regulators expect active QA involvement throughout design, and this is where validation and software engineering overlap.

Work	Usually owned by	Why
Intended use, URS sign-off, risk acceptance	QA and process owners, with engineering input	They own the GxP process the system serves
Audit trail, access control, e-signatures, configuration control	Engineering	MHRA expects system design to provide for audit trails
Design specs, unit and integration tests, traceability links	Engineering	They are produced while building, or reconstructed badly later
IQ/OQ/PQ execution and approval	Shared: engineering supplies scripts and environments, QA approves	Independence of review matters more than who types the protocol
Periodic review, audit trail review	QA, with engineering tooling	Draft Annex 11 wants audit trail reviews done by personnel not involved in the activities reviewed

For a wider orientation on the regulatory vocabulary, our guide to GxP validation for pharma software covers the terms, and validation versus verification explains why the two are tested differently on AI systems.

How do GAMP 5 guidelines relate to Part 11 and Annex 11?

GAMP 5 is the method, and Part 11 and Annex 11 are the requirements. GAMP 5 is ISPE industry guidance on validating computerised systems with a risk-based lifecycle approach, 21 CFR Part 11 is the FDA regulation on electronic records and signatures, and EU GMP Annex 11 sets requirements for computerised systems in GMP environments; in practice GAMP 5 supplies the method for meeting both. GAMP 5 itself is advisory and carries no legal obligation, although regulators including the FDA reference it. It does not replace Annex 11 or Part 11.

The two regulations differ in emphasis. Part 11 is mainly about record integrity and signature equivalence, while Annex 11 governs the whole system lifecycle, including validation, backup, disaster recovery, security and retirement.

The second edition of GAMP 5 was published in 2022. ISPE describes it as adding guidance on AI/ML, blockchain, cloud and open-source software, and as applying computer software assurance (CSA) concepts from the FDA CDRH Case for Quality programme. It includes a new appendix on AI/ML for ensuring fitness for use in a GxP environment. ISPE released a dedicated GAMP Guide on Artificial Intelligence in July 2025. Our article on applying the GAMP guide to automated systems covers its structure in more depth.

Binding text versus drafts

Engineers need to know which documents are in force, because a design built to a draft is a choice, not an obligation.

• 21 CFR Part 11 is US federal regulation. Its §11.10(a) requires validation of systems that create, modify, maintain or transmit electronic records.
• EU GMP Annex 11 (2011) requires the application to be validated and IT infrastructure to be qualified.
• Revised Annex 11 and new Annex 22 (AI) were drafted by the EMA GMDP Inspectors Working Group in cooperation with PIC/S.

FDA’s scope and application guidance says the agency does not intend to enforce Part 11’s validation, audit trail, record retention and record copying requirements as explained there, but records must still meet the underlying predicate rules. Audit trail discretion likewise leaves predicate-rule requirements on date, time, sequencing and not obscuring previous entries fully in place. FDA still enforces access limits, operational, authority and device checks, and the electronic signature provisions. Enforcement discretion is a caveat on scope, not permission to ship without an audit trail.

CSA does not replace CSV; it challenges testing that reduces no risk, and a company applying GAMP 5 correctly is already aligned with it. FDA’s CSA guidance, written for medical device production and quality system software, says manufacturers may consider scripted testing, or a hybrid of scripted and unscripted testing, for high process risk functions. When CSA is enough for an AI component and when full CSV is still needed is covered in our piece on CSA’s scope across the AI lifecycle.

Which GAMP 5 category is the system, and how much validation does it need?

GAMP 5 categories scale validation effort with risk: the higher the category, the more specification and verification work the project carries. Category 2 (firmware) was removed, leaving four active categories.

Category	What it covers	Typical examples	Validation focus
1: Infrastructure	Operating systems, database engines	Windows Server, Oracle databases	Configuration records and installation verification; qualified and controlled rather than functionally tested
3: Non-configured	Off-the-shelf software used as-is	Excel, a standard PDF reader in a GxP context	Installation verification and functional testing of GxP-relevant features
4: Configured	Commercial packages configured, not coded	ERP, LIMS	Proving your configuration is correct, traceable and risk-justified
5: Custom	Bespoke or heavily customised code	In-house applications; AI/ML systems generally	Design and code level validation, unit through IQ/OQ/PQ, no “the vendor is validated” excuse

Anything that makes automated decisions without human verification is treated at the Category 5 level.

Which controls do validation reviewers expect to find in the system itself?

MHRA’s guidance says audit trails identified as required by risk assessment should be switched on, users should not be able to amend or disable them, and any administrator change to them should be recorded. The FDA’s May 2018 warning letter to Reine Lifescience shows what happens otherwise: the investigator found the audit trail disabled on quality control instruments, including an HPLC system, and a QA executive who also ran analytical tests had administrator access to each system.

Diagnostic checklist: audit trail and access controls

• Unique, personal accounts. GoValidation’s Part 11 FAQ describes shared logins as a direct Part 11 violation and a consistent FDA warning letter finding. Draft Annex 11 tolerates shared accounts only for read-only access.
• System-generated, synchronised timestamps. The clock is generated by the system, not entered by the user, and synchronised across servers to a documented source.
• Who, what, when and why. The trail records the user and their role, the old and new values and the date and time, and prompts for the reason for a change. Part 11 audit trails must capture original and new values and the user identity, and users cannot modify or delete them.
• Locked trail, logged settings changes. Draft Annex 11 wants the audit trail enabled and locked at all times, with changes to its settings or system time creating an entry themselves, made only by an administrator not involved in GMP activities.
• Admin rights away from data owners. MHRA says administrator rights should not go to anyone involved in generating, reviewing or approving the data. Draft Annex 11 frames this as segregation of duties plus least privilege.
• Separate storage. Accounts that can modify production records should not have write access to log storage, ideally held on separate infrastructure with different administrative credentials.
• Recorded access history. Annex 11 (2011) requires creation, change and cancellation of access authorisations to be recorded.
• Controlled change. Draft Annex 11 requires changes to configuration, hardware, software, platform and operating system to follow defined procedures, with significant changes re-qualified.
• Reviewable trail. Annex 11 (2011) requires audit trails to be available, convertible to an intelligible form and regularly reviewed.

MHRA does not accept vendor validation data in isolation from system configuration and intended use.

Making tamper evidence provable, not asserted

One concrete design is a hash chain that links each event to the previous one, with optional per-writer signatures for multi-writer provenance. In the reference implementation by the authors of Audit Trails for Accountability in Large Language Models, each record’s hash is a SHA-256 digest over the event payload plus the previous hash, which makes modification or deletion detectable. Auditors can replay the chain to confirm the trail has not been altered or truncated.

Detection only happens when someone checks. So the engineering deliverable is the chain plus a scheduled verification job whose results land in the review record. Expect testers to try to break it: FDA’s CSA guidance gives unscripted testing that attempts to delete the audit trail as an example assurance activity.

Which validation deliverables (user requirements, risk assessment, IQ/OQ/PQ, traceability matrix) should engineering produce as part of the build, not after it?

Engineering should produce the specifications, risk records, traceability and test evidence as the system is built, because each one references design decisions that are hard to reconstruct afterwards. The V-model pairs each specification with a qualification: PQ verifies user requirements, OQ verifies functional specifications and IQ maps to design specifications. GAMP 5 does not mandate a linear V-model and permits Agile and CI/CD delivery, provided traceability and risk justification stay intact.

1. User requirements (URS). Draft Annex 11 expects an approved URS whether the system is built in-house, bought, or provided as a service, and whether delivery is linear or iterative.
2. Risk assessment. FDA recommends basing the validation approach on a justified, documented risk assessment of the system’s potential effect on product quality, safety and record integrity. Annex 11 requires manufacturers to justify standards, protocols and acceptance criteria from that assessment.
3. Functional and design specifications. For Category 5, regulators expect design-level traceability and code logic review, not only URS and test protocols.
4. Traceability matrix. Documented links between requirements, design specifications and test cases should be established and maintained. Missing forward and backward tracing appears among the common computerised system compliance failures listed by Scilife.
5. Test records. FDA’s CSA guidance asks the assurance record to hold the intended use, the risk analysis, a description of testing, issues found and a conclusion on acceptability, signed for high process risk functions.
6. Release provenance. A provenance record links the artefact to its commit, build environment, dependency lockfile digest, test summary, approvals and checksum. For GxP workflows the evidence bundle adds traceability links, risk assessments, validation records and change-control references.
7. Retention configured on purpose. Most CI/CD platforms keep logs and artefacts for 30 to 90 days by default, far shorter than a medical device maker’s audit-trail retention window under 21 CFR 820.

If those seven exist when the code is done, IQ/OQ/PQ becomes execution and sign-off rather than archaeology.

How does computer system validation apply to AI/ML components that change when retrained?

Draft Annex 11 requires any change to a computerised system’s software components to follow defined procedures, with significant changes re-qualified and re-validated. The question is how to keep that tractable when retraining is routine. GAMP 5’s second edition, as summarised by GMP Insiders, expects adaptive systems to have defined control boundaries, human oversight and documented explainability, classifies AI/ML software generally as Category 5, and requires validation to account for performance drift.

Draft Annex 22 applies to AI models in critical GMP applications affecting patient safety, product quality or data integrity. It covers static models only and says dynamic models that learn during use should not be used in critical GMP applications. Its other requirements include intended use, performance metrics, training data quality, test data management and continuous oversight with change control.

What keeps a model in a validated state, in engineering terms:

• Configuration control at deployment. A tested model goes under configuration control before deployment, with measures to detect unauthorised change.
• Independent test data. Test data must not be used in development, training or validation of the model, enforced by technical or procedural controls. FDA’s January 2025 draft guidance on AI for drug regulatory decisions says the same about test data independence.
• Version tracking for code. The same FDA draft asks how software version changes were tracked.
• Planned lifecycle maintenance. It also asks for performance metrics, a risk-based monitoring frequency and retest triggers to be documented in the site’s pharmaceutical quality system, with ongoing monitoring because AI models can be highly sensitive to input changes.

The device side offers a useful pattern, provided it is read as device guidance. FDA’s discussion paper on AI/ML software as a medical device separates locked algorithms, which return the same output for the same input, from adaptive ones. It proposes a predetermined change control plan made of pre-specifications and an algorithm change protocol for implementing anticipated modifications in a controlled way. That protocol includes test dataset sequestration and access control as data is added, plus version tracking and user notification for updates. In pharma manufacturing the same idea maps onto a pre-approved retraining envelope inside change control, which is our reading rather than a regulatory equivalence.

Registry gates that hold up under review

The following is design judgement. We would make promotion to production impossible until an approval event exists, recorded with the decision owner, rationale, scope and supporting artefacts. Policy-as-code can confirm that required tests passed and required approvers signed before promotion. The person who trains or writes the model should not be the only person able to approve its deployment. Gates should also be safe to retry: reject a repeated request that reuses the same key with a different payload, and keep keys for the full replay horizon of the process.

Generative models pose a challenge to traditional computer system validation. Speakers at ISPE’s AI in Life Sciences summit proposed factual consistency, hallucination rate, prompt sensitivity and robustness as GxP-relevant measures aligned with the draft Annex 22. Our article on CSV for AI workflows in practice covers the workflow side, and validation-ready AI for GxP operations covers how to scope a project so it reaches validation at all.

The validated state is an architectural property

The approval-grade evidence a validation reviewer reads is itself an engineering output: traceability, lineage and a record a non-engineer can sign against. TechnoLynx builds that evidence as engineering, alongside the AI system, for life sciences and healthcare teams; it is not regulatory sign-off or certification.

The question to settle before writing a single protocol is narrower than “are we compliant?” Does every path by which it changes (retraining, configuration, a dependency bump) pass through a gate that records who approved it? If one path bypasses the gate, the system’s validated state lasts only until that path is first used.