Sovereign AI - why now

For a decade, the default for "adding AI to your product" was: sign up with a US hyperscaler, pipe the data, pay per token, ship it. For FinTech, MedTech, GovTech and any company handling regulated data in the EU, that default is dead.

Not "under pressure." Not "becoming harder." Dead.

Three things killed it, and the death happened faster than most procurement teams noticed.

In short. Cloud language-model APIs stopped being a safe default for companies with regulated data in the EU, because the AI Act (logging), NIS2 (24 hours to report a supplier incident) and DORA (third-party risk assessment) close the category together. Inference on your own hardware with open weights, graph-enriched context and compliance logs replaces it.

1 · The regulatory trifecta

AI Act (Regulation 2024/1689) classifies most business-critical AI as high-risk. High-risk systems need conformity assessments, post-market monitoring, and - crucially - logging that proves what the system did, when, and on whose behalf. Cloud LLM APIs don't give you that by default. What you get is a rate-limited REST endpoint and a usage dashboard.

NIS2 (Directive 2022/2555) extended the critical-infrastructure obligations to a much larger set of operators. Financial services, health, digital infrastructure, public administration - all in scope. Supply-chain security is explicit: if your AI vendor has a breach, your regulator wants to know within 24 hours. Good luck enforcing that SLA on a hyperscaler's support portal.

DORA (Regulation 2022/2554) is the financial-sector specific one, live since January 2025. It requires ICT risk management, incident reporting, and third-party risk assessment with contractual teeth. "The LLM vendor is SOC2" does not satisfy DORA Article 28. You need documented evidence that the entire AI pipeline - including inference - is under your ICT risk regime.

Any one of those would be manageable. Together, they collapse the cloud-AI category for anyone serious about compliance.

2 · The data-residency door

Your clients already asked the question, even if politely: "where does our data live at rest, and who has access?"

A year ago you could answer "EU region, encrypted, SOC2." That's no longer enough for three classes of client:

• Banks - because their own regulator is already asking.
• Hospitals and medical SaaS - because patient data plus US jurisdiction plus GDPR is a three-way knot nobody wants to untie in court.
• Government and public sector - because procurement frameworks have tightened around "sovereign cloud" requirements in Germany, France, Poland and the Nordics.

"EU region" was a marketing claim. "On hardware we own, in a colo we physically control" is an engineering claim. The second one closes deals.

3 · The training-data problem nobody talks about

Every time a developer copy-pastes a function into ChatGPT or Claude.ai to "ask a quick question," they are donating your internal logic to someone else's training set - or at minimum their retention log.

Yes, enterprise tiers say "we don't train on your data." Read the DPA carefully: retention windows, abuse-monitoring exceptions, subpoena compliance. None of those are "the data never left your control." They're "the vendor promises to be careful with data that did leave your control."

For FinTech code, medical algorithms, government integrations - "careful custody by a third party" is not the same as "never left the building." Your CTO knows this. Your compliance officer knows this. The question is whether your engineering practice has caught up.

What replaces cloud AI

Three requirements, in this order:

1. On-prem inference. Open-weights models (Qwen, Llama, Mistral) served on your hardware via vLLM. Quantized (AWQ or GPTQ, 4-bit) to fit on a single enterprise GPU - NVIDIA RTX PRO 5000 Blackwell 48GB, AMD Radeon Pro W7900 48GB, or an H100 node for fleet deployment. No egress, full audit surface.
2. Graph-augmented context. RAG with a code-aware graph database (ArcadeDB is what we use) so the model has access to your actual codebase structure - not just the chunk it was prompted with. Hallucinations drop measurably.
3. Compliance logging as a first-class citizen. Every prompt, response, fix, and tool call is logged against the regulatory schema your auditor will ask for. Not PDF screenshots. Machine-readable, schema-stable, exportable.

That's the stack. It's more work than curl https://api.openai.com/.... It's also the only stack that survives a DORA audit.

What to build, right now, if you're in this boat

• Triage your current AI usage. Where is source code going? Where is customer data going? Which of those flows has a DPA you've actually read?
• Cost it honestly. Hardware (a single H100 node) plus ops is not cheap, but it's predictable and depreciates - unlike per-token bills that scale with feature success.
• Plan for multi-agent, not single-prompt. Code generation, security review, test generation, audit logging - separate agents with separate prompts make the system reviewable. A single mega-prompt to a cloud LLM does not.

This is what I'm building as SADP - a self-funded sovereign AI development platform for regulated SMEs. If any of the above describes your 2026, let's talk.