What Control Really Means for Government AI
By Frank La Vigne
AI sovereignty has become one of those phrases that sounds precise until someone asks what it actually means.
For one federal agency, sovereignty means keeping sensitive data inside accredited boundaries. For another, it means running open-weight models in a FedRAMP-authorized private cloud. In defense and intelligence settings, it may mean operating inside an air-gapped environment at IL5 or IL6. For a state CIO, it may simply mean avoiding dependence on a vendor that could change pricing, access, or terms in the middle of a contract.
Each interpretation contains part of the truth. None captures the whole picture.
I have come to think of AI sovereignty as a question of control rather than isolation. The goal is not to disconnect from the outside world or build every layer of the AI stack in-house. For most agencies, that would be impractical, expensive, and unnecessary to the mission.
The goal is to understand which parts of the AI system matter enough to control directly, which can be governed through policy and architecture, and which can safely be procured as a service.
That distinction changes the entire conversation.
The Sovereignty Illusion
There is a familiar picture of sovereign AI.
The data stays inside the agency. The models run on government-managed infrastructure. The GPUs sit in an agency-owned data center. The environment is tightly secured, and no sensitive information leaves the network.
From the outside, it looks like complete control.
Then the difficult questions begin.
- Where did the model weights come from?
- Who controls the update path?
- Which software dependencies must be downloaded from external repositories?
- Can the workload move to different hardware?
- What happens if a license changes?
- Can the agency reproduce the exact behavior of the system six months from now — for an Inspector General audit, a records request, or a court proceeding?
This is where sovereignty stops being a location question and becomes an architecture question.
An agency can keep every byte of data inside its own facility and still depend on a model provider it cannot inspect. It can deploy open-weight models while relying on a single cloud platform for orchestration, storage, and GPU access. It can own expensive accelerators without having a consistent way to allocate, monitor, or govern them.
Ownership at one layer does not automatically create control across the whole system.
That is the sovereignty illusion government leaders need to avoid.
Sovereignty Is a Stack
In Owning AI: The Sovereignty Stack, I describe AI sovereignty as a series of decisions across five layers: compute, data, models, applications, and governance.
Each layer raises a different question.
- At the compute layer, the issue is where workloads run, which hardware they depend on, and whether they can move.
- At the data layer, the issue is where information is stored, who can access it, how it moves, and which systems process it.
- At the model layer, the issue is who controls behavior, updates, versions, and deployment.
- At the application layer, the issue is where AI becomes embedded in real mission workflows.
- At the governance layer, the issue is whether the agency can enforce policy, reconstruct decisions, and assign accountability — the same expectations at the center of OMB’s AI governance guidance and the NIST AI Risk Management Framework.
These layers do not need the same ownership strategy.
An agency may reasonably use FedRAMP-authorized cloud compute while keeping sensitive datasets under direct control. It may use a proprietary model for low-risk tasks while deploying an open-weight model internally for high-impact or classified workflows. It may rely on commercial software while maintaining strict control over production deployment and model lineage.
The point is not to own everything. The point is to choose deliberately.
A dependency accepted with full awareness can be part of a sound strategy. A dependency discovered during an outage, an IG audit, a contract recompete, or a security incident is something else entirely.
But choosing deliberately only matters if the agency can act on its choices. That is where sovereignty shifts from architecture to operations.
Control Is an Operational Capability
This is where many discussions about sovereign AI remain too abstract.
Control is not a statement in a strategy document. It is something the agency must be able to exercise.
- Can a workload move from cloud infrastructure to an on-premises cluster?
- Can a team reproduce the experiment that produced a production model?
- Can infrastructure teams see where GPU capacity is being consumed?
- Can a model version be rolled back?
- Can the agency continue operating if an external service becomes unavailable?
These are not theoretical sovereignty questions. They are operational questions — the same questions that sit underneath continuity of operations planning and audit readiness.
They also reveal why AI sovereignty requires a control plane.
The average government AI environment is already fragmented. One program office uses cloud GPUs. Another runs Kubernetes on premises. A third uses a managed model API. Data scientists track experiments in one system, infrastructure teams manage clusters in another, and governance teams maintain policies in spreadsheets, catalogs, and ticketing tools.
Each group sees part of the system.
No one sees the whole.
That fragmentation creates dependency even when the underlying infrastructure is technically owned by the government. If the agency cannot observe, allocate, reproduce, or move the work, its control is limited.
Owning the engine does not help much if nobody can see the dashboard or steer the vehicle.
What a Sovereignty Control Plane Should Do
A sovereignty control plane does not need to replace every system in the agency stack.
It should not replace the data catalog, identity provider, security platform, compliance system, or application governance process. Claims like that may sound ambitious, but they do not reflect how large government organizations actually operate.
Instead, a sovereignty control plane should connect the operational parts of AI that are most likely to become fragmented.
It should give infrastructure teams visibility into compute resources and workloads. It should give AI builders access to governed environments without forcing them into slow, manual processes. It should preserve experiment history, model lineage, and reproducibility. It should allow workloads to run across different infrastructure environments — cloud, on-premises, and air-gapped — without requiring an entirely different operating model for each one.
Most importantly, it should integrate with the systems the agency already trusts.
That is where ClearML fits.
ClearML as the Operational Layer
ClearML provides a unified operational layer across AI infrastructure, development, orchestration, and model deployment.
It does not attempt to replace an agency’s data governance platform or become the security boundary for every application. Instead, it helps organizations manage the AI work taking place within those existing boundaries.
ClearML can orchestrate workloads across on-premises infrastructure, private clouds, government clouds, Kubernetes clusters, and air-gapped environments. That gives agencies a consistent way to manage compute while preserving the freedom to decide where particular workloads should run — including workloads that can never leave a classified enclave.
- For infrastructure teams, this means centralized visibility into resources, queues, scheduling, priorities, quotas, and utilization.
- For data scientists and AI engineers, it means self-service access to approved compute environments without requiring direct administrative control over the underlying infrastructure.
- For platform teams, it means experiment tracking, pipeline reproducibility, model lineage, and a more consistent path from development to deployment.
- For governance and security teams, it means a clearer operational record of what ran, where it ran, which artifacts it used, and how it progressed toward production — the kind of record that supports ATO documentation, IG audits, and public accountability.
This does not solve every sovereignty challenge. No single platform can.
What it does is address one of the most important gaps: the distance between infrastructure ownership and operational control.
The Secure Path Must Also Be the Easy Path
Governance often fails when the approved path is too difficult.
A program team needs GPU access quickly, so it opens a separate cloud account outside the ATO boundary. A developer needs to test a model, so a public API becomes the default. A prototype becomes a mission dependency before infrastructure or security teams know it exists.
This is how shadow AI begins.
Usually, it is not driven by bad intent. It is driven by friction.
The most effective governance model is not simply restrictive. It makes the approved environment easier to use than the unofficial alternative.
ClearML helps create that environment by giving AI builders self-service access to governed compute and repeatable workflows. Teams can move quickly while platform and infrastructure leaders retain visibility into where jobs run, which resources they consume, and how the work is tracked.
Speed and control do not have to be opposites.
With the right operational layer, they can reinforce each other.
That is an important point because sovereignty that developers constantly route around is not sovereignty. It is paperwork.
From Sovereignty Strategy to Sovereignty Practice
Most agencies now have an AI strategy. Many have use-case inventories, approved models, security controls, and infrastructure plans.
The difficult part is turning those intentions into daily operating practice.
That requires a platform that can make dependencies visible, preserve reproducibility, govern access to compute, and support movement across infrastructure environments.
ClearML is well-suited to that role because it focuses on the operational layer where sovereignty either becomes real or remains theoretical.
It does not ask the agency to abandon its existing data platforms, security systems, or governance tools. It gives those systems a practical point of enforcement inside the AI lifecycle.
That is the real value of an AI control plane for government.
It does not promise independence from every external technology. It gives the agency more control over how those technologies are used.
It preserves choice. It reduces hidden dependency. It makes the approved path easier to follow.
And it gives the agency a clearer answer to the question that matters most: are we actually operating AI on our own terms?
About the Author
Frank La Vigne is the author of Owning AI: The Sovereignty Stack, an examination of how nations and enterprises can take genuine control of their AI systems. He writes and speaks regularly on AI infrastructure, governance, and sovereignty.
To read more on how to regain control of your AI systems, visit clear.ml/blog. ClearML is available to Federal and State & Local Government customers through Carahsoft.