主権の下で AI を作ると何が壊れるか — Bilge Yücel (deepset) が示す 4 つの柱と Haystack 流アーキテクチャ (AI Engineer Europe 2026)

ビルゲ・ユジェルの本講演は、 Eoin Mulgrew (10 Downing Street) の Insurgency Model が国家の組織変革論を提示したのと対をなす、 「国家・地域の規制下で AI システムを実装する側」 の technical playbook。 GDPR / EU AI Act 下で欧州大企業や公共機関を顧客に持つ deepset の知見が、 ML エンジニアリングと regulatory compliance の交点で結晶化した 19 分。 MEMEX の AI×政治 軸において、 政策側 (Eoin) → 実装側 (Bilge) の対称ペアとして読むと、 欧州の AI 主権議論の全体像が見える。

開幕でユジェルは sovereign AI を policy 定義 (「組織が自分の条件で AI を design / deploy / operate する能力」) から engineer 向け定義に翻訳し直す。 「我々は policymaker や lawyer ではない、 engineer です」 ── 1:15 のスライドで提示される技術的定義は、 「data flow / model choice / infrastructure / observability / operations 全てに対する明示的 control」。 これを理解可能な粒度に分解するのが 4 つの pillar 設計。

4 つの柱 ── データ / モデル / インフラ / 運用

ユジェルが整理する sovereign AI の 4 pillar は以下の通り。 それぞれに 「何を controllする話なのか」 と 「何が breach になるか」 が明確に定義されている。

1. データ主権 Bilge Yücel が定義する sovereign AI の第 1 pillar。 データが trusted jurisdiction 内で処理・保存されることを保証する。 GDPR は欧州市民データの域内保管を求めるため、 欧州データを米国 Virginia の embedding API に投げた瞬間に data sovereignty が breach される。 もう 1 つの軸は社内 access permissions ── 見るべきでない人がデータにアクセスできる状態も data sovereignty 違反 ── データが trusted jurisdiction 内で処理・保存されること。 GDPR General Data Protection Regulation、 2018 年施行の EU 一般データ保護規則。 欧州市民の個人データに対する最も厳格なデータ保護枠組み。 域外移転を厳しく制限し、 違反は世界売上の最大 4% または 2,000 万ユーロのいずれか高い方の制裁金。 sovereign AI の議論では、 「欧州データは欧州内で処理される」 という最低条件を規定する起点 は 「欧州市民データは欧州内に留まる」 と規定するため、 欧州データを米国 Virginia ホストの embedding API に送った瞬間に breach。 もう 1 つは社内の access permissions ── 見るべきでない人がデータにアクセスできる状態も同じく data sovereignty 違反。
2. モデル主権 ── モデルを誰が control し、 訓練データの origin はどこか。 1 つのモデルに tightly coupled になっている (API が落ちたらアクセス喪失、 値上げで cost 問題) のは典型的 breach。 swappability の有無 ── 「他モデルに切り替えるのに 1 日でできるか、 code base を全部書き直す必要があるか」 が問われる。 そして controversial だが、 訓練データの origin ── 米国系プロバイダより欧州系プロバイダのほうが advantage があるという論点まで含まれる。
3. インフラ主権 ── compute がどこで起きるか。 RAG pipeline、 ingestion、 agent、 tool 群 ── これら全 application layer の物理位置が定義する。 max control から max convenience までの spectrum で並べると、 air gap 環境 ネットワークから物理的に切断された運用環境。 sovereign AI の spectrum で最も control が強い側に位置し、 EU AI Act の high-risk システムにおける一部要件を満たす。 公共部門 / 防衛 / 金融 / 医療など high-stake 用途で採用される。 引き換えに、 model update / external API 呼び出し / managed cloud 機能が一切使えない、 という極端な convenience trade-off を負う (EU AI Act 安全) → private VPC Virtual Private Cloud、 公衆クラウド事業者 (AWS / Azure / GCP 等) 内に論理的に隔離された仮想ネットワーク空間を構築する仕組み。 自社管理の物理ネットワークに近い control を、 cloud の elasticity と組み合わせて得られる。 sovereign AI の spectrum では air gap よりも convenience 寄り、 SaaS よりも control 寄りに位置し、 GDPR 準拠で本番運用を回す実用的な選択肢 (GDPR 安全) → sovereign cloud 特定の国・地域の法域 (jurisdiction) に物理的・運用的に完全に閉じた public cloud オファリング。 通常の hyperscaler が global control plane を持つのに対し、 sovereign cloud は data residency と access control plane を当該国に限定する。 Microsoft Cloud for Sovereignty、 AWS European Sovereign Cloud、 Google Sovereign Cloud などが該当。 provider の出身国によっては Cloud Act 等の域外法のリスクが残る (provider 依存) → SaaS (cloud risk あり) の順。 SaaS では、 米国本社の企業を使う場合、 欧州内で全 application を動かしていても、 親会社が運用データへアクセスする可能性が残る ── これが cloud risk の正体。
4. 運用主権 ── 構築した AI システムを本番でどう monitor / evaluate / manage するか。 model input / output の monitoring、 high-stake (HR / 金融) での human in the loop 自動化された AI システムの実行サイクルに人間の判断を組み込む設計。 sovereign AI の運用 pillar、 特に HR / 金融 / 医療など high-stake 領域で、 EU AI Act や各種 sector 規制が事実上要求する。 「リスクが高い決定の最終 approval は人間が行う」 「異常検知時に人間が介入する」 などの形態。 Haystack では agent component の confirmation strategy で実装される 要件、 versioning / update の auditable な管理 ── ここが弱いと incident response 時に vendor を呼ばないと何も分からない、 という構造的脆弱性を抱える。

