AI 21 CFR Part 11 Compliance: A Practical Guide

What 21 CFR Part 11 Actually Requires

21 CFR Part 11 governs electronic records and electronic signatures in FDA-regulated industries. The regulation applies whenever you use electronic records in place of paper records, or electronic signatures in place of handwritten signatures. It has been on the books since 1997. What it did not anticipate is the explosion of AI-powered tools now embedded in quality systems, manufacturing operations, and laboratory environments across pharmaceutical, biotechnology, and medical device companies.

Here is the core compliance challenge: Part 11 was written for deterministic software. AI is not deterministic. An AI model that analyzes batch records, flags deviations, or auto-generates CAPA recommendations introduces a layer of behavior that traditional Computer System Validation (CSV) frameworks were never designed to handle.

That gap is where companies get hurt on inspections.

Why AI Creates New Part 11 Problems

The regulation sets out specific requirements for electronic records under 21 CFR Part 11.10:

• Access controls limiting system use to authorized individuals (§11.10(d))
• Audit trails that capture operator actions and are computer-generated (§11.10(e))
• Authority checks to ensure only authorized individuals can use the system (§11.10(g))
• Validation to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records (§11.10(a))

Each of these requirements creates a distinct compliance problem when AI is involved.

Access control is relatively straightforward — most AI platforms support role-based access. The problem is that AI systems often pull data from multiple source systems, and the access governance across that data pipeline may not be audited end-to-end.

Audit trails are where things get complicated. Part 11 requires that audit trails capture who did what, when, and what changed. When an AI model makes a recommendation or takes an automated action, who is the "who"? FDA has not issued definitive guidance on AI-generated audit trail entries, but the expectation is clear: the system must capture the model version, input parameters, and the output alongside any human action taken on that output.

Validation is the deepest problem. Traditional CSV under GAMP 5 categorized software from Category 1 (infrastructure) to Category 5 (custom applications). AI models — particularly those built on machine learning that evolve over time or through retraining — don't map cleanly onto any of those categories. A model that changes its behavior after retraining is not the same validated system you started with.

The Computer Software Assurance Shift

In 2022, FDA released its final guidance on Computer Software Assurance (CSA) for Production and Quality System Software. This was a significant update to how FDA expects companies to approach software validation. The CSA framework moves away from documentation-heavy, prescriptive testing toward a risk-based, critical-thinking approach focused on what actually matters to patient safety.

For AI systems, CSA is both a relief and a responsibility.

The relief: you don't have to document every possible test case for an AI tool used in a low-risk administrative context. The CSA framework explicitly supports tailoring your assurance activities to the level of risk.

The responsibility: for AI tools used in high-risk contexts — deviation management, batch release decisions, electronic batch records — the expectation is not less rigor. It is smarter rigor. You need to demonstrate that you understand what the AI is doing, why it produces the outputs it does, and what happens when it is wrong.

In my view, companies using CSA as an excuse to under-validate their AI tools are setting themselves up for serious 483 observations. The guidance does not lower the bar — it moves the bar from paperwork to thinking.

Key Part 11 Requirements for AI Systems: A Comparison

This table represents the minimum delta you need to account for. It is not exhaustive, but it gives a practical frame for where to focus your assurance activities first.

The Validation Challenge for Generative AI

Generative AI adds complexity that predictive AI models don't have. When you deploy a large language model (LLM) to assist with SOP drafting, deviation investigation write-ups, or regulatory submission content, you are working with a system that can produce plausible-sounding but factually incorrect output.

Under 21 CFR Part 11 and broader GMP expectations, the company — not the AI vendor — is responsible for the accuracy of records. The AI vendor's Terms of Service will almost certainly include language disclaiming responsibility for output accuracy. That liability stays with you.

This means any generative AI tool used to produce or modify regulated records needs a human review step that is itself documented and auditable. The electronic signature applied to a deviation investigation report generated with AI assistance is the human's attestation that they reviewed the content and it is accurate. That is not just a procedural nicety — it is the mechanism by which the regulation assigns accountability.

