複数のAIガバナンスプログラムを運用しようと考えて始める組織は、ほとんどありません。そうなるのは、セキュリティ、プライバシー、法務、責任あるAI、エンジニアリングがそれぞれ自らの義務を通じてAIに関わり、どの部門も、問題のうち自らが担う部分については正しく捉えているからです。解決策は、各チームが自らの判断を保ったまま、1つの記録と1つの入口を共有することです。そのために組織を再編する必要はありません。

なぜチームごとに別々のAIレビューが生まれるのか？

各部門が、それぞれ異なる義務を通じてAIに関わるからです。

• セキュリティ部門は、新しいデータフロー、新しいベンダー、そして最近ますます増えている、ツールを呼び出す権限を持つエージェントに向き合うため、ベンダー評価と脅威モデリングの対象をそこまで広げます。

• プライバシー部門は、個人情報の新たな利用を把握し、それをプライバシー影響評価に加えます。

• 責任あるAIチームは、公平性、説明可能性、人による監視を重視し、組織独自の原則に照らしたリスク階層別の評価を構築します。

• エンジニアリング部門は、モデル、バージョン、評価、デプロイを、自部門のプラットフォーム内のレジストリで管理します。

• 法務・コンプライアンス部門は、新たな規制上の義務や契約条件を確認し、すでに実施しているレビューにAIに関する質問を追加します。

各チームはフォームやスプレッドシート、キューを作り、件数が増えてくると、それぞれがツールを探し始めます。どの要望ももっともです。しかし、まとめて見れば、どれも各AIシステムの記録をどこに置くべきかを問うているのです。

分断はどんなコストを生むのか？

兆候はすぐに見つかります。

状況は時間とともに悪化します。プロダクトチームはガバナンスに時間がかかることを知り、レビューを避けられるようにプロジェクトを説明し始めます。台帳同士の食い違いはさらに広がり、その突き合わせは、次に難しい質問を受けた人が担うことになります。

遅れの原因がレビューそのものにあることはまれです。時間の大半は、ステップの合間で、準備の整った申請に次のチームが気づくのを待つ間に過ぎていきます。4つか5つのチームが同じ情報を別々に収集していると、こうした待ち時間が積み重なり、数か月に及ぶこともあります。

繰り返しは、記録そのものにも悪影響を及ぼします。同じ質問をもう一度受けた事業責任者は、前回より短く、丁寧さに欠ける回答をしがちです。そのため、質問の重複は、各チームが最終的にレビューする内容の質を下げてしまいます。

各チームは記録から何を必要としているのか？

各チームのフォームから受ける印象ほど多くはありません。どのレビューでも、求められる内容の大半はシステムに関する同じ基本的な説明です。違いは、各チームがその情報をもとに下す判断にあります。

共通の中核情報（目的、責任者、データ、モデル、影響を受ける人、システムが自ら判断する範囲）は一度だけ収集し、各チームは改めて尋ねるのではなく、その情報を参照するべきです。

共有記録には何を含めるのか？

実用的な記録は3つの層で構成され、それぞれ異なるステップで記入されます。

1. システムの説明（申請受付の時点で一度だけ収集）。目的とユースケース、事業面と技術面の責任者、システムの利用者と影響を受ける人、社内開発・外部調達・既存製品内での有効化のいずれか、モデルと提供元、利用するデータ（個人データや機微データを含む）、システムが下す、または支援する判断、そして人の承認なしに実行できる範囲。

2. 分類（説明から導き出す）。リスク階層、適用される規制と社内ポリシー、その階層で必要なレビュー。

3. 判断とエビデンス（各チームが追加）。承認とその条件、アセスメント結果、未解決の指摘事項、モデルのバージョンに紐づく評価結果、次回のレビュー日。

チーム固有の詳細は、それを必要とするチームの手元に置いておけます。プライバシー部門の影響評価の全文、セキュリティ部門の脅威モデル、エンジニアリング部門の評価スイートは、結果とリンクが記録に戻される限り、それぞれのツールで管理してかまいません。

