A renewal questionnaire came back from a client's procurement team with a question I had not seen on that form before: in which jurisdiction is the model executed, and who operates the hardware it runs on. It was between a question about SOC 2 evidence and a question about password rotation. Answering it properly took the better part of a week. The call went to a vendor, who passed it on to another company that actually ran the model, on hardware in a region someone had picked eighteen months earlier for latency reasons and never written down. Part of the final answer, after all that tracing, was "we believe so."
Nobody on that project was making an argument about European digital policy. The question existed because one of the client's own customers had put it into a contract, and contracts propagate downward. Sovereignty has become a field on a vendor form, sitting between data residency and incident response SLAs, a text box somebody has to fill in before the deal moves.
The gap between wanting AI sovereignty and depending on foreign stacks
The measurement backs this up. Deloitte's State of AI in the Enterprise, published January 2026 across 3,235 director-to-C-suite respondents in 24 countries, found 77% now factor an AI solution's country of origin into vendor selection and 58% build their AI stacks primarily with local vendors. Eighty-three percent rate sovereign AI at least moderately important to strategic planning, 43% very or extremely important, and 66% report at least moderate concern about relying on foreign-owned AI. Worth noting that the survey screened organisations already running AI daily, so these are operators answering, not spectators.
Then the figure that reorders the whole conversation, from the same survey: 11% of companies in the Americas rely on foreign-sourced solutions for the majority of their AI stack, against 32% in EMEA.
Roughly three times the dependence, in the region with the strongest stated preference against it.
That number settles two arguments at once. The European concern is attached to a real exposure, and the exposure is still sitting in production today. What remains is an architecture and supply problem, with a measurable gap between what people say they want and what they actually run.
Now let's break the regional averages into individual countries and we will get a more concrete picture. In France, only 42% of executives say clients are happy with AI-enabled experiences, against 63% in the US, according to the ServiceNow and ThoughtLab Enterprise AI Maturity Index 2026. Customer resistance is a real cost line. It shows up in adoption rates and in how much hand-holding a rollout needs, long before anyone writes it into a governance review. In Germany the same study flags legal liability and intellectual property exposure as a heavier concern than elsewhere, which it is attributed to the regulatory environment and claimant-friendly courts. McKinsey's State of Organizations 2026 puts a number next to that: regulatory, ethical and legal concerns were named as a barrier to adopting externally developed AI by 48% of European respondents and 56% of German ones, against 44% in North America.
The same survey has 72% of leaders reporting that geopolitical uncertainty is already affecting their organisations. That is the concern that the new procurement questions are trying to address: if a supply route or a legal arrangement can change on short notice, buyers want it on paper which country and which company their models actually run in.
For a Mittelstand board in Munich, none of this reads as abstract. A director who already thinks in terms of a duty to organise and a duty to document looks at a system where nobody can say which entity performed the processing, and sees an evidentiary problem they will have to solve under time pressure, with the burden of proof pointing at them.
Answering the question, system by system
Three answers per AI system make the questionnaire survivable:
- First: where inference happens: naming the actual executing entity and region rather than the brand on the invoice.
- Second: where the data rests: including embeddings, logs and whatever the vendor retains for abuse monitoring, which is the one people miss.
- Third: what the replacement path costs: if the first two answers become unacceptable.
The third answer is what turns a documented procurement position into something more than a stated preference, and it is usually the one missing. The first two take an afternoon of chasing documentation. The third requires knowing how much of your system is coupled to a specific provider's behaviour: prompt formats tuned against one model's quirks, function-calling schemas, a retrieval pipeline built around one embedding model's dimensions, evaluation results that only exist for the current vendor. If moving providers means re-tuning every prompt and re-running every evaluation, the replacement path costs six weeks and a quality regression nobody has budgeted. If your own code calls the model through a single wrapper you wrote, with a test suite that checks output quality independently of who the provider is, switching is a configuration change and a week of evaluation.
Decoupling what your business depends on from who runs the hardware
I learned the value of that boundary on a migration that had nothing to do with AI. We had 300 clients on a system built in Microsoft Access, and a mandate to move all of them to a modern web stack. The conventional path was to redesign the interface properly while we were in there. Our main competitor did exactly that, shipped something genuinely better looking, and then spent an enormous amount of time and money retraining their entire client base. We did the opposite and made the new web system look exactly like the old one: same screens, same labels, same flow, with a completely different engine underneath. The migration ran about a year in batches, required zero additional training, and produced a negligible number of migration-related support tickets. The reason it worked is that the surface the users depended on was decoupled from the infrastructure we needed to replace.
Same mechanic, different layer. If the thing your business depends on is "a model that answers these questions at this quality level," and the thing you might need to change is "which company's hardware produces that answer," those two need to be separated by an interface you control before the day you need to use it. Build it afterwards and you are doing architecture work during a procurement crisis, which is the most expensive time to do it.
The normal reflex is to skip all of this by running everything on your own hardware. That is a legitimate option with a cost profile most people underestimate, and I have written separately about what on-premise inference actually demands once you move past the demo. On-premise is a different answer to the same three questions, carrying its own capital expenditure and its own staffing requirement, and the architecture work stays on your plate either way.
The work here is unglamorous and finite. Take the three AI systems closest to customer data or regulated decisions, and write the three answers for each: executing entity and region, every place data comes to rest, and the number of weeks plus the quality risk involved in switching providers. Two of those answers come out of existing documentation in an afternoon. The third is the one that stalls, and the systems where it stalls are the ones to price properly, because that number is what you will be carrying into the next renewal, and somebody's procurement team will eventually ask for it in writing.