This guide covers why that shift is happening now, which sectors in Sweden and the wider EU are actually deploying local AI, what the deployment options look like, and what to demand from any vendor who says the word “sovereign”.

Why European organisations are bringing AI in-house

The baseline is the GDPR. The moment an employee pastes a customer record, a patient note or a personnel file into a cloud assistant, the organisation is processing personal data on someone else's infrastructure, which triggers processor agreements, transfer analyses and, when things go wrong, fines that can reach 4% of global turnover. None of that paperwork exists for a model that never leaves the building.

The second driver is the transfer problem the Schrems II judgment created in 2020 and no amount of contractual engineering has fully solved since. Data residency is not data sovereignty: a US-owned cloud region in Frankfurt or Stockholm is still subject to US law, including the CLOUD Act's reach into data held abroad by American providers. For Swedish public bodies and German regulated industries alike, that residual risk has quietly shaped cloud policy for half a decade.

The third driver has a timetable: the EU AI Act entered into force in August 2024 and its obligations arrive in phases. Self-hosting does not exempt anyone from the Act, but it makes the compliance file dramatically simpler, because the deployer controls the logs, the model versions and the data flows it must document.

Around the AI Act sits a thicket of sector rules pushing the same direction: NIS2 for critical infrastructure, DORA for financial institutions since January 2025, professional privilege for law firms, and secrecy legislation for the public sector. In Germany, works councils and BSI security expectations add their own gravity toward on-premise deployment.

Who is deploying local AI in Sweden and the EU

Adoption follows a simple pattern: the sectors deploying local AI first are the ones that were never able to use cloud AI properly in the first place.

• Healthcare, clinics and care providers running assistants over patient documentation, where GDPR Article 9 special-category data rules out external processing.
• Legal, firms that cannot put privileged client material into any third-party service, but still want drafting, summarisation and research over their own matter files.
• Financial services, banks and insurers balancing DORA, banking secrecy and outsourcing rules, where an on-premise model sidesteps the vendor-risk file entirely.
• Public sector, Swedish agencies and municipalities whose cloud caution since Schrems II is well documented, and who increasingly specify sovereignty in procurement.
• Manufacturing and defence, companies protecting product IP and export-controlled information, often on air-gapped networks where cloud AI is simply impossible.

What these organisations run locally is no longer a compromise: private ChatGPT-style chat for employees, retrieval-augmented answers over internal documents, drafting and summarisation, and OpenAI-compatible APIs that let internal tools call a local model exactly as they would call a cloud one.

The vendor landscape splits into three camps. Hyperscalers now market “sovereign cloud” regions, better than nothing, but the stack, the keys and the legal entity questions remain debated. European API providers keep inference on EU soil but still off your premises. And a third camp puts the AI inside your building: Kaldryn, built by Pontén Solutions in Stockholm, is a Swedish example of that approach, shipping Kaldryn One, a locker-sized appliance that runs a full ChatGPT-class assistant, 200+ open models and an OpenAI-compatible API entirely inside the customer's network.

Appliance or DIY: the two ways to go local

Every organisation that decides to run AI locally faces the same fork. The DIY route assembles open-source parts, an inference server such as vLLM or Ollama, open-weight models, a vector database, a chat UI, and it works, as every lab prototype proves. The hidden cost is everything around the model: SSO, DLP, audit logging, model provenance, GPU drivers, upgrades and an on-call rota. It is a realistic path only for organisations with a platform team to spare.

The appliance route buys the same outcome as a product: pre-built GPU hardware with the platform pre-installed, deployed in minutes and owned like any other piece of IT equipment.

• DIY: maximum flexibility; you own integration, hardening and lifecycle. Budget for engineering time, not licenses.
• Appliance: turnkey, plug in power and ethernet, index your documents, serve the whole team. Kaldryn One is built for exactly this.
• Hybrid: start with one appliance for a department; scale to racks or your own servers later without changing the platform.

The economics favour local more than most buyers expect. Per-seat cloud AI compounds: Microsoft 365 Copilot lists at $30 per user per month, roughly $10,800 a year for a 30-person company before add-ons. A local deployment inverts the model: a fixed hardware cost, then electricity, with unlimited users and unlimited prompts. In the Nordics, where power is comparatively cheap and largely fossil-free, running your own GPUs is also the low-carbon option.

A buyer's checklist for sovereign AI

Whatever vendor you evaluate, including us, these are the questions that separate sovereignty from sovereignty-washing:

1. European entity: is the vendor an EU/EEA company, contracting under a European legal system?
2. GDPR Article 28: is a data-processing agreement offered, or better, is the architecture such that the vendor never processes your data at all?
3. Training clause: does the contract state, in writing, that your data is never used to train anyone's models?
4. The unplug test: ask the vendor to disconnect the internet during the demo. Sovereign AI keeps working.
5. Model provenance: are model weights signed and verified, so you know exactly what is running?
6. Ownership and exit: do you own the hardware, and does the system keep running if the vendor disappears?
7. EU AI Act artefacts: does the platform produce the logs and technical documentation the Act expects from deployers?
8. Security integration: SSO/SAML, DLP, immutable audit logs and SIEM export, sovereignty includes your security team.

Sweden, Germany and the Nordic moment

There is a reason so much of this movement is centred on northern Europe. Sweden combines very high digitalisation with a strong privacy culture and a public sector that writes sovereignty into procurement. Germany brings the Mittelstand's instinct to keep IP in the house, works councils with a real say over employee-data tooling, and BSI-shaped security expectations. Add Nordic electricity prices and the region's fossil-free grid, and the calculus lands in the same place: for a Swedish or German organisation in 2026, the question is rarely whether local AI is possible, it is which box to plug in.

The bottom line

Cloud AI will remain the default for workloads that carry no sensitive data. But for the European organisations that handle patient records, client files, financial data or state secrets, the direction of travel is set: AI is becoming something you own, not something you rent. Sovereignty stopped being a philosophy the day it became a procurement checkbox.

What moved

The two deadlines that moved are the ones for high-risk systems, which were always going to be the heaviest lift.

• The rules for standalone high-risk systems listed in Annex III (think biometrics, critical infrastructure, hiring, credit scoring, access to essential services) were due to apply from 2 August 2026. They now apply from 2 December 2027.
• The rules for high-risk AI embedded in regulated products under Annex I (medical devices, machinery and the like) moved from 2 August 2027 to 2 August 2028.

The main reason is prosaic. The harmonised technical standards that companies need in order to actually prove conformity were running late at CEN and CENELEC, the European standards bodies. You cannot ask firms to meet a bar that has not been drawn yet. So the co-legislators drew the bar's deadline forward in time instead. The European Parliament's own write-up of the March committee vote lays out the logic.

What did not move

This is the part people miss. Plenty of the AI Act is already in force and none of it was delayed.

The ban on prohibited practices has applied since 2 February 2025. The AI literacy duty in Article 4, which says staff who use AI systems need a baseline understanding of them, has applied since the same date. The obligations on general-purpose AI models kicked in on 2 August 2025, along with the governance and penalty framework. And the transparency duties in Article 50, the ones that say you have to tell people when they are talking to a machine and label AI-generated content, still apply from 2 August 2026. They were not touched.

The penalties are unchanged, and they are large

None of this softened the enforcement side. Article 99 still sets fines of up to 35 million euro or 7 percent of global annual turnover for prohibited practices, up to 15 million euro or 3 percent for most other breaches, and up to 7.5 million euro or 1 percent for supplying wrong information to authorities. You can read the exact tiers on the AI Act Explorer. For a mid-sized firm, the percentage figures are the ones that bite.

What a deployer should actually do

Strip away the calendar noise and the to-do list is short. Work out where AI is already being used across the organisation, including the tools nobody officially bought. Sort each use into a bucket: banned, high-risk, limited-risk (which mostly means transparency duties), or minimal. Get the AI literacy training done, because it is already overdue and it is one of the cheapest boxes to tick. And for anything that even might be high-risk, name an owner now, because December 2027 arrives faster than it sounds when standards, documentation and human-oversight processes all have to be in place first.

One quieter point. A lot of the deployer burden is about evidence: keeping logs, pinning the exact model version you assessed, being able to say what the system does with an input. All of that is easier when the model runs on infrastructure you control rather than behind a vendor's API that can change under you. Sovereignty and compliance are not the same thing, but they rhyme.

This is general information, not legal advice. The omnibus text was still being finalised in the Official Journal as this went out, so confirm the final regulation number and any national guidance with your counsel before you act on it.

That's it. A locker-sized black appliance, quieter than the office fridge, plugged into a normal wall outlet and your network switch. Inside it: your company's entire AI capability. Chat over your own documents, more than two hundred curated open models, an OpenAI-compatible API, and not a single byte leaving the building.

The problem with “just use the cloud”

For a lot of teams, cloud AI is genuinely fine. But every conversation we had with hospitals, law firms, banks and public agencies across the Nordics followed the same arc: people were getting real value out of consumer AI tools, leadership wanted that capability properly, and every path to it ran through somebody else's infrastructure, under somebody else's terms.

• The pricing scales with headcount. Per-seat AI subscriptions are a tax on growing.
• The data leaves. However good the contract is, a prompt typed into a cloud assistant physically departs your premises.
• The dependency compounds. Models get deprecated, terms get revised, prices change, and your workflows are built on all of it.

For regulated organisations, the second point alone often ends the discussion. Our answer is not “trust us instead”. It's: don't send the data anywhere at all.

Constraints make products

We gave ourselves three constraints for the appliance, and they shaped everything:

1. It has to live in an office, not a server room. That set the acoustic budget (under 38 dB, quieter than normal conversation), the power budget (a regular wall outlet, no three-phase), and the size (locker, not rack).
2. An IT team of one has to run it. Two cables, power and ethernet. It arrives pre-configured, indexes your documents on-box, and serves your team the same day.
3. It has to keep working with the internet unplugged. Not as a party trick, as the operating assumption. Updates are something you choose to apply, not something that happens to you.

What “a datacenter” actually means for a 30-person firm