承認すべきはソフトウェアだけでなく、その用途です。既存のプロセスの多くは調達に紐づいているため、ソフトウェアを一度承認すると、その後、何に使われているかを把握することはありません。同じ文章作成アシスタントでも、メールの文面を整えるだけなら日常的な用途ですが、誰かが機密の契約書を貼り付ければ、現実のリスクになります。EU AI Actでは、リスクはシステムが何に使われるかによって決まります。そのため、承認済みのツールを新たな用途で使う場合も、改めて入口を通すべきです。

記録は1つ、判断は別々に

よくある間違いは、1つのチームのツールを選び、他の全員にそれを使ってもらうことで重複を解消しようとすることです。これが定着することはほとんどありません。各ツールのデータモデルは、本来のチームのニーズを反映しているからです。プライバシープラットフォームは処理活動を中心に、セキュリティプラットフォームは資産とベンダーを中心に、MLプラットフォームはモデルのバージョンを中心に作られています。どれも、すべてのチームがレビューしている対象であるAIのユースケースを中心には作られていません。

うまくいくパターンは、4つの要素で構成されます。

1. 入口を1つにする。社内開発、外部調達、既存SaaS製品内での有効化のいずれであっても、新しいAI申請はすべて単一の申請受付から入ります。

2. AIシステムごとに1つの記録を持つ。申請受付で共通の中核情報を収集し、システムをリスクに応じて階層に振り分けます。システムが承認されると、その記録がそのままAIインベントリに登録されます。

3. レビューは並行して、判断は別々に。記録は、階層に応じて必要なチームへ回されます。各チームは独自のレビューを行い、独自の承認者を維持し、自らの判断に責任を持ちます。

4. 指摘事項を記録に戻す。セキュリティ上の条件、プライバシーに関する指摘事項、評価結果は同じ記録に紐づけられるため、どのチームも最新の状況を確認できます。チームが独自のチケット管理ツールでレビューを行う場合は、連携を双方向にする必要があります。申請によってチケットが作成され、判断、条件、コメントが記録に戻されます。

既存のシステムはそのまま使い続けます。チケットは引き続きJiraやServiceNowに届き、全社的なリスクも引き続きGRCスイートに集約されます。階層化の方法と既存のGRCプロセスへの引き継ぎについては階層型AI申請受付のガイドで、どの記録をどこで管理すべきかについてはAIガバナンスツールとGRCモジュールの比較で、それぞれ詳しく解説しています。

振り分けは実際にどう機能するのか？

線引きの仕方は組織によって少しずつ異なります。私たちが見てきた中で定着しているワークフローでは、どのチームが何をレビューするかをリスク階層で決めています。そのため、低リスクの申請は素早く進み、高リスクの申請には必要なレビューがすべて行われます。階層は、申請受付時のいくつかのスクリーニング質問で決まります。

• システムは個人データや機微データを使用しますか？

• 採用、与信、価格設定、サービスへのアクセスなど、人に関する判断を行う、または判断を支援しますか？

• 人の承認なしに、他のシステム上で操作を実行できますか？

• 出力は顧客に直接届きますか？

• 社内で開発したものですか、外部から調達したものですか、それともすでに利用している製品内で有効化したものですか？

• 影響を受ける人々はどこに住んでいますか？

最初の3つのいずれかに「はい」と答えた場合は通常、少なくとも中リスクの階層となり、個人データに人に関する判断や自律的な行動が組み合わさる場合は、通常は高リスクとなります。シンプルな3階層の例は次のとおりです。

