大半のエンタープライズ向けAIは、自社内だけで構築されているわけではありません。Gartner社によると、2025年までに70%以上の組織が、サードパーティプロバイダーから提供される何らかの形態のAIを少なくとも1つは導入していると予測されていました [1]。その数値は現在、さらに増加しています。しかし、ほとんどの組織が依存しているガバナンスフレームワークは、自社がコントロール可能なソフトウェア向けに設計されたものであり、未だかつて見たことのないデータでトレーニングされ、自社で設定できないスケジュールで更新され、さらにはベンダー自身にとっても不透明なロジックに従って動作する確率的システムのために設計されたものではありません。

規制の状況は、この現実に追いついています。2025年に段階的な施行期間に入ったEU AI法は、プロバイダー（AIシステムを開発する、または市場に投入する者）と、デプロイヤー（自らの権限のもとでAIシステムを使用する者）との間に明確な一線を画しています。しかし、その境界線によってデプロイヤーの責任が免除されるわけではありません。第26条では、高リスクAIシステムのデプロイヤーが、人間による監視、入力データの品質、モニタリング、および記録保持に関して具体的な義務を負うことが明確に規定されています [2]。調達部門やコンプライアンス部門にとって受け入れがたい真実は、ベンダーがモデルを構築したからといって、規制上の法的責任が単にそのベンダーに移転するわけではないということです。

本ガイドでは、初期のデューデリジェンスから継続的なモニタリングに至るまで、構造化されたAIベンダーリスクアセスメントのフレームワークを提供します。

サードパーティAIリスクにおいて異なるアプローチが求められる理由

従来のベンダーリスク管理では、稼働時間、データセキュリティ、および契約上のSLAを評価します。これらはAIベンダーにとっても引き続き必要ですが、それだけでは十分ではありません。AIシステムは、従来のIT調達では対処できないような性質のリスクをもたらします。

サードパーティAIが他のソフトウェアと根本的に異なる点として、以下の3つの特性が挙げられます。

意思決定ロジックの不透明性。 従来のSaaSアプリケーションは、決定論的なコードを実行します。これに対し、AIシステムが出力する内容は、トレーニングデータ、ファインチューニングの選択、および推論時のパラメータによって形作られますが、導入組織はこれらを把握することができません。与信スコアリングモデルが申請を却下する場合や、人事選考ツールが候補者をランク付けする場合、デプロイヤーはその意思決定について説明を求められます。ベンダーが合理的な説明を提供できない場合、デプロイヤーは解釈できない結果に対して責任を負うことになります。

非静的な挙動。 従来のソフトウェアは、バージョン管理されたリリースを通じて変更されます。一方、AIモデルは、再トレーニング、ファインチューニング、または基盤となるデータパイプラインの変更によって挙動が変化することがあり、これらは正式なリリースサイクルを経ずに行われる場合もあります。調達時に許容可能なパラメータの範囲内で機能していたモデルが、その後の数ヶ月で劣化（ドリフト）することもあります。デプロイヤーは、実際に不利益が生じるまでそのことに気づかない可能性があります。

継承されるデータリスク。 モデルの挙動を左右するトレーニングデータには、偏見、著作権で保護された素材、または適切な法的根拠なしに処理された個人データが含まれている場合があります。デプロイヤーは、それらの決定に一切関与していないにもかかわらず、上流での選択の結果を引き継ぐことになります。GDPRの下では、AIシステムがデプロイヤーのデータ処理合意書と矛盾する方法で個人データを処理した場合、デプロイヤーはプロバイダーとともに対処リスクを負うことになります [3]。

従来のベンダースコアカードでは、これらの動向を捉えることができません。目的に特化したアセスメントフレームワークが不可欠です。

構造化されたAIベンダーリスクアセスメントフレームワーク

以下のフレームワークは、AIベンダーの評価を7つの領域に分類しています。各領域は特定のガバナンスの懸念事項に対応しており、調達時、定期的なレビュー時、または特定の事象を契機とする再評価時にスコアリングが可能です。

Enzaiなどのプラットフォームを使用している組織は、このフレームワークを既存のベンダーライフサイクルワークフローに統合し、AI特有の基準を従来のITリスク指標と切り離された別個のプロセスではなく、並行して管理することができます。

アセスメント質問票

この表は、生きた文書として扱われるべきです。スコアリングのしきい値はユースケースによって異なります。ヘルスケアの優先度判定で使用される高リスクAIシステムには、低リスクのコンテンツ推奨ツールよりもはるかに厳格な透明性が求められます。

ベンダーに尋ねるべき主な質問

質問票は、潜在的なリスクを暴くのに十分なほど具体的である場合にのみ機能します。曖昧な質問は、曖昧な回答を招きます。カテゴリ別に整理された以下の質問は、実行可能な回答を引き出すように設計されています。

モデルの透明性と説明可能性