An estimated 78% of pharmaceutical companies surveyed by ISPE in 2024 reported deploying or piloting AI tools in quality or manufacturing operations. Of those, fewer than 40% had formal validation or assurance documentation for those tools. That gap represents a regulatory liability FDA is beginning to notice directly in inspections.

What FDA Is Actually Looking For

FDA issued approximately 312 Part 11-related 483 observations in fiscal year 2023, with audit trail deficiencies accounting for the largest single category of findings. As AI tools proliferate in quality systems, expect audit trail adequacy for AI-generated entries to become a primary focus area.

FDA has signaled its broader AI focus through the 2021 AI/ML-Based Software as a Medical Device Action Plan, the 2023 Predetermined Change Control Plan guidance for AI-based SaMD, and a growing body of 483 observations referencing AI tools in quality system software. The consistent themes across all of these are:

1. Transparency — Can you explain what the AI is doing and why? For regulated records, black-box outputs are a problem.
2. Human oversight — Is there a documented, auditable human review step for AI-generated content entering a regulated record?
3. Change control — When the AI model changes through retraining, version updates, or fine-tuning, does your change control process capture that and trigger appropriate revalidation?
4. Data integrity — Is the data feeding the AI system subject to the same data integrity controls as other regulated data?

None of those expectations are new. They apply existing principles to a new technology. Companies that understand that framing tend to build better programs than those treating AI compliance as a standalone problem.

How to Build a Part 11-Compliant AI Program

Step 1: Inventory Your AI Tools

List every AI or ML tool used in your quality system, manufacturing operations, or laboratory. Include vendor-supplied tools — LIMS with predictive analytics, ERP systems with AI-assisted batch review, document management systems with AI drafting features — and any internally built tools. Most companies discover they have more AI touchpoints than they realized, and the inventory itself is usually the most clarifying step.

Step 2: Classify Each Tool by GMP Impact

For each tool, determine whether it: (a) creates or modifies regulated records, (b) makes recommendations that directly influence GMP decisions, or (c) provides general productivity support without touching regulated records. Category (a) and (b) tools require formal assurance documentation under CSA. Category (c) tools warrant a brief risk assessment but not full validation.

Step 3: Apply CSA Principles, Not Just CSV Templates

Your assurance activities should be proportional to risk. For high-risk AI tools, this means performance testing across representative data sets, documentation of model behavior under edge cases, and a clear retraining and version-control protocol. The goal is evidence that the system does what you claim it does, reliably, under the conditions you actually use it. Documentation for its own sake is what CSA was specifically designed to move away from.

Step 4: Build Audit Trail Requirements into Vendor Contracts

If you are using a SaaS AI platform, your vendor agreement should specify audit trail data availability, retention periods, and your ability to access complete audit logs on demand. Many SaaS vendors provide activity logs that are not Part 11-compliant without customization or additional configuration. Find this out before you go live — retrofitting audit trail requirements into a contract after deployment is a difficult conversation.

Step 5: Define the Human Review Checkpoint

For every AI tool that touches a regulated record, define the exact human review step: who reviews, what they are attesting to, and how that review is documented. This is often the weakest link in otherwise solid programs. "The user reviewed the output" is not sufficient — the documentation should capture what the reviewer was looking at and what decision they made based on it.

Step 6: Integrate AI into Your Change Control System

Model retraining and version updates must flow through your change control process — a model that behaves differently after retraining is a changed system. If that system creates regulated records, the change requires evaluation and potentially revalidation under your existing change control SOP. This is not optional, and it is one of the most commonly overlooked gaps in AI deployment programs I have reviewed.

Common Mistakes in AI 21 CFR Part 11 Programs

Companies get this wrong in predictable ways, and I have seen the same patterns across industries and company sizes.

The first mistake is treating AI tools as standard COTS (commercial off-the-shelf) software and applying a Category 3 GAMP approach without accounting for what is genuinely different. AI is not COTS in the traditional sense because its behavior can change, and because validation responsibility for complex ML models does not transfer to the vendor the way it might for a standard ERP system.

The second mistake is not capturing model version in audit trails. If your system records that "AI Tool X generated a recommendation on 2026-01-15" but does not capture which version of the model was running, you have no ability to investigate anomalies, reproduce outputs, or demonstrate control over your validated state during an inspection.

