EU AI法の下で、質問票、警戒すべき兆候、契約上の保護策、継続的なモニタリングを網羅した、体系的なAIベンダーリスク評価フレームワーク。
•
•
35 最小読了時間
トピック
大半のエンタープライズAIは社内で構築されていません。Gartnerによると、2025年までに、組織の70%以上が、第三者プロバイダーから提供される何らかの形のAIを少なくとも1つ導入すると予測されていました[1]。その数値は、その後も増加しています。しかし、多くの組織が依拠するガバナンスフレームワークは、組織が管理するソフトウェアを前提として設計されており、確率的システム、すなわち、組織が一度も見たことのないデータで学習され、組織が設定しないスケジュールで更新され、ベンダー自身にも不透明である可能性のあるロジックに従って動作するシステムを想定していません。
規制環境は、この現実に追いつきました。2025年に段階的な施行期間に入ったEU AI Actは、提供者(AIシステムを開発または市場に投入する者)と導入者(自らの権限の下でこれを使用する者)を明確に区別しています。しかし、その線引きによって導入者の責任が免除されるわけではありません。第26条は、高リスクAIシステムの導入者が、人間による監督、入力データの品質、監視、記録保持に関して、特定の義務を負うことを明確にしています[2]。調達およびコンプライアンスチームにとって不都合な真実は、ベンダーがモデルを構築したというだけでは、規制上の法的責任がベンダーに移転するわけではない、という点です。
本ガイドは、初期デューデリジェンスから継続的監視までを網羅する、体系的なAIベンダーリスク評価フレームワークを提供します。
第三者AIのリスクに異なるアプローチが求められる理由
従来のベンダーリスク管理では、稼働率、データセキュリティ、契約上のSLAを評価します。これらはAIベンダーにとっても必要ですが、それだけでは十分ではありません。AIシステムは、従来のIT調達では対応を想定していなかった種類のリスクをもたらします。
第三者AIを他のソフトウェアと根本的に異なるものにする要素は3つあります。
意思決定ロジックの不透明性。 従来型のSaaSアプリケーションは、決定論的なコードを実行します。AIシステムは、学習データ、ファインチューニングの選択、推論時パラメータによって形作られた出力を生成する場合があり、導入組織はそれらに対する可視性を持ちません。信用スコアリングモデルが申請を拒否したり、HR選考ツールが候補者を順位付けしたりした場合、導入者はその決定を説明する必要があります。ベンダーが意味のある説明を提供できない場合、導入者は、自ら解釈できない結果に対して説明責任を負うことになります。
静的ではない挙動。 従来のソフトウェアは、バージョン管理されたリリースによって変化します。AIモデルは、再学習、ファインチューニング、あるいは基盤となるデータパイプラインの変更によって挙動が変化することがあり、場合によっては正式なリリースサイクルを伴いません。調達時には許容範囲内で機能していたモデルが、その後数か月でドリフトする可能性があります。導入者がそれを知るのは、被害がすでに発生した後かもしれません。
継承されたデータリスク。 モデルの挙動を形成する学習データには、バイアス、著作権で保護された素材、または十分な法的根拠なく処理された個人データが含まれている可能性があります。導入者は、こうした上流の選択に関与していなくても、その結果を引き継ぐことになります。GDPRの下では、AIシステムが導入者のデータ処理契約と整合しない方法で個人データを処理する場合、導入者は提供者とともに執行リスクを負います[3]。
従来のベンダースコアカードでは、これらの動態を捉えることはできません。目的に即した評価フレームワークが不可欠です。
構造化されたAIベンダーリスク評価フレームワーク
以下のフレームワークは、AIベンダー評価を7つの領域に整理しています。各領域は特定のガバナンス上の懸念事項に対応しており、調達、定期レビュー、またはトリガーに基づく再評価の際にスコアリングできます。
Enzaiのようなプラットフォームを利用する組織は、このフレームワークを既存のベンダーライフサイクルのワークフローに統合し、AI固有の基準を従来のITリスク指標と並べて管理できるようになります。これにより、別個に分断されたプロセスにしない運用が可能になります。
評価用質問票
領域 | 評価基準 | スコアリング指針 |
|---|---|---|
モデルの透明性 | ベンダーはモデルの種類、アーキテクチャ系統、バージョンを開示していますか。モデルカードやデータシートを提供できますか。既知の制限事項に関する文書はありますか。 | モデルカードを含む完全開示 = 高。部分的な開示 = 中。「独自仕様のため共有不可」= 低。 |
データガバナンス | 学習にはどのようなデータが使用されましたか。ベンダーはデータ処理の法的根拠を確認できますか。データ来歴の記録はありますか。推論時の個人データはどのように扱われますか。 | 法的根拠を伴う文書化されたデータ系譜 = 高。証拠のない一般的な説明 = 中。情報なし = 低。 |
バイアスおよび公平性テスト | ベンダーはバイアス監査を実施しましたか。どの保護特性について行われましたか。結果は確認できますか。どのような是正プロセスがありますか。 | 結果を公表した独立第三者監査 = 高。文書化された内部テスト = 中。テストなし、または「その項目はテストしていません」= 低。 |
セキュリティ | ベンダーはどのようなセキュリティ認証(SOC 2、ISO 27001)を保有していますか。モデルは、敵対的攻撃、プロンプトインジェクション、データ抽出に対してどのように保護されていますか。脆弱性開示プログラムはありますか。 | 関連認証に加え、AI特有のセキュリティ対策 = 高。一般的な認証のみ = 中。認証なし = 低。 |
コンプライアンスと認証 | ベンダーは、EU AI Act、GDPR、または業界特有の規制への準拠を示せますか。高リスクシステムに関する適合性評価はありますか。 | 文書付きの適合性評価を完了 = 高。コンプライアンスプログラム進行中 = 中。コンプライアンス活動なし = 低。 |
インシデント対応 | ベンダーには文書化されたAIインシデント対応計画がありますか。通知期限はどのようになっていますか。インシデント後のレビュープロセスはありますか。 | 定義されたSLAとインシデント後レビューを含む文書化済み計画 = 高。AI固有ではない一般的なインシデントプロセス = 中。プロセスなし = 低。 |
更新および変更管理 | ベンダーはモデル更新をどのように通知しますか。変更通知期間はありますか。導入者は、本番反映前に更新をテストできますか。ロールバックは可能ですか。 | 事前通知とテスト期間およびロールバック = 高。導入後の通知 = 中。通知プロセスなし = 低。 |
サブプロセッサーおよび基盤モデルへの依存 | ベンダーは、上流のAIプロバイダー(例:OpenAI、Anthropic、Google)に依存していますか。上流プロバイダーが条件を変更したり、モデルを更新したり、障害が発生したりした場合はどうなりますか。契約上の保護は下位契約に引き継がれていますか。 | 上流プロバイダーの完全な開示と、契約上の下位引継ぎおよび代替計画 = 高。部分的な開示 = 中。開示なし、または単一プロバイダー依存で代替手段なし = 低。 |
この表は、常に更新される運用資料として扱うべきです。スコアリングのしきい値はユースケースによって異なります。たとえば、医療トリアージに用いる高リスクAIシステムには、低リスクのコンテンツ推薦ツールよりもはるかに厳格な透明性が求められます。
ベンダーに尋ねるべき重要な質問
質問票は、真のリスクを明らかにできるほど具体的でなければ機能しません。曖昧な質問には曖昧な回答しか返ってきません。以下の質問は、カテゴリ別に整理されており、実行可能な回答を引き出すことを目的としています。
モデルの透明性と説明可能性
このシステムはどのモデルアーキテクチャを使用しており、現在本番環境ではどのバージョンが稼働していますか。
想定ユースケース、既知の制限事項、性能ベンチマークを記載したモデルカードまたは技術データシートを提供できますか。
影響を受ける個人に対して、個々の予測や判断を説明するために利用可能な手法は何ですか。
モデルが第三者の基盤モデル(LLMプロバイダーなど)に基づいている場合、どの基盤モデルとバージョンを基盤としているかを開示できますか。
データガバナンスとプライバシー
このモデルの学習と検証にはどのデータセットが使用されましたか。また、データ来歴の記録を提供できますか。
学習時の個人データ処理について、GDPR(または同等の規制)上の法的根拠は何ですか。
モデルは推論時に学習データを保持、記憶、または再現しますか。データ漏えいを防ぐためにどのような保護策がありますか。
導入後に顧客データはどのように使用されますか。モデル学習に再投入されるのですか。また、顧客はオプトアウトできますか。
バイアス、公平性、および安全性
このモデルは、適用される差別禁止法に定義される保護特性全般にわたり、バイアス監査を受けていますか。
監査は誰が実施し、結果は確認できますか。
サブグループ全体で、新たなバイアスや性能低下を検出するための継続監視はどのように行われていますか。
生成AIシステムの場合、有害、誤解を招く、または法的に問題のある出力の生成を防ぐために、どのようなガードレールがありますか。
セキュリティとレジリエンス
敵対的攻撃、プロンプトインジェクション、モデル反転、学習データ抽出に対して、どのような具体的な保護策がありますか。
このシステムは、標準的なアプリケーションセキュリティテストを超えて、AI特有の侵入テストやレッドチーミングを受けていますか。
このサービスのAIコンポーネントに特有の災害復旧および事業継続計画は何ですか。
コンプライアンスと規制対応準備
このシステムはEU AI Actのリスク区分の下で分類されていますか。されている場合、どの分類を受けていますか。
第43条で求められる、高リスクAIシステムの適合性評価に関する文書を提供できますか。
当社の事業地域に適用されるAI規制への完全準拠に向けたタイムラインはどのようになっていますか。
インシデント対応と説明責任
AI固有のインシデント対応計画は何ですか。また、インシデント分類のトリガーは何ですか。
当社の導入に影響するAI関連インシデントについて、契約上の通知期限はどのようになっていますか。
過去のAIインシデントの事例と、それらがどのように解決されたかを示せますか。
すべての質問が、すべてのベンダーに適用されるわけではありません。しかし、明らかに適用される質問に対して、信頼できる回答が得られないこと自体が、重要な示唆です。
ベンダー回答におけるレッドフラッグ
ベンダー評価は、組織がどのように回答を受け止めるかと同じくらい、その回答の内容が重要です。ベンダーの回答には、警戒を強めるべき一定のパターンがあります。
機密保持を装う曖昧さ
営業秘密を保護することには正当な根拠があります。しかし、ベンダーがモデルの大まかなアーキテクチャ系統、使用した学習データのカテゴリ、あるいはバイアステストの有無を開示しない場合、それは知的財産の保護ではありません。リスクの隠蔽です。透明性に関するあらゆる質問に対して「当社のモデルは独自仕様であり、詳細は共有できません」と答えるベンダーは、導入者の規制上の義務を支えることができるベンダーではありません。
文書化の欠如
ベンダーがモデルカード、データガバナンスポリシー、またはインシデント対応計画を提示できない場合、それらが存在しない可能性が最も高いと考えられます。文書化の欠如は中立的な所見ではありません。責任ある導入を支えるために必要なガバナンス基盤へ、ベンダーが投資していないことを示しています。
監査権への抵抗
契約上の監査権に難色を示すベンダーは、それが物流上困難であると主張する場合でも、商業的に不合理であると主張する場合でも、慎重に扱うべきです。EU AI Actは、導入者が提供者のコンプライアンスを検証する必要があることを明確に想定しています[4]。監査条項に抵抗するベンダーは、精査に耐えられない可能性があります。
インシデント対応プロセスの不在
「AIインシデント対応計画は何ですか」という質問に対するベンダーの反応が沈黙である、一般的なITインシデント管理への誘導である、あるいはこれから策定するという約束であるならば、組織は、ベンダーの支援なしにAI障害の全責任を負う準備ができているかどうかを検討すべきです。
責任移転を図る条項
AIの結果に関するすべての責任を導入者に移転しようとする契約文言には注意してください。導入者にも義務はありますが、モデル性能、バイアス、または失敗に関して一切の説明責任を負わないベンダーは、自社システムに対する自信の程度を示していると言えます。
個々の回答よりも、全体の傾向が重要です。真の限界について透明性を持つベンダーは、完璧さを主張しながら証拠を何も示さないベンダーより、はるかに低リスクです。
AI調達における契約上の保護策
評価は必要ですが、それだけでは不十分です。調査結果は、法的に執行可能な契約条項に組み込まれなければなりません。標準的なソフトウェア調達契約には、AI固有のリスクに十分対応する条項がほとんど含まれていません。以下の条項は、いずれのAIベンダー契約にも含めることを検討すべきです。
監査権
契約では、導入者が、合理的な間隔で、かつ所定のトリガー事由(報告されたインシデントや規制当局からの照会など)が発生した場合に、直接または独立した第三者を通じてベンダーのAIシステムを監査する権利を付与すべきです。この権利は、モデル性能データ、バイアステスト結果、データガバナンス実務にも及ぶ必要があります。
インシデント通知
契約では、一般的なサービスインシデントとは別に、AI関連インシデントに対する最大通知期限を定めるべきです。高リスクシステムについては、検知後24時間以内の通知を出発点とするのが妥当です。通知には、インシデントの性質、影響を受けたシステム、推定影響、是正措置を含める必要があります。
データ取扱いおよび保持
契約では、顧客データがAIシステムとの関係でどのように使用されるかを正確に定めるべきです。すなわち、モデル改善に使用されるか、どのように保管されるか、いつ削除されるか、そして顧客が学習データセットからの削除を要求できるかです。これは、AI学習とデータ保護権の交差点に対する規制当局の継続的な注目を踏まえると、特に重要です[5]。
モデル変更通知
契約では、再学習、新しいデータによる更新、アーキテクチャ変更、重大なパラメータ調整を含む、モデルへの重要な変更について、ベンダーに事前通知を義務付けるべきです。通知期間は、更新後のモデルが導入者の環境で本番稼働する前に、導入者がテストを実施できるように設定する必要があります。緊急性のない変更については、30日間の通知期間を基準とするのが妥当です。
パフォーマンスベンチマークとSLA
従来の稼働率SLAに加え、契約では、精度のしきい値、公平性指標、レイテンシ要件を含む、AIシステムの測定可能なパフォーマンスベンチマークを設定すべきです。これらのベンチマークへの違反は、定められた是正義務、必要に応じて解約権を発生させるべきです。
責任の配分
契約では、AIに起因する損害について、各当事者の統制の程度を反映した形で責任を配分すべきです。モデル、学習データ、更新サイクルを管理するベンダーは、それらの構成要素の欠陥について、相応の責任を負うべきです。ベンダーに全面的な補償を認める包括的な免責は、AI導入には適切ではありません。
強固な契約はガバナンスの代替にはなりませんが、ガバナンスを実効化するための執行手段を提供します。
継続的監視:一度きりの評価を超えて
調達時に一度だけ実施して保管したAIベンダー評価は、コンプライアンス上の記録にすぎず、リスク管理の実践ではありません。AIシステムは変化し、それに伴ってリスクも変化します。
継続監視の指標
組織は、複数の観点で継続監視を構築すべきです。
性能ドリフト。 調達時に設定したベンチマークに対して、AIシステムの出力品質を追跡します。劣化は、モデルドリフト、データパイプラインの問題、または開示されていないモデル変更を示している可能性があります。
インシデントの頻度と深刻度。 すべてのAI関連インシデントを、ヒヤリ・ハットを含めて記録し、時間の経過とともに傾向を把握します。異常な出力の頻度増加は、調査を要します。
規制動向。 システムのリスク区分を変更したり、導入者に新たな義務を課したりする可能性のある、適用されるAI規制の変化を監視します。
ベンダーの財務および業務の安定性。 財務的な困難に直面しているベンダーは、モデル保守、セキュリティ、コンプライアンスへの投資を減らす可能性があります。これらはいずれも導入者に直接影響します。
再評価のトリガー
以下の事象は、通常のレビューサイクルとは別に、ベンダーの全面的な再評価をトリガーすべきです。
ベンダーが大規模なモデル更新またはアーキテクチャ変更を発表した場合
組織の導入に関わる場合、または公に報告された場合を含め、重大なAIインシデントが発生した場合
規制指針によりAIシステムのリスク区分が変更された場合
組織がAIシステムの利用方法を変更し、リスクプロファイルが実質的に変わった場合
ベンダーが買収、合併、または重大なリーダーシップ変更を経験した場合
ガバナンスワークフローへの監視の組み込み
効果的な継続監視には、意思だけでは不十分です。既存のガバナンスの運用サイクルに、ベンダー監督を統合するツールが必要です。Enzaiは、継続的な第三者AI監視のためのインフラを提供し、評価結果、契約上の義務、リアルタイムのパフォーマンス指標を単一のガバナンスワークフローに接続します。この統合がなければ、監視義務は時間の経過とともに形骸化し、最も注意が必要な時に組織を無防備にしてしまいます。
ガバナンスはイベントではありません。継続的な実践です。
第25条の落とし穴:導入者が提供者になるとき
EU AI Actにおける最も重要でありながら十分に理解されていない規定の一つは、導入者が提供者として再分類される条件に関するものです。第25条 は、導入者がすでに市場に出ている高リスクAIシステムに自らの名称または商標を付す場合、高リスクシステムに実質的な変更を加える場合、AIシステムの意図された目的を変更して高リスク化する場合、または第三者が元の提供者との契約に基づいて既に市場に投入した高リスクシステムを市場に投入する場合、導入者は提供者とみなされると定めています[6]。
これは、第三者AIをカスタマイズする組織に直接的な影響を及ぼします。ベンダーのモデルを独自データでファインチューニングすること、追加の処理層によって出力を変更すること、あるいはベンダーが示した想定目的とは実質的に異なるユースケースで展開することは、それぞれ再分類の引き金となり得ます。
再分類の影響は重大です。提供者は、高リスクシステムに関するEU AI Act上の義務を全面的に負います。これには、適合性評価、技術文書、上市後監視、EUデータベースへの登録が含まれます。これらの義務は、導入者に課されるものよりもはるかに重いものです。
落とし穴を回避するための実務上の対応
意図された利用目的を文書化する。 ベンダーが示すAIシステムの意図された利用目的と、組織の実際のユースケースを明確に記録してください。差異がある場合は、法務およびコンプライアンスチームによるレビューが必要です。
カスタマイズの範囲を評価する。 第三者のAIシステムをファインチューニング、再学習、または実質的に変更する前に、その変更が本法における「実質的な変更」に該当するかを評価してください。欧州委員会によるこの点に関する指針によって、さらなる明確化が見込まれますが、現時点でもリスクは存在します[7]。
契約上の明確化。 ベンダー契約において、どの当事者が提供者で、どの当事者が導入者であるかを明確に区分し、その区分がどの条件で変更され得るかを明示してください。
早期に法的助言を得る。 提供者と導入者の境界は、ラベルではなく実質の問題です。契約書で自らを導入者と呼んでいても、実際には提供者として行動していると判断されれば、その事実認定を覆すことはできません。
第25条の落とし穴は、仮定の話ではありません。組織が第三者AIシステムをますますカスタマイズし、ファインチューニングするにつれ、導入と提供の境界は、AI規制の中でも最も活発に争われる領域の一つになる可能性があります。
防御可能な第三者AIプログラムの構築
第三者AIベンダーリスクの評価は、調達時のチェックボックスではありません。これは、法務、技術、運用の各領域にまたがる継続的なガバナンス規律です。このリスクを効果的に管理する組織は、AIベンダーの監督を、財務統制やデータ保護と同等の厳格さで扱う組織です。
ここで示したフレームワークは、体系的評価、具体的な質問、契約上の保護策、継続的監視、そして導入者を一夜にして提供者へ変え得る規制上の落とし穴への認識という、出発点を提供します。規制のある環境で高リスクAIシステムを導入する組織にとって、これらはいずれも任意ではありません。
第三者AIガバナンスを大規模に運用したい組織に向けて、Enzaiは、ベンダー評価の管理、義務の追跡、AIポートフォリオ全体にわたる継続的監督を実現するためのプラットフォーム基盤を提供します。デモをご依頼いただき、実際の運用をご確認ください。
Enzaiは、業界をリードするエンタープライズAIガバナンスプラットフォームです。抽象的なポリシーから実運用の監督へと移行する企業を支援するために設計されています。当社のAIリスク管理プラットフォームは、エージェント型AIガバナンスの管理、包括的なAIインベントリの維持、そしてEU AI Act準拠の確保に必要な専門インフラを提供します。複雑なワークフローを自動化することで、Enzaiは、 ISO 42001 やNISTのような国際基準との整合性を維持しながら、企業が自信を持ってAI導入を拡大できるよう支援します。
参考文献
[1] Gartner, 「Gartner、組織の70%がAIガバナンスへ重点を移すと予測」, 2024年。
[2] 欧州議会および理事会、規則(EU)2024/1689(EU AI Act)、第26条 - 高リスクAIシステムの導入者の義務、2024年。
[3] 欧州データ保護会議、「AI ActとGDPRの相互関係に関する意見」、2024年。
[4] 欧州議会および理事会、規則(EU)2024/1689(EU AI Act)、第13条(透明性および導入者への情報提供)および第26条(導入者の義務)、2024年。
[5] 欧州データ保護会議、「AIモデル学習における個人データの使用に関するガイドライン」、2025年。
[6] 欧州議会および理事会、規則(EU)2024/1689(EU AI Act)、第25条 - AIバリューチェーンに沿った責任、2024年。
[7] 欧州委員会、「AIシステムの実質的変更に関するガイドライン」(今後公表予定)、EU AI Actの前文88で言及。
組織がAIを採用し、管理し、監視する能力を、企業レベルの信頼性で強化します。規模で運営する規制対象の組織向けに構築されています。

