AIガバナンスポリシーの書き方（＋含めるべき内容）

組織のわずか11％がAIセキュリティに完全に準備できていると、The Netwrix 2026 Data and Identity Security Reportによると報告されています。

ほとんどの組織でのAI導入は セキュリティレビューが追いつく前に個別のツール選択を通じて行われました：従業員は Microsoft Copilot、ChatGPT、および数十の組み込みAI機能を日常業務に接続し、誰もそれらのツールがアクセスできる内容を規定するアクセスルールを書いていませんでした。

このリスクは、AIアクセスが通常のユーザーリクエストとは異なるレビュー手順に従うために残ります。これらのツールとそれらの背後にあるエージェントのIDは、権限を継承し、機密コンテンツを照会し、手動レビューがそれらをカタログ化するよりも速く新しい監査質問を作成できます。

セキュリティチームは、どのツールが存在し、どのデータにアクセスでき、誰が承認し、チームが例外をどのようにエスカレーションするかを把握する必要があります。書面によるポリシーは、インシデントが問題を提起する前にAIが何に触れられるかを定義し、サイバー回復力を強化しつつAIの導入に責任を持たせます。

AIガバナンスポリシーとは何ですか？

AIガバナンスポリシーは、組織の従業員、契約者、ベンダーがAIツールをどのように使用できるかのルールを定めた文書です。これらのツールがアクセスできるデータ、組織が承認するツール、チームが違反をどのようにエスカレーションするかが含まれます。

チームはしばしば「AIガバナンス」と「AIポリシー」を同義語として使いますが、これは同じ問題の異なる層を説明しており、その区別が誰が何を担当するかを決定します。

AIガバナンスフレームワークは、ポリシーが機能するより広範で継続的なプログラムであり、ポリシーを最新に保つ役割、レビューサイクル、およびツールを含みます。外部の参照フレームワークには、NIST AI Risk Management Framework (AI RMF)やISO/IEC 42001,がフレームワークの構造を提供し、ポリシーはその構造をチームが従えるルールに変換します。

AIガバナンスポリシーの例は何ですか？

抽象的な原則は同意しやすいが実装は難しいです。エンタープライズソフトウェア、医療、金融サービス、防衛契約の参照ポリシーは、データタイプと規制によって要件がどのように変わるかを示しています。

Enterprise Copilot と大規模言語モデル（LLM）のデータアクセスポリシー

これらは、多くの中堅市場のセキュリティチームが作成する必要があるものに最も近い類似物であり、特定の業界規制を除きます。Microsoft 365 CopilotやChatGPTなど、すでに使用されている特定のツールカテゴリに紐づくデータアクセスルールに焦点を当てており、実際のワークフローに基づいた運用を維持しています。これらのポリシーはしばしば、sensitivity labelsとoperating modelを組み合わせ、分類の所有権と技術的な実施を分離します。

ヘルスケアAIガバナンスポリシー

医療機関は、Health Insurance Portability and Accountability Act（HIPAA）に基づいてこれらを構築し、臨床AIの使用（診断または患者向けツールで、最も厳しいアクセスおよび監査ルールの対象）と管理AIの使用（スケジューリング、請求、内部文書化）を分離しています。両者は同じ規制の下で異なるリスクレベルを持つためです。モデルポリシー：組織は、ベンダーがBusiness Associate Agreementを締結している場合にのみ、AIツールに保護された健康情報（PHI）を入力できます。

金融サービスおよび防衛契約のAIガバナンスポリシー

これらはそれぞれ特定のフレームワークに基づいています。金融サービスはService Organization Control 2（SOC 2）、一般データ保護規則（GDPR）、Digital Operational Resilience Act（DORA）を含み、防衛契約はCybersecurity Maturity Model Certification (CMMC)を含みます。どちらもAIツールが顧客の財務データまたは管理された非分類情報（CUI）に触れるかどうかでリスクレベルを直接結びつけています。

防衛方針はさらに進み、Information Security Oversight Office (ISOO) の指針により、契約者はCUIを公共または消費者向けAIツールに一切入力できず、CUIを処理するAIツールはすべて契約者のシステムセキュリティ計画に記載されなければなりません。

