The question regulators actually ask
Most compliance conversations about AI in trial operations start in the wrong place. Someone asks whether 21 CFR Part 11 permits a language model, quality gives a careful non-answer, and the pilot stalls for a quarter. Part 11 has nothing to say about models. It is a rule about records. Section 11.1(b) sets the trigger plainly: the part "applies to records in electronic form that are created, modified, maintained, archived, retrieved, or transmitted, under any records requirements set forth in agency regulations." The obligation attaches through the predicate rule, meaning the underlying regulation that requires the record to exist at all.
For a drug trial that predicate rule is Part 312. Section 312.62(b) requires the investigator to "prepare and maintain adequate and accurate case histories that record all observations and other data pertinent to the investigation on each individual administered the investigational drug." Section 312.62(c) fixes how long those records live: two years past approval of a marketing application for the indication under study, or two years after the investigation is discontinued and FDA is notified. Those sentences, not any statement about artificial intelligence, are what pull a system into scope.
The consequence is practical. A model that ranks candidate countries and sites for enrollment feasibility produces an internal planning artifact and touches no predicate-rule record. A model that codes a verbatim adverse-event term into the analysis dataset supporting a clinical study report touches one directly. Same architecture, same vendor, same prompt engineering. Completely different regulatory weight, and completely different cost to deploy.
What Part 11 requires once it applies
When the rule does attach, section 11.10 lists the controls for closed systems. Read as a specification for a model-assisted workflow, four of them do most of the work.
11.10(a) — validation. Systems must be validated "to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records." The phrase people stumble over is consistent intended performance, because a generative model sampled at temperature does not repeat itself. The way through is to stop validating the model and start validating the system that contains it.
11.10(b) — copies. The system must generate "accurate and complete copies of records in both human readable and electronic form suitable for inspection, review, and copying by the agency." If your model's reasoning and its original output live only inside a vendor's console, you cannot produce that copy.
11.10(e) — audit trails. "Use of 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." The rule was drafted with human operators in mind. A model is not an operator, and this is where most designs get sloppy.
11.10(i) — competence. A determination "that persons who develop, maintain, or use electronic record/electronic signature systems have the education, training, and experience to perform their assigned tasks." That reaches the people who build your inference pipeline, not only the data managers who click through it.
FDA replaced its 2007 thinking here. The final guidance Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations: Questions and Answers (Docket FDA-2017-D-1105) was announced in the Federal Register on October 2, 2024, and supersedes the May 2007 guidance on computerized systems used in clinical investigations. Seven centers signed it, from CDER and CBER through CDRH, CFSAN, CTP, CVM, and the Oncology Center of Excellence. It expands the risk-based approach to validation, updates data integrity and security controls including audit trails, and adds recommendations for agreements between information technology service providers and regulated entities. That last item is the one procurement should read.
Where FDA's AI guidance stops, and why that matters here
FDA's draft guidance Considerations for the Use of Artificial Intelligence To Support Regulatory Decision-Making for Drug and Biological Products (Docket FDA-2024-D-4689) published January 7, 2025. It proposes "a risk-based credibility assessment framework that may be used for establishing and evaluating the credibility of an AI model for a particular context of use (COU)." Context of use is defined as "the specific role and scope of the AI model used to address a question of interest," and credibility as "trust, established through the collection of credibility evidence, in the performance of an AI model for a particular COU."
The scope section is the part operations teams should read twice. The draft excludes drug discovery, and it excludes "operational efficiencies (e.g., internal workflows, resource allocation, drafting/writing a regulatory submission)" where those uses do not affect patient safety or the reliability of study results. A great deal of what people mean by AI in trial operations sits inside that carve-out.
Read it precisely. It is a statement that the credibility framework does not attach. It is not a statement that Part 11 stops applying, and it is not a statement that GCP stops applying. A system that drafts a monitoring visit report is an internal workflow right up until the report becomes an essential record. The boundary is not a property of the model. It is a property of where you put the output.
Still a draft, eighteen months on
The AI credibility guidance remains in draft as of August 2026. Sponsors building programs against it are building against a document FDA may revise. Cite it as a framework for structuring your own evidence, and keep the underlying Part 11 and GCP obligations as the thing your validation actually answers to.
E6(R3) changed the validation question
ICH adopted E6(R3) at Step 4 on 6 January 2025, and FDA announced the final guidance version on September 9, 2025. It is a genuine rewrite rather than an addendum, and Section 4, Data Governance, is where trial operations lives. Section 4.3 covers computerised systems end to end: procedures, training, security, validation, release, failure, technical support, and user management.
Section 4.3.4(a) states the validation principle. The approach "should be based on a risk assessment that considers the intended use of the system; the purpose and importance of the data/record that are collected/generated, maintained and retained in the system; and the potential of the system to affect the well-being, rights and safety of trial participants and the reliability of trial results." Principle 9.3 says the same thing in a sentence: computerised systems "should be fit for purpose (e.g., through risk-based validation, if appropriate)."
Two further clauses set boundaries worth memorising. Section 4.3.4(h) names the critical functionality that always draws heavy validation: "randomisation, dosing and dose titrations and reductions, and collection of endpoint data." Those are the third rail. Putting a probabilistic model in that path requires a reason far better than efficiency and an evidence package to match. And 4.3.4(g) closes the procurement escape hatch: the responsible party "should ensure that the computerised systems are validated as fit for purpose for use in the trial, including those developed by other parties." Buying the system does not move the obligation.
One part of the picture is openly unsettled. E6(R3) Annex 2, which addresses trials with decentralized and pragmatic elements and real-world data sources, went out as a draft on December 30, 2024, and FDA reopened its comment period on March 13, 2025. No final version had been announced through August 2026. If your operating model depends on decentralized data flows, plan for the guidance to move.
The record boundary, drawn use case by use case
The table below is the working version of that boundary. Exposure is not a property of the technique. It follows from whether the output becomes, or determines, a record a predicate rule requires, and from whether a qualified person's judgement stands between the model and that record.
| Operations use case | Record it reaches | Part 11 exposure | What you must be able to produce |
|---|---|---|---|
| Site and country feasibility ranking | Internal planning artifact; no predicate-rule record | Low | Documented method and reproducible inputs. No regulatory validation package unless the output is filed. |
| Participant pre-screening from source records | Screening logs; eligibility determination | Low as a clinician worklist; high if the output is the eligibility decision | Access controls over identifiable data, and a documented clinician decision standing as the record. |
| Medical coding of verbatim terms | Analysis datasets supporting the study report | High | Version-locked model and dictionary, coder confirmation per term, audit trail on every value and change. |
| Safety case triage and narrative drafting | Safety records and expedited reports | High | Reviewer sign-off as the record of authorship, plus retention of the pre-edit model output. |
| Risk-based monitoring signal detection | Monitoring plan and monitoring records | Medium | Documented signal definitions and thresholds. The action taken is the record, not the score. |
| TMF filing and completeness checking | Essential records index | Medium | Audit trail on every reclassification and human confirmation of essential-record status. |
Audit trails for a system that does not repeat itself
E6(R3) is more useful than Part 11 here, because it was written after this problem existed. Section 4.2.2(a)(iii) asks that systems "record and maintain workflow actions in addition to direct data entry/changes into the system." Section 4.2.4 goes further and says corrections "should be attributed to the person or computerised system making the correction, justified and supported by source records around the time of original entry." A computerised system can be the actor of record. The guideline says so directly, which settles an argument that used to consume months.
What follows is a concrete logging obligation. For any model-assisted change to a record, the audit trail has to carry more than a user ID and a timestamp:
- The model identifier and exact version, pinned for the life of the trial.
- The precise input, including any retrieved context passed into the prompt.
- The raw output as generated, before any human edit.
- The reviewer's identity, their decision, and the final committed value.
- The reason for change, where the workflow requires one.
Two hard rules from 4.2.2 sit around that. Audit trails, reports, and logs must not be disabled, and audit trails "should not be modified except in rare circumstances." Timestamps should be unambiguous, with coordinated universal time given as the example. Neither is negotiable because a vendor's default configuration is inconvenient.
The failure we see most often is quiet. A team logs the value the reviewer accepted and discards what the model originally proposed. Months later an inspector asks how a particular coded term was arrived at, and the honest answer is that nobody knows. The pre-edit output is among the cheapest objects in the system to store and by far the most expensive to reconstruct. Keep it. The same discipline applies to any extraction pipeline feeding a regulated record.
Validation evidence that survives an inspection
"Consistent intended performance" is what convinces people a language model cannot be validated. It can be, provided you validate the system rather than the weights. That means a deterministic wrapper around a frozen model, decoding parameters pinned, output constrained to a schema the downstream system enforces, and acceptance criteria stated as measured rates rather than adjectives. For high-consequence extraction there is also a real design choice between generation and deterministic extraction, and the deterministic path is often the cheaper one to defend.
- An intended-use statement naming the specific record the output touches
- A risk assessment in the terms of E6(R3) 4.3.4(a): participant safety, importance of the data, reliability of results
- Requirements and specifications with acceptance criteria expressed as rates, not adjectives
- A frozen model version and pinned decoding parameters, with change control triggered by any change to either
- Test evidence on a labelled set the build team never saw
- Measured performance on the failure classes that matter, not only the aggregate
- Reviewer procedures, training records, and evidence the review is real
- Periodic review to confirm the system remains in a validated state, per 4.3.4(d)
Note what 4.3.4(e) adds: both standard functionality and protocol-specific configurations, including automated data entry checks and calculations, must be validated, and interfaces between systems must be defined and validated too. A model that writes into an EDC through an integration means the integration is in scope as well. If you are writing this into a contract, our note on acceptance criteria for a machine learning deliverable covers the wording that holds up.
"A human reviews it" is a control only if you can prove the review
The dominant design in trial operations is model proposes, qualified person disposes. It is the right design, and it is the one most often asserted and least often evidenced. If human review is the control that keeps a use case out of the high-exposure column, then review has to be measurable in the same way any other control is.
That means a recorded decision per item, retained time-on-item, a tracked disagreement rate over the life of the trial, and a periodic sample audited against ground truth. A reviewer accepting 99.7% of proposals is not exercising a control; the audit trail will show a rubber stamp, and it will show it to whoever asks. Watch that acceptance rate the way monitoring watches an outlier site.
Automation bias is the mechanism, and it gets worse as the model gets better, not better. Two mitigations are cheap: withhold the model's confidence score from the reviewer on a sampled subset, and route a fraction of items to blind dual review. Both give you a defensible number for how much independent judgement the control is actually contributing. Related instrumentation is covered in our pieces on the refusal-rate metric and on drift detection that does not cry wolf.
Hours recovered per unit of evidence owed — our ranking
Editorial weighting of hours recovered against validation evidence owed, from public guidance and practitioner reading — illustrative, not a measured statistic.
The ranking above is our own reading of where the trade is currently best: how many operational hours a use case gives back, set against how much validation evidence it obliges you to produce. It is a judgement, not a measurement, and it should shift as guidance settles. The pattern it encodes is stable, though. Value concentrates where the work is high-volume and the output is a worklist, and it thins out where the output is a determination.
The vendor does the work; you remain answerable
E6(R3) 3.9.5 states that "the selection and oversight of investigators and service providers are fundamental features of the oversight process," and that sponsor oversight includes quality assurance and quality control over the trial-related activities of service providers. Section 3.6.1 requires agreements with service providers to be documented before the activities start. Put alongside 4.3.4(g) and FDA's recommendations on service provider agreements, the position is settled: activities transfer, accountability does not.
Six questions belong in writing before signature, and they are worth asking in this order.
Which model version runs, and what notice do we get before it changes? A silent upgrade is a change to a validated system.
Can that version be pinned for the duration of the trial? If the answer is no, your change-control procedure has to absorb the vendor's release cadence, and you should price that.
Do we receive the raw pre-edit output, or only the accepted value? This is the question that ends deals. A platform that returns only the committed value has moved part of your audit trail inside its own boundary.
Who holds the validation documentation, and can we retain a copy for the full retention period? Section 312.62(c) sets a clock that outlasts most vendor relationships.
Are audit trails exportable in human readable and electronic form? That is 11.10(b) stated as a contract term rather than a hope.
On termination, what comes back, in what format, and by when? Answer it while you still have commercial leverage. The broader pattern is covered in what changes when your AI touches regulated data.
What is moving in 2026
Three developments this year matter more to operations than another round of AI commentary.
ICH M11 became available as FDA guidance on May 22, 2026 (Docket FDA-2022-D-3054). The Clinical electronic Structured Harmonised Protocol sets an internationally harmonised standard for the content and exchange of protocol information, and ships as three pieces: the guidance itself, a template fixing content structure and headers, and a technical specification with harmonised terminologies and standardised data fields for electronic exchange. For anyone automating trial operations this is the quiet headline. Much of the extraction work in this domain exists only because the protocol arrives as prose. A protocol that is structured data is a protocol a system can act on without inferring anything.
FDA opened two requests for information. One, published March 31, 2026, concerns advancing the use of digital health technologies in clinical investigations for drugs and biological products. The other, published April 29, 2026, proposes an AI-Enabled Optimization of Early-Phase Clinical Trials Pilot Program, with the comment period extended on May 28, 2026. The pilot notice ties its approach to the NIST AI Risk Management Framework, which is a useful signal about the vocabulary FDA expects sponsors to speak.
Two documents remain in draft. The AI credibility framework and E6(R3) Annex 2 are both unsettled. Anyone presenting either as fixed requirement is ahead of the record.
For context on scale, ClinicalTrials.gov listed roughly 598,000 registered studies as of August 2026. The operational burden that number represents is the actual market for this work, and none of it goes away because a guidance is still in draft.
Where we would start
Pick one use case on the low-exposure side of the boundary and instrument it completely. TMF misfile detection and feasibility ranking are the usual first choices because a wrong answer costs rework rather than a protocol deviation. The point of the first project is not the savings. It is to build the logging schema, the reviewer instrumentation, and the validation habits on a workload where mistakes are recoverable.
Build the audit record before the model. A pilot that produces savings you cannot evidence has produced a problem, not a result, and retrofitting a logging schema after the fact means rerunning the work.
Write the intended-use statement first, in one paragraph, naming the record, the decision, the reviewer, and the acceptance criteria. If that paragraph is hard to write, the use case is not ready, and no amount of model quality will make it ready.
Bottom line
Part 11 and GCP are not obstacles to model-assisted trial operations. They are a specification, and an unusually clear one once you accept that the regulated object is the record rather than the software. Sponsors and CROs that draw the record boundary first, log the model's original output rather than only the accepted value, and can prove their human review is doing work will find most operational use cases sit on the manageable side of the line. The ones that start with the model and reason backwards to compliance will spend a year discovering which records they touched.
Common objections we hear
Part 11 means we cannot use a generative model at all
Part 11 sets controls on electronic records that a predicate rule requires. It does not prohibit any class of software. The controls in 11.10 are achievable for a model-assisted workflow when the model sits inside a deterministic system with a frozen version, a constrained output schema, a recorded human decision, and a complete audit trail. What Part 11 does prohibit is a workflow whose outputs cannot be reproduced, copied, or explained.
Our vendor says the platform is Part 11 compliant
Compliance is a property of your implementation, your configuration, and your records. The obligations in 11.10 fall on the regulated entity, and E6(R3) 4.3.4(g) requires the responsible party to ensure systems are validated fit for purpose "including those developed by other parties." A vendor can supply capability and documentation. It cannot supply your compliance.
We will validate it once and be finished
Section 4.3.4(c) requires subsequent changes to be validated based on risk, considering both previously collected and new data under change control. Section 4.3.4(d) contemplates periodic review to confirm the system remains validated. With a hosted model, the vendor's release cadence is a change source you do not control, which is exactly why version pinning belongs in the contract.
The model is only advisory, so none of this applies
Advisory is a real distinction and it genuinely lowers exposure, but only when the advice is separable from the decision and the decision is independently recorded. If the reviewer accepts nearly everything, if the interface makes acceptance the default, or if the model's proposal is what actually gets written to the record, then advisory describes the intent rather than the system.
Frequently asked questions
It applies if the system creates, modifies, maintains, archives, retrieves, or transmits an electronic record required by a predicate rule such as 21 CFR Part 312. A model producing an internal planning artifact is generally outside that scope. A model writing into case histories or analysis datasets is inside it. The determination is made per use case, not per product.
Yes, by validating the system rather than the model. Freeze the version, pin decoding parameters, constrain output to an enforced schema, set acceptance criteria as measured rates, and test on a labelled set the build team never saw. ICH E6(R3) 4.3.4(a) makes the depth of that work proportionate to intended use, data importance, and risk to participants and to the reliability of results.
The sponsor. E6(R3) 3.9.5 makes selection and oversight of service providers a fundamental part of sponsor oversight, and 4.3.4(g) requires the responsible party to ensure systems are validated fit for purpose including those built by others. Activities transfer under documented agreements; accountability does not.
Mostly not. The January 2025 draft guidance on AI supporting regulatory decision-making excludes operational efficiencies such as internal workflows, resource allocation, and drafting a regulatory submission, where those uses do not affect patient safety or the reliability of study results. That carve-out removes the credibility framework, not Part 11 and not GCP. The guidance also remains in draft.
The pinned model version, the exact input including retrieved context, the raw output before any human edit, the reviewer's identity and decision, the final committed value, and the reason for change where required. E6(R3) 4.2.2 adds that audit trails must not be disabled, must not be modified except in rare and justified circumstances, and should carry unambiguous timestamps such as coordinated universal time.