2009年、外科医のアトゥール・ガワンデ氏と世界保健機関(WHO)が支援するチームは、わずか19項目の外科手術チェックリストによって、世界8つの病院で合併症や死亡率を劇的に削減できることを示しました。千ページに及ぶプロトコルでも、包括的なフレームワークでもありません。1枚のカードに印刷された19項目です。航空業界も数十年前に同じ教訓を学んでいます。飛行前チェックリストはバインダーではなく、パイロットの手のひらに収まるものです。それから20年近く経った今、私はセキュリティチームがAIベンダーに300項目もの質問票を送りつける様子を目にしています。その半分は「あなたのアプローチについて説明してください」で始まり、実際の障害を検知できるものはほとんどありません。フレームワークは十分にあります。足りないのはチェックリストなのです。
このタイミングには意味があります。EU AI法の汎用AIに対する執行の牙は今年8月に控えており、その背後では高リスク分野の義務化が段階的に進行しています。そしてISO/IEC 42001は今やサードパーティリスク評価の質問票に名指しで登場するようになりました。NIST AIリスクマネジメントフレームワークは、北米において「AIリスクプログラムを持っていることを示してほしい」という要求に対するデフォルトの回答になっています。さらにOECD原則、HITRUSTのAI保証の取り組み、FDAのようなセクター規制当局、そして拡大を続ける米国州法のパッチワークも加わり、今やほとんどの企業が2つ以上のフレームワークを同時に運用する状況に置かれています。
ここで人々を驚かせるのは、フレームワーク自体は概ね一致しているという点です。公開されているクロスウォーク(対応表)を見ると、ISO 42001、NIST AI RMF、EU AI法の間にはかなりの重複が見られます。プログラムを慎重に構築した組織であれば、単一のプロセスと文書のセットで3つすべてを満たすことができます。問題はフレームワークそのものではありません。問題は、それらのフレームワークが実際の担当者の机に届く質問票、監査、証明書へと変換される下流工程で起きているのです。
質問票の問題
最近AIセキュリティ質問票を受け取ったことがある方なら、私が何を指しているかお分かりでしょう。数百に及ぶ質問、自由記述の回答、そして「あなたのAIシステムが公平性をどう確保しているか説明してください」や「責任あるAIへのアプローチを説明してください」といった問いかけです。こうした質問には致命的な欠陥が3つあります。
第一に、これらの質問は証拠ではなく文章でしか答えられません。そして文章はコンプライアンスではなく、創作文にすぎないのです。成熟したプログラムを持つベンダーと、優れた文章力を持つベンダーは、見分けのつかない回答を出してきます。この方式は自信に満ちた作り話に報酬を与え、正直な不確実性を罰してしまいます。どのベンダーでも一切の証拠を出さずに答えられる質問を見かけたとき、私はその質問が誰のリスクも減らしていないと確信します。
第二に、これらの質問は評価対象となるシステムの本質を無視しています。前回のコラムで書いたとおり、LLMは確率的なシステムであり、再現やトラブルシューティングが極めて困難です。モデルの挙動に関するある時点での証明書は、モデルのバージョンが変わったり、システムプロンプトが更新されたり、temperature設定が変更されたりした瞬間に古くなってしまいます。「あなたのモデルはバイアスのかかった出力を生成しますか?」を単純な二択のコンプライアンス質問として尋ねることは、こうしたシステムの本質を根本的に誤解しています。適切な質問は、それを測定し、記録し、その傾向を示せるかどうかです。
第三に、これらの質問はリスクに応じてスケールしません。私はマーケティング用チャットボットを運用するベンダーと、臨床意思決定支援を展開するベンダーの両方に、同じ300項目の追加質問票が送られているのを見たことがあります。すべてが高リスク扱いになれば、実質的に何もリスクとして扱われていないのと同じです。EU AI法は少なくともこの点は正しく捉えており、その4段階のリスク分類は、まさに義務が結果の重大性に応じてスケールするように存在しています。多くの自作質問票には、そうした階層が一切ありません。
実用的なものとは実際どのようなものか
AIコンプライアンスに対して、私は異なる基準を提案したいと思います。それはチェックリストの教訓から直接借りたものです。すなわち、フレームワークの質はその中で最も質の低い質問によって決まる、というものです。ベンダー質問票であれ、社内レビューのゲートであれ、監査プログラムであれ、AI評価に組み込まれるあらゆる質問は、次の5つのテストに合格すべきです。
1. 証拠で答えられること。すべての質問は、ログ、設定、評価レポート、データフロー図、アーキテクチャ文書といった証拠に対応づけられるべきです。唯一可能な答えが小論文であるなら、その質問は削除するか書き直すべきです。「モデルセキュリティへのアプローチを説明してください」は、「本番環境における推論パラメータ(モデルバージョン、temperature、top P、トークン上限)のログを提供してください」に置き換えられます。
2. リスク階層に応じた範囲設定。まずシステムを分類し、その階層にふさわしい質問だけを行います。限定的リスクの社内ツールには10個の質問で十分です。患者データや金融上の意思決定に関わるシステムには、フルセットの対応が必要です。チャットボットベンダーに附属書IV相当の詳細な文書要求を送るべきではありません。
3. 可能な限り測定可能または二値的であること。「評価(eval)を実施していますか?頻度は?直近の安全性ベンチマークの合格率は?」という質問は、「テスト哲学を説明してください」という質問より常に優れています。前者ならレビュー担当者はスコア化し、傾向を追い、ベンダー間で比較できます。
4. 意思決定に関連していること。各質問について、「もし悪い答えが返ってきたら、我々の判断は変わるか?」と自問してください。その質問を削除しても結果が何も変わらないなら、その質問を削除すべきです。この一つのテストだけで、私がこれまで見てきた質問票の半数は消えます。
5. 一度マッピングし、あらゆる場面で再利用すること。コントロールセットを一度構築したら、公開されているクロスウォークを使って、同じ証拠ベースからNIST、ISO、EU AI法の要求に答えます。1つのプロセスで、複数の規制上の読み替えが可能になります。もし各チームがフレームワークごとに別々の文書を作成しているなら、同じ作業に対して3倍のコストを払っていることになります。
本当に重要な質問
AIベンダー評価を1枚のカードに凝縮するとしたら、次のようになるでしょう。モデルはどこに展開されており、上流のプロバイダーは誰か。どのようなデータが入り、どのようなデータが出ていくのか、そしてそれはどこに記録されているのか。そのデータのコピーはどこに、どのくらいの期間保存され、誰がアクセスできるのか。リクエストごとにどの推論パラメータが記録されており、インシデントを再現できるか。評価スイートの内容は何をカバーしており、本番環境に対してどのくらいの頻度で実行されているか。人間による監督ポイントはどこにあり、それなしでシステムは何ができるのか。モデルが本来してはいけないことをした場合のインシデント対応プロセスはどうなっているか。モデルの入れ替えや変更はどのように行い、切り替えにはどのようなテストのゲートがあり、下流の顧客には通知されるのか。
これらは、レッドチーミングに関する前回のコラムで私が主張したのとほぼ同じ質問だと気づかれたでしょう。展開前に、モデルがどこで動作し、どのような入力を処理し、出力がどのようなものかを把握し、事業リスクが時間とともにどう見直されるかを知っておくべきだ、というものです。これは偶然ではありません。優れたセキュリティ上の質問と優れたコンプライアンス上の質問は最終的に収束します。なぜならどちらも、自分が運用しているシステムを本当に理解しているかどうかを問うものだからです。
モデルカードを標準化する
こうした質問の半分を、そもそも尋ねられる前に排除できる業界的な解決策が一つあります。標準化されたモデルカードです。私は前回のコラムでこの点を取り上げ、モデルカードはある程度の知見を提供する傾向があるものの、業界全体で測定基準が標準化されていないと指摘しました。この点は、レッドチーミングよりもコンプライアンスにおいてさらに重要な意味を持ちます。現状、モデルプロバイダーはそれぞれ異なるものを公開しています。異なる評価ベンチマーク、異なる安全性の開示内容、学習データに関する詳細さの違い、同じ用語に対する異なる定義です。この一貫性の欠如こそが、下流の顧客一社一社に独自の質問票を作らせ、ベンダー一社一社に同じ質問へ百通りの異なる答え方をさせる原因になっています。
代わりに、固定されたスキーマを持つモデルカードを想像してみてください。モデルのバージョンと系譜、学習データの出所カテゴリ、データの保存場所と保存期間、公開スコア付きの共通評価ベンチマークのコアセット、文書化された安全性の緩和策、デフォルトの推論パラメータ、そしてモデルの入れ替えやバージョン更新のたびに紐づく変更履歴です。SOC 2が成功したのは、それが巧妙だったからではありません。レポートがどのようなものかについて全員が合意したからこそ、1つの証拠が何千もの顧客に答えられるようになったのです。モデルカードはAI版のそれになるべきです。一度作成し、常に最新の状態に保ち、あらゆる評価における最初の50個の質問の代わりとして機能させるのです。標準化団体はこの構想に近づきつつあり、ISO 42001の文書要件とEU AI法の透明性義務のどちらも、その方向を示唆しています。しかしスキーマが共通化されるまでは、購入者側が毎回同じ項目を同じフォーマットで要求することで、この問題を前進させることができます。SOC 2を標準化したのは調達側からの圧力でした。それはモデルカードも標準化できるはずです。
私が共有したい重要な洞察はこうです。コンプライアンスとは証拠の問題であり、AIにおいて証拠とはオブザーバビリティの問題である、ということです。今まさに到来している執行の波を乗り切る組織とは、最も分厚いバインダーを持つ組織ではありません。ログ、評価、文書が設計段階から整っていて、どんな合理的な質問にも数週間かけた小論文ではなく、数分で証拠をもって答えられる組織です。これが私の言う「タイムレス・コンプライアンス」の意味です。フレームワークは今後も増え続け、規制当局は今後も足並みが揃わなくなり、モデル自体も3年後には見分けがつかないものになっているでしょう。しかしその根底にある原則は変わりません。自分のシステムを把握すること、重要な事柄を記録すること、継続的に測定すること、リスクに応じて精査の度合いをスケールさせること、そして行動に移せない質問は決してしないこと。これらは外科手術チェックリストや飛行前カードにおいても真実であり、SOC 2やISO 27001においても真実であり、現行世代のAI標準の後に来るものが何であれ、真実であり続けるでしょう。包括的な網羅性は動き続ける標的です。誠実に実践されたシンプルさこそが、永続するのです。
本コラムは、生成AIのセキュリティ確保に関する複数回シリーズの第3回です:
第1回: Back to the Future, Securing Generative AI
第2回: Trolley problem, Safety Versus Security of Generative AI
第3回: Build vs Buy, Red Teaming AI
第4回: Timeless Compliance(本コラム)
詳細はAI Risk Summit | Ritz-Carlton, Half Moon Bayで
翻訳元: https://www.securityweek.com/timeless-compliance-why-better-questions-beat-bigger-frameworks/
