AIリスクレジスターはインシデント対応計画ではない

AIの問題が報告された瞬間を想像してみてください。

セキュリティアナリストが、社内のAIツールが実際の業務ワークフローの中で誤った推奨事項を出してしまったというチケットを確認しているとします。もはやこのリスクは理論上のものではありません。これがセキュリティインシデントなのか、モデルの問題なのか、プライバシーの問題なのか、ベンダーの問題なのか、それとも単に「AIがやらかしたこと」なのか、誰もが答えを知りたがっています。リスクレジスターには「不正確な出力」という項目があり、深刻度の評価まで付いているかもしれません。

しかし、今まさに全員が抱いている疑問――「これを止める権限を持つのは誰なのか」――への答えは、そこには書かれていません。

これこそ、多くのAIガバナンスプログラムが今なお埋めきれていないギャップです。組織はAIリスクを特定し、文書化し、ガバナンスの分類項目に振り分けることには上達してきています。しかし、AIリスクが実際に調査・封じ込め・説明を要する「事象」へと変わる、その運用上の瞬間への備えは、まだ十分とは言えません。

セキュリティプログラムにおいて、この違いは重要です。リスクレジスターは懸念事項を文書化することはできても、証拠を保全したり、経営層に通知したり、影響を評価したり、AIシステムの稼働を継続すべきかどうかを判断したりすることはできません。セキュリティ責任者に必要なのは「AIは失敗しうる」と書かれた別のスプレッドシートではなく、実際に失敗が起きたときに実行できる対応モデルなのです。

リストは対応そのものではない

リスクレジスターは可視性を生み出すという点で有用です。組織がリスクに名前を付け、深刻度を比較し、責任者を割り当て、経営層に懸念を伝える助けになります。AI導入の初期段階では、この可視性が特に重要です。多くの組織はまだ、AIがどこで使われ、どのデータが関わり、どの業務プロセスに影響を及ぼしうるのかを把握している最中だからです。

しかし、リスクレジスターはコントロール(統制)ではありません。セキュリティチームは、他の領域ではすでにこのことを理解しています。脆弱性のリストは脆弱性管理プログラムそのものではなく、サードパーティリスクのリストはベンダーリスク管理機能そのものではありません。リストはあくまで作業の出発点に過ぎないのです。

AIリスクにも同じ問題が当てはまります。「モデルの出力は不正確な場合がある」というリスク項目は、誰が出力品質を監視するのか、どの程度のエラーなら許容範囲なのか、どのような証拠を保全すべきなのか、誰がシステムを一時停止できるのかを定義していません。「機微なデータが漏えいする可能性がある」というリスク項目も、プロンプトがログに記録されているか、出力がレビューされているか、ベンダーが送信されたデータを利用できるのか、この事象がプライバシー・法務・セキュリティのどの部門へのエスカレーションを引き起こすべきかを説明してはくれません。

ここに、AIガバナンスが実態以上にしっかりしているように見えてしまう落とし穴があります。組織にはポリシーも、委員会も、受付フォームも、リスクレジスターもあるかもしれません。しかし、こうした成果物があるからといって、運用上の備えが自動的にできているわけではありません。何かが実際に起きたとき、真に問われるのは、組織が次に何をすべきか分かっているかどうかなのです。

AIインシデントは必ずしも侵害のようには見えない

課題の一つは、AIインシデントが従来のサイバーセキュリティインシデントのようには見えないことが多い点です。侵害には見慣れたパターンがあります――不正アクセス、データの窃取、マルウェア、認証情報の侵害、システム内の不審な活動などです。一方でAIの失敗はもっと厄介な形を取ることがあります。最初は誤った推奨事項、誤解を招く要約、安全でない自動化、誤った分類、あるいは意思決定を静かに歪めてしまう出力として現れるかもしれません。

