ニュースの概要
EYは、AIが業務や顧客接点に組み込まれる時代に、AIへの信頼をどのように設計するかという観点から、セキュリティの考え方を示しています。生成AIは文章作成だけでなく、社内検索、営業支援、開発、判断の補助へと利用範囲を広げています。一方で、入力情報の漏えい、誤った回答の拡散、AIに与えた権限の悪用など、従来のシステム管理だけでは捉えにくい問題も増えました。重要なのは、AIを安全な道具とみなすことではなく、利用目的、データ、権限、出力の確認方法を一体で設計することです。
引用元: AI時代のセキュリティアーキテクチャ｜AIへの信頼をどう設計するか（EY）
分析・見解
AIを信用するのではなく、判断を検証できる構造にする
AIの安全性を「正しい答えを出す性能」だけで測ると、運用開始後に問題が見えにくくなる。実際には、回答の根拠を確認できるか、誰がどの情報を入力したか、AIがどの外部サービスを操作したかまで追える必要がある。信頼とは、AIが一度も間違えない状態ではない。間違いが起きても発見し、止め、修正できる状態である。
そのためには、AIの出力をそのまま業務処理へ渡さない設計が有効だ。顧客への送信、決済、契約変更、プログラムの本番反映などは、人の承認や追加確認を挟む。低リスクの要約は自動化し、高リスクの判断は確認を必須にする。この差を業務ごとに定義することが、過剰な制限と無防備な自動化の両方を避ける。
入力データと権限を分けることが漏えい防止の出発点
生成AIの事故では、モデルそのものよりも、何を入力できるか、何を参照できるかの管理不足が原因になりやすい。社内文書を検索できるAIに、全社員が人事情報や取引先の秘密まで閲覧できる権限を与えれば、回答が自然でも情報管理は破綻する。文書の機密度、利用者の役割、案件への関与を組み合わせ、必要な範囲だけを見せる設計が欠かせない。
アクセス権を一度付与して終わりにするのも危険だ。異動、退職、委託先の契約終了、プロジェクトの完了に合わせて権限を自動的に見直す必要がある。さらに、入力内容や参照先を記録し、機密情報が含まれる場合は警告や遮断を行う。これはAI専用の対策というより、ゼロトラスト（利用者や端末を最初から無条件に信じない考え方）をAIの処理単位まで細かく適用する作業である。
AIを単体で守らず、周辺サービスを含めて調べる
AIは単独で動かない。社内データベース、クラウドの保存先、外部の検索機能、業務自動化ツール、開発環境とつながる。攻撃者が巧妙な指示を入力し、AIに不適切な文書を参照させたり、外部サイトへ情報を送らせたりする「間接的な指示攻撃」も想定しなければならない。画面上の回答だけを検査しても、裏側で起きた処理を見逃す可能性がある。
対策の中心は、接続先を限定し、AIが実行できる操作を細かく分けることだ。読み取りと書き込みを同じ権限にせず、外部通信やファイル出力にも上限を設ける。監視では、通常と異なる大量参照、深夜の操作、短時間での権限変更を検知する。AIの導入審査は、モデルの性能比較ではなく、業務全体の経路を確認する審査へ変えるべきである。
事故対応と利用者教育が信頼の持続性を決める
AIの回答を人が過信する問題も見落とせない。もっともらしい誤情報は、明らかなエラーより発見しにくい。導入時には、回答の確認者、利用できる用途、禁止される入力、誤りを報告する窓口を決める。研修も一般論ではなく、実際の業務文書を匿名化した演習にすると、利用者は危険な入力や不自然な回答を理解しやすい。
今後は、AIの安全性を製品選定だけで解決するのは難しくなる。モデルを交換しても、過剰な権限や曖昧な承認手順は残るからだ。企業が持つべき優位性は、特定のAIに依存することではなく、どのモデルでも同じ基準で記録、検証、停止できる共通の土台にある。信頼を宣伝文句ではなく、監査可能な運用データとして蓄積することが、AI活用の継続条件になる。
ビジネスへの影響
導入前に業務を危険度で分け、投資先を絞り込む
AI導入を一律に許可または禁止すると、現場の利用が隠れた形で進み、かえって管理しにくくなる。まず、要約や議事録作成のように失敗時の影響が限定的な業務と、採用、融資、医療、契約、顧客への自動連絡のように結果が直接的な業務を分ける。前者は利用範囲を広げやすいが、後者は人の承認、根拠の保存、再確認の手順を必須にする。
経営会議では、導入件数だけでなく、機密情報を扱う処理の割合、承認なしで実行できる操作数、異常検知から停止までの時間を指標にするとよい。これらは安全部門だけでなく、業務部門や監査部門も共有できる実務的な数字である。
既存の仕組みにAIの管理機能を重ねて無駄を減らす
新しいAI専用基盤を最初から大規模に作る必要はない。現在のID管理、端末管理、データ分類、操作記録、事故対応の仕組みに、AIの入力と出力、参照先、実行操作を記録する機能を加える方が現実的だ。既存のゼロトラスト施策やクラウド監視を活用すれば、費用と導入期間を抑えられる。
ただし、AIの利用状況を把握できない外部サービスを無制限に認めるのは避けたい。契約前に、入力データの保存場所、学習への利用有無、削除方法、障害時の責任分担、監査用記録の取得可否を確認する。便利さだけで選ばず、撤退や切り替えが可能かまで評価することが、長期的な調達判断になる。
安全性を開発の速度と両立させる運用を作る
安全確認を最後にまとめると、現場は審査を避けて非公式なAI利用へ流れやすい。小さな実験環境を用意し、扱えるデータと操作を限定したうえで、短い周期で評価する方法が有効だ。問題がなければ対象を広げ、事故や誤回答が見つかれば範囲を戻す。こうした段階的な拡大なら、事業の速度を保ちながら統制を強められる。
最終的に問われるのは、AIを導入したかではなく、失敗したときに事業を止めずに原因を説明できるかである。経営層は、開発部門だけに責任を負わせず、情報管理、法務、監査、現場責任者を含む意思決定体制を整える必要がある。AIへの信頼は、技術の印象ではなく、日々の確認と改善を続けられる組織能力によって生まれる。