AI Sovereignty for a Business That Will Never Build a Data Centre

AI sovereignty, for a UK business that will never build a data centre, comes down to three questions. Where does our data sit? Where does the model run, and who governs it? Whose courts can compel either? Most mid-market businesses have answered all three already, in the sense that their suppliers' defaults have answered for them. Very few have answered any of them deliberately, and that is the gap worth closing.

The sovereign AI conversation is usually pitched at governments. It is about national compute, chips and homegrown model companies, and it is conducted in megawatts. Translated down to a company with a few hundred staff, a CRM, a handful of AI tools and no intention of owning a server, the case rests on jurisdiction, continuity and control. Cost hardly comes into it, and where it does, it mostly argues the other way.

Earlier posts in this series covered renting your knowledge through software, meaning what accumulates inside the tools you use. This one is about the model those tools run on and the law that sits over it.

What is AI sovereignty?

AI sovereignty is the ability to decide, rather than inherit, where your data sits, where your AI model runs and who governs it, and which legal systems can reach either. For a country that means capability. For a business it means knowledge and choice.

The national version is real and well funded. In April 2026 the government launched its Sovereign AI Unit with £500 million behind it, on the argument that the country must be an AI maker, not just an AI taker. That is a sensible ambition for a country. A mid-market firm deciding whether its sales team should use a particular AI assistant is always going to be a taker, so the useful question for it is what kind of taker it is. It takes AI on its own terms when it knows the three answers and can live with them, and on somebody else's when nobody has asked.

The three legs

The three are separate on purpose. The most common pattern is a careful answer to the first that is taken to cover the other two.

The first leg, where the data sits

The NCSC's cloud security principles state the first leg plainly. You should be confident that you know where your data is, and who can access it. The same principle goes on to cover derivatives of your data, such as verbose logs and machine learning models, which is the part that matters most once AI is involved.

With an AI tool, your data is no longer only the files you uploaded. It is every prompt your team types, every document the system pulls in to answer one, every response it writes and every log it keeps of all three. Those can live in different places from the files themselves.

The government's UK Business Data Survey shows how much of this now runs on someone else's infrastructure. Among businesses that handle digitised data, 31% of businesses said that they use a public cloud provider, such as Amazon Web Services, Microsoft Azure or Google Cloud. In the same survey, 10% of businesses that handled digitised data (8% of all UK businesses) transferred (sent or received) data internationally.

Both figures can be accurate at once. Data held in a UK region of an American provider's cloud has not been transferred anywhere. It is still held by a company that answers to more than one legal system, and residency alone does not settle that. The first leg is necessary, and on its own it says nothing about the other two.

The second leg, where the model runs and who governs it

The model is a separate supplier, even when it arrives inside a tool you already pay for. Your CRM's AI assistant, your helpdesk's reply drafter and your meeting note-taker each send your data to a model, and that model belongs to a company with its own location, its own terms and its own decisions about what to keep.

Governing the model means three things. Someone in the business knows which model each tool uses and who provides it. Someone approves a change, rather than discovering it afterwards. And the work could be moved to a different model without starting again. Model providers retire their models on a schedule, which is a lock-in question to ask before you sign, and sovereignty adds a second reason a model might stop being available to you, which is the law.

The design choice that keeps a model replaceable is simple to state. What the business knows should live in a memory it owns, in readable form, and the model should be the part that reasons over it. Knowledge learned into a model's trained weights cannot be read, checked or carried across to a different model, which is one reason most businesses do not need fine-tuning to teach a system the facts. The memory owns the knowledge and the model owns the behaviour. Kept apart, the model becomes a component you can swap, and the second leg becomes something you can actually answer.

The third leg, whose courts can compel either

This is the leg that "our data is in London" does not reach. A supplier is subject to the law of where it operates and also to the law of where it is headquartered, and those can disagree about who may see what.

The sharpest example is American. The CLOUD Act, passed in 2018, requires US providers to disclose data within their possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States. A London data centre run by a US-headquartered company is therefore within reach of US legal process. A later post in this series covers what that means in practice and what it does not. The point here is narrower. Jurisdiction follows the company as well as the building.

None of this should be read as alarm. The NCSC is matter-of-fact about it, noting that there will be situations where a jurisdiction can request access to your data from the provider. This is normal and not specific to cloud services, the guidance adds. The guidance asks you to know which jurisdictions apply and decide whether that is acceptable, which is a long way from asking you to avoid them.

Continuity is a jurisdiction question too

The legal leg is usually discussed as a question about who can see your data. It is also about whether a service stays available to you at all.

In February 2025 Apple withdrew a security feature from its UK customers. Its support page is titled Apple can no longer offer Advanced Data Protection in the United Kingdom to new users, and it is direct about the effect. "Users in the UK who have not already enabled Advanced Data Protection will no longer have the option to do so." Apple's page does not give a reason. The move was widely reported as following a government demand, and the BBC was specific about it. The request was served by the Home Office under the Investigatory Powers Act (IPA). The Home Office has neither confirmed nor denied that any such notice exists.

