Data Sovereignty: Owning Your AI’s Inputs and Outputs

Data sovereignty is the principle that data is subject to the laws and control of whoever governs it. For a company using AI, the useful version is narrower and more practical: knowing, and deciding, who can see, keep, use and move the data that goes into your AI systems and the outputs that come out of them.

Most companies believe they have this covered because they chose a European data region. That answers where the data sits. It does not answer who controls it, and control is the part with commercial consequences.

The distinction matters more with AI than with ordinary software, because AI systems do not just store data. They read it, learn from it, log it, and produce new material from it. Every one of those steps is a place where control can quietly pass to someone else.

Residency is not control

Cisco’s 2025 Data Privacy Benchmark Study, a survey of more than 2,600 privacy and security professionals in 12 countries, captured the confusion neatly. 90% said data is inherently safer stored locally, and 91% said global providers protect data better than local ones. Both beliefs can be reasonable. Together they show that “where” is doing work it cannot carry.

The legal reason is straightforward. The US CLOUD Act of 2018 allows US authorities to require US-based providers to produce data in their possession, custody or control, regardless of where in the world it is stored. A European data centre operated by a US-headquartered company changes the latency, not the jurisdiction. That is not a reason to avoid global providers, most of whom offer strong contractual and technical protections. It is a reason to be precise about which question each protection answers.

So treat it as three separate questions: where the data is processed, under whose law, and who can make decisions about it. Residency answers the first. Contracts and architecture answer the other two.

Four questions to ask about your inputs

Inputs are everything you send into an AI system: documents, customer records, emails, internal notes, the contents of a prompt. Four questions settle most of the risk.

1. Who can see it? The provider, its subprocessors, human reviewers for abuse monitoring, and anyone with access to your account. Ask for the subprocessor list and the conditions under which a human at the provider can read your data.
2. Is it used to train or improve models? Business and API tiers from the major providers generally exclude customer data from training by default, while consumer tiers often do not. The same model can sit behind very different terms depending on how you pay for it.
3. How long is it kept? Including logs, cached files and data retained for abuse monitoring, which can outlive the conversation by weeks. Zero or short retention is often available, but rarely the default.
4. Where is it processed, and by whom? Not only storage but inference, which may run in a different region from where your files sit.

This is not a theoretical exercise. In the same Cisco study, 64% of respondents worried about inadvertently sharing sensitive information through generative AI, yet nearly half admitted entering personal employee data or non-public company information into such tools. The gap between policy and practice is where control is usually lost, one pasted document at a time.

Your outputs are only partly yours

The instinct is to assume that whatever an AI system produces for you belongs to you. Legally it is less tidy.

The US Copyright Office’s January 2025 report on copyrightability concluded that purely AI-generated material is not protected by copyright, and that prompts alone do not give a user enough control to count as its author. Human selection, arrangement and modification can be protected. Raw output generally cannot. Most provider terms assign you whatever rights they hold in outputs, but they cannot assign rights that do not exist.

The practical consequence is that the defensible value is rarely in the individual output. It sits in what surrounds it: your documents and instructions, the human editing, and the assets your use of AI accumulates over time. Those are the parts worth protecting contractually and architecturally.

The asset nobody lists: your context layer

Every company that uses AI seriously builds up a body of material that makes the models useful for its specific work: the documents they retrieve from, the instructions that describe how the business operates, the examples of good output, the evaluation cases, and the feedback on what worked. Call it the context layer.

It is the most valuable data asset in the whole arrangement, because it is specific to you and it compounds. It is also the one most often left inside a vendor’s product by default, stored in a proprietary format, in a workspace you rent. When that happens, switching provider means rebuilding the part that took longest to make.

Keeping the context layer in a store you control, in formats you can read and move, is the single most effective data decision a company makes. It is the data version of the argument against vendor lock-in, and it is why an AI operating system treats context as infrastructure rather than as a feature of whichever tool is current.

What the law now gives European buyers

For companies in the EU, the buyer’s position improved materially in September 2025. The EU Data Act has applied since 12 September 2025, and its chapter on switching between data processing services covers cloud, platform and software services, including many AI tools.

Contracts in scope must let the customer switch provider or move data back on premises, with a notice period of no more than two months, a transition period of no more than 30 calendar days in most cases, and at least 30 days to retrieve data afterwards. The data covered explicitly includes the input and output data, including metadata, generated by the customer’s use of the service. Until 12 January 2027, providers may charge only the direct costs of switching and data egress. After that date they may not charge for switching at all.

That does not make every AI product portable, and early termination penalties for fixed-term contracts remain allowed. It does mean the exit terms in your AI contracts are now a negotiating position rather than a courtesy, which makes switching costs far easier to keep near zero. How the rules apply to a specific contract is a question for counsel. That they apply at all is worth knowing before renewal.

A working data-control checklist

None of this requires a large programme. It requires a handful of deliberate decisions.

• Map the data. Which AI tools are in use, which data goes into each, and on which tier. AI governance is the owner of that register.
• Use business terms. Move any consumer-tier use of AI with company data onto business or API terms that exclude training by default.
• Set retention deliberately. Shorten retention where the provider allows it, and know what is kept for abuse monitoring.
• Own the context layer. Keep instructions, documents and evaluation cases in a store you control, in open formats.
• Test the exit. Once a year, export a real workload and confirm you could run it elsewhere.
• Write it into the contract. Training exclusions, retention, subprocessor notice, output rights and exit terms, in writing.

The question underneath all six is the same one that decides which AI services to buy and what to keep: when this relationship ends, what leaves with the provider and what stays with you?

If your context still lives inside someone else’s product, tell Daniel what you have built so far, where your data sits today, and what the business needs it to do. Book 30 minutes with Daniel.

Frequently Asked Questions

What is data sovereignty in AI?

It is control over who can see, keep, use and move the data that goes into your AI systems and the outputs that come out of them. Legally, data sovereignty means data is subject to the laws of the place and party that govern it. Practically, for a company, it means knowing and deciding how each AI provider handles your inputs, outputs and accumulated context.

Is data residency the same as data sovereignty?

No. Residency answers where data is stored or processed. Sovereignty also asks under whose law and who controls it. Under the US CLOUD Act, US-based providers can be required to produce data in their possession, custody or control regardless of where it is stored, so a European data region alone does not settle the question.

Do AI providers train their models on our data?

It depends on the tier, not just the provider. Business and API tiers from the major providers generally exclude customer data from training by default, while consumer tiers often do not. Check the terms for the specific product and plan in use, and move any company data off consumer-tier tools.

Who owns AI-generated outputs?

Contractually, most providers assign you whatever rights they hold in outputs. Legally, the US Copyright Office concluded in January 2025 that purely AI-generated material is not protected by copyright and that prompts alone are not enough to make a user its author. Human selection, arrangement and editing can be protected, which is where the defensible value sits.

What does the EU Data Act change for AI contracts?

Since 12 September 2025, contracts for cloud, platform and software services in scope must allow switching or moving data back on premises, with at most two months’ notice, a transition period of at most 30 days in most cases, and at least 30 days to retrieve data. Switching and egress charges are limited to direct costs until 12 January 2027 and then prohibited.

What is the first step towards data sovereignty for AI?

Map which AI tools are in use, which data goes into each, and on which terms. That register usually reveals consumer-tier tools handling company data, retention settings nobody chose and context held in vendor formats. Fixing those three things, and owning your context layer in open formats, covers most of the practical risk.