Residency was the easy part

For most of the last decade, sovereignty was a conversation about values. Whether Europe should depend on American infrastructure. Whether regulation was a strength or a handicap. Whether any of it mattered commercially.

That conversation is over, and it did not end because someone won the argument. It ended because dates started passing.

15 January 2026. Amazon Web Services made its European Sovereign Cloud generally available, with a first region in Brandenburg and €7,8bn committed through 2040. The architecture is serious: a separate legal entity under German law, EU-resident-only operations, independent identity management, billing, DNS and certificate authority. Reported pricing sits at a premium of around fifteen percent over standard EU regions. Microsoft, Google with Thales, and Oracle are all fielding comparable offers.

This matters less for what AWS built than for what building it concedes. The largest infrastructure providers in the world have collectively decided that European jurisdictional exposure is a real enough commercial problem to justify parallel infrastructure. That is not a marketing position. That is capital expenditure.

3 June 2026. The European Commission proposed the Cloud and AI Development Act as the centrepiece of its Technological Sovereignty Package. The proposal states the position plainly: three non-EU providers control more than seventy percent of the European cloud market, and those providers are subject to third-country laws with extraterritorial effect, including laws mandating data access that may conflict with EU fundamental rights.

CADA introduces four Union assurance levels. Level 1 is a self-assessment baseline that nearly every provider serving the public sector will need to meet. Level 2 requires demonstrated independence from third-country influence and transparency over the software supply chain. Level 3 requires the provider to be owned and controlled from within the EU, with criteria extending to personnel citizenship. Level 4 adds EU-cleared personnel, third-party audit, and a prohibition on transferring AI inference data outside the Union.

Whatever survives trilogue, something important has already happened. For six years the European conversation about cloud sovereignty ran through voluntary certification, and voluntary certification failed. The EUCS scheme was never adopted, because member states could not agree on what sovereignty meant. CADA does not resolve that disagreement so much as route around it, by giving procurement officers a scale with numbers on it. A buyer can now specify a level. A vendor can now be measured against one.

2 August 2026. The EU AI Act’s high-risk obligations became enforceable: risk management, data governance, technical documentation, logging, human oversight, cybersecurity resilience. The Act addresses multi-agent systems directly. Where a sequence of agents performs a function, the compliance boundary extends to every agent performing a high-risk function in that chain, not only to the model that started it.

Read that again with an integration architect’s eyes. The obligation to produce evidence does not stop at the model. It follows the chain of calls, into the systems those calls touch.

Behind all three dates sits the moment the residency argument stopped working. In June 2025, Microsoft’s French subsidiary confirmed under oath before a French Senate hearing that it could not guarantee protection of data from US authorities, even for data held in France under a French-marketed sovereign offering.

That answer was honest, and it was correct. The CLOUD Act reaches data through the parent entity, not through the server. A European data centre operated by a company under US jurisdiction is a European data centre under US jurisdiction. Everyone in enterprise procurement understood this in principle before June 2025. What changed is that it is now on the record, and every evaluator in Europe can cite it.

The standard model of digital sovereignty has three layers, and it is a good model.

Data sovereignty is control over where information is stored and who may lawfully access it. Operational sovereignty is visibility into and control over what a provider does inside your environment. Technological sovereignty is autonomy over the stack itself, and continuity if the relationship with the provider ends. AI sovereignty is usually drawn as a vertical, cutting through all three.

Every one of those layers describes a state. Where something sits. Who can see it. Who owns it.

None of them describes what happens next.

An enterprise does not run on stored data. It runs on decisions, and in 2026 a growing share of those decisions are executed by software with no person present. An invoice is matched and paid. A shipment is rerouted. A patient record is updated from a device reading. A credit limit is adjusted. A customer is offboarded. Each of these is an act performed by an automated process, against a system of record, under a legal jurisdiction that nobody classified when the integration was built.

We propose a name for the missing layer.

The term is technical and its content is not. Law, evidence, continuity: those are the terms a CIO already argues in. What the word “runtime” adds is precision about where. A runtime is the place code actually executes, and the entire argument of this paper is that Europe has spent five years regulating where data rests while paying almost no attention to where its decisions are carried out.

Runtime sovereignty is not a refinement of data sovereignty. It sits above all three established layers, because it is the layer at which the other three are either honoured or quietly bypassed. An organisation can hold every byte of its data in a sovereign region and still execute the decisions that matter on a control plane it does not govern, generating an audit trail it does not hold, in a process that stops the moment a foreign legal order lands on a vendor it has never met.

Runtime sovereignty is testable. Four questions decide it, and every one can be asked in a procurement conversation.

