Which GCP Clause Actually Governs Your Clinical AI Model

Search the Step 4 text of ICH E6(R3) for "artificial intelligence" and nothing comes back. Search it for "machine learning": nothing. "Algorithm": nothing. The same three searches against Annex 2 return nothing. The guideline that governs how you run a clinical trial in every ICH region, revised for the first time since 2016, contains no vocabulary at all for the technology every clinical operations function is currently buying.

That is not an oversight, and it is not a gap you get to argue into existence. The clause that governs your clinical AI model is section 4.3.4, validation of computerised systems, read with the systems inventory at 3.16.1(x)(i), the audit trail expectations at 4.2.2, the sponsor oversight duties at 3.9 and 3.6.6, and Principle 9.3, which says computerised systems should be fit for purpose "e.g., through risk-based validation, if appropriate". Your model is a computerised system, or a function inside one. Nothing in E6(R3) creates a separate category for it and nothing exempts it.

The single sentence that decides how much work this actually is sits at 4.3.4(e): "Both standard system functionality and protocol-specific configurations and customisations, including automated data entry checks and calculations, should be validated." A vendor validation pack covers the first half. Your prompts, thresholds, retrieval corpus, exclusion rules and score cut-offs are the second half, and they are yours.

What a full-text search of the guideline actually returns

The claim is reproducible, so here is the method. The documents searched were the ICH Step 4 final guideline PDF at database.ich.org (ICH_E6(R3)_Step4_FinalGuideline_2025_0106.pdf, document history ending at the 6 January 2025 endorsement) and the Annex 2 Step 4 guideline adopted 3 June 2026. Both were converted to plain text on 30 August 2026: 28,650 words and 6,253 words respectively. Case-insensitive searches for "artificial intelligence", "machine learning", "algorithm", "neural", "large language" and the standalone token "AI" return zero matches in both.

What the guideline does contain is a thin band of automation vocabulary, and it is worth seeing all of it at once because the whole regulatory argument for AI in GCP is built on these six sentences.

A second absence matters. The glossary defines "Computerised Systems Validation" but never defines "computerised system". You are required to validate a category the guideline declines to bound, and that ambiguity runs in the regulator's favour: a sponsor arguing that its retrieval-augmented query service is not a computerised system is arguing against a definition that does not exist.

None of this is accidental drafting. The Introduction states that the principles "are intended to apply across clinical trial types and settings and to remain relevant as technological and methodological advances occur", and that the guideline "is intended to be media neutral to enable the use of different technologies". E6(R3) was built to survive technologies it could not name. The cost of that choice is that it gives you no AI checklist, and inspectors will assess your model against clauses written with eCRFs and IRT systems in mind.

Section 4.3.4 is the clause, and 4.3.4(e) is the sentence

Read 4.3.4 as nine sub-clauses and map each to a question you would otherwise expect an AI guidance to answer.

Sub-clause (a) makes the responsible party accountable for validation status "throughout its life cycle" and requires a risk assessment considering intended use, the importance of the data the system generates, and the potential to affect participant safety and the reliability of trial results. That is a context-of-use statement and a model risk assessment in GCP language, written before FDA proposed the same construct in draft.

Sub-clause (b) sets the acceptance standard: the system "conforms to the established requirements for completeness, accuracy and reliability" and performs "consistent with its intended purpose". For a deterministic edit check that is a pass/fail test script. For a probabilistic classifier it forces the decision most sponsors avoid: what numerical performance counts as conformance, measured on what data, against what pre-defined acceptance criterion.

Sub-clause (c) requires that subsequent changes be validated based on risk "and should consider both previously collected and new data". This is the clause that governs a model version bump mid-study: a change in classification behaviour raises the question of whether data already processed under the previous version remain consistent. Answering that retrospectively is expensive. Defining your re-validation triggers before first patient in is not.

Then (e), the sentence that costs money. Different degrees of validation, it continues, "may be needed for bespoke systems, systems designed to be configured or systems where no alterations are needed". That last category is exactly what a platform vendor will tell you it sells. It almost never is. If you have written a prompt, tuned a confidence threshold, restricted a corpus to your protocol library or defined which flags escalate to a human, you have configured the system, and 4.3.4(e) puts that configuration in scope regardless of how thick the vendor's pack is.

