リスクに応じたコントロールをどう設計するのか
リスクに応じたコントロールを設計する必要がある。ここで陥りやすいのは、高リスクが見込まれる用途を怖がるあまり、すべての用途に同じだけの強い統制をかけてしまうことである。しかし、それでは活用が進まず、結果として現場が抜け道をつくってしまうような環境になりやすい。重要なことは、リスクに応じて“統制の強さ”を変えることだ。
このときの主要論点は、次の5つに整理できる。
- アクセス制御:誰がどのAI機能を使うことができ、どのデータにアクセスできるかを制御する。これは従来の「データアクセス管理」の延長線上にあるものだ。全社員が同じナレッジベースにアクセスできる設計は利便性が高いものの、権限逸脱の温床にもなりやすい
- 入力統制:入力可能なデータの範囲を定める。たとえば、機密区分に応じて利用環境を分ける、匿名化や要約化を求める、特定データは原則禁止とするなど、データ分類に応じた統制が求められる
- 出力統制:AIによる出力結果の使い方に条件を設ける。たとえば、社内利用は可能だが、対外利用はレビュー必須、高リスク業務は承認必須といった形で用途ごとに条件を明確にしていく。AI出力の無確認利用を防ぐ上で、この統制は特に重要である
- 職務分離:「利用者」「レビュー者」「承認者」を必要に応じて分ける。たとえば、高リスク用途では、利用者本人だけで完結させず、別の責任者が確認する仕組みを入れる。これは、従来の内部統制の考え方と同じである
- 利用環境統制:未承認ツールや個人アカウントの業務利用を防ぎ、ログ取得できる環境で利用させる。閉域環境、承認済みサービス、接続先制御など、システム面のコントロールも欠かせない
ここで大切なことは、低リスク用途では最小限の統制にとどまるため、AIの活用を促進しやすい。一方、高リスク用途ではレビューや承認、証跡を残すという考え方である。すべてを厳格に管理することが高度なリスク管理ではない。リスクに応じて、必要なところを統制することこそが、実務で機能する管理である。
「ヒューマン・イン・ザ・ループ」の設計
生成AIの活用では、「最後は人が確認する」という表現がよく使われる。しかし、これだけでは実装としては不十分である。重要な点は、「人がどの局面で、何を、どの水準まで確認するのか」を設計することだ。
たとえば、「ヒューマン・イン・ザ・ループ」を考える際には、次のように整理するとよい。
- 対外文書では事実誤認や表現、根拠を確認する
- リスクのある業務では業務担当者に加え、責任者が確認する
- 法務、人事、財務、品質領域などでは専門部門の確認を必須とする
- 低リスク用途では抜き取りレビューにとどめる
つまり、人が介在すること自体が目的ではなく、“業務上重要な誤り”を防ぐためのポイントに人を配置することが目的である。加えて、ログ取得とモニタリングも欠かせない。AIリスク管理を監査するためには、少なくとも次の情報を残す必要がある。
- 誰が利用したのか
- どのような目的で利用したのか
- どのデータや文書を参照したのか
- どのAI環境やモデルを使ったのか
- どのようなレビューや承認を経たのか
さらに、継続監視のためにはKRI(Key Risk Indicator)やKPIも必要になる。たとえば、高リスク用途の利用件数、レビューの実施件数(未実施数)、例外申請の件数、問い合わせ件数、対外利用の件数、インシデントの件数などは、管理状態を把握する指標として使いやすい。
データガバナンスの観点から見れば、ログやモニタリングも単なる監視ではない。説明責任を果たし、改善につなげるための観測手段である。ここがなければ、AIリスク管理は「やっているつもり」で終わりやすい。
この記事は参考になりましたか?
- 生成AI時代のデータガバナンス再設計連載記事一覧
-
- 「AIガバナンス」の落とし穴 なぜ生成AIリスクは利用ルールをつくっても防げないのか?
- 生成AIガイドラインに禁止事項だけ並べていないか、現場活用のための設計法とデータガバナンス...
- 「データを整えるだけ」の常識は通用しない BI時代から脱却する、AI時代のデータガバナンス
- この記事の著者
-
小林 靖典(コバヤシ ヤスノリ)
ショーリ・ストラテジー&コンサルティング株式会社 ディレクター国内大手コンサルティングファームにて、データマネジメント・コンサルティングチームの立ち上げを主導。現在はショーリ・ストラテジー&コンサルティングにてデータ領域の専門チームを率い、データドリブン推進、AI導入支援、データマネジメント/データガバナンス領域のサービスを提供。データ領域のコンサルタントとして十数年以上にわたり、製造業(自動車、電機、機械、化学、食品)を中心に、小売業、通信サービス、金融・保険業、製薬...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか?
この記事をシェア