だからといって重要性が下がるわけではありません。セキュリティワークフローで使われるAIツールがアラートを誤分類することもあります。生成AIアシスタントが回答の中で機微な情報を漏らしてしまうこともあります。業務プロセスに組み込まれたモデルが時間とともにドリフトし、信頼性の低い推奨を出すようになることもあります。ベンダー管理のAI機能が、組織側が十分にレビューしていないアップデートの後に挙動を変えてしまうこともあります。

セキュリティチームには、こうした事象を実務的に仕分ける方法が必要です。AIのエラーすべてを本格的なセキュリティインシデントとして扱う必要はありません。とはいえ、意味のあるワークフローでAIを利用しているすべての組織は、AI関連の事象がどのように報告され、トリアージされ、エスカレーションされるのかを把握しておくべきです。この仕組みがなければ、チームは責任の所在を巡って議論するうちに時間を浪費し、その間にも影響は広がり続けてしまいます。

最初のステップは、何をAIインシデントとみなすかを定義することです。この定義は、セキュリティ、プライバシー、安全性、運用、コンプライアンスに関わる懸念事項を幅広く網羅できるものでありながら、従業員がいつ何かを報告すべきかを判断できるほど具体的である必要があります。分かりにくいチャットボットの回答は、データ漏えい事象と同じレベルの対応を必要としないかもしれませんが、どちらもレビューへの道筋は用意しておくべきです。

調査の前に証拠が存在していなければならない

インシデント対応は証拠に依存します。サイバーセキュリティの世界では当たり前のことですが、AIガバナンスの議論では見落とされがちです。何が起きたのか、誰がそのシステムを使ったのか、どのデータが関わったのか、どのような出力が生成されたのかを再構築できなければ、組織はその事象を調査することも、自らの対応を説明することも困難になります。

AIシステムは、この証拠の連鎖を複雑にしがちです。プロンプトがログに記録されていないこともあります。出力が保持されていないこともあります。ベンダーのツールが提供する可視性が限定的なこともあります。モデルのバージョンは変わることがあります。ユーザーがAI生成コンテンツを、出典を残さないまま別のシステムにコピーしてしまうこともあります。事業部門がAIの出力をシステムの事象としてではなく、単なる推奨事項として扱ってしまうこともあります。

セキュリティ責任者は、AIシステムが本番稼働に移行する前に、証拠に関する要件を整備するよう働きかけるべきです。少なくとも、組織はどのようなログが利用可能か、どのくらいの期間保持されるか、誰がアクセスできるか、それらが調査に十分な内容かを把握しておく必要があります。リスクの高いユースケースについては、モデルのバージョン、プロンプト履歴、出力履歴、ユーザーの操作、データソース、下流の意思決定に関する記録も必要になるかもしれません。

これは、あらゆるAIとのやり取りを厳重に監視する必要があるという意味ではありません。監視の度合いはリスクに見合ったものであるべきですし、組織はプライバシー、法務、労務上の配慮も依然として尊重する必要があります。要点はシンプルです。実際の業務に影響を及ぼすほど重要なAIシステムであれば、何か問題が起きたときに証拠の痕跡を残せるだけの重要性もある、ということです。

責任の所在は暗黙のままにしておけない

AIの責任所在は分散しがちです。事業部門がユースケースのスポンサーとなり、データサイエンスチームがモデルを構成し、IT部門がプラットフォームを管理し、セキュリティ部門がリスクを評価し、ベンダーが基盤となる機能を提供する――誰もが関与しているのに、展開後に完全な説明責任を負う人が誰もいない、ということが起こり得ます。

このあいまいさは、インシデントの最中に危険な形で表面化します。AIツールが信頼性の低い出力を出し始めたとき、組織はそのシステムの責任者、その業務プロセスの責任者、そして利用を継続するか停止するかを判断する責任者が誰なのかを把握している必要があります。ガバナンス委員会は監督機能を提供できますが、展開済みのすべてのAI機能について運用上の責任者を務めることは通常できません。

