AIガバナンスフレームワーク：機能するものの構築方法

AIはほとんどの組織に複数の経路で同時に到達します。ここにはライセンスされたアシスタント、既存のSaaSツール内で有効化されたAI機能、そして誰もチケットを発行していないいくつかのツールが含まれます。

すべてをカバーするはずのガバナンスフレームワークは、通常、遅れて導入されるか、まったく導入されません。The Netwrix 2026 Data and Identity Security Reportによると、41％の組織がすでに人間に代わってエージェントAIを本番運用しており、11％は強制的で継続的かつ積極的なレビューを通じてAIガバナンスを運用化しています。

信頼度はそのギャップを示しており、決して良いものではありません。売上高1億ドルから10億ドルの組織のうち、独立したAIガバナンスとコントロールの監査に合格すると非常に自信を持っているのはわずか18％です。Grant Thorntonによると。

一方で、中堅市場のITリーダーの42％がThe Netrio’s Mid-Market AI Readiness Report において、過去1年間にAI関連のセキュリティインシデントまたは露出が確認されたと報告しました。その距離を埋めるフレームワークは、すべての書かれたルールを誰かがテストできるコントロールと誰かが参照できる記録に結びつけます。

AIガバナンスフレームワークとは何ですか？

AIガバナンスフレームワークとは、組織がAIシステムを設計、展開、利用する方法を管理するための、ポリシー、役割、プロセス、およびコントロールの構造化されたセットです。これには、ライセンスされたアシスタント、ブラウザ経由でスタッフがアクセスする公開ツール、SaaSアプリケーション内に搭載されたAI機能、および内部モデルが含まれます。

ISO/IEC 42001は、運用構造を重視するAI管理システムを指します。AIリスク管理フレームワークは、リスクの特定と対処に重点を置いています。

これら3つのドキュメントはしばしば混同され、その区別が責任者を決定します。frameworkはライフサイクルの各段階における責任とプロセスを定義します。policyはルールを設定し、assessmentは特定の日付にどちらがどれだけ機能しているかをテストします。

AIガバナンスフレームワークが重要な理由

このフレームワークは、散在する意思決定を、取締役会、規制当局、または監査人が検査できるものに変えることで、その地位を確立します。

• 証拠に基づく承認： セキュリティは、各ツールがどこにアクセスし、どのIDで動作しているかの明示的なリストを用いてAI展開を承認でき、作成者の保証に代わります。
• 防御可能な監査証跡: リスク評価、アクセスレポート、構成履歴、委員会議事録がすべて一か所にまとめられています。
• 制限された爆発範囲： スコーピングとアクセス制限により、侵害または誤設定されたAIセッションがアクセスできるデータ量が決まります。
• 遅くするのではなく、より速い承認： 常設の受付経路とリスク階層により、低リスクのユースケースは迅速に通過し、残りは実際のレビューへ回されます。
• 2つではなく1つのプログラム： AIリスクはすでに稼働中のレジスター、コントロールライブラリ、レビューゲートに反映されているため、二重管理はありません。

これらのすべては同じ根本的なことに依存しています：AIが現在ライブ環境で何を達成できるかを知ることです。

既存のガバナンスプログラムがAIに遅れをとる理由

3つの力がほぼ同時にセキュリティチームに襲いかかります。それぞれが、ポリシーの主張と環境が証明できることの間の距離を広げます。

AIは承認されるよりも早く到着します

利用はポリシーを先行しており、数字は大きく異なります。ISACAの2026 AI Pulse Pollによると、デジタルトラストの専門家の90％が従業員が組織内でAIを使用していると信じている一方で、その組織のうち38％だけが正式で包括的なAIポリシーを持っています。

シーケンシングが不足の大部分を説明しています。RSM AI調査報告書によると、中堅市場の組織の約3分の1がガバナンスコントロールが整う前にパイロットや本番環境に移行し、16％は問題が発生してからガバナンスに到達しています。蓄積されるのは一時的な承認や文書化されていない例外の山です。誰かが証拠を求めるまでは問題ありません。

コンプライアンスの期限が過ぎ始めています

標準が最初に登場し、構造の期待を設定しました。ISOは2023年12月18日に国際的なAI管理システム標準としてISO/IEC 42001を発行し、ほとんどのチームはこれをNIST AI RMFと任意の補完として組み合わせています。