Sub-clause (g) closes the outsourcing route: systems must be validated as fit for purpose "including those developed by other parties", with the documentation maintained and retained. You cannot hold the vendor's evidence at arm's length. Sub-clause (h) names the functions attracting the highest rigour — "critical functionality, such as randomisation, dosing and dose titrations and reductions, and collection of endpoint data" — so a model output feeding a dose decision or an endpoint value carries the burden the guideline reserves for randomisation systems. Periodic review under (d) is the only mechanism here that catches silent drift in a hosted model, and its cadence is yours to justify.

Finally (i) allows unresolved issues to persist if they are justified and their risks addressed by mitigation strategies "prior to and/or during the continued use of the system". That is the clause under which a model with known failure modes can be deployed, provided the failure modes are documented and mitigated rather than discovered by an inspector.

The clause that bites an AI that writes into the EDC

Most AI governance conversations in clinical operations stop at validation. The clause that kills poorly-designed deployments sits elsewhere, in the sponsor's data-handling duties at 3.16.1. Sub-clause (i) reads: "The sponsor should not make changes to data entered by the investigator or trial participants unless justified, agreed upon in advance by the investigator and documented." An automated data-cleaning agent that corrects units, harmonises verbatim terms or resolves inconsistencies is the sponsor making changes to investigator-entered data. It is permissible, but only against a documented, pre-agreed scope. That agreement is a design artefact you write before deployment, naming the fields in scope and the change types allowed, not a retrospective explanation.

Sub-clause (l) is stranger and more useful: "The sponsor should not have exclusive control of data captured in data acquisition tools in order to prevent undetectable changes." A sponsor-hosted pipeline that ingests, transforms and returns site data without the investigator seeing what changed sits badly against that sentence. The mitigation is visibility: the investigator must be able to see the state of their data and, under 3.16.1(o), endorse it at predetermined milestones.

Section 4.2.4 supplies the one place in E6(R3) where a non-human actor is contemplated directly. 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 system may be the attributed actor. It may not be the justifier: the justification and source-record support remain a human obligation, which is the structural reason a fully autonomous query-resolution loop cannot be made compliant simply by logging well.

For derived values, 3.16.2(c) requires the sponsor to ensure "the traceability of data transformations and derivations during data processing and analysis". A model producing a risk score, an imputed value or a classified adverse event term is a transformation inside that requirement, and traceability means showing which input produced which output under which model version — a lineage requirement most inference stacks do not meet out of the box.

What "the model did it" has to resolve to in an audit trail

Section 4.2.2 governs metadata and audit trails for data of higher criticality, and it is unusually specific. Systems must log user account creation and changes to roles and permissions (a)(i), document initial entry and any subsequent change or deletion with reason where appropriate (a)(ii), and "record and maintain workflow actions in addition to direct data entry/changes into the system" (a)(iii).

That third requirement is the one AI deployments fail. A model that reads a record, scores it and routes it for human review has performed a workflow action without changing any data, and under 4.2.2(a)(iii) that action sits inside the audit trail expectation for critical data. Most agent frameworks log to application telemetry, which is not an audit trail: usually mutable, often retained for weeks rather than the trial retention period, and rarely reviewable in the sense 4.2.2(c) requires, that audit trails and logs be "interpretable and can support review".

Sub-clause (b) adds that audit trails "should not be disabled" and should not be modified except in rare circumstances with a logged justification. Applied to a model service that reaches the inference log, the version register and the configuration history, not just the EDC's own trail. The glossary definition — records capturing "details on actions (manual or automated) performed" — removes any argument that automated actions sit outside the concept.

The practical test is simple. Take one record the model touched and show who or what acted, when, under which system identity, with which version and configuration, what the human reviewer saw and what they decided. If any element of that chain lives only in an observability platform with a 30-day retention policy, the answer is no.

Centralised monitoring under 3.11.4.2 is where the guideline already assumes analytics

There is one place where E6(R3) all but writes AI into the process without naming it. Section 3.11.4 describes monitoring as including "data analytics" and notes that some activities, "e.g., centralised monitoring, may be conducted by different methods and persons with different roles (e.g., data scientist)". Section 3.11.4.2(a) defines centralised monitoring as an evaluation of accumulated data "by the sponsor's qualified and trained persons (e.g., medical monitor, data scientist/data manager, biostatistician)", and (b) states that "use of centralised data analytics can help identify systemic or site-specific issues, including protocol noncompliance and potentially unreliable data".

