“The model runs on our infrastructure.”
It is a useful statement. It identifies where inference happens. It does not establish who governs the knowledge the model receives, which identity may invoke it, what information leaves the environment, which tools it can reach, or who controls the system’s state and operation.
Locality is one coordinate in a sovereignty assessment. A defensible claim needs to describe the other controls around it.
The European Commission’s 2026 Cloud Sovereignty Framework offers a useful, bounded example. In a cloud procurement context, it assesses 48 criteria across eight categories, including legal and jurisdictional matters, data and AI, operations, supply chain, technology, security and compliance, and environmental sustainability. The framework is not a universal definition of sovereign AI. Its relevance here is narrower: even a cloud-sovereignty assessment is expressed through multiple dimensions, rather than a data-centre address alone. [1]
Residence: where does inference happen?
The first question is still important: where are the model, runtime, and supporting services executing?
Running inference locally can reduce dependence on an external inference endpoint. It can also support workloads that require tighter control over network connectivity or operation without an external AI service. Those are meaningful architectural properties.
They do not automatically settle how the system behaves. A locally hosted model may still depend on remote licensing, external telemetry, vendor-managed updates, remote administration, or other services. A local deployment may also operate inside an environment with broad administrator access or weak separation between users and services.
The deployment boundary needs to be stated precisely. “Local” could mean a customer-controlled server, a managed private cloud, a hosted environment in a particular jurisdiction, or a machine disconnected from external networks. Those descriptions establish different conditions. A local model is evidence about model execution location; it is not, by itself, evidence about the rest of the environment.
Control: what does the system know, and what can it reach?
Knowledge
An AI system acts on more than model weights. It receives documents, structured records, classifications, context, and sometimes information inferred from previous activity.
Institutional control therefore includes the ability to govern which sources are authoritative, how knowledge is structured, how provenance is retained, and how access restrictions affect retrieval and use. If a model is local but the knowledge it consumes has unclear ownership, untracked updates, or uncontrolled access, locality has not resolved those questions.
The same applies to generated results. An organization needs to know how outputs are associated with their sources, where they are retained, and whether they can affect records used in later decisions.
Identity
A system has several identities to distinguish: the human requesting work, the service assembling context, the inference runtime, and any tool or external service involved.
NIST’s Zero Trust Architecture states that physical or network location alone does not establish implicit trust. Authentication and authorization are separate functions performed before access to a resource. [2] Applied to AI systems, this means that being inside a private network does not answer which human or service may read a record, invoke a model, or call a tool.
Identity and permission checks need to be enforced at the resource and action boundaries. A model’s interpretation of a user’s request cannot substitute for those checks.
Inference and data egress
The inference path includes more than the final prompt. Depending on the architecture, information may travel through context assembly, embedding services, model requests, tool results, logs, telemetry, diagnostics, caches, backups, and support channels.
A useful assessment identifies which of those paths exist, what information each can carry, and which ones cross the approved boundary. The answer may differ between deployments and workloads. For a system that permits external inference, the provider, model, configuration, data sent, and governing controls should be explicit. A switch to an external runtime should not happen as an invisible recovery action.
This is where “the model is local” and “the system is controlled” diverge. The first describes a component. The second requires evidence about the routes and services surrounding it.
Tools and state
A model can propose a tool call or recommend a transition. The governed system determines whether that call is permitted and whether the requested state change is valid.
Tool access should be scoped to the identity and task that require it. State changes should be handled by the system that owns the relevant workflow or record, with validation and provenance appropriate to the consequence. Generated text can inform a decision; it should not acquire operational authority merely because a model produced it.
Authority: who can change or stop the system?
Sovereignty has an operational dimension: who may select or update a model, change routing, revise policies, grant permissions, inspect events, suspend a capability, or recover from a failure?
A system can run locally while depending on another party for critical changes or incident response. Those dependencies may be acceptable. They should be identified and governed rather than obscured by the location of the model.
The NIST AI Risk Management Framework provides relevant guidance on this wider system view. It treats governance as a continuing function across the AI lifecycle and calls for documented roles, accountability, human oversight, and attention to risks from third-party software, hardware, and data. It is a voluntary AI risk-management framework, not a sovereignty certification. [3]
Operational authority also needs a human owner. Someone in the institution must be able to understand what the system is permitted to do, review significant changes, respond to incidents, and decide when a capability should be suspended. If those responsibilities are unclear, local execution alone cannot supply them.
CARM’INK’s bounded position
CARM’INK SEE, the Sovereign Execution Environment, is designed around preserving institutional control over data, access, and execution. Its target architecture brings together a formal semantic layer, governed documentary handling, provenance, controlled inference, and explicit operational boundaries.
Local CPU or GPU inference can support institutional control. External inference requires an explicit configuration decision. Neither statement means every deployment is air-gapped, every dependency is institution-controlled, or every legal and supply-chain question has been resolved. Those conclusions depend on the deployment, workload, contracts, configuration, infrastructure, and operating responsibilities.
That distinction matters. CARM’INK’s position is architectural: sovereignty should be assessed across the controls that govern what the system knows, which identities it recognizes, where inference occurs, what information moves, what actions are permitted, how state changes, and who remains accountable.
Make the claim match the evidence
A sovereignty statement should name its scope.
A deployment may be able to establish that inference runs on customer-controlled infrastructure. A separate network review may establish that specified external routes are blocked or permitted. An access review may establish which identities can retrieve knowledge or invoke tools. Operational records may establish who can change the runtime or suspend it.
Each finding supports a specific claim. Together, they can support a broader assessment of institutional control. The exact wording should follow the evidence available for that deployment.
Model locality tells us where inference runs. Sovereignty is demonstrated by control over the knowledge, identities, routes, actions, state, and operational decisions that surround it.
References
- European Commission, Directorate-General for Digital Services, “Sovereign Cloud Framework explained”, 1 June 2026.
- National Institute of Standards and Technology, SP 800-207: Zero Trust Architecture, 11 August 2020.
- Elham Tabassi, National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0), 26 January 2023.