A question you've answered before
Every operations manager has answered this question already. Just not about AI.
When you bring in a contractor, you decide: do they work on our site or theirs? With our equipment or theirs? Nobody leaves that to chance, because the answer settles who is responsible for what, what the contractor can reach, and what happens when something goes wrong.
AI is no different. Every AI system has a venue - the place where its machinery sits and the thinking actually happens. On the training call I wrote about in the last post, I watched the venue question decide everything without once being named.
Two chairs
The woman I was working with wanted her tender emails screened. Simple enough. But her AI runs inside her company's Microsoft environment, behind security settings her IT department chose, and when we asked it to follow a link in an email and read the tender page behind it, it couldn't. Worse: the first time, it didn't tell us. It swapped in a web search and produced an answer that looked right. Only on the second attempt did it admit the truth: I can't reach that page from here.
My own system reads those same tender pages every morning without asking anyone's permission. The difference between us wasn't skill, budget or ambition. It was venue, plus one thing more. I can change my setup with a decision made over coffee, because I don't have to ask IT. I am IT. She has to ask. For most people in a real organisation, that's exactly how the venue question first arrives - wearing a permissions problem.
Two parts, two places
Here's the idea that makes venue tractable. The thing you're running has two parts, and they can live in different places.
The first part is the rules - the layer that decides when to act, what to look at, what to do with the answer. The second part is the model - the intelligence you send a question to and get judgement back from. In my tender system, the rules live on my own server: wake at this hour, read these emails, visit these pages, score what you find. The judgement comes from a frontier model, reached over the internet each time the rules ask for it. My machinery, their engine.
That split is the most common serious arrangement: your rules calling their model. And here is the part that catches people out, the part that matters more than any other sentence in this post. Your rules living on your own server does not mean your data stays on your own server. Every time the rules ask the model a question, the content of that question travels to wherever the model lives. Data follows the model, not the rules. If that model sits in someone else's cloud, so does everything you send it.
Full control is the other end: both parts on your own hardware, running a model you host yourself. One caution before you claim that nothing leaves the building: a local model does not, by itself, make a local system. Data follows every component that touches it - retrieval, storage, logs, backups - and the model is only the easiest boundary to overlook. Whether a model you can host yourself is good enough for your work is a measurable question, which is why I benchmark it rather than guess.
Four common shapes
Once you see venue as those two parts, the options sort themselves into four familiar shapes. The AI can run entirely inside the provider's app, which is where nearly everyone starts and where you rarely think about venue at all. It can run on your own computer. It can run on a server you control - a rented machine in a data centre, or a box on your own network - usually with the rules there and the model called over the internet. Or it can run on infrastructure the provider hosts and manages for you. If you are relaying this to your IT people, the crosswalk is: the provider's app is SaaS, your own machines are on-prem, a server you control is self-hosted, and provider-managed infrastructure is a managed service.
When AI is a product, you mostly don't think about any of this, because the venue came decided. Usually that means the provider's cloud. The moment you move towards directing a tool or running a service, the choice becomes yours to make, and worth making well.
What the venue decides
No leader cares about server locations for their own sake, and you shouldn't either. Venue matters because it sets four things you do care about.
The first is where your data goes. In a regulated business this is the opening question, and sometimes the only one that matters. We just saw why: the data goes wherever the model is.
The second is what breaks when the provider changes. Prices rise, products get retired, systems go down. The more of your machinery sits on someone else's ground, the more of their decisions become your problems.
The third is where the total cost sits. A subscription, metered usage, or hardware and electricity are only how the bill arrives. The full cost includes the engineering, the monitoring, and the operating burden each shape carries - and it shifts as the work scales. Moving venue changes your cost structure, not just your invoice.
The fourth is the ceiling on capability. A model you host yourself still trades some raw ability for the control you gain. Sometimes that trade is worth making and sometimes it isn't - but it should be a trade you chose with your eyes open, not one you backed into.
Filter first
One warning about sequence. For most organisations, venue is a decision you meet on the way to building something: you pick the work first, then decide where it runs. If your contracts or your regulator say certain data must never leave the building, flip that order. Venue becomes your first filter, applied before you shortlist a single use case, because it rules out whole approaches before you've spent a minute designing them. Work out which kind of organisation you are before the architecture conversation starts, not halfway through it.
Your site or theirs
Which brings us back to the contractor. Your site or theirs, your equipment or theirs. You've made this call many times about people, and you already know how to make it well: deliberately, early, and with the consequences in view.
In the last post I said that moving from using to directing to running hands you decisions the provider used to make. This is the first of them, and the one with the sharpest edge. Where it runs decides where your data goes, what can break, what it costs, and what it can do. That's worth deciding on purpose, rather than inheriting by accident.
The one-page card version is here: Where Does It Run?
Hit reply and tell me where your AI runs today - and whether anyone actually chose it.
-- Alastair