You Can't CAPA What You Can't Classify

By Kayla Britt, Britt Biocomputing

You’ve run a pilot for your LLM-assisted deviation triage, documented the results, and are preparing to validate and deploy the system organization-wide. The context of use is clearly documented, and a risk assessment has been done. But when you’re reviewing the risk assessment and pilot testing results, you notice that in one of the runs, the LLM referenced a superseded version of the SOP in the draft deviation summary.

Sachin Bhandari recently authored a column in this publication (“CSV Assumes The AI System Sits Still — It Doesn’t”) where he identifies four assumptions from computer system validation (CSV) that probabilistic AI doesn’t inherit. He names the final assumption, silent failure, as the most dangerous of the four. In a deterministic system, failure produces an observable event: an error, downtime, a complaint. It gets logged, documented as a deviation, closed with a CAPA. A large language model (LLM) can simply fail quietly.

Now assume the good case. The failure didn’t stay silent; you found it in review. The problem starts there. CSV also assumes that when you find an error, your quality system already has a name for it.

Your quality team documents the deviation: superseded SOP referenced. But the existing categories don’t cover generative AI-specific error types. Your QMS deviation vocabulary assumes a fixed function: the system either performed its function correctly or it didn’t. Once the error is documented, the remaining step is determining, via root cause analysis (RCA), what external factor caused the error.

An LLM or agentic error can occur with no component broken in any way the QMS recognizes. Every part behaved; the system composed a wrong answer out of them. Neither “human error” nor “hardware malfunction” fits. When you conduct the root cause analysis, you settle on “hallucination.” Then you reach the corrective action stage, and again, you realize the usual tools don’t quite fit. Without a template to work from, you aren’t sure where to start your investigation.

Do you start with the model weights? The architecture around the model? If so, what part of the pipeline?

After several days of back-and-forth with the data science team, you eventually identify the true root cause: the retrieval-augmented generation (RAG) architecture retrieved the outdated SOP. On the surface, hallucination and retrieval failure are indistinguishable. Both failure modes produce fluent, looks-right-but-wrong outputs. Nowhere in the QMS does “retrieval failure” appear as a deviation classification option.

Hallucination and retrieval failure demand corrective actions in entirely different layers of the system. One sits in how the model was prompted and constrained. The other sits in a document index that never dropped the obsolete file. A team that settles on the wrong name writes a CAPA against the wrong layer — and closes it.

The Categories For AI Error: Error Type × Origination Point

Classifying a generative AI error takes two fields: the error type (what kind of error is it?) and the error origination point (in which component of the architecture did it arise?).

Both are required to accurately classify the error and identify its root cause and corrective action. In our opening example, the retrieval failure was indistinguishable from a fabrication on the surface — which is why the investigation spent days in the wrong layer.

The Probabilistic Failure Mode Taxonomy: Error Type × Origination Point

Dimension 1: Error Type — What Went Wrong

The error type axis includes six categories:

1. Fabrication — This is fluent, plausible-looking output that is not grounded in any verifiable data. Includes: citation/reference fabrication, data point fabrication, and entity fabrication.
2. Misinterpretation — Failure to draw the correct conclusions from accurate data. Includes: recognition errors, reasoning errors, and omission.
3. Contextual Misapplication — Output is outside the bounds of appropriate contextual constraints. Includes: population mismatch, temporal validity, specification noncompliance.
4. Confidence Miscalibration — An inaccurate confidence score is generated. Includes: overconfidence, under-confidence/hedging, and failure to flag conflicting evidence.
5. Boundary Violation — Actions are outside the model’s sanctioned scope, authority, or safety boundary. Includes: scope creep, authority creep, and adversarial boundary breach.
6. Subgroup Performance Failure — The output is accurate in aggregate but less accurate for subpopulations within the larger group. Includes: demographic subgroup bias, pharmacovigilance/safety-signal bias, and site/transferability bias.

Dimension 2: Origination Point — Where It Went Wrong

The origination point axis includes six categories:

1. Training Data — This is the furthest upstream source of error; any generative AI application built on a foundation model inherits provenance risk. Includes: data poisoning, data privacy, distribution shift, and source error.
2. Retrieval/RAG Layer — This occurs in the retrieval pipeline of RAG-based generative AI systems. Includes: chunking failures, embedding drift, grounded hallucination, multi-hop/complex query, and retriever-generator misalignment.
3. Model Inference — These are runtime errors that occur when training data and retrieval are sound. Includes: ungrounded generation, sycophancy/prompt sensitivity, numerical errors, non-determinism, structured output failures, and prompt injection.
4. Human-AI Interface — Errors arise from how humans interact with the AI system. Includes: automation bias, confidence miscommunication, deskilling/workflow integration, and prompt design.
5. Agent Orchestration — This occurs in the orchestration layer of multi-agent or multistep LLM systems. Includes: quality degradation across iterations, multistep planning failures, compounding propagation, and tool use errors.
6. Supplier — This is rooted in components provided by the vendor. Includes: silent model updates, deprecation, multi-tenancy leakage.