The phrase sounds grandiose, but look at what a small organisation actually needs from AI infrastructure: an assistant that knows its documents, a private API for the tools it builds, and governance a lawyer can sign off. That's not a hyperscale problem. It fits in a box, GPUs, storage, models, retrieval, admin console, audit log, all of it.

One box for a thirty-person firm. Racks of them for a data center. The platform is the same either way, which is exactly the point. Sovereignty shouldn't be an enterprise luxury.

What's next

We're publishing more of the thinking behind the platform here on the blog, the engineering trade-offs, what runs well on one box in 2026, and what we're hearing from the regulated side of the market. For the deeper technical material, the research hub has the reference architecture and compliance white papers. And if you'd rather just see the box: meet Kaldryn One.

The phased timeline

What you should already be doing

Two obligations have applied to essentially every organisation using AI since February 2025:

• Avoiding prohibited practices. The banned list (manipulative techniques, social scoring, most emotion recognition in workplaces, and similar) applies regardless of company size or sector.
• AI literacy (Article 4). Staff who operate or use AI systems must have a sufficient level of AI literacy. This is a real, current obligation, and one of the easiest to evidence with a training module and a record of completion.

What lands on 2 August 2026

The big one. From this date the high-risk regime applies to Annex III use cases, think employment and HR screening, credit scoring, essential services, education, and most public-sector decision support. Deployers of high-risk systems get concrete duties: use the system per its instructions, ensure human oversight, keep logs, feed incidents back to the provider, and in some cases run a fundamental-rights impact assessment (FRIA).

Alongside it, the Article 50 transparency duties apply: people must be told when they're interacting with an AI system, and AI-generated content must be disclosed in a machine-readable way where required.

Where self-hosting changes the picture

The AI Act doesn't care where your servers are, obligations follow the use case, not the hosting model. What self-hosting does change is how much of the evidence chain you control. When the model runs on your hardware, you can pin the exact model version you assessed, produce your own logs without waiting on a vendor, and answer "what does the system actually do with inputs" from first-hand knowledge rather than a sub-processor list. That's why Kaldryn ships the deployer tooling, transparency banner, AI-literacy module, FRIA/DPIA templates and an immutable audit log, in the box.

Sensible next steps

1. Inventory your AI use and sort it: prohibited (stop), high-risk (prepare for Aug 2026), limited-risk (transparency), minimal (document and move on).
2. Stand up AI-literacy training now if you haven't, it's already due.
3. For anything potentially high-risk, assign an owner for the deployer duties and start the FRIA groundwork this year.

It started in a courtroom

The turning point most people can name is Schrems II, the 2020 ruling from the EU's top court that struck down the main legal bridge for sending personal data to the United States. The court's problem was structural, not petty: US surveillance law let American agencies reach data held by American providers, and a European whose data got caught up had no real way to object. That mismatch has never been fully resolved. Each replacement arrangement has been challenged, and the current one sits on the same fault line as the two that fell before it.

Then people read the fine print

Underneath the court case was a quieter realisation about the US CLOUD Act. In plain terms, it can compel American providers to hand over data they hold, even when that data is stored on servers physically located in Europe. Read that twice. Your data can sit in a data centre in Frankfurt or Stockholm and still be reachable under a foreign law, because the company holding it answers to a foreign government. For a hospital, a ministry or a bank, that is not a comfortable footnote. It is the whole problem.

2026 is when talk turned into moving vans

For years this was a debate. Recently it became action. In June 2025 Denmark's digitalisation ministry announced it was moving off Microsoft software toward open-source alternatives, citing sovereignty and cost, as reported at the time. The German state of Schleswig-Holstein set out to shift tens of thousands of machines to Linux and open tools, as the trade press covered. And in May 2026 the Swedish government adopted its first national cloud policy, stating outright that the country is too dependent on suppliers outside the EU. The European Commission followed with a proposed Cloud and AI Development Act built around the same worry.

Where AI walked straight into it

Here is the irony. Just as Europe grew wary of sending sensitive data to foreign clouds, along came a technology that wants to send it all: prompts, documents, context, the lot, straight to a provider's model. Adopting cloud AI carelessly undoes years of careful work on data transfers in a single procurement.

Which is why running AI locally is not really a fringe stance any more. It is the same instinct that is moving government offices to open source, expressed at the level of a single tool. Keep the capability, keep the data at home. We happen to be a Swedish company that built AI this way from the start, so we are not surprised the continent is arriving here. We just got here early.

What it covers, and what it asks

The CRA applies to products with digital elements, which is a deliberately wide net: hardware and software that can connect to a device or a network, from smart home gadgets to operating systems, firewalls and password managers. If you place such a product on the EU market, you inherit a set of duties. The Commission's CRA pages are the reference.

The core requirements are the sort of thing security people have asked for politely for a decade and are now getting in law. Products have to be secure by design and secure by default. They must ship without known exploitable vulnerabilities. Makers have to run a real vulnerability-handling process, with coordinated disclosure and free security updates across a defined support period. And they have to produce a software bill of materials, an SBOM, so buyers can actually see what is inside the thing they bought.

How it touches AI systems

An AI product is still a product. If it has digital elements and it goes on the market, the CRA's security-by-design and vulnerability-handling duties apply to it like anything else, sitting alongside whatever the AI Act asks. There are carve-outs, notably for non-commercial open-source software and for products already covered by sectoral rules like medical devices, but the general software case is squarely in scope.

There is a reporting edge worth flagging for anyone shipping software. From 11 September 2026, makers have to report actively exploited vulnerabilities and severe incidents to ENISA and national response teams on a tight clock, with an early warning inside 24 hours. That is a real operational obligation, not a paperwork one.

The self-hosting angle

The CRA does not care whether your AI runs in the cloud or on your own metal. Its duties attach to products, not deployment locations. But the philosophy behind it, know what your software is made of, patch it, do not ship known holes, is far easier to honour when you control the stack. When you run an AI system in-house, you can produce a real SBOM, apply updates on your schedule, and account for every component. When your AI capability is a remote API, your supply-chain visibility ends at the vendor's edge, and you are trusting their CRA compliance as much as your own.

Regulators keep circling the same idea from different directions. The EU cybersecurity agency ENISA has documented for years how supply-chain attacks reach customers through their suppliers rather than head-on. The CRA, DORA and NIS2 all push the same way: know your dependencies, shorten your chains, own your risk. Keeping AI on-premise is one concrete way to do all three at once.

This is general information and not legal advice. The CRA's scope, classes and timelines have real nuance, so confirm how it applies to your specific product with a qualified adviser.

“Do we need a GPU cluster and a DevOps team?”

No. This is the assumption that stops most teams from even evaluating on-prem, and it's a few years out of date. A modern open-weights model, quantized and served well, delivers a genuinely useful assistant on a single appliance-class machine. Kaldryn installs on a fresh Ubuntu server in under ten minutes, no Kubernetes, no platform team. If you can rack a NAS, you can run your own AI.

“Are open models actually good enough?”

For the everyday work an internal assistant does, drafting, summarising, answering questions over your own documents, yes, and the gap to frontier cloud models has narrowed every quarter. The trick is matching the model to the job: a fast small model for chat and retrieval, a bigger one for heavy drafting. Kaldryn ships 200+ curated models with signed weights, so choosing isn't a research project.

“Who maintains it?”

