The Bottom Line
Data sovereignty is a runtime control problem as well as a storage problem. Local ownership, residency, and zero-copy access constrain where evidence resides and who may reach it, but they do not establish who may convert that evidence into an operational effect. A defensible sovereignty architecture evaluates the decision boundary: the point where a system approves, denies, or escalates an action. At that boundary, it should be possible to show the evidence used, its freshness, the policy in force, the authority invoked, and the record of what happened next.
That standard matters most when an AI system crosses from recommendation into action. An answer, a ranked case, and a proposed course of action can inform human judgment. A shipment block, containment order, external notification, or command to a control system changes the world. Treating those acts as ordinary outputs of a governed query leaves the decisive question unanswered: who had the authority to cause that effect, under which rule, with what opportunity for human intervention?
The practical implication is straightforward. Sovereignty should be assessed where evidence becomes effect, not only where a table is stored or a model retrieves context.
Storage control answers where evidence resides
Storage placement remains a serious form of control. It can determine which legal jurisdiction applies, who owns the underlying files, which lifecycle rules govern them, and which infrastructure carries the risk of a compromise. The value of those controls should not be minimized.
Databricks describes its Unity Catalog managed tables as retaining data in customer-owned cloud storage, with placement configurable at metastore, catalog, or schema level. Its guidance on managed-table storage presents a concrete model for keeping location and lifecycle choices under customer control. That is meaningful evidence of data locality. It is not, however, evidence that every downstream action is authorized.
Consider a quality signal. The source data may stay inside a permitted regional environment. A model may read it through an approved identity. Yet the proposed effect can vary sharply: flag a case for review, pause a production step, quarantine inventory, notify an external body, or instruct another system to act. Storage controls do not decide among those effects. Unless storage controls are explicitly integrated with a decision-policy layer, a database cannot determine whether a temporary signal is fresh enough for a halt, whether the relevant mandate has expired, or whether a person must approve an escalation.
This distinction is not a criticism of local storage or governed catalogs. It is a boundary on what they prove. Location answers where evidence sits. It cannot, on its own, answer whether an effect is allowed now.
That gap grows when a system has tools. An agent with read access can produce a recommendation. An agent with a tool credential can also create, amend, or transmit something beyond the original data boundary. The architecture must therefore preserve control after retrieval, not stop its reasoning at retrieval.
Governed access does not settle operational authority
Zero-copy access reduces unnecessary replication, but it does not settle operational authority. A system can legitimately read distributed evidence while lacking permission to commit any particular action derived from it.
The shift toward distributed access is real. Databricks describes OpenSharing connections as a way to expose on-premises, private-cloud, and edge data to governed workloads without replicating the underlying data. Its Storage Ecosystem announcement frames this as centralized governance across distributed storage. The open protocol described in its OpenSharing release also makes clear why location no longer requires a central copy.
That is an important architectural improvement. It may preserve local custody and reduce duplicated data. But a permitted query is still only a permitted query. It does not carry a general power to create an effect in another system.
The distinction becomes visible in cross-domain analysis. A manufacturing data analysis describes connecting design, production, quality, supply, logistics, and service context to support traceability and corrective action. That shared context can make a recommendation better informed. It does not determine which corrective action is lawful, proportionate, or within the mandate of the actor holding the tool.
Centralized ontology platforms and export-into-the-lake designs can organize context well. Their weakness appears when organizational meaning is mistaken for authority. A unified model may show that a component, a production batch, and a field report are related. The model does not itself establish who may halt a line, send an external notification, or override a local rule. Those are decisions made under authority, not properties discovered in data.
Three controls answer three different questions
Data locality concerns where the underlying evidence is held. Governed access concerns who may discover, read, or share that evidence. Decision control concerns whether specific evidence may cause a specific effect at a specific time under a defined authority.
The three layers belong together, but they cannot substitute for one another. A mature design makes the boundary between them explicit, because each leaves a different question open.
The model is deliberately stricter than a data-management checklist. Decision control cannot prove that an underlying policy was wise, lawful, or complete. It can make its application inspectable. That is the necessary condition for contesting an action after the fact.
The decision boundary follows operational authority
The decision boundary should sit where authority can be applied and accounted for. It need not follow the place where all data is aggregated. In some cases it may be close to a production system. In others it may be in a regional environment, an edge location, or a separated network. The architectural question is not where a diagram looks most elegant. It is where the relevant policy, credentials, and human oversight can govern the act.
Return to the quality signal. A local environment may be able to classify a signal and recommend that a batch receive attention. A line-halt action may require a different authorization path. An external notification may require another one again. The same evidence can travel through several decision classes without granting the first class the authority of the last.
This is where human moral agency becomes concrete. Human-in-the-loop accountability does not mean placing a person beside a button after an automated system has already framed every material option. It means preserving a meaningful chance to assess the evidence, the policy basis, and the consequence before an irreversible or high-consequence effect occurs. The NCSC's guidance on intelligent security tools warns that handing actions to intelligent tools can remove timely human intervention and calls for clear accountability for tool-influenced decisions and actions.
The point extends beyond cyber security. NATO's Principles of Responsible Use for AI include lawfulness, responsibility and accountability, explainability and traceability, reliability, and governability. Those principles are not implementation details. They describe the qualities required when a machine-assisted decision has consequences that cannot be excused as a database event.
For an after-action reviewer, the standard is demanding. The reviewer needs more than a final result and a model trace. They need to establish which evidence version was available, which authority was active, whether the policy check passed, who approved or overrode the recommendation, which tool was invoked, and whether the effect was actually committed. Without that chain, review becomes reconstruction by inference.
Can AI agents act without centralizing data?
Yes, an AI agent can act without centralizing data, but only if the action path is controlled independently of the retrieval path. Local or federated evidence can support a recommendation while the authorization to commit an effect remains at the decision boundary.
The agent must therefore treat recommendation and effect as different control classes. Recommendation can be broad enough to surface context, uncertainty, and alternatives. Effect needs a narrower contract. Before a tool invocation can commit a consequential action, the runtime should evaluate at least these conditions:
- the evidence satisfies the freshness rule for that action;
- the identity invoking the tool holds the required authority;
- the policy currently in force permits the action and its scope;
- the tool is restricted to the approved operation and target;
- the commit result is recorded, including denial, failure, or escalation.
These checks should be durable rather than conversational. A prompt may state a constraint, but a prompt is not an enforcement point. Context windows can be shortened, instructions can conflict, and a model can produce a plausible rationale for an impermissible action. The NCSC's guidance on agentic AI advises proportionate autonomy, active oversight, logging, attribution, and the ability to stop an agent. It also distinguishes human-in-the-loop, human-on-the-loop, and human-out-of-the-loop operating models.
The required human role depends on the action, not on a generic preference for manual review. A recommendation to inspect a case may accept a lower threshold. A decision that changes a physical process, affects an external party, or uses force needs a higher standard of control. The UN's analysis of human control in weapons systems links human control with predictability, reliability, international humanitarian law, and accountability. Its context is specific, but the underlying lesson travels: a system should not be called controlled merely because a human was somewhere in its workflow.
Replay is an accountability mechanism
Replayability is the ability to reconstruct a decision from the evidence, rules, authority, and execution result available at the time it was made. It does not prove that the decision was correct. It makes the decision available for challenge, investigation, and correction.
This distinction prevents a common mistake. A log of the final tool call is not a decision record. It may show that a tool executed. It does not show why the system believed execution was allowed, whether the underlying evidence was stale, or whether a conflicting policy was evaluated. A model transcript has the opposite weakness. It may show reasoning-like text while omitting the identity, authorization, and state transition that made the effect real.
A decision record needs both forms of evidence. It should attach the source lineage and version, the freshness assessment, the policy identifier and evaluation outcome, the acting identity or delegated mandate, the requested effect, any human approval or override, and the committed result. The record also needs a stable correlation between the recommendation and the effect. That correlation makes a denial legible rather than appearing as a missing action.
Verification matters because consequential systems can fail in ways that are hard to see from their outputs. CSET's work on verification mechanisms and limits on AI decisions explains why verification mechanisms and limits on AI decisions matter in critical national-security systems. Its analysis is not a template for every commercial workflow. It is a clear warning against treating apparent system competence as proof of acceptable control.
The same conclusion follows from the law of armed conflict as analyzed in the UN's human-control framework. In high-consequence settings, accountability cannot be satisfied by a post-hoc claim that a model processed the available data. The question is whether a responsible human or institution retained a traceable basis to authorize, constrain, and review the use of the system. CSET's analysis of responsible and ethical military AI applies meaningful human control beyond weapons to intelligence, surveillance, planning, and decision support. The wider relevance is that moral agency requires a real decision point, not ceremonial approval after the fact.
Sovereignty requires a runtime for effect
Sovereign Decision Fabric is Scalytics' proposed architectural term for a pattern that keeps context, freshness, policy, authority, lineage, and replay attached to a decision from event through effect. The term describes a control plane for actions, not another place to centralize every source dataset.
That distinction matters in distributed environments. Evidence can remain in local systems while a decision runtime requests only what the proposed action needs. It can evaluate policy near the authority that owns the effect. It can deny an action without exporting the complete underlying corpus. And it can persist a decision record that names the evidence and rules used without pretending that one global ontology owns every fact.
The Sovereign Decision Fabric category is useful as a vocabulary for this separation. The technical challenge is not simply to connect an agent to more context. It is to make the transition from context to effect constrained, attributable, and replayable.
There are real limits. A decision fabric cannot repair ambiguous mandates, poorly written policy, missing source lineage, or human review that is too rushed to be meaningful. It cannot make an unreliable sensor reliable. Nor can replay turn a harmful action into a justified one. These are governance and operational problems that technology can expose but not resolve.
Still, the architecture can force the right question into view. When a system proposes a consequential action, can its owner identify the current evidence, the active rule, the authority that allowed it, the person accountable for intervention, and the committed result? If the answer depends on reconstructing several disconnected logs after the event, sovereignty remains an aspiration rather than a control.
The policy position worth defending is therefore precise: data may remain local, access may be governed, and analysis may be federated. Yet sovereignty is incomplete until the authority to turn evidence into an effect is equally local, governed, and reviewable.
About Scalytics
Our founding team created Apache Wayang, the federated execution framework that lets computation run where the data lives and dramatically reduces unnecessary data movement.
We also built and maintain kafSCALE, a high-performance, Kafka-compatible streaming platform designed for Kubernetes and object storage. It delivers elastic scale without broker complexity or lock-in.
Our mission: Keep data in place. Bring compute to the data. Enable secure, sovereign, and production-ready AI operations.