これらの例を使用して、組織が実際に持つツール、データタイプ、およびコンプライアンス義務に基づいて独自のポリシーを確立してください。

AIガバナンスポリシーが重要な理由

書面によるポリシーは、セキュリティチームが測定、実施、改善できるAI導入のガバナンスモデルを提供します。また、ツールの承認、データアクセス、監視、およびエスカレーションをレビュー可能な証拠に変えます。

AIの導入は、セキュリティが評価できるよりも速く攻撃対象範囲を拡大します

新しいCopilot、ChatGPT、または組み込みAI機能はすべて組織のデータへのアクセスが必要であり、それぞれが管理すべき新しいアクセス経路を作成します。Netwrix 2026 Data and Identity Security Reportによると、76％が環境内の非人間のアイデンティティを完全に管理または監視しておらず、多くのAIツールの導入は継続的な可視性なしに行われています。

規制の枠組みは自主的な指針から強制へと移行しています

EU AI Actの適合性評価義務は高リスクシステムに対して一般的に2026年8月2日から適用されます。付属書Iの製品法令に該当する高リスクシステムは2027年8月2日から適用されます。文書化されたポリシーは、組織が義務化される前に要件を追跡していたことを示すのに役立ちます。規制が発効するまで何も記録しないと、誠意ある努力の証拠が残りません。

監査人と取締役会は、文書化されたポリシーを期待しています

経営陣が「AIは安全か？」と尋ねたとき、書面によるポリシーはその答えが単なる意見以上である証拠です。口頭の保証は監査やインシデントレビューで崩れます。ポリシーはセキュリティの姿勢を監査人が読めて取締役会が指摘できるものに変換し、ISO/IEC 42001で正式化された。

最小権限は、ポリシーがアクセスを定義している場合にのみAIツールに適用されます

セキュリティチームは何年もかけて役割ごとに人間のアクセスを制限してきました。チームは通常、AIツールを同じ規律から除外し、それらを展開した人間の延長または一般的なサービスアカウントとして扱います。 Identity guidance は両方のアプローチを推奨しません。なぜなら least privilege は範囲が限定され、責任あるアクセスを要求するためです。ポリシーはAIツールを独自のアカウントクラスとして指定し、実際のアクセス制限を課します。

それを持っていない組織はすでにその代金を支払っています

Netwrixの2026年データおよびIdentityセキュリティレポートによると、72％の組織がAIと自動化の影響で過去2年間に機密データに対するidentity関連リスクが増加したと述べています。ポリシーのギャップはすでにリスクデータに現れており、それを報告している組織はAIを最も速く採用している組織です。

AIガバナンスポリシーに含めるべき内容

利用可能なポリシーには、セキュリティ、法務、IT、およびデータ所有者が承認とアクセスの決定に翻訳できる条項が必要です。各条項は、ポリシーの声明を所有者、ツール、データカテゴリ、またはそれを強制可能にする管理に結びつけるべきです。

