The validation decision most pharma teams get wrong

Most pharmaceutical organisations validate every AI system the same way: apply the full Computer System Validation (CSV) lifecycle — requirements, design, IQ, OQ, PQ, traceability matrices, regression testing — regardless of what the system actually does. This default is understandable. It feels safe. And it is, in many cases, a misallocation of months of engineering and quality assurance effort toward systems that do not require it.

The FDA’s Computer Software Assurance (CSA) framework, formalised in the September 2022 final guidance, exists precisely because full CSV applied uniformly creates validation burden disproportionate to risk. CSA is not a shortcut — it is a risk-proportionate alternative that applies critical thinking before applying documentation. The distinction matters because teams that default to full CSV for every system delay AI deployments by months for no regulatory benefit, while teams that misapply CSA to high-risk systems create genuine compliance gaps.

The FDA issued over 3,500 warning letters related to GMP violations between 2019 and 2023, with data integrity findings present in approximately 65% of them (FDA Inspection Observations database). EudraLex Volume 4 Annex 11 has been cited in more than 200 regulatory actions across EU member states since its 2011 revision.

We see both failure modes in practice. The more common one, by a significant margin, is over-validation: teams that apply full CSV to a non-GxP data visualisation dashboard or an auxiliary scheduling tool simply because it runs in a pharmaceutical environment. The rarer but more consequential failure is under-validation: teams that hear “CSA means less documentation” and apply it to GxP-critical process control systems that genuinely require comprehensive validation evidence. According to an ISPE industry survey (2023), organisations that adopted CSA reported a 40% reduction in average validation cycle time for low-to-moderate-risk systems compared to traditional CSV.

How CSA differs from traditional CSV

CSV, as traditionally practised under GAMP 5 and 21 CFR Part 11, is a documentation-intensive lifecycle. Every requirement traces to a test case. Every test case traces to evidence. The validation package for a single system can run to hundreds of pages, and the maintenance burden — revalidation on every change — compounds over time.

CSA does not eliminate this lifecycle. What it does is make the intensity proportional to risk. The FDA’s CSA guidance introduces a risk-based framework where the validation approach scales with the system’s impact on product quality and patient safety:

• High-risk systems (direct GxP impact on product quality, patient safety, or data integrity): full validation with comprehensive documentation, scripted testing, and formal traceability. These systems still look like traditional CSV in practice.
• Moderate-risk systems (indirect GxP impact, supporting quality processes but not directly controlling them): risk-based testing with documented rationale, but without exhaustive scripted test cases for every requirement. Unscripted testing — exploratory, ad hoc, or error-based approaches — is explicitly acceptable under the guidance.
• Low-risk systems (no GxP impact, or GxP impact fully mitigated by other controls): minimal documentation. The validation evidence may be as simple as a risk assessment that documents why comprehensive testing is not warranted.

The critical shift is philosophical: CSV asks “have we documented everything?” while CSA asks “have we tested the right things?” Both questions are valid. The problem is that CSV’s question, applied uniformly, produces compliance theatre for low-risk systems and genuine assurance for high-risk ones — at the same documentation cost for both.

When full CSV validation is the right approach

Full CSV is not obsolete. For AI systems that directly affect product quality or patient safety, the comprehensive validation lifecycle remains the appropriate — and in many regulatory contexts, the expected — approach.

Specific conditions that warrant full CSV for an AI system in pharma:

The system makes autonomous decisions affecting batch release. If an AI model determines whether a pharmaceutical batch meets quality specifications — and that determination feeds directly into the release decision — the model is GxP-critical. Its training data, inference logic, and output handling all require documented validation with traceable test evidence. This includes AI-based in-process control systems that adjust manufacturing parameters (temperature, pressure, fill volume) without human review of each adjustment.

The system generates or modifies GxP-regulated records. Under 21 CFR Part 11 and EU GMP Annex 11, electronic records used for regulatory submissions or quality decisions must maintain data integrity throughout their lifecycle. An AI system that generates batch records, creates deviation reports, or modifies validated data requires the same documentation controls as any GxP record system — plus additional controls for the model’s behaviour over time, since ML models can drift in ways that deterministic software cannot.

The system operates as the sole quality control gate. When an AI vision system is the only barrier between a defective product and a patient — with no human inspector as a secondary check — the validation burden is proportionally high. The visual inspection systems used in sterile injectable manufacturing are a clear example: the consequence of a missed defect is direct patient harm, and the validation evidence must be commensurate with that risk.

