AI sovereignty is the key topic of the moment. The layer under the model was not on the agenda.

The day after

Last week we wrote that cyber sovereignty was on ITBN's agenda and that we had not put it there. Today I was in the Bálna, and the word has moved one step on. Last week it was kiberszuverenitás. Today it is AI-szuverenitás, AI sovereignty, a key topic these days. It was a great day of networking. I will not name anyone, so I will read the programme instead: the programme is public, the conversations were not.

Counted by us this evening: 104 programme items. 36 carry AI in the title, one in three. 8 are about AI agents. 3 are about sovereignty, all three in the main hall, the last of them closing the day at 15:35, before the awards: "Digitális és kiber szuverenitás — Képes-e Magyarország önállóan megvédeni és működtetni digitális infrastruktúráját?", can Hungary defend and operate its digital infrastructure on its own. Its abstract asks what happens when the usual foreign technology services become unavailable overnight. Last week the word was in the event description. Today it had the closing slot in the main hall.

What the room was securing

Read the abstracts and the day sorts itself into three questions.

What users do with AI. "Hogyan kontrolláljam az AI használatot?", how do I control AI use, is the Shadow AI thread from our previous piece, now on stage as a method: visibility first, then risk-based rules, then auditable control. Banning the tools, the abstract says, is not enough.

What agents are allowed to do. Eight sessions, from "Why you should Repatriate Identity to Deliver an Agentic Control Plane" to an OWASP talk whose abstract compresses the thread into six words: "Don't babysit your agent. Fence it." Fences rather than approvals.

What the state must control. The three sovereignty sessions above.

All three are the same problem: a black box you cannot see into, a model, an agent, a foreign dependency, and how to keep control of it anyway. A noon session title put the whole day in four words: without trust, without control. That is the right instinct. I want to add the layer the abstracts skipped.

The layer under the model

The moment a security team runs AI itself rather than buying it as an API, it inherits a stack: the operating system, the model loader or inference runtime (Ollama, vLLM), the gateway in front of the models (LiteLLM or similar), and the monitoring stack watching all of it. Each layer is software from a vendor or a community, and each ships with defaults.

Some of those defaults send data out. Two examples, checked this evening against the vendors' own documentation:

• vLLM collects anonymous usage data by default: hardware, model architecture, configuration. Documented and switchable (VLLM_NO_USAGE_STATS=1 or DO_NOT_TRACK=1).
• Grafana ships with reporting_enabled set to true, sending anonymous usage statistics to the vendor, and checks for updates every ten minutes. Also documented, also switchable.

Neither is a leak. Both are things a security team wants to know before it writes the egress policy, not after. Telemetry, data leakage and software calling home are real issues in an AI stack. Control egress. Run open-weight models behind your own firewall. Understand what the stack does on the wire before you trust what it says in the chat window.

Here is the count that made me write this. Across the 104 items, three abstracts mention telemetry, each time as input to the defence: XDR feeds, threat intelligence. Zero mention egress control or call-home behaviour. None names a model runtime (Ollama, vLLM), an LLM gateway, or the monitoring stack under an AI platform. One, on AI-assisted vulnerability work, mentions open-weight models and specialised runtimes. The black-box concern applies just as much to the plumbing, and the plumbing was not on the agenda.

What I tell people who ask

If you are buying enterprise hardware this year, here is my recommendation, and I want it to be unmissable.

Buy it from Lenovo, HPE, Dell or Huawei. Servers, storage and network are the easy part: good, supported, and they will outlive the software you first put on them.

Then think ahead with the software stack, and have an alternative before you need one. There are three options:

• 1. The hardware vendor's own first-party software. One accountable party, and it is often already in the contract.
• 2. The largest open-source option, Apache CloudStack or similar. No single vendor can end-of-life it under you.
• 3. Talk to me. I have a solution. Our stack is built in the EU: a packaged, auditable product under a commercial licence, with an exit guarantee.

Whichever you choose, choose it knowing the other two exist. Vendor dependency, as one of today's abstracts on technical debt put it, reproduces itself; it is not a one-off clean-up.

Next week

It was a great day of networking and I will follow it up properly. Over the next week I am going through the recordings as they become available, together with the material from AI Summit Budapest, and I will share what I learned here. If you were in the room and disagree with any of the above, that is what the follow-up is for.