
A sepsis alert fires in a rural emergency department at 3 a.m. The nurse on shift has never seen the model's validation data, does not know whether it was trained on patients like the one in front of her, and has no one to call about it. Somewhere in a filing cabinet, a regulatory clearance says the tool is safe and effective. Both things are true at once.
That gap is why comparing the World Health Organization's health ethics guidance with the US Food and Drug Administration's device framework is more useful than treating them as rival documents. They answer different questions. Read together, they cover ground neither covers alone.
Two documents, two jobs
The WHO's guidance on the ethics and governance of artificial intelligence for health is advisory. It is written for ministries of health, hospital leaders, and developers working in systems with uneven infrastructure, and it lays out broad principles: protecting human autonomy, promoting well-being and safety, ensuring transparency and explainability, fixing responsibility and accountability, advancing inclusiveness and equity, and sustaining responsive systems over time. Nothing in it is enforceable. Its power comes from being the reference point that national bodies adapt.
The FDA's framework is a regulatory one. It has no published set of health ethics principles in the WHO sense. Instead it classifies software functions as medical devices, requires evidence of safety and effectiveness for the intended use, governs labeling, and follows products after release. The agency also maintains a public list of authorized devices that use machine learning, and its guidance documents address clinical decision support, predetermined change control plans for updates, and good machine learning practice developed with international partners.
So the shorthand: the WHO describes what a decent health system should require. The FDA describes what a company must prove before selling into the US market. A tool can satisfy one and fail the other badly.
Safety as a system property versus safety as a product claim
For the WHO, safety lives in the whole delivery chain — staffing, training, procurement, connectivity, supervision, and a clinician's practical ability to override or ignore a recommendation. A model that performs well in a validation set but arrives in a clinic with no protocol for acting on its output is not safe, regardless of its accuracy.
The FDA's approach is per-product and per-indication. A sponsor demonstrates performance for a stated use, describes risks, addresses cybersecurity, and commits to post-market monitoring. That is a rigorous bar, and it is narrower than the WHO's.
Clearance answers "does this device work for its stated use?" It does not answer "will this device help or harm this patient, in this clinic, with these staff?"
If you are evaluating a vendor, treat the regulatory clearance as a floor. Then ask the operational questions the WHO framework forces: who trains new staff on it, what happens when the network is down, and what the fallback process is when the tool is silent.
Transparency: explaining versus disclosing
These two documents use the same word for different things, which causes most of the confusion in procurement meetings.
The WHO leans toward explainability and intelligibility — users and patients should be able to understand, in terms meaningful to them, how a conclusion was reached and that a computational tool was involved at all. The default expectation is disclosure, not disclosure-on-request.
The FDA's transparency expectations center largely on labeling and documentation: intended use, performance results against relevant benchmarks, known limitations, and clear instructions. Notably, the agency does not impose a blanket requirement that a model's internal logic be interpretable. Devices whose reasoning is difficult to inspect have been authorized on the strength of validation evidence and clinical context.
In practice, that means a US-cleared tool may still be opaque to the clinician using it. If your organization wants explanation as a condition of purchase, you have to write it into the contract, because the regulatory pathway will not do it for you.
Equity: a mandate versus an evidence question
Equity is where the two diverge most sharply in tone. The WHO treats inclusiveness as a first-order ethical commitment, with explicit attention to under-represented populations, unequal access, and the risk that well-funded systems capture the benefits while others absorb the harms. Bias mitigation and equitable deployment are obligations, not optional features.
In the FDA framework, equity mostly surfaces as a data and evidence question: does the submission show that the device performs adequately across the intended patient population, including relevant subgroups? Sponsors are generally expected to characterize performance across the groups the device will serve, and a body of evidence drawn from a narrow population is a recognized weakness rather than an automatic disqualifier.
The distinction matters for buyers. A device can be authorized while its evidence base is thin for the patients in front of you. Demographic breakdowns of validation data, and plans for local performance monitoring, belong in your evaluation checklist.
Where they agree
Despite the different vocabularies, the overlap is real and worth stating plainly:
- Human oversight is non-negotiable. Neither document endorses unsupervised clinical decisions.
- Accountability must be assigned to a person or institution, not to the tool.
- Governance runs across the lifecycle, from design through deployment, updates, and retirement.
- Documentation matters, both for regulators and for the clinicians and patients affected.
- Post-deployment monitoring is expected, because performance drifts as populations and practices change.
Turning both frameworks into questions you can actually ask
Most teams do not need to master either document. They need a short list that keeps them honest in vendor meetings and internal reviews:
- Who is clinically and legally accountable when this tool is wrong?
- Which patient populations appeared in the validation data, and in what numbers?
- What does the clinician see, and how easily can they override it?
- How are model updates governed, and will we be told before one ships?
- What is the workflow when the tool is unavailable or unreliable?
- How do we tell patients that a tool was used in their care?
- What local data will we collect to check performance after go-live?
A practical way to use both
Match the document to the job. If you are buying, use the WHO principles as a scoring rubric and the FDA authorization as a minimum threshold — never as evidence of fairness or fitness for your specific setting. If you are building, design to the FDA's evidence and change-control expectations, then document to the WHO's transparency and equity expectations, because those are increasingly what health systems ask for in tenders.
If you sit in a hospital or health authority, the most valuable step is dull and specific: write down, before deployment, who monitors performance, who fields clinician concerns, and how a patient learns that a tool informed their care. Neither document will write that page for you. Both assume someone will.
This is general guidance, not legal, regulatory, or clinical advice. Regulatory pathways and device requirements change, and decisions about patient care belong with qualified clinicians and, where relevant, counsel.
Photo: Tima Miroshnichenko / Pexels


