必ずしも必要とは限りません。エンタープライズ向けGRCスイートは、ポリシーの遵守確認、コントロールテスト、課題管理、監査ワークフローをすでに扱っており、これらの機能はそのままAIシステムにも適用できます。一方で、GRCスイートが標準では保持していないのが、AI固有の記録です。つまり、AI検出、モデルとエージェントのメタデータ、バージョン管理されたエビデンス、そして重なり合う複数のAI規制をまたぐマッピングです。答えは、こうした記録をどこまで作成する必要があるかによって決まります。

既存のGRCスイートが、AIについてすでに十分に対応できることは？

GRCの中核となる手法と原則は、変更を加えることなくAIに適用できます。ServiceNowはIntegrated Risk Managementのコンプライアンスワークフローを「ポリシーを管理し、コントロールテストを自動化し、課題を調査する」ものと説明し、「監査エビデンスを一元化する」としています。Archerは、ポリシーガバナンス、監査管理、規制コンプライアンス、全社的リスク管理の製品を、信頼できる唯一の情報源（System of Record）となる1つのシステム上で提供しています。AIガバナンスプログラムには、初日からこれらすべてが必要であり、どれも作り直すべきではありません。このうち次の6つの機能は、AIガバナンスにもそのまま引き継げます。

• ポリシーの遵守確認。生成AIの利用規程も、他のポリシーと変わりません。公開し、遵守確認を集め、例外を追跡します。

• 課題と指摘事項の管理。モデルレビューで見つかったバイアスに関する指摘は、担当者、期日、是正計画を伴う課題です。

• 監査ワークフロー。内部監査部門は、監査計画、実地調査、報告をすでにスイート上で運用しています。

• コントロールライブラリ。本番システムへのアクセスを制限するコントロールは、データベースと同じく推論エンドポイントにも適用されます。

• 全社的なリスク分類体系。AIリスクは、別の体系を並行して設けるのではなく、取締役会がすでに目にしているオペレーショナルリスクの分類体系に集約すべきです。

• 既存の承認プロセス。調達、セキュリティレビュー、プライバシー評価、変更諮問委員会は確立された経路であり、AIの申請はこれらを迂回せず、きちんと通過させるべきです。

既存ベンダーも動き出しています。ServiceNow AI Control Towerは「自社製かサードパーティ製かを問わず、あらゆるAIエージェント、モデル、MCPサーバーを自動的にインベントリ化する」とうたい、EU AI Act、NIST AI RMF、California AI Transparency Act向けのコンテンツを提供しています。Collibra AI Governanceは「あらゆるAI資産のための統合レジストリ」、EU AI ActとNIST AI RMFのテンプレート、そして「ソースデータセットからモデルの学習、推論、デプロイ、利用まで」をたどるリネージを提供しています。OneTrust AI Governanceは「AIシステム、モデル、エージェント、データセット、ベンダー、プロジェクト、ユースケースを検出してインベントリ化する」とし、EU AI Act、NIST AI RMF、ISO 42001のテンプレートを備えています。ArcherもAI Governanceの製品を掲げています。購入者にとっての問いは、もはやスイートにAIモジュールがあるかどうかではありません。そのモジュールが自社のAI資産に対して十分な深さを備えているか、そしてAI固有の記録をどこに置くべきか、という点です。

GRCモジュールがAIシステムに対して構造的に対応できないことは？

GRCのデータモデルは、ポリシー、コントロール、リスク、課題、そしてServiceNowの場合はCMDBの構成アイテムを中心に設計されています。しかし、優れたAIガバナンスプログラムには、こうしたモデルが想定していないオブジェクトが必要です。これらのツールでAIガバナンスを運用しようとする企業には、6つのギャップが共通して見られます。以下で一つずつ詳しく説明します。

1つ目は検出です。GRCの記録は、誰かが作成したからこそ存在します。一方、AIは、SaaSベンダーが有効化した機能、経費で契約されたサブスクリプション、ベンダー製品に組み込まれたモデル、社内プラットフォーム上で構築されたエージェントを通じて入り込み、そのいずれも登録を生みません。EnzaiのAIインベントリは、AI検出、プラットフォームからのインポート、ユースケース申請を組み合わせています。各手法で何が漏れるかについては、AIインベントリ構築ガイドで解説しています。

2つ目は、モデルとエージェントのメタデータです。ベースモデルとそのバージョン、提供元、プロンプト設定、ファインチューニング用データ、自律性のレベル、ツール権限はいずれもAIシステムの属性ですが、コントロールの記録にはそれらを入れるフィールドがありません。

