21 CFR Part 11 for AI: Validating LLM and RAG Systems

The Short Answer

21 CFR Part 11 does not regulate technology. It regulates electronic records and signatures created in support of a predicate rule. So the question is never “is our LLM compliant” - it is does this system create, modify or maintain a GxP record. If it does, Part 11 applies to that record no matter what produced it.

The genuinely hard part is not audit trails or signatures, both of which are ordinary engineering. It is that Part 11 assumes a system you can validate to a fixed expected output, and a language model is not that. The resolution is to stop trying to validate the model and validate the system around it - with performance specified statistically against a frozen evaluation set, and deterministic controls the model cannot override.

What Part 11 Actually Asks Of You

Stripped of the compliance-vendor framing, Part 11 asks a small number of concrete questions. Each one has a specific answer in an LLM system, and the answers are more different from conventional software than most guidance admits.

How Do You Validate Something Non-Deterministic?

This is the question that stalls most pharmaceutical AI projects, and it is usually framed as though it has no answer. It does. You stop treating the model as the unit of validation.

A conventional validated system is specified as: given input X, the system returns Y. A language model cannot be specified that way, and pretending otherwise produces validation documents that are false on the day they are signed. The workable specification is statistical and bounded:

• A frozen, versioned evaluation set. Real inputs from the actual workflow, with expected outputs agreed by the people who own the process. This is the durable asset - far more so than any tool, as covered in LLM observability and evaluation tools.
• A threshold agreed before testing, not after. Deciding what “good enough” means once you have seen the results is how validation becomes theatre.
• Separate scores for retrieval and generation. A system that retrieves the wrong document and summarises it beautifully fails for a completely different reason than one that retrieves correctly and overstates the conclusion. One combined number hides both.
• Revalidation triggers written down. Model version, prompt, chunking strategy, retrieval parameters, and reranker are all configuration. If any changes, the validated system is not the running system.

The FDA’s Computer Software Assurance guidance, finalised in February 2026, supports this. It replaces documentation-heavy validation with assurance effort proportionate to patient-safety and product-quality risk. For AI that distinction is unusually valuable, because the same model can be high-risk in one workflow and trivial in another - and CSA lets you validate the risky path properly rather than spreading equal paperwork across both.

The Part That Actually Wins Review: A Deterministic Layer

The single most useful architectural decision in a regulated AI system is to put controls outside the model that the model cannot override. Not prompt instructions - code.

In practice that means the system refuses rather than improvises when retrieval returns nothing relevant; every claim carries a source identifier resolvable back to a specific document and version; and confidence thresholds are enforced by the application, not requested in a prompt. A reviewer can inspect and test all three. None of them depends on the model behaving well on the day.

This is the same principle behind the deterministic override layer in SystemAudit, which caps scores it cannot substantiate and deletes findings it cannot prove - and behind the published hallucination benchmarks, where 0 of 297 citations across six public suites were fabricated. In a GxP context the value of that structure is not the accuracy number. It is that the control is inspectable: you can show a reviewer the rule, not just the result.

What Goes In The Audit Trail

Most teams log the answer. That is not enough to reconstruct a decision, and reconstructability is the whole point of the requirement. To explain, months later, why the system said what it said, the record needs:

• The input, exactly as submitted
• The retrieved context, with source document identifiers and versions
• Model identifier and version, and the prompt template version
• The output as returned, before any downstream formatting
• The human review event - who saw it, what they changed, what they approved

The version detail matters more than it looks. If a source document is revised after the fact, an audit trail that records only the document ID will reconstruct the wrong answer - it will show the system citing text that did not exist when it answered.

On the pharmaceutical platform I worked on, this was implemented as 365-day immutable retention in CloudWatch. The retention period came from the predicate rule; the property that mattered was immutability, not the storage technology. Any store that cannot be edited after write will do.

What Actually Blocks Approval

Across regulated engagements, the objections that stop AI systems are consistently architectural rather than statistical. Accuracy is the easiest thing to evidence, because it can be measured. The three that hurt:

