Where does your intelligence come from? AI sovereignty, and what to do about it

Most conversations about AI are about capability. Which model is smartest, which tool is fastest, what it can do this month that it could not do last month. There is a quieter question underneath all of it, and it matters more than any benchmark.

Where is your intelligence actually coming from? And if it comes from a single source, what happens when that source changes the price, changes the rules, or is switched off?

That is what AI sovereignty is really about. It matters now for a simple reason: AI has moved from a side experiment to something businesses genuinely run on, and control of that intelligence has quietly become a strategic question rather than a procurement one.

Sovereignty sits at three levels

It helps to see that this question exists at several levels at once.

Nationally, governments are asking how much of their AI capability should sit under domestic control.

For enterprises, it is the version that matters most right now: how much of your operation depends on intelligence you do not own, and where is your backup? This is the level to act on today.

And increasingly it will become personal, as individuals weigh whether their own tools and knowledge are truly theirs or merely rented.

The moment it stopped being theoretical

In June, the question got a very concrete answer. On 12 June, in the wake of a US government export control order, Anthropic suspended public access to its most capable models for users outside US jurisdiction. It happened within hours, only days after the models were released. Access was restored a few weeks later when the control was lifted, so the disruption was temporary. The point it made was not.

Overnight, organisations around the world learned that the most powerful intelligence they had access to could be turned off by a government on the other side of the planet, with no notice and no say. It has left many leaders asking a question they had not seriously considered: is it wise to run on a single, paid, closed model that we reach only through someone else's API?

This lands hardest for Australian businesses, who sit outside the jurisdiction making these calls. But it is significant enough that plenty of American organisations are reworking their AI strategies too. Single-source dependence is a risk wherever you are.

Open versus closed

The choice underneath all of this is between closed and open models.

A closed model is one you rent through an API. You send your prompt to the provider, the provider runs the model on their infrastructure, and the answer comes back. You get frontier capability with almost no setup, but you do not control the model, the terms, or whether it stays available, and your data leaves your walls every time you use it. That is exactly the arrangement June exposed.

An open model is one whose weights you can download and run yourself. The leading open models have closed most of the capability gap with the closed frontier, often to within a few percentage points on common tasks, at a fraction of the per-use cost, and the cost of running them has fallen sharply as the tooling has matured. The trade is that "run it yourself" is not one decision. It is a spectrum of options, each with a different balance of control, cost and effort.

Here is the honest headline before the detail. For most businesses the right answer is not one extreme or the other. It is a deliberate mix, and teams that get the mix right commonly report meaningful savings against a fully rented stack, because the cheap, high-volume and sensitive work runs on open models while the hardest work still calls a frontier API.

Now the options, from lightest to heaviest.

Option 1: A smaller owned stack

Run smaller open models on modest hardware you own, from a well-specified workstation up to a single GPU.

The upside: full control, your data never leaves the building, and no per-use bill. Capability has moved in your favour here, because a well-quantised mid-sized model in 2026 does work that needed a much larger model two years ago, and tools like Ollama and LM Studio make getting a model running genuinely straightforward.

The challenge: you are limited to smaller models, so the very hardest reasoning tasks may still be beyond it. A single machine has no redundancy, so if the hardware fails your service is down. And someone still has to set it up and keep it patched. This suits internal, high-volume, lower-sensitivity work more than mission-critical, customer-facing systems.

Option 2: A larger owned stack

Buy serious hardware, production-grade GPUs, to run the bigger and more capable open models in-house.

The upside: near-frontier capability that is genuinely yours, with your data fully on your own infrastructure and predictable cost at high volume.

The challenge: this is where the hidden costs live. Industry analyses consistently find that the true cost of running your own inference is several times the raw hardware or GPU-rental price once you add engineering time, and that the break-even point against simply renting a frontier API sits at very high volumes that most businesses never reach. A serious build runs into real money, the specialist engineers to run it are scarce and expensive, the models refresh every couple of months and each refresh means re-testing and redeploying, and a GPU sitting idle overnight and at weekends still costs you. This only makes sense at genuine scale, or where the data absolutely cannot leave your control.

Option 3: Rented infrastructure

Deploy your own open models on cloud GPU capacity you rent, or use a managed service that runs open models inside your own cloud boundary. You own the model and the data flow without owning the hardware.

The upside: no capital outlay, far less to maintain than owning the metal, and you can scale up and down with demand. Managed options from the major cloud providers give you private endpoints and enterprise controls, and specialist providers will host open models for you behind an API.

The challenge: you are still depending on an infrastructure provider, so this is more resilient than a single closed model but not fully sovereign. A rented dedicated GPU costs the same whether it is busy or idle, managed convenience carries a markup, and you are still trusting a third party with the environment your data runs in. This is often the pragmatic middle for a business that wants more control without building a data centre.

Option 4: Multi-model orchestration

Keep using models through APIs, but route each task across a mix of open and closed models behind a single layer, rather than committing to one vendor.

The clearest example arrived days after the June switch-off. The Tokyo lab Sakana AI launched Fugu, a system that presents as one API but routes work across a swappable pool of frontier models, built explicitly as a hedge against exactly the kind of vendor and export lock-in that took those models offline. Its founders put it plainly: relying on a single company's model is a risk because access can vanish overnight, and a swappable pool routes around that.

The upside: flexibility, no single-vendor lock-in, and the ability to send each task to whatever model suits it, without rebuilding when a model changes.

The challenge: it is still API-based, so for most such services your data still passes through third-party providers. It improves your resilience and your choice, but it does not by itself give you full data sovereignty.

Option 5: Full open-source, on your own infrastructure

At the far end, run open models entirely on infrastructure you control, up to a fully air-gapped deployment where prompts and data never touch an external network.

The upside: maximum control and the strongest possible data position, which is why regulated industries reach for it.

The challenge: it is the most demanding and expensive route, and it needs real, ongoing engineering capability to run safely and securely. For most businesses this is a level too far, reserved for the specific workloads where nothing less will do.

So what do you actually do?

You do not need to solve your model architecture this week. You need to answer the question underneath it honestly.

Where is your intelligence coming from, is it a single source, and what is your plan if that source changes the terms or switches off? For most businesses the answer will be a deliberate mix: a closed frontier API for the hardest work, open models you run or rent for the high-volume and sensitive work, and enough optionality that no single provider can leave you stranded. June showed that this is no longer hypothetical. The businesses that have an answer will be a great deal calmer the next time it happens.

This is the first piece in a short series. Still to come: what "open" really means and why the distinction matters commercially, the real cost of the hardware behind an owned setup, and a plain-language tour of the open models actually worth considering.