Is it safe to use AI in GxP clinical trial systems under MHRA guidance? Yes, where the system is validated for its intended use, a named person reviews each output before it becomes a record, and the audit trail shows what the model proposed and who confirmed it. The MHRA judges the outcome and the oversight rather than the tool.
This guide covers what the MHRA has published, the failure mode it has already seen, the activities a site may hand to a model, the audit trail an AI-assisted entry leaves, change control, and the questions to put to a vendor.
- No MHRA guidance is written specifically for AI inside a GCP system, so the general computerised systems rules carry that weight.
- Accountability stays with the organisation, and the person who signs an output owns it.
- An AI feature is validated for its intended purpose, and the record of an AI-assisted action carries the input, the output, the model version and the confirming person.
Is It Safe to Use AI in GxP Clinical Trial Systems Under MHRA Guidance?
AI is permitted in a GxP clinical trial system on the same terms as any other computerised function. The MHRA GXP Data Integrity Guidance and Definitions, revision 1 of March 2018 and last updated on 27 September 2021, states at section 6.19 that computerised systems should be validated for their intended purpose, and section 3.6 sets the effort proportionate to the risk of a failure.
The risk of an AI feature follows what its output touches. A model drafting a cover note carries almost no regulatory weight. A model whose output lands in a trial record, a deviation log or a response to an inspector carries the full weight. The dividing question is whether a GCP record changes, and whether a person confirmed the change first.
- Criticality follows the decision. Section 4.1 ties criticality to how data influences decisions, which puts a suggestion that routes a deviation above one that reorders a task list.
- Human confirmation holds the line. A named person accepting or rejecting the output keeps attribution intact, which is the ALCOA+ attribute inspectors test first.
- The audit trail carries the proof. Section 6.13 requires it to capture who, what, when and why without obscuring the original record.
The model has no accountability. The signature does.
What Has the MHRA Actually Published About AI in GxP?
The MHRA Inspectorate published Use of AI for GXP inspection responses: setting standards without stifling innovation on 29 June 2026. It addresses submissions sent to MHRA compliance teams after a GxP inspection, and states that the agency’s concern is whether submissions are “accurate, verifiable, and prepared under appropriate oversight”, with a focus on process and outcomes rather than on specific tools.
That post is the agency’s clearest published statement on AI in a GxP context, and its scope is inspection responses. A site looking for a rule written for AI features inside a CTMS, an eTMF or an electronic site file finds the expectations distributed across the general computerised systems provisions. Four sources carry the weight between them.
| Published source | Version and date | What it settles for AI |
|---|---|---|
| MHRA Inspectorate, AI for GXP inspection responses | 29 June 2026 | Submissions must be accurate, verifiable and prepared under appropriate oversight, technically reviewed, and signed off by someone with authority and accountability |
| MHRA GXP Data Integrity Guidance and Definitions | Revision 1, March 2018, updated 27 September 2021 | Validation for intended purpose and the limits of vendor validation data (6.19), audit trail content (6.13), risk and criticality (3.6, 4.1, 4.2), contract duties (6.20) |
| ICH E6(R3) Guideline for Good Clinical Practice | Step 4, adopted 6 January 2025 | Systems should be fit for purpose (Principle 9.3), proportionate to risk (2.12.10(c)), source changes traceable (2.12.2), access secure and attributable (2.12.10(a)) |
| MHRA GCP inspections guidance | Updated 22 September 2026 | The dossier “must be provided within 30 days”, with a separate computerised systems dossier set dated September 2026 |
The absence of AI-specific guidance removes no obligation, because an AI feature is a computerised function and those rules already reach it. The Inspectorate post adds one expectation: the organisation, rather than its software, answers for what it submits.
Also Read: What MHRA Expects from Electronic Source Systems Under the 2026 UK Regulations
How Does a Fabricated Citation Reach an Inspection Response?
The Inspectorate post names the practices it will reject. Responses have cited MHRA guidance that does not exist, and frameworks inappropriate to the deficiency. Corrective and preventive action plans have arrived generic and superficial, with no genuine root cause analysis. One response ran past 90 pages while failing to address the deficiencies it answered.
The route into the file is short. A quality manager at a hypothetical trust, Northgate General, receives a major finding on delegation records. A model drafts the response overnight and quotes a plausible paragraph number from a guidance document that was never published. The draft goes out under the requester’s signature, and the organisation has made an inaccurate statement to an inspector.
- Verify every citation against the primary source. The person signing opens the cited page, which is the only check that catches an invented reference.
- Watch for the warning signs the MHRA lists. Generic language, absent site-specific detail, unexplained citations and inconsistent terminology all indicate inadequate verification, and a verbose response may simply be returned.
- Keep root cause work with the people who know the site. The post states that AI “cannot substitute for the technical understanding and organisational knowledge” a meaningful corrective action needs.
Materially false statements to inspectors have always been regulatory offences. A drafting tool changes the speed at which an inaccurate statement can be produced, and leaves the offence where it was. The findings a site answers most often sit in the guide to common MHRA GCP inspection findings, and the plan belongs in a governed CAPA record.
What May AI Do at a Site, and What Must It Never Do?
The published guidance stops short of a list, so a site writes its own and holds it in the quality system. The dividing line sits where a record becomes final. A model may do the preparatory work. The acts that create regulatory meaning stay with a named, delegated, trained individual.
| Activity | What a model may do | What it must never do | Who confirms, and where the record lands |
|---|---|---|---|
| Document filing | Propose a classification and filing location, and flag an absent record | File, reclassify or archive a document, or mark a section complete | Research governance lead, in the investigator site file |
| Data entry and correction | Draft a value, pre-populate a field, and flag a value outside an expected range | Save a correction, supply a reason for change, or close an open query | The delegated staff member, in the audit trail of that field |
| Training and delegation | Flag a signatory who acted before the training record was dated | Amend a training date or extend a delegation | Principal investigator, in the delegation log and training file |
| Deviations and CAPA | Draft a description, group related events, suggest a root cause | Set the grade, approve the plan, or close the action | Quality lead, in the deviation log |
| Signatures and approvals | Assemble the pack and identify who is due to sign | Apply an electronic signature, approve for a person, or re-date an approval | The named signatory, in the approval record |
| Regulatory submissions | Draft text and assemble supporting evidence | Supply a citation the signer has not verified against the primary source | The person with authority and accountability |
AQ’s AI proposes, flags and drafts, and it never closes a record or applies a signature. A list of this kind becomes testable when each row names the record the output lands in and the role that confirms it, because the delegation log then evidences the authority behind that confirmation.
A flag is a question. Only a person can answer it.
What Must the Audit Trail Show for an AI-Assisted Entry?
An AI-assisted entry has more to record than a typed one, because the proposal and the confirmation are two separate acts by two actors. Section 6.13 requires the trail to capture who, what, when and why, and that users cannot amend or switch it off. Five elements make the entry reconstructable.
- The input. The records the model was given, which lets a reviewer judge the basis of the output.
- The output as proposed. The suggestion in its original form, which shows what the person was asked to accept.
- The model version. An identifier for the version in use, which ties the output to a validated configuration.
- The decision and the person. Acceptance, rejection or amendment, attributed to a named user in their role at the time.
- The timestamps. Separate times for the proposal and the confirmation, which evidences a review rather than a reflex.
Every AI action inside AQ appears in the audit trail alongside the person who reviewed it. An inspector who finds a confirmed value with no visible proposal has to take the site’s word for how that value arrived.
How Is a Model Update Brought Under Change Control?
A model update changes system behaviour, so it travels the route any other change to a validated system travels. The difficulty is specific to AI: a vendor may improve a model without changing a screen, so a site can receive new behaviour with no visible release. Three controls close that gap.
- Require notice, and version the model in the inventory. The technical agreement names model changes as notifiable, and the inventory entry carries the model version beside the software version, so an old record can be read against the behaviour in force then.
- Re-test the intended use after an update. A short regression set against the site’s own scenarios evidences fitness for purpose on the new version.
- Record the assessment either way. A documented decision that no re-testing is needed is itself evidence. An undocumented one reads as an uncontrolled change.
The testing method itself is covered in GAMP 5 and computerised system validation, and the site-side sequence in validating a system before first patient in.
What Should a Site Ask an AI Vendor?
Section 6.19 states that vendor-supplied validation data in isolation is not acceptable without regard to configuration and intended use, and section 6.20 places the contract giver and acceptor responsibilities in a technical agreement. A site therefore buys evidence as well as software.
| Question to the vendor | Why it matters | The evidence to ask for |
|---|---|---|
| Where does the model run, and in which jurisdiction? | The answer drives the data protection assessment and the transfer position | A written statement of the processing location for each AI feature, in the data processing agreement |
| Is our data used to train your models? | Trial data used for training leaves the site’s control | A contractual prohibition, or a documented opt-out |
| What validation evidence covers the AI features? | Features released outside the validation scope sit outside the site’s qualification | Installation, operational and performance qualification per release, plus test scripts covering AI outputs |
| How will we be told about a model change? | A silent update is an uncontrolled change to a validated system | Release notes, and a notification clause in the technical agreement |
| Can the AI act without a human confirmation? | A feature able to close a record creates a signature nobody made | The configuration showing which actions require confirmation, and the permission set enforcing it |
Answers belong in writing and in the file, because an answer given in a demonstration evidences nothing at inspection. The wider assurance pack NHS procurement asks for is set out in the guide to DSPT and Cyber Essentials for research software.
When does AI in a trial system become a medical device?
Software intended for a medical purpose can be regulated as a medical device in the UK. The MHRA’s guidance collection on software and artificial intelligence as a medical device, last updated on 3 February 2025, states that many such products are regulated as devices, including in vitro diagnostic devices. The manufacturer’s stated intended purpose decides it.
- Operational AI sits outside the device regime. A feature that flags a missing training certificate has an administrative purpose.
- Clinical interpretation changes the position. A feature intended to diagnose, screen or guide treatment carries a medical purpose, and the device route applies in addition. Ask the vendor to state the intended purpose in writing.
Should a Site Disclose AI Use to an Inspector?
Disclosure of AI assistance in an inspection response is voluntary. The Inspectorate post states plainly: “This isn’t mandatory, but we believe transparency benefits everyone.” It adds that inspectors will consider disclosure positively, and describes what one holds.
- A brief statement at the start of the submission. The reader knows how it was prepared before reading it.
- Identification of the AI-assisted sections. The scope is bounded, leaving the other sections free of doubt.
- Confirmation of human verification and approval. The statement names the accountability the post requires.
The systems themselves are declared separately. The MHRA’s good clinical practice inspections guidance, last updated on 22 September 2026, publishes a computerised systems dossier template, clinical trial spreadsheet and checklist dated September 2026, alongside the standard dossier template at version 7.0 of December 2025. An AI feature inside a trial system is part of what that return describes, and the system inventory is where it appears. Which system owns which record decides where it is declared, as set out in which system you actually need.
Also Read: What Does an MHRA Inspector Look For in a Pharmacy Site File?
AI Governance Inside the AQ Platform
AQ runs AI as Connected Intelligence, with AQ Assist as the in-platform assistant, across the modules a site already keeps its evidence in. The governing design decision is the one described throughout this guide: AQ’s AI proposes, flags and drafts, and a named person reviews and confirms before anything becomes a record. AQ is built for MHRA GCP inspection on that basis.
- The confirmation step is built in. AQ Assist raises a proposal and a named user accepts, amends or rejects it, which keeps attribution on the person for every entry.
- Every AI action is in the audit trail. The proposal, the decision and the user sit in the same trail as manual entries, so one record reconstructs end to end.
- Release evidence comes with each version. AQ is validated to GxP standards with every release, with installation, operational and performance qualification and a 21 CFR Part 11 and EU Annex 11 assessment, which supplies the vendor half of a qualification file.
- The assurance position is documented. AQ holds NHS Data Security and Protection Toolkit Standards Met for 2026 and Cyber Essentials certification, operates ISO 27001-aligned controls, and the platform is UK-hosted.
- The record set is connected. Flags raised in the electronic investigator site file route into the quality management system as deviations or CAPA actions, which keeps one event in one thread.
AQ has been in continuous daily NHS use for six years, supports MHRA compliance, and was built by Phase 1 trial doctors. A live demo walks through how a proposal, a confirmation and an audit trail entry look in sequence.
Frequently Asked Questions
Is it safe to use AI in GxP clinical trial systems under MHRA guidance?
Yes, on the conditions that apply to any computerised function in a regulated system. The system is validated for its intended purpose, a named person confirms each output before it becomes a record, and the audit trail shows the proposal, the model version and the confirming user. The MHRA judges the oversight rather than the tool.
Does MHRA allow AI in GCP systems?
The MHRA has published no prohibition, and no guidance written specifically for AI inside a GCP system. Its 29 June 2026 Inspectorate post states that the agency’s concern is whether submissions are accurate, verifiable and prepared under appropriate oversight. The general computerised systems and data integrity expectations reach AI features as they reach any function.
Does an AI feature need validation?
Yes. Section 6.19 of the MHRA GXP data integrity guidance requires computerised systems to be validated for their intended purpose, and states that vendor-supplied validation data in isolation is not acceptable without regard to configuration and intended use. The depth of testing follows the risk.
Who is accountable for an AI-suggested entry?
The person who confirmed it, and the organisation that employs them. The Inspectorate post states that organisations remain responsible for the accuracy of their responses, and that those responsible must verify factual claims.
What should a site ask an AI vendor?
Where the model runs and in which jurisdiction, whether the site’s data is used to train it, what validation evidence covers each AI feature, how model changes are notified, and whether any AI action can complete without a human confirmation. Each answer belongs in a written agreement.
