On your own ground: running AI-built software where you choose
In payments there’s always a short list of systems that never touch the internet. Everyone knows which ones they are, nobody argues about it, and the reasons are boring in the best way: the data is sensitive, the rules say so, and the cost of being wrong is too high. When those teams start using AI to build and run software, the first thing they ask is whether any of it can live on that list. Which model is cleverest comes later.
For a lot of AI tooling today the honest answer is no. The orchestration calls out to a hosted service. The logs go to someone else’s dashboard. Cost tracking depends on a provider’s billing API. Take away the connection and the system either stops or keeps going without the parts that made it trustworthy.
I don’t think every organisation needs to run everything on its own hardware. Most don’t. But I do think it should be a choice you make, with the trade-offs in front of you, rather than something your tools decided for you.
Three reasonable places to run
Roughly, there are three options, and each makes sense for someone.
Your own infrastructure. Your data centre, your private cloud, your hardware, operated by your people. You keep control of where data goes and when things change, and you take on the operational work that comes with that. For many regulated and public-sector organisations this is where the conversation starts and ends.
Fully air-gapped. The same, with no network path out at all. Software and models arrive by a controlled process and nothing leaves. It’s more work, and for certain systems it’s the only acceptable answer.
A hosted control plane. Someone else runs the coordination layer, and you decide where the work itself happens. This is the fastest way to get going and the right fit for teams whose constraints are about speed rather than residency.
None of these is the virtuous one. They’re answers to different questions about risk, cost and how much operational work you want to own. What matters is that the system you choose works properly in the option you need, rather than offering a reduced edition for the harder ones.
What has to stay inside
If you do need your own ground, the trick is spotting the quiet dependencies. A product can run on your servers and still rely on the outside world in ways that only show up on the day the connection goes.
The models need to be ones you can run yourself, under terms that a supplier can’t change underneath you. Open-weight models make this practical, and deploying local models goes into what that looks like.
The record of what happened needs to be kept where you are. If the evidence of what your AI did lives in someone else’s service, an outage or a contract dispute takes your evidence with it.
Identity and approvals need to work without phoning home. If you can’t tell which agent did what, or who approved it, without an outside service being up, the record isn’t really yours.
And cost control has to work offline. A budget that’s enforced by calling a provider’s billing API stops being enforced when there’s no provider.
Why regulators care about the same things
Two pieces of European regulation make the same points from a different direction.
The EU AI Act’s Article 12 asks high-risk AI systems to record events automatically across their lifetime, so that what the system did can be traced (source: EUR-Lex, Regulation 2024/1689, Article 12). The high-risk obligations were scheduled to apply from August 2026, and what to log for Article 12 covers the practical side. Wherever you run, the requirement points at the same thing: a complete record you control.
DORA asks regulated financial entities to manage their ICT risk, including keeping operational logs and being able to recover from incidents (source: Regulation (EU) 2022/2554). A core process that can’t run without an outside service is a dependency you have to account for in that framework.
Neither rule says you must run on your own hardware. But both are much easier to satisfy when the record, the controls and the ability to keep running sit somewhere you can vouch for.
How we think about it
At Deep Thinking we’re building two products that are meant to work together. Kizuna is where AI agents build software under your rules. Voxeltron is where that software is deployed, isolated, secured and kept running. Our line is “build and run software with AI, on your own ground”, and we mean the choice above literally: your own infrastructure, air-gapped if you need it, or our hosted control plane if that suits you better.
We’re designing both so that the harder options aren’t a cut-down edition. Both are in development, we don’t have customers yet, and I’d rather you tested that claim than took it on trust. That’s part of why we’re running a pilot programme.
Questions to ask any supplier
Whatever you end up buying, these questions separate systems designed for your ground from systems that tolerate it.
- Can it run with no outbound connection, permanently? Ask to see it, not to be told about it.
- Where is the record of what the AI did, and can you read and verify it without the supplier?
- Do you control the models? Could a licence change stop you running them in two years?
- How does cost control work when there’s no connection to a provider?
- How do identity and approvals work offline, including revoking access?
- Is anything missing in the on-premises or air-gapped version that the hosted version has?
If the answers are short and specific, the system was probably designed for this. If they’re long and hedged, it probably wasn’t.
If you’re working on this, we’d like to hear from you.