Remember when picking a cloud region felt like a solved problem? You ticked a box that said Frankfurt or Dublin or Sydney, your data lived there, and everyone moved on. The compliance team got their screenshot. The architecture diagram got its little flag icon. Done.
I used to believe that too. Then I read the law more carefully, and I stopped sleeping quite as well.
Here is the thing I want you to sit with for a minute. Where your data physically sits, and who can legally compel someone to hand it over, are two completely different questions. We have spent a decade pretending they are the same question. They are not. And the gap between them is about to get a lot more expensive to ignore.
This is the part I care about most, so I want to be precise rather than dramatic. Data sovereignty means your data is governed by the laws of the jurisdiction you choose, and that no other government can reach into it through a side door. Data residency, the thing most people configure, only means the bytes live in a particular country. Those are not synonyms. I wrote a neutral, plain explainer on the difference at data residency versus data sovereignty if you want the careful version. This piece is the opinionated one.
The region toggle is a comfort blanket
Let me say the quiet part out loud. A region setting tells you where the disk is. It tells you almost nothing about whose courts can open it.
Picture a European company. Customer records in a data center near Frankfurt. Region locked, residency satisfied, auditor happy. The operator of that infrastructure is headquartered in the United States. Under U.S. law, that headquarters can be served with a warrant, and the data on the Frankfurt disk can be compelled out, because the law follows the company, not the disk.
That is not a hypothetical I invented to scare you. It is the explicit design of a law that already exists.
Meet the CLOUD Act
In 2018, the United States passed the Clarifying Lawful Overseas Use of Data Act, the CLOUD Act, as part of a larger spending bill. It amended the old Stored Communications Act, and it did one thing with surgical clarity. It established that a U.S.-based provider must disclose data in its possession, custody, or control when served with valid legal process, regardless of whether that data is stored inside the United States or on foreign soil (CLOUD Act, 2018).
Read that again. Regardless of where the data is stored.
The law did not appear out of nowhere. It came directly out of a fight. The U.S. government wanted emails that Microsoft was storing on servers in Ireland, Microsoft said no, the location is foreign, and the case climbed all the way to the Supreme Court. Congress short-circuited the whole argument by passing the CLOUD Act, which settled the question in the government's favor and made the case moot (CLOUD Act, 2018). The reach is the point. It was built to reach.
I want to be fair here, because I think fairness is what makes an argument worth listening to. The CLOUD Act is not some lawless dragnet. It requires legal process, it has reciprocity agreements with allied governments, and there are mechanisms for a provider to challenge a request that conflicts with foreign law. None of that is nothing. But notice what none of it changes. If the company that runs your infrastructure answers to a U.S. court, your region toggle is a comfort blanket, not a wall.
And the United States is not unique in this instinct. Plenty of governments assert reach over data their companies control. I am pointing at the CLOUD Act because it is the clearest, most documented example, not because it is the only one. The pattern is what matters. Whoever controls the company controls the data, and the flag on your architecture diagram does not change the chain of command.
Regulation is not slowing down. It is accelerating.
Now here is why I think this stops being a footnote and becomes a front-line concern, and soon.
The volume of law governing where data lives and how AI systems are built is going UP, fast, on both sides of the Atlantic. The EU AI Act entered into force on August 1, 2024. The bans on prohibited practices kicked in on February 2, 2025. Obligations for general-purpose AI models started on August 2, 2025. And the heavy obligations for high-risk AI systems land on August 2, 2026 (EU AI Act implementation timeline).
That is four major compliance waves inside two years. From one law. In one region.
Do you see where this is going? Every one of those obligations assumes you can answer a simple question with a straight face. Where does this data live, who governs it, and who can compel access to it. If your honest answer is "it sits in Frankfurt, but a foreign court could pull it tomorrow," you do not have a clean answer. You have a liability dressed up as a checkbox.
Don't get me wrong, regulation that protects people is a good thing, and a lot of the AI Act is exactly that. But the trend line is unmistakable. The questions are getting harder, the auditors are getting sharper, and the gap between residency and sovereignty is exactly the gap they are learning to probe.
Sovereignty is a property of control, not configuration
So what do you do about it? You stop treating sovereignty as a setting and start treating it as a property of who controls the stack.
This is the part where I get to tell you what I believe, which is why we built Carpathian the way we did. We run our own infrastructure, on hardware we control, on U.S. soil, instead of reselling a slice of a hyperscaler and pasting our logo on top. That is not a flex. It is a deliberate choice about who answers for your data, and it comes with its own honest tradeoffs, which I will get to.
Because here is the uncomfortable truth about most "cloud sovereignty" offerings. A lot of them are a hyperscaler underneath, with a sovereignty wrapper sold at a premium. The marketing says local. The control plane, the billing entity, the ultimate parent company, often still trace back to a jurisdiction that can compel. You did not buy sovereignty. You bought a more expensive version of the same comfort blanket.
Now the fair part, because I promised it. Hyperscalers are extraordinary. The breadth of services, the global footprint, the ability to spin up a hundred regions before lunch, that convenience is genuine and I am not going to pretend otherwise. For a huge number of workloads, that convenience is the right call and sovereignty barely registers as a concern. If you are running a hobby project or a low-stakes internal tool, you genuinely do not need to think about any of this, and anyone telling you that you do is selling you something.
But convenience and control are not the same axis, and we have been trained to confuse them. When the law gets serious, and it is getting serious, control is the thing that holds. A control plane you operate. A company that answers to one set of courts you chose. Hardware you can point at. That is sovereignty you can defend in front of an auditor, not sovereignty you have to take on faith.
What I am committing to
I will not pretend running your own infrastructure is free. It is harder. It is slower to scale in raw service breadth. It means we say no to features a reseller would just bolt on from a hyperscaler's menu. We carry that cost on purpose, because I would rather give you fewer things I can stand behind than a long menu I cannot.
What I am committing to is simple. We will keep building on infrastructure we own and operate, on U.S. soil, with a clear chain of control you can inspect, so that when you ask "whose laws govern my data," the answer is one sentence and not a flowchart. And we will keep writing the honest version of these questions, even the parts that complicate our own pitch, because a sovereignty story you cannot interrogate is just marketing with a flag on it.
The next time someone shows you a region toggle and calls it sovereignty, ask the only question that has ever mattered: not where does my data sleep, but who can wake it up.