主権は spectrum である ── 「全部 sovereign にしろ」 は誤り

6:29 でユジェルが強調するのは、 sovereignty を all-or-nothing で語ってはいけないという点。 金融 / 医療 / 公共部門の high-stake 領域なら full air-gap が必要かもしれないが、 普通の enterprise / startup は全 pillar で sovereign である必要はない。 重要なのは 「自分が今どのレベルの vendor lock-in と control を抱えているかを知っていること」。 これは Laurie Voss (Arize) が eval で 「Agent が clever になる余地を残せ」 と説いたのと相似の警告で、 「規制対応を過剰に詰めると application の柔軟性を殺す」 trade-off の話。

ここで体感スケールで考えると、 compute 1 GPU を air gap 環境で 1 ヶ月回すコストは、 同等性能の SaaS 推論 API の 5〜10 倍に達する (provider と GPU 世代によるが、 概算)。 つまり 「sovereign にする」 という決断は、 1 ピラーごとに数倍のコスト増を引き受けることに等しい。 銀行のセキュリティ金庫を全室分用意するか、 必要な書類だけ金庫に入れて他はオフィス棚に置くかの選択 ── 全室金庫は安全だが、 業務速度は壊滅的に遅くなる。

「主権化しろ」 と言われた月曜日に何が壊れるか

7:08 から本題。 ユジェルが提示する想定シナリオは、 「カンファレンスから戻った月曜日に CIO から 『動いてるシステムを sovereign にしろ』 と言われた」 状況。 直感的に最初に手をつける箇所と、 そこで壊れるものを 4 つに整理する。

1. モデル差し替え ── API 論理の全面翻訳

Frontier API (OpenAI、 Anthropic、 etc) を self-hosted モデルに置き換える。 これが最初に手が伸びる場所だが、 着手した瞬間に API 論理を新モデルアーキテクチャに翻訳する作業 が始まる。 prompt の書き直し、 system 性能のゼロからの evaluation、 大量のコード ── 「モデルを差し替える」 という 1 行の決断が、 実装上は数週間〜数ヶ月の翻訳工事に変質する。

2. データ jurisdiction 移行 ── マルチ DB 管理の地獄

米国ホストの情報を欧州に移すこと自体は可能だが、 着地したら 複数 DB / 複数インスタンスを管理する 状態になる。 search はどう設計するか ── query classification を先に行うか、 両方の DB に投げて結果を merge するか。 単一の RAG パイプラインが、 jurisdiction-aware router を持つ多段システムに変わる。 配達倉庫を 1 つから複数に分けた瞬間、 「どの倉庫に在庫を確認するか」 が新しい問題として生まれるのと同じ構造。

3. Managed → on-prem ── vendor lock-in の正体が露出する

