Expert article in mt|medizintechnik 2.2026: how hospitals can safeguard their use of AI systems with risk management
October 19, 2026
Published in mt|medizintechnik, Issue 2.2026
Published in mt|medizintechnik, issue 2.2026
In issue 2.2026 of the trade journal mt|medizintechnik, Valeri Milke explains how hospitals can use risk management to safeguard their use of AI systems. His German-language article “Risikomanagement für KI-Systeme im Medizinbetrieb” (risk management for AI systems in clinical operations), with the strapline “Therapieentscheidungen durch Algorithmen” (treatment decisions by algorithms), appears on pages 8 to 12 of the issue published in April 2026 with a focus on personalised medicine, and includes three figures and one table. The journal is published by TÜV Media GmbH in Cologne. Author: Valeri Milke, CEO of VamiSec GmbH, Lead Auditor for ISO/IEC 27001 and ISO/IEC 42001. The article links the requirements of the Medical Device Regulation (MDR), the AI Act and the Cyber Resilience Act (CRA) to a practical approach for everyday hospital operations — from the threat model and the assessment of possible consequences through to safeguards and documented evidence. This news item restates the key points in our own words and places them in the regulatory context as of October 2026.
The core argument: deploying AI means sharing responsibility
AI applications have arrived in many hospitals: they flag anomalies in X-ray and CT images, suggest treatment options or support the planning of appointments, beds and medication. The more such systems shape decisions, the more patient care depends on their outputs being reliable. A model trained on unbalanced data, a new model version rolled out without anyone noticing, or a gradual decline in performance during operation can put patients directly at risk — and at the same time erode trust in AI-supported medicine. The article therefore puts the spotlight on a perspective that is often neglected in the debate: that of the organisations deploying these systems. Not only manufacturers but also hospitals, laboratories and medical practices have to manage AI risks actively — as an ongoing task across the entire life cycle in which technology, organisation and ethics are considered together.
When medical AI counts as a high-risk system
Medical AI usually becomes a high-risk system through medical device law: if the AI system is itself a medical device, or a safety component of one, and a notified body has to assess its conformity, the AI Act also classifies it as high-risk. Under the MDR, software that provides information used for diagnostic or therapeutic decisions is generally assigned at least to class IIa and therefore requires a notified body — which covers most clinical AI applications. The notified body reviews the AI Act requirements as part of the existing MDR procedure; no second certification is created. In addition, the AI Act directly designates certain healthcare use cases as high-risk, such as systems for triaging patients in emergency departments. The guidance MDCG 2025-6 of June 2025 explains this interplay in 36 questions; the 2027 deadline it mentions has since been postponed to 2028 by the EU legislator.
Shared responsibility: what providers and deployers each contribute
Legally, the roles are separate; in practice, they depend on each other. The provider operates a risk management system, ensures sound data governance and demonstrates conformity. The deployer — in a hospital, that is the institution, not the individual physician — uses the system in accordance with the instructions for use, assigns human oversight only to trained and authorised staff, makes sure that any input data it supplies itself are suitable and representative, monitors operation and reports anomalies to the provider. As a rule, it keeps the automatically generated logs under its control for at least six months. The AI Act does not require deployers to run a formal risk management system; a risk management process of their own, for example based on IEC 80001-1, is nevertheless the practical foundation for meeting these obligations. Important: anyone who markets a system under their own name, substantially modifies it or repurposes it for a high-risk use takes on the obligations of a provider.
Identifying threats: STRIDE, OWASP and model drift
To identify risks, the article recommends threat modeling along data flows and interfaces. The STRIDE model, which originated at Microsoft, sorts threats into six categories: Spoofing (faked identities), Tampering (manipulation), Repudiation (deniable actions), Information Disclosure, Denial of Service and Elevation of Privilege. Clinical examples: a spoofed imaging device feeds in images from elsewhere, an altered model file shifts diagnostic thresholds, and an over-privileged integration account opens up access to the configuration. For applications built on large language models, the OWASP Top 10 for LLM Applications 2026 lists further attacks, such as prompt injection — instructions smuggled into the input — or data and model poisoning. Then there is model drift: a gradual loss of performance because patient populations, devices or clinical practice have changed compared with the conditions under which the system was validated.
Assessing consequences, implementing safeguards, keeping evidence
Identification is followed by assessment: what would a malfunction mean for patients, for staff and for the delivery of care? The article sets likelihood against severity in a matrix, with severity covering medical, data protection and societal consequences. It groups the safeguards into four fields of action — prevent, detect, correct and document — for example representative test data, monitoring with alerts, human review at critical points and the option to roll back to the previous version. Suitable frameworks are ISO 14971 for product risk, ISO/IEC 23894 as AI-specific guidance and ISO/IEC 42001 as a voluntary management system that structures legal obligations but does not replace them. The AI Act requires a fundamental rights impact assessment only for certain use cases, such as emergency triage, and only from public bodies or providers of public services; for AI-enabled medical devices, the data protection impact assessment and clinical risk management carry the assessment.
Why the topic is pressing now — and what you can do
The AI Act entered into force on 1 August 2024; the prohibitions and the obligation to promote AI literacy have applied since 2 February 2025, and the transparency obligations since 2 August 2026. The Digital Omnibus on AI, in force since 27 July 2026, sets the high-risk deadlines: 2 December 2027 for directly listed use cases and 2 August 2028 for AI-enabled medical devices — for providers and deployers alike. Systems placed on the market or put into service before then are only covered after significant design changes. The Cyber Resilience Act excludes medical devices but applies to the non-medical IT products that hospitals procure: their manufacturers have had to report actively exploited vulnerabilities since 11 September 2026, and the remaining obligations apply from 11 December 2027. Five steps are worth taking: create a register of all AI applications with role and classification; clearly assign oversight and training; agree monitoring, logging and reporting channels with providers by contract; draw up a threat model for every critical system; and require update commitments and a Software Bill of Materials (SBOM) in procurement.
New on vamisec.com: the knowledge page on this topic
New on vamisec.com: the knowledge page “AI risk management in clinical settings”. It takes up the arguments of the journal article, updates them to reflect the situation as of October 2026 and explores them in depth from the deployer’s perspective — covering the classification of medical AI, the division of obligations between provider and hospital, a threat model with AI-specific attacks, risk assessment, concrete safeguards and the evidence required, complemented by frequently asked questions and verified sources. You can find the page at https://vamisec.com/en/wissen/secure-software-development/ki-risikomanagement-medizin. How the AI Act and the MDR interact from the manufacturer’s perspective is explained at https://vamisec.com/en/ki-vo-medizinprodukte — information on our MDR consulting is available at https://vamisec.com/en/mdr.
All links
Issue 2.2026 at mt|medizintechnik: https://mt-medizintechnik.de/fokus-auf-personalisierte-medizin/ · Knowledge page AI risk management in clinical settings: https://vamisec.com/en/wissen/secure-software-development/ki-risikomanagement-medizin · Category Secure Software & Product Development, medical devices section: https://vamisec.com/en/wissen/secure-software-development#medizinprodukte · AI Act and medical devices: https://vamisec.com/en/ki-vo-medizinprodukte · EU AI Act at a glance: https://vamisec.com/en/wissen/grc/eu-ai-act · MDR cybersecurity at a glance: https://vamisec.com/en/wissen/grc/mdr-cybersecurity · Threat modeling: https://vamisec.com/en/wissen/secure-software-development/threat-modeling · MDR consulting: https://vamisec.com/en/mdr
Do you have questions about your organization's IT security?
Free Initial Consultation →