Why can't healthcare products just use a hosted model API?
Occasionally they can. More often the blocker arrives from a customer rather than a regulator: a hospital, insurer or clinic writes data-handling terms into the contract that a shared model API cannot satisfy, and no amount of vendor documentation changes their answer. The deal stalls at security review with a product that works perfectly.
Once that happens, the question stops being about model quality and becomes an infrastructure question. Running inference on hardware or in a cloud account you control removes the objection rather than arguing with it.
What does a private healthcare AI deployment look like?
The shape is consistent: your application, a controlled backend gateway, a private encrypted path, the model running as a service inside your environment, a schema-validated response, and the result rendered back to a clinician or reviewer. Nothing in that path reaches a public endpoint, and the model service holds no credentials to write to your records.
That architecture is what a recent healthcare engagement used, for a client processing patient medical reports who needed the model to stay entirely inside their own infrastructure. The work is the serving layer, the private connectivity and the validation, rather than the model itself.
How do you stop the model producing a wrong clinical answer?
You do not rely on the model to police itself. A deterministic gate sits between the answer and your application: a fixed list of rules, each returning pass or fail, identical verdict for identical input. Values cited must be traceable to the source document. Required fields must be present. Anything outside an allowed list is rejected.
A failed rule is never quietly corrected. The response comes back marked as rejected with the failing rules named, so the interface shows a needs-review state and a human decides. Output is review-only by default, with no automatic write into a patient record.
What can AI usefully do in a healthcare product today?
Extraction and structuring of clinical documents, summarisation that cites its source line by line, retrieval across a body of internal guidance, coding and billing support with a reviewer in the loop, and intake or triage workflows where the model drafts and a person approves. All of it with a validation layer, and all of it review-only.
What we will tell you not to build is anything that acts autonomously on a patient record. The constraint is not technical caution; it is that review-only output is what gets through your customers' procurement, and an autonomous write is what stops it.
How an engagement runs
| Stage | What happens | Timeline |
|---|---|---|
| Assessment | Your data path, deployment options and validation requirements examined, with acceptance criteria written as testable statements | About one week |
| Private deployment | Model serving inside your environment, private connectivity, validation gate, tenant isolation, observability, infrastructure as code | About three weeks |
| Product build | The clinical-facing application on top, built with the same review-only discipline | Scoped on a call |
Work runs on synthetic data throughout. Accounts stay yours, access is named and limited-privilege, and it is removed at handover with written confirmation.
