Sovereign AI

The advantages of distributed processing are frequently described in terms of scale. For a ministry, agency, or programme office, the more consequential advantage is the ability to keep a decision close to the data, authority, and operational context that make the decision legitimate. Distributed processing should therefore begin as a topology decision, not as a late-stage technique for increasing compute capacity.

That distinction matters when data is already spread across operational commands, partner organisations, secure environments, national boundaries, and different legal authorities. Moving every record into a single analytical estate can simplify one view of the world. It can also create a new concentration of jurisdictional exposure, replication duties, transfer cost, and dependency on the party that operates the central control plane. The fact that a platform can ingest data does not settle whether it should.

The policy question is not whether central systems have a place. They often do. It is whether centralization has been treated as a presumption before anyone has shown that it is necessary for the mission outcome. A no-egress discipline starts from the opposite presumption: process governed data where it is held, move only the minimum result or approved event, and make every exception explicit.

This is not a claim that federation removes institutional friction. It makes that friction visible. The European data strategy frames access, reuse, and interoperability as policy concerns alongside data availability. The NIST AI Risk Management Framework similarly treats governance and measurement as continuing functions, rather than a one-time technical approval. A processing architecture should make both possible when an agent, analyst, or automated service crosses organisational boundaries.

‍

Compute placement is the wrong first question

Many programmes inherit a batch-era sequence. First select a central lake, warehouse, ontology, or AI platform. Then establish feeds from every source. Finally, distribute workloads when the central environment begins to strain. That sequence treats topology as an implementation detail. In a sovereign setting, topology is part of the policy decision because it determines which party copies data, who can inspect it, which jurisdiction receives it, and how an action can later be explained.

The more useful opening question is: what information must move for this decision to be made, and what information may remain where it is? That question separates a request for a common operating picture from a request for universal data possession. The two are often conflated. A commander may need an approved risk indicator, a confidence statement, and the source system's provenance without needing an enduring duplicate of every underlying record in a central environment.

This reframing also clarifies the limits of a centralized ontology. A common model can be helpful for the entities that genuinely need shared meaning. It becomes a poor default when its adoption requires every institution to export source data first, or when the model becomes the only permitted route to operational action. The result is an architecture in which a local change waits for central ingestion, transformation, permissioning, and publication before it can inform a local decision.

For leaders, the issue is accountability. A central platform may offer a clean dashboard while obscuring which source authority remains responsible for a record and which transformation changed its meaning. A topology-first review asks for those boundaries before it accepts a dashboard as proof of integration. It does not reject integration. It insists that integration preserve the authority needed to defend a decision.

‍

Data topology is the first architecture artifact

Before approving processing technology, a programme should require a map of the data and execution boundaries it intends to govern. This is not a network diagram decorated with application logos. It is a decision artifact that records where information originates, which authority owns it, what classification and retention rules apply, where an execution runtime may operate, and which movements have a stated mission purpose.

The minimum map should distinguish four things that are routinely collapsed into one box:

‍

• the system that is authoritative for a fact
• the environment in which that fact may be processed
• the party permitted to receive a derived result
• the audit record that explains how the result was produced

‍

Once those distinctions exist, centralization can be judged against a concrete purpose. Some data will need to be brought together for cross-domain planning, model training under approved controls, historical analysis, or statutory reporting. Other data can support a local decision through a query, a signed event, or a narrowly scoped model invocation. The architecture should make those two paths visibly different.

‍

‍

This approach is consistent with the security guidance in the UK National Cyber Security Centre's machine-learning collection, which places secure design and operational considerations around machine-learning systems rather than treating the model as an isolated object. It also gives procurement teams a better test of a proposed platform. Instead of asking whether a supplier supports federation in principle, ask whether a component can execute in the governed environment, retain source provenance, and produce an auditable output without exporting raw data by default.

The topology map should be maintained as policy changes, not filed with the initial business case. New partners, model providers, and agent runtimes alter the map. So do new links between classifications or regions. Treating the map as living governance prevents a programme from discovering, after deployment, that its most sensitive data path was created by an apparently minor integration.

‍

Federation changes the economics of processing

Federation is not a refusal to coordinate. It is a design in which coordination does not require universal replication. A federated plan can place an operation near an approved source, return a constrained result, and compose that result with others under a separate policy. The principal gain is decision control: each movement becomes a choice that can be justified, rather than a side effect of adoption.

Apache Wayang illustrates the technical premise. Its planning model separates application logic from platform-specific execution and allows an optimizer to choose operators across heterogeneous engines. The significance for leadership is not the framework itself. It is the proof that a workload need not be bound to one execution engine merely because its inputs are distributed. The planning problem includes the cost of movement as well as the work performed at each location.

That is a more demanding model than a federated query layer alone. Query federation can leave action, model execution, agent permissions, and evidence capture outside its scope. A governed execution model must carry those concerns with the work. In-situ execution means running an approved computation inside, or directly adjacent to, the environment that governs the source data, then releasing only the permitted output.

We describe a Sovereign Decision Fabric as an architecture that coordinates data, agents, and actions across governed environments while keeping authority, execution, and audit evidence attached to each decision. The Scalytics Sovereign Decision Fabric is relevant here as a concrete approach to that architectural posture, not as a substitute for a programme's own sovereignty policy.

‍

The comparison is not a ranking. It is a reminder that each posture makes a different commitment. A programme that selects the first or second posture by default should be able to defend why raw movement, rather than constrained execution, is necessary.

‍

Can AI agents run without centralizing data?

Yes. AI agents can operate across governed environments without centralizing all underlying data, provided the programme defines local tool permissions, result contracts, and audit records before allowing the agent to act. The agent does not need universal read access to coordinate a mission workflow. It needs a controlled way to ask an authorised local capability a specific question and receive a result that has policy-defined meaning.

