The client was a US telecom. The data was American, the servers were American, and using an American cloud AI service on it was still, flatly, off the table.

That surprises people, because “AI sovereignty” has become shorthand for a European anxiety — a Brussels concern, filed next to GDPR and the Digital Markets Act, faintly protectionist, mostly rhetorical. It’s the sort of phrase that appears in a keynote and never in a sprint. So when an American company tells you their American customer data can’t touch an American AI vendor, the frame breaks, and something clearer shows up underneath it.

The constraint wasn’t geopolitical. It was CPNI — a category of telecom customer data that comes with federal rules about where it may travel — plus a contract that said the same thing in stricter words. Nobody involved had an opinion about digital independence. They had a regulator.

This is the most useful thing to understand about sovereignty right now: it’s a technical requirement wearing a political costume, and the costume is doing real damage. It makes the requirement sound optional — a preference, a posture, something you adopt if you feel strongly about it. Meanwhile the organisations who genuinely need it are often the last to work that out, because they’ve been told this is a debate about flags.

The two questions nobody separates

So they ask the wrong question. Someone proposes an AI project, someone else notes that the data is regulated, and the meeting concludes that AI isn’t possible here.

What actually happened is that two different questions collapsed into one:

Can we use AI on this data?

Can we send this data to a cloud AI vendor?

The second has a hard no. The first, in almost every case I’ve seen, does not — and hasn’t for a while.

The collapse is easy to miss because for about three years the two questions genuinely had the same answer. If you wanted a model good enough to be useful, it lived in somebody else’s datacentre and you reached it over an API. “Using AI” and “sending your data somewhere” were the same act. A lot of institutional knowledge got formed in that window, and it hasn’t been revisited since.

What makes this expensive is that the decision doesn’t look like a decision. Nobody writes down “we have chosen not to pursue AI in our regulated business lines.” It surfaces as a series of meetings that end early, a proposal that quietly doesn’t get a second version, an innovation budget that gets spent on the parts of the company where the data is boring. From the inside it feels like compliance working correctly. From the outside it’s a company that has ruled out a category of tooling for its most valuable data, on the basis of a technical constraint that stopped being true.

Where the requirement actually comes from

It’s worth being specific about who genuinely has this constraint, because the political framing has made the real list invisible.

Sector regulation. Telecom customer records, health data, financial data, criminal justice data. These come with rules about processing and disclosure that predate cloud AI by decades and were never written with it in mind — which is precisely the problem, because “we sent it to a vendor for analysis” maps badly onto rules drafted for a world of filing cabinets and named processors.

Contract. Very often the strictest constraint in the room isn’t a law at all. It’s a clause in a master services agreement, put there by a client who has their own regulator, which says the data stays inside a defined boundary. No lobbying will change this one. Somebody signed it.

Professional privilege. Lawyers, doctors, journalists protecting sources. Here the concern isn’t only about the vendor’s behaviour — it’s that the existence of a third-party copy can itself be discoverable, which changes what privilege means.

Public bodies. Procurement rules, national security classifications, citizen data held under statute. Slow, cautious, and generally not free to make a pragmatic call.

And yes, jurisdiction. Foreign legal reach over data held by foreign-owned providers is a real category, and it’s the one everybody argues about. I’d note it’s one item on a list of five, and in my experience the least common trigger for an actual project. It’s just the loudest, because it’s the only one that makes for a good speech.

Four of these five have nothing to do with independence from anybody. They’re the ordinary machinery of operating in a regulated industry. The fifth got all the airtime, and in doing so it convinced everyone that this was a values question.

What it actually cost to do properly

Here’s the part that should change the calculation, and the reason I think this is worth writing about now rather than two years ago.

The build was about two weeks. The hardware was one machine with two consumer graphics cards in it — the sort of thing an enthusiast has under a desk, not a GPU cluster, not a procurement cycle. The model was a small open one, running locally. The pipeline picks up new conversations on a schedule, classifies them in two passes, and ships the results into a dashboard the client’s team already had open. Nobody touches a spreadsheet at any point.

The task it replaced was being quoted at roughly two work-weeks per month of human review. The pipeline does a comparable volume in about five hours, unattended, overnight, inside the compliance boundary.

I want to be careful about what that does and doesn’t prove. This is a classification problem — sorting messages into a fixed taxonomy — which is one of the tasks small local models have become genuinely good at. It is not evidence that you can run a frontier-grade assistant on two consumer GPUs, because you can’t.