よくある申請を例に考えます。人事チームが、既存の採用ソフトウェアに搭載された、応募者を順位付けするAI機能を有効化したいとします。分断されたモデルでは、セキュリティ部門がベンダーのアップデートを1日で承認する一方で、プライバシー部門と責任あるAIチームはそのことを知らないままかもしれません。一本化されたモデルでは、申請は入口を通ります。記録には、この機能が個人情報を使って採用判断を支援することが記載され、高リスクの階層に振り分けられます。プライバシー部門は影響評価を実施し、責任あるAIチームは公平性をテストして監視の要件を定め、セキュリティ部門はベンダーのデータの取り扱いをレビューします。いずれも同じ説明に基づいて行われます。各チームの条件は記録に紐づけられ、それらが満たされた時点で機能が本番稼働します。後になって、採用判断を支援しているシステムはどれかと尋ねられても、インベントリにフィルターをかけるだけで答えが出ます。

規制対応において、なぜ記録を1つにすることが重要なのか？

複数の法域の規制当局は現在、自動化されたシステムがどこで人に関する判断を行い、または支援しているかを組織が把握し、それを説明できることを求めています。EU AI Actは高リスクAIシステムの導入者に義務を課しており、一般データ保護規則（GDPR）は自動化された処理のみに基づく決定を制限しています。コロラド州やカリフォルニア州などの米国の州に加え、ケベック州やオーストラリアでも、自動化された意思決定の利用について開示を求め、場合によっては評価も求める規則の導入が進んでいます。法律ごとに表現は異なりますが、どのシステムが関わっているか、どのデータを使っているか、どの判断に影響するか、誰が確認したかを問う点は共通しています。

分断されたモデルでは、こうした答えが複数のチームに散らばっています。どのシステムが存在するかはエンジニアリング部門が、どのシステムが個人情報を使っているかはプライバシー部門が、どのシステムが重要な判断を支援しているかは責任あるAIチームが、どのサードパーティツールが承認されたかはセキュリティ部門が把握しています。記録が1つであれば、プライバシー部門や法務部門は、別々のリストから全体像を組み立てるのではなく、求めに応じてすぐに答えられます。

一本化の際、チームはどこでつまずくのか？

一本化の取り組みでは、たいてい同じ問題がいくつか生じます。

• 切り替え期間中に入口が2つある。移行中も旧フォームが使える状態のままだと、一部の申請者はそれを使い、その後、自分の申請が失われたと思い込みます。旧フォームは、新しいフォームの運用を開始する日に停止します。

• インベントリへの登録が早すぎる。申請を提出するとすぐにインベントリに登録される仕組みだと、申請を先に進めるために最低限の情報しか入力されず、承認されないかもしれないシステムの、中身の薄い記録でインベントリが埋まっていきます。説明は申請受付の時点で収集し、システムが承認されてからインベントリに追加します。

• リスク判定の結果が申請者に見えている。どの回答で階層が上がるかが見えると、申請者はそれを避ける答え方を覚えてしまうことがあります。また、解釈できないリスクフラグを目にする申請者もいます。通常は、結果をレビュアーと承認者にだけ表示するほうがうまくいきます。

• 法務部門の確認を経ていないリスクスコア。組織が最終的に承認したツールに高いリスクスコアが記録されていると、将来の訴訟で不利に受け取られるおそれがあります。まずは「懸念なし」から「ブロック」までの、レビュアーによるシンプルな判定結果から始め、リスク分類体系が固まり、全社のリスクマトリクスと整合してからスコアリングを加えるほうが安全な場合もあります。何を評価すべきかだけでなく、リスクをどう記録すべきかも法務部門に確認してください。

• 誰も設計していないコントロール。エージェントの数は、エージェントごとに今もITチケットが必要であるなど、誰かが意図して決めたわけではない理由で少なく抑えられていることがよくあります。この制約は、利用者が自分でエージェントを作れるようになった時点でなくなります。キューが暗黙のうちにコントロールの役割を果たしているなら、そのキューが解消される前に、エージェントも入口を通るようにします。

