What are the EMA and FDA principles for AI in clinical trials? They are ten joint guiding principles of good AI practice in drug development, published on 14 January 2026. They cover context of use, risk, data governance, performance assessment and life cycle management. They are not binding rules, and they shape the guidance each regulator writes next.
This guide takes each of the ten principles in turn and states what it asks of a UK research site and what it asks of a sponsor. It also sets out where the principles sit against the rules a UK site is already legally bound by. The wider map of AI use across a trial is covered in How is AI used in clinical trials?, and platform evaluation against AI claims in AI for compliance and inspection readiness.
What Are the EMA and FDA Principles for AI in Clinical Trials?
The European Medicines Agency and the US Food and Drug Administration published Guiding principles of good AI practice in drug development on 14 January 2026. The two agencies identified the ten principles jointly, and each published the same document. The FDA copy carries identical principle headings.
Three facts decide how much of it reaches a research site.
- Scope. The document states that AI “refers to system-level technologies used to generate or analyse evidence across the drug product life cycle”, which spans nonclinical work, clinical trials, manufacturing and safety monitoring.
- Status. The agencies describe the ten as “intended to lay the foundation for developing good practice”, and the EMA announcement states that they “will underpin future AI guidance in the different jurisdictions” and “will be supplemented by additional EU guidance”. No enforcement sits in the document itself.
- Audience. The principles address whoever develops or deploys an AI system producing regulatory evidence, which in most trials means the sponsor and the supplier rather than the site.
Ten principles arrived. No new rule book arrived with them.
Which Ten Principles Did the Agencies Publish?
The ten headings appear below in the agencies’ own order, each with the one thing it asks for.
- Human-centric by design. Human wellbeing and ethical values shape the system from the start of design.
- Risk-based approach. Validation, controls and oversight match the context of use and the assessed model risk.
- Adherence to standards. The system meets the legal, technical, scientific, cybersecurity and regulatory requirements that apply, including GxP.
- Clear context of use. The role and scope of the AI are defined before development, which governs how it is validated.
- Multidisciplinary expertise. AI technical skill sits alongside knowledge of the area where the system is used, across the life cycle.
- Data governance and documentation. Data sources, processing steps and analytical decisions are recorded so they can be traced and verified, and sensitive data is protected.
- Model design and development practices. Sound engineering practice and fit-for-purpose data support interpretability, accuracy, reliability and robustness.
- Risk-based performance assessment. The whole system is evaluated, including how people interact with it, using metrics suited to the intended use.
- Life cycle management. Quality management covers the whole life cycle, with scheduled monitoring and periodic re-evaluation to catch data drift.
- Clear, essential information. Purpose, performance, limitations and updates reach users and patients in plain, accessible language.
What Goes Wrong When a Site Reads the Principles as a New Rule Book?
Two failure modes follow a publication like this one, and a research office can produce either within a fortnight.
The first is a parallel policy. A quality lead writes an AI procedure alongside the existing computerised systems procedure, with its own approval route, risk register and training record. Six months later two documents govern one system, and the platform validation file cross-references neither. An inspector asks which procedure applied on the day a flagged document was filed, and the answer takes a week to assemble.
The second is silence. A research office reads that the principles are not binding and files the news. The platform ships a model update in the next release, the classification behaviour changes, and no change control record captures it, because nobody decided who owned the question. The delegation log still names the right people. The evidence that those people reviewed a known version of a known feature is missing.
Both failures share one cause. The principles describe work an existing quality system already has a home for, and the error is building a second home or none.
The principles ask for records a site already keeps. They ask for them about one more thing.
How Do the Principles Sit Alongside MHRA Expectations?
A UK research site works to three separate published items, and only one of them is law. The distinction decides what a site must do and what it only has to read.
| Published item | Date | Status in the UK | What it actually governs |
| ICH E6(R3) good clinical practice principles | Step 4 on 6 January 2025; legal requirement from 28 April 2026 | Legally binding under Regulation 28 of the amended UK Clinical Trials Regulations | Trial conduct, including the computerised systems a site uses |
| EMA and FDA guiding principles of good AI practice in drug development | 14 January 2026 | Guiding. The agencies describe them as a foundation for future guidance | AI generating or analysing evidence across a medicine’s life cycle |
| MHRA AI Airlock | Phase 3 opened 6 October 2026 | Not formal guidance. The MHRA states that its reports “do not constitute formal guidance” | AI-enabled medical devices, as a sandbox rather than a rule |
Compliance with the ICH E6 GCP principles became a legal requirement in the UK on 28 April 2026. The MHRA guidance on compliance with ICH E6 GCP in the United Kingdom, last updated that day, states that Regulation 28 refers to the guideline “as amended from time to time”. The Annexes are not legally binding in themselves, while the UK-specific principle requires that “the investigator and sponsor must have regard to all relevant guidance”.
That last clause is where the principles acquire practical weight. A UK site has a standing duty to have regard to relevant guidance. Ten principles published jointly by two major regulators qualify for a site running an AI feature in a trial system, and an inspector may reasonably ask whether the site has read them.
The MHRA AI Airlock is frequently cited here and addresses something else. It is a regulatory sandbox for AI-enabled medical devices, launched in spring 2024, with Phase 3 opened on 6 October 2026 and focused on post-market surveillance. A research office reading Airlock material finds nothing there governing a document classification feature in its site file. What MHRA expects of AI inside a GxP trial system is covered in Is it safe to use AI in GxP clinical trial systems?.
Also Read: How to Complete the MHRA Computerised Systems Inspection Dossier covers the system inventory that every tool a site uses must appear in, including an AI feature inside a platform already in service.
What Does Each Principle Ask of a UK Site and of a Sponsor?
The principles are written for the whole drug development life cycle, so a single reading serves neither party well. The table below splits each one: the site column states the work a UK research site can perform, the sponsor column the duty that stays upstream.
| Principle | What it asks of a UK research site | What it asks of a sponsor or developer |
| 1. Human-centric by design | Keep a named person in front of every AI output before it reaches a trial record, and record who confirmed it | Show that participant wellbeing shaped the design, not a later review |
| 2. Risk-based approach | Scale the evidence held to what a wrong output would cost, from a wasted minute to an unseen quality signal | Assess model risk per context of use and justify the oversight chosen |
| 3. Adherence to standards | Hold the AI feature to the same GxP, security and data protection standards as the system it sits in | Demonstrate conformance to the technical, scientific and regulatory requirements that apply |
| 4. Clear context of use | Write down what the feature is for before it goes live, in lines specific enough for a validation test to use | Define the role and scope of the AI before development begins |
| 5. Multidisciplinary expertise | Put research staff who know the process alongside whoever administers the system when a new use is approved | Combine AI skill with therapeutic and regulatory knowledge across the life cycle |
| 6. Data governance and documentation | Record the data the feature reads, who can see it, how long it is kept and the lawful basis for processing it | Trace data sources, processing steps and analytical decisions for verification |
| 7. Model design and development practices | Ask the supplier which practices were followed and keep the answer on file. A site writes none of the model code | Use sound engineering practice and fit-for-purpose data, supporting interpretability and robustness |
| 8. Risk-based performance assessment | Test the task as staff perform it, including the confirmation step, against a scripted set with a stated acceptance rate | Evaluate predictive performance using metrics suited to the intended use |
| 9. Life cycle management | Bring every model version under change control and re-check performance on a schedule rather than on rumour | Run quality management across the AI life cycle and monitor for drift |
| 10. Clear, essential information | Tell staff what the feature does, what it cannot do and when it last changed, in the training record | Provide purpose, performance, limitations and updates in language suited to the audience |
Three of the ten are almost entirely upstream. Principles 5 and 7 describe how a model gets built, and principle 3 rests largely on the supplier’s own conformance evidence. A site’s honest position on those three is a question put to the vendor and a written answer kept on file. Principle 6 runs into UK law directly, and the controller and processor duties behind it sit in UK GDPR for clinical trial sites.
Which Principles Produce a Document, a Test or a Routine?
A site that wants to act on the principles needs them sorted by the kind of work each creates. Sorted that way, the ten fall into three groups, each landing in a record a research office already maintains.
- A document you write once and revise. Principles 4, 6 and 10 produce an intended-use statement, a data record and a plain-language description of limits. The evidence lives in the validation file, the AI use register and the training record, which means a site satisfies three principles with three short entries rather than a policy.
- A test you run before go-live and after each change. Principles 3, 7 and 8 produce qualification evidence, a vendor assessment and a performance result against a scripted set. The evidence lives in the qualification report, which means the acceptance criterion chosen there is the most consequential decision in the group.
- A routine you maintain for as long as the feature runs. Principles 1, 2, 5 and 9 produce a confirmation step, a proportionate risk position, an approval group and change control. The evidence lives in the audit trail, approval minutes and change control record, which means this group alone fails silently when nobody owns it.
The routine group carries four principles and produces no deliverable a site can finish. It is also the group the second failure mode destroys. A model update ships, the behaviour shifts, and the audit trail records confirmations against a version nobody wrote down.
The method behind the test group, from the intended-use statement and the acceptance criterion through to model change control, is set out in validating an AI feature in a regulated clinical trial system. The approval route, training expectation and periodic review that hold the routine group together belong in one written procedure, covered in how should a research site govern the use of AI?. The validation method for the system itself sits in GAMP 5 and computerised system validation.
AQ’s AI proposes, flags and drafts, and a named person reviews and confirms, so the confirmation step principle 1 asks for is a property of the record rather than a local habit. Every AI action is written to the audit trail, which makes the principle 9 question answerable years later.
Also Read: Is your research site ready for AI? scores the seven conditions that decide whether a site should hold, pilot on one study or adopt across the portfolio.
Good AI Practice Inside the AQ Platform
Connected Intelligence is the AI capability across the AQ Platform, and AQ Assist is the in-platform assistant a user works with directly. The principles a site carries itself map onto properties of the record rather than a separate exercise.
- AQ’s AI proposes, flags and drafts, and a named person reviews and confirms, which keeps the accountable decision with the individual the delegation record authorises.
- Every AI action is written to the audit trail, so the proposal and the confirmation are both retrievable for an inspector.
- Every AQ release goes through validated release and change control, with installation and operational qualification evidence and a 21 CFR Part 11 and EU Annex 11 assessment, so an AI feature ships inside the same release evidence as the version a site runs. Performance qualification stays with the site, against its own configuration and intended use.
- Quality and corrective action records sit in the quality management system and CAPA on one connected record, which allows the periodic review principle 9 asks for to read the evidence a confirmation was made against.
- The platform is UK-hosted, holds NHS DSPT Standards Met for 2026, is Cyber Essentials certified and runs ISO 27001-aligned controls.
AQ was built by Phase 1 trial doctors and has been in continuous daily NHS use for six years, with 13 sites on one connected record and 70 concurrent studies. It supports MHRA compliance and is built for MHRA GCP inspection. Book a live demo to see where a proposal becomes a confirmed record.
Frequently Asked Questions
What are the EMA and FDA principles for AI in clinical trials?
They are ten joint guiding principles of good AI practice in drug development, published by the European Medicines Agency and the US Food and Drug Administration on 14 January 2026. The headings are human-centric by design, risk-based approach, adherence to standards, clear context of use, multidisciplinary expertise, data governance and documentation, model design and development practices, risk-based performance assessment, life cycle management, and clear, essential information. Both agencies describe them as a foundation for future guidance in each jurisdiction.
Are the EMA and FDA AI principles legally binding in the UK?
No. The principles carry no enforcement of their own, and the UK is not a party to the document. A UK site still has a standing duty under the amended UK Clinical Trials Regulations to have regard to all relevant guidance, which covers a site running an AI feature in a trial system. The binding instrument remains the ICH E6 GCP principles, a legal requirement in the UK since 28 April 2026.
Which of the ten principles does a research site carry itself?
Seven of the ten produce work a site can perform. Principles 4, 6 and 10 produce documents: an intended-use statement, a data record and a plain-language description of limits. Principle 8 produces a performance test of the task as staff perform it. Principles 1, 2 and 9 produce a confirmation step, a proportionate risk position and change control over model versions. Principles 3, 5 and 7 describe how the model was built, so a site holds the supplier’s answer.
Do the principles mean a site needs a separate AI policy?
No, and a separate policy creates a known problem. A second document governing one system leaves an inspector asking which procedure applied on a given day. The principles ask for entries in records a quality system already holds: the validation file, the AI use register, the training record, the change control record and the audit trail. One written procedure covering approval, training, monitoring and review suits most sites.
Does the MHRA AI Airlock apply to clinical trial software?
No. The AI Airlock is a regulatory sandbox for AI-enabled medical devices, launched in spring 2024, with Phase 3 opened on 6 October 2026. The MHRA states that its Airlock reports do not constitute formal guidance. Software a site uses to run trial operations falls under the general computerised systems expectations instead.
What happens next after the EMA and FDA principles?
Jurisdiction-specific guidance. The EMA announcement states that the ten principles “will underpin future AI guidance in the different jurisdictions” and that EU guideline development is already underway. A site that aligns its records to the ten now carries less work when a binding instrument arrives, because the principles are the stated foundation for whatever each regulator writes next.