The same person who maintains the rest of your infrastructure, which is to say, not much of anyone, most weeks. The platform monitors itself, the admin console shows what your users are doing (and what they're trying to do, the DLP log is illuminating), and updates are explicit: you decide when, they're signed, and you can defer them indefinitely on air-gapped deployments.

“What happens when the internet goes down?”

Nothing. That's the whole design. Retrieval, chat, the API, everything runs on-box. An internet outage that takes the office offline takes your cloud AI subscriptions with it; the appliance in the corner doesn't notice.

“What does it cost, really?”

Owned hardware is a fixed cost; per-seat cloud AI is a linear one. The crossover point depends on your headcount and usage, but the shape of the curve is the part to internalise: an appliance costs the same whether ten people use it or two hundred. Past a modest team size, “unlimited users, just electricity” stops sounding like marketing and starts being the spreadsheet.

“How do we prove to compliance that nothing leaves?”

This is where on-prem flips from being the cautious choice to the easy one. The answer isn't a vendor questionnaire and a sub-processor list, it's a firewall rule and a packet capture. Kaldryn seals its network perimeter on boot and ships the evidence tooling (immutable audit log, SIEM export, isolation checks) to demonstrate it. Your DPO gets an architecture where the sensitive question, where does the data go?, has a one-word answer: nowhere.

Evaluating a deployment for your own team? The reference architecture covers the technical detail, and our EU regulation briefings cover the compliance side.

That sounds obvious until you look at how most enterprises consume AI today. A prompt typed into a cloud assistant leaves the building, is processed on infrastructure the customer never sees, under a contract that can be revised, and is often retained for some period for abuse-monitoring or training. For a marketing team that trade-off is fine. For a hospital, a law firm, a bank, or a defence contractor, it is frequently a non-starter.

The three layers of sovereignty

It helps to be precise, because vendors use the word loosely. True sovereignty has three independent layers, and a deployment is only as sovereign as its weakest one:

• Data sovereignty, your inputs, outputs and documents physically stay on hardware you control and are never transmitted to a third party.
• Model sovereignty, you can inspect, pin, and keep running the exact model you deployed, regardless of a vendor deprecating or altering it.
• Operational sovereignty, the system keeps working without phoning home, even fully air-gapped, and you decide when and whether to update it.

A “private” cloud endpoint typically gives you the first layer on paper and none of the others. A downloaded open-weights model gives you model sovereignty but leaves you to solve operations, governance and security yourself. Sovereign AI as a product category is the attempt to deliver all three at once.

Why now

Three forces are converging. First, regulation: the EU AI Act, GDPR enforcement, sector rules like DORA and NIS2, and national data-residency expectations have made “where does the data go?” a board-level question. Second, capability: open-weights models are now good enough that a self-hosted assistant is genuinely useful for drafting, summarising and document Q&A, the gap to frontier cloud models has narrowed for everyday enterprise tasks. Third, economics: per-seat cloud AI pricing scales linearly with headcount, while owned hardware is a fixed cost that the organisation keeps.

“The question has quietly flipped. It used to be “why would we run AI ourselves?” Now, for regulated buyers, it is “why are we still sending this data to someone else?””

What sovereignty is not

Sovereignty is not isolationism, and it does not mean giving up a modern experience. A well-built sovereign platform still offers streaming chat, retrieval over your own documents, image understanding, an admin console and an API, it simply runs them on metal you control. Nor does sovereignty mean “air-gapped or nothing”: most organisations run connected for convenience and reserve full network isolation for their most sensitive workloads. The point is that the choice is yours to make and to change.

Who needs it first

Adoption is led by the organisations with the least room to be wrong about data handling:

• Healthcare, patient data under GDPR Article 9, MDR/IVDR and the emerging European Health Data Space.
• Legal, privilege and client confidentiality that cannot survive a third-party processor.
• Finance, DORA, supervisory expectations and the sensitivity of transaction and client data.
• Defence and public sector, classification, national sovereignty and air-gapped environments by default.

What these sectors share is that the cost of a data-handling mistake is measured in licences, lawsuits and lives, not churn. For them sovereignty is the baseline, and a capable assistant on top of it is the prize.

Getting there

The practical path is less daunting than it sounds. Sovereign AI runs on commodity GPU servers or even capable CPU nodes for smaller models; it installs in minutes rather than requiring a Kubernetes platform team; and the governance, isolation and compliance tooling that regulated buyers need can ship in the box rather than being assembled from a dozen projects. That is the bet Kaldryn is built on, and the rest of this research hub goes deeper on each layer, from reference architectures to EU AI Act compliance.

Design goals

• Zero data egress, no inference input, output or document ever leaves the perimeter.
• No phone-home, licensing, updates and operation work without outbound internet.
• Single-server start, cluster-ready growth, scale out without rebuilding.
• Defence in depth, isolation enforced at multiple independent layers.
• Operable by a small team, no dedicated platform or DevOps org required.

The five planes

It is useful to decompose the appliance into five planes, each with a clear responsibility:

1. Serving plane, the model runtime (e.g. vLLM and Ollama behind a load balancer) with tier-aware routing across CPU and GPU nodes.
2. Retrieval plane, document ingestion, embeddings, a vector store and security-trimmed RAG so answers cite your own files.
3. Identity plane, SSO/SAML, group-to-role mapping and just-in-time provisioning, with metadata upload for air-gapped IdPs.
4. Governance plane, DLP scanning, an immutable audit log, and policy enforcement on every inbound and outbound message.
5. Observability plane, latency percentiles, tokens/sec, queue depth and KV-cache utilisation per tier.

Network topology

For the air-gapped deployment, the topology is intentionally boring. Clients reach the appliance over the internal network only; the appliance has no default route to the internet. Where an organisation wants connected convenience for some workloads and isolation for others, the recommended pattern is a single appliance running in data-isolation mode with egress sealed, rather than two separate systems to keep in sync.

Air-gapping should never rely on one toggle. We recommend three independent layers:

• Application layer, outbound networking disabled at the code level so the software cannot initiate external calls.
• Host layer, an egress firewall (e.g. nftables) that drops outbound traffic regardless of application behaviour.
• Network layer, no route to the internet from the appliance's VLAN, verified by the customer's own controls.

GPU sizing

Sizing is driven by three variables: the parameter count and quantisation of the models you intend to serve, your target concurrency, and your latency budget (time-to-first-token and tokens/sec). As rough guidance, always validate with your own benchmark on your own hardware:

The important architectural property is that moving between these tiers is a capacity change, not a re-platforming. Tier-aware routing lets you add nodes and point heavier workloads at GPU tiers while lighter ones stay on cheaper hardware.

Model serving and provenance

Each model should be verified by content hash on first load and pinned thereafter, so the weights you reviewed are the weights that run. A provenance grade, covering license, source, stability and integrity, lets administrators make informed choices from a curated catalogue rather than pulling arbitrary weights from the internet. We cover this in depth in our note on model provenance.

Governance on the hot path

DLP and audit are not bolt-ons; they sit on the message hot path. A regex-and-rules scan runs on every inbound and outbound message to block, redact or audit PII, secrets and network data, and every action is written to an immutable, SIEM-exportable log. Because nothing leaves the perimeter, this audit trail is also the organisation's complete record for eDiscovery and supervisory review.

Deployment and day-two operations

The reference deployment is a single signed, checksummed installer that carries every image, model and dependency, runs preflight checks, stands up services and warms a default model, no manual wiring. For air-gapped sites, updates arrive as signed media rather than over the network, and restores run detached so the appliance cannot be bricked by a bad upgrade. The goal throughout is that a small IT team, not a platform org, can own it.

Want the full version of this reference architecture, including diagrams and a sizing worksheet? Talk to our team, we provide it under NDA for evaluation.

The number that started the conversation

Estimates vary, but the shape is consistent and uncomfortable. Something like ninety percent of Europe's digital infrastructure runs on non-European, mostly American, providers, and the three big US hyperscalers hold roughly two-thirds of the European cloud market. The European providers' share actually fell over recent years. Analyses like the EuroStack work from the Bertelsmann Stiftung lay out the dependence in detail. Once you see the figures, a lot of European policy over the past two years reads as a single reaction to them.

The laws catching up

Several legal threads pull in the same direction. The EU Data Act, applicable since September 2025, is dismantling the fees and technical obstacles that lock customers into a cloud provider, and it obliges providers to guard non-personal data against unlawful foreign-government access. The GDPR's transfer rules, shaped by the Schrems II ruling, keep the risk of sending personal data abroad firmly on the table. And in June 2026 the Commission proposed a Cloud and AI Development Act, part of a wider tech-sovereignty package, whose own framing is blunt: over-reliance on non-EU cloud providers is a significant risk to Europe's digital autonomy. The proposal talks about tripling EU data-centre capacity and defining tiers of cloud sovereignty, the strongest of which rules out third-country corporate control for the most sensitive public workloads.

Sweden puts it in writing

This is not only a Brussels story. On 28 May 2026 the Swedish government adopted its first national cloud policy for public administration, stating in plain Swedish that the country is heavily dependent on suppliers outside the EU. The policy does not ban American cloud. It requires risk assessments, open standards, clear contracts and exit plans, so that a public body can actually leave a provider if it needs to. The direction is unmistakable even where the language is careful.

From policy to actual migrations

The most telling signal is that organisations stopped waiting for the laws to finish. In June 2025 Denmark's digitalisation ministry announced a move from Microsoft software toward open-source alternatives, on explicit sovereignty grounds, as reported at the time, with Copenhagen citing a Microsoft licence bill that had climbed sharply over five years. In Germany, the state of Schleswig-Holstein set out to move tens of thousands of machines off Windows and Office to Linux and open-source tools, projecting real annual savings, as covered in the trade press. These are not startups making a point. They are governments moving payroll and email.

Where AI fits

AI sharpens every part of this. An assistant that sends prompts and documents to a foreign-controlled cloud is the exact dependence the sovereignty debate is about, applied to your most sensitive internal knowledge. Running the model on your own hardware is not a clever hedge against the trend. It is the trend, expressed at the level of a single deployment. When the computation happens where the data already lives, there is no provider to be locked into, no border to defend, and no foreign statute that reaches the server.

None of this means American cloud is going away, and this guide is not a prediction that it should. It is a map of a real shift in what European institutions consider prudent. For a Swedish company that has always built AI to run inside the customer's walls, the map mostly confirms a bet we made early. The rest of the continent is now describing, in law and in budgets, the thing we build.

“Where does the data go, and who is processing it?”

With cloud AI this question spawns a diagram: your organisation (controller), the AI vendor (processor), their infrastructure provider (sub-processor), possibly a transfer mechanism if anything touches a third country. Each hop needs contracts, assessment and monitoring.

With a self-hosted deployment the diagram collapses: the data goes to a machine you own, processed by software you operate. There is no processor for the inference step, no sub-processor chain, no international transfer. Whole categories of GDPR homework, DPAs for the AI vendor, transfer impact assessments, sub-processor change notifications, simply don't arise for the core processing.

“What's our lawful basis, and did we minimise?”

Hosting doesn't change this one: you still need a lawful basis (typically legitimate interests for internal productivity tooling, with a documented balancing test) and you still need data-minimisation discipline. What helps in practice is control at the gateway: DLP rules that stop obvious over-sharing (personnummer, card numbers, patient identifiers) before it reaches the model, and retention settings you define rather than inherit from a vendor's policy.

“Can we actually delete? What about the embeddings?”

The Article 17 question is where LLM deployments get genuinely technical. A person's data can live in five places: chat histories, uploaded documents, the vector index built from those documents (embeddings), any fine-tuned model trained on them, and backups. An honest erasure story has to reach all five.

“Do we need a DPIA?”

Usually yes, and you should want one anyway, a DPIA is where the design decisions (what data the assistant can see, who can query what, retention, access) get made deliberately instead of by default. The EDPB's work on AI models (notably its Opinion 28/2024 on personal data in model training) is worth your DPO's time here; among other things it underlines that whether a model itself contains personal data is a case-by-case question. Self-hosting makes the mitigations section of the DPIA notably shorter: no third-party access, no transfers, physical control of the hardware.

“What do we tell employees?”

Transparency duties apply regardless of hosting: update your internal privacy notice, be clear about what's logged (admins can typically see usage), and set rules for what belongs in prompts. An internal AI-use policy plus the AI-literacy training you already owe under the AI Act covers most of it.

The short version for the steering meeting: GDPR applies either way, but self-hosting converts your hardest external-dependency questions into internal engineering questions, and internal engineering questions have answers you can verify.

First, self-hosting is not an exemption

A common misconception is that running AI on your own hardware puts you outside the EU AI Act. It does not. The Act regulates the deployment and use of AI systems based on risk, not on where the GPUs sit. What self-hosting changes is the difficulty of compliance: when data never leaves your perimeter, a whole class of obligations around transfer, processing and residency become architectural facts rather than contractual promises you have to extract from a vendor.

Know your risk tier

The Act is risk-tiered. Most enterprise assistant use, drafting, summarising, internal document Q&A, falls outside the high-risk categories, but you must confirm that for your specific use cases. Deploying AI in areas such as recruitment, credit, biometric identification or critical infrastructure can pull you into the high-risk regime with substantially more obligations. Step one is always a documented classification of each use case.

The transparency obligation (Article 50)

Users must know when they are interacting with an AI system, and AI-generated content must be marked as such where required. In practice this means a transparency notice in the assistant UI, locale-aware and customisable, plus clear labelling of AI output. This is straightforward to satisfy but easy to forget.

AI literacy (Article 4)

From 2025 the Act expects organisations to ensure staff who use AI systems have an adequate level of AI literacy. A short, trackable training module with a certificate is the pragmatic way to evidence this, and it doubles as good change-management when rolling an assistant out to a workforce.

Data governance and GDPR

This is where on-premise deployment pays for itself in compliance terms:

• Data residency, when inference and documents stay on your hardware, residency is a fact of the architecture, not a clause to negotiate.
• Right to erasure (GDPR Art. 17), erasure must propagate across conversations, documents, embeddings, any fine-tuned weights and backups; design for this from day one.
• Lawful basis and minimisation, you still need a basis for processing and should apply DLP to keep sensitive categories out of prompts where appropriate.
• Records of processing, your audit log is also your evidence base.

Logging and traceability

High-risk systems must keep automatic logs, and even outside that tier an immutable, exportable audit trail is the difference between asserting compliance and demonstrating it. Look for SIEM export (syslog or signed webhook) so the AI system's records flow into the same monitoring as the rest of your estate.

Human oversight

The Act expects meaningful human oversight of consequential AI use. Architecturally this means role-gated capabilities, the ability to review and override, and not wiring an assistant directly into irreversible actions without a human in the loop.

A condensed checklist

1. Classify each use case by risk tier and document it.
2. Add an Article 50 transparency notice and label AI output.
3. Roll out and track Article 4 AI-literacy training.
4. Pin data residency to your own hardware; confirm zero egress.
5. Implement erasure that propagates to embeddings, fine-tunes and backups.
6. Apply DLP to inbound and outbound messages.
7. Enable an immutable audit log with SIEM export.
8. Define human-oversight and role-gating policies.
9. Prepare DPIA/FRIA documentation where required.
10. Have EU-qualified counsel review the whole package.

Sector overlays

On top of the horizontal obligations, expect sector rules: MDR/IVDR and EHDS in healthcare; DORA, CRA and EBA expectations in finance; FRIA, an Article 49 registry and NIS2 in the public sector; and national regimes such as Sweden's Dataskyddslagen and Offentlighetsprincipen. A platform that ships these overlays as templates rather than leaving you to build them is doing a meaningful amount of the work for you.

Want the downloadable version of this checklist, pre-filled with a risk catalogue and DPIA/FRIA templates? Get in touch and we will share the compliance kit.

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.

2. Which cost shape fits, linear or flat?

Per-seat cloud AI scales with headcount; owned hardware doesn't. Neither is universally better:

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.

Models are a supply-chain dependency

We have spent a decade learning to scrutinise software supply chains, signing artefacts, pinning versions, generating SBOMs, scanning for tampering. Model weights have largely escaped that scrutiny despite carrying comparable risk: a poisoned or swapped checkpoint can subtly degrade outputs, leak training data, or behave differently from the artefact you evaluated. The fix is to apply the same supply-chain hygiene to models that we already apply to code.

Hash on first load, then pin

The foundational control is simple: compute a content hash of the weights the first time a model is loaded, record it, and pin to it. On every subsequent load the hash is checked. If a file changes, through tampering, corruption or an unnoticed substitution, it no longer matches and the system refuses to run it. This is the model equivalent of a checksummed, signed release, and it gives you a hard guarantee that the weights you reviewed are the weights serving your users.

“Provenance is not about distrusting open models. It is about being able to prove, at any moment, that the thing running is exactly the thing you approved.”

A trust score, not a vibe

Beyond integrity, administrators need to decide which models are appropriate to deploy at all. A structured provenance grade makes that decision auditable by scoring each model across dimensions such as:

• Source and license, is the origin reputable and the license compatible with your use?
• Stability, is the model mature and widely exercised, or experimental?
• Integrity, does it pass hash verification and load cleanly?
• Behaviour, does it pass a canary evaluation on install before anyone relies on it?

Rolling these into a single 0-100 grade, backed by a short canary eval at install time, turns 'which model should we trust?' from a matter of reputation into a documented, repeatable decision a security reviewer can sign off.

Why it matters more on-premise

Paradoxically, running your own models raises the provenance bar rather than lowering it. In a cloud service the provider implicitly owns model integrity; when you self-host, that responsibility moves to you. The upside is that you also gain the control to do it properly, pinning the exact weights, keeping them running regardless of upstream deprecation, and proving the chain of custody to an auditor. Provenance is the discipline that lets sovereignty and trust coexist.

Provenance is one plane of a larger sovereign-AI architecture. For the full picture, see our reference architecture for air-gapped LLM deployment and our primer on sovereign AI.

Two uses, two sets of rules

The EHDS splits health data use into two categories, and the distinction matters.

Primary use is what you would expect: using someone's health data to care for them. Electronic health records, cross-border access when a patient travels, that sort of thing. Secondary use is everything else, research, innovation, policymaking, training a model, and it runs through national health data access bodies that issue permits. The Commission's EHDS pages lay out the phased timeline, with the main secondary-use machinery arriving toward the end of the decade.

The rule that should make AI vendors pay attention

For secondary use, the EHDS does not just wave data out the door. Processing has to happen inside a secure processing environment that meets high privacy and cybersecurity standards. Data is pseudonymised or anonymised. And here is the striking part: you cannot download the personal data out of that environment. You bring your analysis to the data, run it inside the walls, and take only the results away.

Sit with that for a second, because it is a profound statement of principle. The most sensitive data in Europe, the EU has decided, should be processed in a controlled environment that the data does not leave. Researchers come to it. It does not go to them.

Health data was always special, and now it has scaffolding

Under GDPR Article 9, health data is a special category with extra protection, and Swedish rules like the patient data act (patientdatalagen) add their own layer. The EHDS does not replace any of that. It builds infrastructure on top of it, and where AI is a medical device, the Medical Device Regulation comes into play as well. It is a dense stack.

The practical takeaway for anyone building or buying clinical AI is not that the EHDS forces you on-premise today. The phased dates stretch out for years, and much of the detail lives in implementing acts still to come. The takeaway is about direction. When European regulators design their flagship health data framework around secure, no-download environments, they are telling you what "good" looks like for sensitive data. Running the AI where the data already sits is not a fringe position. It is increasingly the one the law is describing.

This is general information, not legal or clinical advice. Health data rules are among the most complex in the book, and the EHDS interacts with the GDPR, the MDR and national law in ways your compliance and clinical governance teams need to work through for your setting.

The obligations, in one paragraph

In-scope entities must take “appropriate and proportionate” technical and organisational measures across a familiar checklist: risk analysis, incident handling, business continuity, supply-chain security, secure development and configuration, vulnerability handling, cryptography policies, access control and MFA. Add to that a strict incident-reporting clock (early warning within 24 hours of a significant incident, incident notification within 72) and personal responsibility for management bodies, and you have the shape of the regime. Penalties scale to €10M or 2% of global turnover for essential entities.

Why your AI deployment is part of this

Nothing in NIS2 says “artificial intelligence”. It doesn't need to. The directive regulates the network and information systems you rely on, and the moment an assistant is drafting your documents, answering questions over your files, or wired into your workflows via an API, it has become one of those systems. Three consequences follow:

• It joins your risk analysis. What data can the AI system reach? Who can query it? What happens if it's compromised or unavailable? These now need documented answers.
• It joins your supply chain review. NIS2 makes you responsible for the security of your suppliers and service providers. Every external AI service is another supplier to assess, contract with, and monitor.
• It joins your incident scope. A breach involving the AI layer, leaked prompts, exfiltrated documents, a poisoned model, is an incident like any other, with the same 24/72-hour clocks.

The supply-chain angle favours shorter chains

Here is the practical observation: every obligation above gets easier when the chain is shorter. A cloud AI dependency means your NIS2 supply-chain duties extend through the vendor and their sub-processors; your incident response depends on their disclosure speed; your continuity planning inherits their outages. A self-hosted deployment turns that external dependency into an internal system, still in scope, still needing hardening and monitoring, but assessed and evidenced by you, on your timeline.

If you're starting now

1. Confirm whether you're in scope (sector + size, in your member state's transposition, in Sweden, via the new cybersecurity act implementing NIS2).
2. Add AI systems explicitly to your asset inventory and risk analysis, shadow AI included.
3. Map your AI supply chain: every external model API, plugin and integration is a supplier.
4. Rehearse the 24-hour early warning with an AI-flavoured scenario once, you'll find the gaps quickly.