Between March and May 2026 we surveyed 611 IT and business decision-makers across Denmark, Finland, Germany, the Netherlands, Norway and Sweden. We were not trying to find out whether AI was happening. We were trying to find out where it gets stuck.

Two numbers from that research define this paper.

The distance between those figures is the argument of this document. Urgency is high and rising. Infrastructure is close to absent. The gap is five-fold, and it does not close by writing a policy.

Further context from the same research. Sixty-four percent rate centralised governance of integrations as critically or very important, which tells us awareness is not the problem. Sixty-five percent say connecting legacy systems to modern cloud platforms is a significant challenge. Fifty-nine percent struggle with the complexity of point-to-point connections that cannot be managed at scale. Two-thirds run between two and five integration platforms simultaneously. Sixteen percent still write custom point-to-point integration code by hand, while describing that practice as a major problem.

This is what an ungoverned runtime looks like from the inside. Not a single bad decision, but the aggregate of a decade of individually rational ones.

The cost is measurable. Knowledge workers in the surveyed markets spend a mean of 7,6 hours a week on manual tasks that could be automated, which for an organisation of a thousand employees works out at roughly €10,7m a year in direct salary terms alone. German workers carry the heaviest individual burden at 8,5 hours. Danish organisations bear the highest mean annual cost. The single largest bottleneck in every country surveyed is data entry and transfer, which is another way of saying that where the pipelines are missing, people become the integration layer.

The AI return is not arriving either. Only thirty-four percent have AI in production in any department, and seven percent have deployed it widely. The mean share of AI projects achieving measurable P&L impact is 25,5 percent. Among organisations that have deployed AI, thirty-six percent name integration challenges as the top barrier to further progress.

Denmark reports the highest rate of AI deployed at scale in the survey, at seventeen percent, more than double the European figure. It is also the only country where an integration-first approach is the dominant strategy rather than a parallel one, at thirty-eight percent. Danish organisations allocate a mean of 17,75 percent of IT budget to integration, and one in five spends more than thirty percent.

Data sovereignty is critical for seventy-three percent of Danish organisations, the highest figure in the survey.

Denmark did not choose between sovereignty and speed. It built the layer first and got both. That pattern is not theoretical. It is measured, in one of the six markets, right now.

Ninety-seven percent of the organisations we surveyed are already factoring AI agents into their governance thinking. Three percent are not.

That figure is easy to misread. It does not mean the infrastructure is ready. It means the question has arrived. Set it against the twelve percent who have built integration as a governance and control layer, and the shape of the next two years becomes clear: near-universal intent to deploy agents, sitting on top of a runtime that in seven out of eight organisations cannot govern them.

Here is why that matters more than it did with earlier automation.

A tool that assists a person is governed by the judgement of the person using it. If the output is wrong, a human is in the loop to catch it, and if they do not, accountability is straightforward. An agent that acts with minimal oversight has no such property. It requires infrastructure to authorise, observe, constrain and, when necessary, reverse what it does.

The Model Context Protocol made this concrete faster than most enterprises expected. MCP standardised how models call tools, and every major platform vendor added support within roughly a year. That was good for the ecosystem and it collapsed the integration problem for agent builders. It also means the tool-call layer is now the surface where an agent meets a system of record, at every organisation, through one protocol.

Which makes the tool-call layer the audit surface.

The evidence a regulator will ask for is not a model card. It is a record: who called which tool, with what data, under what authorisation, at what time. That record is generated at the integration layer or it is not generated at all.

Now add jurisdiction. An agent action is not a query. It is an instruction executed against a system, and it inherits the jurisdiction of the infrastructure that executes it. If the orchestration runs on a control plane operated under third-country law, then every agent action in your organisation is a decision taken under that law, regardless of where the underlying records happen to be stored.

This is where the two halves of this paper meet. Sovereignty stopped being an infrastructure procurement question the moment enterprises started letting software act on their behalf. The agent is the reason runtime sovereignty is urgent rather than merely interesting.

If runtime sovereignty is the missing layer, the next question is a practical one. Where in an enterprise architecture does it actually get implemented?

The answer is narrower than most sovereignty programmes assume, and it is not the cloud provider.

A cloud provider sees infrastructure. It knows a container started, a request arrived, a disk was written. An identity provider sees authentication. It knows who logged in and what role they held. A data platform sees records at rest. None of them sees the act.

The integration layer sees the act. It is the only component in the stack that observes the complete transaction: which process ran, which system it touched, what it changed, under whose authorisation, in what sequence, with what result. That is not a claim about product quality. It is a structural property of where the layer sits. Everything else in the architecture sees a fragment.