This requires a different model from the common pattern of placing an agent beside a large central corpus and treating access to the corpus as the agent's intelligence. An agent may instead be a coordinator. It can route a request to a local analytic service, invoke a policy-constrained search, or request an attested summary. The local environment retains discretion over data access, filtering, and retention. The coordinating layer retains an account of the request, authority, and response.

The NATO data and artificial intelligence strategy links responsible use of data and AI to interoperability, protection, and trust among allies. Those requirements make the boundary around an agent's access more important, not less. An alliance can share mission-relevant results without assuming that every participant should expose identical data stores or adopt a single foreign-jurisdiction control plane.

This model has hard limits. An agent cannot synthesize evidence it is not permitted to receive. It may make poorer recommendations when a needed source cannot provide an approved derivative. Some tasks, particularly model training and long-horizon pattern analysis, may require a deliberately created common data environment. These are reasons to specify the exception, including its retention and review conditions. They are not reasons to make wholesale export the unexamined baseline.

The operational test is whether an agent's proposed action can be reconstructed. Decision-makers should be able to identify the request, policy authority, local system that evaluated it, data version or event reference, model or ruleset involved, and recipient of the result. Without that chain, an agent architecture has centralized risk even when its infrastructure is physically distributed.

‍

Observability is part of command and control

Once work crosses runtimes, a single platform console cannot be assumed to provide a complete account. The control-plane requirement is to correlate an operational request across local services, event streams, model calls, and human approvals without turning observability into another uncontrolled export channel.

OpenTelemetry's trace model provides a useful foundation: a trace is a path through an application, while context propagation allows spans from different processes, services, virtual machines, and data centres to be assembled into that path. The policy implication is straightforward. A trace identifier and associated evidence should travel with an approved request even when the payload does not. That gives an oversight body a way to ask what happened without demanding unrestricted access to every underlying source.

For a programme office, observability should answer four questions in a form that can be reviewed after the fact:

‍

1. Which authority approved the request and the purpose for which it was made?
2. Which local runtime received it, and under which policy version?
3. What output, refusal, or error was returned?
4. Which subsequent action relied on that output?

‍

This is also where event-driven processing can help. Apache Kafka's documentation on Streams describes processor topologies, stateful operations, and processing guarantees. In policy terms, an event record can serve as a durable boundary between domains if its schema carries provenance and its handling rules are explicit. It should not be mistaken for a universal audit solution. Event retention, consumer access, and replicated state remain governance decisions.

Programmes should avoid the false choice between a single operational picture and local accountability. A shared trace and a shared decision record can offer the first while preserving the second. The objective is a defensible account of execution, not a claim that every system has been absorbed into one console.

‍

Egress must be approved as an operational cost

Network egress is often delegated to finance after architecture approval. That is too late. Data movement across regions, clouds, or organisational boundaries can change the cost of a service and expand the set of systems that must be accredited, monitored, and defended. It should be treated as a requirement at the same stage as availability, latency, and classification.

The provider documentation makes the point without requiring a speculative cost model. AWS explains how data-transfer charges appear in its Cost and Usage Report. Azure publishes distinct bandwidth treatment for inbound, inter-region, and outbound traffic. Google Cloud documents network charges by traffic path and geography. The rate cards vary, but the governance lesson does not: an architecture that moves data by default has accepted a recurring dependency whose economics and jurisdiction can change.

No-egress discipline does not mean that no data ever leaves a boundary. It means every material flow receives a purpose, an owner, a receiving environment, a retention rule, and a test for whether a smaller derivative would meet the need. A summary, aggregate, risk score, signed event, or denial message may be sufficient. If raw export is required, that decision should be visible in the architecture record rather than concealed inside a connector configuration.

This discipline also improves procurement. A supplier's nominal platform price cannot be assessed separately from the movement pattern its reference architecture assumes. The relevant question is not simply what the service costs to run. It is what flows must be sustained, copied, observed, and retained to make the service useful in the programme's actual topology.

‍

Centralization remains a choice that must be defended

There are sound reasons to centralize. An enterprise may need a governed historical repository for statutory reporting. A joint mission may require a shared data product with stable semantics. A model-training programme may require a carefully approved corpus. Where those needs are real, a central environment can reduce duplication of analytic work and establish common controls.

The trade-off is that centralization converts many local dependencies into one higher-consequence dependency. It requires clear rules for source correction, access revocation, schema change, retention, and continuity when a participating authority changes its posture. A closed single-vendor stack under foreign jurisdiction may be acceptable for some workloads and unacceptable for others. That conclusion should follow from the topology and mission, not from a platform's promise of unification.

Senior sponsors can make this judgement through a small set of decision checkpoints:

‍

• Is the mission outcome dependent on raw data centralization, or only on a common derived result?
• Which authority remains accountable when a source changes, is withdrawn, or is contested?
• Can the workload run locally with a defined result contract and a shared trace?
• What egress, retention, and jurisdictional commitments does the central option create?
• What evidence will allow an independent reviewer to reconstruct a consequential action?

‍

Distributed processing has advantages when it protects these decisions from being made accidentally by integration patterns. It is not inherently cheaper, simpler, or more secure. It introduces coordination overhead and demands mature interface governance. But it gives a public institution a way to make centralization an explicit act of policy, rather than the price of participating in a digital system.

The position worth defending is simple. Before a programme exports governed data into a lake or entrusts operational meaning to a centralized ontology, it should be able to answer why the decision cannot be made where the data already has authority. If it cannot, the architecture has selected convenience over sovereignty.