It was a consumer feature, and most businesses never relied on it, but the mechanism transfers. A capability customers had been using was taken away because of the law in their country, and nobody breached a contract along the way.

Two lessons follow. The law that matters is not only foreign law, and in this case the government in question was the customers' own. And a deliberate answer to the third leg includes a fallback. For each AI capability the business depends on, it is worth knowing what you would do if it were withdrawn tomorrow. If the honest answer is that the work would stop, that is the dependency to address first.

Why the case is not cost

It would be easy to sell sovereignty as a saving, and for a business of this size it would usually be untrue. For most mid-market workloads, renting a frontier model through an API is cheaper than running your own by a wide margin, and the economics only turn at a scale few firms of this size come near. A later post in this series puts real numbers on that.

So the case rests on three other things. Jurisdiction is knowing whose law sits over each piece and deciding you can accept it. Continuity is knowing what keeps working if a supplier changes course, retires a model or withdraws a service. Control is being able to change the arrangement on your own timetable rather than a supplier's.

None of the three requires owning a model. Most of the work is in the first leg and in keeping the knowledge outside the model, which is why the case for owning your intelligence and the case for AI sovereignty end up in the same place. An intelligence system, meaning a maintained record of what the business knows that people and machines can both query, is what makes the model replaceable. Running your own model is one possible answer to the second leg, and for most businesses not the right one yet.

What a deliberate answer looks like

When I wrote our own answers down, they were not all British. Our knowledge lives in plain files on our own machines, with a copy on GitHub, which is an American company, and the model we use most comes from a US provider, so US law reaches both. I would make both choices again. What changed is that each became a decision with a known fallback. The files open in any text editor, nothing we know lives inside a model's weights, and a different model can be pointed at the same memory.

The second leg is the one I could answer least well from experience, so this autumn I am working through what it takes to adapt and run a small open model myself, one day a week, on a deliberately neutral task with no client data in it. The later posts in this series draw on that work.

For most businesses the first pass is short. List every AI tool in use, including the ones inside software you already pay for. For each, write down where the data and logs sit, which model does the work, where its provider is headquartered, and what you would do if it disappeared. Most answers will be acceptable, and the few that are not justify the exercise.

Practical takeaways

1. Ask the three questions separately. A good answer on where the data sits says nothing about who governs the model or whose law reaches the supplier.
2. Count the logs and the prompts as data. What your team types and what the system retrieves to answer it can live somewhere different from the files.
3. Record the supplier's headquarters next to the data location. Jurisdiction follows the company as well as the building.
4. Keep the knowledge outside the model. It is what turns a model change from a rebuild into a configuration change.
5. Write a fallback for every AI capability you depend on. If the answer to "what if this were withdrawn tomorrow?" is that the work stops, start there.

Frequently asked questions

What is AI sovereignty?

AI sovereignty is a business's ability to decide, rather than inherit, three things about the AI it relies on. The first is where its data sits, including the prompts, logs and documents the system handles. The second is where the model runs and who governs it, meaning who chooses it, changes it and can switch it off. The third is whose courts can compel the providers of either. For a government the phrase means compute and homegrown model companies. For a mid-market business it means having a deliberate answer to each of the three, written down, and knowing what you would do if one of them changed.

Does AI sovereignty matter if we will never build a data centre?

Yes, because the national version and the business version are different questions. Governments talk about sovereignty in terms of compute, chips and homegrown model companies, and almost no mid-market business will ever own any of those. What a business can own is its answers. It can know which country holds its data and its logs, which provider's model it depends on and how replaceable that model is, and which legal systems reach each supplier. None of that needs a server room. It needs an afternoon with the supplier list and somebody whose job it is to keep the answers current.

What is the difference between data sovereignty and AI sovereignty?

Data sovereignty is about where information is stored and which laws apply to it. AI sovereignty includes that and adds the model, which is a separate supplier with its own location, its own owner and its own terms. A business can keep every file in a UK region and still send each prompt, along with the documents retrieved to answer it, to a model run by a different company under a different law. The NCSC's cloud guidance already counts machine learning models and logs as derivatives of your data. AI sovereignty is the habit of asking the data questions about the model as well.

Does using cloud AI mean we are not sovereign?

No. Sovereignty is about whether the answers are deliberate, and a cloud AI service can be a perfectly good answer. The questions to put to it are about jurisdiction and continuity. Which country's law governs the provider, whatever region your data sits in? What would happen if that provider withdrew a capability from the UK, or was compelled to hand something over? And could you move the work to a different model without rebuilding it? If you know the answers and can live with them, you are using cloud AI on your own terms. If nobody has asked, the supplier's defaults have answered for you.

Who in the business should own AI sovereignty?

One named person with enough seniority to say no to a supplier, usually whoever already owns supplier risk or data protection, with the founder or CEO signing off the answers. It should not sit with whoever set up the AI tools, because the role is to question those choices rather than defend them. The job itself is small. Keep a one-page record of the three answers for every AI supplier, review it whenever a supplier is added or changes its terms, and take it to the board once a year. Most businesses find the first pass takes an afternoon.