In our experience, a clear minority of AI systems in pharmaceutical environments — often fewer than one in four — genuinely require full CSV-level validation. The remaining systems are candidates for CSA’s risk-proportionate approach, but identifying which systems fall into which category is the decision that most organisations skip entirely.

What documentation does cGMP demand for AI systems?

Whether a team chooses CSA or full CSV, certain documentation requirements are non-negotiable for AI systems operating in cGMP (current Good Manufacturing Practice) environments. These requirements derive from 21 CFR Parts 210/211, EU GMP Annex 11, and the ISPE GAMP 5 Second Edition guidance for AI/ML systems.

Model lifecycle documentation. Traditional software is deterministic: the same input produces the same output, and validation evidence from version 1.0 applies until the code changes. ML models break this assumption — they learn from data, and their behaviour changes when retrained. cGMP documentation for AI systems must include the training dataset provenance and quality assessment, the model architecture and hyperparameter selection rationale, the acceptance criteria for model performance (not just accuracy — false positive rate, false negative rate, and domain-specific metrics that matter for the specific manufacturing context), and the revalidation triggers for model updates. This requirement applies under both CSA and CSV; the difference is how much scripted test evidence accompanies each element.

Change control for model retraining. Every model retrain is a change to the validated system. Under traditional CSV, this triggers a change control process that may require regression testing of the full validation package. Under CSA, the change control process is risk-proportionate: a model retrain on new production data may require only performance verification against the acceptance criteria, documented with a risk assessment justifying why full regression is not warranted. The documentation burden differs substantially between the two approaches, but the requirement for documented change control does not.

Ongoing performance monitoring. cGMP environments require periodic review of computerised systems (EU GMP Annex 11, Section 11). For AI systems, this translates to continuous performance monitoring — tracking model accuracy, data drift, and failure patterns against the documented acceptance criteria. The validation-ready AI frameworks we have described for GxP operations must include monitoring infrastructure as a validation requirement, not as an operational afterthought. An AI system without performance monitoring is a system that cannot demonstrate ongoing compliance — regardless of how thorough the initial validation was.

Audit trail integrity. Both CSA and CSV require that AI system actions are traceable. For ML models, this means recording which model version produced which output, what input data was used, and whether the output was accepted or overridden by a human operator. In manufacturing environments where AI-based quality control systems inspect pharmaceutical packaging, the audit trail must link each inspection decision to the specific model version and input image — not just the pass/fail outcome.

Applying the decision per system, not per organisation

The CSA-versus-CSV decision is not binary for most organisations. A pharmaceutical company deploying multiple AI systems across manufacturing, quality, and laboratory operations will likely use both approaches — full CSV for high-risk GxP-critical systems and CSA for everything else.

The decision criteria, applied per system:

Risk classification drives the approach. Assess each AI system against three dimensions: product quality impact, patient safety impact, and data integrity impact. Systems with direct impact on any of these dimensions warrant full CSV. Systems with indirect or mitigated impact are CSA candidates. Systems with no GxP impact may not require formal validation at all — a documented risk assessment that explains why is sufficient.

Regulatory jurisdiction affects expectations. The FDA’s CSA guidance is explicit and relatively permissive toward risk-based approaches. The EMA and EU GMP Annex 11 framework is compatible with CSA principles but uses different terminology and emphasises different controls — particularly around data integrity and electronic signatures. Teams operating across both jurisdictions need a validation strategy that satisfies the more demanding framework per system, which is not always the same one for every control.

Organisational maturity determines feasibility. CSA requires quality teams to make risk-based judgments rather than following prescriptive checklists. This is a capability, not merely a policy change. Organisations whose quality function is accustomed to “validate everything the same way” need training and parallel practice before CSA produces better outcomes than their existing CSV default. We find that the transition typically takes six to twelve months of parallel operation before teams trust — and are competent in — the risk-based approach.

The cost of getting this decision wrong runs in both directions. Over-validation delays AI deployment by months per system and consumes quality engineering resources on documentation that adds no regulatory value. Under-validation creates compliance gaps that surface during inspections — and in pharmaceutical manufacturing, inspection findings carry concrete business consequences including warning letters, consent decrees, and import alerts.

The path between these two failure modes is a system-by-system regulatory scope assessment that maps which validation approach each AI deployment requires before the validation effort begins. A GxP Regulatory Scope Analysis identifies that boundary for each system in the pipeline.