AIデータはオンプレミスにあります。モデルはお客様のハードウェア上で動作します。これは主権AIと呼ばれます。
では、考えてみてください。機密性の高いリクエストを処理するモデルを誰が決定するのか？ガードレールロジックはどこで実行されるのか？その推論リクエストからのテレメトリはどこへ送られるのか？
ほとんどのエンタープライズAI導入において、正直な答えは次のとおりです。ベンダーオーケストレーションレイヤー、ホスト型SaaSポリシーエンジン、そして自分で選んだわけではないクラウドリージョンで動作する可観測性パイプラインです。データは境界を離れることはなく、ランタイムの権限が境界内に入ることもありませんでした。
これがコントロールプレーン主権問題（Control Plane Sovereignty Problem）であり、ほとんどのエンタープライズAI主権戦略（Enterprise AI Sovereignty Strategy）が残しているギャップです。
レジデンシートラップ（Residency Trap）
データ保存要件は現実のものだ。管轄コンプライアンス、国境を越えた転送制限、データ引力の制約—これらすべてが実際のアーキテクチャに影響を及ぼす。問題は、データ保存が主権の代理として採用されており、その代理が不完全であることだ。
データが存在する場所と実行時の権限が存在する場所は、別の問題です。多くのエンタープライズAI導入は現在、私が偽の主権と呼ぶものを示しています。ワークロードはローカルで実行されますが、ルーティングロジック、ポリシー適用、テレメトリパイプライン、またはアイデンティティ権限は依然として外部のSaaSシステムに解決されます。インフラストラクチャは主権があるように見えますが、運用権限は外部に固定されたままです。
主権展開の前提と、ランタイム権限が実際に存在する場所との間のギャップが、現在のエンタープライズAIにおける定義上のコントロールプレーンの問題です。
4つのプレーン、4つの問い
ランタイムで主権が現実のものとなるためには、4つの機能プレーンがローカル権限下になければなりません：
推論ルーティング（Inference routing） — どのモデルがどのリクエストを処理するか、どのフォールバックが発動するか、負荷がどのように分散されるか。ベンダーのオーケストレーションレイヤーがこのロジックを所有している場合、ルーティング動作は外部から変更可能です。ベンダーのポリシー変更により、あなた側で変更チケットを発行することなく、AIワークロードがリクエストをルーティングする方法が変更される可能性があります。
ポリシーの適用 — ガードレール、コンテンツフィルター、安全性評価、レートロジック。ほとんどのエンタープライズAI導入では、管理されたガードレールサービスが便利であるため、これを外部委託しています。その結果、AIシステムの動作境界は、自社で運用していないシステムによって定義されます。ベンダーがポリシーモデルを更新すると、AIの動作が変わります。
可観測性 — どのような推論リクエストとレスポンスが、どこに、どのような保持ポリシーの下でログ記録されるか。もしあなたのAIオブザーバビリティがSaaSパイプラインに依存している場合、推論テレメトリはトランザクションごとに境界の外に出ます。リクエスト、レスポンス、コンテンツ — モデルがどこで実行されていてもベンダーインフラストラクチャにストリーミングされます。
IDと認可 — 誰がどのような条件でモデルを呼び出せるか。トークンの検証がローカルフォールバックなしでサードパーティのIdPを経由する場合、モデルアクセス権限は外部依存性に左右される。
診断: 推論パスの各ステップについて: 今夜このコンポーネントを所有するベンダーがその動作を変更した場合、ユーザーが気づく前にあなたは知ることができるか？
いずれかのプレーンに対して答えが「ノー」である場合、そのプレーンはあなたの運用権限の境界外にあります。
3つのトポロジー
エンタープライズAIシステムは、3つのパターンのいずれかで推論をルーティングします。それぞれに異なる主権の姿勢があります。
完全委任(Fully delegated): ベンダーのオーケストレーション層がモデル選択、フォールバック、ガードレール、テレメトリーを管理します。すべてのランタイムプレーンは外部から変更可能です。
| プレーン | 誰がそれを変更できるか |
|---|---|
| ルーティングロジック | ベンダー |
| ガードレールポリシー | ベンダー |
| テレメトリー保持 | ベンダー |
| モデル選択 | ベンダー |
分割権限: ローカルルーターはモデル選択とフォールバックを担当する。推論実行とガードレール評価はベンダー管理のままである。これは、意図的な主権投資を行ったが、コントロールプレーン分析を完了していない組織で最も一般的なアーキテクチャである。ルーティングの主権は現実のものである。ポリシーと可観測性の露出はそうではない。
| プレーン | それを変更できる者 |
|---|---|
| ルーティングロジック | ローカル |
| ガードレールポリシー | ベンダー |
| テレメトリ保持 | ベンダー |
完全主権スタック: 4つのプレーンすべてのローカル運用。すべてのランタイムプレーンはローカル権限下にある。運用オーバーヘッドはかなり高い。主権の主張は、敵対的条件下で唯一維持されるものである。
予期せぬ故障モード
ランタイム依存関係の継承は、このように蓄積されます。ローカルに展開されたAIシステムから上流のベンダー管理のランタイムサービスへの運用権限の移譲です。それは徐々に起こります—ここに管理されたガードレール、そこにホストされた観測可能性パイプライン、スタックにすでにあったためにベンダーID統合が行われます。単一の決定が問題を生み出すわけではありません。蓄積された依存関係の表面が問題を生み出すのです。
最も重要な障害モードは、運用エラー状態が発生しないものです。ワークロードは正常に動作し続けます。リクエストは処理され、レスポンスが返されます。その間、推論テレメトリーはベンダーの可観測性SaaS（Software as a Service）にストリーミングされ、あなたが記述していないポリシーの下でログ記録、保存、クエリが可能になります。
これはサイレント・ソブリンティ障害（Silent Sovereignty Failure）です。権限がアラームも、ヘルスチェックの失敗も、運用ダッシュボードに何か問題があるというシグナルもなく境界を離脱します。それは、探している場合にのみ見えます。
主権は、実行時動作が外部から変更可能なままであるときに失敗します。
実際に必要なもの。
実用的な出発点は依存関係マップです。推論パスをホップごとに辿り、各ステップで実行を所有する者を特定し、各依存関係を sovereign（主権）、delegated-safe（委任セーフ）、delegated-risky（委任リスク）に分類します。ほとんどのチームは、依存関係の表面積が予想よりも広いことに気づきます。それはアーキテクチャの悪い決定のせいではなく、ベンダー統合が主権上の懸念としてマッピングされることなく蓄積される方法によるものです。
安全に委任できないコンポーネントは、外部の可変性が主権主張を直接損なうもの、すなわちポリシー執行、ルーティング権限、監査証跡の整合性です。ベンダーがあなたの承認なしにこれらの動作を変更できる場合、AIシステムの実行時ガバナンスは外部に依存することになります。
主権漂流監査役(Sovereign Drift Auditor) — 構造化された出発点が必要な場合は、この依存関係分析をインフラ構成に対して実行します。
主権は運用上の特性であり、展開場所ではありません。実行時の権限が境界を離れると、主権も離れます。