Sovereignty Is Not an Attitude, It Is an Architecture Decision
Talk of European technological sovereignty quickly starts to sound like industrial policy and strategy papers from Brussels. For a dental practice, though, the question is very concrete: where do the systems that process patient data run? Who can access them? And what happens when a provider changes its terms, discontinues a service, or is compelled by an authority outside Europe to hand over data?
None of that is answered by a stance. It is answered by an architecture. Sovereignty exists where a practice physically holds its data, can trace how it is processed, and could switch providers without losing anything. With PAIRA, we build an AI reception for dental practices that is designed on exactly that principle: local first, European wherever local is not enough. This article explains why we consider that the right foundation, without alarmism and without pretending that cloud services could be dispensed with altogether.
The Legal Starting Point: Health Data Is a Special Category
The GDPR does not treat health data like ordinary personal data. Article 9 places its processing under a general prohibition with narrowly defined exceptions:
"Processing of personal data revealing [...] and the processing of [...] data concerning health [...] shall be prohibited." — Regulation (EU) 2016/679 (GDPR), Article 9(1), 2016
Treatment itself falls under one of those exceptions, but the exception does not relieve the practice of responsibility for every processor it brings in. A practice that uses an AI service remains the controller under the GDPR and needs a processing agreement under Article 28 that actually describes what happens to the data. On top of that sits the duty of medical confidentiality under Section 203 of the German Criminal Code, which has to be kept in mind whenever an external provider is involved.
Three further points shape the European perspective:
- Third-country transfers: transfers to countries outside the EU are governed by Chapter V of the GDPR. In its Schrems II judgment of 16 July 2020 (Case C-311/18), the Court of Justice of the European Union invalidated the transfer mechanism to the United States that applied at the time. Its successor framework is being challenged in court. An architecture that rests on an adequacy decision rests on something that can be revoked.
- Access laws outside Europe: the United States CLOUD Act of 2018 allows US authorities to demand data from providers based in the United States regardless of the country in which the servers are located. An EU region operated by a US hyperscaler is therefore a matter of data residency, not necessarily of data sovereignty.
- Section 393 SGB V: with the Digital Act (Digital-Gesetz), the German legislature for the first time set out explicitly under which conditions healthcare providers may process health and social data in the cloud. Those conditions include a processing location in Germany, the EU, the EEA or a country with an adequacy decision, and a current C5 attestation from the German Federal Office for Information Security (BSI) for the cloud service. Practices should check the exact attestation levels and transition periods against the current text of the law with their data protection adviser.
We do not read Section 393 SGB V as a hurdle but as a benchmark. It describes what the legislature considers a trustworthy cloud in healthcare. For every component a practice does not run itself, that is the right yardstick.
Dependency Is an Operational Risk, Not Only a Privacy Issue
Even once every legal question is settled, a second problem remains: dependency. The European cloud market is dominated by a handful of non-European providers. According to Synergy Research Group, the three largest US providers accounted for roughly 70 percent of the European cloud infrastructure market in 2024 (source: Synergy Research Group, 2024). For an individual practice, that concentration translates into four concrete risks:
- Pricing and contract risk: terms of use, pricing models and regions can be changed unilaterally. A practice has no negotiating power against a global provider.
- Discontinuation risk: AI models and interfaces are retired on a yearly cadence. A practice function that is hard-wired to a model version inherits a migration project at a time someone else chooses.
- Outage risk: a reception that stops working without an internet connection is a problem on Monday morning, not on the provider's status page.
- Exit risk: getting data out of a proprietary service is often harder than putting it in. The EU Data Act, applicable since September 2025, obliges providers of data processing services to make switching easier. That is progress, but a right to switch is no substitute for an architecture that makes switching practically possible.
Sovereignty in this sense means that the practice keeps the ability to say no. It can replace a service without migrating patient data, because the data never lived with the service in the first place.
The Practical Alternative: Inference On Site, Edge in Europe
A few years ago, demanding local AI processing inside a dental practice would have been unrealistic. That has changed. Modern workstation-class servers built around a system-on-chip in which the CPU and the graphics unit share the same memory now run language models, image analysis and the embeddings behind knowledge search at the power draw of an office PC. That makes it possible to run a large part of an AI reception where the data already is: inside the practice.
This is how PAIRA is built:
- The practice server (the "Brain") sits inside the practice network. Scheduling logic, patient matching, document analysis, the knowledge base and audit logs all run locally. Patient master data does not leave that network for AI processing.
- Local models handle text understanding, image processing and embeddings. They are replaceable because they sit behind an interface of our own rather than being woven into the business logic.
- Real-time speech processing, which local hardware cannot yet deliver at the required quality, runs in data centres inside the EU with contractually guaranteed zero data retention: audio is processed, not stored, and never used for training.
- The telephony link runs through an edge server hosted by a European operator. The practice server opens the connection from the inside out, so no port has to be exposed on the practice network.
- Encryption and audit apply at every layer: data is encrypted at rest and in transit, every access is logged traceably, and system access goes through a private overlay network rather than publicly reachable services.
The result is not a cloud-free architecture but a cloud-minimal one: every external component has to justify why it cannot run locally, and it has to be operated in Europe, secured by contract, and replaceable.
What Practice Owners Should Actually Check
Whether you use PAIRA or another system, the questions to put to any provider of an AI solution in healthcare are the same.
- Where is which data processed? Ask for a list of processing locations per data type. "EU region" answers the question about location, not the question about the provider's legal framework.
- Which data leaves the practice at all? A system that sends out only audio without master data has a different risk profile from one that uploads the entire patient record for processing.
- Is there any retention? Have zero data retention guaranteed in the contract, not merely promised in a slide deck.
- What does the exit look like? Ask in which format you get your data back and how much business logic stays with the provider.
- What happens during an outage? Check which functions keep working without an internet connection.
- Who carries the responsibility? The processing agreement under Article 28 GDPR has to reflect the actual architecture. A boilerplate contract that does not describe what really happens protects no one.
How we built the data protection architecture in detail is covered in our article on GDPR-compliant AI in dental practices. What "Made in Germany" means to us beyond the label is set out in the article on Made-in-Germany quality.
Conclusion: Sovereignty Is a Series of Small, Verifiable Decisions
European technological sovereignty is not decided for dental practices in Brussels. It is decided in every individual choice of provider. A practice that runs its AI locally, limits external services to what is genuinely necessary, and keeps each of those components European, contractually secured and replaceable is sovereign in the practical sense: it controls its data, understands its processing, and retains the freedom to switch.
That is exactly how we build PAIRA. If you want to see what a locally operated AI reception could look like in your practice, you will find the details on the PAIRA product page, or you can contact us directly.
Frequently Asked Questions
What does technological sovereignty mean for a dental practice in practical terms?
It means the practice controls where its patient data is processed, who can access it, and whether it could switch providers without losing data. It is less about where a product comes from than about architecture: local processing, European operators for everything external, contractually guaranteed deletion, and a realistic exit.
Is an EU region at a US cloud provider enough for patient data?
An EU region answers the question of storage location, not the question of legal framework. The US CLOUD Act allows US authorities to demand data from US providers regardless of where the servers are located. Whether that is acceptable in a specific case is something a practice should assess with its data protection adviser rather than assume silently.
What does Section 393 SGB V regulate for dental practices?
The provision sets out the conditions under which healthcare providers may process health and social data with cloud services. These include requirements on the processing location within Germany, the EU, the EEA or a country with an adequacy decision, and a current C5 attestation from the BSI for the cloud service. The specific attestation levels and deadlines should be checked against the current text of the law.
Can an AI reception run entirely without the cloud?
Large parts of it can: scheduling logic, the knowledge base, document analysis and text processing run on the practice server with PAIRA. Real-time speech processing at the quality a natural conversation needs is not yet something local hardware delivers in full. That component runs in EU data centres with zero data retention and without any transfer of patient master data.
Is local AI hardware even affordable for a single practice?
Yes. Modern workstation-class servers with memory shared between the CPU and the graphics unit run language models and image analysis at the power consumption of an office PC. The purchase is in the range of a well-equipped practice workstation, not a data centre, and the device remains the property of the practice.
What should a processing agreement for AI services contain?
It should reflect the actual architecture: which data types go to which processing location, which sub-processors are involved, whether and for how long data is stored, that no use for model training takes place, and how data is returned or deleted at the end of the contract. A boilerplate contract without those details does not describe what really happens.