その後、EUのスケジュールが変更され、多くのチームが計画していた方向とは異なりました。Digital Omnibus on AIは、2026年7月8日に規則（EU）2026/1744として採択され、単独の付属書IIIシステムに対する多くの高リスク義務を2027年12月2日まで、製品組み込みの付属書Iシステムに対しては2028年8月2日まで延期しました。

2つの日付は変更されず、両方とも過ぎました。2026年8月2日から、Article 50の透明性義務と委員会の汎用AIモデルに対する執行権限がAI Act enforcement timelineに基づいて適用されています。その日付以前に市場に出ていた生成システムは、ほとんどのチームにとって次の実際の締め切りである2026年12月2日までにArticle 50(2)の表示義務を満たす必要があります。

AIはすでにある権限の負債を増幅させます

AIツールは既にあるアクセス権を利用します。 Microsoft自身の過剰共有に関するガイダンスは はっきりと述べています：Copilot は既存のMicrosoft 365の権限と保護を継承するため、権限過多のサイト、継承されたアクセス、感度ラベルの欠如は導入前に修正する必要があります。

誰も気づかなかった数年分のアドホックな共有が、プロンプトがアクセスできる瞬間に検索可能になります。まずその層を修正することが成果につながり、統合されたIdentityとデータガバナンスを持つ組織はAIの完全な準備が整っていると報告する可能性がほぼ5倍高くなります。

機能するAIガバナンスフレームワークの6つの柱

ほとんどの公開されたフレームワークは、データアクセスの可視性をプライバシーやデータガバナンスなどの広範な領域に埋もれさせています。認証と監査がそれに依存しているため、独自の柱を持ち、 ISACAのAI監査手順は アクセスログ、変更管理プロセス、および役割ベースのポリシーを具体的に求めています。

1. 範囲とインベントリ

スコープは、他のすべてのコントロールが適用される対象を定義します。AIシステムやユースケース、各々に関連するビジネス目標、リスク許容度、規制上の義務を示します。

ISO/IEC 42001 第4.3条は、範囲が文書化された情報として利用可能であることを要求しています。サポートする在庫がない範囲声明は最初のサンプルで失敗します。

2. 所有権と承認の経路

責任は指名された個人にあります。エグゼクティブスポンサー、ガバナンスリード、セキュリティ、データ保護、および事業部門の所有者は、それぞれ特定の意思決定権を持っています。

ISO/IEC 42001のコントロールA.3.2は直接的に「AIの役割と責任は組織のニーズに応じて定義され割り当てられるべきである」と規定しています。実際のテストは、新しいユースケースを誰が承認し、誰が停止できるかを誰かが言えるかどうかです。

3. コントロールにマッピングされたポリシー

ポリシーは許容される使用、禁止されているデータタイプ、人間の介入要件、透明性の期待、およびインシデント対応をカバーします。ポリシーは各行がそれを強制するコントロールを明記しているときに機能します。

これらのコントロールはアクセス制限であり、data classification、すでに導入されているDLPソリューション、条件付きアクセス、およびログ記録です。コントロールのないルールは文であり、安全策ではありません。

4. データとアイデンティティの可視性

この柱は、あらゆるAIのやり取りに関する2つの質問に答えます。ツールがアクセスできるデータは何か、そしてどの人間、機械、または非人間のアイデンティティがそれを呼び出したのか？

これは、多くのプログラムが証明できない柱でもあります。報告書はその理由を定量化し、74％の組織が機密データとそれにアクセスできるIDの単一で統一されたビューを持っていないことを明らかにしました。付与されたアクセスと実際のアクセスは異なるリストであり、履歴のある環境ではすぐに乖離します。

5. ライフサイクル管理

ライフサイクルはデータからモデル開発、展開、レビュー、廃止まで進み、各移行時に意思決定のゲートがあります。廃止はほとんど誰も到達しないゲートであり、監査人が質問する部分です。

Identity ライフサイクル管理 はすでに人の入社、異動、退職を管理しており、AI エージェントも同じ分野に属します。NIST AI RMF のサブカテゴリー MANAGE 2.4 は、意図した使用と一致しない AI システムを代替、切断、または無効化するための仕組みと割り当てられた責任を求めています。

6. 測定と改善

測定はガバナンス委員会に決定材料を提供します。重要な指標は、AIインシデント数、ポリシー例外、リスク評価のカバレッジ、およびコントロールの有効性です。

ISO/IEC 42001の条項9および10は、監視、内部監査、経営レビュー、および是正措置をカバーしています。決定を変えないものは追跡する価値がありません。