Three things follow. The guideline expects the analytic function to be staffed by qualified persons, and Principle 5.1 lists "technology experts" among the expertise a trial may need, so a signal-detection model sits inside an activity E6(R3) already contemplates with a named role attached. Section 3.11.4 requires monitoring to be "performed by persons not involved in the clinical conduct of the trial at the site being monitored", so the independence question attaches to the humans reviewing model output rather than to the model. And 3.11.4.3 requires the monitoring plan to describe "the various monitoring methods and tools to be used, and the rationale for their use".

That last requirement is the natural home for your model documentation. Intended use, the population the model was validated on, the thresholds that trigger a site visit and the rationale for choosing analytics over source data verification all belong in the monitoring plan, a document inspectors already read. A separate "AI governance dossier" living outside the trial's controlled documents is an artefact nobody at an inspection knows how to ask for.

The contrast with participant-facing uses is sharp. EMA's list of AI uses in trials starts with recruitment and eligibility determination, which is also where deployment claims are loudest and where the published clinical-development cycle-time evidence still needs careful unpicking. Centralised monitoring is the use case where the guideline's own language does most of the compliance argument for you.

Who is accountable when the vendor's model is wrong

The glossary settles this in one line. A service provider is "a person or organisation (commercial, academic or other) providing a service used by either the sponsor or the investigator to fulfil trial-related activities". A model is neither a person nor an organisation. The company that supplies it is a service provider; the model itself can never be one, which means no responsibility can be transferred to it.

Section 3.6.6 states that a sponsor may transfer any or all trial-related activities to a service provider, "however, the ultimate responsibility for the sponsor's trial-related activities, including protection of participants' rights, safety and well-being and reliability of the trial data, resides with the sponsor". Section 3.9.5 makes selection and oversight of service providers "fundamental features of the oversight process", and 3.6.9 extends that oversight to "activities further subcontracted by the service provider" — which reaches the foundation-model provider sitting behind your clinical vendor.

Annex 2 sharpens this for external data. Section 3.4.1 states that "regardless of which entity owns and/or controls data or undertakes data processing steps, sponsors remain responsible for oversight of these steps, including extraction, linkage and transformation", and 3.5.1(b)(vii) requires an assessment of "systems and tools used for the collection and acquisition of RWD (e.g., registries, DHTs), including the validation status as appropriate".

One more clause decides how much of this lands in the trial master file. Appendix C.2.12 accepts that certain essential records "may not be specific to a trial" — it names master services agreements, SOPs and validation records — and may be "retained outside the trial-specific repositories". That is permission to keep a model's validation package in a system-level repository rather than filing it per study. It is not permission to be unable to produce it: record keeping and essential documents is the most common finding category in MHRA sponsor inspections, at roughly 18% of all sponsor findings (Ennov analysis of MHRA GCP inspection metrics).

Which instrument actually binds you on 30 August 2026

This is where most vendor material fails, by quoting draft text as though it were law.

The EMA computerised systems guideline is the document most GCP teams underuse, and it is why the picture is less bare than E6(R3) alone suggests. Unlike the ICH text it names AI five times, defining it in the glossary as "a very broad set of algorithms, which enable computers to mimic human intelligence ... from simple if-then rules and decision trees to machine learning and deep learning" — wide enough to catch the rules engine you already run. Its scope section lists AI "used in clinical trials e.g. for trial participant recruitment, determination of eligibility, coding of events and concomitant medication, data clarification, query processes and event adjudication", then says the sentence that belongs in every governance SOP: "Requirements to AI beyond the generally applicable expectations to all systems will not be covered in this guideline initially. This may be covered in a future Annex."

That is the whole European position. AI is in scope, the requirements are the generally applicable ones, there is no carve-out and there is no AI annex yet. Note also that its legal background cites ICH E6(R2), because it was written before R3 landed; its detailed expectations on validation, user management and audit trail review now sit underneath E6(R3) section 4.3 rather than replacing it.

One contrast matters for anyone whose company also manufactures. In GMP the binding computerised-systems text on 30 August 2026 remains the 2011 EudraLex Annex 11. The draft revised Annex 11 and the new draft Annex 22 on artificial intelligence went out for consultation on 7 July 2025, closing 7 October 2025. They are not law, and the widely-quoted line that generative AI is excluded from critical GMP applications is a draft position, not an enforceable requirement. GCP has no equivalent draft in circulation at all.

Does the EU AI Act reach a trial AI at all?

