AI is starting to act
Life-sciences teams are taking AI agents from pilots into day-to-day work: assembling batch records, drafting deviations and proposing decisions, not only summarizing them.
Life sciences
Agents can propose. A qualified person authorizes.
Before a batch is released, a GxP record is changed or a trial blind is broken, AtlaSent checks that the person acting holds the authority for that exact action, issues a single-use permit bound to it, and checks the permit again at the moment the system executes. Whether the request came from a person, a workflow or an AI agent, the evidence is something an inspector can verify without trusting us.
- RequestedAn AI release assistant proposes releasing batch B-1.
- HeldWaits for the Qualified Person’s decision.
- ApprovedAccepted and signed by the QP for that batch.
- RunsOnly that batch is released, once.
Every decision leaves a signed record a reviewer can check.
Why now
Agents are moving from drafting to doing. The rules have not moved.
Accountability stays with people
The model industry and regulators describe is draft and review: the agent proposes, the Qualified Person or quality unit authorizes, and the record shows both. FDA and EMA published shared principles of good AI practice in drug development in January 2026.
The AI rules are still drafts
As of October 2026, EU GMP Annex 22 on artificial intelligence and the revised Annex 11 are still in draft after the 2025 consultation, and FDA’s guidance on AI credibility is still a draft. Controls you put in place now need to hold up whichever way the final text lands.
Where the gap is
Your QMS records the intent. It does not withhold the effect.
A change control, an approval routing, a training record, an audit trail — all of these establish that a process was followed. None of them structurally prevent an action from reaching a validated system when current authority is incomplete, stale, or not bound to the exact change. That distinction is what an inspector is actually probing.
Bind the exact action
Authorization is bound to this batch, this subject, this protocol version, this system change — not to a role or a standing permission.
Fail closed
A missing approval, an expired authority, or a changed material field refuses the action rather than logging it after the fact.
Independent evidence
A hash-linked, signed record an auditor verifies with a source-open offline tool, without trusting AtlaSent’s servers or our word.
See it decide
GMP batch release, from our research testbed.
A QP asks to release a batch. AtlaSent decides; the simulated ERP asks AtlaSent again before it posts the release. In the full run of twelve scenarios, two legitimate releases go through, nine unsafe ones are stopped, and one is caught only afterwards.
Legitimate release
Request. The QP is named and trained, the batch record and results are in order.
Result. Allowed, with a permit for exactly this batch. The release posts once.
Superseded batch record
Request. The QP certified version 1 of the batch record; version 2 was executed.
Result. Refused. The permit is bound to the record’s fingerprint, so a signature on one version cannot release another.
Out of specification
Request. An assay result is still under OOS investigation.
Result. Refused, whoever asks, until the investigation closes.
Same person produced and released
Request. The certifier also approved the batch’s production record.
Result. Refused. Segregation of duties is checked at the decision.
Deviation opened after approval
Request. A deviation is opened after the decision but before the ERP posts the release.
Result. Refused at execution. The check at the point of release catches what changed after approval.
AI agent proposes the release
Request. A release assistant proposes the release; the QP has not accepted it yet.
Result. Held for the QP. Only the QP’s acceptance of exactly that proposal can release it, and the permit names the agent, its model version and the QP.
Prevention needs the system that executes the release to ask AtlaSent first. A pilot starts by confirming that it does.
Clinical trials
Emergency unblinding: immediate for the right person, impossible for anyone else.
Grade 4 adverse event
Request. The treating investigator needs one participant’s treatment arm now. Their identity is verified, with MFA.
Result. Allowed immediately, for that one participant. No approver, no wait.
Whole randomization list
Request. The emergency request is widened to the full randomization list.
Result. Refused. An emergency discloses one participant, never the list.
Not the treating investigator
Request. Someone without an investigator role for that participant requests the code break.
Result. Refused. Only the verified treating investigator can break the blind for their participant.
The same testbed runs a trial across a simulated sponsor, CRO, IRT, EDC, site EHRs and data monitoring committee. Some cases are clinical policy calls, for example whether lapsed emergency-unblinding training should block a real emergency. Those are set per study by the sponsor, not by us.
What an inspector receives
A dossier for every decision, verifiable offline.
For each decision, the inspector gets the action, the batch or participant, the record version and specification in force, the person who decided and their signature, the policy version and who approved it, and, where an AI agent proposed the action, the agent, its model version and who accepted it.
The inspector re-runs the decision from its recorded inputs and checks the hash chain of the log, without access to AtlaSent.
Where it stands
Built: the authorization runtime that decides, issues permits, verifies them and keeps a hash-chained record, running in production on our own release pipelines; clinical unblinding on our staging runtime.
Simulated: the GMP batch-release, data-integrity and process-control prototypes, against simulated ERP, QMS, LIMS and controllers; the clinical vendors.
Next: a first pilot on one action at one site, run in the customer’s validation environment.
GMP research testbed disclosure: Batch-release, data-integrity, and process-control examples currently use synthetic data and simulated execution systems. They are not GxP-validated, approved for regulated production, or proof of a live MES, LIMS, ERP, or OT integration. Actual prevention requires an accepted pre-execution control in the connected native system.
A first pilot
One action, one site, six weeks.
Choose one consequential action: releasing one product at one site, a GxP record change, or emergency unblinding in one study. AtlaSent connects to the system that executes it in a validation environment, the qualification tests run against it, and your quality unit receives the executed protocol and a working control. Nothing changes in production until your QA says so.
We are looking for a first design partner among sponsors, manufacturers and CROs, and for IRT, EDC and ERP vendors who want to show their systems act only on authorized requests.
Built for
Heads of Quality and Qualified Persons, clinical operations leaders, CROs, IRT and EDC vendors, and teams putting AI agents into GxP work.
Tell us where this is wrong
We welcome comments on this page.
If you work in quality, manufacturing or clinical operations and something here is unclear, missing, or would be phrased differently in your organization, we want to hear it. That includes the policy calls above: if you would set them differently, tell us why.
Please do not include patient data, batch records or other regulated or confidential information.
Regulated actions
One authorization lifecycle, applied where consequence is irreversible.
Batch release. Clinical unblinding. Protocol amendment. Validated-system change. Patient-linked data export. Each is routed through the same evaluate → permit → verify → evidence path before it reaches the regulated system, whether the actor is a person, a workflow, or an AI agent.
Acceptance pattern
Prove an authorized action can proceed, an unauthorized action is refused, missing approval is refused, and changed or replayed work is refused. Evidence should show exactly which stage was established.
What we claim, and what we do not
Control properties, mapped to clause language — never conformance.
AtlaSent supplies enforcement and evidence properties that map to specific requirements in 21 CFR Part 11, EU GMP Annex 11, and ICH E6(R3) — for example, that a record is attributable to a verified actor, that it is bound to the exact operation, and that it is tamper-evident and independently verifiable.
We do not claim, and you should not repeat, that AtlaSent is Part 11 compliant, Annex 11 validated, or certified. Compliance is a property of your validated process and your documented qualification of it, not of a vendor’s product. AtlaSent is a control inside that process and an evidence source for it; the mapping is stated so your QA function can qualify it, not so it can be skipped. Framework references are alignment mappings pending our own counsel review — ask us for the current status rather than inferring it from this page.