AIインシデントは運用上の危機として扱われるべきである

過去数年間、ほとんどの組織はAIリスクについてガバナンスの言葉で話してきました。

モデルは正確か？モデルは公平か？データは承認済みか？規制に準拠しているか？これらは重要な質問ですが、唯一の質問ではありません。より緊急な質問は、何かが間違ったときに何が起こるかです。

AIエージェントが予期せぬアクションを取ったときに何が起こるか？モデルが機密データを漏洩したときに何が起こるか？モデルが妄想的な回答を生成し、法的責任を生じるか、または自動化された決定が顧客、従業員、患者、またはパートナーに影響を与える場合に何が起こるか？

そして、実際的には、組織はどこに応答を調整するのか？これが現在進行中の変化です。AIリスクは、ガバナンスの問題だけでなく、運用上の回復力の問題になっています。

AIは、実験から企業の稼働マシナリーに入り込んでいます。カスタマーサポート、ソフトウェア開発、金融運用、ヘルスケアワークフロー、採用、請求処理、サプライチェーン、内部自動化に組み込まれています。AIがビジネスに接続されるにつれて、AIの障害はビジネスインシデントになります。

OECD AIインシデントモニターは、2026年1月だけで596件のAIインシデントを追跡しました。年間200%の成長です。OECD AIインシデントモニターやAIインシデントデータベースなどの取り組みは、産業が経験から学ぶことができるように、AIシステムに関連する否定的な結果や有害な結果を文書化しています。

その比較は重要です。成熟した産業は、障害を防ぐ方法と、障害が発生したときにどう対応するかを問い合わせます。

AIインシデントは従来のソフトウェアバグのように振る舞わない

従来のソフトウェアバグは、通常、比較的明確な境界があります。何かが壊れたとき、エンジニアは調査し、チームは問題を再現し、コードを修正し、修正を適用します。

しかし、AIインシデントはより複雑です。確率的、断続的、モデル、プロンプト、検索システム、プラグイン、エージェント、ユーザー、ダウンストリームビジネスプロセスの相互作用から生じる可能性があります。時には、AIシステムは設計どおりに動作していますが、設計は使用されている環境に不完全であることがあります。那により、対応がより困難になります。

消費者向けチャットボットでの妄想は一つの問題です。法的、金融的、臨床的、または人事ワークフロー内の妄想は別の問題です。テストでの偏った出力は深刻です。生産環境での決定プロセスは別のレベルのものです。メールを草案するAIアシスタントは一つのことですが、パーミッションを変更したり、返金を発行したり、レコードを更新したり、ワークフローをトリガーしたり、コードを実行したりできるエージェントは別のリスクカテゴリです。

MIT AIリスクリポジトリには、誤ったまたは誤解を招く情報、プライバシーとセキュリティの失敗、差別、悪用、システムの安全性に関する問題など、幅広いAIリスクが記載されています。OWASPのLLMアプリケーション向けトップ10も、プロンプトインジェクション、機密情報漏洩、不確実な出力の取り扱い、過度なエージェンシーのようなリスクを強調しています。これらは、抽象的な技術的な懸念ではなく、実際的な障害モードです。

AIエージェントがあまりにも多くの権限を持っている場合、人間が意図しないアクションを取る可能性があります。プロンプトインジェクションが成功した場合、システムは情報を漏洩したり、敵対的な命令に従ったりする可能性があります。機密データがモデルまたは検索システムを介して漏洩した場合、対応には法的、規制上、顧客、評判上の影響があります。那は、AIガバナンスの言葉が時々あまりにも受動的になる理由です。ガバナンスは、真実であるべきことを教えてくれます。インシデント対応は、現実がポリシーよりも速く動いているときに何をすべきかを教えてくれます。

対応はクロスファンクショナルになる

サイバーセキュリティから得られる最大の教訓は、インシデントがセキュリティチーム内に留まることはないということです。初期段階では、イベントは技術的なものに見えるかもしれません。ただし、すぐに、法務、コミュニケーション、ビジネスリーダーシップ、コンプライアンス、顧客チーム、外部顧問、保険会社、フォレンジック専門家、そして時には取締役会が関与することになります。

