Enterprise AI Sovereignty

Until recently, sovereignty was largely a question of public policy: where data centers are located, which jurisdiction governs the data held in them, and how national compute capacity is secured. Presented to a commercial audience, it tended to read as caution with an infrastructure bill attached.

The relevant risk has since changed. The question facing most organizations is no longer whether an external adversary can reach their AI systems. It is whether the provider of those systems can alter commercial terms, pricing or model behavior beneath a workflow already in production, and whether the prompts and corrections flowing outward are steadily transferring institutional knowledge to that provider.

Market forecasts have adjusted accordingly.

Enterprise software has historically required the buyer to adapt. Processes were reshaped to fit a product’s data model, a fee was payable to extract the organization’s own data, and a model was selected in the expectation that its terms would hold. Each layer asked the business to bend.

Sovereignty is best understood as the decision to stop bending, and it warrants a precise definition, because those marketing the term have an incentive to leave it broad. As Ben Van Roo observed in July, sovereignty is “a set of exits, not a set of deeds.” Ownership of the model, the platform or the data center is not the requirement. The ability to withdraw from each of them is.

Preserving those exits is not a procurement outcome. It is a set of five tenets the organization applies continuously, and each reinforces the others.

1. 01

   Own

   Own the enterprise context

   The reasoning behind a price, the conditions attached to a customer commitment and the judgment that governs an exception are what give company data its commercial value. That context should be treated as an asset with named owners and defined rights, core records should remain in their authoritative systems, and approved knowledge should be held separately from individual conversations so that it can move.

   The knowledge leaves with the organization, in a form a subsequent model can use.

2. 02

   Route

   Route models by value, risk and continuity

   Complex analysis may justify a leading model; routine classification frequently does not; sensitive work may require private processing. Business rules should remain independent of any single model, approved providers should sit behind a common internal interface, and alternatives should be tested against genuine operating cases.

   Changing providers becomes a configuration change and a validation exercise rather than a migration.

3. 03

   Gate

   Gate actions with enterprise authority

   As AI begins to update records and initiate transactions, authority must remain with the organization. Permissions should be applied before AI reads and again before it acts, consequential decisions should require human authorization, and a record should be retained of what was accessed, which model was used and who approved the outcome.

   Authority and the audit record remain in the organization’s systems, whichever model is in use.

4. 04

   Run

   Run where the business already operates

   The financial, customer and operational systems already supporting the business should remain the authoritative record. The operating environment should follow the requirements of the workflow, and recovery obligations should follow the consequences of failure. In our experience a targeted workflow often delivers measurable value well before a broader modernization program concludes.

   The same workflow runs wherever the business requires it, on a provider’s infrastructure or elsewhere.

5. 05

   Keep

   Keep what the enterprise learns

   Each useful correction contains an improvement. An employee who amends an AI-generated quotation may have surfaced a pricing exception that subsequent workflows will also need. Corrections and outcomes should be captured, validated by experienced practitioners and reflected in approved knowledge. Retaining conversation histories alone achieves nothing.

   What the organization learns remains with the organization rather than accruing to a provider.

• Is a change of model a configuration change or a migration?
• On exit, what transfers to us, and in what format?
• Can this operate in our cloud, our own infrastructure and a disconnected site?
• Is the training opt-out contractual?
• Does the software adapt to our process, or our process to the software?

The constituent capabilities are available today. Open-weight models are adequate for the majority of workloads, routing layers reduce a change of model to a change of configuration, and on-premises and edge inference are established. For most organizations the binding constraint is habit: the bundle remains the easier purchase.

The degree of control should be proportionate to the value and consequences of the workflow. Private infrastructure and multiple providers carry genuine operating and testing costs, which should be weighed against continuity, accountability and the ability to change direction. Control then becomes an explicit criterion in the investment decision rather than an assumption within it.

For organizations ready to proceed, ALPS maintains a portfolio of enterprise solutions assessed against these five exits, supported by advisors who understand the demands of enterprise operations.

Sources: McKinsey, Sovereign AI: building ecosystems for strategic resilience and impact (2026); Ben Van Roo, “Making Fetch a Thing” (July 2026), for the exits framing.