• 適用範囲と対象: ポリシーが対象とする範囲と適用対象を定義し、従業員、契約者、ベンダー、および既に使用されているshadow AIツールを含みます。明確な範囲がない場合、ポリシーは既知のツールのみを管理し、それ以外は管理されません。
• ガバナンスの役割と運営委員会： ポリシーの所有者の名前と、ポリシー外の事象があった場合にエスカレーションする相手。所有者が指定されていない場合、「ポリシーの施行」は最初に問題を発見した人に委ねられます。
• リスク分類： データや意思決定に基づいてAIのユースケースを低リスク、中リスク、高リスクに分類します。階層がないと、すべてのAIユースケースが同じレベルの精査を受けるため、高リスクのものは十分にレビューされず、低リスクのものは不必要な摩擦を生み出します。
• データアクセスおよび使用ルール： AIツールの各リスクレベルがアクセスできるデータとできないデータを指定します。これは価値声明を実施可能な管理に変える条項です。これがなければ、「責任あるAIの使用」は技術的な意味を持ちません。
• 承認されたツールおよびベンダーのレビュー手順： セキュリティ、法務、データ担当者が、誰も会社のデータに接続する前に新しいAIツールを審査・承認する方法を確立します。これがないと、ツールの導入はセキュリティレビューではなく、最初に見つけた人によって行われます。
• 監視および監査の要件： 組織がチームが実際にポリシーを遵守しているかを検証する方法を定義します。誰も現実と照合しないポリシーは紙の上だけに存在します。
• インシデント対応とエスカレーション： AIツールがセキュリティまたはコンプライアンスの問題を引き起こしたり明らかにしたりした場合の対応を定めます。これがないと、チームはAI関連のインシデントを場当たり的に、誤った手順で、または遅すぎて対応します。
• 規制の整合性： ポリシーをNIST AI RMF、ISO/IEC 42001、およびEU AI Actを含む適用可能なフレームワークにマッピングします。これにより、1つのポリシーで複数のコンプライアンス義務を満たすことができ、規制ごとに別の文書を必要としません。
• レビューと更新の頻度： 新しいツールカテゴリ、規制の変更、インシデントなどの重要なトリガー後に、定められたスケジュールでポリシーを見直すことを約束してください。AIツールはほとんどのポリシーレビューサイクルよりも速く変化するため、頻度がないポリシーは数か月で陳腐化します。

採用と説明責任のバランスを取るAIガバナンスポリシーの書き方

経営陣はAIの導入を迅速に進めたいと考えていますが、セキュリティは不注意な場合の結果を負います。セキュリティチームが証拠を必要とする順序でポリシーを作成してください。まず所有者、次にツールとデータフロー、その後リスク階層、アクセスルール、規制マッピング、レビューの頻度です。インベントリ作成前に書かれたアクセスルールは、すでにリスクを生んでいるツールを見逃しがちです。

1. 文章を書く前に、クロスファンクショナルなガバナンスチームを結成しましょう

実際の役割を明確にすることから始めましょう。施行、法務、規制言語の遵守を担当する情報セキュリティまたはIdentity and Access Management (IAM)のリーダー、機密データの所在を把握しているITまたはデータ所有者、日常的にAIツールを使用する事業部門の代表者、例外を承認できる経営幹部のスポンサーです。

セキュリティ内部だけでなく外部のビジネスユニットを結びつける権限をすでに持つ役割に基づいて議長を選んでください。セキュリティ主導の組織では、それがCISOです。リスク優先の組織では、ビジネスユニットがすでに企業リスクに関してその役割に報告しているため、代わりに上級リスク担当役員が務めます。AIガバナンスも同じ権限が必要で、そうでなければそれらのユニットは任意と見なします。

役割ごとに1人に限定し、作業負荷が多い場合のみ補助者を置いてください。セキュリティが単独でポリシーを作成すると、セキュリティ文書のようになり、リスクを生み出す事業部を統治する権限が不足する可能性があります。

2. 既に持っているAIツールとデータフローを、シャドーAIを含めて棚卸しします

SaaS支出、調達記録、ブラウザ拡張機能、Open Authorization (OAuth)付与監査、および事業部門への直接調査の4つのソースから一度にインベントリを構築します。

従業員が「単なるライティングアシスタント」と見なして定期的に省略するツールがあるため、4つすべてを照合してください。調達記録には個別に費用計上されたものが含まれないことがあります。個別のサブスクリプションは承認閾値を下回ることがあり、支出レビューでは既存のSaaS契約内のバンドルされたAI階層を見逃す可能性があります。

Microsoft 365の場合、Entra IDのエンタープライズアプリケーションとサービスプリンシパルを列挙し、委任されたまたはアプリケーションのMicrosoft Graph権限を持つものをフラグ付けします。各付与はAIツールが使用できるアクセス経路です。

OAuth同意付与の監査とMicrosoftの不正な同意付与に対する修復手順は、リスクのある認可を検出しクリーンアップするのに役立ちます。各ツールの目的、ビジネスオーナー、および関係するデータをAIシステムのインベントリに記録してください。

3. リスク層別にAIユースケースを分類する

各ユースケースを2つの基準でまとめて分類します：

