主権制約下で AI を構築する際の課題 - deepset GmbH ビルゲ・ユチェル氏

主権 AI の実現：クラウド依存からの脱却と技術的ロードマップ

EU AI 法や各国のデータローカライゼーション規制が強化される中、企業は「自社のインフラで AI を制御する」必要性に迫られています。単なるコンプライアンス対応ではなく、ベンダーロックインを解消し、長期的なコストと柔軟性を確保するための具体的な技術的アプローチが必要です。

主権 AI の4 つの柱：エンジニアが定義する「制御」とは

政策用語としての「主権ある AI」は抽象的ですが、エンジニアの視点では明確な技術要件に落とし込むことができます。Deepset のヴィグエン氏は、データ、モデル、インフラ、運用の 4 つを柱とする技術的定義を提示しました。

1. データ主権：どこで保存・処理するか

企業が最も重要な資産であるデータを、信頼できる環境と管轄区域で扱うことが求められます。GDPR の観点では、欧州市民のデータは欧州内に留めるべきですが、埋め込みモデルや API を米国バージニア州のサーバーに送信すれば、即座に管理権を失います。また、組織内で閲覧すべきではないユーザーがデータにアクセスできる状態も、主権侵害となります。

2. モデル主権：誰が選択・切り替えを行うか

特定のモデルプロバイダーに強く依存し、API の停止や価格改定でシステムが止まる状態は主権の欠如です。アーキテクチャを変更せずにモデルを交換できる「交換可能性」を持ち、トレーニングデータの起源（どこでどのデータを使って学習されたか）を把握・管理できることが重要です。

3. インフラ主権：計算リソースはどこにあるか

AI アプリケーション層がどこで実行されるかが問われます。エアギャップ環境なら EU AI 法への準拠が可能ですが、プライベート VPC や主権クラウド、あるいは SaaS を利用する場合は、ベンダーのアクセス権限（例：米国企業の Cloud Act）によってリスクが生じます。

4. 運用主権：監視と管理は誰が行うか

システムが本番環境でどのように振る舞うかを監視し、モデルの入出力やバージョン管理を統制・監査可能な形で管理できる能力です。特に人事や金融などの高リスク領域では、人間をループに組み込む必要があり、インシデント対応の責任体制も明確である必要があります。

「主権には連続性がある。すべての柱において完全な主権を必要とするわけではありません。重要なのは、システムにおけるベンダーロックインのレベルを理解し、ドメインに応じて必要な主権のレベルを選択することです。」

移行が招く技術的課題：コード再実装と管理負担の増大

マネージャーや CIO から「既存システムを主権化してほしい」と指示された場合、API からセルフホスト（オンプレミス）へ移行する際、多くの技術的障壁に直面します。

まず、API ロジックの変換が必要です。フロントエンドの API を呼び出すロジックを、新しいモデルアーキテクチャやローカル環境向けに書き直す必要があります。プロンプトの調整も求められ、システムのパフォーマンスをゼロから評価し直す膨大な工数がかかります。

次に、データの法域移動に伴う複雑化です。米国にホストされていたデータを欧州へ移す際、複数のデータベースを管理することになり、検索機能（Search）の再設計が課題となります。クエリ分類を行うか、複数 DB への同時送信を行うかなど、アーキテクチャの見直しが必要です。

さらに、インフラ管理の負担増も無視できません。クラウドベンダーに任せていた Kubernetes クラスターの管理やハードウェア制限（CPU と GPU の接続など）、ネットワーク管理を自前で担うことになります。また、これまで観測性がなかったシステムで、ブラックボックス状態から脱却するためにログ保存やトレーシングの統合を急ぐ必要も生じます。

Haystack が解決する課題：統一インターフェースと YAML による柔軟性

これらの課題に対し、オープンソースのオーケストレーションフレームワーク「Haystack」が有効な解決策となります。Haystack を採用することで、モデルや環境の変更を最小限のコードで可能にします。

1. 統一されたインターフェース

クラウドからセルフホスト型へ移行する際、コードの数行を変更するだけで対応可能です。異なるモデルプロバイダーやハードウェアに依存しない一貫した API を持つため、基盤の変更がアプリケーションロジックに直結しません。

2. 明示的なデータフローと追跡可能性

Haystack のパイプラインでは、すべての入力と出力が型付けされ宣言されます。これにより、アプリケーション全体で「どのデータがどこにあるか」を正確に把握できます。エージェントのような非決定論的アーキテクチャでも、ツール呼び出しやその出力を追跡可能にし、LLM 観測ツールや OpenTelemetry との統合も容易です。

3. YAML によるバージョン管理

アプリケーションを YAML にシリアライズできるため、Git などのバージョン管理システムで履歴を追跡できます。問題発生時は該当コミットに戻り、ハッシュを確認するだけで復旧が可能となり、監査要件にも対応します。

4. オープンソースによるブラックボックスの排除

内部の仕組みが隠されていないため、必要な時にコードをカスタマイズしたりコンポーネントを拡張したりできます。これは「主権」を実現するための根本的な条件です。

具体的な実装：ガードレールと交換可能なエージェント構成

主権 AI を実現するアーキテクチャでは、安全性と柔軟性を両立させる設計が求められます。例えば、ユーザー入力に対してプロンプトインジェクションや規制違反をチェックする「ガードレール」を最初に配置し、安全なリクエストのみをエージェントへ流すフローを構築します。

エージェント内部では、公開データには他社の専用モデルを利用しつつ、ガバナンスやナレッジベース処理にはローカルで実行するモデル（Mistral、Nvidia 製など）を切り替えるハイブリッド構成が可能です。また、数百のツールを持つ場合でも、動的なツール検索（BM25 など）を活用してコンテキストを最適化し、必要な機能のみを呼び出します。

さらに、人間をループに組み込む戦略も可能です。重要なアクション（例：支払いリクエスト）を実行する前にエージェントが人間の承認を求めるよう定義し、リスク管理を徹底できます。このように、Haystack を用いれば、すべての要素を交換可能かつ追跡可能な状態に保ちながら、必要なレベルの主権を持ったシステムを構築できます。

主権 AI 実装のためのチェックリスト

最終的に、自社のシステムが本当に「主権ある」ものになっているかを確認するには、以下の質問に答える必要があります。

• モデルの交換可能性: アプリケーションロジックを変更せずに、異なるモデルプロバイダーへ切り替えられるか？
• 再現可能なログ: コンプライアンスに従い、実行ログを再現可能かつ監査可能な形で保存しているか？
• インシデント対応の独立性: ベンダー（ハイパースケーラー）に連絡することなく、自チームでインシデントに対応できる体制があるか？

主権 AI は単なる理想論ではありません。技術的なアーキテクチャ変更を通じてリスクを管理し、長期的なコントロールを確保するための現実的なロードマップです。今こそ、ベンダーへの依存度を再評価し、自社の条件で AI を設計・運用する準備を進める時です。