ICH E6(R3) was finalized on January 6, 2025, and became effective in the EU in July 2025. It is the first revision to the GCP guideline in nearly a decade, and it arrives at the same moment that AI tools are proliferating across clinical trial operations. The timing is not coincidental — the revision was explicitly motivated by the need to address risk-based and technology-enabled approaches to clinical trial conduct, including the role of computerized systems in data management and oversight.
The guideline does not mention large language models or agentic AI. It does not have to. Its requirements for data governance, audit trails, computerized system validation, and human oversight apply to AI-assisted processes as directly as they apply to any other electronic system that creates, modifies, or manages clinical trial records.
What follows is a practical reading of the E6(R3) requirements that are most relevant to sponsors using AI tools in their clinical data management pipeline.
What changed from E6(R2)
E6(R3) reorganized the structure of the guideline significantly. The core change relevant to clinical data management is the elevation of data governance as a first-class requirement, addressed in Chapter 4. E6(R2) addressed data management in general terms; E6(R3) is more specific about what sponsors and CROs must demonstrate regarding how clinical data is collected, managed, and maintained in a state fit for decision-making.
The specific additions relevant to AI-assisted processes:
Data governance framework. Sponsors must have documented processes for ensuring data quality throughout the trial lifecycle. For AI-generated data artifacts, this means the governance framework must address how AI outputs are generated, reviewed, and approved — not just how data is entered by site staff.
Computerized system validation. E6(R3) strengthens the validation requirements for computerized systems used in trial conduct. The guideline explicitly states that validation should be proportionate to the risk and intended use of the system. For AI systems that generate SDTM mappings or Define-XML, the intended use directly influences regulatory decisions — the validation requirements are correspondingly high.
Audit trails. Section 4.9 of E6(R3) requires that audit trails be maintained for electronic systems used to manage clinical trial data. The language is specific: audit trails must record who performed each action, what action was performed, when it was performed, and — where applicable — why a change was made. For AI systems, "who" includes the AI agent and "what" includes the inference call that produced the output.
The human oversight requirement
E6(R3) is unambiguous on the principle that qualified humans must oversee data management processes. Section 4.1 establishes that sponsors are responsible for implementing data governance that ensures data integrity, and that this responsibility cannot be delegated to automated systems. An AI tool that produces clinical data outputs without qualified human review is not consistent with E6(R3) requirements, regardless of how accurate its outputs might be.
The practical implication: every AI output that influences a clinical data artifact — an SDTM mapping, a DMP entry, a Define-XML variable definition — must be reviewed and approved by a qualified person before it can be considered part of the trial's records. The qualified person's review must be documented, attributed to their identity, and timestamped.
This is not a new requirement — E6(R2) required human oversight of data management processes as well. What E6(R3) adds is specificity about what "documented" means and what an inspector should be able to find when they audit a computerized system. The audit trail for a qualified person's review of an AI proposal is not optional documentation. It is a required record under E6(R3) section 4.9.
Risk-based validation for AI systems
One of E6(R3)'s central contributions is the formalization of risk-based approaches to GCP compliance. For computerized systems, this means validation effort should be scaled to the risk level of the system's intended use. A system that produces outputs that go directly into regulatory submissions without additional human verification requires more rigorous validation than a system used for internal planning.
For AI-assisted SDTM mapping, the risk level is high. The outputs directly influence the submission package. A mapping error that survives to submission can cause a Pinnacle 21 failure or trigger a deficiency letter. Under E6(R3)'s risk-based framework, this use case requires a validation package that specifically addresses the AI components' accuracy, consistency, and behavior under edge cases — not just the application infrastructure they run on.
The validation package should include: a definition of intended use and scope, qualification testing against known cases with verified correct outputs, a description of confidence scoring and how it relates to the human review decision, and a documented process for updating the validation when the underlying model is changed.
What "data integrity" means for AI-generated records
E6(R3) emphasizes data integrity throughout Chapter 4. For AI-generated records, data integrity has a specific implication that differs from traditional EDC data integrity: the record must not only be accurate, but its provenance must be traceable. A data point in a clinical database that was originally proposed by an AI agent, revised by a DM lead, and approved by a senior programmer must reflect that chain of custody — not just the final value.
This is what distinguishes an audit-trail-compliant AI system from a system that merely produces correct outputs. Correct outputs without provenance do not meet E6(R3)'s data integrity standard. The chain of custody from AI proposal to human approval to committed record is the compliance story. It must be documentable on request.
Practical steps for sponsors using AI DM tools
Given the E6(R3) requirements, sponsors evaluating or currently using AI tools in their data management pipeline should verify the following:
First, confirm that the AI tool's audit trail captures agent-level operations, not just human interactions. Ask the vendor for an example audit report from a study showing both agent inference records and human approval records.
Second, confirm that a validation package exists for the AI components. The validation package should address the system's intended use in SDTM mapping, Define-XML generation, or whatever data management function it performs — not just the application layer.
Third, confirm that the human approval step is architecturally enforced. A system where the approval step can be bypassed by configuration does not meet E6(R3)'s human oversight requirement — the oversight must be structural, not optional.
Fourth, document your data governance framework explicitly for AI-generated artifacts. The framework should describe how AI outputs are generated, reviewed, and approved, and how the chain of custody is maintained from AI proposal to committed record. This documentation is what an inspector will look for under section 4.1 of E6(R3).
E6(R3) does not prohibit AI in clinical data management. It sets the bar for what compliant AI-assisted data management looks like. The bar is achievable — but it requires AI tools that were designed for the regulated environment, not tools designed for general productivity that have been deployed in a regulated context without the necessary compliance architecture.