You have won a tender and are expected to build a platform for health data within a year. So far you have run your infrastructure yourself, and the cloud was never an option because of data protection, security, and data sovereignty. Now the platform is supposed to scale and use AI, which calls for GPU power that is hard to keep in house. So the cloud after all? Four developments argue for it.
1. The legal framework has become clearer
Since Germany’s Digital Act of 2024, § 393 SGB V explicitly regulates cloud use in healthcare. Care providers, health and long-term care insurers, and their processors may process health and social data in the cloud if four conditions are met:
- Processing takes place in Germany, the EU, the EEA, or Switzerland, or in a third country with an adequacy decision by the European Commission. The provider has an establishment in Germany.
- Technical and organisational measures reflect the state of the art.
- The cloud systems used hold a current BSI C5 attestation, since 1 July 2025 generally of Type 2. A Type 2 attestation audits the effectiveness of the security measures over a longer period.
- The corresponding customer criteria listed in the attestation report are implemented. Part of the obligations therefore rests with the customer.
2. European cloud providers have caught up
Digital sovereignty is on every conference slide right now. Behind it sits a concrete question: who can access the data? If the provider, through its US parent, is subject to the CLOUD Act or Section 702 of FISA, US authorities can demand disclosure, even from a data centre in Frankfurt.
§ 393 SGB V leaves this question open. The large US providers can meet its requirements too. Anyone who wants to avoid access by authorities outside the EU has to look at the provider’s ownership as well.
This is exactly where European providers have caught up. Providers such as Open Telekom Cloud, STACKIT, or Hetzner meet the legal requirements and today offer compute, storage, networking, and GPUs for demanding applications. The range of managed services is smaller than at the US hyperscalers. We maintain a continuously updated overview of European providers.
3. AI compute demand is hard to plan for
Smaller and mid-sized open-weight models can now be run in house quite well. What is usually underestimated is the step from a pilot project to serving several hundred or a thousand users: many concurrent requests need a multiple of the GPU capacity. And anyone who knows the leading chat models from everyday use expects the same quality from an internal tool. Competitive open-weight models such as Kimi K3, DeepSeek V4, and GLM 5.3 need servers with several high-end GPUs for that. Hardware bought today is depreciated over several years. The models’ requirements change within months.
This is where the cloud plays to its strength. GPU capacity can be rented and adjusted to actual demand. Or you do not run the models yourself at all and use them via an API. Legally, an API endpoint is a cloud service like any other, so the requirements of § 393 SGB V apply here as well. In addition, the contract should rule out that inputs are used for training. Our overview of LLM APIs with EU endpoints shows which providers commit to what.
A technical property of inference helps here: it does not require permanent storage. Inputs and outputs can be processed 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 lowers the risk considerably. Choosing the provider carefully is still necessary.
4. The barrier to entry has dropped
For a long time, the effort of learning a new platform spoke against the cloud. 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. 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 create 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 an approval before every change, this is usually safer than manual configuration in the console, where mistakes creep in easily.
Network architecture, identity management, encryption, backups, disaster recovery, and compliance remain demanding, in healthcare in particular. Still, a small team today needs far less time than a few years ago to set up a new environment securely.
So the cloud after all?
If your infrastructure works, there is no immediate reason to switch. No cloud provider matches the sovereignty of your own systems, and for steady workloads your own hardware is often more economical. Whether a move pays off only becomes clear from the specific use case: which data is processed, how much demand fluctuates, which requirements will be added in the coming years, and what both paths cost over their entire lifetime, including staff, hardware refresh, and operations.
Often the result is a mix, for instance your own infrastructure for the core and rented GPU capacity for AI. For a platform that is built from scratch, has to scale, and is supposed to use AI, much speaks for the cloud today: the legal framework is clear, European providers meet it, and getting started has become easier.