You have won a tender and are expected to build a platform for health data within a year. For 15 years you have run your infrastructure yourself. Back then, the cloud was out of the question, too many open questions around data protection, security, and data sovereignty. Now the platform is supposed to scale and use AI. That calls for GPU power that is hard to justify keeping in house. So the cloud after all?
The debate is not new. Cloud infrastructure offers scalability and compute, while healthcare brings particular demands on data protection, information security, and data sovereignty. In recent years, however, both the legal framework and the technical options have changed. Four developments are worth a closer look.
1. The legal framework has become clearer
With Germany's Digital Act of 2024, cloud use in healthcare was regulated explicitly in the Social Code for the first time. § 393 SGB V permits care providers, health and long-term care insurers, and their processors to process health and social data via cloud services, provided certain conditions are met. These include processing in Germany, the EU, or certain other countries, as well as appropriate technical and organisational measures.
The service used must also hold a current BSI C5 attestation, since 1 July 2025 generally of Type 2, which demonstrates the effectiveness of the security measures over a period of time rather than only at a single date.
2. European cloud providers have caught up
Few terms are as popular right now as digital sovereignty. It appears on every conference slide. Behind it, though, sits a fairly concrete question: who can actually access the data?
The server location alone does not answer it. A data centre in Frankfurt helps little if the provider, through its US parent, is subject to the CLOUD Act or Section 702 of FISA.
This is exactly where things have moved in recent years. European providers have caught up. They are not yet on the level of the big US hyperscalers in every respect, but they now offer capable infrastructure even for demanding applications. Among the German providers, for example, Open Telekom Cloud, STACKIT, and Hetzner hold C5 Type 2 attestations. We keep a regularly updated overview of European providers holding a C5 attestation.
3. AI moves faster than your own hardware
Smaller and mid-sized open-weight models can well be run in house these days. What is easily underestimated is the step from a pilot project to serving several hundred or a thousand users: many concurrent requests require a multiple of the GPU capacity. Then there are user expectations. Model performance still grows primarily with model size and compute (Scaling Laws), and anyone who knows the leading chat models from everyday use is quickly frustrated when the internal tool answers noticeably worse. Competitive open-weight models such as Kimi K3, DeepSeek V4, and GLM 5.3 need servers with several high-end GPUs to run. Such hardware is hard to justify keeping in house.
This is where the cloud plays to its strength. GPU capacity can be rented and adjusted to actual demand, now also from European providers. Or you do not run the models yourself at all and use them via an API. If the endpoint is located in the EU and it is contractually ruled out that inputs are used for training, this is in principle an option for health data too. An API endpoint is a cloud service like any other: the requirements of § 393 SGB V apply here as well. Our overview of LLM APIs with EU endpoints shows which providers offer them and what they commit to.
A technical property of inference helps here: it does not require permanent storage. Inputs and outputs can be processed entirely in memory and discarded after the response. If the provider contractually waives logging and storage (zero data retention), no data ever accumulates that could later be handed over, for instance under the CLOUD Act. That does not replace careful provider selection, but it lowers the risk considerably.
4. The barrier to entry has dropped
One often underestimated argument against the cloud has long been the learning curve. Every provider comes with a world of its own: consoles with hundreds of services, its own terminology, its own concepts for networking, permissions, and encryption. Anyone wanting to switch had to rely on documentation, forums, and trial and error.
AI assistants have changed that fundamentally. They walk you through every setting, explain best practices, and help judge which option fits your case. Properly set up AI agents go a step further: through Infrastructure as Code they implement servers, networks, permissions, and security rules directly. Every change exists as code and can be reviewed, traced, and repeated. With the right guardrails, such as automated checks and approvals before every change, this is safer than manual configuration in the console, where mistakes creep in easily.
This does not mean infrastructure has suddenly become easy. In healthcare in particular, network architecture, identity management, encryption, backups, disaster recovery, and compliance remain demanding. But the hurdle of learning a new environment and setting it up securely has become much lower for a small team.
So the cloud after all?
Not necessarily. Your own infrastructure can still make sense. For very large, continuously running workloads it is sometimes more economical, and tight dependencies on existing systems or particular demands on control and availability can argue for running things yourself.
For new platforms, though, the cloud is a far more realistic option today than it was a few years ago. The legal framework is more concrete, the market offers more choice, and AI increases the need for flexibly available compute while lowering the barrier to entry at the same time.