Back to Podcast Digest
AI Engineer19m

What Breaks When You Build AI Under Sovereignty Constraints - Bilge Yücel, deepset GmbH

TL;DR

  • Sovereign AI gets concrete fast — Bilge Yücel translates the policy language into engineering terms: control over data flow, model choice, infrastructure, observability, and operations, then groups it into four pillars—data, model, infrastructure, and operational sovereignty.

  • The first sovereignty failure can be as small as one API call — Yücel’s example is sending EU citizen data to an embedding API hosted in Virginia: even if the app feels compliant, that single data path can already violate GDPR-style data sovereignty.

  • Retrofitting sovereignty into an existing AI system breaks more than people expect — swapping a frontier API for a self-hosted model means prompt rewrites, fresh evaluations, architecture translation, and lots of new code; moving data into Europe creates multi-database search headaches; replacing managed cloud with on-prem exposes hidden Kubernetes, networking, CPU/GPU, and hardware dependencies.

  • Sovereignty is a spectrum, not a purity test — Yücel stresses that not every team needs a fully air-gapped setup; finance and healthcare may, but many startups just need to understand their actual control level and vendor lock-in before a CIO suddenly says, “make it sovereign.”

  • Haystack’s pitch is swappability plus traceability — deepset argues its open-source orchestration framework reduces lock-in with consistent interfaces, explicit typed data flow, YAML serialization for versioning, and OpenTelemetry-based tracing, so teams can move between cloud and self-hosted setups with fewer architectural changes.

  • A sovereign agent stack adds guardrails before and after the model — the sample architecture routes user input through an input guardrail for prompt injection and regulatory checks, sends safe requests to an agent with local tools and MCP servers, then applies an output guardrail to prevent sensitive-information leaks, with optional human approval for actions like payment requests.

The Breakdown

Sovereignty, minus the policy jargon

Bilge Yücel opens by grounding the topic in deepset’s real customers—Airbus, Bosch, Siemens, the European Commission, and German federal ministries—where sovereignty is not theoretical. His practical definition is cleaner than the policy one: sovereign AI means explicit control over data flow, model choice, infrastructure, observability, and operations.

The four pillars: data, models, infrastructure, operations

He breaks sovereignty into four buckets engineers can actually reason about. Data sovereignty is where data is stored and processed, model sovereignty is who controls the model and whether you can switch it, infrastructure sovereignty is where compute runs, and operational sovereignty is whether the system is traceable, auditable, and maintainable in production.

How you quietly lose sovereignty without noticing

The most memorable example is simple: GDPR may say EU citizen data stays in Europe, but if you send that data to an embedding API in Virginia, you have already lost control. He adds that sovereignty also breaks internally when employees can access data they shouldn’t, and externally when “European” deployments still sit under the Cloud Act because the vendor is US-headquartered.

Why sovereignty is really a convenience-vs-control tradeoff

Yücel frames infrastructure choices as a spectrum from “max control to max convenience.” Air-gapped environments offer the most safety, private VPCs and sovereign clouds sit in the middle, and SaaS is easiest—but that ease often comes with legal and operational exposure you may not notice until it matters.

What breaks when your boss says, “Make it sovereign”

This is the talk’s sharpest section: he walks through the Monday-morning reality of retrofitting sovereignty into a system that already works. Replace a frontier model with a self-hosted one, and suddenly you are rewriting prompts, translating API logic, reevaluating performance, and touching a lot of code; move private data into the right jurisdiction, and now search across multiple databases becomes a whole architecture problem.

The hidden infra tax of leaving managed cloud

Once you swap managed infra for on-prem, the vendor lock-in you ignored becomes painfully visible. Now your team owns Kubernetes, network plumbing, and the awkward split between CPU-based application layers and GPU-hosted model inference, which cloud providers had quietly been smoothing over for you.

Haystack’s answer: make every layer swappable and visible

Yücel uses the moment for a direct Haystack plug, but it is a focused one: consistent interfaces to swap cloud for self-hosted models, explicit typed data flow so you can see exactly what moved where, YAML serialization for version control, and open source so there is “no black box, no hidden assumptions.” The core promise is that orchestration will not fix your GPU shortage, but it can stop sovereignty work from becoming a full rewrite.

A sovereign agent stack with guardrails and human approval

He closes with a concrete architecture: input guardrails catch prompt injection and policy issues, a tool-using agent does the work, and output guardrails prevent sensitive data leakage. In the Haystack example, tools can come from local MCP servers, BM25 helps search across large toolsets, OpenTelemetry powers tracing, and human-in-the-loop approvals can be required for actions like submitting payment requests—ending on a simple checklist: can you swap models without changing app logic, store reproducible logs compliantly, and handle incidents without calling a hyperscaler?

Share