But the class of work that classification covers is enormous and unglamorous, and it’s most of what regulated organisations actually want: triage, routing, tagging, extracting structure from unstructured text, telling you what’s in a pile of documents nobody has time to read. That work now runs on hardware you can buy with a credit card, and it runs where you tell it to.

Five years ago “sovereign AI” meant “worse AI, later, at greater expense.” That was a real trade-off and it deserved the eye-rolling it got. It is mostly no longer true, and a lot of strategies are still priced as though it is.

The trade-off you do pay

It isn’t free, and I’d rather say what it costs than pretend otherwise.

You give up the frontier. The best model available to you is not the best model available. For classification that gap has closed to the point of irrelevance; for open-ended reasoning it very much hasn’t.

You own the box. Updates, capacity, the failure at 3am, the awkward conversation about what happens when it needs to run twice as much next quarter. A cloud API is somebody else’s operational problem, and that’s worth real money.

And the one nobody budgets for: you have to measure quality yourself. When you call a vendor’s API you inherit their benchmarks, their evaluation, and their claim that it works. Run your own model and nobody is doing that for you.

That part surprised me most on this project, and it’s the piece I’d argue is genuinely managerial rather than technical. We ran controlled experiments on the classification prompt, changing one variable at a time against a hand-labelled reference set. Two results came out backwards from what everyone expected. Asking the model to explain its reasoning alongside its answer made it measurably less accurate, reproducibly. Giving it a “thinking” mode — more compute per message, the thing you’d assume helps — made it dramatically slower and less reliable on the hardest category.

Both of those are things you’d never learn by reading a model card. They cost about a week to establish and they were the difference between a system we could defend and one that merely produced output.

The general lesson: sovereignty moves the evaluation burden onto you. That’s a staffing decision, not an infrastructure one, and it’s the line item most often missing from the business case. If you’re going to run your own models, somebody on the team has to own the question how do we know this is working — and that person needs time, a labelled test set, and permission to report a bad number.

The managerial reframe

The pattern I keep seeing is that sovereignty gets treated as a blocker, and blockers get routed around or waited out. Neither works. You can’t route around a regulator and the wait is indefinite.

Treated instead as a design input — the same category as latency, budget, or an accessibility requirement — it becomes tractable, because design inputs are things engineers are used to building against rather than arguing with. The question stops being are we allowed to do AI and becomes what shape does AI take here, which has answers.

Two things follow from that shift that are worth naming.

It’s a capability, not a project tax. The first sovereign deployment is expensive because you’re learning: hardware, model selection, evaluation, the operational shape of it. The second is mostly configuration. If your business touches regulated data at all, the right unit of investment is the capability, amortised across clients and projects — not a surcharge you rediscover and re-argue every time a proposal comes up.

The compliant path has to be the easy one. This is the part I’d underline for anyone leading a team. Rules don’t determine behaviour; friction does. If the approved way to analyse a pile of customer data is slow, requires three approvals, and produces a worse answer, then the rule is not really in force — it’s a statement of preference that people will comply with exactly as long as it’s convenient. A tool that runs unattended overnight and beats the manual process on both speed and quality doesn’t need to be enforced. It just needs to exist.

That’s the argument I’d make to a board, and it isn’t about risk at all. Building the compliant path properly is how you stop competing against your own shortcuts.

Boring infrastructure

I’d like the word sovereignty to become boring. Right now it carries too much — independence, geopolitics, a certain amount of continental pride — and all of that noise is preventing a fairly mundane engineering conversation from happening in organisations that badly need to have it.

The useful version is much smaller. It’s the ability to answer one question without hedging: where is this data, and who can compel access to it? That’s it. Not a position on anybody’s jurisdiction, just a sentence you can say out loud to an auditor, a client, or a court.

Plenty of organisations can’t say that sentence today. Which is fine, as long as it’s a decision — but mostly it isn’t one. It’s an accumulation of individually reasonable choices, made when the alternative genuinely was worse, that nobody has revisited since the alternative got good.

The client in this story never framed any of it as sovereignty. They had a regulator, a contract, and a number they needed. What they got was a small grey box, humming away in a rack that belongs to them, doing in an afternoon what used to take a fortnight — and no interesting story at all about where their customers’ data went.

That’s what it should look like when it’s working.

About the author
Jean-Christophe Cuvelier
Jean-Christophe Cuveliertotophe
Fractional CTO & technical lead · Brussels

He runs Wellmade, a product engineering studio, and still writes the code. Twenty years of building products for companies that wanted the thinking and the building done by the same person.