Where the confusion comes from

The mix-up is understandable. For years, "AI" meant "a website you log into," so no internet sounded like no AI. But the model itself does not need the internet to think. It needs the internet to be somewhere else, on a provider's servers. Move the model onto a machine in your building and the connection becomes optional. The intelligence was never in the network. It was in the weights, and the weights can sit right next to you.

What it handles without ever phoning home

Here is the ordinary, useful work an offline assistant does, none of which requires a connection to anything outside your walls. It answers questions about your own documents, because those documents live on the same network and the model reads them there. It drafts emails, reports, summaries and replies. It pulls structured information out of messy files: dates, names, figures, clauses. It classifies and routes. It helps people write code against your own systems. It holds a conversation over many turns. And it does all of this at full speed, because there is no round trip across the internet slowing it down.

What it genuinely cannot do

Let me be honest about the trade, because the honest version is still a good deal. An offline assistant cannot look things up on the live web. It knows what is in your documents and what was in its training, not this morning's news or a public website. For a lot of internal work, that is exactly what you want, because the answers should come from your own trusted material, not a random web page. But if your use case genuinely needs live external information, an air-gapped setup is the wrong tool, and you can choose a connected configuration instead. The point is that it is your choice, not a limitation forced on you.

The version most people actually want

In practice, most organisations do not run fully air-gapped. They run connected for convenience and simply keep the AI workload sealed, so the sensitive processing never leaves the building even though the office has internet. The fully offline mode is there for the work that demands it: the classified project, the regulated data set, the environment where an internet connection is itself the risk. Either way, the assistant is capable, fast and private. "Offline" was never a synonym for "worse." It just means the intelligence came to your data instead of the other way round.

