Most AI assistants are built to sound right. In healthcare-adjacent work, sounding right isn't the job — being right, and being able to show why, is. That gap is where a lot of well-meaning AI projects quietly become a liability.
Singapore's AI in Healthcare Guidelines (AIHGle 2.0) set the expectation plainly: accountability, transparency, and human oversight. You can't bolt those on at the end. They have to be in the architecture from the first line. Here's how I build for that — without turning the thing into a glorified FAQ that can't actually help anyone.
"Mostly right" is the problem, not the goal
A general language model answers from a blend of everything it has ever read. That's fine for drafting an email. It's the wrong foundation when someone is asking what a procedure costs, or whether a service is appropriate for them, and a confident wrong answer carries real consequences.
So the first design decision is to stop the model from answering from memory at all.
Ground every answer in the client's own verified data
The assistant doesn't "know" anything about the business. On each question, it retrieves the relevant facts from a controlled source the client owns and maintains — the live catalogue, the current pricing, the approved policies — and answers from that, and only that. If the fact isn't in the source, the assistant doesn't have it, and says so.
This single choice does most of the heavy lifting for compliance. Answers become traceable to a specific, current, client-approved record instead of to a model's best guess. When the business updates its data, the answers update with it. Nothing is frozen into a prompt or invented on the fly.
Constrain the scope, and make the edges defer
A trustworthy agent knows what it is not for. I define its boundaries explicitly: the topics it handles, and everything else it declines and hands to a human. An assistant that helps a patient find the right health screening should not be improvising medical advice — it should recognise that question and route it to someone qualified.
Refusing well is a feature. "I can't answer that, but here's who can" is a compliant answer. A plausible-sounding overreach is not.
Keep a human in the loop where it counts
Automation should absorb the volume — the same fifty questions a day that staff used to answer by hand — and escalate the rest. Uncertainty, edge cases, anything that touches judgment: these go to a person, with the full context attached so the handoff is seamless. The goal is to augment the team, not to replace the judgment they're there to provide.
Log everything, so accountability is real and not a slogan
Every interaction leaves a trail: what was asked, what facts were retrieved, what was answered, and where it was escalated. That record is what makes "accountability" more than a word. It lets the business review what the assistant is saying in its name, catch drift early, and correct it. (That deserves its own piece — it's coming.)
Review, sample, correct
No system ships finished. I sample real conversations, look for where answers are weak or boundaries are fuzzy, and feed the corrections back in. Compliance isn't a launch-day checkbox; it's a habit the system is built to support.
Aligned, not certified
A careful word on language: I build aligned to frameworks like AIHGle 2.0. That means the architecture reflects their intent — grounded answers, clear scope, human oversight, full auditability. It does not mean a certification, and I won't claim one. The precision is the point. In this kind of work, overstating your compliance is its own red flag.
If you're an IT firm or consultancy whose client wants AI that holds up under scrutiny — not just a demo that impresses in the meeting — this is the bar I build to. That's usually the harder half of the job, and it's the half worth getting right.