Five principles, each with a control behind it
A principle that is not enforced by the platform is a preference. Each of these maps to something a customer can inspect.
| Principle | The control that enforces it |
|---|---|
| A qualified human is accountable for care decisions | Review steps are configured centrally per agent category and cannot be removed from the build interface. |
| An agent reaches only what its function requires | Per-agent data and tool scoping, set independently of the builder's own permissions. |
| The model is a reviewable choice | Model selection is configuration with a recorded change history and a re-run of the evaluation set before promotion. |
| Everything is reconstructable after the fact | Immutable logs of prompts, retrievals, tool calls, model calls and outputs, exportable per user and date range. |
| Nothing reaches production unreviewed | Change control with separation of duties between building an agent and approving its release. |
Where human judgement is required
We draw this line publicly because health systems have been sold autonomy that did not exist, and because a vague line is unenforceable.
- Clinical decisions. Diagnosis, treatment selection, dosing and changes to a care plan are human decisions. Agents may retrieve, summarise, draft and flag.
- External submission. An agent may draft a payer appeal; a person submits it.
- The patient record. Agents read under scoped access; they do not write to the EHR.
- Closing exceptions. An agent may raise a flag; dismissing it is a human act with an identity attached.
Where the boundary reasonably sits across workflow types: agentic AI for the healthcare sector.
Model selection and review
Because the platform is model-agnostic, which model answers is a governed decision rather than an architectural fact — and a governed decision has to be recorded.
- Candidate assessment. A new model is assessed against the same evaluation set used for the agents that might adopt it.
- Scoped introduction. It becomes available to selected agent categories, not to the whole estate at once.
- Recorded change. Changing the model behind a production agent is a change-controlled action with an owner, a reason and a timestamp.
- Rollback. The prior configuration remains available, so reverting is an action rather than a project.
- Sensitivity routing. Workloads a health system designates as internal-only run on internal or self-hosted models, enforced by policy configuration.
Agent permissions
The most common governance failure we see in health systems is agents inheriting their builder's access. A senior analyst with broad entitlements builds an agent, and the agent quietly acquires the same reach for every user who invokes it.
- Agent scope is defined centrally, by an engineering owner, and is not editable from the build interface.
- Retrieval is filtered at query time by the entitlements of the person asking, not the person who built the agent.
- Each tool's reach is fixed when the tool is created, so selecting it in an agent cannot widen it.
- An agent cannot expand its own scope during a task, however it plans.
- The whole estate — every agent, its owner, its data reach, its model — is visible in one view.
What we will not build
Stating this is commercially useful. It is also the fastest way for a prospective customer to work out whether we are describing a real system.
- Agents that issue diagnoses or treatment recommendations without a qualified human in the loop.
- Agents that write to the patient record.
- Deployments where PHI leaves the compliance boundary to a provider not covered by a business associate agreement.
- Configurations that let an agent builder widen the agent's data reach beyond what an engineering owner has scoped.
- Claims of clinical outcome improvements we have not independently evidenced.
The adoption figures we publish — active users, queries processed, agents live — are platform-wide usage totals as of May 2026, measured from the June 2025 production launch. They evidence adoption, not clinical effect, and we describe them that way deliberately.
Frequently asked questions
How does Inference Analytics govern AI?
Through controls built into the platform rather than policy alone: centrally configured human review steps that an agent builder cannot remove, per-agent data and tool scoping set independently of the builder's permissions, model selection as change-controlled configuration with recorded history and rollback, immutable audit logs across all agents, and separation of duties between building an agent and approving its release to production.
Do your AI agents make clinical decisions?
No. Agents retrieve, summarise, draft, check and flag. Diagnosis, treatment selection, dosing and changes to a care plan remain human decisions, and outputs that inform care are reviewed by a qualified person whose identity is recorded in the audit log.
Can an AI agent access more data than the person using it?
Not on our platform. Retrieval is filtered at query time by the entitlements of the person asking, and an agent's overall scope is set centrally by an engineering owner rather than inherited from whoever configured it. An agent also cannot widen its own scope during a task.
How do you decide which AI model to use?
A candidate model is assessed against the same evaluation set as the agents that might adopt it, introduced to selected agent categories rather than the whole estate, and adopted through a change-controlled action with a named owner and a recorded reason. The prior configuration stays available so rollback is an action rather than a project.
What will Inference Analytics not build?
Agents that diagnose or recommend treatment without a human in the loop; agents that write to the patient record; deployments where PHI reaches a provider not covered by a business associate agreement; configurations that let a builder widen an agent's data reach past what an engineering owner scoped; and claims of clinical outcome improvement we have not independently evidenced.