HigLabo
Latest posts
AIニュース：SaaSの裏で誰が処理している？ “隠れAI委託”が引き起こす契約リスク
DataGrail調査が示す、AI機能付きSaaSの裏側で誰がデータを処理しているのか
生成AIを組み込んだSaaSが増えるなか、いま企業実務で静かに重くなっているのが「誰が実際にデータを処理しているのか」という問題です。企業は特定のSaaSベンダーと契約していても、その裏側では別のAIモデルや外部基盤が使われていることがあります。
利用者からは見えにくいこの構造が、DPA（データ処理契約）や委託先台帳、個人情報影響評価の運用見直しを難しくします。再委託そのものが直ちに問題なのではなく、把握と説明が追いつかないことが、コンプライアンス上の盲点になりやすいという話です。
https://www.datagrail.io/blog/
SaaSを使っているだけでも、知らない第三者が関わりやすい理由
結論から言うと、SaaSの機能が高度になるほど、ベンダー自身だけで全機能を作るより、外部のAI基盤を組み合わせるほうが速く、安く、競争力も高めやすいからです。要約、検索、分類、チャット応答のような機能では、外部の大規模言語モデルが裏側で動いていることがあります。
この構造自体は不自然ではありません。ただ、利用企業の目線では、「契約相手」と「実際の処理主体」がずれて見えやすくなります。
従来のSaaSでも再委託はありましたが、生成AI機能ではモデルや基盤の変更が比較的起こりやすいと考えられます。ある時点ではA社のモデルを使っていても、別の月にはB社に切り替わることがありますし、特定機能だけ別基盤に乗ることもあります。
DataGrailが示した“見えにくいAI依存”の論点
DataGrailは近年、新しいシステムやAI利用を継続的に検出する方向性を示しています。
実務上は、企業が把握しているSaaSベンダー数よりも、実際の処理関係者が多くなることがあります。表に見えるサービスの裏で、別の事業者がAI処理を担う構造は、現実的な前提になりつつあります。
とくにSaaSを多数利用し、個人情報や顧客データを扱う法務責任者、プライバシー担当者、Vendor Management担当者にとっては、最新のプライバシー調査を踏まえて、SaaSベンダー自身が外部AIモデルを再委託利用する時代の管理方法を見直す必要があります。
https://www.datagrail.io/blog/product/introducing-vera-the-first-complete-ai-privacy-agent/
外部モデルの利用が、DPAと契約実務を複雑にする
SaaSベンダーが自社アプリの中に生成AI機能を追加すること自体は珍しくありません。その際、API経由で外部モデル提供者を呼び出していれば、入力データの一部がその先に渡る可能性があります。
利用企業から見ると、契約先は一社でも、実際には複数の事業者が処理に関与していることになります。ここで重要なのは、名称の把握だけではなく、どの機能で、どのデータが、どこへ流れるのかを見極めることです。
DPAが追いつかないのは、契約不備より変化の速さが大きい
一般にDPAでは、どのデータを、誰が、どの目的で、どう処理するかを定めます。ただ、生成AI時代は前提条件の更新が速く、契約文書が現場の実態に追いつきにくくなっています。
問題は、法務部門の努力不足というより、運用対象そのものが流動化していることにあります。同じSaaSでも、通常保存は自社基盤、要約は外部モデル、検索拡張は別クラウドという構成になっていることがあります。
その結果、契約締結時点では正しかった再委託先一覧が、数か月後には実態とずれていることも起こります。委託先管理では、文書の整備だけでなく、継続的な更新確認が欠かせません。
委託先台帳が古くなる3つのズレ
第一のズレは、「契約相手」と「実際の処理主体」のズレです。ベンダー審査では主契約先だけを見がちですが、AI機能の一部は外部モデルに依存していることがあります。台帳上は一社でも、実務上は複数社が関与している可能性があります。
第二のズレは、「導入時の確認」と「機能追加後の実態」のズレです。SaaSは後からAI要約や自動分類を追加しやすいため、初回審査の情報だけでは足りません。リリースノートやサブプロセッサ一覧の更新確認が必要になります。
第三のズレは、「説明の粒度」と「利用企業が必要とする粒度」のズレです。ベンダーが「AIを利用しています」とだけ説明していても、法務や情シスが知りたいのは、どの処理がどこに送られるかというデータフローです。
委託先管理では、形式的な説明だけでなく、実質的な監督ができる情報粒度が重要になります。日本を含む個人情報保護実務でも、この観点は重要です。
AI要約機能をオンにしただけで、処理条件は変わりうる
たとえば営業支援SaaSで、会議メモのAI要約機能を有効化したとします。利用者の感覚では便利機能をオンにしただけでも、実際には会議内容、話者情報、顧客名、商談情報などが、要約処理のため別経路に送られる可能性があります。
ここでの代表的な確認項目としては、保存の有無、学習利用の有無、送信先の地域、再委託先の変更通知があります。AI機能の有効化は、単なるUI変更ではなく、データ処理条件の変更になりうるからです。
もし委託先台帳やDPA確認が旧状態のままだと、社内説明と実態がずれます。ベンダー評価では、利用規約だけでなく、FAQ、セキュリティ文書、サブプロセッサページ、製品アップデート情報まで横断して確認するほうが現実的です。
Amazon Web Services, Inc.怖がるべきはAIそのものではなく、説明できない依存関係
この論点の本質は、「AIは危険だ」という単純な話ではありません。怖いのは、誰が何を処理し、どこまで責任を負うのかを、自社で説明できなくなることです。
ビジネス部門は導入スピードを重視し、法務は契約整備を求め、情シスは実装と監視を見ます。しかし依存関係が見えないと、どの部門も全体像を持ちにくくなります。
今後の実務では、導入前審査だけでなく、導入後監視の比重が高まると見られます。AI機能追加時の再評価、サブプロセッサ更新の定期確認、ベンダー向け質問票の見直しは、現実的な対応として重要です。
質問も「AIを使っていますか」だけでは不十分です。「どの機能で外部モデルを使うのか」「入力データは保存されるのか」「再委託先の変更はどう通知されるのか」まで確認する必要があります。
“使うかどうか”ではなく“説明できる形で使えているか”へ
DataGrailが示しているのは、SaaSの裏側で進む見えにくいAI依存が、従来の委託先管理を難しくしている現実です。DPAや委託先台帳が機能しにくくなるのは、担当者の努力不足だけではなく、AI導入で処理関係が動的になったからです。
対策の出発点はシンプルです。契約相手を見るだけで安心せず、どの機能が、どのデータを、どの外部モデルに触れさせるのかを確認することです。
検討段階の実務としては、利用中SaaSを「AI利用開示あり」「第三者モデル開示あり」「再委託先不明」の3区分で棚卸しし、DPA、委託先台帳、個人情報影響評価の見直し優先度をつけると、次の行動が明確になります。
派手なニュースではなくても、実務への影響は大きい論点です。AI導入の議論は、使うかどうかから、説明できる形で使えているかへ移ってきています。