managed infrastructure を on-prem On-premises の略、 自社・自組織の物理拠点に compute インフラを設置・運用する形態。 sovereign AI の spectrum で max control 側に位置する。 cloud provider が抽象化していた要素 (Kubernetes cluster 管理、 ネットワーク設定、 hardware lifecycle、 セキュリティ更新) を全て自前で持つ必要があり、 vendor lock-in の代わりに operational burden を抱える。 欧州の sovereign cloud 議論では、 完全 on-prem と sovereign cloud の中間に private VPC が位置する に置き換えると、 Kubernetes コンテナ orchestration の業界標準 OSS。 cloud provider の managed Kubernetes サービス (EKS / GKE / AKS) を使う場合、 control plane / etcd / node OS の運用は provider が引き受けるが、 sovereign AI の文脈で on-prem に移行すると、 これら全層を自前で運用する必要が生じる。 CPU で動く application layer と GPU で動く model inference を network 越しに繋ぐ orchestration が、 sovereign 移行で最初に重荷化する箇所 cluster の管理、 ネットワーク管理、 hardware 寿命管理 ── cloud provider がやっていた全部が自前に降りてくる。 さらに hardware 制約も発生する ── application layer は CPU、 model は GPU で動くから、 この 2 層を network で接続する必要があり、 接続管理が新しいボトルネックになる。 移行して初めて、 cloud がどれだけの vendor lock-in を抽象化していたか、 その輪郭が見える。

4. Observability 黒箱 ── auditable でない agent layer

observability をそもそも持たないシステムは、 sovereign 化以前にすでに問題を抱えている。 しかし sovereign 移行で観測性を組み込む段階で、 多くのチームは 「AI application layer が完全な black box であり、 中で何が起きているか分からない」 という事実に直面する。 監査可能 (auditable) にするためには、 全 step を log する必要がある。 version control の問題も同時に発生 ── application layer 全体をどう version で管理するか。

Haystack ── orchestration framework が解ける問題

9:44 でユジェルは 「shamelessly plug」 と前置きしつつ、 Haystack が 4 つの問題のうち 3 つに直接効くことを示す (GPU 制約だけは framework では解けない、 とフェアに認める)。 Haystack の sovereign AI 向け 4 特徴は以下:

• Consistent interface ── cloud → self-hosted への移行で、 数行のコード変更だけで済む。 hardware 接続にだけ集中できる。 引っ越しで、 全家具を運ぶのではなく、 同じ規格の差し込みプラグだけ用意すればよい構造。
• Explicit data flow ── 全 input/output が typed + declared。 pipeline 定義を 「読める」 状態にあり、 どこにどのデータが流れているか明示される。 agent のような less deterministic な architecture でも、 tool call と tool output 全てが traceable。
• YAML serialization ── アプリケーションを YAML にシリアライズして version control に放り込める。 commit hash で 「過去の任意時点でのシステム状態」 に戻れる ── auditable 要件 (operational sovereignty) を技術的に satisfies する。
• Truly open source ── black box が存在しない、 hidden assumption もない。 component を拡張・カスタマイズしたい時、 中で何が起きているかを実際に読める。 これは Arize Phoenix が open source eval platform として担う役割 と同じ思想軸 ── 「vendor lock-in なしで本番品質の AI が組める」 ことの実装。

Sovereign architecture pattern ── ガードレール → エージェント → ガードレール

11:31 でユジェルが提示する high-level sovereign architecture は、 シンプルだが普遍的なパターン。 user input → input guardrail (安全性チェック) → agent (LLM + tool 群) → output guardrail (compliance チェック) → output、 という 3 層構造。

1. Input guardrail ── prompt injection 検知 + 規制要件 (このエージェントが扱ってよい用途か) の判定。 unsafe な request は application layer に入る前に即座に reject される。 空港の手荷物検査 ── 危険物は搭乗ゲートに到達する前に止める設計。
2. Agent ── system prompt を持つ LLM + 複数 tool (API call、 knowledge base への search、 sub-agent、 そして MCP Model Context Protocol、 Anthropic が 2024 年 11 月に公開したオープン規格。 LLM と外部ツール・データソース間の接続を標準化する。 sovereign AI の文脈では、 MCP server を local に self-host することで、 tool registry も完全な control 下に置ける。 Haystack の agent component は MCPToolset 経由で local MCP server と接続し、 必要な tool だけを動的に取り出す設計 サーバー群)。 sovereign 構成では、 model も MCP server も、 必要に応じて local / self-hosted に置き換え可能。
3. Output guardrail ── compliance check (sensitive 情報の leak 防止)。 agent が生成した output が、 顧客に渡してよい状態かを最後に検証する。

Haystack の役割はここで、 全ノードを swappable / traceable / vendor-lock-in-free に保つ こと。 「自分の必要とする sovereignty level」 をパラメータ化して、 各 pillar ごとに個別に調整できる状態を作る。

実装の具体 ── Guardrail / MCP toolset / Agent / Pipeline

14:35 からの実装パートで、 ユジェルは 4 段階のコードを順に見せる。 全体像を文章で整理すると:

