Data sovereignty

Where the term comes from and where it is standardised

Data sovereignty is a politically shaped term. It came into wide use in Europe after case law of the Court of Justice of the European Union twice in succession struck down the basis for data transfers to the United States, making it clear that the operator's registered office helps determine who has access. In everyday usage, it overlaps with digital sovereignty, which also covers questions of technological dependence.

There is no legal definition. The General Data Protection Regulation does not recognise the term. In Chapter V, it regulates the conditions under which personal data may be transferred to a third country, and in Case C-311/18 the Court of Justice ruled that standard contractual clauses alone are not sufficient if the law of the destination country prevents an equivalent level of protection. The European Data Protection Board has published a step-by-step assessment procedure on this.

On the other side are provisions that establish access: under 18 U.S. Code Section 2713, added by the CLOUD Act, providers within US jurisdiction can be required to hand over data, regardless of where the data is stored. FISA Section 702 is directed at providers of electronic communication services within the same jurisdiction. It is precisely this constellation that explains why the question of location does not answer the question of access.

What the answer is made up of

The question of data sovereignty breaks down into six individual questions. Each has a verifiable answer, and only together do they form a picture.

• Legal form and registered office of the contracting party. Who is the controller in the contract, in which register is it entered, and which law is it subject to?
• Ownership structure. Does the provider belong to a group with a parent company in a third country? A European subsidiary does not change group affiliation.
• Subprocessors. Who is actually involved, where are they based and for what purpose? This list is in the processing register under Art. 30 and is the most informative part of any review.
• Processing locations for each step. Storage, index, embeddings, model calls, logs, support. See Data residency.
• Contractual basis for third-country transfers. Adequacy decision, standard contractual clauses, supplementary measures? And for which processing exactly?
• Handling of requests from public authorities. Is there a documented procedure, and is the customer informed where this is permitted?

A reliable statement about data sovereignty answers all six points. You will find Nexoria's information on this further down in the section “How Nexoria implements this”.

Which operating models exist

• Global provider with a European region: technically mature and widely available. Group affiliation remains, and the question of access is addressed through contracts and supplementary measures.
• Sovereign operating models: operation by a local company, sometimes with separate staff and separate administration. The set-ups differ considerably; what matters is who has administrative access.
• European provider with its own infrastructure: registered office, operation and law coincide. The subprocessors still need to be checked, because payment processing, error monitoring and telephony rarely come from the same company.
• Operation in your own data centre: the most extensive control and the highest ongoing effort. For language models, it also means running the models yourself and keeping them up to date.

None of these models is right in principle. The choice depends on which data is processed and how much effort an organisation can and is willing to bear.

How Nexoria implements this

Nexoria answers the six questions openly and without superlatives. The contracting party is Nexoria Systems UG (haftungsbeschränkt), with its registered office in Kelkheim, registered at the Amtsgericht (Local Court) Königstein im Taunus. For operation, the following applies: Files, the knowledge index and semantic search run on dedicated servers in Germany. The website and dashboard are also hosted in Germany.

On the model provider: Answer generation by Nex uses Mistral AI.

Other services and enabled integrations need to be considered separately: error monitoring via Sentry, based in the USA, without access to document content, payment processing via Stripe, as well as Microsoft Graph and Gmail when the email integration is enabled. For the optional VoiceBot, Telnyx (headquarters USA, EU branch Ireland) provides the telephone connection in Frankfurt; speech recognition and speech synthesis are handled by Voxtral from Mistral AI. The components and providers involved are listed under Security and privacy and in the processing register.

The full chain of subprocessors, with registered office, purpose and contractual basis, is set out in the processing register. On the data protection framework: For your data protection review, the data processing agreement under Art. 28, the processing register under Art. 30 and the data protection impact assessment under Art. 35 GDPR are publicly available.

Where the limits lie

• The information on the GDPR is not to be understood as a certificate or seal of approval. The details on this page are Nexoria's own statements; the data flows for each processing step are described in the privacy policy and the processing register.
• The technical and organisational measures are based on BSI IT-Grundschutz and have been implemented, specifically following the modules ORP.4, CON.1, APP.5.3 and OPS.1.1.5. This does not replace a certificate.
• Technical error monitoring via Sentry, payment processing and enabled email integrations have their own data flows. For the optional VoiceBot, Telnyx is added for the telephone connection. The providers involved and the contractual bases are listed in the processing register.
• ChatGPT (OpenAI), Claude (Anthropic), Gemini (Google) and Langdock can optionally be connected to Nexoria. Nexoria also works without these integrations. When connected, shared content is transferred to the respective provider. That provider's terms, processing locations and settings apply.
• Whether a particular foreign access law applies to a particular processing operation is a legal assessment, not a product feature. For this purpose, the security overview documents the processing locations and the providers involved.

If you want to separate the question of location from the question of access, you will find the page on location under Data residency. The full classification with all processing steps is available under Security, and the questions from procurement processes are answered in the Due diligence FAQ.