1. このシステムはどのようなモデルアーキテクチャを使用しており、現在どのバージョンが本番環境にデプロイされていますか？

2. 想定されるユースケース、既知の制限事項、およびパフォーマンスベンチマークを説明するモデルカードまたは技術データシートを提供できますか？

3. 個々の予測や決定を影響を受ける個人に説明するために、どのような方法が利用可能ですか？

4. モデルがサードパーティの基盤モデル（例：LLMプロバイダーなど）に基づいている場合、どの基盤モデルおよびバージョンをベースに構築しているか開示できますか？

データガバナンスとプライバシー

1. このモデルのトレーニングと検証にはどのようなデータセットが使用されましたか？また、データの来歴記録を提供できますか？

2. トレーニングにおいて個人データを処理する、GDPR（または同等の規制）上の適法な根拠は何ですか？

3. モデルは推論中にトレーニングデータを保持、記憶、または再現しますか？データ漏洩を防ぐために、どのようなセーフガードが設けられていますか？

4. 導入後、顧客データはどのように使用されますか？モデルのトレーニングにフィードバックされますか？また、顧客はそのオプトアウトが可能ですか？

バイアス、公平性、および安全性

1. このモデルは、適用される差別禁止法で定義されている保護特性全体にわたって、バイアスに関する監査を受けていますか？

2. 誰が監査を実施しましたか？また、結果をレビュー用に提供することは可能ですか？

3. サブグループ間での新たなバイアスの発生やパフォーマンスの低下を検知するために、どのような継続的モニタリングが行われていますか？

4. ジェネレーティブAIシステムの場合：有害、誤解を招く、または法的に問題のある出力の生成を防ぐために、どのようなガードレールが設けられていますか？

セキュリティと回復力

1. 敵対的攻撃、プロンプトインジェクション、モデルインバージョン、またはトレーニングデータの抽出に対して、具体的にどのような保護対策が講じられていますか？

2. システムは、標準的なアプリケーションセキュリティテストを超えた、AI特有のペネトレーションテストやレッドチーム演習を受けていますか？

3. このサービスのAIコンポーネントに特化した災害復旧およびビジネス継続計画（BCP）はどのようなものですか？

コンプライアンスと規制への備え

1. このシステムはEU AI法のインシデントリスクカテゴリに分類されていますか？分類されている場合、どの区分に該当しますか？

2. 第43条で義務付けられている、高リスクAIシステムの適合性評価のドキュメントを提供できますか？

3. 当社が事業を展開する法管轄区における、適用されるAI規制への完全な準拠に向けたタイムラインはどのようになっていますか？

インシデント対応と説明責任

1. AI特有のインシデント対応計画はどのようなものですか？また、どのような場合にインシデントとして分類されますか？

2. 当社の導入環境に影響を与えるAI関連インシデントの、契約上の通知タイムラインはどのようになっていますか？

3. 過去のAIインシデントの例と、それらがどのように解決されたかを示すことができますか？

すべての質問がすべてのベンダーに当てはまるわけではありません。しかし、明らかに該当する質問に対して信頼できる回答が得られないこと自体が、1つの「評価結果」となります。

ベンダーの回答におけるレッドフラグ（危険信号）

ベンダー評価においては、回答の内容だけでなく、企業がどのように回答を受け取るかも重要です。ベンダーの回答に以下のようなパターンが見られる場合は、より厳格な精査が必要となります。

機密保持を口実にした曖昧さ

営業秘密を保護することには正当な理由があります。しかし、モデルの一般的なアーキテクチャファミリー、使用されたトレーニングデータのカテゴリ、またはバイアステストの存在の開示を拒否するベンダーは、知的財産を保護しているのではなく、リスクを隠蔽していると言えます。透明性に関するあらゆる質問に対して「当社のモデルは独自開発のものであり、詳細を共有することはできません」と回答するベンダーは、デプロイヤーの規制上の義務をサポートできるベンダーではありません。

ドキュメントの欠如

ベンダーがモデルカード、データガバナンスポリシー、またはインシデント対応計画を提示できない場合、最も考えられる理由は、これらが存在しないということです。ドキュメントがないことは、中立的な結果ではありません。それは、ベンダーが責任ある展開をサポートするために必要なガバナンスインフラストラクチャに投資していないことを示しています。

監査権への抵抗