Which means a complete evidentiary record can only be assembled in one place. An organisation that tries to reconstruct agent accountability from cloud logs, identity logs and application logs is performing forensics across three partial accounts, none of which was designed to answer the question. The record either exists at the integration layer or it exists nowhere.

Runtime sovereignty depends on one architectural decision, taken early and difficult to reverse: the separation of the control plane from the data plane.

The control plane is where processes are designed, deployed, monitored and audited. The data plane is where they execute, against real systems, carrying real payloads. In a platform where these are one thing, they share a jurisdiction by construction, and no contract can separate them afterwards. In a platform where they are genuinely distinct, execution can sit in one jurisdiction while management sits in another, and either can be moved without the other.

That separation is what the four tests are really testing. It is why continuity under compulsion is an architectural question rather than a commercial one, and it is the reason so many platforms fail it while satisfying every residency requirement on paper.

An integration platform built for data residency and an integration platform built for runtime sovereignty are not the same product, though the category sells them under one name.

The residency-shaped platform asks where the data is stored and answers with a region. Its control plane is a single hosted service, because that is the efficient way to build a multi-tenant product. Its audit trail is a feature of that service. Its exit path is an export.

The sovereignty-shaped platform asks where the decision is executed and answers with a deployment choice. Its control plane is relocatable, because that is the only way continuity under compulsion can be satisfied. Its audit trail belongs to whoever holds the control plane. Its exit path is a documented migration that a customer can run.

The category has spent a decade optimising for the first. Regional data centres, residency certifications, in-region processing commitments. All of it real, all of it addressing the layer that has now been solved and priced by the infrastructure providers themselves. Almost none of it addresses where the act occurs.

A market has appeared in the last eighteen months for agent gateways: products that sit between models and tools, enforcing policy on every call, logging what was invoked and by whom.

Every capability in that description already exists in a mature integration platform. Policy enforcement per call, denial by default, authorisation recorded, a complete transaction log, connectivity to systems of record. The tool call and the integration call are the same call, arriving through a different protocol.

Buying a separate gateway to govern agents, alongside an integration platform that governs everything else, produces two partial audit trails and a seam between them. The seam is where the evidence goes missing, and it is exactly the fragmentation the previous chapter warned about, reintroduced deliberately at the moment it matters most.

Agent governance is a function of the integration layer. Any architecture that separates them will have to reconcile them later, under a regulator’s timetable rather than its own.

A manifesto that only makes its own case is a brochure. Four objections to everything above are strong, and a CIO reading this will already have thought of all of them.

Sovereignty costs money. The premium on sovereign cloud offerings sits in the region of fifteen to twenty percent, and feature sets are narrower. Sovereign regions launch with fewer services, fewer availability zones and thinner model catalogues than their mainstream equivalents. On-premises deployment carries capital cost, skills cost and slower time to value.

We will be specific about our own number, because a document that criticises other vendors’ premiums while concealing its own is not worth reading. The sovereign tier described in the next chapter costs €1 000 per month above the standard platform price. That is what it costs us to deliver Frends from European infrastructure under a European ownership chain, and that is what we charge for it. Whether it is worth paying depends entirely on the workload, which is the argument of the rest of this chapter.

CADA may not survive in recognisable form. The precedents are not encouraging. The EUCS certification scheme never achieved adoption because member states could not reconcile their positions on immunity from extra-European law. The ePrivacy Regulation, proposed in 2017, has been stalled for close to a decade. CADA enters trilogue as one of the most contested files on the table, and the compliance thresholds are not yet specified. Building a strategy on the assumption that Level 3 becomes binding on schedule would be unwise.

Europe is pulling in two directions at once. The Digital Omnibus, presented in November 2025 and under negotiation through 2026, is an explicit competitiveness-driven simplification of GDPR, AI Act and cyber-reporting obligations. The same institution proposing binding sovereignty assurance levels is simultaneously reducing the regulatory burden that made sovereignty urgent. Both things are true, and the tension is unresolved.

Full technological sovereignty is not attainable. Not in Europe, not anywhere, not within any planning horizon that matters. Semiconductors, foundation models and the deepest layers of the stack are not going to be European on a five-year view. Any organisation pursuing sovereignty as a purity standard will spend heavily and arrive nowhere.

We accept all four.

The conclusion we draw is not that sovereignty is overstated. It is that sovereignty is a risk-management discipline applied selectively to workloads, and that the correct deliverable is optionality rather than independence.

Not every workload needs Level 4. Most need Level 1. A minority — clinical systems, payment execution, grid operations, citizen records, defence supply chains — need considerably more, and those are precisely the workloads where an organisation currently has the least visibility into where execution actually occurs.