How cloud AI bills you

There are two meters running. Per-seat products charge a flat monthly fee for each user. Per-token APIs charge for the text going in and, more expensively, the text coming out. As of 2026 a mid-tier frontier model runs somewhere around two to three dollars per million input tokens and ten to fifteen dollars per million output tokens, going by the published rates from Anthropic, OpenAI and Google. There are also much cheaper small-model tiers, some down at ten to forty cents per million tokens, and for light workloads those are genuinely hard to beat.

That last point matters, so I will say it plainly. If a handful of people use AI occasionally, the cloud is probably cheaper than buying a GPU, and you should use the cloud. The economics of local AI do not turn on the simple case. They turn on volume.

Where the meter starts to hurt

Costs stop being trivial in three situations. The first is concurrency: lots of people using the assistant at once, all day. The second is retrieval over long documents, where every question drags a large chunk of context through the model and every token is billed. The third is agentic use, where the model calls itself in loops to complete a task, quietly multiplying the token count by ten or more. A single power user running agentic workflows can burn through hundreds of thousands of tokens a day. Multiply that by a department and the monthly invoice stops looking like a rounding error.

This is the profile where owning the hardware changes the picture, and it happens to be the exact profile of a company that wants AI woven into daily work rather than used as a novelty.

The break-even, honestly

There is a useful 2025 study on this, a cost-benefit analysis of on-premise LLM deployment, and its numbers are worth quoting because they are neither hype nor dismissal. A single modern consumer GPU can serve a 24 to 32 billion parameter model at roughly 150 to 200 tokens per second. For a small but steady workload, the authors find hardware paying for itself against commercial API costs in months, sometimes in under one. For larger deployments on data-centre GPUs, the payback stretches to a few years, and it only holds if you actually keep the hardware busy.

That caveat is the whole game. A GPU you bought and left idle is the most expensive way to run AI ever devised. The break-even assumes sustained utilisation, and independent analyses put the crossover point where self-hosting beats cloud at somewhere north of fifty percent steady usage. Below that, you are paying for silicon that naps.

The line item nobody budgets

Here is where most do-it-yourself on-premise projects quietly bleed money. It is not the hardware. It is the person. Running your own inference stack means someone has to keep models updated, GPUs healthy, drivers current and security patched. Analyses of on-prem total cost of ownership repeatedly find that a fractional infrastructure engineer, call it half a full-time role at seventy-five to a hundred thousand a year, is the single largest three-year line item, larger than the servers.

This is the honest weak point of naive self-hosting, and it is also precisely the problem a managed appliance exists to solve. When the box arrives pre-configured and someone else handles the updates and monitoring, that staffing line disappears from your budget. The distinction between "run your own models" and "own an appliance that runs your models" is mostly this line item.

The value that is not on the invoice

Cost comparisons that stop at tokens miss the reason most of our customers are here in the first place. When the model runs in your building, your data never becomes a transfer to assess, a breach waiting to be reported, or a dependency on a provider that can change its prices or its terms. IBM's 2025 breach research puts the global average cost of a data breach at 4.44 million dollars, and flags a real premium when unsanctioned AI tools are involved. None of that shows up in a per-token quote, but it is real money and real risk.

How to actually decide

Skip the vendor spreadsheets and do this instead. Estimate your steady-state usage in tokens per month, honestly, including the agentic and long-context workloads you plan to grow into. If it is small and likely to stay small, use the cloud and enjoy it. If it is large, or growing fast, or touching data you cannot send outside the building, price the owned option properly, including the staffing you will avoid with a managed appliance, and compare it to the cloud bill you would be signing up to pay every month, forever. For a lot of regulated, AI-hungry organisations, that comparison is not close. For others it genuinely is, and we would rather tell you so than win a deal you will regret.

Where open models are genuinely good now

The enterprise sweet spot is drafting, summarising, classifying, extracting and answering questions over your own documents. On these tasks, leading open-weight models like Llama 4, Qwen 3.5, Mistral and DeepSeek score within a few points of closed frontier models on standard knowledge benchmarks, according to public leaderboards, and in practice are widely judged production-ready. If your use case is a private assistant that reads your files and helps people write, the model is not your bottleneck any more.

Where open models still trail is the hardest end: multi-step agentic coding, the trickiest reasoning, the frontier of the frontier. If that is your core workload, weigh it honestly. For the back office, it rarely is.

Why leaderboards will mislead you

Treat public benchmark scores with suspicion, for two reasons. First, the classic benchmarks are saturated. MMLU, the one everyone quotes, is so close to maxed out that a two-point difference between models is noise, not signal. The field has moved to harder tests of coding, reasoning and long-context retrieval precisely because the old ones stopped discriminating. Second, and more important, none of these tests are your work. A model that tops a leaderboard on general knowledge can still be mediocre at summarising your specific contracts in your specific house style. The only benchmark that predicts your results is your tasks.

Provenance and licence are part of the score

For regulated work, raw capability is not the only axis. Two others matter as much. The first is provenance: where the weights came from, whether they are signed, whether you can pin the exact version you evaluated so it cannot change under you. The second is licence, which varies a lot between open models and decides whether you may actually use a given model commercially. It is worth noting that several of the strongest open models in 2026 come from Chinese labs, which is not a problem in itself when you run the weights entirely on your own hardware and nothing phones home, but it is a fact a careful buyer should know and reason about rather than discover later.

The reassuring part of running open models locally is that provenance becomes something you can actually control. You choose the model, you verify it, you host it, and it stays exactly as you left it. There is no silent upgrade that changes its behaviour mid-quarter, which is a real problem with rented models and a real headache for anyone who has to keep an evaluation valid over time.

A short evaluation protocol

Put together, a defensible model choice looks like this. Assemble a small suite of your real tasks with a known good answer for each. Shortlist two or three open models whose licence fits your use. Run the suite, blind if you can, and have a domain expert grade the outputs against your standard, not a generic one. Check provenance and pin versions. Re-run the suite when you change anything. It is not glamorous, and it is far more reliable than trusting a number someone else produced on a test that has nothing to do with your business.

Benchmark figures cited here come from public leaderboards rather than primary lab reports, and model capabilities move quickly. Treat this as a method, not a ranking. The method outlives the models.

Answer the one question they will ask first

Every security review of an AI tool starts, explicitly or not, with a single question: where does our data go? If your answer involves a third-party provider, another country, or a sentence with the word "trust" in it, you have just created a week of follow-up questions about transfers, retention, sub-processors and breach exposure. If your answer is "it stays on our own hardware, on our own network, and here is how we prove it," you have skipped most of the interrogation. Design the pilot so the answer is the short one.

Scope it small and specific

Vague pilots frighten security teams because vague pilots cannot be assessed. "We will roll out AI across the company" is not a plan, it is a liability. "We will let the support team summarise tickets, using this data set, on this system, for eight weeks, with these people having access" is something a reviewer can actually evaluate and approve. Pick one workflow, one data set, one group of users. Make the boundaries obvious.

Bring the paperwork they were going to ask for

You can save weeks by showing up with the documents the review needs instead of waiting to be asked. For anything touching personal data, a data protection impact assessment is often required under Article 35 of the GDPR, and a pilot that keeps data in-house makes that document short, because there is little transfer risk to assess. Have the access list ready. Have the logging story ready, so you can show what the system did and who used it. Know which regulatory buckets your use falls into, including the AI literacy duty that already applies to staff using AI. None of this is heavy if you plan for it. All of it is painful if you improvise it under questioning.

Give them an off switch and an audit trail

Two things make a reviewer relax more than almost anything else. The first is a clean way to stop: if the pilot goes wrong, how fast can you shut it down and contain it? Have an answer. The second is an audit trail: can you show, after the fact, exactly what the system did, with which data, for whom? A system that keeps an immutable log turns "trust us" into "look for yourself," and that shift is often the difference between approval and delay.

None of this is about gaming the review. It is about respecting it. Security teams are not the enemy of an AI rollout. They are the reason the rollout survives contact with the real world. Design the pilot as though the review is the point, keep the data in the building so the hardest questions answer themselves, and you will spend far less time defending it and far more time using it.

The four things it asks for

Article 50 sets out transparency duties for a handful of situations. In plain terms:

• If people interact with an AI system such as a chatbot, they have to be told, unless it is obvious to a reasonably observant person.
• If a system generates synthetic audio, image, video or text, that output has to be marked in a machine-readable way as artificially generated.
• If you use emotion recognition or biometric categorisation on people, you have to inform them.
• If you produce a deepfake, or AI-generated text published to inform the public on matters of public interest, you have to disclose that it is artificial, with some exceptions for artistic or clearly editorial work.

The Commission's regulatory framework pages are the place to watch for the detailed guidance, which tends to arrive close to the application date.

Why the machine-readable bit is harder than it sounds

Telling a user "you are chatting with a bot" is easy. Marking generated content in a machine-readable way is the part that trips teams up. It means watermarking or metadata that survives copying, screenshots and re-encoding, which is a genuinely unsolved problem for text and a partly solved one for images. The law is asking for something the technology does not do perfectly yet, and everyone involved knows it.

For most companies deploying an internal assistant, the practical exposure is narrow. You are not usually generating public deepfakes. You are running a tool that drafts emails and answers questions over your own files. The relevant duty is mostly the first one: make sure people know when they are talking to the assistant rather than a colleague, which is easy to design in.

Where running things locally helps, and where it does not

Let me be honest about the limits here. Running a model on your own hardware does not exempt you from Article 50. The duty follows the use, not the location of the GPU. If you generate a deepfake on a local box, you still have to label it.