1. Guardrail ── model provider (例: media chat generator) を指定 → 名前付きモデルを呼び出し → LLM message router に接続 → 入力を classification (safe / unsafe) → safe route と unsafe route に分岐。 数行で動く。
2. MCP toolset ── local 自前 host の MCP server に MCPToolset で接続 → サーバー上の数百ある tool から必要なものだけを名前指定で取り出す (例: knowledge-based search、 generate PDF report)。 Python 関数を直接 tool 化することも可能、 RAG pipeline 自体を tool として包むこともできる。
3. Searchable toolset ── 取り出した tool 群を BM25 ベースの動的 tool search に流す。 agent が数百 tool を持つ場合、 全部の tool 定義を context に詰め込まずに、 query に応じて relevant な tool だけ動的に検索する。 図書館の OPAC ── 全蔵書を頭に入れる必要はなく、 必要な時に検索すればよい。
4. Agent + chat generator ── system prompt で 「あなたは sovereign agent、 これらの tool にアクセスできる」 と定義 → on-prem の chat generator (自社内部 URL に接続するカスタム component) を脳として接続 → tool を渡す → confirmation strategy で human in the loop を設定 (例: 「支払いリクエスト submission 時は常に人間 approval、 list payment request tool は初回だけ permission を求める」)。
5. Pipeline 統合 ── tracer (LLM observability に接続) → input guardrail → agent → output guardrail を 1 本の pipeline に接続。 実行例: 「Q3 の未払い請求を引っ張って PDF レポートを生成して」 → tool を順に呼び出して → 指定ディレクトリに PDF を保存。

observability については、 Haystack の component 入出力と agent trace は全て可視で、 LLM observability tool に直接 span として流せる。 OpenTelemetry Observability の業界標準プロトコル、 Kubernetes logs から各種クラウド monitoring まで業界横断で採用。 LLM 特化拡張として OpenInference があり、 prompt text / completion text / token counts / model name / invoked tools などを標準化。 Haystack は OpenTelemetry integration を持つため、 sovereign AI の auditability 要件を業界標準ツール群 (Arize Phoenix、 Datadog、 self-hosted Grafana 等) で満たせる integration 経由で、 自前 observability stack を組むことも可能 ── これが operational sovereignty の auditability 要件を満たす。

Sovereign チェックリスト ── 3 つの問いで自己診断

17:52 でユジェルが提示する閉じの checklist。 自分のシステムが本当に sovereign かを、 3 つの質問で確かめる:

1. application logic を変えずに model を swap できるか?
2. reproducible な run log が compliant な形で保管されているか?
3. incident 時に hyperscaler の vendor を呼ばずに、 自分のチームが応答できるか?

この 3 質問は、 「sovereign AI」 という抽象概念を、 月曜日のチーム会議で「我々は今どこに立っているか」 を判定する operational test に翻訳する。 1 つでも No なら、 その箇所が次の investment 対象。

着眼点

「Sovereign」 は政策語ではなく engineering 仕様だ ── という re-framing

講演冒頭の policy 定義 → engineer 定義への翻訳が、 この講演の最大の貢献。 「data flow / model choice / infrastructure / observability / operations 全てに対する明示的 control」 という技術的定義は、 policy maker や弁護士の言葉ではなく、 monday morning の sprint planning で扱える粒度。 これは Laurie Voss が「eval は ML jargon ではなく『テスト』だ」と reframe した手法 と相似で、 抽象用語を engineering vocabulary に降ろす業界貢献。

主権の spectrum 設計 ── 「完全 air gap」 でも 「完全 SaaS」 でもない中間の発見

4 pillar × max control / max convenience の spectrum は、 sovereignty を 2 値ではなく多次元の調整パラメータとして扱う設計。 air gap → private VPC → sovereign cloud → SaaS という連続軸を、 data / model / infrastructure / operations の 4 軸で 独立に調整できる ことに気づくと、 「金融サービスだから全 pillar で air gap」 ではなく、 「model は self-hosted、 data は VPC、 observability は OpenTelemetry self-host、 でも storage は sovereign cloud」 のような細粒度設計が可能になる。 cost と compliance の両立点を技術的に探索する余地を開く。

Open source orchestration framework の地政学的意味