3つ目は、重なり合うAI規制をまたぐフレームワークのマッピングです。1つの与信判断システムが、EU AI Actの附属書III、ISO 42001の適用範囲、NIST AI RMF、さらに顧客が居住する州の法律の対象に同時になることがあります。しかも、これらの規制は変化します。コロラド州はAI法を廃止したうえでSB 26-189として再制定し、同法は2026年5月14日に署名され、消費者の権利は2027年1月1日から適用されます。AIに関するデジタル・オムニバスは2026年7月27日に発効し、附属書IIIの義務の適用を2027年12月2日に延期しました。手作業で維持するコントロールライブラリは変更のたびに後れを取り、あるフレームワーク向けのエビデンスが次のフレームワークで再利用されることはほとんどありません。

4つ目は、モデルの挙動の継続的なモニタリングです。コントロールテストは定期的に実施するものです。EU AI Act第9条第2項は、高リスクAIシステムのリスクマネジメントシステムを「ライフサイクル全体を通じて計画・実行される、継続的かつ反復的なプロセス」と定めています。ドリフト、出力品質、ガードレールのシグナルはテレメトリであり、四半期ごとのテスト結果ではありません。

5つ目は、特定のモデルバージョンにひも付いたエビデンスです。監査人から、システムが何に照らして、誰によって、どのバージョンで検証されたのかを問われたら、本番環境で稼働しているバージョンを明示して回答する必要があります。また、ベンダーがベースモデルを変更した際には、エビデンスの収集が改めて発動されなければなりません。コントロールテストでは、この問いに答えられません。

6つ目は、エージェント単位の自律性と権限管理です。エージェントがどのツールを呼び出せるか、確認なしで何を実行できるか、再帰の上限をどこに置くかは、エージェントの担当範囲が広がるにつれて変わる判断です。Enzaiの自律型AI（エージェンティックAI）ガバナンスモジュールは、各エージェントを「監督なしで何ができるか：読み取りのみ、提案のみ、または実行」によって階層化し、許可されていないツール呼び出しを境界でブロックします。

GRCモジュールと専用のAIガバナンスはどう違うのか？

深さはベンダーやリリースによって異なるため、各行は結論ではなく、評価のための問いとしてご活用ください。

GRCスイートの拡張が正しい選択となるのはどんなときか？

次の3つの条件が自社に当てはまる場合は、既存のGRCツールを使うことが正しい選択かもしれません。

AI資産が小規模で固定的：システムは数十程度で、書き込み権限を持つエージェントはなく、附属書IIIのカテゴリーや業種別の高リスク規制に該当するものもありません。また、1年以内にこの状況を変える予定もありません。

規制上のエクスポージャーが低い：EUの高リスク規制の対象となる事業がなく、ISO 42001認証も予定しておらず、AIに言及した監督当局からの要請もありません。

責任体制がすでに確立している：AIリスクを担う第2線の責任者が指名され、インテークの経路が機能しており、事業部門の責任者が購入したものを登録しています。

3つすべてが当てはまる場合は、既存のリスク登録簿にAIの属性を追加し、ベンダーのAIモジュールを有効化し、見直しの期日を設定してください。2つ目のプラットフォームには現実的なコストがかかります。統合、ベンダーリスク審査、ログインがそれぞれ1つずつ増えるのです。ガバナンス成熟度モデルでアドホックまたは反復可能な段階にあるプログラムにとっては、ツールの導入よりも、ポリシーを策定してシステムを洗い出すことのほうが効果は大きいでしょう。

例として、ベンダー製品に組み込まれたAI機能が8つあり、不正検知モデル1つがすでにモデルリスク管理の対象となっていて、エージェントは導入していない地方の保険会社を考えてみます。この場合、当面はスイートの拡張が正解です。

専用のAIガバナンスレイヤーが必要になるのはどんなときか？

通常は、次のシグナルのいずれか1つがあれば十分です。

実行権限を持つエージェントが本番環境で稼働している場合。GRCの課題レコードでは、「このエージェントはCRMを読み取り、返金を提案できるが、返金を実行してはならない」という内容を表現できません。しかも、こうした一覧はどのポリシーよりも頻繁に変わります。

同じシステムに複数のAI規制が適用され、しかもそれらが変化し続けている場合。クロスフレームワークでの再利用を伴う、システム単位・フレームワーク単位のエビデンスこそが、同じ情報の収集を繰り返さずに済む唯一の方法です。

銀行の場合。2026年4月17日に発出され、SR 11-7に代わったSR 26-2は、生成AIモデルとエージェンティックAIモデルは「本ガイダンスの対象外である」と明記しています（米連邦準備制度理事会）。つまり、銀行のモデルリスク管理フレームワークは、その銀行が最も急速に導入しているシステムを正式にはカバーしていません。後で整合させることを前提に構築する並行フレームワークには、MRMツールとGRCの課題ログのどちらでもない置き場所が必要です。