The practical instruction is classification. Sort workloads by consequence of compulsion: what breaks, and how fast, if the provider is ordered to stop. Then place execution accordingly. Most organisations have never done this exercise for their integration estate, which is why the twelve percent figure is what it is.

One further caution, and it applies to us as much as to anyone.

The market has produced a category of offerings that present European independence while retaining structural dependencies: joint ventures with a non-EU parent, European-branded services running on non-EU controlled backends, national clouds whose operating company answers to a foreign holding structure. Distinguishing these from genuine jurisdictional independence requires an audit, not a check of a company’s registered address.

The four tests exist for this reason. They are answerable with evidence, and they are difficult to answer dishonestly.

Sovereignty delivered through contract is a promise about how a company will behave. Sovereignty delivered through architecture is a property of how a system is built. The first can be revoked by a court in another country. The second cannot.

Six design principles follow from the four tests. They are written so that any platform, including ours, can be measured against them.

Execution goes to the data, not the reverse. The runtime should deploy where the systems live: in the cloud, in a private data centre, behind a firewall, air-gapped with no outbound path. The management layer should see execution telemetry, not payloads.

The control plane must be relocatable. If the design assumes a single vendor-operated control plane in a single jurisdiction, continuity under compulsion fails by construction, no matter how good the contract is. Portability of the control plane is the hardest of the six principles to retrofit and the one most worth asking about.

Code and connectors must be inspectable. Open connectors and access to the underlying source are what convert a vendor claim into something a customer’s own security team can verify. A platform that cannot be read cannot be audited, and a platform that cannot be audited cannot produce evidence.

One audit trail across integrations, APIs and agent actions. Fragmented logs across separate tools do not constitute an evidentiary record. When a regulator asks a question about a chain of agent actions, the answer must come from one place.

Access denied by default. Every exposed endpoint and every agent-callable tool should be unreachable until a policy explicitly permits it, with authorisation evaluated per call and recorded.

Exit is a feature. Standard notation, portable definitions, documented data extraction, and a migration path a customer can execute without the vendor’s cooperation.

Principles are cheap. Four mechanisms in our own platform are what turn them into something a security team can verify, and they are the specific things I would want a customer to interrogate in any platform, ours included.

Telemetry crosses the boundary. Payloads do not. This is the one that decides whether the architecture claim is real. When a Frends Process runs, integration data moves between Agents inside the customer’s network. What reaches the control plane is execution statistics and telemetry: which process ran, when, how long it took, whether it succeeded, which shape it failed on. The invoice, the patient record, the payment instruction never leave the data plane. A CIO evaluating any platform should ask exactly what crosses that boundary, and should expect a specific answer rather than a reassurance, because a control plane that receives payloads has quietly become a data plane in a different jurisdiction.

Agents connect outbound only. The Ground Agent reaches on-premises systems without those systems being exposed to the internet. Connections are initiated from inside the network outward, over Azure Service Bus on the standard service and its equivalent on the sovereign tier. Nothing needs an inbound path through the firewall, which is what makes air-gapped and heavily segmented deployment possible rather than theoretical.

No policy means no access. An API published on the platform is unreachable until a policy explicitly permits it. The same rule governs agent access: a Process exposed through an MCP Trigger becomes a callable tool, and which clients may call it is decided by API policy, evaluated per call. A client asking what tools exist receives only the tools it is authorised to invoke. Denial by default is the setting, not a configuration a customer has to remember to apply.

One audit trail, not three. Process executions, API calls and agent tool calls resolve to the same record, inspectable shape by shape, with every configuration change logged. This is the point of chapter five in concrete form. An organisation running a separate agent gateway alongside an integration platform has two records and a seam between them. Here there is one, because the tool call and the integration call are the same call.

We are publishing this because a document arguing for auditability that does not audit its author is worth very little.

Frends is delivered in three ways. The standard cloud service runs on Microsoft Azure. From the end of September 2026, Frends Sovereign Cloud runs from a StackIT data centre in Frankfurt, with no US entity anywhere in the operating or ownership chain, delivered on a separate .eu deployment. And the full platform, control plane included, can be deployed on customer infrastructure, including air-gapped.

Those are three different answers to the four tests, and pretending otherwise would be the sovereignty washing described in the previous chapter.

Locus of execution — pass, in every configuration. Frends Agents run in cloud, on-premises, in containers, distributed, or fully air-gapped with local AI models. Integration data moves between Agents; only execution statistics and telemetry reach the control plane. The Ground Agent connects to on-premises systems without exposing them to the internet, over outbound-only connections. Execution can be placed entirely inside a network the customer controls, whichever control plane they use.

