AI agents and workflow automation for life sciences, built for the conditions a GxP process imposes rather than for a demonstration.
Across pharma, biotech and the CRO sector, agent pilots have gone well. The agent reads the protocol, drafts the narrative, reconciles the listing, finds the discrepancy, prepares the submission section. Everybody has seen it work. Very few organizations have one operating inside a regulated process, and the reason is not that the technology fell short. A pilot demonstrates that the agent can produce a correct result. A regulated deployment requires evidence that it does so consistently, that every action is attributable to an accountable person, and that an inspector can be shown why the output can be relied upon. Those are different claims, and the second one is the entire project.
Here is the problem underneath every stalled agent programme in this industry. Computer system validation is built on a reasonable assumption: that a given input produces a given output, repeatably, so testing a representative set of cases establishes how the system behaves. A language model does not work that way. The same input can produce a different output, both correct, phrased differently. A slightly different input can produce a materially different result. Nothing about this is a defect, it is the nature of the technology, and it means the standard validation argument does not transfer. You cannot test every case and conclude the behaviour is now known.
Organizations respond in one of two unsatisfactory ways. Some apply the traditional approach anyway, producing a protocol that tests a hundred examples and a report that overstates what those examples establish. Others conclude agents cannot be validated and keep them permanently in pilot, which is why so many demonstrations never touch a regulated process. Neither is necessary. What is required is an assurance argument built for a probabilistic component: bounded scope, constrained output, performance measured over a population rather than per case, a human accountable at the point of use, and monitoring that detects degradation.
The same prompt can produce different output
Which breaks the repeatability assumption every traditional validation protocol rests on.
Pilots prove capability, not consistency
A demonstration shows the agent can. Production requires evidence that it does, at volume.
Agents live in the gaps between systems
Those gaps exist because no integration was built, so there is no documented process to automate.
Attribution has nowhere to land
An agent has no qualification and no standing, so every action is somebody else’s responsibility.
The data is scattered across validated systems
LIMS, CTMS, eTMF, EDC, RIM and QMS each hold part of it and none of them was built to be read by software.
Quality is asked to approve something nobody has approved before
With no precedent to copy, the safe answer is no, and that is a rational response.
Ask what happens when the agent is wrong, before asking what it can do. Take the first process somebody wants to automate and work through the failure: the agent produces a plausible wrong output, nobody catches it, the work proceeds. Who is affected, how far does it travel, when would it be noticed, what would it cost to unwind, and whose name is on it. That conversation determines the autonomy level, the review model, the monitoring and the validation effort, and it takes an hour. Programmes that start with capability and reach this question late tend to discover that the process they chose first was the one they should have chosen last.
The first process matters more than the architecture. Chosen well, it proves the governance model on work where being wrong is recoverable, and the second deployment inherits an approved pattern. Chosen badly, the programme spends a year on a validation argument nobody has made before, in a process where the quality function is right to be cautious.
Step 1
Map where the time actually goes
Step 2
Score candidate processes by consequence and reversibility
Step 3
Discover the undocumented rule
Step 4
Set the autonomy level deliberately
Step 5
Design the attribution model
Step 6
Constrain the agent in the system, not in the prompt
Step 7
Build the evaluation set before the agent
Step 8
Integrate with the validated systems properly
Step 9
Agree the assurance argument with quality
Step 10
Operate with monitoring that detects drift
The first agent should be in a process where being wrong is survivable. Not the one with the biggest business case. The first deployment is not really about the process, it is about establishing the governance pattern, the validation argument, the monitoring approach and the quality relationship, and all of that is easier to establish where a mistake is caught quickly and costs little. Once approved, the pattern is reusable and the second and third deployments take a fraction of the effort. Organizations that lead with the highest-value regulated process spend their first year in a negotiation nobody has the precedent to resolve.
The line runs through every capability below. Finding information, checking it against a source, assembling it into a required form and drafting text for review are mechanical tasks performed by expensive people. Deciding whether something is acceptable, reportable, safe or compliant is not, and no amount of capability changes who has to own it.
Agents and orchestration
Single-purpose agents scoped to one process step, which is where this technology is most reliable and easiest to govern
Multi-agent orchestration where a workflow genuinely decomposes, with explicit handoffs rather than emergent coordination
Tool and system access through permissioned interfaces, so an agent can only do what it has been granted
Deterministic control flow around probabilistic steps, keeping the sequence predictable even where the content is not
Exception detection and escalation, since knowing when to stop is more valuable than handling one more case
Human-in-the-loop checkpoints placed where the consequence justifies them rather than uniformly
Document and data work
Document AI across protocols, reports, submissions, batch records, source documents and correspondence
Retrieval over your own content, with every assertion traceable to the passage that supports it
Extraction into structured fields, presented as candidates with provenance rather than written silently
Cross-document reconciliation, which is where most of the manual effort in this industry actually sits
Drafting against templates and conventions, producing a first version for a qualified person to own
Summarisation with the source attached, because a summary nobody can check is not usable here
Governance and operations
Evaluation sets built with the owning function, covering exceptions as well as the common path
Guardrails enforced in the system: scope limits, tool permissions, output constraints and approval gates
Audit trails that distinguish agent actions from human actions and record what the human was shown
Performance monitoring against the evaluation set, run continuously rather than at acceptance
Model and prompt change control, since both change behaviour and both are changes to a validated process
Validation support scoped with your quality function, designed around a probabilistic component
The third column is the work where the agent drafts and a qualified person decides, which is where every one of these should begin. The determination in each case stays with the function that owns it.
| Function | Where the effort goes today | Safe first automation |
|---|---|---|
| Clinical operations | Site communication, document chasing, status reconciliation | eTMF completeness checking and document classification at filing |
| Clinical data management | Query generation, listing review, discrepancy hunting | Candidate discrepancy identification for a data manager to confirm |
| Regulatory affairs | Assembling submissions from content held in several places | Locating and reconciling source content, with authoring left to people |
| Pharmacovigilance | Case intake, duplicate detection, narrative drafting | Duplicate detection and narrative drafting for qualified review |
| Quality management | Deviation triage, investigation assembly, trend review | Evidence assembly and similar-event retrieval before an investigation |
| Manufacturing and supply | Batch record review, deviation paperwork, CoA checking | Exception flagging on batch review, never disposition |
| Research and preclinical | Literature review, protocol drafting, data wrangling | Literature screening and structured extraction with sources retained |
What an agent can do is entirely determined by what it can reach and what it is permitted to do there. That access model is the architecture, it is where the governance lives, and it is considerably more consequential than the choice of model or framework.
| System | What it holds | Sensible initial access |
|---|---|---|
| eTMF and document systems | Study documentation, filing structure, completeness state | Read and classify. Propose filing, never file unreviewed |
| CTMS | Study, site, milestone and monitoring status | Read. Write only through a reviewed action |
| EDC and clinical data | Subject data, queries, listings, edit checks | Read. Propose queries for a data manager to issue |
| Safety database | Cases, narratives, coding, follow-up | Read and draft. No status change, no determination |
| RIM and submissions | Registrations, content, commitments, correspondence | Read and assemble. Authoring and filing stay with people |
| QMS | Deviations, CAPA, change control, training | Read and assemble evidence. No workflow advancement |
| LIMS, ELN and manufacturing | Results, batch records, specifications, process data | Read and flag exceptions. Never disposition or release |
A prompt is not a control, and in an audit it will not be treated as one. Instructing an agent not to approve anything, not to read outside its scope or not to proceed without confirmation describes an intention. Whether it holds depends on the model, the inputs and the phrasing, and it can be circumvented by content the agent reads. A control is a permission the agent does not have, a tool it cannot call, an approval gate it cannot pass or an output schema it cannot violate, all enforced by the system rather than requested of the model. Every guardrail that matters should be implemented that way, and the test is simple: would it still hold if the model ignored its instructions entirely.
None of the frameworks below was drafted with a probabilistic component in mind, and that is the honest starting point rather than an obstacle. Their requirements concern intended use, risk, control, attribution, data integrity and evidence, all of which apply perfectly well to an agent. What does not transfer is the implicit assumption that testing establishes behaviour once and for all. The assurance argument has to be constructed rather than copied, and it has to be owned by your quality and regulatory functions. We build systems that can carry whatever argument they approve, and we do not make the determination.
Frameworks the controls may need to support
- GxP expectations across the processes the agent touches, and GAMP 5 as the lifecycle framework for the system
- 21 CFR Part 11 and EU Annex 11 for electronic records and signatures, where the records fall within scope
- ICH GCP where the agent operates in clinical processes, with the sponsor obligations that implies
- Emerging AI governance expectations, which your regulatory function should be tracking as they settle
Data integrity and ALCOA+
- Attributable, which is the hardest one here, since an agent action must resolve to an accountable person
- Legible and contemporaneous, with agent actions timestamped and recorded as they occur
- Original and accurate, with every derived statement traceable to the source it came from
- Complete, consistent, enduring and available, applied to the agent’s record as to any other
Privacy
- Patient and subject data handled to the obligations your counsel defines, including HIPAA and GDPR where applicable
- Minimisation in what the agent is given, since the model only needs what the task requires
- Clear position on whether any content reaches a third-party model provider, and under what terms
- Data residency and cross-border processing assessed where the hosting arrangement implies it
Validation
- Intended use defined narrowly, because a broadly scoped agent is a broadly scoped validation problem
- Performance established over a population using the evaluation set, rather than case by case
- Human accountability documented as part of the control, not as a mitigation added afterwards
- Monitoring and periodic re-evaluation, since this is a component that can degrade without any change being made
The autonomy level should follow from what happens when the agent is wrong, not from what the agent is able to do. The ladder below is the one to agree with your quality function before anything is built, and most regulated work should sit on the first three rungs for a long time.
| Level | What the agent does | When it is appropriate |
|---|---|---|
| Retrieve | Finds and presents information, asserts nothing | Almost always. The value is high and the risk is close to zero |
| Draft | Produces output a qualified person reviews and owns | Where review is genuine at the volume intended, which is the condition |
| Flag | Identifies candidates and exceptions for human decision | Where the human decides and the agent only narrows the field |
| Act, reversible | Takes an action that can be undone without consequence | Where the action is logged, visible and genuinely reversible |
| Act, consequential | Takes an action with external or irreversible effect | Only with documented senior acceptance and sustained evidence |
| Decide | Makes a determination the quality system treats as a judgement | Not appropriate in GxP processes on current technology or expectations |
Agent programmes are reported as use cases piloted and hours theoretically saved. The outcome that matters is whether anything is running inside a regulated process with quality approval, because that is the threshold almost nobody has crossed and the one that converts the technology into results.
| Category | What we measure | Why it matters |
|---|---|---|
| Processes in validated production | Agent-supported processes approved and running, not piloted | The only outcome that distinguishes this from an experiment |
| Evaluation performance | Accuracy against the agreed set, trended, including on exceptions | The number the quality argument rests on, and the one that drifts |
| Genuine review rate | Volume per reviewer against what real review would take | Detects the formality problem before an inspector does |
| Edit rate on drafts | Proportion materially changed before a human owns them | The leading indicator of degradation, and it moves first |
| Escalation accuracy | How often the agent stops when it should, and does not when it should not | Knowing when to stop is the capability that makes the rest safe |
| Cycle time by stage | Where time actually moved, separating worked from waiting | Automation frequently speeds a stage that was not the constraint |
| Time from approval to second deployment | How reusable the governance pattern proved | Whether the first engagement built a capability or a one-off |
We will pick the process by consequence rather than by enthusiasm, discover the rule your people actually apply, build the evaluation set that makes performance a number, set autonomy and attribution with your quality function before anything is built, and deliver something that runs in production rather than something that demonstrates well.
CaliberFocus is a life sciences AI partner taking AI agents from successful pilot to validated production inside regulated processes. From choosing the first process by consequence and discovering the undocumented rule to building the evaluation set, setting autonomy and attribution with your quality function and enforcing guardrails in the system rather than the prompt, we deliver automation a GxP process can carry and defend.
- Autonomy scoped by consequence, not by capability
- Evaluation sets built with the function that owns the work
- Guardrails enforced in the system, not in the prompt
- Attribution and audit trails that separate agent and human actions
Security & Compliance