Wiring It Into The QMS

The dual-axis structure folds neatly into the format quality professionals are already familiar with: documentation of the incident, deviation generation, root cause analysis, corrective action, effectiveness check, deviation closure.

The error type axis gives practitioners a shared vocabulary for identifying the type of deviation up front, where preexisting categories no longer transfer cleanly. The origination point axis guides practitioners through the root cause analysis. It narrows a complex investigation into a structured process culminating in one of six options, with evidence tied to the origination point.

Circling back to the opening scenario, the deviation would have been documented as fabrication. This describes what the output looked like at intake: fluent, plausible, and wrong.

The RCA changes that. The summary didn’t contain a fabrication; it cited a real SOP that was outdated. The correct error type is contextual misapplication, subtype temporal validity. The deviation record must be updated to correct the error type during RCA closure.

The table below identifies the cross-functional team responsible for each investigation and the evidence that investigation needs. Corrective actions are outlined in the next section.

Opening The CAPA

After the root cause analysis is complete, you need to open a CAPA. The CAPA is determined directly from the error origination point, the RCA, and the corresponding evidence.

Retraining is largely unavailable as an option. A sponsor deploying a vendor-wrapped foundation model has no access to the training data set, no ability to adjust weights, and frequently no ability to pin a version. There is no row in the table below that changes the model, because such a row rarely exists for GMP or other regulated deployments.

Model inference appears in two different rows. Some inference failures are addressable in the harness: prompt injection, structured output failures, and ungrounded generation can be constrained by input validation, grounding requirements, and output checks. Others are properties of the architecture. Non-determinism can be bounded but not eliminated. Where the failure mode is irreducible, the corrective action is not a fix but a boundary: narrowing the context of use or adding a human verification step at the point the output is consumed. Both are legitimate closeable corrective actions.

To demonstrate the utility of the origination point axis more concretely, take an alternate version of the opening scenario. The output is identical: the superseded SOP appears in the deviation triage assessment. But the retrieval logs show the index behaved correctly. The current SOP was retrieved and passed into context. The model generated from parametric memory instead of the context it was given.

The error type is the same: contextual misapplication, temporal validity. The origination point is not model inference, subtype ungrounded generation. And the corresponding corrective action is different — output validation requiring every assertion in the summary to resolve to a retrieved chunk, with the output failing closed when it doesn’t.

Nothing about the index changes, because nothing about the index was wrong.

Without a taxonomy, every probabilistic AI error is indistinguishable from the next in the record, whatever the investigation concluded. Deviation trending is an existing expectation, not an enhancement. A quality system that cannot separate retrieval failures from inference failures cannot trend either one. It cannot detect that index governance has a systematic weakness, cannot detect that reviewer oversight is degraded, and cannot demonstrate to an inspector that it is continuously monitoring the validated system.

The classification is what makes the monitoring operationally possible.

What A Taxonomy Doesn't Do

The error taxonomy is meant to give practitioners a working basis for probabilistic deviations in GxP settings. It isn't a validation package, it doesn't tell you whether to deploy, and it will need revision as real-world case studies accumulate. Version it and put it under change control.

It also raises new questions: how do we complete an effectiveness check for a probabilistic system? Rerunning the model after the corrective action doesn’t prove or disprove whether the corrective action was effective.

Bounded reproducibility testing after the corrective action is one means of performing an effectiveness check. This involves testing a representative sample of prompts and ensuring the results fall within the preregistered acceptance criteria. The standard shifts accordingly: you are not demonstrating that the failure has been eliminated, you are demonstrating that the control designed to catch it is present and firing.

The First Step

Adding the error type categories to the deviation dropdown in your QMS is the first step. Origination point follows at RCA closure. Together, they are what makes probabilistic errors visible to trending.

You can’t see what you don’t classify, and you can’t control what you don’t see.

About The Author:

Kayla Britt is the founder of Britt Biocomputing, a consultancy advising regulated life sciences companies on validation of AI-enabled systems, including large language models and agentic AI. She is a member of the International Society for Pharmaceutical Engineering (ISPE) and the Parenteral Drug Association (PDA), and serves as founding Co-Chair of the Chesapeake Bay Area chapter of the ISPE GAMP Community of Practice (CoP) and as a member of the AI CoP Workforce Preparedness subcommittee. Before founding the firm, she conducted adversarial testing of frontier AI models. She is a co-author of a public comment to FDA Docket FDA-2026-N-4390 on the AI-Enabled Optimization of Early-Phase Clinical Trials Pilot Program. She can be reached at kayla@brittbiocomputing.com.