_Summary
When a bank brings AI into regulatory reporting, one of the first questions from IT security is where the data will be stored. The answer is usually reassuring: an EU region, Frankfurt or Amsterdam, and the box gets ticked. But location answers only half the question. The other half is who holds legal power over the data and over the systems that process it. Supervisors and auditors are asking about that half more and more.
What is the difference between data residency and data sovereignty?
- Data residency describes where data physically sits.
- Data sovereignty describes which jurisdiction can compel access to it.
The two often get treated as the same thing, but they are separate. Under the US CLOUD Act, providers subject to US jurisdiction must disclose data within their possession, custody or control whether it is stored inside or outside the United States (US Department of Justice, CLOUD Act text). A document stored in Frankfurt by a US-controlled provider therefore remains within reach of US legal process.
This is not a theoretical concern. At a French Senate hearing in June 2025, Microsoft France’s Director of Public and Legal Affairs said he could “not guarantee” that French citizens’ data held in French data centres would never be passed to the US government without Paris’s consent (Assemblée nationale, written question 10884).
Why does this matter more for compliance AI than for other software?
It matters because of what compliance AI has to read. It does not work on generic text. To assess a financing against the EU Taxonomy, answer a due diligence questionnaire, or check internal policies against an updated regulation, the AI has to ingest credit files, loan contracts, counterparties’ annual reports, internal policies and, in family offices, custodian bank statements. Together these are the most sensitive documents an institution holds.
Processing also differs from storage. When AI works on a document, the document is opened, parsed, and turned into inputs and outputs. Each of those steps creates another place where the data exists, and another place where jurisdiction applies.
Isn’t the legal basis for EU–US data transfers settled?
Not yet. The EU General Court upheld the EU–US Data Privacy Framework on 3 September 2025, and the ruling was appealed to the Court of Justice on 31 October 2025 as Case C-703/25 P (University of Copenhagen, European Data Protection Law Review). The Court of Justice struck down both predecessor frameworks, Safe Harbor and Privacy Shield. Building a multi-year compliance architecture on a transfer mechanism that is under appeal is a risk decision, not a formality.
What does DORA change?
DORA turns the question from a privacy topic into a supervisory one. Financial entities must keep registers of information on their ICT contracts. The European Supervisory Authorities used those registers to designate the first critical ICT third-party providers (EIOPA). In November 2025 they published a list of 19 such providers, among them the largest cloud platforms (PwC Legal).
For ICT services that support critical or important functions, DORA also requires documented exit strategies. For a bank, the question of which AI runs on whose infrastructure, under which jurisdiction, is now something to document, justify and defend in front of an auditor.
What does sovereignty look like in practice?
Sovereignty does not come from a stronger contract or a “sovereign” label on a data centre. It comes from how the system is built.
4 questions are worth putting to any AI vendor before it touches your documents:
- Is any company in the processing chain subject to non-European jurisdiction? That includes the vendor’s parent company, its hosting provider, and any external model API it calls.
- Does the model run on infrastructure the vendor controls, or does every document go out to a third-party API?
- Is each client’s data processed in its own isolated environment?
- Is your data ever used to train or improve the model?
A fifth question is easy to overlook: can every answer the AI produces be traced back to the document and passage it came from?
Sovereignty over your data means little if you cannot account for what the AI concluded from it.
How does DYDON AI approach this?
We built our platform on the premise that the AI comes to the data, not the other way round. That rests on three architectural commitments.
Swiss-incorporated, Swiss or European-hosted, no US company in the chain. DYDON AI is a Swiss company with no US parent. Our hosting infrastructure is either Swiss or European, depending on the needs of our clients. Because no company in the processing chain is subject to US jurisdiction, the CLOUD Act has nothing to attach to. The same holds for any other foreign access law that works through a provider’s corporate ties.
Nothing retained outside your environment. The models we use are open-weight models with fixed weights. They process a document and return an answer, and they do not learn from or remember what they have seen. Client data is never used for training. Your documents, extracted data and validated answers exist in one place only: your own dedicated, isolated environment, under your control. That is also where the audit trail lives. Nothing sits in a shared pool, on a third-party API, or in a vendor log on foreign infrastructure.
Open-weight models on European infrastructure. Every document is processed on infrastructure within European jurisdiction, and no external model API is called. Where an institution requires it, the platform can also run inside the client’s own IT environment.
Let’s talk about your use case
Every institution or organisation handles different documents, under different rules. If you’re thinking about bringing AI into your compliance work, or want to check whether your current setup really keeps your data under your control, we’re happy to talk it through.
Tell us about your situation, and we’ll show you how DYDON AI can help you use AI securely, with your data staying where it belongs. Get in touch with us →