Which trial software has the best automation features? A site cannot answer that until automation is separated from AI. Automation fires a predetermined rule and returns the same output every time, so it needs testing. AI returns a proposal that varies with its input, so it needs a named person to confirm it.
Both arrive under one word on a vendor slide, and a site that cannot tell which it is being shown cannot size the validation work it is taking on. This guide classes the features a trial platform ships, states what each one needs before it can be trusted, and makes the case for fixing the deterministic work first.
Which Trial Software Has the Best Automation Features?
That question usually gets a vendor name for an answer, and a vendor name tells a site nothing about what it will have to prove at an inspection. The best automation in a trial platform is the automation a site can write down as a rule, test once against its protocols, and then stop thinking about.
Three properties separate automation worth buying from a feature that merely looks busy.
- The rule is visible in configuration. A site can read the rule, see who may change it and place it under change control, which makes the behaviour auditable rather than assumed.
- The output is reproducible. The same inputs produce the same result on every run, which allows a single test script to stand as evidence until the rule changes.
- The failure is visible. The rule fires or it does not, and the audit trail records the trigger, so a missed action shows up as an absent record rather than a silent wrong answer.
A feature failing those three tests is probably a model rather than a rule, whatever the demonstration called it. The distinction decides the paperwork.
What Is the Difference Between Automation and AI in a Clinical Trial Platform?
Rules-based automation executes a condition a human wrote. A due date calculated from a site initiation date, a reminder at a threshold, a status that changes when a report is filed, a field that refuses a value outside a range: each is a deterministic function with one correct output. An AI feature produces a proposal from a model whose output varies with its input, so it is right most of the time and wrong some of the time, and the system cannot tell a site which is which without a person looking.
| Aspect | Rules-based automation | AI feature |
| What it does | Executes a condition written by a person | Proposes an output inferred from a model |
| Same input, run twice | Identical output every time | Output may vary, and varies more at the edges of the data |
| What governs the behaviour | A configuration item a site can read | A model version the supplier controls |
| What it needs to be trusted | Test scripts covering the rule, its boundaries and its error handling | Validation for the site’s intended use, plus a named person confirming each output |
| Typical failure | The rule is wrong or scoped wrongly, and fails the same way every time | A plausible output that is wrong in one case and right in the next |
| Effect of a supplier update | Regression test of the affected rules | A new model version enters change control, and the feature is reassessed |
| Where accountability sits | With the person who configured and approved the rule | With the named person who confirms the output before it becomes a record |
A rule fires. A model proposes.
Which Platform Features Are Automation, and Which Are AI?
The table below classes the features a UK research site is most often shown, and states the evidence each class attracts.
| Platform feature | Class | What it needs before a site trusts it |
| Visit due dates calculated from a site initiation date | Automation | Test the calculation against each protocol schedule, including month ends and amended windows |
| Reminder raised when a document reaches its review threshold | Automation | Test the threshold, the lead time and the recipient list for every document type in scope |
| Status that changes when a condition is met | Automation | Test each transition, and confirm the audit trail records the trigger and not only the saved state |
| Field validation that refuses an out-of-range value | Automation | Boundary testing at the limit and either side of it, with the error message checked |
| Mandatory fields and signature order enforced before save | Automation | Evidence the system blocks the path rather than warning the user |
| Expected document list generated from study type and country | Automation | Review of the template that produces the list, plus a check against one live protocol |
| Document type proposed on upload | AI | Acceptance rate per document type, a reversible misfile, and confirmation before anything is filed |
| Dates, version numbers and names read off a document into fields | AI | Accuracy per field, and a confidence threshold that routes a weak read to a person |
| Contradiction flagged between two record sets | AI | A written list of the records it reads across, and a worked example on the site’s own records |
| Deviation descriptions or response text drafted | AI | Review before the text becomes a record, and a control against unverifiable citations |
| Natural-language search across filed records | AI | A relevance test on the site’s own document set, and the permission model behind it |
| Risk scores that prioritise findings | Either, so ask | The scoring logic in writing. A weighted rule set is automation. A learned score is AI. |
The last row is the one that moves in a procurement. Prioritisation is sold as intelligence and is often a weighted rule set, which is good news for a buyer, because a rule set can be read, tested and owned. A site should also establish whether a flag on the investigational medicinal product (IMP) accountability record is a threshold rule or an inferred score.
Also Read: How AI Finds Documentation Gaps in an Investigator Site File works through the cross-record check in the ninth row, including how a flag is scored, routed to a person and what it does and does not prove.
Does Rules-Based Automation Need Validation?
Yes. Automation is a computerised system function, and the general rules reach it in full. ICH E6(R3), which reached Step 4 on 6 January 2025, states at Principle 9.3 that “computerised systems used in clinical trials should be fit for purpose (e.g., through risk-based validation, if appropriate)”. Section 2.12.10 puts the duty on the investigator and institution to ensure the computerised system requirements are addressed “proportionate to the risks to participants” and “to the importance of the data”, which is the sentence that sizes the work.
The same logic appears in EU GMP Annex 11 on computerised systems, which UK sites meet through the Annex 11 assessment in a supplier’s validation package. Its principle states that “where a computerised system replaces a manual operation, there should be no resultant decrease in product quality, process control or quality assurance”. Clause 4.7 requires that “system (process) parameter limits, data limits and error handling should be considered” in test scenarios, which is a precise description of how an automated rule is tested. The MHRA guidance on GxP data integrity, published 9 March 2018 and last updated 27 September 2021, carries the audit trail and risk-proportionality expectations behind both.
Validation of a deterministic rule is finite work with a clear end point.
- The rule is specified before it is tested. A written statement of the condition and the expected output gives the test script something to prove, which is what turns a screenshot into evidence.
- Boundaries carry the risk. Testing at the limit, either side of it and on an invalid input exposes the scoping error that a happy-path test hides.
- The configuration is a controlled item. A change to a date rule or a threshold runs through change control with a named approver, so the rule a site tested is the rule still running a year later.
- Testing ends. A deterministic function proven once stays proven until the rule or the release changes, which is the economic advantage of automation.
The method, including the risk categorisation that decides how deep the testing goes, is set out in GAMP 5 and computerised system validation.
What Changes When a Feature Becomes AI?
Four obligations attach to an AI feature that a deterministic rule never attracts, and each one lands on the site rather than the supplier.
- Validation for intended use. The feature is validated for the job the site uses it to do, so a supplier’s package supports that work without replacing it.
- Model versioning. The model behind the feature carries a version identifier that belongs in the system inventory, which is what makes the behaviour a site tested identifiable later.
- Change control on model updates. A model that improves behind an unchanged screen is a change to a validated function, so the notice period and the regression testing belong in the agreement.
- An enforced confirmation step. A named person reviews and confirms every output before it becomes a record, enforced by configuration rather than by policy, which keeps the accountable decision with the individual the delegation log authorises.
AQ meets the last of those by configuration: its AI proposes, flags and drafts, and a named person reviews and confirms. The activity-by-activity line between what a model may propose at a site and what it must never do is set out in Is It Safe to Use AI in GxP Clinical Trial Systems? What MHRA Expects.
Also Read: AI for Compliance and Inspection Readiness: What a UK Site Should Look For in a Platform carries the seven-row claim taxonomy, the five-line specification and the weighted scorecard for comparing two shortlisted platforms.
Should a Site Automate Before Adding AI?
Yes, and the reason is mechanical. An AI feature reads the records a site already holds. Records assembled by hand carry gaps and late entries that are invisible to the model, so the model reasons confidently across them and produces proposals a quality lead has to disprove one at a time.
Consider a hypothetical multi-site organisation, Northgate General, that keeps its delegation log on a spreadsheet updated monthly and files training certificates in a separate folder. A cross-record check reads both and reports three staff who performed delegated activities without current training. One is real. The other two are artefacts of the records: the delegation log had not been updated since the last protocol amendment, and two certificates were filed six weeks after the training date. The quality lead spends a week reconciling three flags, and the flag count on the dashboard means nothing to anyone.
An AI layer inherits the reliability of the records underneath it.
Three deterministic foundations carry most of that risk, and each is a rule rather than a model.
- Entries created from an authorised source. A delegation entry generated from the approved list with an effective date removes the transcription step, which is where the drift between the log and the activity starts.
- Dates calculated rather than typed. Training currency derived from the certificate date, and review dates derived from approval dates, make a lapse a system state instead of a manual check somebody has to remember.
- Completeness enforced at the point of entry. Mandatory fields and blocked saves stop an incomplete record existing, which is cheaper than finding it in a report three months later.
An AI layer over those three foundations reads records that are already contemporaneous and attributable, and its flags then point at genuine contradictions rather than at the site’s own filing habits.
How Should a Site Size the Validation Burden Before Buying?
Five questions put to a supplier separate the two classes feature by feature, and each answer has a use beyond the meeting it is given in.
| Ask the supplier | What the answer tells a site |
| Is this feature a rule or a model? | Whether the output is reproducible, and therefore whether one test script can stand as evidence |
| If it is a rule, where is it configured and who may change it? | Whether the rule is a controlled configuration item a site can place under change control |
| If it is a model, which version runs today and how will we be told it changed? | Whether the feature can enter a site’s change control at all |
| Which of your validation documents cover this feature by name? | Whether the feature sits inside the validated scope of the release the site will run |
| Show the setting that stops this feature changing a record without a confirmation | Whether the human step is enforced by configuration or asserted in a policy |
The answers also set the business case. Deterministic features add test scripts in year one and little after. AI features add user acceptance testing, procedure changes, training and a reassessment every time a model version moves. Weighting those dimensions before a demonstration is covered in the AI compliance and inspection readiness guide.
Automation and AI in the AQ Platform
AQ separates the two classes by design, and keeps both inside one validated release and one audit trail.
- Deterministic work sits in configuration across AQ CTMS and AQ QMS: visit windows and due dates calculated from study dates, review and training currency derived from approval and certificate dates, and mandatory fields enforced before a save.
- Connected Intelligence is the AI capability across the platform, and AQ Assist is the in-platform assistant a user works with directly.
- AQ’s AI proposes, flags and drafts, and a named person reviews and confirms, which keeps the accountable decision with the individual the delegation log authorises.
- Every AI action is written to the audit trail, so the proposal and the confirmation are both retrievable for an inspector.
- AQ is validated to GxP standards with every release, covering IQ, OQ and PQ with a 21 CFR Part 11 and EU Annex 11 assessment, so the automated rules and the AI features both sit inside the validated scope of the version a site runs.
- 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 more than 150 studies run on the platform. It supports MHRA compliance and is built for MHRA GCP inspection. Book a live demo to put the five supplier questions above to the platform, feature by feature.
Frequently Asked Questions
What is the difference between automation and AI in a clinical trial platform?
Rules-based automation executes a condition a person wrote, and returns the same output every time from the same input. An AI feature produces a proposal inferred from a model, and the output varies with the input. Automation is validated as a deterministic function through test scripts. An AI feature is validated for the site’s intended use and needs a named person to confirm each output before it becomes a record.
Which trial software has the best automation features?
Judge the automation rather than the brand. The strongest automation in a trial platform has the rule visible in configuration, a reproducible output, and a failure that shows in the audit trail. Ask a supplier to name which features are rules and which are models, where each rule is configured and who may change it. A platform that answers that consistently is describing a real build.
Does rules-based automation need validation?
Yes. Automation is a computerised system function, and ICH E6(R3) Principle 9.3 requires computerised systems used in clinical trials to be fit for purpose through risk-based validation where appropriate. The depth is proportionate to the risk to participants and the importance of the data. Testing covers the rule, its boundaries and its error handling, and it ends once proven, until the rule or the release changes.
Should a site automate before adding AI?
Yes. An AI feature reads the records a site already holds, so gaps and late entries in hand-assembled records produce confident proposals that a quality lead has to disprove individually. Entries created from an authorised source, dates calculated rather than typed, and completeness enforced at entry are deterministic fixes. An AI layer over those records flags genuine contradictions instead of filing habits.
Who is accountable when an automated rule fires incorrectly?
The organisation remains accountable for the accuracy and completeness of its records, and within it the accountability sits with the person who specified and approved the rule. An automated rule is a controlled configuration item, so a wrong due date or a mis-scoped threshold is a change control and deviation matter rather than a user error. The audit trail should show the trigger that fired, which is what allows the scope of the error to be established.
