AI and 21 CFR Part 11: A Clause-by-Clause Compliance Guide

Does 21 CFR Part 11 Apply to AI-Generated Records?

Yes. If a record is required by an FDA predicate rule and it exists electronically, Part 11 applies no matter what produced it. An AI system that drafts a batch deviation summary or flags an out-of-specification result is touching a record governed by the same predicate rule as if a person had typed it by hand. The mechanism doesn't change the obligation.

I get some version of this question almost every time a pharma, device, or biotech client starts piloting an AI tool inside a GxP process. Part 11 was finalized in 1997, long before anyone was running a large language model against a batch record. FDA has never amended Part 11 itself to mention AI. What FDA has done instead is publish newer guidance that sits on top of an unchanged rule: guidance on computer software assurance, on predetermined change control plans, on AI in regulatory submissions.

None of those documents is titled "AI and Part 11," and none of them replaces it. This guide connects the base regulation, the clauses that create the most friction for AI systems, and the guidance layer FDA has actually built to address the gap.

What 21 CFR Part 11 Actually Regulates

Part 11 governs electronic records and electronic signatures used to satisfy requirements that already exist elsewhere in FDA's regulations — 21 CFR 211 for drug cGMP, 21 CFR 820 for the device quality system regulation, 21 CFR 58 for GLP studies, and others. Part 11 doesn't create new record-keeping duties. It sets the conditions under which an electronic record or signature can substitute for a paper one.

The clauses that matter most, for any system, are:

• 11.10(a) — validation to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.
• 11.10(e) — computer-generated, time-stamped audit trails recording the date, time, and identity of the operator for any action that creates, modifies, or deletes an electronic record, retained as long as the record itself.
• 11.10(i) — confirmation that people who develop, maintain, or use the system have the training and experience to do so.
• 11.10(k) — controls over system documentation, including revision and change control.
• 11.70 — signature/record linking strong enough that a signature can't be excised, copied, or transferred to falsify a record.
• 11.100, 11.200, 11.300 — signature uniqueness, two-component authentication (ID plus password, or biometric), and controls over identification codes and passwords.

None of that language mentions software, algorithms, or automation method. Part 11 is written to be method-agnostic. That's exactly why it offers no instructions for a system whose outputs can change from one run to the next.

Why AI Strains Part 11's Core Assumption

FDA's 2003 guidance, "Part 11, Electronic Records; Electronic Signatures — Scope and Application," narrowed how aggressively the agency enforces Part 11. FDA said it would use enforcement discretion on some requirements, including extensive validation for certain legacy systems already in use.

But the guidance also said two things would still be enforced without exception: the ability to generate accurate and complete copies of records, and the ability to protect records so they can be accurately and readily retrieved. Those two obligations are precisely where AI systems tend to struggle. Outputs can be probabilistic, model versions drift over time, and "the record" sometimes means a snapshot of a live inference rather than a stable, static document.

Part 11 assumes a system behaves the same way today as it did yesterday, given the same inputs. Most validated GxP software honors that assumption by design. A machine learning model that gets retrained or fine-tuned on new data does not make that promise unless someone engineers it to.

Clause by Clause: Where AI Creates Risk

11.10(a) — Validation

Traditional computer system validation proves a system does what it's specified to do, every time, through scripted test cases run against known inputs and expected outputs. An adaptive or continuously learning model resists that framing directly. The same prompt can produce different outputs across model versions, and sometimes across runs of the same version, if sampling settings aren't locked down.

Validation for an AI-enabled system has to prove something narrower and more honest than "it always produces this exact output." It has to show the system operates within defined performance bounds, that drift outside those bounds gets detected, and that a human decision point exists before an AI output becomes part of the official record.

11.10(e) — Audit Trails

An audit trail has to capture who did what, when, independent of the person who did it. For AI-assisted decisions, "who" gets murky fast. If a model suggests a disposition and a quality reviewer accepts it with one click, the audit trail needs to distinguish the model's suggestion from the human's action of record.

I've reviewed audit trails that log "record approved" and nothing else. That's not enough once an algorithm is in the loop, because you can't reconstruct afterward whether the human actually evaluated the output or just clicked through it. Without that separation, you can't demonstrate the meaningful human review regulators expect.

11.10(i) — Personnel Qualification

This clause requires that people who develop, maintain, or use the system have the training and experience to do the job. Applied to AI, that means the human reviewer approving a model's output needs to understand where that model tends to fail. A reviewer who knows the software interface but not the model's failure modes — where it hallucinates, where it misclassifies edge cases — isn't qualified to serve as the check on it, no matter how fluent they are with the screen in front of them.

11.10(k) — Change Control

Standard software change control assumes discrete releases you can test and approve before deployment. A model that's periodically retrained, or a vendor-hosted large language model updated silently behind an API, breaks that assumption outright. You can't approve a change you weren't told about.

This is the exact gap FDA's predetermined change control plan framework for AI-enabled device software functions was built to close. It requires manufacturers to spell out in advance what a model is allowed to change on its own, and what triggers a new submission instead.

11.70 — Signature/Record Linking

Section 11.70 requires that a signature be bound tightly enough to its record that it can't be excised, copied, or transferred to authenticate a different record. AI complicates this in a specific way: if a model regenerates its output between the moment a reviewer reads it and the moment they sign, the signature may end up linked to a version of the record the reviewer never actually saw.

The fix has to happen at the system level, not the policy level. The signature needs to be bound to the exact output version and timestamp the reviewer reviewed, not to a live or regenerable inference.

11.100, 11.200, 11.300 — Signature Authentication