What local deployment does change is your ability to build the disclosure in and keep it there. When you control the whole stack, you can enforce a labelling policy at the point of generation, log every output, and prove after the fact what the system produced and how it was marked. When the generation happens behind a third-party API, you are trusting a supplier's implementation and their roadmap. For a duty that turns on being able to demonstrate what your system did, owning the system is a quieter life.

This briefing is general information and not legal advice. Article 50 has carve-outs and edge cases, particularly around journalism and creative work, so check the final text and any Commission guidance against your specific use with a qualified adviser.

The threat that is already happening

Before anyone attacks your model, your own people are quietly moving data into tools you do not control. It is called shadow AI, and it is not hypothetical. IBM's 2025 Cost of a Data Breach research found that one in five breached organisations were breached in connection with shadow AI, that these incidents carried a cost premium of hundreds of thousands of dollars, and that the great majority of organisations that suffered an AI-related breach lacked proper access controls on those AI tools. The global average breach already sits at 4.44 million dollars. Shadow AI is not a compliance footnote. It is a live breach vector with a price tag.

The mechanism is mundane. An employee pastes a customer list, a contract, a patient summary or source code into a public assistant to get help. The data is now on someone else's servers, possibly retained, possibly used to improve a model, and entirely outside your logs and your control. No firewall stopped it because it left through a browser tab.

The supply-chain dimension

Every external AI service you adopt is another supplier in a chain that regulators increasingly expect you to secure. NIS2 made supply-chain security a statutory obligation for in-scope entities. DORA created direct oversight of critical cloud providers precisely because so much of European finance leans on the same few of them. The EU cybersecurity agency ENISA has documented how supply-chain attacks reach their targets not head-on but through a trusted supplier. Each AI dependency you add is one more link that can be attacked, and one more relationship you have to assess, contract for and monitor.

What on-premise inference removes

Keeping the model inside your network does not make you invulnerable. You still have to secure the box, patch it, control access to it and watch it. What it does is remove entire categories of risk rather than adding controls to manage them.

When inference happens in your building, the exfiltration path through a third-party API is closed, because there is no third-party API in the sensitive path. The supplier you would have to secure and monitor is not in the chain. The international transfer you would have to justify never occurs. The provider that could log your prompts, change its retention policy, or be compelled to hand data to a foreign authority is not holding your data, because your data never reached it. A sealed system with an immutable audit log lets you prove, rather than hope, that sensitive information stayed where it belonged.

Building the model

Put the pieces together and the threat model for enterprise AI has a clear centre of gravity. The headline risk is not a clever adversary defeating your model. It is routine data leakage through unsanctioned or externally hosted tools, compounded by a growing web of AI suppliers you now have to secure. The most effective single control is not another monitoring product. It is architecture: give people a capable assistant inside the boundary so they stop reaching for the ones outside it, and keep the sensitive inference on hardware you own so the data has nowhere external to go. Everything else, the prompt-injection defences and the rest, is worth doing on top of that foundation. It is not a substitute for it.

This paper is general guidance, not a security assessment of your environment. Your own threat model depends on your data, your sector and your obligations, and is a conversation for your security team. The direction it points, though, is consistent with where European regulation has been heading for years. Shorten the chain. Keep the sensitive data home.

What renting gives you

Renting AI, which is what using a cloud provider mostly is, has real advantages and I am not going to pretend otherwise. You start immediately. You pay nothing up front. Someone else runs the infrastructure, patches it and keeps it healthy. You always have access to the latest model the moment it ships. For getting going, for experiments, for light and occasional use, renting is genuinely the sensible choice. If that is your situation, rent, and do not let anyone guilt you out of it.

What renting costs you

The catch with renting is the catch with all renting. You pay forever, the payments scale with how much you use, and at the end you own nothing. Your data lives in the landlord's building, under the landlord's rules, which can change. You are exposed to price rises and to a model being retired out from under a workflow you built on it. And the more essential the capability becomes to how you work, the more your business depends on a thing you do not control. Dependence is the real rent, and it compounds quietly.

What owning gives you

Owning AI means running it on your own hardware. It costs more to start and it asks more of you, or of whoever manages the box for you. In exchange you get the things ownership always gives. A fixed cost instead of a meter. Data that stays in your building. A model you can pin so it does not change under you. Independence from a provider's prices, terms and roadmap. For heavy, steady, sensitive use, the sums and the control both tend to favour owning, which is the case we make in detail in our note on the total cost of ownership of on-premise AI.

Just make it a decision

The point of this is not that owning always wins. It does not. Plenty of companies should rent, and plenty should run both, cloud for the casual and generic, owned for the crown jewels. The point is to choose on purpose. Renting AI is easy to slide into and hard to climb out of once your workflows are built on someone else's meter. Before that happens, spend an hour on the old question. For this capability, at our scale, with our data, do we want to own it or rent it? Answer it deliberately, and you will make a better choice than the one you would have drifted into.

A quick recap for people who tuned out

The court's problem was never really with any single company. It was with the mismatch between EU data protection law and US national security law. Programmes operating under authorities like FISA Section 702 let US agencies reach data held by US providers, and a European whose data got swept up had no equivalent of a court to complain to. That gap is why Privacy Shield fell, and why its predecessor Safe Harbor fell before it.

After Schrems II, companies leaned on Standard Contractual Clauses plus so-called supplementary measures, and everyone had to run a transfer impact assessment to check whether the destination country actually offered adequate protection. It was a lot of paperwork for something that, deep down, the paperwork could not fully fix.

The Data Privacy Framework, and why people are nervous

In July 2023 the Commission adopted a new adequacy decision, the EU to US Data Privacy Framework, which restored a legal basis for transfers to certified US companies. Useful, and a relief for a lot of businesses. But it sits on the same fault line as the two arrangements that came before it, and the same activist who brought down the first two has said he expects this one to end up back in Luxembourg.

Through 2025 and into 2026 the framework has been under real pressure, including questions about the independence of the US oversight body it relies on. Nobody sensible is treating it as settled. If your compliance plan assumes the Data Privacy Framework will still be standing in three years, you are making a bet, not a plan.

Where AI quietly reintroduces the problem

Most companies spent years getting their transfer house in order, and then rolled out AI tools that undo a lot of it in a single procurement. A cloud assistant sends prompts, documents and context to a provider that is very often US-controlled, which pulls you straight back into the Schrems II world of adequacy decisions and transfer assessments. The AI did not create a new legal category. It just poured new data into the old one.

This is the least glamorous argument for running models locally, and maybe the strongest. When the inference happens on a server in your building, there is no transfer to assess, no adequacy decision to depend on, and no activist lawsuit that can change your legal exposure overnight. The data that would have crossed the Atlantic never leaves the room. The European Data Protection Board keeps publishing guidance on transfers, and it is worth reading, but the shortest compliant path is the one where the guidance does not apply to your workload because nothing crossed a border.

None of this is legal advice. International transfer rules are intricate and moving, and your DPO and counsel should map your specific flows. The general point stands on its own though. Data that stays home is data you never have to defend at the border.

What SOC 2 actually is

SOC 2 is an attestation. An independent auditor examines your controls against the Trust Services Criteria published by the American Institute of CPAs and writes an opinion on them. There are five criteria: Security, Availability, Processing Integrity, Confidentiality and Privacy. Only Security, sometimes called the common criteria, is mandatory. You choose the others based on what you promise customers.

There are also two flavours. A Type I report looks at whether your controls are well designed at a single point in time. A Type II report watches whether they actually operated effectively over a period, usually six to twelve months. Enterprise buyers who know what they are doing ask for Type II, because a snapshot of good intentions is easy and a track record is not.

What ISO 27001 actually is

ISO 27001 is a certification, which is a different animal from an attestation. Instead of an auditor's narrative opinion, you get a pass-or-fail certificate from an accredited body that says your information security management system meets the standard. The 2022 edition organises 93 controls into four themes: organisational, people, physical and technological. You do not implement all 93 blindly. You run a risk assessment, decide which apply, and record your reasoning in a statement of applicability.

The useful news is that these two frameworks are not rivals so much as cousins. The overlap between the SOC 2 criteria and the ISO 27001 controls is large, commonly estimated around eighty percent, so the evidence you gather for one carries most of the weight for the other. Doing both is far less than twice the work.

Where self-hosting maps cleanly

Several of the criteria and controls land naturally when the system lives in your own environment. Confidentiality, one of the five Trust Services Criteria, is straightforward to evidence when the data never leaves a boundary you control and the encryption keys are held by you rather than a third party. Access control, a whole cluster of ISO 27001 technological controls, is yours to enforce end to end. Physical security, an ISO theme in its own right, becomes a question about your own premises rather than a paragraph of trust in someone else's data centre you will never visit.

The flip side is real and worth stating. Owning the controls means owning the evidence. Nobody hands you a report to forward. You have to run the access reviews, keep the logs, test the backups and document the lot. A well-built self-hosted platform makes that easier by generating the audit trail for you, but the responsibility is yours. That is the trade: less borrowed trust, more of your own.

How to think about it as a buyer or a builder

If you are evaluating AI, do not accept a vendor's SOC 2 as evidence about your own use of their tool. Ask what controls you are responsible for and whether the architecture lets you satisfy them. If you are building an internal capability, decide early which criteria and controls you will need to show, because retrofitting an audit trail onto a system that was not designed to keep one is miserable. Either way, the frameworks are not the goal. They are a structured way of proving that the sensible things are actually being done, and a self-hosted design gives you direct control over most of the sensible things.

This paper is general information rather than a compliance opinion. The exact scope of a SOC 2 examination or an ISO 27001 certification for your organisation is a conversation for your auditor and your security function.

Match the model to the job

Think about what an internal assistant is really asked to do. Summarise this document. Answer a question using our own files. Draft a reply in our house style. Pull the key dates out of this contract. Classify these tickets. This is the bread and butter of business AI, and none of it is a frontier reasoning challenge. It is competent language work over your own material.

For that work, the open-weight models you can run on your own hardware in 2026 are genuinely good. Models like Llama 4, Qwen, Mistral and others land within a few points of the big closed models on standard knowledge benchmarks, and in practice they are perfectly capable of the drafting, summarising and document questions that make up the day job. Using a frontier cloud model for this is like chartering a jet to cross the street. It works, but you have badly overpaid, and you handed someone else your luggage.