フレームワークを5つのステップで構築する方法

この柱は完成したフレームワークが何を保持しているかを説明します。構築は、誰かが書きたいポリシーではなく、すでに環境にあるAIから始まる異なる順序で進みます。この5つのステップを順番に実行してください。

1. すでに稼働しているAIを棚卸しする

3つのソースから取得してください。単一のシステムがすべてを知っているわけではないからです。ライセンスされたアプリとservice principalsはあなたのidentity providerから、組み込みのAI機能はベンダーのリリースノートと管理センターから、許可されていないツールはegressログから来ます。

承認リストは大幅に過小評価されると予想してください。 2026年のPagerDuty調査によると、オフィスの専門家の66％がポリシーで許可されていないと考えながらも職場でAIを使用しており、組織のわずか20％だけがシャドウAIを完全に監視または管理しています。

次に、見つけたものをリスク階層に分類します。内部の生産性、顧客向けサービス、規制対象データの使用はそれぞれ異なる監査レベルが必要であり、階層がシステムが受ける残りの作業量を決定します。

2. 所有者を割り当て、承認パスを構築する

各AIシステムに、IT、セキュリティ、データ保護、またはそれを使用する事業部門の指名された所有者を割り当ててください。チーム、委員会、配布リストは対象外です。

次に、リスク評価からコントロール設計、承認、レビュー日までのリクエスト経路をマッピングします。例外を許可する人と、リスクが変化した際にシステムを停止できる人を書き留めてください。

定期的なaccess certificationで、管理者、サービスアカウント、アプリケーション、AIエージェントが現在の業務に必要な権限のみを保持していることを確認してください。Active Directory service accountsは通常、不要な権限が隠れている場所です。

3. テスト可能な各ルールをコントロールにマッピングします

ポリシーを行ごとに確認し、その横に適用するコントロールを書いてください。名前を挙げられない場合、そのルールはまだ適用できず、ギャップリストに入ります。

曖昧さなく明確に禁止線を示してください。法務および人事データに関する明確な例外を設け、分類されていない個人識別情報（PII）への生成型AIのアクセスを禁止します。

特権アクセスはその条件で管理する必要があります。AIサービスを設定する管理者は昇格が必要なため、承認されたセッションごとに短期間のジャストインタイム（JIT）資格情報を発行し、zero standing privilegeをそれらのサービスを統合するアカウントに適用してください。

4. 既に実行しているプロセスにAIを組み込みましょう

既存のリスク登録簿、管理ライブラリ、問題追跡システムにAIリスクカテゴリを追加し、AIユースケースを既存の受付、変更管理、セキュリティレビューのゲートを通過させます。 ISACAのガイダンスはまさにこれを推奨しており、AIリスク管理は確立されたサイバー、リスク、プライバシープログラムを補完します。

サードパーティおよび組み込みAIには同様の対応を行い、プロバイダー、データフロー、統合方法、保持条件、所有者、終了計画を記録します。アクセスレビューにツールが必要な場合は、IGA toolsを既に対象となっているシステムと比較してください。

5. リズムを設定し、それが機能することを証明します

最初のレビューの期限が来る前にレビューの頻度を決め、これらの対策を既存の IT risk assessment サイクルに組み込みます。新しいものを購入する前に、すでに展開されているコンプライアンスツールがレポートできるか確認してください。

次に、監査人のようにフレームワークをテストします。AIシステムを1つ選び、その所有者、リスク階層、コントロールセット、アクセスレポート、最終レビュー日を取得し、1時間以内にどれだけ作成できるか確認してください。

NIST AI RMFおよびISO/IEC 42001にフレームワークを合わせる

このように構築されたフレームワークは、最終的にあなた自身の語彙で書かれます。監査人、顧客、規制当局はそのようには求めません。彼らはどの標準に準拠しているかを尋ね、マッピングにより何も再構築せずに答えることができます。

ISO/IEC 42001の条項5は所有権とAIポリシーをカバーし、条項6および8はリスクと影響評価をカバーし、条項9および10は測定と改善をカバーします。上記の6つの柱のうち4つが名称変更されました。

どちらを先にマッピングするかは単なる偶然ではなく、その理由は両者が同時に言及されるために見失われがちです。ISO/IEC 42001は監査可能で認証可能ですが、NIST AI RMFはそうではありません。この違いが、あなたが主張できることと証拠をどこに提出すべきかを決定します。

