In healthcare, the external processor is the breach surface.
Hospitals carry stacking obligations — NIS2, GDPR health data, EHDS, the AI Act — and the data that leaks leaks through third-party platforms, not the hospital. We run healthcare IT where the data never leaves the EU, with clinical AI on open-weight models on your own hardware.
Healthcare organisations in the EU face several regulatory regimes at once — NIS2 (hospitals are essential entities), GDPR (health data is a special category), the European Health Data Space, and the AI Act for clinical AI — and a single patient-data incident can breach more than one of them simultaneously. The dominant way that data is actually lost is not a direct hack of the hospital but exposure through an external processor: a third-party platform, vendor or AI API added to the data path. The engineering answer is to remove that processor — keep data on EU-sovereign infrastructure you control and run clinical AI on open-weight models on your own hardware — and that is the way Argus Root runs healthcare IT.
In short
- Hospitals are NIS2 essential entities (€10M/2%); health data is a GDPR special category (€20M/4%, controller liable even when the processor is breached); EHDS (EU 2025/327) governs storage and sharing; clinical AI is AI Act high-risk (€15M/3%).
- The penalties stack — one incident can trigger GDPR, NIS2 and the AI Act at once.
- The 2025 failure mode was the external processor: one vendor breach exposed ~15.8M files and ~169k sensitive records, including HIV status — the hospital was not hacked, the platform was.
- The average healthcare breach costs $7.42M and takes ~279 days to contain — the highest of any sector.
- The control that removes the dominant failure mode: EU-sovereign infrastructure + open-weight AI on your own GPUs — no record leaves your jurisdiction.
Which regulations bind you — and why do the penalties stack?
Healthcare is one of the few sectors where four major regimes apply to the same systems at the same time. Under NIS2, hospitals and healthcare providers are essential entities, the highest tier, with hard cybersecurity obligations and fines up to ten million euros or two percent of turnover. Under GDPR, health data is a special category demanding the strongest protection, and the controller — the hospital — is liable even when a processor causes the breach, up to twenty million euros or four percent. The European Health Data Space regulation governs how records are stored and shared. And where AI is used as, or in support of, a medical device, the AI Act classifies it as high-risk, up to fifteen million euros or three percent.
The consequence of all four applying together is that a single event rarely stays in one box. A breach of patient data processed by an AI system can be a GDPR violation, an NIS2 security failure and an AI Act non-compliance at once, each with its own regulator and its own fine, layered on top of an average healthcare breach cost of around seven and a half million dollars and a containment time near nine months. Compliance here is therefore not a matter of satisfying one rule but of removing the conditions under which several can be breached simultaneously — which points at the data path itself.
Why is the external processor the breach surface?
The instructive thing about the serious 2025 healthcare incidents is where they happened. They were not, for the most part, hospitals being broken into directly. They were patient data exposed through centralised third-party platforms and software vendors — the systems hospitals had sent their data out to. One French vendor breach alone exposed in the order of fifteen point eight million files and around one hundred and sixty-nine thousand sensitive records, including patients' HIV status. The hospitals involved had not been hacked; the processor holding their data had.
This reframes the security problem. Every time patient data is sent to an external system, a third-party-hosted application or a foreign AI API, three things are added at once: a processor to your breach surface, a jurisdiction to your legal exposure, and a dependency to your clinical uptime. Under GDPR you remain liable for that processor's failure, and the more processors sit in the path, the more ways the same data can leak while the liability stays with you. The single most effective control, then, is not another layer of monitoring on top of the external path but the removal of the external path where it is not essential — keeping the data, and the processing, on infrastructure you control inside the EU.
Can you run AI in a hospital without sending data to a foreign API?
Yes, and this is the part that has genuinely changed. Open-weight models now run capably on your own GPUs or in a sovereign EU cloud, which means a hospital can use AI for documentation, triage support or knowledge retrieval without shipping a single patient record to an external API. The model comes to the data rather than the data going to the model. That inverts the breach path described above: there is no external processor to be the breach surface, no foreign jurisdiction added to the exposure, and no third-party outage that can take a clinical AI feature offline — and when AI sits in a triage or diagnostic workflow, its availability is a patient-safety property, not a convenience.
It also makes the AI Act far more tractable. A high-risk clinical AI system you run yourself, on infrastructure you control, is one where the data governance, the human oversight and the cybersecurity the Act demands are yours to implement and evidence, rather than properties you have to take on trust from a vendor. The check below shows the shape of it: a clinical query answered by a model running on-premises, with the egress to external APIs measured at zero.
# clinical AI on-prem: open-weight model on your GPU — no record leaves the EU $ ollama run med-model "summarise this discharge note ..." served by: on-prem GPU node · external API calls: 0 $ check egress --to external-apis 0 connections · patient data never left the building # the external processor you remove is the breach surface you eliminate
What EHDS means for how you architect now.
The European Health Data Space regulation, in force since March 2025, sets the rules for how health records are stored, accessed and shared, keeping them within national healthcare infrastructure rather than scattered across arbitrary third parties. From 2029 it goes further, requiring datasets to be made available for secondary use — research, public health, innovation — through secure processing environments under permits granted by national access bodies. It is, in effect, a mandate to know where your health data is and to be able to govern access to it precisely.
The practical lesson is to build for that future now rather than retrofit it later under deadline. An estate where the data already sits on EU-based infrastructure you control, with access governed and the flows documented, turns the 2029 obligation into a configuration change — opening a controlled, permitted path to a secure processing environment — rather than a re-platforming project. Architecting for local sovereignty today is the cheap version of EHDS readiness; discovering in 2028 that your data is spread across processors you cannot fully account for is the expensive one.
What we run for healthcare.
We bring the relevant Argus services together into one sovereign healthcare estate rather than selling them as separate parts. That foundation is EU-based managed infrastructure and managed cloud where the sensitive data paths stay under your control, with the security hardened and mapped to NIS2 through our managed security practice and the GDPR data flows documented for your records of processing. On top of it we run clinical AI on open-weight models, drawing on our work in production AI integration and retrieval knowledge systems, so documentation, triage support and knowledge retrieval happen without a record leaving the building.
Around that core sit the properties healthcare cannot do without. Resilience is engineered in through backup and disaster recovery, because when AI assists a clinical workflow its uptime is part of patient safety. The whole is mapped to the obligations you answer to through our compliance and sovereignty practice, so the position you can show a regulator is demonstrable rather than asserted. The result is not a stack of products but a healthcare estate designed around a single principle: the most sensitive data your patients have stays under your control, inside the EU.
Sovereign by design, because the penalties stack.
In a sector where one incident can trigger three regulators and the average breach costs millions before the fines, the prudent architecture is the one that removes failure modes rather than monitoring them. Keeping data and AI on infrastructure you control inside the EU is not the cautious option that costs you capability; given open-weight models and proper engineering, it is the option that eliminates the dominant breach path while keeping the AI fast, available and yours to govern. The sovereignty is the security, not a tax on it.
It is also increasingly a differentiator rather than a compliance chore. Being able to tell a regulator, a referring clinician and a patient that their most sensitive data stays under EU jurisdiction and your control is becoming a reason organisations are chosen, not merely a box they tick. That is the same principle behind everything Argus runs — a European operator that builds and runs the infrastructure itself, on open foundations, and tells you the truth about where your data sits — applied to the data that matters most and the rules that punish losing it hardest.
Questions healthcare buyers ask.
Which regulations bind a healthcare organisation in the EU?
Do the penalties really stack on a single incident?
Why is the external processor described as the breach surface?
Can you run AI in a hospital without sending data to a foreign API?
What is the EHDS, and what does it mean for our architecture?
Is the EU AI Act relevant to clinical AI?
Does keeping data local mean we lose resilience?
How do you handle GDPR controller liability for us?
Can you work with our existing clinical systems and EHR?
Why run healthcare IT with Argus Root rather than a hyperscaler?
Map your healthcare estate to the rules that punish losing it.
Tell us what you run and where patient data flows, and we will map it against NIS2, GDPR, the EHDS and the AI Act, show you where an external processor is widening your breach surface, and set out what a sovereign estate with on-premises AI would change. You get a clear picture of the exposure, the controls and the resilience, before any commitment.