ロジスティクス的に困難である、あるいは商業的に合理的でないといった理由をつけて、契約上の監査権に難色を示すベンダーには、注意を払う必要があります。EU AI法は、デプロイヤーがプロバイダーのコンプライアンスを検証する必要があることを明示的に想定しています [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法における最も重大で、かつ最も理解されていない規定の1つは、デプロイヤーが「プロバイダー」として再分類される条件に関するものです。第25条では、すでに市場に存在する高リスクAIシステムに自らの名前または商標を付す場合、高リスクシステムに実質的な変更を加える場合、AIシステムの想定される目的を変更して高リスクシステムにする場合、またはサードパーティが元のプロバイダーとの合意に基づいてすでに市場に投入した後に高リスクシステムを市場に投入する場合、デプロイヤーはプロバイダーとみなされると規定されています [6]。

これは、サードパーティのAIをカスタマイズする組織に直接的な影響を及ぼします。ベンダーのモデルを独自のデータでファインチューニングすること、追加の処理レイヤーを介して出力を変更すること、またはベンダーが表明した想定目的とは実質的に異なるユースケースにデプロイすることは、それぞれ再分類を発生させるのに十分な可能性があります。

再分類の結果は重大です。プロバイダーは、適合性評価、技術文書、市販後モニタリング、およびEUデータベースへの登録を含む、高リスクシステムに対するEU AI法の義務をすべて負うことになります。これらの義務は、デプロイヤーに課されるものよりもはるかに重いものです。

罠を避けるための実践的なステップ

• 想定される目的を文書化する。 AIシステムに対するベンダーの表明した想定目的と、組織の実際のユースケースの明確な記録を維持します。いかなる相違も、法務およびコンプライアンスチームによってレビューされるべきです。

• カスタマイズの範囲を評価する。 サードパーティのAIシステムをファインチューニング、再トレーニング、または実質的に変更する前に、その変更が同法における「実質的な変更」に該当するかどうかの評価を実施します。この点に関する欧州委員会のガイドラインによってさらなる明確化がもたらされると期待されていますが、リスクは現在も存在しています [7]。

• 契約上の明確さ。 ベンダーとの合意において、どちらの当事者がプロバイダーであり、どちらがデプロイヤーであるかを明確に定義し、その分類が変更される可能性のある条件を指定します。

• 早期に法務の助言を求める。 プロバイダーとデプロイヤーの境界線は、ラベルではなく実質の問題です。契約書の中で自らをデプロイヤーと呼んでいても、プロバイダーとして行動しているという事実認定を覆すことはできません。

第25条の罠は仮定の話ではありません。組織がベンダーのAIシステムをカスタマイズし、ファインチューニングするケースが増えるにつれて、デプロイ（導入）とプロビジョン（提供）の境界線は、AI規制において最も活発に争われる分野の1つになる可能性が高いと考えられます。

信頼性の高いサードパーティAIプログラムの構築

サードパーティのAIベンダーリスクアセスメントは、調達における単なるチェックボックスではありません。それは、法務、技術、および運用の領域にまたがる、継続的なガバナンスの規律です。このリスクを効果的に管理できる組織とは、AIベンダーの監視を財務管理やデータ保護に適用するのと同様の厳格さで扱う組織です。

ここで概説したフレームワークは、構造化されたアセスメント、具体的な質問、契約上の保護措置、継続的なモニタリング、そして一晩でデプロイヤーをプロバイダーに変えてしまいかねない規制上の罠への認識といった、出発点を提供するものです。規制された環境で高リスクAIシステムを導入する組織にとって、これらのいずれも欠かすことはできません。

サードパーティのAIガバナンスを大規模に運用することを目指す組織向けに、Enzaiはベンダーのアセスメントを管理し、義務を追跡し、AIポートフォリオ全体で継続的な監視を維持するためのプラットフォームインフラストラクチャを提供します。実務における機能を確認するには、デモをリクエストしてください。

Enzaiは、大手のエンタープライズAIガバナンスプラットフォームであり、組織が抽象的なポリシーから運用上の監視へと移行するのを支援するために特別に構築されています。当社のAIリスク管理プラットフォームは、エージェント型AIガバナンスを管理し、包括的なAIインベントリを維持し、EU AI法への準拠を確実にするために必要な専用インフラストラクチャを提供します。複雑なワークフローを自動化することにより、Enzaiは企業が自信を持ってAIの導入を拡大できるようにすると同時に、ISO 42001やNISTなどのグローバル基準との整合性を維持します。

参考文献

[1] Gartner, "Gartner Predicts 70% of Organisations Will Shift Focus to AI Governance," 2024.

[2] European Parliament and Council, Regulation (EU) 2024/1689 (EU AI Act), Article 26 - Obligations of Deployers of High-Risk AI Systems, 2024.

[3] European Data Protection Board, "Opinion on the Interplay Between the AI Act and the GDPR," 2024.

[4] European Parliament and Council, Regulation (EU) 2024/1689 (EU AI Act), Article 13 (Transparency and provision of information to deployers) and Article 26 (Deployer obligations), 2024.

[5] European Data Protection Board, "Guidelines on the Use of Personal Data in AI Model Training," 2025.

[6] European Parliament and Council, Regulation (EU) 2024/1689 (EU AI Act), Article 25 - Responsibilities along the AI value chain, 2024.

[7] European Commission, "Guidelines on Substantial Modification of AI Systems" (forthcoming), referenced in Recital 88 of the EU AI Act.