カスタマイズのバックログは、決定的な兆候です。GRCチームがモデル、エージェント、バージョンのためにカスタムテーブルを構築しているなら、そのスイートは変更要求を重ねるごとに、AIガバナンスプラットフォームへと変わりつつあります。

ISO/IEC 42001認証が対象となる場合。2023年12月に発行されたISO/IEC 42001:2023は、「人工知能マネジメントシステムを確立し、実施し、維持し、継続的に改善するための要求事項を規定する」規格です。監査人は、適用範囲内のAIシステムごとに、それが一定期間にわたって運用されてきたことを示すエビデンスを求めます。

二者択一なのか、それともAIガバナンスレイヤーがGRCのSystem of Recordにデータを供給するのか？

二者択一ではありません。そう考えると、どちらの側でも商談を失うことになります。実際に機能するのは、記録を分担する形です。AIガバナンスレイヤーは、GRCが想定していないオブジェクト、すなわちインベントリ、モデルとエージェントのメタデータ、フレームワークのマッピング、システム単位のエビデンス、リスク層別インテークを保持します。GRCスイートは引き続き、全社的リスク、ポリシー、課題、監査のSystem of Recordとして機能します。

Enzaiのプラットフォームは、JiraやServiceNowへのワークフロー連携を備え、インテークのタスクや承認を、チームがすでに使っているシステムへ送ります。リスク層別インテークのガイドでは、インテークの記録を、ベンダーリスク、調達、セキュリティ、プライバシーの共通の入口と位置づけています。これにより各部門は、同じことを何度も尋ねるのではなく、1つの記録から必要な情報を取得できます。

EU AI Actも同じ線を引いています。第17条第4項により、EUの金融サービス法に基づく内部ガバナンス要件の対象となる金融機関である提供者は、その既存のガバナンスによって品質管理システムの要件を満たすものとみなされます。ただし、第9条のリスクマネジメントシステム、第72条の市販後モニタリング、第73条の重大インシデントの報告という3つの要素は除かれます。つまり同規則は、企業のガバナンスフレームワークはそのまま維持され、そこにAI固有の要素が追加されることを前提としています。

既存の仕組みがスイートではなくスプレッドシートの場合は？

ISO 42001を目指すチームによく見られるスプレッドシートのケースは、事情が異なります。最初の20システム程度までなら、スプレッドシートでも十分なインベントリになります。しかし、複数の担当者が編集するとき、エビデンスをバージョンにひも付ける必要があるとき、そして誰がいつリスク評価を変更したのかを監査人に問われたときには、立ち行かなくなります。GRCスイートを持たない組織が、AIを統制するためだけにGRCスイートを購入すべきではありません。AIガバナンスレイヤーのほうが小さな投資で済み、監査人が求める記録を保持でき、すでに使っているチケット管理ツールとも連携できます。スイートを持ちながら依然としてスプレッドシートでAIを管理している組織は、記録は分かれているものの連携されていない状態にあり、その連携を構築することこそが取り組むべきプロジェクトです。

運用面での意味

どちらの判断を下す場合でも、進め方は同じです。

1. 判断する前にAI資産を把握します。検出を実行し、各システムの自律性レベル、規制上の適用範囲、責任者をインベントリに記録します。判断を左右するのは、その数と構成です。

2. 分担を文書化します。どのオブジェクトをGRCスイートに置き（ポリシー、全社的リスク、課題、監査）、どれをAIレイヤーに置くか（システム、モデル、エージェント、バージョン、システム単位のエビデンス）を決めて公開し、どのチームも二重に管理しないようにします。

3. すべてのシステムを、適用されるすべての規制にマッピングし、変動する期日を記録します。附属書IIIは2027年12月2日、コロラド州の消費者の権利は2027年1月1日、銀行における生成AIおよびエージェンティックAIのシステムはSR 26-2です。クロスフレームワークでのエビデンス再利用を備えたフレームワークライブラリがあれば、スプレッドシート頼みの作業から脱却できます。

4. 引き継ぎを定義します。承認は既存ワークフローのタスクに、指摘事項は課題に、残余リスクは分類体系への登録になります。規模を広げる前に、1つのシステムで引き継ぎをテストしてください。何をどこに置くかは、ServiceNowやCollibraとの比較記事で整理しています。

5. 判断を見直すトリガーを設定します。たとえば、書き込み権限を持つ最初のエージェント、附属書IIIに該当する最初のシステム、ISO 42001の適用範囲を決める最初の会議です。

Enzaiは、分担された記録のうちAI固有の部分と、すでに運用しているGRCツールやITSMツールへの引き継ぎのために設計されています。自動化されたAIガバナンスを既存のスイートとどう連携できるか、Enzaiチームにご相談ください。