1. ツールが扱うデータ（公開、内部、規制対象、または個人識別情報（PII））。
2. そのデータで何をするか（要約して表示し、ビジネスの意思決定に役立てるか、自律的に行動するか）。

公開マーケティング文のみを書き換えるツールは、どれだけ高度でもリスクは低いです。顧客記録を引き出してサポートチケットに回答するツールは、出力が通常に見えてもリスクが高いです。

取引を実行したり生産を変更したりする自律的なツールは最上位に位置し、必須の人間の承認が必要です。EUで運用している場合は、これらの内部層を EU AI Act categories の上に重ねて、両方のスキームが見えるようにしてください。

4. 各リスクレベルがアクセスできるデータとできないデータを定義します

各アクセスルールをリスクレベルからデータカテゴリへの直接マッピングとして記述してください。低リスクツールは非機密で既に公開されているコンテンツにアクセスできます。中リスクツールは特定の既に分類されたデータセットへのアクセスに限定されます。高リスクツールは展開前に明示的な書面承認、アクセスログ記録、および指名された人間のレビュアーが必要です。

規制対象データの場合、条件を明確に指定してください：PHIには署名済みのBusiness Associate Agreementが必要であり、CUIは認定環境以外のツールに入力できません。

5. 公開する前にエスカレーションとインシデント対応を定義する

AIツールがセキュリティまたはコンプライアンスの問題を引き起こしたり明らかにした場合に何が起こるかを明確にしてください：誰が通知されるのか、どのくらい迅速か、そしてどの既存のインシデント対応プロセスが対応するのか。ステップ1で指定されたガバナンス役割にエスカレーション経路を結びつけ、問題に対して最初に気付いた人に自動的に任せるのではなく、明確な責任者を設定してください。

このステップが書面化されていないと、チームはAI関連のインシデントを場当たり的に、誤ったプレイブックで、あるいは遅すぎて対応してしまい、ポリシーがインシデント発生前に埋めるべきギャップが生じます。

6. ポリシーを適用される規制フレームワークにマッピングする

1つのコントロールマトリックスで、すべてのフレームワークに対応できます。4つのAI RMF機能（Govern, Map, Measure, and Manage）をISO/IEC 42001のマネジメントシステム条項およびAI Actのリスク階層に合わせ、統合マトリックスに対してポリシー言語を一度だけ作成します。

この2つの標準は相互に補完し合います。NIST AI RMFは運用リスク管理のアクションを提供し、ISO/IEC 42001はガバナンスの構造と監査証跡を提供します。これらのフレームワーク全体で同じ制御言語を使用することで、すべての義務に関する重複した文書を減らすことができます。

7. 公開前にレビューの頻度を設定する

最低でも年次の特定の間隔を設定し、新しいAIツールカテゴリの採用、規制の変更、インシデント、買収や再編成（主要なビジネスプロセスおよび関連データ要件の大幅な変更を含む）など、オフサイクルレビューを強制する特定のトリガーを設けます。

リスクに応じて頻度を調整し、リスクの高いシステムはチームがより頻繁にレビューし、ガバナンス委員会は定期的に会合を開きます。頻度、トリガー、担当者は文書に記載してください。誰かの頭の中だけにあるレビュー予定は、その人が役割を変えると無効になります。

AIガバナンスポリシーを実践で適用する方法

ポリシー条項には、セキュリティが検証できる技術的な管理が必要です。「ポリシーで禁止」と言うだけでは、可視性、アクセスレビュー、アラート、取り消しがその答えを真実にするときにのみ意味があります。

AIツールが実際にアクセスできる内容を完全に把握しましょう

実施は、AIツールとデータの接続のライブマップから始まります：OAuth許可、Microsoft 365およびMicrosoft Entra ID の権限、ブラウザ拡張機能、および既存のSaaSプラットフォーム内の埋め込みAI機能。

同時に正面玄関を閉じます：未検証のアプリケーションに対するユーザー同意を無効にし、新しいリクエストを管理者同意ワークフローにルーティングして、新しいAI統合がデフォルトでレビュー プロセスに入るようにします。

