Home / Insights / Three questions that end the conversation

Every vendor says "AI-powered."
Three questions that end the conversation.

How to tell a governed AI operating system from an AI feature stapled onto architecture that was already decided — in under five minutes, in any demo.

Ospia Insights · Governance

Walk into any hospital-software demo in 2026 and you will hear the same two words: "AI-powered." The phrase has stopped meaning anything. But three questions restore the meaning instantly — and the answers sort the market for you.

1. Can you replay a decision the AI made four months ago?

Not "show me a log." Replay it: the exact model and prompt version, the inputs it saw, what it recommended, the alternatives it weighed, and who approved the action. If a payer disputes a claim, or a clinician questions a flag, you need to reconstruct exactly what happened, long after it happened. Systems that added AI as a feature keep, at best, a basic log. A governed operating system keeps a decision ledger — because replayability was a design requirement, not an afterthought.

2. Can you set how far automation goes — per task — and prove who changed it?

Autonomy should not be a global switch, and it should never be a vendor default. For one specific task — say, submitting a claim, or dispensing against a protocol — you should be able to set the level: suggest only, act with confirmation, act within a policy you approved, act autonomously. And you should be able to show the audit record of who changed that setting and when. If autonomy is hard-coded or buried, the AI is being governed by the vendor, not by you.

Where software takes action, governance is the product. An agent should be handed a permission-scoped subset of the same task registry your staff use — nothing more.

3. Can you switch AI provider without a project?

Models change monthly. Costs shift, capabilities leapfrog, and some task classes need to run on a private model for data-sensitivity reasons. If switching provider — or routing sensitive tasks to a different model — is a re-integration project, you are locked to a decision made once, by someone else. In a well-architected system no provider is named anywhere outside a model router, so switching is configuration, not a programme.

The tell: what can the AI never do?

Ask it plainly. The right answer is specific: the AI can never act outside the task registry, or above the autonomy level you configured. Agents invoke the same permission-checked tasks your staff do, under the same authorization, producing the same audited events. There is no back door, because there is no second door. And when the model is unavailable, the hospital keeps running on deterministic fallbacks — AI adds speed and foresight, but is never a dependency.

Most systems answer these three questions no, no and no — because the AI was added to an architecture that had already been decided.

These are not gotcha questions. They are the questions a hospital making a fifteen-year decision should be able to ask of anyone — including us. Bring them to our demonstration. Forty-five minutes, on your numbers, with the architecture open: hello@ospia.in.

Primary sources

This resource is grounded in the following official standards, laws and regulator guidance. Links were checked on 22 August 2026.

Questions buyers ask

Straight answers

How do I tell governed AI from a bolt-on feature?

Ask whether you can replay a past decision in full, set autonomy per task with an audit trail, and switch AI provider without a project. Governed systems answer yes to all three; bolt-ons usually cannot.

What happens when the AI model is down?

The hospital keeps running. AI should add speed and foresight but never be a dependency — deterministic fallbacks cover the assistive paths, so operations continue even with no external AI configured.

Can we limit what the AI is allowed to do?

Yes. Agents should invoke only the same permission-checked tasks your staff use, never above the autonomy level you set. Higher-autonomy actions require a named human or an approved policy, and every run is replayable from the decision ledger.

Related reading

Keep going

Category

You don't need a new HMS. You need to stop buying HMS.

The three taxes baked into how hospitals buy software.

Read the article →
Compliance

Compliant by design: ABDM, DPDP, NMC and GST at write-time.

Why compliance belongs in the data model, not a document.

Read the article →

Next step

Bring the three questions to a demonstration

Forty-five minutes, on your numbers, with the architecture open. Synthetic data, zero real patients.

Book your hospital simulation More insights

synthetic data · zero real patients
self-hosted or managed cloud
one database per hospital