Continuity under compulsion — fails on the standard service, passes on the sovereign tier. A customer running the standard Frends Cloud is running a control plane on infrastructure operated by a company under US jurisdiction. We are not going to describe that as sovereign, because it is not. Frends Sovereign Cloud is operated from Frankfurt on StackIT, which sits within Schwarz Digits, part of the privately held German Schwarz Group. There is no US parent, no US operating entity and no US legal reach into the chain. On-premises deployment passes for the same structural reason.

Evidentiary control — follows the same line. The audit trail is complete and customer-readable in every configuration. Who holds it differs. On the standard service it resides in an Azure-hosted control plane. On the sovereign tier and on-premises, it stays within infrastructure the customer or a European operator controls.

Reversibility — pass, with one qualification, in every configuration. Processes are built in BPMN 2.0, a published standard. Connectors are open source. The underlying .NET code is directly accessible. Pricing and roadmap are public. The qualification is honest: process definitions and the task library are Frends-specific, so migration away is real work rather than an export. Reversibility here means the exit is documented and executable, not that it is free.

Three gaps remain, and a customer who buys the tier believing otherwise will be wrong about something that matters.

The technology stack is still Microsoft. Frends Processes compile to C# and run on .NET. Moving the operator from Azure to StackIT resolves the operational dependency and leaves the technological one intact. Against the three-layer model in chapter two, that is one layer solved and one only partly. We think the operational layer is where the acute risk sits, because that is the layer a legal order acts on. But we are not going to claim we have solved a layer we have not.

No framework exists to certify any of this. CADA is a proposal in trilogue. There is no audit, no recognition, and no level any provider can hold today. Frends Sovereign Cloud is designed against the criteria in the proposal. It does not hold a level, because no level exists to hold, and any vendor telling you they have one is describing something that has not been created yet.

And the weakest link is the one furthest from us. This is the important one.

A customer running Frends Sovereign Cloud has a European control plane, European execution and a European audit trail. If a Process on that platform contains an AI Connector pointed at a model API operated in the United States, then at the moment that Connector fires, the inference data leaves the sovereign chain. The runtime is sovereign. The inference is not.

Frends is model-agnostic and supports local models, including in air-gapped deployment, so this is a configuration choice rather than a platform limit. But it is the most likely real-world failure of everything described in this chapter, and it will happen to organisations who believe they have bought their way out of the problem. The chain is only as sovereign as its weakest hop.

Our connector library is smaller than the largest global platforms. Our partner ecosystem is smaller. We are a European vendor with European scale and we have no interest in pretending otherwise.

We also do not claim that choosing a European vendor solves sovereignty. It removes one category of exposure. It does not remove exposure introduced by the technology stack, the models called from inside a process, or the systems being integrated. The four tests apply to the whole chain. A customer who applies them rigorously will find gaps in every stack, ours included. Finding them is the point.

The argument of this paper is not that Europe should build everything itself. It should not, and it cannot.

The argument is that Europe has spent five years debating where its data sleeps, while the decisions that run its hospitals, grids, banks and public services migrated into an automation layer that nobody placed under jurisdiction. That layer is now about to be handed to agents. The compliance dates have started passing. The gap between sixty-one percent and twelve percent is the size of the exposure.

For CIOs and technology leaders. Classify your integration estate by consequence of compulsion before you classify anything else. Ask the four tests of every platform in your stack, including the ones you already own. Treat control-plane portability as a procurement requirement rather than a technical curiosity. Trace the full chain to the model call, because a sovereign runtime calling a foreign model is a chain with a hole in it. Build the layer before you scale the agents, because the organisations that worked in that order are the ones showing measurable AI returns.

For vendors, ourselves included. Publish where you fail. The market is full of sovereignty claims that dissolve on inspection, and the fastest way to be trusted in a market like that is to be inspectable. State your jurisdictional exposure in your own words before a competitor states it in theirs, and put your price next to it.

For policymakers. Assurance levels are a genuine advance, because a scale with numbers on it is something a buyer can specify. But cloud infrastructure is not where European decisions are executed. The orchestration and integration layer is, and it currently sits outside the framework’s field of view. There is today no way for any provider to be certified on where automated decisions are carried out, who holds the evidence of them, or whether they continue under compulsion. A regime that certifies where data rests and says nothing about where decisions are executed will have certified the easier half of the problem.

Europe does not need to own the whole stack. It needs to be able to choose, and to change its mind, without rebuilding the business each time. That is what optionality means, and it is built at the runtime layer or it is not built at all.

Jukka Rautio, Chief Executive Officer