Agentic workflows
that a validation lead can sign.
Agents in a clinical programming operation are only useful if a QA reviewer can say what they are allowed to do, where they run, what they logged and who approved each action. INNOVIZZ builds that first: a model gateway under your identity system, orchestration wired to your platforms, prompt and output logging into your audit trail, and an evaluation harness that gates anything from reaching production. The agent capabilities come after, one at a time, on one or two studies, with every recommendation reviewed by a person and every compliance check decided by deterministic rules.
Everyone has a pilot; nobody has a sign-off
Three patterns from the last two years of agent pilots in sponsor and CRO programming groups.
A public coding assistant, a personal subscription, a prompt with a de-identified log pasted in. Useful, unlogged, and outside every SOP. The question is no longer whether agents touch clinical programming; it is whether the organization can see it.
An agent drafted queries or flagged anomalies well in a sandbox. Then validation asked where the model ran, what it saw, what it wrote and who approved it, and the pilot had no answers. It stayed a pilot.
Named agents with marketing personalities arrived with no evidence that they existed in production anywhere. A biometrics lead does not buy a name. They buy a described capability with a validation approach and a person who signs.
Four capabilities, described by function, bounded by rules
No agent on this page has a name, because a name is not a specification. Each capability is built against your schemas, deployed in your VPC or on premise, and limited to proposing. Deterministic rules over structured data decide compliance and readiness; a person decides everything else.
Watches EDC and source streams against rules your data management lead owns, ranks anomalies, and drafts queries for a reviewer. It never raises a query to a site on its own.
Validates source and SDTM against the specification and the pinned controlled terminology continuously, with Pinnacle 21 pre-checks in the loop. The check is deterministic; the agent explains and routes the finding.
One view over TLF QC status, SDTM and ADaM conformance and narrative completeness, with guidance changes surfaced for a person to assess. Status is computed from records, not estimated by a model.
A queryable protocol layer for study teams: eligibility confirmations, visit windows, deviation risk, with every answer cited to the protocol section and logged. Advisory only; it does not decide eligibility.
Governed LLM and agent infrastructure in your tenancy
The security review asks where the model runs before it asks what the model does. So the architecture is the first deliverable, built once inside your Azure or AWS tenancy and reused by every agent and automation that follows.
Every call to a model goes through a gateway you own: your identity provider, your allowlist of model endpoints, your rate limits and your logging. No programmer calls a public endpoint directly.
Agents reach SAS, R, the EDC and the metadata repository through connectors with scoped, read-mostly permissions. Write actions are gated behind a named approval and recorded per action.
Every prompt, retrieved document, model output and reviewer decision is written to a log you keep, in a form your QA function can inspect. The evidence packet exists before the inspection.
Known-answer test sets per capability, run before release and on every change. An agent capability that fails its evaluation does not reach production, and the run record shows why.
Potentially unblinding data never reaches an outside model. Where a model runs inside your tenancy, it runs on infrastructure your security policy allows. The data flow diagram is shared under NDA before kickoff.
A reference architecture, configuration, patterns and a runbook, so your platform team runs it after we leave. We do not host the gateway and we do not hold the keys.
The governed agent shelf
For programming teams the most useful agents live inside the editor people already use. The shelf is a versioned set of agent skills in your source control: job launch and scheduling on the platform, run triage with a log-proven output inventory, log diagnosis with an evidence pack per verdict, study and reporting-event provisioning, and controlled backups. Write actions are gated by named approval; generated programs land in a controlled folder; capability changes travel through a governed request loop, never a local edit. It ships as part of Coding Operations.
Every version carries its change record. Your platform owner approves each capability before rollout and the approval is recorded per action.
The shelf follows your change and backup procedures. Training and a user guide come with the first release; the skills stay in your source control.
The shelf launches, triages, diagnoses and provisions. It does not write a derivation into a production program on its own and it does not approve its own output.
Infrastructure, then one capability, then the next
Ninety to one hundred and twenty days from kickoff to a first capability in production is typical when the tenancy and the security review are ready. The sequence is fixed; the pace is set by your review calendar.
The reference architecture is designed against your security policy and model allowlist, then reviewed by your security and IT leads before anything is built. The data flow diagram is part of the review.
Gateway, orchestration, logging and the evaluation harness deployed in your tenancy, tested, documented, handed to your platform team with a runbook.
One capability, scoped to named studies and named reviewers, built against your schemas, evaluated on known answers, released only after your reviewers accept it. Nothing it proposes reaches a site, a dataset or a deliverable without a person.
Further capabilities added the same way, each with its own evaluation set and acceptance. The infrastructure is reused; the governance does not loosen as the count grows.
Agents run under the same four rules as everything else
The rules are what make the word agent acceptable in a validated environment.
Rules settle every case they can. A model is consulted only for the residual the rules cannot decide, and its output passes through the same rules before anyone sees it.
Processing runs in your environment, under your identity system. Nothing potentially unblinding reaches an outside model. The data flow diagram is available under NDA before kickoff.
Every output that matters is accepted by a person on your side whose name is on the record. Model output never writes a finding into a deliverable on its own.
Inputs, versions, tool events and decisions are logged as they happen, so the packet an auditor asks for exists before the audit does.
What you provide, what you receive, who signs
Your cloud tenancy, identity system, security policy and model allowlist; the schemas and SOPs for the first capability; the names of the reviewers who will accept it; one or two studies to start on.
A reference architecture deployed in your tenancy, gateway and logging configuration, orchestration patterns, the evaluation harness, a runbook, and each agent capability with its validation evidence and acceptance record.
Your security and IT leads accept the architecture; no model endpoint goes live outside your allowlist. Your biometrics or data management lead accepts each capability; every recommendation it makes is reviewed by a person.
Before you decide
The questions that come up in the first technical conversation, answered the way we answer them on a call.
Why do the agents not have names?
Because a name is not a specification and a buyer in a regulated function cannot validate a personality. Each capability is described by what it may do, what it may not, what it logs and who approves. If a product name helps a procurement form, it goes in the statement of work, not on the page.
Which models do you use?
The ones your allowlist permits, through a gateway in your tenancy. Azure OpenAI and AWS Bedrock are the common cases; private models inside your VPC where policy requires. The architecture does not depend on one vendor and the evaluation harness is how a model change is approved.
Can an agent change a dataset or a program?
Not on its own. Write actions are gated behind a named approval and recorded per action. Generated code lands in a controlled folder for review. The agent proposes; a person disposes; the log shows both.
How is this validated?
Infrastructure is qualified as infrastructure, under your framework. Each capability carries a specification, known-answer evaluation sets, test evidence and an acceptance record. Risk is assessed under GAMP 5 and the Part 11 controls are in the design: audit trail, access control, record integrity. The validation documents are listed as they exist, not before.
How long before something is in production?
Ninety to one hundred and twenty days to a first capability is typical when the tenancy and the security review are ready. The infrastructure takes most of that; the second capability is faster because it reuses it.
How is it priced?
Against a written statement of work with deliverables, milestones and acceptance criteria. Infrastructure and each capability are scoped separately. No figure before the scope is understood.
Where this sits
The governed agent shelf ships inside the Coding Operations packages, alongside SAS to R parity validation and lineage.
SEE CODING OPERATIONSWhat the AI does, what it does not, who signs off: the four rules every engagement runs under.
READ THE APPROACHA complete synthetic run with its evidence packet: what governed automation looks like when it is finished.
OPEN THE EVIDENCE ROOMStart with the architecture review.
Tell us the tenancy, the security constraints and the capability you would build first. We reply with a scoped proposal for the review and the infrastructure.
Or start with the Validated Automation Review: two to four weeks, one workflow corridor, fixed scope. The plan is yours whether or not we build it.