AIインシデントも同様のパターンに従うでしょう。

機密顧客情報を公開するモデルを想像してください。セキュリティとプライバシーチームは何が起こったかを理解する必要があります。法務は義務を評価する必要があります。コミュニケーションは顧客、規制機関、またはメディアのために準備する必要があるかもしれません。エンジニアリングはシステムを無効またはロールバックする必要があるかもしれません。ビジネスリーダーは継続性と封じ込めのバランスを取る必要があるかもしれません。

または、エンタープライズシステム全体で予期せぬアクションを開始するAIエージェントを想像してください。技術チームはそれをシャットダウンできるかもしれませんが、組織はまだ何が行われたか、誰が影響を受けたか、どのような決定が下されたか、契約上の義務がトリガーされたか、同じ障害が将来防止されるかを知る必要があります。これはAIチームだけで解決することはできません。

組織は、必要になる前にクロスファンクショナルな筋肉メモリーを構築する必要があります。つまり、明確なエスカレーショントリガー、明確な役割、明確な意思決定権、明確なコミュニケーションパス、明確なドキュメント、練習が必要です。

危機の際、調整はインフラであり、ソフトスキルではありません。

調査中のAIは対応を制御すべきではない

組織が考慮する必要がある別の問題があります。調査中のAIシステムが、対応を調整するために使用される同じコミュニケーション、ドキュメント、ワークフロー、または自動化にアクセスできる場合、組織には問題があります。

サイバーセキュリティでは、これはよく知られた原則です。ランサムウェアが企業ネットワークを妥協した場合、対応を調整するために妥協されたシステムを使用しないことです。バンド外に出ます。インシデントと対応を分離します。

同じ論理がAIにも適用されます。

AIシステムは人間の意味では悪意的ではありませんが、対応計画を参照したり、対応会議の要約を作成したり、ワークフローに影響を与えたり、次のステップを推奨したり、同じ環境内で動作したりする場合、組織は真正に対応を分離していません。

これは、エージェント型AIでは特に重要です。GoogleのセキュアAIフレームワークは、プロンプトインジェクション、データ汚染、ローグアクションなどのリスクを強調しています。これは、適切なフレーミングです。AIシステムがツール、データ、ワークフロー全体で動作する能力が高まるにつれて、組織はモデルセーフティと運用上の分離について考える必要があります。

火事を調査しているように考えてみましょう。故障したシステムにスプリンクラーコントロールを接続したくないでしょう。

準備、練習、対応、報告

AIインシデントの準備のための有用なフレームワークは、サイバーセキュリティで成熟したものと同じです。準備、練習、対応、報告です。

準備とは、インシデントの種類を事前に定義することです。偏り、妄想、データ漏洩、モデルドリフト、プロンプトインジェクション、エージェントの暴走、未承認ツールの使用、サードパーティモデルの障害などです。各種類には、さまざまな利害関係者と決定が必要です。

良いプレイブックは、200ページの文書をフォルダーに保管するものではありません。誰もが危機の際に137ページを開きません。良いプレイブックは、役割ベースで、アクセス可能で、実行可能です。法務は法務が何をすべきかを知っています。エンジニアリングはエンジニアリングが何をすべきかを知っています。コミュニケーションはいつ関与する必要があるかを知っています。取締役会は管理がエスカレートするときを知っています。

練習とは、テーブルトップ演習を実行することを意味します。1年に1回のチェックボックスとしてではなく、筋肉メモリーを構築するのに十分な頻度で。取締役会がAIインシデントについて議論する最初の時は、実際のAIインシデントの際には絶対にあってはなりません。法務、エンジニアリング、プライバシー、セキュリティ、コミュニケーションが一緒にAIの障害を処理する最初の時は、顧客がすでに質問をしている際には絶対にあってはなりません。