データ中心プログラムにおけるAI RMFの可能性と限界

AI RMF CoreはGovern、Map、Measure、Manage全体でリスク管理を整理し、そのサブカテゴリは要件ではなく成果の声明です。NISTは適合性評価スキーム、認定基準、認証機関の要件を公開していません。プログラムがAI RMFに準拠している、またはコントロールがそのサブカテゴリに対応していると言うことはできますが、「NIST AI RMF認定」とは言えません。AI RMF Core organizes risk management across Govern, Map, Measure, and Manage, and its subcategories are outcome statements, not requirements. NIST publishes no conformity assessment schemes, accreditation criteria, or certification body requirements. You can say your program aligns with the AI RMF or that controls map to its subcategories. You can't say "NIST AI RMF certified."

何かをマッピングする前に知っておくべき2つ目の制限があります。72のサブカテゴリーすべてにおいて、access control、identity、authentication、permissions、data provenanceはいずれも名前が挙げられていません。したがって、どのidentitiesがどのデータにアクセスできるかを知ることは、証拠パックが実際に有効にするものであり、テキスト上のフックではなく解釈によってAI RMFにマッピングされます。

3つのサブカテゴリファミリーが実際にその重みを担っています。サードパーティセットが最も強力で、GOVERN 6.1はサードパーティのAIリスクに関するポリシーをカバーし、MANAGE 3.1は「サードパーティリソースからのAIリスクと利益が定期的に監視されること」を要求し、MAP 4.2はサードパーティコンポーネントの内部リスク管理をカバーしています。MEASURE 2.7および2.10はセキュリティとプライバシー評価の証拠が集まる場所です。デプロビジョニングにはMANAGE 2.4とGOVERN 1.7を組み合わせてください。

監査前にNISTクロスウォークを翻訳する必要がある理由

NISTはAI RMFのサブカテゴリーからISO/IEC 42001へのcrosswalkを公開しており、実際の作業を省けます。また、チームを困惑させる特性もあります。202のコントロール参照はすべて付録Bを指しており、付録Aのコントロールは一切引用していません。

この区別は、マッピングが監査に耐えられるかどうかを決定します。付録Aは規範的で、そのコントロールは「shall」と記述されており、適用声明はこれに基づいて作成されます。付録Bは実装ガイダンスで、そのコントロールは「should」と記述されており、組織が適用声明にそのガイダンスを含めるか除外するかを正当化する必要はないと明確に述べています。MANAGE 2.4を「B.9.4 Intended use of the AI system」に送るクロスウォークの行は、監査可能なコントロールではなくアドバイスを指しています。

翻訳が機械的なのは、42001が2つの付録を並行して番号付けしているためで、B.9.4はA.9.4のガイダンスです。これを飛ばすのが一般的な誤りです。もう一つ知っておくべきことは、クロスウォークは発行済みの規格ではなく、最終草案であるISO/IEC FDIS 42001を対象としていることです。

ほとんどのプログラムが見落とす条項

リスク評価と影響評価は42001における別々の義務であり、それらを混同することが初回の適用声明で最も一般的なギャップです。条項6.1.2は、可能性、リスクレベル、およびリスク基準を用いて自身のAI目標に対するリスクを評価します。条項6.1.4は、個人、個人のグループ、および社会に対する外部影響を評価しますが、そのような可能性の仕組みは含みません。

関係は一方向です。条項6.1.4は影響評価の結果をリスク評価に考慮することを要求していますが、注記6.1.2では組織が影響評価を使用して結果を評価することができると述べています。それぞれに独自の文書化された情報義務があり、付録A.5は影響面を管理し、条項8.4は計画的な間隔または重大な変更時に両方を実施し、結果を保持することを要求しています。ISO/IEC 42005は方法を提供しますが、ガイダンスであり認証対象ではありません。

データとアイデンティティの可視性は、条項ではなくコントロールに基づいています。38の Annex A controls の9つのカテゴリーの中で、A.7.5 Data provenanceはデータ中心のプログラムが求めるもので、AIデータの出所を記録するための文書化されたプロセスを必要とします。

認証が実際に求めるもの

認証はISO/IEC 17021-1に基づき2段階で行われ、認証機関の能力はISO/IEC 42006によって定められ、2025年7月に発行されます。ステージ2は計画される段階であり、完了したリスク評価やAIシステムのイベントログなどの証拠に基づいて現場での実施と有効性を評価します。