セキュリティプログラムは、特に機微または影響の大きいワークフローで使われるAIシステムについて、明確に名前を付けた責任者を置くよう求めるべきです。責任には、監視、例外対応、ユーザー向けガイダンス、ベンダーとの調整、インシデントのエスカレーションに対する責任が含まれるべきです。また、意思決定権も含まれるべきです。権限を伴わない説明責任は、スプレッドシートに書かれた単なる名前に過ぎないからです。

最も難しい問いは、往々にして「一時停止の権限」を巡るものです。リスクが許容範囲を超えたとき、誰がAIシステムを停止・制限・ロールバック・廃止できるのか。この問いに展開前に答えていなければ、組織はプレッシャーの中でその答えを迫られることになりかねません。

セキュリティ責任者にはAI対応プレイブックが必要

AI対応プレイブックは複雑である必要はありませんが、実効性のあるものでなければなりません。従業員がAIに関する懸念をどう報告するか、事象がどうトリアージされるか、どのような証拠が保全されるか、誰が調査するか、法務やプライバシー部門がいつ関与するか、そして誰が運用上の判断を下せるかを明示すべきです。さらに、経営幹部にいつ通知する必要があるかも定義しておくべきです。

プレイブックは、関与するAIシステムの種類を反映したものであるべきです。リスクの低い社内生産性ツールであれば、軽量なレビュー経路で十分かもしれません。一方、セキュリティ運用、規制対象の意思決定、顧客とのコミュニケーション、医療ワークフロー、金融プロセスを支えるAIシステムには、より強固な監視とエスカレーション体制が必要です。対応モデルは、そのユースケースが持つリスクに見合ったものであるべきです。

ここにこそ、セキュリティがAIガバナンスを官僚的なものにすることなく規律をもたらせる余地があります。セキュリティチームはすでに、エスカレーション経路を構築し、証拠を保全し、インシデントレビューを実施し、失敗の後に統制を改善する方法を知っています。チャンスは、インシデントが問題を突きつける前に、その運用上の筋力をAIガバナンスにも広げていくことにあります。

組織はまた、重要なAI関連事象について、インシデント後のレビューを実施すべきです。目的は責任追及ではなく、そこから学ぶことであるべきです。監視は機能したか。責任者は明確だったか。証拠は十分だったか。ベンダーは対応したか。ユーザーは許容される利用方法について混乱していなかったか。誰が意思決定を下せるのか、組織は把握していたか――こうした問いを検証するのです。

ガバナンスは実行可能でなければならない

AIガバナンスは、ポリシー、倫理、コンプライアンスの課題として語られることがよくあります。確かにそのすべての側面を持ってはいますが、AIシステムが本番環境に入った時点で、それはセキュリティの実行上の課題にもなります。リスクは監視されなければならず、事象は調査されなければならず、そして誰かが実際に行動を起こせなければなりません。

だからこそ、次に目指すべき成熟度の段階は、単により良い文書化を進めることではありません。組織に必要なのは、システムが稼働中で、意思決定に時間的制約があり、事実がまだ揃っていない――そんな状況でも機能するガバナンスです。その瞬間、リスクレジスターは組織が何を想定していたかを説明する助けにはなっても、対応そのものを動かしてはくれません。

セキュリティ責任者は、企業内の他の場所でAIガバナンスが完成された形で届けられるのを待つべきではありません。多くの組織がまだ軌道修正できるほど初期段階にある今のうちに、運用モデルの形成に自ら関わるべきです。目標はすべてのAIリスクを自分のものとして抱え込むことではなく、AIが実際に稼働し始めたときにそのリスクを管理できる状態を確実にしておくことです。

リスクレジスターは、経営層に「何が起こりうるか」を伝えることができます。インシデント対応計画は、実際にそれが起きたときに人々が「何をすべきか」を伝えます。AIガバナンスがセキュリティプログラムにおいて意味を持つためには、組織は両方を備える必要があります。

本記事はFoundry Expert Contributor Networkの一環として掲載されています。
参加をご希望の方はこちら