The third mistake is passive human review. When users rubber-stamp AI outputs without genuine review, the electronic signature becomes meaningless from a compliance standpoint. This is a training and culture issue as much as a technical one, but it falls squarely within the scope of what an FDA investigator will probe when reviewing your Part 11 controls. The right question to ask is whether your reviewers could actually detect an AI error in what they are signing — and whether your process gives them the information they would need to do that.

The Vendor Accountability Question

One point that I find consistently underappreciated: your AI vendor's FDA compliance posture matters, but it does not transfer to you.

Some AI vendors are pursuing their own Part 11 compliance attestations or SOC 2 Type II reports. Those attestations are useful background information and worth asking for. But your validation is your validation. The FDA will inspect your records, your audit trails, your human review documentation — not your vendor's.

When I work with clients on AI tool selection, vendor compliance documentation is one of eight factors I evaluate. It matters, but it is not a substitute for your own assurance program. Vendors who claim their platform is "Part 11 compliant" are usually referring to the technical features they offer — not to the procedural and documentation obligations you own.

For a broader look at how validation principles apply across quality system software, see our guide to GMP software validation at certify.consulting and explore how Certify Consulting approaches FDA readiness assessments for organizations deploying new technology.

What This Means Practically

If you have AI tools deployed in your quality system today and you do not have formal assurance documentation for them, you have a gap. The question is how significant that gap is and what it would take to close it.

The companies that handle this best are the ones that treat AI validation as an extension of their existing CSV/CSA discipline rather than a separate compliance project. The principles are the same. The application requires thinking through what is genuinely different about AI — and building your program around those differences rather than hoping the old templates stretch far enough to cover them.

The regulation has not caught up to AI in every respect. FDA's guidance is still evolving. But the core obligations under 21 CFR Part 11 — accuracy, reliability, audit trail, access control, human accountability — apply to AI-generated records the same way they apply to any other electronic record. That is not going to change, regardless of how the AI landscape develops.

At Certify Consulting, we have helped 200+ clients navigate FDA compliance challenges with a 100% first-time audit pass rate. If you are trying to get your AI program into a defensible state before your next inspection, that work is worth starting now.

Frequently Asked Questions

Does 21 CFR Part 11 apply to AI-generated records? Yes. If an AI system creates, modifies, maintains, archives, retrieves, or transmits records that are required under FDA regulations, those records are subject to Part 11 requirements regardless of whether a human or an AI generated them. The company remains responsible for the accuracy and integrity of those records.

What audit trail information is required for AI-generated entries under Part 11? At minimum, an AI-generated audit trail entry should capture: the user ID of the person who initiated the action, a timestamp, the model name and version, the input data or a hash of it, the AI output, and the human disposition of that output (approved, rejected, modified). Standard audit trails designed for human-only interactions do not capture model version or input provenance, which is the most common gap.

How does FDA's 2022 CSA guidance change AI validation? FDA's Computer Software Assurance guidance replaces prescriptive IQ/OQ/PQ documentation with risk-based assurance activities. For AI tools, this means you should focus your validation effort on demonstrating system reliability in ways that reflect actual use and risk level — not on generating documentation volume. High-risk AI tools still require rigorous testing; the difference is that the testing should be targeted rather than exhaustive.

Does model retraining require revalidation under Part 11? Yes, if the retrained model is used in systems that create or affect regulated records. A retrained model is a changed system and must go through your change control process, including an evaluation of whether revalidation is required. The scope of revalidation should be proportional to the nature and magnitude of the change — not every retrain triggers a full revalidation, but none should bypass change control entirely.

What is the company's liability when an AI vendor claims Part 11 compliance? The company remains fully liable. Vendor Part 11 compliance claims typically refer to technical features the platform offers — audit logging, access controls, encryption. Your compliance obligations include the procedural controls, the human review steps, the SOP documentation, and the validation records. None of those transfer to the vendor. Confirm exactly what the vendor's claim covers before relying on it in your compliance program.

Last updated: 2026-06-03