These clauses govern the human side of the equation: unique signatures, two-component authentication, and controls over credentials. They don't change for AI-assisted workflows, and that's the point worth stating plainly — an AI system cannot hold a Part 11 signature. Only a person authenticated with a unique ID plus password or a biometric can sign, per 11.200. Whatever the AI recommended, a qualified human is the one accountable for the record once it's signed.

Part 11 Clause vs. AI-Specific Risk

The Guidance Layer FDA Has Actually Built for AI

Part 11 itself stays silent on AI. FDA has built guidance around it instead of into it, and three documents matter most right now.

The Computer Software Assurance for Production and Quality System Software draft guidance, issued September 13, 2022, shifts validation away from scripted, document-everything testing and toward a risk-based approach that ties testing rigor to patient risk and process impact. That framework is friendlier to AI-enabled QMS tools than classic computer system validation, because it scales validation effort to where the actual risk sits instead of forcing exhaustive scripted testing of every possible model output.

For AI-enabled medical devices, FDA finalized the Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions guidance in December 2024. A predetermined change control plan lets a manufacturer pre-specify what a model is permitted to change post-market, within bounded performance criteria, without triggering a new 510(k) or PMA supplement every time. It's the closest thing FDA has published to an answer for "how does change control work when the software keeps learning."

On the drug and biologic side, FDA released the draft guidance "Considerations for the Use of Artificial Intelligence to Support Regulatory Decision-Making for Drug and Biological Products" on January 6, 2025, under docket FDA-2024-D-4488. It introduces a risk-based credibility assessment framework for AI models used in regulatory submissions, built around context of use, model risk, and the credibility evidence needed to support that use. It doesn't reference Part 11 by number. But any record that credibility assessment produces, and any signature applied to approve using the model's output in a submission, still has to satisfy Part 11's existing requirements.

These three documents tell you how to run validation and change control in an AI context. Part 11 still tells you what the resulting electronic records and signatures have to look like once they exist.

Practical Compliance: What to Actually Build

If you're standing up an AI tool that touches GxP records, the compliance work isn't exotic. It's the same Part 11 discipline applied to a system with a probabilistic component. In my experience, the failure point is rarely the regulation being unclear. It's teams skipping the boring parts because "it's just AI."

1. Classify the record first. Determine whether the AI system's output is itself a Part 11 record — a report, a signed disposition — or an input to a human-authored record. That decides how much of Part 11's machinery applies to the AI output directly versus to the downstream document.
2. Lock the model version in production. Don't run a validated process against a vendor's "latest" endpoint. Pin the version, document it in the validation package, and treat any version change as a change-control event under 11.10(k).
3. Separate AI suggestion from human decision in the audit trail. Log the model's output, model version, and generation timestamp as a distinct event from the human's approval action. A single combined log entry can't demonstrate meaningful review.
4. Define human-in-the-loop points explicitly, in writing. Decide where an AI output can flow straight into a record and where it requires a qualified human review and signature first.
5. Write a predetermined change control plan for anything that learns. Even outside FDA's device-specific framework, the concept transfers: specify in advance what the model may change on its own, and what triggers revalidation.
6. Train reviewers on the model's failure modes, not just its interface. 11.10(i) requires qualified personnel. A reviewer who doesn't know where a model tends to hallucinate or misclassify isn't a real check on it.

Organizations building this at the management-system level, rather than tool by tool, often map these controls into ISO/IEC 42001:2023 clause 8.1 (operational planning and control) and clause 6.1.4 (assessing AI system impacts). That gives the AI program a formal structure to sit inside. The division of labor stays clean: the ISO clauses govern how the AI system is managed day to day, and Part 11 governs what the records and signatures it touches have to look like once they're created. A structured AI risk assessment is usually the fastest way to surface which clause is actually at risk before an inspector does.

FAQ

Does 21 CFR Part 11 specifically mention artificial intelligence? No. Part 11 was finalized in 1997 and hasn't been amended to reference AI or machine learning. It applies to AI-generated or AI-assisted records the same way it applies to any electronic record, because the rule is defined by function — does it satisfy a predicate rule requirement — not by the technology that created it.

Can an AI system apply an electronic signature under Part 11? No. Part 11 signatures require a legally accountable individual, authenticated by a unique identification code plus password or a biometric, per 21 CFR 11.100 and 11.200. An AI system can generate a recommendation or draft, but only a qualified human can sign, and the audit trail needs to show that person actually reviewed what they were signing.

Do I need to revalidate every time an AI model is retrained? Not necessarily a full revalidation, but you need a documented trigger for reassessment. If you've built a predetermined change control plan that bounds what retraining can change, a retraining event within those bounds may only require confirming performance stayed inside the pre-specified limits, rather than repeating validation from scratch.

Is FDA's Computer Software Assurance guidance a substitute for Part 11 compliance? No. Computer Software Assurance changes how much testing rigor you apply during validation based on risk. It doesn't replace Part 11's requirements for audit trails, record integrity, or signature controls. Treat it as guidance on how to validate efficiently, and Part 11 as the baseline the validated system still has to meet.

How does 11.70 apply specifically to AI-generated drafts? Section 11.70 requires that a signature stay tightly bound to the exact record it authenticates. If an AI model can regenerate its output after a reviewer reads it but before they sign, the signature risks binding to a version the reviewer never saw. The control is to capture and freeze the exact output version and timestamp at the moment of review, not at the moment of signature.

What's the single most common Part 11 gap in AI-enabled systems? Audit trails that don't distinguish an AI-generated suggestion from the human action that approved it. Without that separation, you can't demonstrate the meaningful human review regulators expect before an AI output becomes part of an official GxP record.

If your organization is piloting AI inside a validated GxP environment and needs the audit trail and validation architecture mapped before an inspection finds the gap first, the healthcare and pharma AI governance practice works through exactly this kind of Part 11 mapping.

Last updated: 2026-08-18