AIガバナンスにおけるデータ保護の議論は、その多くが出発点を間違えています。ベンダーがどの認証を保有しているか、どのサブプロセッサーをリストアップしているか、そのクラウドがどのリージョンにあるか、といった点を問います。これらはいずれも正当な問いです。しかし、お客様のAIエージェントを監視するという特定のカテゴリのツール — インフラ上のあらゆるエージェント、セッション、モデル、MCPサーバーを検出し、それぞれが到達できる範囲をマッピングするツール — については、その下にもっと根本的な問いが隠れています。すなわち、そのガバナンスツール自体がそもそもお客様のデータを受け取ることがあるのか、という問いです。
その答えが「はい」であれば、お客様は新たなプロセッサー、機密情報の新たなコピー、侵害や召喚状の対象となり得る、あるいは外部に情報を送信させられ得る新たな場所を作り出してしまったことになります。一方、その答えが「いいえ」 — 設計上、構造的に「いいえ」 — であれば、その下流にあるGDPRの問いの大半は格段に小さくなります。これがAIプラットフォームをセルフホスティングする論拠であり、誇張することなく正確に論じる価値があります。
重要なプライバシー保証は構造的なものであり、証明書ではない
SOC 2レポートやISO 27001認証は、ベンダーが保有するデータをめぐるプロセスを備えていることを示します。これは有用ですが、あくまでお客様のデータへのアクセスをどう統制しているかについての主張にすぎません。はるかに強固な保証は、そもそもデータを保持しないことです。一度も受け取っていないものは、漏洩させることも、不適切に扱うことも、開示を強制されることもできません。
セルフホスティングはまさにそれを実現します。コントロールプレーンが自社のホスト、クラスター、クラウドの内部 — 外部への送信を一切伴わない完全なエアギャップ環境を含む — で稼働するとき、それが観測する機密情報がお客様のペリメータを越えることは決してありません。ベンダーがお客様の運用データを一切見ることがないため、ベンダーは運用データのサブプロセッサーにはなりません。これは監査して確認すべきポリシー上の約束ではなく、アーキテクチャ上の事実です。
本製品の現状を明確にしておきます。Olivares AIはリリース前です。SOC 2、ISO/IEC 27001、EU AI Actその他いかなるフレームワークの認証も取得しておらず、監査も進行中ではありません。本製品は、これらのフレームワークが検証する統制目標 — 監査ロギング、アクセス制御、完全性、暗号化、変更管理 — に対応するよう設計されており、その時が来れば監査を受ける準備が整っています。以下で述べるレジデンシーの論拠はいかなる認証にも依存しておらず、それこそがまさに要点です。
ペイロードではなくエッジを
核心となる設計上の判断は、何を保存するかにあります。AIガバナンスツールは誰が何に触れられるかを把握する必要があります。それらの接触を通じて流れるクエリの内容、プロンプトの本文、シークレット、個人データそのものは必要ありません。
そのため、このグラフが保存するのはペイロードではなくエッジです。すなわち、エージェントとリソースの間のアクセス関係と、そのアクセスが読み取り（R）か読み取り/書き込み（RW）かです。data-export-job → prod-postgres (RW) がエッジにあたります。そのジョブが読み取った行は保存されません。マップは、あるエージェントが s3://billing-exports 内のオブジェクトに到達したことを記録しますが、そのエクスポート内容をコピーすることはありません。
| 保存するもの（アクセスマップ） | 保存しないもの |
|---|---|
| エージェントのアイデンティティ（ロール／アプリケーション名） | クレデンシャルの値、トークン、キー |
到達されたリソース（prod-postgres） | クエリの本文、結果の行 |
| アクセスタイプ — RまたはRW | プロンプトおよびレスポンスのペイロード |
| タイムスタンプ、結果、信頼度レベル | シークレット、通信中のPII |
シークレットや個人データを含む可能性のある入力は、何かが書き込まれる前に編集（リダクション）およびシークレットスキャンが行われます。したがってリダクションは、後からのクリーンアップとしてではなく、収集のエッジで実行されます。保存しないものは漏洩させようがなく — 漏洩させようのないものは、GDPRの処理範囲を拡大させることもありません。
データがペリメータ内にとどまる仕組み
運用において、これを誠実に保つ3つの特性があります。
読み取り優先の観測。 コレクターは、お客様がすでに生成している信号 — アプリケーションログと監査ログ、OpenTelemetry、そしてカーネルレベルのグラウンドトゥルースのバックストップとしてのeBPF — を通じて観測します。エージェントのデータ経路上のプロキシではないため、アクセスの形状を見ても内容は見ず、たとえ障害が発生しても本番環境を停止させることは決してありません。お客様のトラフィックをコピーする必須の中間者（man-in-the-middle）は存在しません。
テレメトリの外部送信なし。 セキュア・バイ・デフォルトとは、外部への自動送信（phone-home）がないことを意味します。ベンダーへのテレメトリは、お客様が明示的に有効化しない限りオフです。お客様の環境に関する情報 — エージェント名も、アクセスマップも、利用回数も — は、デフォルトでベンダーに送り返されることはありません。
外部送信ゼロのエアギャップ。 切断された、規制された、あるいは機密扱いのネットワークにおいては、コントロールプレーンは完全にローカルで稼働し、ライセンス検証はオフラインで行われます。外部への経路は一切ありません。これに尽きます。「EUのデータはお客様の管理下にあるEUインフラ上にとどまらなければならない」というデータレジデンシー要件に対して、エアギャップのセルフホスト型デプロイメントは可能な限り文字どおりの答えです。データの移動先がそもそも存在しないため、データは決して移動しません。
保持と消去（リテンション・パージ）は設定可能なので、アクセスマップでさえどれだけの期間保持するかをお客様が制御できます。
GDPR第28条への対応 — 誠実に
GDPR第28条は、管理者とプロセッサーの関係、およびデータ処理契約が定めるべき内容を規定しています。ここで重要な観察は、セルフホスト型デプロイメントにおいては、お客様の運用データに関する通常の「ベンダー＝プロセッサー」という関係が大部分において消失するということです。ツールがお客様のインフラ内で稼働し、そのデータを一切受け取らないため、ほとんどのデプロイメントにおいてお客様は自社環境内で自社データの管理者かつプロセッサーであり続けます。
だからといってDPAが無意味になるわけではありません。商業上の関係においては、責任を明文化すること — ソフトウェアサプライチェーン、サポートアクセス、将来導入され得るマネージドコンポーネントについて — は依然として有益です。第28条に基づくデータ処理契約は、エンタープライズ調達向けにご要望に応じてご提供します。変わるのはその範囲です。お客様の個人データがどこへ送られたかというリストは存在しません。なぜなら、そもそも一度も送られていないからです。これは「当社のサブプロセッサーリストを信頼してください」よりもはるかに短く、はるかに弁護しやすい、DPO（データ保護責任者）や調達チームとの対話になります。
これは構造的な論拠であるため、その境界についても同じ誠実さで扱うべきです。セルフホスティングはレジデンシーと処理の責任をお客様に移すものであり、その責任を取り除くものではありません。お客様は依然としてホストを保護し、保持期間を制御し、誰がアクセスマップを読めるかを統制する必要があります — そしてそのマップ自体が機密情報です。だからこそ、それに対するあらゆる特権的な閲覧は監査され、各コンポーネントは相互TLS（mutual TLS）で互いに認証し合います。本製品はベンダー側の攻撃対象領域をほぼゼロにまで縮小しますが、運用者の責任を免除するものではありません。
結論
規制当局、DPO、あるいは自社のセキュリティチームから「このAIガバナンスツールを採用したら、当社のデータはどこへ行くのか」と問われたとき、可能な限り最も強固な答えは「どこにも行きません — データは一切外に出ず、ツールがそれを見ることもありません」です。その答えはアーキテクチャに由来します。すなわち、セルフホスト型の実行、ペイロードではなくエッジを保存する設計、書き込み前のリダクション、テレメトリの外部送信なし、そして外部送信ゼロのエアギャップ運用です。証明書は優れたプロセスを裏付けることはできますが、そもそも受け取っていないデータがもたらす保証には匹敵しません。
この体制の完全かつ誠実な解説 — 未認証の現状を含むコンプライアンスの立場、およびGDPR第28条のDPAがどう位置づけられるか — については、/security をご覧ください。その主張を裏付けるコードをご覧になりたい場合は、製品全体が /open-source ページにてAGPL-3.0のもとでセルフホスト可能です。