Less often than the compliance briefings suggest. Article 2(6) provides that the Regulation "does not apply to AI systems or AI models, including their output, specifically developed and put into service for the sole purpose of scientific research and development". Article 2(8) excludes "any research, testing or development activity regarding AI systems or AI models prior to their being placed on the market or put into service", while noting that testing in real-world conditions is not covered by that exclusion.

Beyond those exclusions, the Annex III high-risk categories target employment, credit, biometrics, education and essential services; a sponsor-side eligibility screening model does not land in them. Annex I status attaches through product legislation, which is how an AI-enabled medical device used in a trial gets caught. Those obligations now apply from 2 December 2027 and 2 August 2028 respectively, following the AI Omnibus that entered into force on 27 July 2026.

What is already live is narrower but real: the Article 5 prohibitions, the Article 4 AI literacy duty and the GPAI model obligations. Article 4 carries the operational cost, requiring providers and deployers to ensure a sufficient level of AI literacy among staff operating these systems. For a sponsor that means training records for the CRAs and data managers reviewing model output — which section 4.3.2 of E6(R3) asks for anyway, in its requirement that those using computerised systems be appropriately trained in their use.

The blunt version: GCP is the binding constraint on your trial AI and the AI Act mostly is not. Building governance around the AI Act while treating E6(R3) as a formality gets the priority backwards.

What this means in practice

Start with the inventory, the cheapest item on the list and the first thing an inspector asks for. Section 3.16.1(x)(i) requires the sponsor to hold "a record of the important computerised systems used in a clinical trial", including "the use, functionality, interfaces and validation status of each computerised system, and who is responsible for its management", plus a description of access controls and security measures. If your prescreening model, coding assistant or central-monitoring signal engine is missing from that record, every other control you built is undocumented from the inspector's point of view. Adding a row costs an afternoon, and it forces the question of who owns the system — which in most organisations turns out to be nobody.

Then write the 4.3.4(a) risk assessment as a real document, not a form. The clause names three inputs: intended use, the importance of the data the system generates, and the potential to affect participant well-being, rights and safety and the reliability of results. A model that suggests a query for human approval and one that closes a query autonomously share an architecture and differ under all three. Write the intended use narrowly enough that expanding it later triggers change control under 4.3.4(c); scope creep from a pilot into an endpoint-adjacent process is the most common way sponsors end up outside their own validated state.

Split the validation file in two along the seam 4.3.4(e) creates. Column one is the vendor's: platform functionality, infrastructure qualification, security testing. Column two is yours: prompt and configuration versions, threshold settings, the corpus the model retrieves from, the acceptance criteria you set and the evidence you generated on an independent, representative test set drawn from your own studies. Sponsors underestimate the second column because the vendor pack is heavy and looks complete. It covers the wrong half.

Decide, explicitly and in writing, whether model output writes to a data acquisition tool. If it does, 3.16.1(i) requires prior agreement with the investigator and 3.16.1(l) requires that the sponsor not hold exclusive control of the data. If it does not — if the output is a recommendation a human accepts or rejects — your obligations shift toward 4.2.2(a)(iii) workflow logging and toward evidencing that the human review is real rather than nominal. Both are defensible. Neither survives being left undecided until an audit.

Put the model where inspectors already look. Analytics used in centralised monitoring belong in the monitoring plan under 3.11.4.3, with the rationale for their use. Transformations and derivations belong in the data management plan, with the traceability 3.16.2(c) requires. Validation records may sit in a system-level repository under Appendix C.2.12, provided the retrieval path from a study to that repository is documented.

Finally, rank the use cases honestly. The FDA draft guidance, non-binding as it is, draws a line worth borrowing: it does not address AI used "for operational efficiencies (e.g., internal workflows, resource allocation, drafting/writing a regulatory submission) that do not impact patient safety, drug quality, or the reliability of results". E6(R3) draws no such line, because everything inside a trial's computerised systems falls under section 4.3 regardless. Together they give a workable order: model risk under 4.3.4(a) sets the depth of evidence, and the FDA exclusion tells you which uses will never need a credibility argument in a submission even though they still need validation. Before committing budget to a recruitment model, read the broader cycle-time evidence base with the same scepticism.

The person who signs is the one named as responsible for the system's management under 3.16.1(x)(i), countersigned by whoever owns quality assurance for the study under 3.11.1. If that pairing does not yet exist in your organisation for AI systems, the gap is organisational rather than regulatory. E6(R3) already told you where to put the names.