対応とは、生のイベントを規律を持って調整することを意味します。誰が部屋にいますか？何がわかっているか？何がまだ不確かなか？何が決定されましたか？誰が承認しましたか？12時間と48時間の間に何が変わったか?

報告とは、AI規制がより具体的なものになっていることを認識することを意味します。EU AI法には、特定の高リスクAIシステムの提供者に対する重大インシデント報告の義務が含まれています。詳細は管轄区域、業界、ユースケースによって異なりますが、方向は明確です。AIインシデントは、増加して報告を必要とします。何が起こったか、どのようなことがわかっていたか、どのような行動が取られたか、いつの間にかを明確にした記録が必要です。

AIは助けることができますが、判断を代替することはできません

AIインシデント対応が完全に自動化されるべきだという考え方があります。私は、それが間違ったフレーミングであると思います。

AIは大いに助けることができます。事実を要約できます。欠けている情報を特定できます。インシデントを以前のパターンと比較できます。事後報告書を草案できます。規制上の義務をマッピングできます。プレッシャー下にあるときに管理上の負担を軽減できます。

しかし、深刻なインシデントでは、人間は不可欠です。

誰かが事実が十分かどうかを判断する必要があります。誰かが顧客への影響を比較検討する必要があります。誰かがシステムを一時停止するかどうかを決定する必要があります。誰かが組織が報告のしきい値を超えたかどうかを判断する必要があります。誰かが説明責任と共感を持ってコミュニケーションをとる必要があります。

AIのインシデント対応における適切な役割は、危機チームを置き換えることではありません。危機チームにより良いコンテキストを、より速く提供することです。

NISTのAIリスク管理フレームワークは、AIリスク管理を4つの機能で構成することで役立ちます。ガバナンス、マッピング、測定、管理です。インシデント対応の場合、私は1つの実際的な拡張を追加します。リハーサルです。

テストされていない計画は、実際の計画ではありません。それは理論です。

取締役会もプレイブックが必要です

AIリスクは取締役会レベルのトピックになっていますが、取締役会の関与はオーバーサイトスライドで止まってはなりません。取締役会は、危機が発生する前に役割を理解する必要があります。

取締役会はいつ通知されるか？どのような決定が取締役会の入力を必要とするか？管理はどのような情報を提供するか？物議を醸すこと、顧客への影響、法的責任、規制上の義務、運用上の混乱がどのように評価されるか?

多くの組織には、セキュリティプレイブック、プライバシープレイブック、コミュニケーションプレイブック、法的プレイブックがあります。しかし、AIインシデントのための取締役会プレイブックはほとんどありません。そのギャップは、AIシステムが規制された、収益を上げる、顧客向けのワークフローに入り込むにつれて、より明らかになるでしょう。取締役会の役割は、組織がプレッシャー下でより良い決定を下すことを助けることであり、より技術的なものになることではありません。

信頼できるAIには運用上の回復力が必要です

信頼できるAIについての多くの議論があります。これは正しい志です。しかし、信頼は原則だけで作られるのではありません。信頼は、組織が準備する方法、問題を検出する方法、対応する方法、コミュニケーションする方法、意思決定を文書化する方法、改善する方法を示すときに作られます。

サイバーセキュリティは同じ進化を経てきました。組織は予防に多くの時間を費やしてきました。そうするべきです。しかし、成熟した組織は最終的に、予防だけでは十分ではないことを学びました。回復力も必要です。AIも同じ段階に入っています。

私たちは確かに、より安全なモデル、より強力なコントロール、より良い評価、より良いレッドテーミング、より良いガバナンスを構築する必要があります。しかし、私たちはインシデントが発生することも受け入れる必要があります。モデルは失敗します。エージェントは予期せぬ方法で動作します。データは漏洩します。人間はシステムを誤用します。ベンダーはミスを犯します。規制は進化します。

質問は、インシデントが発生したときに、組織が速度、調整、判断、説明責任を持って対応できるかどうかです。那が、AIが実験から信頼できるインフラストラクチャへの移行を可能にする方法です。那が、回復力が文化になる方法です。