Most writing about health AI is addressed to the people building it. This one is addressed to the people building it, but written from the other side of the table — the side that has to sign, deploy, and answer for the result.
I have sat on that side. National Director of Epidemiology for a ministry of health. National focal point to PAHO for surveillance and the International Health Regulations. Today, director of a federal health coordinating center in Mexico. I have been the person a vendor was presenting to, and the person who had to live with what was bought.
Here is what that side is actually thinking while your demo is running.
We are not evaluating your model. We are evaluating our exposure.
A vendor walks in with accuracy figures. The room is polite. But the questions being formed are not about AUC.
They are: If this is wrong, who is accountable? What happens to the people using it when it fails? Can we stop using it without the program collapsing? And when the person who championed this leaves, who maintains it?
A model is a technical artifact. A deployment is an institutional commitment, usually longer than the political cycle that approved it. Those are different risks, and the second one is the one that keeps a director awake.
Vendors who only answer the first never understand why the deal stalls.
Four things that decide it, none of which are the model
1. Whether it survives our data, not yours.
Ministry data is not a clean extract. It is a register filled in at the end of a twelve-hour shift, by someone who was also attending patients. It has duplicates, misspelled names, dates that are impossible, fields left blank because the form did not fit the case. Categories change when a guideline changes, so the same variable means different things before and after a certain year.
A system that assumes clean input is not a system we can deploy. It is a system we would have to build a data-cleaning program around first — and that program is the real cost, which nobody put in the quote.
Show me what your tool does with a messy real record and you will have told me more than any benchmark.
2. Whether we can operate it without you.
Health institutions have turnover, budget cycles that end, and procurement rules that make emergency contracts hard. A system that only you can maintain is a dependency we are being asked to accept indefinitely.
The question is not whether you offer support. It is whether the handover is real: documented decisions, readable code, a runbook someone new can follow, and a way for our own team to change a parameter without opening a ticket.
I build this way because I have been on the receiving end of the alternative.
3. Whether it fits a workflow that already has no slack.
A twelve-minute consultation does not have four extra clicks in it. A nurse doing the weekly report does not have twenty minutes to reconcile two systems that disagree.
If the tool adds time, it must remove more time somewhere visible, and the person who pays the cost must be the person who gets the benefit. When the cost lands on the clinic and the benefit lands on the central office, adoption dies quietly and nobody reports it — the numbers just stop being entered.
4. Whether anyone is watching it after launch.
Populations shift. Protocols change. A new assay arrives with a different range. A coding guideline is updated and the same event starts being recorded differently.
Drugs have pharmacovigilance. Devices have post-market surveillance. Most deployed health models have nothing: no scheduled recalibration, no monitored metric, no named owner. They degrade silently, and the only trace is a slow drift nobody attributes to the software.
If your proposal has no monitoring plan with a metric, a cadence and a name attached, you are proposing something we cannot responsibly accept.
What a good proposal looks like from here
Short version: it is honest about scope and explicit about the boundary.
- It states what the tool does not do, in writing, before we ask.
- It names the population it was validated on, and how that differs from ours.
- It prices the data work separately instead of hiding it.
- It defines what “working” means with a number we can check ourselves.
- It says who we call, and what happens when that contract ends.
None of this is a technical bar. It is a professional one, and it is low. The reason it filters so effectively is that most proposals do not clear it.
The other direction
This cuts both ways, and I say it to colleagues in the public sector as often as to vendors.
If we cannot state what decision the tool is supposed to improve, we are not ready to buy. “We want to use AI” is not a requirement; it is a budget line looking for a justification. The vendor is not the only one who has to be rigorous.
The best deployments I have seen started with a narrow, boring, clearly owned decision — one that a specific person makes repeatedly, on a known cadence, with a known cost of being wrong. Everything good followed from that clarity.
I work on both sides of this: helping health organizations decide what is worth building, and helping teams build it so it survives contact with a real institution. That is the conversation I want to have.