I expect sovereign AI to become an increasingly important platform requirement as organisations move from asking models questions to allowing agents to perform work.
The opportunity is to run useful agentic workflows in a controlled data centre or on premises, with clear authority over the data, execution and operation of the system. A locally hosted model is one component of that capability. The platform around it determines whether the organisation can actually keep control.
Nestor Dubnevych's LinkedIn post about sovereign AI in the legal sector prompted this article. His post includes reports and allegations that I have not independently verified. I am using it to frame the architectural question, without treating those claims as established evidence of data misuse or an industry-wide migration.
There is a strong engineering case to examine on its own: what would it take for an organisation to operate a complete agentic workflow within a boundary it chooses and can enforce?
Define what control means
For this discussion, I use sovereign AI to mean an organisation's ability to govern where an AI system runs, who can access it, how it acts and which external dependencies it accepts. That is an operational definition, rather than a claim of absolute independence or a legal certification.
The deployment choices need precise language:
- On premises describes where infrastructure is installed. It can still depend on external model APIs, identity services, telemetry or licensing checks.
- A controlled data centre can be operated by the organisation or an approved provider. The important questions include administrative access, keys, network paths, contractual responsibilities and applicable jurisdiction.
- Air-gapped operation requires isolation from external networks and a controlled process for bringing in software, models and updates. It is a stronger requirement than placing servers in a private room.
Cloud use also does not automatically mean that customer data trains a provider's models. For example, OpenAI states that business data from its business offerings and API platform is not used for training by default. Training use, retention, administrative access and operational dependence are separate questions. A sound deployment decision examines each of them.
Follow the work beyond the model
Consider an illustrative contract-review workflow. An agent retrieves an agreement and an internal playbook, identifies deviations, drafts proposed changes, obtains approval and saves a new version to the document system.
Serving the language model locally covers only one part of that journey. Document parsing might call an external service. Embeddings might be generated elsewhere. A tracing service might receive excerpts. An approval screen might depend on a hosted control plane. A tool might have broader document access than the person who started the request.
I would map the complete path before describing the workflow as sovereign:
| Part of the workflow | Control the platform must make explicit |
|---|---|
| Models and document processing | Where inference, OCR, embeddings and reranking run; which artefacts must be available locally |
| Retrieval and tools | Which records each user and agent can read or change, with permissions enforced by the receiving service |
| Orchestration and state | Where runs, checkpoints, queues and approvals persist; how interrupted work resumes |
| Evidence and operations | Where prompts, outputs, tool results, traces, backups and support bundles are stored or sent |
| Administration and lifecycle | Who can change policy, deploy models, rotate keys, install updates and recover the system |
The boundary has to include the management services as well as the services processing requests. A local execution engine that needs a remote service to start new runs has a different continuity property from a fully local installation.
Deployment options exist; their conditions matter
There are concrete building blocks for this approach.
NVIDIA's NIM documentation describes air-gapped inference: prepare model assets in a connected environment, transfer them through an approved channel, and run the container using local assets without outbound access. That establishes a documented path for the inference layer. It does not, by itself, establish that a surrounding agent workflow is disconnected or secure.
LangChain documents self-hosted LangSmith on an organisation's Kubernetes infrastructure, with optional deployment and agent-platform capabilities. It is an Enterprise offering with feature-specific prerequisites. Its egress documentation distinguishes ordinary self-hosting from offline operation: standard installations require outbound billing and licence verification, while running without egress requires an offline licence. Optional telemetry and selected model-provider paths also need review.
These are documented capabilities and constraints, not a comparative product recommendation or a claim that I have validated those configurations. They illustrate why procurement should ask for the exact deployment mode, feature set and dependency list. “Self-hosted” alone is an incomplete answer.
For a platform intended to run fully inside a controlled environment, I would expect local deployment options for orchestration, state, identity integration, secrets, model serving, observability and the tools required by the chosen use case. Any remaining external dependency should be named and tested against the organisation's requirements.
Local execution still needs bounded authority
An agent running in your own data centre can still perform the wrong action with excessive permissions. Network location does not establish trust. NIST's Zero Trust Architecture guidance explicitly rejects implicit trust based solely on physical or network location or ownership.
For the contract example, I would enforce matter-level access at retrieval time and again when tools read or write documents. Approval should bind to the particular revision and action being authorised. A changed draft should not inherit approval for an earlier version.
The platform should record the evidence, policy version and approval associated with an action. It should also distinguish instructions from the user from untrusted content retrieved from a document. OWASP describes indirect prompt injection through external files and recommends least privilege and separation of untrusted content. Moving the model closer to the data does not remove that risk or make broad tool credentials appropriate.
These controls are part of the platform design. They need to survive model changes and new workflows.
Test independence through the operating lifecycle
A useful acceptance exercise is to remove external access in an authorised test environment and run a representative workflow from beginning to end. Then restart the services and run it again.
That second step matters. A warm demonstration can conceal a dependency on downloading weights, obtaining a token or contacting a licence service during startup.
I would extend the exercise to a worker failure, an approval pause, a backup restore and a controlled model update. Check that work resumes correctly, permissions still apply and repeated execution does not duplicate an action. Where a dependency is deliberately external, test the agreed degraded behaviour and recovery path.
Disconnected operation also needs a maintenance process: approved software and model imports, provenance checks, vulnerability handling, evaluation before promotion and a reliable rollback. An isolated installation that cannot be maintained is a weak long-term proposition.
The commercial assessment belongs alongside those tests. Local deployment brings responsibility for capacity, hardware, patching, storage, recovery and skilled operators. Compare the cost and quality of completed workflows under representative load. A model that fits in memory has not yet demonstrated that it can meet the required service level.
The platform opportunity
I see a substantial opportunity for platforms that make this operating model practical: agentic workflows that can be deployed, governed, observed and maintained inside the organisation's chosen environment.
The strongest offer would combine useful automation with an explicit account of its dependencies. It would let the customer decide what may cross the boundary, enforce that decision and retain the capability to operate and evolve the system.
That is the standard I would apply to sovereign AI: demonstrate control over the complete workflow, including the day it fails and the day it needs to change.
Sources
- Nestor Dubnevych's LinkedIn post, read October 28, 2026: the discussion that prompted this article; its allegations are not treated as verified facts.
- OpenAI, Enterprise privacy, updated January 8, 2026: published business-data training commitments.
- NVIDIA NIM, Air-Gap Deployment: preparation and operation of offline inference.
- LangChain, Self-hosted LangSmith and egress requirements: deployment scope, licensing and outbound dependencies. Documentation checked October 28, 2026.
- NIST SP 800-207, Zero Trust Architecture, August 10, 2020: resource protection without implicit trust based on location.
- OWASP, LLM01:2025 Prompt Injection: indirect instructions in retrieved content, least privilege and mitigation limits.