deepset の Haystack が欧州系企業の Bosch / Airbus / 欧州委員会・ドイツ連邦省庁で本番採用されている事実は、 「米国 hyperscaler に依存しない AI 本番運用 stack」 の現実的選択肢が存在することを意味する。 これは Anthropic を NVIDIA + Microsoft が $350B で抱える米国側構造 や、 Pentagon 7 社契約 の調達側構造に対する、 欧州側の「自前 stack で動かす」 路線の 1 つの代表例。 Eoin Mulgrew が国家の組織側で Insurgency Model を組んでいる時、 同じ欧州で Bilge が実装側で orchestration framework を提供している ── この 2 つは 「欧州が AI 主権をどう実装するか」 の up-down ペア。

動画の構成

• (00:00) 自己紹介 / deepset = Haystack の開発元 / 欧州大手と公共部門が顧客
• (01:15) Sovereign AI の policy 定義 → engineer 定義への翻訳
• (02:01) 4 pillar 詳説: データ主権 (jurisdiction + access permissions)
• (02:49) インフラ主権の spectrum (air gap → VPC → sovereign cloud → SaaS)
• (04:28) モデル主権 (tightly coupled vs swappable + 訓練データ origin)
• (05:49) 運用主権 (monitoring + human in the loop + versioning)
• (06:29) 「Sovereignty is a spectrum」 ── 全 pillar で sovereign な必要はない
• (07:08) 月曜日の現実 ── model 差し替えで何が壊れるか
• (07:56) jurisdiction 移行で multi-DB 管理地獄に
• (08:46) managed → on-prem で vendor lock-in の輪郭が露出
• (09:44) Observability black box + version control 問題
• (09:44) Haystack の 4 特徴 (consistent interface / explicit data flow / YAML / open source)
• (11:31) Sovereign architecture pattern (input guardrail → agent → output guardrail)
• (12:23) Agent の中身 ── LLM + tools + MCP servers + sub-agents
• (12:56) Haystack の役割 ── swappable / traceable / vendor-lock-in-free
• (14:35) Guardrail のコード実装
• (15:09) MCP toolset で local MCP server と接続
• (15:54) BM25 ベースの動的 tool search
• (16:18) Agent component + chat generator (on-prem custom)
• (17:06) Confirmation strategy ── human in the loop の実装
• (17:52) Sovereign 自己診断チェックリスト 3 問
• (18:31) 結び

出典

• What Breaks When You Build AI Under Sovereignty Constraints — Bilge Yücel, deepset (AI Engineer Europe 2026)
• deepset 公式
• Haystack (open-source orchestration framework)
• Haystack GitHub リポジトリ
• GDPR 公式
• EU AI Act 公式

用語集

• Sovereign AI ── 組織が AI システムを自分の条件 (data / model / infrastructure / observability / operations 全てに対する明示的 control) で design / deploy / operate する能力。
• 4 Pillars ── data sovereignty / model sovereignty / infrastructure sovereignty / operational sovereignty。 各 pillar が独立に調整可能な spectrum 軸。
• Haystack ── deepset が開発する open-source LLM orchestration framework。 typed input/output、 YAML serialization、 OpenTelemetry integration を備え、 sovereign AI の主要要件を満たす。
• Cloud risk ── 米国本社の SaaS を使う際に、 欧州データセンターで運用していても親会社が運用データにアクセスし得るリスク。 米国 Cloud Act / FISA 等の域外法に起因する。
• Air gap ── ネットワーク隔離環境、 EU AI Act の high-risk 要件の一部を満たす最も control の強い infrastructure 配置。
• Sovereign cloud ── 特定 jurisdiction に閉じた public cloud オファリング。 air gap と SaaS の中間で、 control と convenience の trade-off を取る選択肢。
• VPC (Virtual Private Cloud) ── public cloud 内に論理的に隔離された仮想ネットワーク。 GDPR 準拠で本番運用を回す実用的中間解。
• On-prem ── 自社拠点でのインフラ運用。 max control だが Kubernetes クラスタ管理など operational burden を全部引き受ける。
• Swappability ── application logic を変えずに model や provider を差し替えられる性質。 model sovereignty の中核要件。
• Input/Output Guardrail ── agent の前後に置く検証層。 入力側で prompt injection / 規制違反を検知、 出力側で sensitive 情報 leak を防ぐ。
• Human in the loop ── 自動化 agent の意思決定サイクルに人間の approval を組み込む設計。 EU AI Act / 各種 sector 規制が high-stake で事実上要求する。
• OpenTelemetry / OpenInference ── observability の業界標準プロトコルと LLM 拡張。 self-hosted observability stack を組むことで、 vendor を呼ばずに incident response できる operational sovereignty を実装可能にする。
• MCP (Model Context Protocol) ── Anthropic が公開した LLM ↔ ツール接続規格。 local self-host で sovereign 構成を実現できる。