Sovereign AI: the operating playbook
Sovereignty is a capability, not a location. Five rights, a ladder of infrastructure routes, and four proofs to run before production.

In shortSovereignty is a capability, not a location: an institution is sovereign when it can keep an AI service useful, governable, and replaceable as conditions change. The playbook specifies five rights (locate, exclude, operate, retain value, change), a ladder of four infrastructure routes chosen by the workload, and four proofs to run before production: exit, custody, agency, and continuity.
Every AI vendor now sells sovereignty. Most of them mean a region on a map. Boards, regulators, and procurement teams have started asking a harder question: when the model changes, the supplier stumbles, or the rules move, can we keep this service useful, governable, and replaceable?
That question is the subject of Sovereign AI: the operating playbook, a new report from Fig Research. This piece walks through the argument. The full report, with the worked example and the checklists, is free to download above.
Sovereignty is a capability, not a location
An institution is sovereign in practice when it can keep an important AI service useful, governable, and replaceable as conditions change. Local infrastructure can help. It does not, by itself, establish control over information, authority to act, or the ability to leave a supplier.
The playbook replaces the label with an operating test. Five rights turn an aspiration into requirements. Each should be specified for a workload and demonstrated before production.
- Locate. Choose where information is processed, stored, and supported.
- Exclude. Control who can read records, use keys, and change policy.
- Operate. Maintain an accepted service through a defined disruption.
- Retain value. Keep the context, evaluations, and knowledge created through use.
- Change. Replace models, infrastructure, and the control platform.
The central design choice follows. Protect the institutional core while keeping access to useful external capability. Add isolation, dedicated capacity, or local execution when a specific requirement justifies the burden. Do not make every workload pay for the most restrictive architecture.
Model choice and owned context are durable principles. Hardware ownership, zero retention, open weights, and reversibility are answers to specific requirements, and each needs a precise test. An export is not necessarily a working exit. A branch cannot undo a disclosure.
Why this matters more every quarter
The incentives are not aligned. A model provider does better when more of your work flows through its models and more of your know-how shows up in its usage, its evaluations, and eventually its weights. Your institution does better when that know-how stays in a form you own and the model underneath it stays replaceable.
Two of the five rights carry this. Retain value means the records, decisions, corrections, and criteria for success created through work are kept somewhere that outlasts the model and the platform that first captured them. Change means switching models is a setting, not a migration. Together they turn every month of use into an asset the institution holds rather than a dependency it deepens.
Where the infrastructure question actually lands
Most sovereignty debates start with infrastructure and never leave it. The playbook puts infrastructure third, after the workload charter and the routing decision, because the right amount of isolation depends on what the workload has to survive.
There are four routes, from most isolated to least. Choose the rung from the charter, not from the vendor's brochure.
- Owned or isolated runtime. The workload must prohibit external egress, or must survive the loss of every outside provider. Capacity, software, and an operating team are yours.
- Attested compute you do not own. Sensitive information is involved, and hardware attestation can prove the workload ran inside an enclave the host cannot inspect.
- Contracted cloud with zero retention. Sensitive information is involved, the contract can be enforced, and the institution can verify the configuration that is actually running today.
- Approved managed service. None of the above applies. Use the frontier and spend the control budget on custody, authority, and continuity instead.
The rung is a means. Isolation buys you locate and part of exclude. It does not buy custody of application logs, safety signals, and support access. It does not buy an action boundary around what the model is allowed to do. It does not buy continuity, because owning the building does not mean the service comes back within the agreed interval. Whichever rung you choose, the proofs at the end of this piece are the same.
Design the system
The report runs one workload through every decision: a casework assistant that prepares an evidence-based case summary for a trained reviewer. It may retrieve and draft. It may not decide a case or send anything outside the boundary. Search and manual processing stay available when the model route fails.
Write the charter before choosing the stack. Name the mission, the information the assistant may touch, the authority it holds, the quality the service owner will accept, and the continuity the business needs. A charter keeps a supplier's product description from becoming the institution's definition of sovereignty.
Route the workload, then select the model. Ask, in order: can deterministic software solve the task, must the workload prohibit external egress, must the service survive loss of the provider, and is sensitive information involved. Only then compare models on the institution's own cases: correctness, completion, permission violations, latency, and correction effort.
Follow every copy of the information. Prompts, retrieved records, outputs, traces, and support artifacts each have their own retention and access rules. Custody is the complete path, not the database where the record began. A no-training commitment does not eliminate logs or support access. Customer-controlled keys do not always mean a provider cannot process plaintext while doing its job.
Own what the institution learns. Keep records, permissions, evaluations, workflow configuration, and outcomes in a form that moves. The proof is a rehearsal, not an export button: move one workflow into a second environment, restore permissions, run the same cases, and measure what was lost.
Put authority outside the model. A model may propose an action. The surrounding system decides whether it is allowed. Approval is bound to the exact operation, execution rechecks current authority, and the decisive test is whether the system blocks an unauthorized action even when the model has been persuaded to attempt it.
An alternative must survive the rehearsal. Naming a second provider is not continuity. The alternative needs capacity, compatible software, restored context, valid credentials, and a team that can take over within the required interval. Run a timed switch and record what it took.
Prove it in operation
Price accepted outcomes, including control. Token prices and GPU-hour rates are inputs. Compare the cost of accepted outcomes at an agreed quality, latency, and recovery level, with failed attempts, retries, and human correction in the cost base. If resilience justifies a more expensive route, fund that requirement explicitly instead of hiding it inside optimistic unit economics.
Make the contract match the operating test. Custody means defined retention and access terms, demonstrated by tracing copies and exercising deletion. Exit means usable exports and transition support, demonstrated by restoring a workflow elsewhere. Agency means scoped tools and approval controls, demonstrated by attempting unauthorized actions. Continuity means recovery duties and support, demonstrated by a timed rehearsal. An exit clause that cannot be executed is weak protection.
Ninety days to a defensible decision. Days 1 to 30 map and baseline. Days 31 to 60 build and contract, with the fallback built alongside the primary service. Days 61 to 90 exercise and decide: outages, compromised credentials, model changes, unauthorized retrieval, and a rehearsed provider switch. A successful pilot authorizes the next controlled step. It does not automatically authorize more sensitive data or greater action authority.
Four proofs before production
The institution should be able to demonstrate the control it claims. Run these before release, after material changes, and on a schedule, and keep the results with the workload charter.
- Exit. Restore the workflow in a second approved environment with context, permissions, and acceptable quality preserved.
- Custody. Verify locations, key authority, retention, deletion, and exceptional access. Resolve unexplained paths before widening exposure.
- Agency. Attempt unauthorized retrieval and action. Exercise approvals, revocation, and the kill switch.
- Continuity. Remove a critical dependency and recover an accepted service within the agreed interval.
For suppliers, repeatable proof of these outcomes is a stronger proposition than an unqualified sovereignty promise. For buyers, a test that fails means repair the control, narrow the scope, or delay release. Make a decision, not a presentation.
Where we agree with Palantir, and where we differ
Palantir's Institutional Sovereignty in the Age of AI is the clearest statement of the case so far. Its thesis is that sovereignty is your alpha: the value an institution creates should compound inside the institution, not inside a model provider's weights. It is direct about incentives, and it gives infrastructure a definite shape: a ladder of assurance from owned hardware to attested compute to zero-retention cloud, and a control layer that is model agnostic, granularly permissioned, audited, and built to branch. We agree with nearly all of that, and the ladder above is our version of theirs.
Where the playbook adds something is proof. A ladder tells you where a workload can run. It does not tell you whether the control you bought is real. The operating test, the four proofs, the pricing of accepted outcomes, and the contract that mirrors the test are the parts an institution needs on the day a regulator, a board, or an outage asks for evidence. And where we differ in emphasis is the default: structural isolation is the right answer for the workloads that need it, and a cost the rest should not carry.
How Fig runs this
The playbook was written from work with institutions that have to answer these questions, and the platform is built around the same five rights.
- Model choice stays open. Fig Intelligence routes every task across frontier models from multiple labs, with per-team controls. Switching is a setting, not a migration. How the router decides is its own post: Flash or Thinking.
- Context stays yours. Enterprise Context holds records, permissions, evaluations, and workflow configuration in a form that exports and restores, which is the portable core the report describes.
- Authority sits outside the model. Approval gates precede anything irreversible, credentials are scoped, and Command Center records what ran and why. The security review kit built on the four proofs is Getting the CISO to yes.
- Ninety days is a program we run. Transformation Services executes the map, build, and exercise sequence with the institution's own owners and evidence.
Key takeaways
- Sovereignty is an operating capability: useful, governable, and replaceable under change. Location can help; it is not proof.
- Five rights make it specifiable: locate, exclude, operate, retain value, change.
- Infrastructure is a ladder of four routes chosen by the workload charter, and the same four proofs apply on every rung.
- Before production: exit, custody, agency, continuity, demonstrated on your workflow and kept with its charter.
Control what matters. Retain what you learn. Keep the ability to change.


