In healthcare, the relationship between what is approved and what is used differs from most sectors. There is already a dense system of review: medical device regulations, quality frameworks, medical-ethical review committees, data protection officers. That system is built around physical devices, medications, and treatment protocols. AI applications often slip through the gaps, because they were not procured as a tool but are used as one. A language model that reads along in a patient record, a transcription tool during a consultation, an algorithm that supports triage: none of these applications need to have gone through the existing review route to still be used daily.
On top of that, the interests at stake in healthcare weigh more heavily than in many other sectors. It is not only about business operations, but about patient safety, medical-ethical responsibility, and patients' trust that what happens with their data proceeds under control. That makes the question "what is actually running here" more pressing than elsewhere, and at the same time harder to answer, because healthcare professionals work under time pressure and a tool that helps is not quickly reported if reporting it feels like a detour.
The IT department of a healthcare institution has a list of approved systems. That list is a starting point, not reality. A physician who uses a language model to draft a discharge letter, a nurse who consults an app for medication interactions, a secretariat that deploys speech recognition outside the official records system: this kind of use arises because it delivers results, not because it was requested. No one intended to conceal this. It was simply never asked about, and whoever does ask about it must be able to do so without a sanction looming. Only then does an honest answer emerge, and only with an honest answer can an institution know where the risks truly lie.
After the inventory comes classification: what role does an AI application fulfill, and what risk level belongs to it. In healthcare, that distinction is sharp. A tool that summarizes notes for a care provider's own use carries a different weight than a system that factors into a diagnosis or a decision about treatment capacity. The classification itself is determined by regulation that falls outside the scope of this page and that is continuously evolving; the current classification and the obligations that go with it are addressed elsewhere. What matters here is the mechanism: every application is given a place in a classification by function and impact, so that it becomes clear which applications require attention and which do not.
Healthcare institutions do not build from scratch. Review committees, quality systems, data protection officers, and internal audit routes already exist. A governance approach for AI that stands apart from that becomes an extra layer that no one maintains. An approach that connects to the existing structure becomes part of what already happens: the same committee that assesses a new medical device also assesses a new AI application; the same risk register gets a category for AI alongside the categories already there. That does not call for a new apparatus, but for a framework that fits what the institution already does.
A board of directors, a supervisory body, or an inspectorate wants to be able to see what is going on, not assume it is under control. Demonstrability means that an up-to-date overview exists of which AI applications are in use, who uses them, what risk level applies to each, and what agreements have been made around them. That overview is not a one-time document. Healthcare institutions constantly change systems, and staff carry tools from one department to another. A governance set that keeps track of this is usable at the moment accountability is demanded, not only at the moment it was drawn up.
The combination of strict existing review and rapidly growing informal use is not unique to healthcare, though it carries a sharper edge here because of the patient standing at the end of the chain. Institutions wanting to see how comparable issues are organized in another context can look at how AI governance in education handles a similar tension between duty of care and practical use, at the way AI governance in professional services safeguards confidentiality and client interests, or at how AI governance in manufacturing handles systems that directly intervene in a physical process.
Once it is clear which AI applications are running and under which risk level they fall, another question remains: what that use means for the work itself. A governance inventory shows what is running, not how much time that frees up or which part of a task can actually be taken over. That question falls outside governance and within the work scan from FTE TO AI, which calculates per task which part of the work can be taken over by AI. For a healthcare institution that first wants an overview of what is being used, and then wants to know what that use means for the deployment of staff, that second question follows logically from the first.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.