ステージ1は人々がつまずきやすい段階です。ステージ2の準備状況を評価し、内部監査や経営レビューが単に予定されているだけでなく、実際に実施されているかを確認します。完全な内部監査サイクルを終えている必要があり、これによりチームの想定よりも認証の現実的な日付が通常1四半期遅れます。

AIガバナンスフレームワークチェックリスト

監査結果となるギャップを浮き彫りにする6つの質問です。ポリシーの環境ではなく、実際の環境に基づいてそれぞれ回答してください：

• プログラムは責任者を指名し、実際の日付でレビューサイクルを設定していますか？
• 使用中のすべてのAIシステムを特定し、それぞれがアクセスするデータとIDにマッピングしましたか？
• AIポリシーは、アクセス制限、DLP、条件付きアクセス、ログ記録を含む特定の技術的管理策を指していますか？
• フレームワークはNIST AI RMF、ISO/IEC 42001、またはその両方に準拠しており、カバレッジをベンチマークできますか？
• リクエストに応じてリスク評価、構成ログ、アクセスレポート、委員会議事録を作成できますか？
• ツール、規制、リスクの変化に応じてフレームワークを更新する計画はありますか？

答えられないことはすべて、所有者、修正計画、および検証日が必要なギャップです。

NetwrixがAIガバナンスの証拠ギャップを埋める方法

第4の柱は、ガバナンスの意図が環境の現実と出会う場所であり、ネイティブツールが簡潔な形で保持するかポータルに散在するデータに基づいています。Netwrixは名前付きのAI governance機能を通じてその層を提供します。各製品が何をするかを正確に知ることが重要です。

AIが到達できる範囲を報告する

Netwrix 1Secure は、決定がまだ取り消し可能な段階で事前展開の質問に答え、誰かが有効にする前にCopilotがアクセスできる機密データを報告します。稼働後は、Copilotの活動を報告します。ユーザー、タイムスタンプ、参照されたリソースを一覧表示し、機密データを露出する応答にフラグを立てます。また、Microsoft Entra IDの役割、権限、変更も追跡します。

Netwrix Access Analyzerは問題の難しい部分を処理します。ネストされたグループメンバーシップを解決して、有効なアクセス権をActive DirectoryおよびMicrosoft Entra IDユーザー、SharePointサイト、ファイルシステムに対して計算し、オープンアクセスと継承の破損を明らかにします。これにより、柱の4は単なる主張から、テーブル越しに渡せる個別のレポートへと変わります。

ログウィンドウを超えた証拠の保持

フレームワークは意思決定後数か月で監査されるため、これは報告の問題というより保持の問題です。 Netwrix Auditor は誰がいつ何を変更したかを前後の値とともに記録し、時点レポート を日次構成スナップショットから作成します。

規制対象の顧客2社が、審査時の違いを示しています。 First National Bank and Trust of Beloitは、17拠点で300ユーザーの継続的なOCCコンプライアンスを維持し、1週間分の手動チェックリスト作業を1時間の準備に置き換えています。

Credissimoは消費者金融業務全体でGDPRおよびISO/IEC 27001の準拠を証明し、監査レポートを1週間ではなく1日で85％速く生成しています。

Netwrixは、ピラー4が必要とするデータアクセス、identity、および監査レポート層をカバーしており、より広範なAIガバナンスプラットフォームはこれを既に持っていると想定しています。これらのプラットフォームはより広範なワークフローを実行し、AIベンダーはモデルの動作を制御し、フレームワーク、委員会、および決定はあなたのもとにあります。

まずは1つのシステムでフレームワークを検証してください

経営陣は、現在のアクセス、構成、および活動データが意思決定に役立つ場合にフレームワークを信頼します。これにより、プログラム全体を一度に開始することは推奨されません。影響の大きいシステムを1つ選び、機微なデータの露出、権限の範囲、例外の量、証拠パックの完全性を測定してください。

既存のテナントで動作するライセンス付きアシスタントは最良のプロトタイプです。権限モデルが既存のアクセス決定に基づいており、可視化ツールが現在利用可能だからです。そのシステムに対して6つの柱を適用し、証拠が実際に何を示しているかを確認し、そこからAIインベントリの残りにパターンを展開してください。

デモをリクエストして、AIツールが到達できる範囲を確認し、その背後にあるIDをマッピングし、次回の監査で求められる変更履歴を保持しましょう。