BroadOakData · Agentic AI
Getting instrument data into a regulated life-sciences platform is rarely a technology problem. It is a cost, risk and accountability problem. Every new instrument, file format or software version means someone has to work out what each column means, map it to the platform’s data model, check the units, prove it was done correctly, and keep the evidence for an auditor.
This article describes a design for automating that work with AI agents without handing the AI any authority it should not have. It is written for the people who pay for this work and answer for it: technology leaders, quality owners and data governance teams.
A note on status. The design below was built and tested as a proof of concept, on synthetic data, against a mock target platform. Nothing here has run against a live production system, so the cost points are design levers with a measurement plan, not realised savings. I say which is which throughout.
Where the cost really sits
In a typical integration programme the expensive parts are not the servers. They are:
- Skilled time per instrument. Each new data source needs analyst effort to interpret and map it, and the effort repeats for the next instrument that looks almost the same.
- Rework. Batches that fail validation late go back to the start, along with the reviewer time already spent on them.
- Review effort spent in the wrong place. Reviewers re-check fields that are obvious while the genuinely ambiguous ones get the same few minutes.
- Audit preparation. Reconstructing who decided what, with which version of which tool, is slow when the evidence is scattered.
- Uncontrolled AI spend. If a model reads every file, reasons over every row and retries on every error, token costs scale with data volume instead of with the genuine need for judgement.
The core design choice: the AI proposes, code decides, people approve
The system splits the work into three kinds of step, and only one of them uses a language model.
- Deterministic steps (reading files, normalising formats, running checks, executing a mapping). No model, no token cost, and the same input always gives the same output.
- A constrained proposal step. This is the only place a model can be used, and only to suggest what a column means and how it might map. A strict validator accepts a proposal only if every operation, field, unit conversion and vocabulary term is in a closed, pre-approved set. Anything the model invents is dropped and recorded.
- Human decisions. Resolving uncertain fields, signing off the full mapping, approving the batch and releasing it to the platform are reserved for named people. No agent or tool can perform them.
This split is what makes the cost, security and governance stories hang together. Each is a consequence of the same boundary.
Cost reduction levers
1. Pay for judgement only where judgement is needed. Three of the agents’ work is deterministic. The model is confined to interpretation and proposal, and the system runs in an offline, rules-and-knowledge mode by default. Token spend is therefore tied to the number of unfamiliar layouts, not to the number of batches or rows.
2. Generate once, run many times. Once a mapping is signed off, the system produces a transformation package from a fixed template. No model writes any file, and the package runs without a model. After that, each new batch from the same instrument is a deterministic run with near-zero marginal compute cost. The package is also run once standing alone before it is accepted, so defects are found before they reach production data.
3. Reuse what people have already approved. Approved mappings and the corrections reviewers made enter a mapping memory, and similar sources are matched against it. The more the system is used, the more of each new instrument is already familiar, which shrinks reviewer effort per source. The memory learns only from human approvals, so it cannot be steered into learning wrong mappings.
4. Send people to the uncertain fields. Every field gets a confidence score computed from evidence the application measures itself, not from the model’s own claim. The model’s suggestions are capped, so it can never get a field accepted alone. Reviewers spend their time on what is genuinely uncertain, while the full mapping still receives sign-off.
5. Fail safe instead of guessing. An unfamiliar layout produces fields marked as unmapped, with hints, never a plausible-looking guess. Wrong data caught at the door costs minutes. Wrong data caught after release costs investigations, corrections and credibility.
6. Make scope configuration, not code. Which instrument types and file formats are in scope is configuration, backed by schema definitions. Adding another instrument type is a documented, repeatable task rather than a new development project.
Business impact: what to measure
I would not claim a percentage saving from a proof of concept on synthetic data. What the design gives you is a clear set of measures to capture in a real pilot:
| Measure | Why it matters |
|---|---|
| Analyst hours to onboard a new instrument | The main driver of integration cost |
| Share of fields accepted at confidence threshold, and share changed by reviewers | Shows whether scoring is trustworthy and where review time goes |
| Batch rework rate (failed validation or rejected at review) | Direct measure of waste |
| Reviewer minutes per batch | The recurring human cost |
| Model cost per onboarded source, and per batch | Confirms spend tracks novelty, not volume |
| Time to retrieve full evidence for an audit question | Audit readiness as a cost |
Compare each against the current manual baseline before the pilot starts. Without a baseline, any later saving is an assertion.
Security by construction
The security controls sit outside the model’s reasoning, so they hold even if the model behaves badly.
- A closed tool list. The assistant can use only the small set of operations it was given, and nothing else.
- Default-deny authorisation on every call. Each tool call is checked against policy, and each agent has its own allow-list. A refused call is recorded.
- Masking before the model. Personal and health-related data is masked before any model sees it, and the data mode and model mode are linked: real data with a model requires masking to be enabled.
- Customer scoping and walls. A person works only on customers they have been granted, and conflicts of interest can be walled off explicitly.
- Per-customer AI policy. Whether a language model may process a customer’s data, whether the system may learn from their approvals, and how long learned mappings are kept are set per customer.
- Original data is kept and verified. Source files are stored with a hash and every stage re-checks them. Staged records are immutable.
- Constrained model output. Because proposals are validated against a closed set of operations, a manipulated or mistaken model cannot make the system perform an action outside that set.
Governance people can audit
Governance is where a design like this earns trust with quality and compliance teams.
- Human-only decisions. Approving a connector, resolving a flagged field, signing off a mapping, approving or rejecting a batch, and releasing to the platform cannot be reached by any agent, tool or model.
- Dual sign-off. Even a fully confident mapping needs more than one distinct person’s sign-off, bound to the exact mapping. If the mapping changes, the sign-offs no longer apply.
- Segregation of duties. The person who proposes or authors cannot also be the one who approves, and approving and releasing are separate acts by default.
- A tamper-evident audit trail. Every call is hash-chained and records the model identity and version, references to inputs and outputs, the knowledge-base version, the mapping version, and the reviewer’s identity. Stored artefacts are cross-checked against it.
- Changes go back through the gates. A validation failure or a request for changes returns the batch to the mapping stages, and a new mapping needs new sign-off, a fresh transformation and a fresh validation.
What is not yet proven
A candid list matters more here than a polished one:
- No live language-model run of the interpretation or proposal steps has been done.
- The target definitions are stand-ins, and there has been no connection to a real production platform.
- Confidence scoring uses uncalibrated heuristics and needs calibration against real reviewer decisions.
- Formal electronic signatures, validation documentation and change control remain organisational work, as does regulatory compliance more broadly.
- The accuracy figures the proof of concept reports are regression checks, not evidence.
Takeaways
- Put the model where judgement is scarce and everything else in code. That single decision controls cost, risk and audit effort together.
- Treat approval as a human act the AI cannot reach. Governance that depends on the model behaving is not governance.
- Measure before you claim. Set the manual baseline first, then run a pilot on real data and report what actually changed.
- Design for the audit on day one. If you can reconstruct every decision cheaply, the audit stops being a project.