Back to Blogs
AI Sovereignty in Practice: What It Means for a Government Agency Deploying LLMs
For a government agency, AI sovereignty is the ability to decide, and to prove, who controls an AI system the agency depends on. That covers seven things: its data, its model weights, the infrastructure it runs on, who can change it after approval, what it is built from, evidence of how it behaved, and how the agency can exit while retaining its work. Sovereignty is not a place. It is control over those seven things.
AI sovereignty and sovereign AI both get used loosely. Most top-ranking pages frame them at the level of a nation: national compute, national models, national data centers. That matters for national policy. It does little for a program office that has to sign an LLM contract.
Key insights
- At the agency level, sovereignty means control over data, model weights, infrastructure, operations and updates, supply chain, evidence and exit.
- Data residency is where data sits. Sovereignty also covers who can reach it, who can change the system, and whether the agency can walk away with its work.
- For covered federal agencies, M-25-21 governs AI use, including testing and monitoring, and M-25-22 writes several of these controls into contract terms. As of September 2026, no later memo has replaced either one.
- Data classification sets the deployment floor, expressed in impact levels and authorizations.
- Ask every vendor whether a “sovereign” offer still depends on a model or provider the agency does not control.
What is AI sovereignty?
Start with the attributed definitions, because none of them is official. IBM defines AI sovereignty as the capacity of an organization or a country to control its AI technology stack, including infrastructure, data, models and operations. Red Hat describes sovereign AI as a shift from renting AI to owning it. Oracle talks about a government’s or organization’s control over AI technologies and their data, including how they are deployed and operated.
The vocabulary does not line up. IBM uses sovereign AI for the infrastructure and capability, and AI sovereignty for the control, and says the first can provide the technical foundation for the second. Red Hat flips the emphasis and uses that same term for the political question of who gets to set AI policy. In February 2026, researchers at Stanford HAI compared defining the term to “trying to nail jelly to a wall.” CNAS notes that a consensus definition remains elusive.
So ask what is sovereign AI and you get several answers. No sovereign AI definition carries official weight. The working definition here is the one in the opening lines: control over seven things, each of which an agency can test.
Stanford HAI supports that agency view. For companies and other organizations, the researchers write, it “often means operational control: deploying AI on-premise, avoiding vendor dependencies, and retaining control over data and models.”
Residency, data sovereignty and operational sovereignty
Three terms get blurred. The difference matters once you write requirements.
- Data residency is location: where data is stored and processed. IBM describes the concept as having grown out of that residency concern into a broader strategy.
- Data sovereignty, in IBM’s framing for AI, adds who can access the data and how it moves through AI pipelines. That includes training data, real-time inputs, model outputs and telemetry.
- Operational sovereignty, in Red Hat’s words, “is about who runs your system.” IBM adds the ability to audit operations and modify configurations.
Cisco names the failure that sits between them. Its “sovereignty gap” is legal control over data without control over the hardware or software layers where that data is processed. Picture data stored in the right country, under the right contract, running on a stack the agency cannot inspect or change. Residency is satisfied. Control is missing.
Where the national definition stops helping
Most top-ranking definitions frame sovereignty at the level of a country. Cisco, for example, defines sovereign AI as systems developed, deployed and governed within a nation’s legal and operational boundaries. The CNAS Sovereign AI Index tracks 184 government-backed projects as of its August 2026 update, and most disclose foreign partners, mostly U.S. companies. Brookings goes further, calling full-stack sovereignty “structurally infeasible for almost any country.”
None of it gives a program office anything to put in a statement of work. An agency cannot build a chip supply chain. It can decide who holds its data, which model version it runs, who can change it, what evidence it keeps, and how it leaves.
CNAS offers the bridge. At the model layer, it finds that countries define sovereignty as the ability “to run, modify, and govern a model domestically without dependence on a foreign firm’s” API or licensing terms. Swap “domestically” for “inside our boundary.” Swap “foreign firm” for “our vendor.” Now you have a test an agency can apply to any contract.
The seven control points of AI sovereignty for an agency
Each control point is a question the agency should be able to answer in writing, before award and again at renewal.
| Control point | The question the agency asks | What good looks like |
| Data | Where do prompts, retrieved documents, outputs and logs live, who can reach them, and can they train someone else’s model? | The contract bars training on non-public agency data, and the agency knows where its data is stored and processed |
| Model weights | Can we hold, host and freeze the model version we approved, or can we only call an API? | The agency runs the approved version where it chooses, or has an agreed way to test a model it cannot see |
| Infrastructure | Which environment does our data class call for? | The environment matches the data class, from commercial or government cloud to on-premises, edge or air-gapped |
| Operations and updates | Who can change the model or its settings after approval, and will we know? | Changes come with notice, go through agency control, and get caught by monitoring |
| Supply chain | Do we know the base model, the components and the data lineage behind the system? | The vendor discloses the base model and upstream components |
| Evidence | Can we produce our own record of how the system behaved, without relying on the vendor’s word? | Test results, impact assessments and monitoring records that the agency retains and evaluates using its own methods |
| Exit | If the contract ends, do we keep our data, fine-tuned models and code in a usable format? | Portability, rights to code and models produced under the contract, and a closeout transfer plan |
Data
Data is the obvious control point, and it is wider than storage. Think prompts, the documents a retrieval system pulls in, generated outputs and the logs around all of them. M-25-22 requires agencies to ensure contracts “permanently prohibit the use of non-public inputted agency data and outputted results to further train publicly or commercially available AI algorithms,” absent explicit agency consent. FedRAMP’s 2025 AI prioritization initiative had a related rule. Model information from training on customer data could not leave the customer’s environment without the customer’s permission.
Model weights
An API call gives an agency answers. Holding the weights gives it the model. The gap shows up at testing time. M-25-21 says that when an agency cannot access the underlying source code, models or data, it must use alternative test methods, such as querying the service and observing the outputs, or giving the vendor evaluation data.
Open-weight models widen the options. America’s AI Action Plan notes that many governments hold sensitive data they cannot send to closed model vendors. NTIA’s 2024 report found that open-weight models let users run models without sharing data with third parties, and it also flagged misuse and oversight risks. Open weights put the model file in the agency’s hands. The other six control points still need their own answers.
Infrastructure
Sovereign AI infrastructure comes in several legitimate forms: commercial cloud, government cloud, on-premises, edge and air-gapped. The right one depends on the data the system will touch, which the classification section below maps out. One boundary matters from the start. M-25-21 and M-25-22 do not cover AI used as a component of a National Security System. Those deployments follow DoD and Intelligence Community policy.
Operations and updates
A hosted model can change under you. Red Hat gives the example of a vendor update that causes drift the customer cannot fix locally. M-25-21 anticipates this. It requires ongoing monitoring designed to detect changes to an AI system after deployment, along with changes in its context of use or data. The practical ask is simple: notice before a change, and a way to stay on the version you approved.
Supply chain
An LLM system is assembled from parts. There is a base model, software libraries, training data and sometimes other providers’ services. NIST AI 600-1 lists “Value Chain and Component Integration” as a generative AI risk, meaning non-transparent or untraceable integration of upstream third-party components. Red Hat’s idea of technical sovereignty points the same way, framed around a software or AI bill of materials. If a vendor cannot say what the system is built on, the agency cannot say it controls it.
Evidence
Control you cannot demonstrate is hard to defend in an audit. For high-impact AI, M-25-21 sets minimum practices: pre-deployment testing, an AI impact assessment, ongoing monitoring, operator training, human oversight, remedies or appeals, and public feedback. Red Hat’s assurance sovereignty asks for independent verification with your own measurements rather than the provider’s. The NIST AI Risk Management Framework is voluntary. Its core organizes the same work into four functions: govern, map, measure and manage.
Exit
Exit is the control point that tests all the others. Take a hypothetical agency that fine-tunes a model on its own case files. It has built something valuable, and whether it can take that model elsewhere depends on the contract.
M-25-22 lists lock-in protections for AI contracts: “vendor knowledge transfers, data and model portability, providing agencies with rights to code and models produced in performance of a contract,” plus transparent licensing and pricing. It also asks agencies to keep the components needed to operate and monitor a system available for as long as necessary, and to plan data transfers at closeout. Stanford HAI reaches a similar place at national scale, describing sovereignty as the capacity to choose and reconfigure dependencies. Brookings recommends building portability in through procurement.
Federal policy already writes much of this down
For AI in government, two OMB memoranda set the rules for covered executive branch agencies, current as of September 2026. Neither covers AI used in National Security Systems. Both were issued April 3, 2025. Both implement Executive Order 14179.
- M-25-21, the memo on agency use of AI, replaced M-24-10. It required each agency to retain or designate a Chief AI Officer within 60 days. Agencies other than DoD and the Intelligence Community must inventory AI use cases at least annually and post a public version. AI counts as high-impact when its output is a principal basis for decisions or actions with a legal, material, binding or significant effect on rights or safety. Agencies had 365 days to document the minimum practices, and they must stop using high-impact AI that cannot be brought into compliance.
- M-25-22, the memo on AI acquisition, replaced M-24-18. It applies to contracts awarded under solicitations issued from late September 2025, and to options exercised after that. Its training, portability and closeout terms are the ones quoted above.
- M-26-04, issued December 11, 2025, implements Executive Order 14319. It applies two Unbiased AI Principles, truth-seeking and ideological neutrality, to any LLM an agency procures, however it is deployed. It excludes national security systems and sunsets after two years unless extended.
The OMB memoranda index, checked through M-26-19 of September 10, 2026, shows no later memo replacing M-25-21 or M-25-22.
Two other instruments give direction. America’s AI Action Plan, released in July 2025, is a set of recommended policy actions. It supports open-weight models for sensitive-data use, and it recommends standards for high-security AI data centers and wider agency use of classified compute. The NIST AI RMF is voluntary. The binding instruments are the OMB memos.
Those memos govern federal executive agencies. They do not bind state or allied governments. Still, US federal policy offers a useful template for anyone drafting their own AI procurement terms.
How data classification sets the deployment floor
Classification decides the minimum environment. Other rules, such as export controls, can add to it.
Start with CUI. Under 32 CFR 2002.4, CUI is information the government creates or possesses, or that someone else holds on its behalf. It qualifies when law, regulation or government-wide policy requires or permits safeguarding it. Classified information is excluded. CUI Basic and CUI Specified differ by whether the underlying authority sets specific handling controls.
For cloud environments, the DoD Cloud Computing Security Requirements Guide (SRG) sorts data into impact levels. In paraphrase, from an earlier published release of the guide (check the current release for exact wording):
- IL2: public information, plus unclassified information outside CUI that needs only minimal access control.
- IL4: CUI and other mission-critical data.
- IL5: CUI that needs more protection than IL4, and unclassified National Security Systems.
- IL6: classified information up to SECRET. Missions above SECRET fall outside the SRG and follow DoD and Intelligence Community policy.
Export-controlled technical data carries its own access and storage rules on top of these.
FedRAMP is mid-transition. FedRAMP 20x is in Phase 3, with Class A, B and C certifications formalized (Class B maps to Low, Class C to Moderate) and a submission pipeline planned for July to September 2026. A Class D (High) pilot is planned for FY27. FedRAMP plans to stop accepting new Rev5 certifications on June 11, 2027, a date it calls an estimate. Its own materials now say “certified” where older documents said “authorized.”
When a vendor cites FedRAMP, check two things separately: the status of the AI service itself, and the status of the cloud underneath it. The SRG, for its part, speaks of impact levels and authorizations. It does not speak of air gaps. That is where the two ideas tend to get mixed up.
Sovereign AI vs air-gapped AI: what is the difference?
Sovereignty is control across the seven points above. Air-gapping is a network-isolation pattern. It delivers some of that control in environments where data cannot leave the boundary. The two overlap without being the same thing.
An air-gapped system can still fail the exit test, if the contract gives the agency no rights to its fine-tuned model. It can fail the supply chain test, if nobody can say what the base model contains. Seekr’s own guide to air-gapped AI makes the cost point: for organizations without a real sovereignty or classification constraint, “a well-governed private cloud deployment may deliver most of the control at lower cost.”
For environments where data cannot leave the boundary, that guide covers what it takes to run generative AI offline.
What should an agency require from a vendor for sovereign deployment?
Put the control points into the solicitation as questions. Each of these eight traces back to a memo or source above. Treat them as prompts for your contracting and legal teams to turn into terms.
- Will you confirm in writing that our inputs and outputs will not train your public or commercial models?
- What data and model portability, knowledge transfer, and rights to code and models produced under the contract do you offer?
- Will the components needed to operate and monitor the system stay available for as long as we need them? What is the closeout transfer plan?
- Can we test the proposed system before award, ideally in an environment on our own networks? If we cannot see the model, which alternative test method will you support?
- How will we hear about model and configuration changes after deployment, and can we decline them?
- Which base model and upstream components is the system built on?
- Which environment will the system run in for our data class, at which impact level, and what is the FedRAMP status of your service and the underlying cloud?
- If we call this deployment sovereign, does it still depend on a model or provider we do not control?
The last question comes from the Carnegie Endowment‘s warning about “sovereignty-washing”: local clouds that depend on foreign providers, or national systems built on externally controlled models. The same test works one level down, for an agency weighing a vendor’s label.
For reference, here is how Seekr describes its own approach. Seekr states that customer data and models remain fully owned and controlled by the customer, and that it does not use customer data to train its models. According to Seekr, SeekrFlow runs across cloud, on-premises, edge and air-gapped environments, and is available in AWS GovCloud (US) through AWS Marketplace. The government page lists the deployment options.
Sovereignty an agency can check
AI sovereignty in practice comes down to answers an agency can produce on request. Where does our data go? Which model are we running, and who can change it? What is it built on? What evidence do we hold? How do we leave? When the contract answers every one, the agency has the control that matters for its mission, whatever the network diagram looks like.
See what sovereign deployment looks like on your own infrastructure
Book a consultation with an AI expert. Share your challenges and objectives, and our team will connect to explore solutions and walk you through a live demo of SeekrFlow.
You can also review Seekr’s private deployment options.
Sources
- M-25-21, OMB memo on federal use of AI, April 3, 2025
- M-25-22, OMB memo on AI acquisition, April 3, 2025
- M-26-04, OMB memo on Unbiased AI Principles, December 11, 2025
- OMB memoranda index, checked September 2026
- The White House, America’s AI Action Plan, July 2025
- Federal Register, Executive Order 14179, Removing Barriers to American Leadership in Artificial Intelligence
- FedRAMP, FedRAMP 20x, and the FedRAMP AI prioritization initiative
- eCFR, 32 CFR Part 2002, Controlled Unclassified Information
- DoD Cloud Computing Security Requirements Guide (DISA), impact level definitions
- NIST, AI Risk Management Framework
- NIST, AI 600-1, Generative Artificial Intelligence Profile
- NTIA, report on open-weight foundation models, 2024
- Stanford HAI, AI Sovereignty’s Definitional Dilemma, February 17, 2026
- CNAS, Sovereign AI Index, updated August 2026
- Brookings, Is AI sovereignty possible? Balancing autonomy and interdependence, February 2026
- Carnegie Endowment, essay by Luca Belli on putting sovereignty to work, September 3, 2026
- IBM Think, topic page on the term, updated September 2026
- Red Hat, sovereign AI topic page; Cisco, what is sovereign AI; Oracle, sovereign AI
FAQ
What is AI sovereignty?
It is the ability to control an AI system you depend on, from its data and model to how it is run and how you leave it. Sources define it differently: IBM treats it as control of the AI stack, while others apply it to national policy. For a government agency, it comes down to a short list of control points you can check in a contract.
What is sovereign AI, and how is it different from AI sovereignty?
IBM uses sovereign AI for the infrastructure and capabilities, and AI sovereignty for the control they make possible. Red Hat uses the two terms with the opposite emphasis, and IBM notes they are often used interchangeably. When a vendor uses either term, ask which meaning it intends.
Sovereign AI vs air-gapped AI: what is the difference?
Sovereign AI is about who controls the data, the model, its operation and the exit. Air-gapped AI is a network-isolation pattern for environments where data cannot leave the boundary. There, an air gap can support sovereignty, but it leaves portability and supply chain questions open.
What should an agency require from a vendor for sovereign deployment?
Start with a written bar on training with agency data, plus data and model portability and rights to what the contract produces. Add notice and control over model changes, and disclosure of the base model and its components. Match the environment to the data class, then ask whether the offer still depends on a provider the agency does not control.
Is data residency the same as data sovereignty?
No. Residency is where data is stored and processed. Data sovereignty also covers who can access the data and how it moves through AI pipelines. Cisco’s term for the difference is the sovereignty gap.
Do open-weight models make an agency sovereign?
They help with one control point. Holding the weights lets an agency run a model without sending its data to a closed vendor. Updates, supply chain, evidence and exit still need their own answers, and NTIA’s 2024 report notes misuse and oversight risks alongside the benefits.
Do M-25-21 and M-25-22 apply to national security systems?
No. Both memos exclude AI used as a component of a National Security System. Those deployments, including classified ones, follow DoD and Intelligence Community policy.
Accelerate your path to AI impact
Book a consultation with an AI expert. We’re here to help you speed up your time to AI ROI.
Request a demo