セキュリティチームは通常、人間のアカウントに対して「誰が何にアクセスできるか」を答えられます。このステップでは、ネストされたグループや継承されたアクセスから生じる実効権限を含む、AIツールおよびエージェントに対する同等の回答を構築します。

ここではMicrosoftのネイティブツールが役立ちますが、Purview DSPM for AIは上位100のSharePointサイトに対してのみ自動リスク評価を実行するため、より広範なdata security postureビューがネイティブの状況を検証し、ギャップを特定するのに役立ちます。

特にCopilotの場合、感度ラベルをSharePointサイトのアクセス制限およびRestricted Content Discoveryと組み合わせて、過剰な共有がCopilotが参照する基礎データに届かないようにします。

人に対して行うのと同じ方法でAIに最小権限を適用してください

AIツールおよびエージェントのIDを独自のアカウントクラスとして扱い、同じアクセスレビューおよび証明ワークフローを人間のアカウントで既に使用しているものと同様に適用します。広範な常設権限ではなく、範囲が限定され期限付きのアクセスを要求し、入社・異動・退職プロセスを実行して、人間のオフボーディングとAIツールの廃止を管理します。

Zero Standing Privilegeはタスクスコープのephemeral accountsを使用し、永続的な昇格権限の資格情報の代わりにこの規律をモデル化します。

イースタンカーバーカウンティスクールズはまさにこの規律を適用しました：学生データの周りに管理者アカウントを放置する代わりに、学区は必要なときだけ特権アクセスを Netwrix Privilege Secure を使って制限し、展開は四半期単位のプロジェクトではなく数日で完了しました。

すべてのエージェントIDをhuman sponsorに紐づけて、ヒューマンオーナーが離れたときにも各アカウントに責任ある所有者を保持します。現在のアイデンティティガイドラインでは、エージェントのレビュー頻度を短くすることを推奨しており、最低でも四半期ごと、高権限エージェントは月次で行うべきです。エージェントのアクセスは年次認証よりも速く変わるためです。

AI駆動のデータ露出を継続的に監視する

監視は継続的に行う必要があります。新しいAIツールや統合が登場した瞬間に、一度きりのアクセスレビューは陳腐化するためです。記録された権限を超えて、AIツールが実際に照会し取得するデータを追跡し、承認された使用範囲外の量や機密性のパターンを検出してください。

Microsoft 365では、Copilotの操作が統合監査ログに記録されるため、監査人が昨年の記録を要求する前に、ポリシーが約束する証拠の保持期間と監査の保持期間が一致していることを確認してください。これにより、セキュリティチームはポリシーのアクセスルールが実際のAIの動作と一致していることを証明できます。

Netwrix AI Governance、Netwrix 1Secure™を通じて提供され、セキュリティチームが監査証拠として保持できるCopilotの操作追跡と報告を追加します。

AIツールがアクセス境界を超えたときにアラートとエスカレーションを自動化します

検知は、ポリシーで既に定義されているエスカレーション経路をトリガーした場合にのみ価値があります。検出結果をポリシーのガバナンスセクションに記載されたincident response process に自動的にルーティングし、すべてのアラートを監査証拠として記録します。エスカレーション経路は、明確な所有権とタイミングを持つ機能的な取り消しプロセスに接続されている必要があります。

AIガバナンスポリシーを実行可能な管理に変えましょう

各条項が技術的コントロールに対応している場合、書面によるポリシーはリスクを軽減します：AIツールがアクセスできる内容の可視化、AIアイデンティティの最小権限、継続的な監視。

多くのAI関連リスクは、Identityインシデントと同じアクセス経路をたどります。攻撃者は正当な資格情報を使ってデータにアクセスし、過剰な常時アクセス権を持つAIツールは環境内のもう一つの過剰権限を持つIdentityになります。

データセキュリティとアイデンティティセキュリティは、2つの視点から見た同じ問題であり、両方が一緒に適用される場合にのみポリシーはリスクを軽減します。

デモをリクエストして、1SecureがAIツールのアクセスをマッピングし、Copilotのやり取りを追跡し、ポリシーのアクセスルールを監査証拠に変える方法をご覧ください。