Where the big models still earn their keep

Let me be fair, because the honest version of this argument is more persuasive than the hype version. There are tasks where frontier models still pull ahead: the hardest multi-step reasoning, complex agentic coding, the genuine edge of what is possible. If that is your core business, weigh it seriously and pay for the best. But for a company whose AI need is a private assistant over its own knowledge, that gap is irrelevant. You are paying a premium, in money and in data exposure, for capability you will never use on the task in front of you.

What "good enough" buys you

Once you accept that an open model handles the real work, the rest of the decision opens up. You can run it yourself, which means your documents never leave the building. You can pin the exact version so it does not change under you mid-quarter, which anyone maintaining a rented model has learned to dread. You pay a fixed cost for hardware instead of a meter that runs forever. And you stop routing your most sensitive internal knowledge through a third party for tasks that never needed one.

The frontier is a wonderful thing, and for the problems that need it, nothing else will do. Just notice how few of your actual problems live there. Most of them are waiting quietly in your own files, and a model you can hold in your own hands is more than enough to answer them.

The principles that bite hardest

A working language-model deployment collides with a handful of GDPR principles more than the rest. Purpose limitation and data minimisation, from Article 5, are in constant tension with the machine-learning instinct to hoard data because it might be useful. Lawful basis, from Article 6, has to be settled before you process a single record, and for most internal tools that means a documented legitimate-interest assessment. Special-category data, from Article 9, is the landmine: health, biometric, political and similar data is prohibited to process unless a specific exception applies, and it has a way of turning up in document sets nobody screened.

None of this is exotic. It is the ordinary GDPR you already know, applied to a system that happens to read everything you feed it and remember more than you expect.

The erasure problem is real, and most vendors are vague about it

Article 17, the right to be forgotten, is where AI architecture stops being a formality. Deleting a person's record from a database is a solved problem. Deleting their data from a model that was trained on it, or from the vector embeddings a retrieval system built out of their documents, is not. The information is smeared across weights and numbers in a way you cannot simply drop a row from.

When you ask any AI vendor how erasure works, listen for specifics. What happens to the embeddings derived from a deleted document? How long until it ages out of backups? Does a fine-tuned model retain it? If the answer is a shrug or a slogan, the erasure story is not real. The EDPB's Opinion 28/2024 makes clear this is not a theoretical worry: the Board stated that a model trained on personal data cannot, in every case, be assumed anonymous, and that anonymity has to be assessed rather than declared.

Why architecture, not paperwork, decides this

You can write the finest data protection impact assessment in the world, as Article 35 often requires for high-risk AI, and it will not save you if the underlying system cannot honour a deletion request or keeps sending personal data somewhere it should not go. The document describes the system. It does not fix it.

This is the quiet argument for building the boundary in early. When the model, the index and the logs all sit inside your own network, the mitigations section of your DPIA gets dramatically shorter, because whole categories of risk are absent rather than managed. No third-party processor for the inference step. No international transfer to assess against the shifting backdrop of adequacy decisions. No sub-processor chain that changes when a vendor signs a new supplier. The EDPB's guidance spends pages on how to handle these risks in a cloud setting. Removing the cloud from the sensitive path removes the pages.

A design checklist worth keeping

If you take one thing from this paper, make it a set of questions to ask at design time rather than audit time. Where does personal data physically go when a prompt is submitted? Who, human or corporate, can technically read it along the way? Can a deletion request be honoured completely and demonstrably? Is special-category data filtered before it reaches the model? Is there an immutable log of what the system did with whom? A deployment that can answer those cleanly is one where by-design was more than a slogan.

This paper is general information, not legal advice. The GDPR interacts with the AI Act, sector law and national rules in ways your data protection officer and counsel need to map for your circumstances. The engineering point stands on its own, though. Compliance you can prove starts with architecture you chose deliberately.

From marginal cost to fixed cost

With per-token cloud AI, every use has a price. Ask more questions, pay more. The cost scales with your success. When you own the hardware, that relationship breaks. The machine costs what it costs whether it answers ten questions a day or ten thousand. Past the purchase, the main thing you are paying for is the electricity to run it and cool it. Usage is effectively free. The marginal cost of one more question rounds to nothing.

This flips the psychology of AI adoption in a way people underestimate. On a meter, you quietly discourage use, because use is cost. On owned hardware, you want people to use it as much as possible, because you have already paid for it and idle capacity is wasted money. The incentives finally point the same way as the goal.

What the electricity actually is

Let me not hand-wave the number, because energy is a real line item. A serious inference server with high-end GPUs draws real power, and cooling adds a meaningful amount on top. Independent cost analyses in 2026 put a single high-end GPU server in the region of ten kilowatts under load, with cooling adding perhaps a quarter to a third again. That is a genuine running cost, and any honest budget for local AI includes it rather than pretending inference is free.

The part that is easy to like

There is a quieter benefit to the electricity model beyond the maths. A power bill is predictable. You can budget it a year out and it will not surprise you because a team discovered a new agentic workflow and tripled the token count overnight. Owned hardware gives you a cost you can plan around, which finance departments tend to appreciate more than a variable bill that grows with adoption.

And for a company running in a place with clean, steady, reasonably priced power, the electricity model has an environmental and a cost logic that both point the same way. We build in Sweden, where the grid is largely low-carbon, and running your own inference on that kind of power is a different proposition than doing it on a dirtier, pricier grid. The precise figures depend on your location and your tariff, so price it for your own situation rather than trusting a brochure. But the shape of the deal is appealing: pay once for the machine, then pay for power, and stop feeding a meter that never stops running.

What it actually says

The wording is broad on purpose. Providers and deployers of AI systems have to take measures to ensure, to their best extent, a sufficient level of AI literacy among their staff and other people who operate and use AI systems on their behalf. It tells you to account for people's technical knowledge, experience, education and training, and the context the systems are used in.

Notice what it does not do. It does not prescribe a curriculum, a certificate or a number of hours. That vagueness makes some compliance teams nervous, but it is also a gift: you get to decide what "sufficient" looks like for your people, as long as you can show you thought about it and did something real.

Why the EU bothered

The logic is that half the risk in AI comes not from the models but from the humans pointing them at the wrong problem. Someone pastes a client's personal data into a public chatbot. Someone trusts a confident answer that happens to be wrong. Someone automates a decision that should have had a person in the loop. None of that is fixed by better model weights. It is fixed by people who understand what the tool is and is not.

What "sufficient" looks like in practice

You do not need to turn your finance team into machine-learning engineers. Sufficient literacy for most staff means they understand a few things well enough to act on them. That the tool can be wrong and sounds equally confident either way. That some information should never go into it. That the output is a draft, not an oracle. That there are tasks where a human has to make the final call. And that the rules differ depending on whether the tool runs inside the company or sends data outside it.

That last point is where the shape of your deployment matters. If your assistant runs on your own hardware and nothing leaves the building, a big chunk of the "do not paste that here" anxiety simply goes away, and your training gets shorter and calmer. If staff are using a mix of external tools, the literacy programme has to spend real time on what is safe to send where. The EU AI Office has signalled it will publish living guidance and examples on literacy, so keep an eye there.

One practical note. Because Article 4 is already in force and enforcement of the broader Act is ramping up, "we will get to training later" is not a great position to be caught in. It is the one duty you can close out this quarter.

As always, this is general information rather than legal advice. Talk to a qualified adviser about what an adequate literacy programme looks like for your sector and your risk profile.

What the data says

IBM's 2025 Cost of a Data Breach report put some hard figures on the phenomenon. One in five organisations that suffered a breach had a shadow AI element involved. Those breaches cost meaningfully more than average, a premium measured in hundreds of thousands of dollars. And of the organisations that had an AI-related breach, the overwhelming majority had no proper access controls on the AI tools in question. The global average breach already runs to 4.44 million dollars. Shadow AI is a line item now, not a curiosity.

The mechanism is completely ordinary, which is why it is so hard to stop. A salesperson pastes the customer list into a chatbot to draft outreach. A developer drops in proprietary code to debug it. Someone in HR summarises a sensitive case. Each of them is just trying to do their job faster. And each of them has quietly moved company data onto servers you do not control, outside your logs, possibly retained, possibly used to train a model. No alarm went off, because the data left through a browser tab like any other web page.

Why banning it does not work

The instinct is to send a stern email and block the tools at the firewall. It does not work, for a simple reason: the tools are genuinely useful, and people will find a way. They will use their phones. They will use a personal account. They will route around whatever you put up, because the productivity is real and the deadline is real. Prohibition without a substitute just pushes the behaviour further into the dark, where you can see even less of it.

The fix is a better default

The durable answer to shadow AI is not a stricter policy. It is a better default. Give people an assistant that is at least as capable as the public one they are tempted by, that runs inside your walls so the data stays put, and that is genuinely easy to reach. When the sanctioned tool is good and the data never leaves, the incentive to sneak off to a public chatbot mostly evaporates. People were not trying to leak data. They were trying to get help. Give them help that is safe and they will take it.

That is a large part of why we build AI to run on the customer's own hardware. It turns the shadow AI problem inside out. Instead of chasing every unsanctioned tool your staff might reach for, you provide one good tool where the sensitive processing happens in the building, and the reason to go elsewhere goes away. You cannot email your way out of shadow AI. You can build your way out of it.

The concentration-risk problem, stated plainly

DORA created an oversight regime for what it calls critical ICT third-party providers. In November 2025 the European Supervisory Authorities named the first batch, and the list read exactly as you would guess: AWS, Microsoft Azure, Google Cloud, Oracle, IBM and others, as the supervisors confirmed. Regulators pointed out that a large majority of EU financial entities rely on at least two of the big three cloud platforms for critical functions.

Think about what that means as a systemic matter. If most of the continent's banks and insurers run their critical workloads on the same three American companies, then those three companies are single points of failure for the whole financial system. An outage, a compromise or a geopolitical rupture at one of them is not one firm's problem. It is everyone's problem at once. That is precisely the risk DORA was written to manage.

What DORA asks firms to do

