AI introduces new risks, such as outputs that can be confidently wrong or difficult to explain, and models that can be manipulated through crafted prompts to bypass their own safeguards.
AI also reshapes risks that already existed, such as reliance on vendors for both a model's behavior and the infrastructure it runs on. All of this raises an inevitable sovereignty question: how much control does the organization actually retain over the AI systems it deploys?
Why Hosting isn't Control
Consider two organizations. The first hosts its AI entirely on domestic infrastructure, at significant cost and operational complexity. It meets every data residency requirement. However, it runs on a closed model it doesn't own. The vendor still controls what the model was trained on.
The license itself can also be terminated by the vendor, at which point the organization is contractually required to stop using and delete the model, regardless of where it is hosted. The organization has secured the building, but not what happens inside it.
The second organization runs on foreign cloud infrastructure. It has secured contractual data-handling guarantees, assessed the model's behavior itself rather than relying on the vendor's claims, keeps its own governance and audit trail, controls its own encryption keys, and retains the internal skills to operate the system. It can be confident in how the model behaves, protect its own data, detect and correct a bad decision, and switch vendors if it needs to. Hosting everything in-house gave the first organization none of that.
Hosting was never the real question.
Where Control is Actually Won or Lost
Start with data and models, the most familiar part of this picture. Who owns the training data, whether it can be reused, and whether the organization depends on a single vendor's model, its updates and its roadmap. This is also where bias should be monitored: the data used to train a model shapes its behavior, and models should be assessed against safety and fairness before an organization relies on them.
A model trained and maintained entirely outside the organization's reach can change behavior overnight, for reasons that have nothing to do with the organization itself.
Inference is less discussed but just as critical. Even an organization that owns its data and fine-tunes its own model still depends on the infrastructure needed to run it: chips, cloud capacity, and processing that can be throttled, re-priced, or restricted, regardless of who owns the data or the model itself.
This is also where sensitive prompts are processed, often in real time, raising the question of who can see them, where they are transferred, whether they are retained after the response is returned, or reused to train the model itself. This is a separate layer of exposure, one that getting data and models right does nothing to prevent.
Governance turns intentions into practice: a clear, adopted usage policy, a baseline of controls that includes encryption, data retention rules and monitoring metrics, and requiring that a system's outputs can be explained and audited, rather than simply trusted. Without this, an organization may comply with every regulation on paper while having no real visibility into how its systems are actually used or how they behave.
Operations tends to get less attention, especially during design and implementation, when organizations often rely on external resources and haven't yet built the internal capability. Running an AI system well requires people who understand it enough to maintain it, adapt it and if necessary replace it. Without that expertise, systems will tend to stay longer than they should, becoming harder to maintain or safely retire.
In the end, none of this matters if a human can no longer meaningfully oversee, question, or override what the system decides. Accountability cannot be delegated to a machine: whatever it decides, the responsibility, and the risk, remain with the organization. Human oversight has to be built into the process, not appended to it. It is the last line of defense when every other safeguard fails.
Moving to Risk-Based Assessment
Not every system requires the same level of scrutiny. What matters is the criticality of the activity it supports: a system recommending playlists carries different stakes than one approving loans or guiding medical decisions, a distinction regulators are already making, as the EU AI Act's risk-based obligations show.
AI sovereignty will not be won by choosing the right data center, nor verified through a compliance checklist. It builds on layered controls: the data a system relies on, the models it uses, the infrastructure it runs on, the governance that oversees it, and the people who can still intervene when it fails.
But maximum sovereignty should not be the default. Like security, sovereignty should match the risk. High-stakes systems deserve more control. Low-stakes ones don't need the same effort. That balance is what keeps sovereignty practical and achievable. For security teams, that is the real audit to run: whether the level of control matches the system's risk profile.