Who Actually Controls Your AI? Insights from Cory Hawkvelt on AI Sovereignty, Security and Governance

HYPERSTACK × UKAI

Insights from Hyperstack CPTO Cory Hawkvelt on why sovereignty and security are not the same thing.

Ask a room full of technology leaders whether their AI is sovereign and most will say yes without hesitation. Ask them what that word actually means for their organisation and the room tends to go quiet. That gap sat at the center of a UKAI webinar Hyperstack co-hosted this month, where our CPTO Cory Hawkvelt sat down with UKAI to unpack what sovereign AI really requires once you get past the label.

The conversation covered a lot of ground, from hardware provenance to open-weights models to the shadow AI problem quietly growing inside most organisations. Here is what stood out.

Sovereignty Without Security Is Just Geography

The word sovereignty has become the new cloud. A decade ago, everything needed to be in the cloud and hardly anyone could explain what that actually meant either. Sovereignty is following the same path. Organisations say they need sovereign AI when what they actually want is security, and geography is only one part of that picture.

Cory used a food supply chain comparison that landed well with the audience. If you ask where the fruit in a jar of jam came from, hearing that the warehouse is in the UK is not a real answer. You want to know who grew it, who processed it and under whose safety standards it moved along the way. AI deserves the same scrutiny. Knowing that your GPUs sit in a UK data center tells you nothing about who operates them, what they log or which jurisdiction that operating team answers to.

The AI Stack Has More Layers Than Traditional IT Ever Did

Traditional enterprise IT was comparatively simple. A database, an ERP system, a file server, maybe a single data centre. You wrote a policy about where the data lived and who could access it and that policy mostly held up.

AI has broken that model without replacing it. Inference providers, proxies, orchestration layers, model vendors, agents and token billing systems now sit on top of the same data, and each layer adds a new dependency and a new question about who is actually in control. A compromised spreadsheet used to mean someone could see raw numbers. A compromised AI pipeline means someone can see how you interpreted those numbers, which is a different and often more sensitive kind of exposure. Cory's point was direct: the policies written for the old stack were not written badly; they were simply written before this stack existed, and stretching them to cover it does not work.

It Is Not Just IT's Problem to Solve

One theme kept resurfacing throughout the session. This is not a single department's responsibility. Operations, finance, and marketing all touch AI in ways that security teams rarely see end-to-end, often without realising a tool they already use has AI quietly built into it. A CRM might be generating summaries with a model nobody signed off on. The fix is not a stricter mandate handed down from the top. It is awareness spread across the whole organisation, paired with leadership that actually understands the risk well enough to act on it rather than delegate it and move on.

Open Weights Models Trade Blind Trust for Testable Trust

One of the more counterintuitive parts of the discussion concerned where frontier open weights models actually come from. Judging by parameter count, context window, and licensing terms, most of the genuinely competitive open weights models today come out of China, with strong contributions from Europe through labs like Mistral and Black Forest Labs. That fact makes some organisations uneasy on instinct, the same way Huawei hardware once did in telecom infrastructure.

Cory argued that instinct does not transfer cleanly to models. With an open weights model, you cannot see the training data, but you can inspect the artifact itself. You can test its behaviour, benchmark it for bias and post-train it under your own controls, no matter which country produced it. A closed model from a familiar, trusted brand can still leave you blind to what that provider is doing with your requests behind the scenes. Transparency, not nationality, is the variable that actually determines what you can audit and control.

One AI Policy for the Whole Company Protects Nothing

Perhaps the sharpest piece of advice from the session was this: stop trying to write a single AI policy for the entire business. A marketing team generating social media images does not need the same controls as a finance team building a board report from sensitive transaction data, and neither needs the lockdown you would put around credit card processing.

Treat all of it the same way and one of two things happens. Lock everything down too tightly, and employees route around the policy using personal accounts on their own phones, which is exactly how shadow AI takes hold inside organisations that thought they had this handled. Leave the policy too loose, and the genuinely sensitive data gets no protection at all. The better approach is proportional. Identify which categories of data are actually sensitive, approve specific tools for those categories, and let low-stakes work move through whatever is fastest and cheapest.

Four Questions Worth Asking This Week

For any team ready to act on this, Cory's advice is condensed neatly into four practical steps.

• First, find out how many models and providers your organisation is actually using. Count the CRM, the website chatbot, the coding assistants and any tools you already license that quietly added AI features. The real number is almost always higher than expected, and twenty or thirty across a mid-sized company is normal rather than alarming.

• Second, work out which of those tools touch data you genuinely care about. HR records, patient information, financial data and client contracts belong in this category. Most of your organization's AI usage probably does not.

• Third, for each sensitive use case, trace the entire path. Who operates the infrastructure behind the model? What jurisdiction that team sits under. What gets logged and whether that logging protects you or exposes you. Where the servers physically sit matters far less than who is running them, because a well-located data center does not help if the operations team sits somewhere you would never approve for your own staff.

• Fourth, check whether your existing policy actually distinguishes between these categories or whether it treats a cat meme and a board report the same way. If it does not, that gap is where the real risk lives.

The Operations Layer Is Where Control Actually Sits

The thread running through the entire session was that control comes down to people and operations, not just physical location. A GPU cluster sitting in a UK facility does not tell you much if the team operating it, patching it and potentially handling your data in transit sits somewhere you have no visibility into at all.

As Cory put it, the geography of the building containing the GPUs is irrelevant if the people operating them are somewhere you would never accept for your own staff. The requests, the responses, the logs, the operators and the jurisdiction they sit under all matter. Know who is operating your stack and make sure you are genuinely comfortable with that answer.

Want That Kind of Control Over Your Own Infrastructure?

Hyperstack's Secure Private Cloud gives you a straight answer to the operations question Cory raised: dedicated, single-tenant GPU clusters with no oversubscription and a named, accountable support team you can actually reach. Talk to us about mapping your own AI stack onto infrastructure you control end-to-end.

Thanks to everyone who joined the live session with UKAI and to everyone still working through the questions Cory raised afterwards.