“Should we run AI in the cloud or on our own hardware?” is usually asked as a technology question. It's really four smaller questions, about your data, your cost structure, your appetite for dependency, and your operational reality. Answer those honestly and the decision mostly makes itself.
1. Can your most valuable data legally and culturally leave the building?
Not “is the vendor's DPA acceptable”, can the data leave? For patient records, case files, deal documents, source code and citizen data, the answer is often no, regardless of what the contract says. If the data that would make AI most useful to you is exactly the data you can't send out, cloud AI gives you a capable assistant that isn't allowed to do its job.
A useful exercise: list the five document sets your team would most want an assistant to know. For each, ask whether you'd email it to an external consultancy. That's roughly the bar for sending it to any third party.
2. Which cost shape fits, linear or flat?
Per-seat cloud AI scales with headcount; owned hardware doesn't. Neither is universally better:
| Factor | Cloud (per seat) | On-prem (owned) |
|---|---|---|
| Cost shape | Linear with users | Flat after purchase |
| Small pilots | Cheap to start | Up-front hardware |
| Whole-company rollout | Compounds every month | Same box, more users |
| Budget character | Opex, recurring | Capex, owned asset |
The honest summary: for a five-person trial, cloud wins on cost. For an organisation-wide capability you intend to keep, the flat curve wins, usually sooner than people expect.
3. How much dependency can your workflows tolerate?
Cloud AI means your capability is downstream of someone else's roadmap: models get deprecated, terms get revised, prices move. That's survivable for casual use and painful for load-bearing workflows. The test we suggest: if the vendor doubled the price or retired your model tomorrow, what would break? If the answer is “our core processes”, you're not buying a tool, you're taking on a dependency, and dependencies deserve harder scrutiny.
4. What can your team actually operate?
The traditional argument for cloud was operational: someone else runs it. That argument has weakened as on-prem platforms became appliances. If your bar is “no Kubernetes, no ML engineers, one box, two cables”, that bar is now met. What remains true: you should evaluate on-prem the way you'd evaluate any infrastructure purchase, support, updates, monitoring, evidence for auditors, not as a science project.
The shape of the answer
In practice we see three stable outcomes. Teams with public data and spiky usage stay in the cloud. Regulated organisations with sensitive corpora go on-prem, because nothing else clears legal. And a growing middle group runs both: cloud for generic tasks, an appliance for everything touching the crown jewels. All three are rational, what's not rational is defaulting to the cloud without pricing in the data question, the cost curve, and the dependency.
If you're working through this for your own organisation, our 2026 guide to sovereign deployment in Sweden and the EU goes deeper on the regulatory side, and we're happy to talk through the maths for your headcount.