• レビューメンバー全員を承認者として扱っている。レビューメンバーは増えていく傾向があり、やがてガバナンスチームは、チャットやメールでレビュアーを追いかけることに日々を費やすようになります。メンバーの側も、どの申請で本当に自分が必要とされているのかがわからなくなります。承認しなければならない人と、知っておくだけでよい人を分け、それぞれ異なる方法で通知します。

始め方

1. ツールを選ぶ前に重複を洗い出す。各チームの現在のフォームが収集している項目を一覧にし、チーム固有の判断ではなくシステムそのものを説明している項目に印を付けます。たいていは重複が多く見つかります。

2. 共有記録の内容と管理者について合意する。AIシステムの記録にどの項目を含め、誰が維持するかを決めます。多くの場合、責任あるAIチームまたはAI責任者の部門が、プライバシー部門と共同で管理を担います。

3. 階層を文書化する。スクリーニング質問、各階層で必要なレビュー、それぞれの目標処理期間を公開し、申請者が始める前に見通しを持てるようにします。

4. 初版は短くする。シンプルなフォームほど使われます。必要な項目の大半を初版でカバーし、残りは実際に使われるようになってから追加します。地域ごとに独自の質問票を運用している場合は、まずそれらを統合し、法域ごとの分岐は後から追加します。

5. 入口を1つにし、並行して振り分ける。各チームの承認者はそのままにし、変えるのは申請が入ってくる場所と記録を置く場所だけです。

6. すでに使われているシステムを取り込む。人に関する重要な判断を行う、または支援するシステムや、機微データを使うシステムから始めます。最もリスクが高く、最も多くの質問が寄せられるからです。

7. ツールの選定は最後に。適切なプラットフォームとは、データモデルがAIシステムの記録を保持でき、各チームの既存のワークフローへスムーズに引き継げるものです。

よくある質問

AIガバナンスを一本化すると、1つのチームが他のチームのレビューを引き継ぐことになるのですか？

いいえ。一本化の対象は記録と入口です。各チームは独自のレビューと承認者を維持し、引き続き自らの判断を下します。変わるのは、同じ情報を別々に集めなくなることだけです。

各チームは、すでに使っているツールを手放さなければなりませんか？

いいえ。プライバシー部門はプライバシープラットフォームを、セキュリティ部門はベンダーリスク管理ツールを、エンジニアリング部門はモデルレジストリを、そのまま使い続けられます。AIシステムの記録はそれらにリンクでき、各レビューの結果を保持するため、どのツールがインベントリになるかを競う必要はなくなります。

共有のAIシステム記録は、誰が管理すべきですか？

通常は、責任あるAIチームまたはAI責任者の部門が、プライバシー部門と共同で管理します。両者を合わせれば、ユースケースとデータの両方をカバーできるからです。最も重要なのは、記録が1つであり、ポリシーの責任者とプロセス運用の責任者がそれぞれ指名されていることです。AI責任者がAI活用推進も担っている場合は、レビューには別の責任者を置きます。運営委員会が管理責任の所在を議論している間にプログラムが停滞することはよくありますが、多くの場合、この2人の責任者を指名することで前に進み始めます。

プロダクトチームに入口を使ってもらうにはどうすればよいですか？

判断に至る最も速いルートにすることです。3つではなく1つのフォーム、明確な階層、並行して進むレビューがあれば、チームにとって入口を使う理由になります。調達やプラットフォームへのアクセスを承認済みの記録と結びつければ、残りの大部分も解消されます。

Enzaiの位置づけ

Enzaiは、その共有記録となるよう設計されています。1つの申請受付の入口から、AIシステムごとに単一の記録を作成し、リスクに応じて階層に振り分け、JiraやServiceNowへの引き継ぎを含めて各チームのレビューへ回します。AIインベントリは、これらの記録から構築されます。そのため、どのチームも自らの判断を保ちながら、同じ事実に基づいて作業できます。チームをまたいでAIガバナンスの一本化を進めている場合は、Enzaiチームにご相談ください。