DORA rests on several pillars, but the ones that touch AI directly are ICT risk management and third-party risk. In practice a financial entity has to keep a register of its ICT third parties, assess concentration risk, ensure it has exit strategies, and be able to keep operating if a provider fails. If your AI runs on a cloud model, that provider goes in the register, and you have to be able to answer the awkward question: what happens to this capability if this provider is unavailable, and can we actually move?

Where on-premise changes the answer

Running an AI system on your own hardware does not make DORA go away. You still have resilience obligations, you still test, you still report incidents. But it changes the third-party risk picture in a specific, favourable way. A model that runs inside your own data centre is not another critical dependency on an externally overseen hyperscaler. It shortens the chain. Your exit strategy for that workload is trivial, because there is nothing to exit. And the concentration-risk question a supervisor might ask about your AI has a clean answer: this one does not add to our exposure, because we own it.

For the ICT third-party register, fewer external suppliers means less to document, monitor and stress-test. For concentration risk, keeping a critical workload in-house is the opposite of piling more load onto a designated critical provider. None of this is a silver bullet, and a badly run on-premise system can be less resilient than a well-run cloud one. But the structural point holds: the shorter your supply chain, the easier DORA's third-party questions are to answer.

This briefing is general information and not legal or regulatory advice. DORA is detailed and enforced by sector supervisors, so work through your specific obligations with your compliance function and, where relevant, Finansinspektionen guidance.

Follow a single question

Imagine an employee asks the assistant to summarise a contract. With a cloud tool, here is the journey that question takes. The contract and the question leave their laptop, travel across the public internet, arrive at a provider's data centre (often in another country), get processed on machines nobody at your company will ever see, and the answer travels back. Somewhere in that trip, your contract sat on someone else's computer. Maybe it was retained for a while. Maybe it was used to improve a model. You are trusting a contract and a policy that the contract stayed private.

Now the local version. The employee asks the same question. The contract and the question go to a server sitting in your own building, on your own network. The model runs there. The answer comes back. Nothing crossed the internet. Nothing landed on a machine you do not own. There was no third party in the loop to trust, because there was no third party. That is the whole difference, and it is not subtle.

What "the building" really refers to

The phrase is a bit literal. What we mean is your trust boundary: the network and hardware you control. For most customers that is a server in their office or their own data centre. It can be genuinely air-gapped, with no internet connection at all, for the most sensitive work. Or it can be connected for convenience but configured so that the AI workload itself never sends data out. The point is that you decide where the edge is, and the sensitive processing happens inside it.

Why this is more than a feeling

Keeping data local is not just reassuring. It removes real, specific problems. There is no international data transfer to assess against the shifting rules that followed the Schrems II ruling. There is no foreign statute that can reach a server which never held your data. There is no provider that could log your prompts or change its retention policy next quarter. When a regulator, an auditor or your own security team asks the hard question, where does the data go, you get to give the shortest possible answer. It stays here.

We seal the network perimeter on boot, keep an immutable log of what the system did, and ship the tooling to demonstrate that nothing left. That is the machinery behind the slogan. But the slogan itself is simple, and it is the reason a lot of our customers picked local AI in the first place. Their most valuable data is exactly the data they cannot send away. So we built the version where they do not have to.

The Data Act, formally Regulation (EU) 2023/2854, has applied across the Union since 12 September 2025. The European Commission's own summary frames it as a law about "fairness in the data economy." That is true but a bit abstract. Let me pull out the parts that touch anyone running software.

Leaving a cloud provider is supposed to get easier, and cheaper

If you have ever tried to move a few terabytes out of a hyperscaler, you know the drill. The data is easy to put in and strangely expensive to take out. Those egress fees were never really about the cost of bandwidth. They were a fence.

Chapter VI of the Data Act (Articles 23 to 31) goes after that fence directly. Providers have to remove the commercial, technical and contractual obstacles that stop you switching to a different provider, moving to your own on-premises infrastructure, or running several providers at once. And Article 29 sets a clock on the fees themselves: switching charges are being reduced during a transition period and must be gone entirely from 12 January 2027, as legal analyses from firms like Greenberg Traurig spell out. After that date, moving your data out is supposed to cost you nothing.

Read that again with a procurement hat on. The EU has decided that lock-in through exit fees is a problem worth legislating away. If a regulator thinks the switching cost is the issue, the cleanest answer is the arrangement where there is no provider to switch away from in the first place.

The part about foreign governments

Article 32 is the one that does not get enough attention. It requires providers of cloud and edge services to put in place technical, legal and organisational measures to prevent unlawful access by third-country governments to non-personal data held in the EU, where that access would clash with EU or member-state law.

Note the careful wording: non-personal data. Personal data transfers are still governed by Chapter V of the GDPR, which is a separate conversation. But the fact that the EU felt it needed a dedicated article about foreign state access to ordinary business data tells you how real the concern has become. The worry has a name in most people's minds, the US CLOUD Act, and the Data Act is the Union writing a partial answer to it into law.

What this means if you are adding AI

Here is where it gets concrete for anyone rolling out an assistant or a document-search tool. Every prompt, every uploaded file, every retrieved passage is data leaving your control the moment it hits a cloud model's API. The Data Act does not ban that. It just keeps chipping away at the assumption that your data naturally lives in someone else's data centre.

If you run the model locally, the whole question of switching costs, egress fees and third-country access stops applying to your AI workload. Not because you found a clever contractual workaround, but because the data never became someone else's problem to begin with.

None of this is legal advice, and the Data Act interacts with the GDPR, the Data Governance Act and sector rules in ways your counsel should map for your situation. But the direction of travel is not subtle. Europe is legislating for a world where you can pick up your data and walk. Running AI on your own hardware is simply the shortest version of that walk.

Start with tokens, not dollars

Everything in per-token pricing rests on one conversion, and it is worth internalising. As a rough rule, English text runs about 1.3 tokens per word, so a 750-word page is roughly a thousand tokens, per OpenAI's own guidance. Treat that as approximate, not exact. Code and technical writing run higher. Other languages, including Swedish, inflate the count noticeably because the tokenizer was optimised for English. And newer models sometimes use tokenizers that produce meaningfully more tokens for the same text. So build in headroom rather than pretending the conversion is a constant.

The three multipliers people forget

A demo query is cheap. A real deployment is expensive for reasons the demo never shows you.

• Output tokens cost several times more than input tokens across every major provider, and useful assistants generate a lot of output. Weight your estimate accordingly.
• Retrieval over your own documents means every question quietly drags a large slab of context through the model. A one-line question can carry ten thousand tokens of retrieved material behind it, and you pay for all of them, every time.
• Agentic workflows, where the model calls itself in a loop to finish a task, can multiply token use by ten or more against a single-shot query. This is where the scary numbers come from, and it is exactly the direction serious deployments are heading.

Any estimate that ignores these three is pricing a toy and budgeting for a tool.

A method you can defend

Here is a way to produce a number you will not be embarrassed by later. Pick two or three real roles, not averages, and estimate their honest daily token use including retrieval and any agentic workflows. Convert to a monthly per-role figure. Multiply by how many people in each role will actually use the tool, not the whole headcount and not just the pilot group. Apply the provider's real input and output rates separately, because the blended number hides the expensive half. Add a growth factor, because usage of a tool people like goes up, not down. Then annualise. The result is usually two to five times the back-of-napkin figure the demo suggested, and it is the number worth taking to a decision.

Why this exercise favours owning the hardware, sometimes

Run this method and one of two things happens. Either the annual cloud number is modest, in which case the cloud is the right answer and you should stop reading vendor white papers like this one. Or it is large, and it recurs every year forever, and it grows. In that second case, the comparison against owned hardware, which is a fixed cost that does not scale with every extra query or every new hire, suddenly looks different. We walk through that comparison in our companion piece on the total cost of ownership of on-premise AI. The point of this paper is narrower: get the real cloud number first, because most people never do, and it is the number that decides everything else.

Figures here are illustrative and drawn from published rules of thumb and vendor rates current in 2026. Your actual usage is the only estimate that matters, which is exactly why it is worth measuring before you sign.

Here is what the demo does not show you.

The meter never stops

Per-token pricing is a meter. It runs on every single interaction, forever. That is fine when three people use it now and then. It is a very different thing when four hundred people use it all day, every working day, for the next five years, and the meter is still running the whole time. You are not buying a tool. You are renting a habit, and the rent is due every month whether the tool got more valuable or not.

Owned things have a different shape. You pay once, and then usage is close to free. A meter has the opposite shape. Usage is the cost, and the more your people rely on AI, the more you pay for their reliance. Success makes the bill go up. Think about how strange that incentive is.

The half of the bill nobody quotes

There is a detail in the pricing that quietly doubles or triples real costs. Output tokens, the text the model writes back, cost several times more than input tokens across every major provider. Look at the published rates from Anthropic or Google and you will see the same pattern: output is where the money is. A good assistant is one that writes a lot back. So the better the tool does its job, the more of the expensive kind of token it generates. The pricing punishes exactly the behaviour you wanted.

Then there is retrieval. The moment your assistant answers questions using your own documents, every question drags a big slab of context through the model, and you pay for all of it. A one-line question can carry ten thousand tokens of retrieved material behind it. And agentic workflows, where the model works in loops, can multiply the count tenfold. None of this shows up when you are poking at a demo with single questions.

Do the annual maths, once

I am not going to tell you the cloud is always the wrong choice, because it is not. For light, occasional use, the cheap model tiers are genuinely hard to beat, and you should use them. The problem is not the cloud. The problem is signing up for a per-token meter without ever working out what it costs at full tilt.

So do it once. Take a real heavy user, estimate their honest daily token use including retrieval and any agents, multiply by the people who will actually use the tool hard, apply the real input and output rates separately, add growth because usage of a good tool goes up, and annualise. We walk through the method in more detail in our note on estimating your real token bill. Most people never run that number. It is usually two to five times the figure the demo implied.

Once it is in front of you, one question does the rest of the work. Would you rather pay that number every year, growing, forever? Or own the thing that produces the same answers, on hardware in your building, at a fixed cost that does not care how many questions your people ask? For a lot of companies, seeing the annual figure written down is the entire decision.