Life Sciences AI: What Regulated Teams Can Actually Deploy Today

The use cases that clear validation most easily share three properties

Across the deployments that have made it into regulated production, the pattern is remarkably consistent. The task is bounded, the input is structured, and the output is checkable by a qualified person in less time than it would take them to produce it themselves. Miss any one of those and validation becomes disproportionately expensive.

Bounded means the task has a defined beginning and end and a limited set of acceptable output shapes. "Generate a test script for this requirement" is bounded. "Improve our validation approach" is not. Bounded tasks can be specified in a URS, which means they can be tested.

Structured input means the system is reasoning over records you control — requirements, case forms, deviation records, batch data, a document corpus with known provenance — rather than over open-ended free text of uncertain origin. Structured input makes the output reproducible enough to test, and it makes citation possible.

Checkable output is the property people underweight. A reviewer must be able to determine whether a given output is correct without redoing the work. A generated test script is checkable: read it, confirm it exercises the requirement. A generated risk rationale with citations is checkable. A recommendation with no supporting evidence is not checkable at all, which means human review degrades into rubber-stamping — the exact failure mode an inspector probes for.

Run your candidate list through those three filters before you build anything. In practice it usually promotes validation documentation, test generation, traceability maintenance, document assembly, deviation triage, safety narrative drafting, and literature screening — and it demotes most of what appears in vendor roadmaps.

The assurance evidence you need before production

This is the part teams consistently underestimate, and it is worth being concrete about it because the list is finite. Six artefacts carry almost all the weight.

• Model governance. A documented record of which model version is in use, who approved it for this intended use, what changed at the last update, and how a change is controlled. A model that silently updates underneath a validated process is an uncontrolled change, and an inspector will treat it as one.
• An evaluation set that gates releases. A held-out, representative set of cases with known-correct answers, with defined acceptance thresholds, run before any model or prompt change reaches production. This is the single most load-bearing artefact in the whole package — it converts "the output looks good" into evidence.
• Safeguards on output. Deterministic checks the output must pass before a human ever sees it: schema conformance, required citations present and resolvable, forbidden content absent, numeric values within range. These catch the failure classes that are cheap to catch mechanically and expensive to catch by reading.
• A human-in-the-loop policy with teeth. Written definition of what a reviewer must check, what evidence they need to do it, how long it should take, and what happens when they reject. Review that cannot be performed in the time allotted is review that will not be performed. why human-in-the-loop can't be a footnote goes through this in detail.
• Drift monitoring. Ongoing measurement of output quality in production against the evaluation baseline, plus monitoring of input distribution. Validation is a point-in-time statement; a probabilistic system needs continued evidence that the statement still holds.
• A documented fallback. What the process does when the system is unavailable, degraded, or its output is rejected. If the answer is "the work stops", you have introduced a single point of failure into a regulated workflow, and that is itself a finding.

Assemble these before the pilot rather than after. Every one of them constrains the design, and retrofitting them is where most programmes lose their schedule. AI governance exists largely to help teams get this package right the first time; our broader piece on AI governance in life sciences covers the organisational side.

Annex 22 and Part 11 are architecture inputs, not paperwork

The most common and most expensive misreading of the regulatory position is that Annex 22 and 21 CFR Part 11 are documentation obligations you satisfy at the end. They are not. Both make claims about system behaviour, and behaviour is decided in the architecture.

The draft EU GMP Annex 22 draws a hard line: an adaptive or generative model may not be the decision-maker on a GMP-critical question. That is a statement about where a decision is taken in your system, not about what your SOP says. If your workflow lets a model's output become an approved record without a qualified person exercising judgment on it — including by making rejection so effortful that nobody rejects — you have a design problem that no procedure will fix. Build the human decision point into the data model so the state transition is impossible without it. Our Annex 22 requirements walkthrough covers the specific clauses.

Part 11 shapes the record layer. Electronic signatures must bind to the specific record and the specific meaning of the signature. Audit trails must be computer-generated, time-stamped, and independent of the operator, and they must capture the AI-generated draft, the human edits, and the approval as distinct, attributable events. Storing only the final approved artefact loses the evidence that a human actually exercised judgment, which is precisely what an inspector will ask you to demonstrate. FDA 21 CFR Part 11 compliance covers the record requirements in full.