1. No reconstructible record. The answer was logged; the retrieved context was not. Nobody can now explain the output. This is unfixable retrospectively - the evidence was never captured.
2. Data flows that cannot be shown to isolate. A shared vector index across tenants or environments, with isolation asserted rather than enforced. On a pharmaceutical engagement, closing exactly this class of gap - cross-tenant isolation plus prompt-injection guardrails - was what moved the platform from blocked to 24 of 24 acceptance criteria passed and Part 11 readiness.
3. No change control over prompts and models. The system was validated in March against a model version the provider has since deprecated, and nobody recorded the swap. The validated system and the running system are different systems.

Scoping: Which Parts Are Even In Scope?

The cheapest compliance decision available is architectural: keep the model out of the record path where the workflow allows it.

A retrieval assistant that helps a reviewer find the relevant SOP section, where the reviewer then reads it and records their own determination, is a search tool. The record is the human’s. The same model writing a deviation summary that is stored as part of the deviation record is inside the record path, and everything above applies.

These are often the same underlying system with a different output destination - and teams routinely take on the second scope when the first would have met the business need. Decide deliberately, and write the decision down, because a reviewer will ask.

Frequently Asked Questions

Does 21 CFR Part 11 apply to LLM and RAG systems?

Part 11 applies to the electronic records and signatures a system creates, modifies, maintains or transmits in support of a predicate rule - not to the technology used. So the question is never “is the LLM regulated”; it is whether this system produces or alters GxP records. A RAG assistant that only summarises documents for a human who then makes and records the decision usually sits outside the record path. The moment its output is stored as part of a batch record, deviation report or validation document, Part 11 applies to that record - and the model became a records system.

How do you validate a non-deterministic system like an LLM?

You do not validate the model to a fixed output. You validate the system around it and specify performance statistically: a versioned frozen evaluation set with a threshold agreed before testing; deterministic controls the model cannot override, such as refusing when retrieval returns nothing relevant; and change control treating model version, prompt and retrieval parameters as configuration items requiring revalidation. The FDA Computer Software Assurance guidance finalised in February 2026 supports this - risk-based assurance proportionate to patient-safety impact rather than documentation volume.

What audit trail does an AI system need for Part 11?

A secure, computer-generated, time-stamped trail that records who did what and when, is independent of the operator, and does not obscure previous entries. For an LLM system the meaningful record is larger than the answer: input, retrieved context with source identifiers and versions, model and prompt version, output, and any human review or override. On the pharmaceutical platform I worked on this was 365-day immutable CloudWatch retention - immutability was the property that mattered, not the storage technology.

Is CSA different from CSV for AI systems?

Yes, and the difference matters more for AI than for conventional software. Traditional validation tends to produce documentation proportionate to system size. Computer Software Assurance, finalised by the FDA in February 2026, asks you to spend assurance effort in proportion to patient-safety and product-quality risk, using critical thinking and unscripted testing where appropriate. For an LLM feature that is high risk in one workflow and trivial in another, CSA lets you validate the risky path properly instead of spreading equal documentation across both.

Can an AI system apply an electronic signature under Part 11?

No. An electronic signature must be uniquely attributable to an individual person and cannot be reused by or reassigned to anyone else. A model is not a person and cannot hold one. The pattern that works is that the AI drafts and a named human signs, with the audit trail recording the machine-generated content and the human attestation as separate events. Designing this in early is straightforward; retrofitting it after a system has been signing records automatically is not.

What usually blocks an AI system from passing GxP review?

Three things, none of which is model accuracy: no reconstructible record, because the retrieved context was never logged; data flows that cannot be shown to isolate regulated data; and no change control over prompts and model versions, so the validated system is not the system in production. Accuracy is the easiest of these to evidence because it can be measured. The other three are architectural and expensive to add late.

Design For It, Or Pay For It Later

Almost everything above is inexpensive if decided at architecture time and expensive or impossible afterwards. An audit trail that was never captured cannot be reconstructed. An isolation boundary added after go-live means revalidation. A signature model retrofitted onto a system that has been auto-approving records means reopening every record it touched.

None of this is a reason to avoid AI in regulated environments. It is a reason to decide scope and record path first, and build second. If you are weighing an AI system that will touch GxP records, the deterministic-controls approach and the published benchmark runs are the two things I would look at before anything else - including mine.