Every AI tool entering the clinical trial space claims to be "21 CFR Part 11 compliant." The phrase has become a marketing checkbox, deployed with the same confidence and roughly the same specificity as "enterprise-grade" or "scalable." Most sponsors accept it at face value until an inspector asks a pointed question about how a specific output was generated, who reviewed it, and how the review was documented — and the vendor's answer turns out to be a log table with a timestamp column.
Part 11 was written in 1997 for electronic records and signatures. It predates LLMs by three decades. But its requirements map cleanly onto AI-assisted systems when you read the regulation carefully, and the gap between what it requires and what most AI vendors actually implement is wide enough to constitute a compliance risk for any sponsor relying on those outputs in a regulated submission.
What follows is a practical checklist for evaluating whether an AI clinical trial tool meets the actual requirements of 21 CFR Part 11 — not the marketing version of them.
What Part 11 actually requires for AI systems
Section 11.10 specifies controls for closed systems. The relevant requirements for AI-generated outputs are:
§11.10(e): Audit trails. Systems must use "secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records." For AI systems, this means the audit trail must capture the AI's action (the inference call that produced the output) with the same rigor it captures a human user's action. An audit trail that logs human approvals but not the AI proposals that preceded them does not meet this requirement.
§11.10(d): Limited system access. System access must be limited to authorized individuals. For AI systems, this extends to the agents themselves — each agent should have a defined scope and should not be able to access data or produce outputs outside that scope.
§11.10(k): Documentation controls. Adequate controls over systems documentation must exist. For AI systems, this includes documentation of the model versions used, the validation approach, and how the system's behavior was verified against intended use.
§11.50/11.70: Electronic signatures. If electronic signatures are applied to AI-assisted records — as they would be when a DM lead approves an AI-generated SDTM mapping — the signature must be linked to the specific record, must include the name of the signer and the date/time, and must be rendered unusable by other individuals.
The compliance checklist
Ask your vendor these questions. The answers should be documentable — not just assertions.
1. Is the audit trail computer-generated and append-only? The audit trail must be produced by the system, not by the user, and it must be impossible for any user — including administrators — to modify or delete entries. A conventional database with UPDATE and DELETE privileges is not append-only. Ask specifically: how is immutability enforced? What happens if an administrator attempts to modify an audit record?
2. Does the audit trail capture AI inference calls, not just human actions? Most EDC audit trails capture human user actions. Most AI tools do not extend this to their own operations. The audit trail for an AI clinical data management tool must capture every inference call: which agent made it, which model version was used, what inputs were provided, what outputs were returned, and the timestamp of each. Without this, the AI's contribution to the record is undocumented.
3. Is the model version logged with every output? Model versions are updated. An output produced by GPT-4o-2024-11-20 and an output produced by a later version of the same model are not equivalent. For compliance purposes, the specific model version that produced each output must be logged so that an inspector reviewing a study conducted 18 months ago knows exactly what model produced the mapping they are looking at.
4. Is source attribution stored for AI reasoning? When an AI proposes an SDTM mapping, the basis for that mapping — the source passages from the protocol, the controlled terminology codes consulted, the SDTM IG sections applied — should be logged as a linked record. This is the "why" of the AI's decision. Without it, an inspector can see that the AI produced an output, but cannot evaluate whether the reasoning was sound.
5. Is human approval required before AI output enters a clinical artifact? This is the most frequently violated requirement. 21 CFR Part 11 requires that electronic records be reviewed by authorized individuals. An AI output that is automatically committed to a study database without human review has bypassed this requirement. The human approval step is not optional and cannot be waived by configuration without creating a compliance gap.
6. Is the authentication method for human approvals Part 11-compliant? Section 11.300 specifies controls for electronic signatures. The approval action that a DM lead takes when reviewing an AI proposal constitutes an electronic signature if it creates, modifies, or approves an electronic record. The authentication method must meet the requirements for electronic signatures: unique credential, non-shared, biometric or at minimum a combination of something the signer knows and something they possess.
7. Does a validation package exist? 21 CFR Part 11 requires that systems be validated to ensure accuracy, reliability, and consistent intended performance. For an AI system, this means IQ (installation qualification), OQ (operational qualification), and PQ (performance qualification) documentation that specifically addresses the AI components — not just the underlying EDC or data management software. Ask for the validation package before signing any contract. If it does not exist, the system is not Part 11 compliant regardless of what the vendor claims.
8. Can you reconstruct any record as it existed at any point in time? This is the practical test. Take a specific SDTM variable mapping from a study. Can the vendor show you exactly what the AI proposed, what confidence score it assigned, what reasoning it provided, whether a human revised it, who approved the final version, and when? If the answer to any of those questions is "no" or "we'd have to look into that," the audit trail is incomplete.
9. Is the audit trail in a format an inspector can follow without a guide? An audit report that requires the vendor's engineering team to interpret is not an audit report — it is a log file. The Part 11-compliant output is a human-readable document that mirrors the format a QA auditor would recognize from an EDC: each row a decision point, each decision linked to its documentation, the reasoning chain visible without needing to know the underlying data model.
What most AI tools actually provide
The practical reality is that most AI tools entering the clinical space were built for speed and capability, with compliance treated as a later-stage concern. The audit trail, if it exists, covers human-facing interactions in a web application UI. The AI's operations are logged in internal application logs that are not structured for regulatory review. Model versioning is managed at the infrastructure level but not exposed in the audit record. Validation documentation is a gap. The human approval step exists as a UX feature but is not architecturally enforced.
None of this makes these tools unusable. It makes them unsuitable for producing outputs that enter regulated clinical records. Using them for drafting, for internal analysis, for decision support that a human independently verifies — these are lower-risk uses. Using an AI tool to produce SDTM mapping documentation that goes directly into a submission package, without a compliant audit trail and a documented human review process, is a risk the DM lead and their sponsor own.
The question to ask before you sign
Ask any AI clinical trial vendor: can you share the validation package for your AI components, and can you demonstrate an audit report for a study that shows agent-level reasoning logs alongside human approval records? If the answer is yes and the documentation is substantive, proceed with appropriate due diligence. If the answer is no, or if the validation package covers only the application infrastructure and not the AI logic, the compliance claim is not yet earned.