The practical consequence for architecture is a short list: version and pin your models; make citation a structural property of every output rather than a formatting convention; record the pre-edit draft alongside the post-edit approved version; make the reviewer identity and the review evidence part of the record; and make the whole chain queryable, because at some point you will have to reconstruct how one specific output came to exist. Explainability in a GxP context is mostly this — traceability, not model interpretability research.

Buy versus build

Building an AI capability on top of a foundation model is straightforward now; building the assurance layer around it is not, and that is where the effort actually goes. A realistic internal build means owning an evaluation harness, a model version control and approval process, output safeguards, a review interface a quality reviewer will accept, an audit trail that meets Part 11, drift monitoring, and the validation package for all of it. Then you own maintaining that against model deprecations you do not control.

Build makes sense when the use case is genuinely specific to your organisation — a proprietary process, an internal data model nobody else has, a workflow that is a competitive asset — and when you have an engineering function that can carry validated software long term. It is a poor choice for common regulated workflows, where you would be rebuilding an assurance layer that already exists and then validating your version of it.

When you buy, the evaluation questions that matter are narrow. Does every output carry a resolvable citation to source? Is a reviewer's edit itself an auditable event? What model versions are in use, and what is the vendor's change-control commitment when a provider deprecates one? What evaluation evidence can they hand you, on your data rather than their demo set? Can the system produce, for a single historical output, the full chain of input, model version, generated draft, reviewer, and approval? A vendor who cannot answer the last one is selling a chat feature with a compliance page. GxP Copilot and TraceDraft were built around those answers, which is the honest reason we can be specific about the questions.

There is a middle path worth naming: buy the assurance layer and the validated workflow, and build the narrow domain logic that is genuinely yours on top of it. For most biotechnology and medical devices organisations under a few thousand people, that is the right shape.

A pilot-to-production path with real gates

A pilot that cannot fail is not a pilot. The sequence below works because each stage has an explicit gate that a programme can genuinely not pass, which is what keeps a weak use case from consuming a year.

• Stage 1 — use case selection. Apply the bounded / structured / checkable filter and write down what "correct" means for this output. Gate: you can state the acceptance criteria in a sentence a quality reviewer agrees with. If you cannot, stop here.
• Stage 2 — evaluation set construction. Assemble fifty to two hundred representative cases with known-correct answers, drawn from your real historical records including the messy ones. Gate: quality has reviewed the set and agrees it represents production reality.
• Stage 3 — offline evaluation. Run the candidate system against the set. Measure against your thresholds. Gate: the system meets the thresholds on real data, and the failure modes are characterised — you can describe the shape of what it gets wrong, not just the rate.
• Stage 4 — shadow or parallel run. Run alongside the existing process on live work for four to eight weeks without the output being used. Gate: review time per item is genuinely lower than doing the work manually, and reviewers reject at a rate consistent with offline results. A rejection rate of near zero in a parallel run usually means reviewers have stopped reading.
• Stage 5 — validation and controlled release. Complete the validation package including the assurance evidence above, train reviewers against the HITL policy, and release to one team or one system. Gate: quality sign-off, and a documented fallback that has been tested rather than merely written.
• Stage 6 — monitored production and expansion. Drift monitoring live, periodic re-evaluation scheduled, change control covering model updates. Gate: one full re-evaluation cycle passed before expanding scope.

End to end this is typically three to six months for a first use case and materially faster for the second, because the assurance layer is reusable even when the use case is not. Automated validation in life sciences covers what this looks like once several use cases are running in the same programme.

What is still not deployable, and why that is fine

Being clear about the current ceiling is more useful than optimism. Autonomous agents executing multi-step GMP workflows without a human decision point are not deployable, and the constraint is regulatory rather than technical. Models that adapt continuously in production are not deployable in a validated state, because the validated entity would be changing underneath the validation. Anything that makes a batch release, product quality, or patient safety determination without a named qualified person is not deployable, and will not become deployable by an architecture improvement.

That ceiling leaves a very large amount of real work available. The bulk of effort in a validation function, a medical writing team, or a safety operation is not final judgment — it is assembly, retrieval, drafting, cross-checking, and consistency maintenance. Those are exactly the tasks that fit the bounded / structured / checkable shape, and taking them off a qualified person's desk is what makes the judgment work better rather than merely faster. GxP AI for mid-size biotech covers how this plays out in smaller organisations, and book a demo if you want a specific use case assessed against the gates above.