AI利用ポリシーの構築:CIOと法務責任者のための6セクションフレームワーク

従業員はすでにAIを使っている。
あなたが承認したAIツールではない。まだレビューしていないツールだ。誰かが昨年セットアップした無料のChatGPTアカウント。部門長がチームの予算に追加したCopilotサブスクリプション。3人のエンジニアがインストールしたブラウザ拡張機能で「画面を読んでより速く書けるよう助けてくれる」というもの。
これらのツールはすべて現役で使用されている。これらのツールに貼り付けられた顧客レコード、社内の財務予測、契約書の下書きはすべて潜在的なデータ漏洩だ。そしてAI利用ポリシーのない企業はすべて、何も言わないことでそのすべてを暗黙的に承認している。EU AI Actは、高リスクなコンテキストでAIをデプロイする組織に対して文書化されたガバナンスを要求している。EU AIガバナンス義務のEUR-Lexサマリーは、非公式な慣行はコンプライアンス要件を満たさないことを明確にしている。
ポリシーはAIの採用を遅らせない。採用を生き残れるものにする。従業員に何が安全で、何が承認が必要で、何がオフリミットかを明確なガイダンスとして提供する。全面的にAIを避けるか無謀に使うかではなく、既知の境界内で素早く動けるようになる。
この記事では完全な6セクションの構造、各セクションで行う主要な決定事項、そして自社の表現のアンカーとして使える実際のベンダーポリシーの参考資料を提供する。
スケール後ではなく今すぐ必要な理由

主要データ:AIポリシーなしのコスト
- ナレッジワーカーの78%が雇用主の明示的な承認なしに職場で個人的なAIツールを使用。ほとんどの組織は、従業員全体でどのツールが使用されているかを把握していない(Microsoft Work Trend Index、2024年)
- AIガバナンスポリシーのない企業はGDPRのもとでインシデントあたり平均488万ドルのデータ侵害コストに直面。中堅企業のガバナンスプログラムの中央値コスト5万〜10万ドルと比較して(IBM Cost of Data Breach Report 2024)
- 現在施行されているEU AI Actは、高リスクなコンテキストでAIをデプロイする組織に文書化されたガバナンスの整備を要求。非公式な慣行はコンプライアンス要件を満たさない(EU AI Act、2025〜2026年施行)
ステージ1のガバナンスギャップはAIインシデントの最も一般的な原因だ。しかし多くの組織は「AIが会社でより定着したら」ポリシーに対処すると自分に言い聞かせる。その論理は逆だ。
ポリシーを書くべき時はインシデントが起きた後ではなく、起きる前だ。そしてインシデントは今この瞬間、見えないところで起きている。
中規模法律事務所の弁護士が合併契約書の下書きをChatGPTに貼り付けて文章を整える。営業担当者が顧客連絡先データのスプレッドシートをAIツールにアップロードして個別メールを自動生成する。エンジニアがコメントに内部APIキーを含むコードのレビューをCopilotに依頼する。
これらの従業員はどれも悪意を持って行動していなかった。どれも禁止するポリシーガイダンスを持っていなかった。どれも会社はそれが起きたことを知らない。
今四半期書くポリシーは、これらのインシデントがより大きな問題になることを防ぐポリシーだ。それはまたステージ2の入場券でもある:AIマチュリティモデルは管理されたパイロットを実行する前に書面によるポリシーを必要とする。ノーポリシーの基盤の上にコンプライアントなAIプログラムは構築できない。
良い知らせ:始めるのに完璧なポリシーは必要ない。存在して共有されているものが必要だ。反復は不在に勝る。
「今四半期書くポリシーは、インシデントがフロントページの問題になることを防ぐポリシーだ。主要なデータ侵害を防いだはずのガバナンスプログラムのコストは5万〜10万ドル。侵害後の法的費用、規制対応、顧客コミュニケーションは平均488万ドル。AIガバナンス投資の計算は明快だ。」(Rework、IBM Cost of Data Breach 2024に基づく)
6セクションAIポリシーテンプレート(6-Section AI Policy Template)
ガバナンスコンプライアンス、従業員の明確さ、法的保護の最低要件をカバーするエンタープライズAI利用ポリシーを構築するための構造化フレームワーク。6つのセクションは:(1) 許容使用(承認ツール、許可目的、役割ベースのアクセス)、(2) データ分類ルール(どのデータ階層をどのツールカテゴリに入れられるか)、(3) 新ツールの承認プロセス(受付、レビュー、レジストリ)、(4) 禁止ツールとアクション(コンプライアンスとセキュリティの厳しい境界線)、(5) インシデント報告(報告チャネル、対応SLA、報告者の保護)、(6) トレーニング要件(すべての従業員のベースライン、高アクセス役割向けの強化)。6セクションすべてをカバーする作業草案は、開発中の完璧な文書より価値がある。反復は不在に勝る。
6つの必須セクション
セクション1:許容使用
このセクションが答える問い:どのAIツールが、どの目的に、どの従業員の役割に対して承認されているか。
行うべき主要な決定:
承認されたツールを名前で列挙する。総称的な「承認されたAIツール」と言わない。名前を挙げる:ChatGPT Enterprise、Microsoft Copilot for Microsoft 365、Anthropic Claude for Teams、GitHub Copilot。各指名ツールには承認ステータスがある:承認済み、条件付き承認(制限あり)、またはレビュー中。
承認された各ツールについて、許可されたユースケースを述べる。「ChatGPT Enterprise:社内コミュニケーションの下書き、会議メモのサマリー、初稿コンテンツの生成に承認。顧客データの処理または人間によるレビューなしのコンプライアンス文書生成には承認されていない。」
どの役割がどのツールにアクセスできるかを定義する。すべての従業員がすべてのツールを必要とするわけではない。財務チームは倉庫チームがアクセスできないAIツールにアクセスできるかもしれない。これはガバナンスの選択であり、技術的制限ではない。
ベンダー参考資料: Microsoft 365 CopilotはMicrosoft Compliance Centerの統合でエンタープライズグレードであり、既存のMicrosoft 365データ処理、DLP(データ損失防止)ポリシー、監査ロギングを引き継ぐことを意味する。会社がすでにMicrosoft 365を使用しているなら、Copilotは既存のコンプライアンス環境内で動作するため、最もガバナンスの摩擦が少ない。
セクション2:データ分類ルール
このセクションが答える問い:従業員はAIツールにどのようなデータを入力できるか。
これはポリシーの中で最も重要な単一のセクションだ。ほとんどのAIガバナンスインシデントはここで起きる。従業員が承認されたツールを承認された目的に使うが、間違ったデータを貼り付ける。
行うべき主要な決定:
データ階層と、どの階層がどのツールカテゴリで許可されているかを定義する。実用的なフレームワーク:
| データ階層 | 例 | 外部AIへの許可 |
|---|---|---|
| 公開 | 公開ウェブサイトコンテンツ、公開レポート、一般的なビジネス知識 | はい、いずれの承認ツールも可 |
| 社内 | 社内プロセス文書、非機密の業務データ | DPAのあるエンタープライズAIツールのみ |
| 機密 | 顧客の個人識別情報(PII)、財務予測、M&A資料、IP | プライベートまたはオンプレミスのAIデプロイのみ |
| 制限 | 医療記録、規制対象の財務データ、企業秘密 | 明示的な法的レビューなしの外部AI不可 |
ここで必要な詳細はAIアクセスのためのデータ分類ルールに完全に記載されており、このポリシーセクションと並行して読むべきものだ。
ベンダー参考資料: OpenAI Enterpriseはデータをモデルトレーニングに使用せず、DPA(データ処理契約)のもとで運営し、SOC 2 Type II認証を保持している。それにより社内階層データの適切な保存先になる。Anthropic Claude for Businessも同様にノートレーニングコミットメントとデータ所在オプションを提供している。重要なポイント:これらのコミットメントをポリシー上クリアとして扱う前に、実際のエンタープライズ契約で確認する。
よくあるギャップ: 「機密データ」の定義なしに「機密データでAIを使わない」と言うポリシー。従業員は「機密」を極端なケース(医療記録、社会保障番号)として解釈し、顧客のメールアドレス、契約条件、または社内売上数字も多くの企業の基準では機密であることに気づかない。
セクション3:新ツールの承認プロセス
このセクションが答える問い:従業員はどのようにして使用前に新しいAIツールを評価・承認してもらうか。
承認プロセスなしでは3つのアウトカムがある:従業員がいずれにせよ未承認ツールを使う(シャドーAI)、従業員がAIをまったく使わない(採用がブロックされる)、またはITが誰かが請求書を受け取ったときに事後的にすべてを承認する。これらのいずれもガバナンスではない。
行うべき主要な決定:
受付プロセスを定義する。シンプルなフォームで十分だ:ツール名、ベンダー、意図するユースケース、処理されるデータの種類、コスト、誰が依頼したか。これは申請者が5分で完了できるべきだ。
レビュー担当者を指名する。委員会ではなく一人。ほとんどの企業では、これはCIO、CISO(最高情報セキュリティ責任者)、またはその代理人だ。レビュー担当者はツールのデータ処理条件、DPAの利用可能性、SOC 2ステータス、データ分類ルールとの整合性を確認する。
対応期限の基準を設定する。標準的なリクエストには5営業日。法的レビューが必要な場合は10日。これにより承認プロセスが拒否機構ではなく応答性があることが示される。
ツールレジストリを構築する。すべての承認ツール、その条件、最終レビュー日を記載したシンプルなスプレッドシートまたはイントラネットページ。レジストリが従業員に見えると、重複した申請を提出せずに自己解決できる。
NISTアライメントに関する注記: NIST AI リスク管理フレームワーク(AI RMF)には、AIリスク管理が機能する前に組織が必要とする構造、プロセス、チームを確立するGOVERN機能が含まれている。そのMAP機能は、特に組織のAI利用とそのリスクプロファイルの特定をカバーする。ツールレジストリを持つ承認プロセスは、両方の推奨事項の実践的な実装だ。
セクション4:禁止された使用
このセクションが答える問い:絶対的な境界線は何か。
禁止された使用は2つのカテゴリに分類される:禁止ツールと禁止アクション。
禁止ツール(例):
- あらゆる業務目的の作業への無料コンシューマー向けAIツール(DPAなし、データ処理不明)
- エンタープライズ契約経路のないベンダーのAIツール
- ITレビューなしでビジネスアプリケーションのコンテンツにアクセスまたは変更するブラウザ拡張機能
禁止アクション(例):
- 人間によるレビューと文書化なしに採用、昇進、またはパフォーマンスに関する最終決定をAIで行う
- 弁護士によるレビューなしに法的アドバイス、コンプライアンス判定、または規制申請を生成するためにAIを使用する
- アクティブなDPAなしに顧客PIIを外部AIツールに入力する
- 規制対象のコンテキストで、実際には人間ではないのに人間からのものであると主張するコミュニケーションをAIで生成する
- M&A資料、取締役会資料、またはその他の重要な非公開情報を外部AIツールに入力する
禁止アクションのリストは法務チームとコンプライアンスチームが最も多くの意見を持つ場所だ。業界固有の規制要件に注意する。医療機関にはHIPAAの制約がある。金融サービス会社にはFINRAとSECの考慮事項がある。法律事務所にはクライアントデータに関する職業倫理規則がある。これらの規制上の下限は禁止アクションに属する。非公式なガイダンスとしてではなく。
よくあるギャップ: 禁止された使用をまったくリストしないポリシー(「判断を使え」)、またはほぼすべての実用的なAI使用をブロックするほど包括的に禁止された使用をリストするポリシー(採用を地下に追いやる)。目標は実際のリスクに対する具体性であり、徹底的な制限ではない。
セクション5:インシデント報告
このセクションが答える問い:何か問題が起きたときどうなるか。
AIインシデントは従来のセキュリティインシデントより多様だ。含まれるもの:AIツールが顧客に不正確な情報を送信する、承認されたツールの予期しない動作によるデータ漏洩、AIシステムからの差別的なアウトプット、外部の視聴者に届いた不正確なAI生成コンテンツ。
行うべき主要な決定:
AIインシデントを構成するものを定義する。例を挙げる。「AIツールがレビューしていない顧客コミュニケーションを送信した場合。AIツールが意図せず共有したデータにアクセスまたは保持したように見える場合。AIのアウトプットが顧客の苦情や評判上の懸念を引き起こした場合。AIツールが差別的または有害なアウトプットを生成した場合。」
報告チャネルを指名する。一つの連絡先:CIO、CISO、または専用のAIガバナンスアドレス。従業員は複雑なシステムを渡り歩くのではなく、30秒で報告できるべきだ。
対応SLAを設定する。確認時間は?誰が調査するか?外部への開示(顧客通知、規制通知)が必要かどうかを誰が決定するか?データ漏洩インシデントには、既存の侵害対応手順が適用される。GDPR(一般データ保護規則)またはCCPA(カリフォルニア州消費者プライバシー法)のもとでデータ侵害を構成する可能性のあるAIインシデントはそれらのタイムラインに従う必要がある。
報告は奨励されており、罰せられないことを明確にする。従業員がAIインシデントを報告することを恐れると、インシデントは見えないまま積み重なる。ポリシーは、善意の報告が保護されることを明示すべきだ。
よくあるギャップ: インシデント報告セクションがまったくないこと。多くのAIポリシーは許容使用とデータ制限をカバーするが、インシデント対応を未定義のままにしている。これが軽微なインシデントを重大なものにするギャップだ。従業員はエスカレーション方法が分からない問題を報告せず、小さな漏洩が積み重なる。
セクション6:トレーニング要件
このセクションが答える問い:承認されたツールの使用前にAIリテラシートレーニングを完了する必要があるのは誰か。
AIツールは、その制限についてのコンテキストなしに使用されると、品質の低いまたはリスクのあるアウトプットを生成する。AIが自信を持って不正確な情報を生成できることを理解している従業員は、信頼できる事実として扱う従業員とは異なる方法でAIアウトプットをレビューする。トレーニングはリスク軽減であり、コンプライアンスのチェックボックスではない。
行うべき主要な決定:
役割とツールでトレーニング要件を定義する。すべての人が同じトレーニングを必要とするわけではない。初稿メールにCopilotを使用するマーケティングコーディネーターは、SQL生成にAIを使用するデータアナリストとは異なるトレーニングを必要とする。
すべての従業員のための最小限のベースラインを設定する:AIとは何か(そして何でないか)、会社のデータ分類ルールが実践でどういう意味かを持つか、AIインシデントを認識する方法、そして報告方法。このベースライントレーニングは2時間未満で非同期的に提供できるべきだ。
高いAIアクセス権を持つ従業員(AIワークフローを構築するエンジニア、AIツールを管理するチームリード、Execute機能を持つAIを使用する役割)には、特定のツールの動作、制限、障害モードに関する深いトレーニングを必須とする。
更新のケイデンスを定義する。AIツールは年次トレーニングサイクルが追跡できるより速く変化する。ポリシーが改訂されたときに重要なポリシーの更新(新しい承認ツール、新しい禁止使用)の確認を必須とする。
アンカーとしてのベンダーポリシー参考資料
エンタープライズAI契約を交渉する際、これら3つの参考資料が組織が交渉のベースラインとすべき基準を確立する。
OpenAI Enterprise: 正式なDPAを提供し、データをモデルトレーニングに使用しないことを約束し、SOC 2 Type II認証を維持し、専用のセキュリティレビュープロセスを提供する。エンタープライズ契約は法務チームにデータ処理条件の出発点を提供する。現在のセキュリティとプライバシーの文書についてはOpenAI Enterpriseを参照。
Anthropic Claude for Business: ビジネスデータのノートレーニングコミットメント、データ所在オプション、エンタープライズグレードのデータ分離を提供する。Anthropicの許容使用ポリシーは、モデルが生成する/しないコンテンツのカテゴリを定義しており、自社の禁止使用リストの参考になる。現在のポリシー文書はanthropic.com/legalにある。
Microsoft Copilot for Microsoft 365: Microsoft 365コンプライアンス境界内で動作し、既存のDLPポリシー、保持ラベル、監査ロギングがCopilotのインタラクションに適用されることを意味する。すでにMicrosoft 365コンプライアンスエコシステムを使用している組織にとって、これが監査可能なデータ処理を持つエンタープライズAIツールへの最も摩擦の少ないパスだ。現在のコンプライアンス文書についてはMicrosoft 365 Copilotを参照。
これらの参考資料は守りやすい交渉ポジションを提供する。「SOC 2 Type IIとノートレーニングコミットメント付きのDPAを必須とする」は上記3つのベンダーすべてが満たせる標準的な要求だ。これらを満たせないベンダーはデフォルトで機密階層の制限が適用されるべきだ。
最も多くのリスクを生むポリシーのギャップ
AIマチュリティモデルのガバナンスセクションに基づくと、これらが最も多くのインシデントを生むギャップだ。
ポリシーにデータ分類がない。 最も一般的で最も危険なもの。どのデータがどこに行けるかについての明示的なガイダンスなしに、従業員は直感にデフォルトし、それは大きく異なる。データ分類は正しく実装することで最も影響が大きい単一のセクションだ。
インシデント報告メカニズムがない。 インシデントが沈黙のうちに積み重なる。早期に対処できたはずの小さなデータ漏洩がより大きな問題になる。すべてのAIポリシーには指名された連絡先と定義された報告パスが必要だ。
新ツールの承認プロセスがない。 シャドーAIはベンダーマーケティングのペースで拡大する。承認プロセスなしに、カンファレンスで好意的なレビューを得た新しいツールはすべて潜在的な責任になる。
ほぼすべての実用的なAI使用をブロックする禁止使用リスト。 主にリスクを心配するチームによって書かれたポリシーで、AIを使って作業する必要があるチームからの意見がない。その結果採用が地下に追いやられ、ポリシーが防ごうとしていたリスクより悪い状態になる。
レビューのケイデンスがない。 2024年に書かれてそれ以来更新されていないポリシーは今日従業員が使用しているツールに対応していない。承認ツールリストの四半期ごとのレビューが最低限だ。年次のフルポリシーレビューはカレンダーイベントであるべきだ。
Rework分析: 5つのAIトランスフォーメーション失敗モードフレームワーク全体のガバナンス失敗パターンに基づくと、データ分類セクション(6セクションAIポリシーテンプレートのセクション2)が最も重要な単一のポリシー要素だ。データ階層とツール階層マッピングを明示的に定義する組織は、ほとんどの違反を引き起こす曖昧さを排除することでAI関連のデータ漏洩インシデントを大幅に削減する。ほとんどのインシデントは悪意ある従業員によって引き起こされるのではない。自分の特定の状況にルールが適用されることを知らなかった従業員によって引き起こされる。明示的なデータ分類はその曖昧さを取り除く。
摩擦を生まずに実施する方法
強圧的な実施はポリシーがない場合と同じアウトカムを生む:シャドーAI。機能する実施アプローチは、軽量なプロセスと可視のアカウンタビリティを組み合わせる。
実際にアクセス可能なツールレジストリ。 従業員は申請を提出せずにツールが承認されているかどうかを確認できる。ツール名、ステータス、許可使用、最終レビュー日を含む四半期ごとに更新される共有スプレッドシートが摩擦を大幅に削減する。
迅速な承認対応。 新ツールリクエストへの5日間の対応により、従業員がいら立ちからプロセスを迂回することがなくなる。
包括的な監視ではなく抜き打ちチェック。 使用中の未承認ツールを発見するためのAIツールの請求書と経費報告書の四半期ごとのレビュー。監視ではなく、アカウンタビリティ。
マネージャーのアカウンタビリティ。 部門長はチームがどのAIツールを使用しているかを知っている。承認ツールリストを可視化し四半期ごとの更新を送ることで、マイクロマネジメントなしに実施できるよう準備される。
ポリシーのレビューケイデンス

AIテクノロジーは従来のITより速く変化する。1月に書かれたポリシーは7月には実質的に古くなっているかもしれない:新しいツールのリリース、ベンダー条件の変更、規制ガイダンスの発行。レビューのケイデンスをポリシー自体に組み込む。
四半期ごと: 承認ツールリストのレビュー。新たにレビューされたツールを追加。ベンダー条件が変更されたツールを削除または制限。前の四半期のインシデントをログに記録し、ポリシーの更新が必要かどうかを評価。
年次: フルポリシーレビュー。データ分類の階層が現在のビジネスデータの種類を反映しているかどうかを評価。禁止使用の例を更新。変化したものに基づいてトレーニング要件を改訂。
トリガーベース: 重要なAIインシデント、ベンダーのデータ処理条件の重大な変更、業界に影響する新しい規制ガイダンス。トリガーイベントが即時対応を必要とする場合は四半期サイクルを待たない。
ポリシーの構造、まとめ
その役割を果たすAI利用ポリシーには以下の6つのセクションがある:
- 許容使用:承認ツール、許可目的、役割ベースのアクセス
- データ分類ルール:どのデータがどのツールカテゴリに入れられるか
- 承認プロセス:新ツールがどのように評価され登録されるか
- 禁止ツールとアクション:コンプライアンスとリスクの境界線
- インシデント報告:報告方法、誰が対応するか、何が保護されるか
- トレーニング要件:すべての従業員のベースライン、高アクセス役割の強化
このリストを印刷する。法務顧問とCISOに共有する。最初のバージョンの草案作成のために半日をブロックする。今日社内で公開された作業草案は、6カ月後に完成する完璧なポリシーより価値がある。
難しい問いはポリシーの書き方ではない。最初のインシデントが起きてポリシーが実際に機能したかどうかわかるときに何が起きるかだ。
次に読むべきもの
AIアクセスのためのデータ分類ルールでこのポリシーのセクション2が必要とする完全な4階層フレームワークを確認してほしい。
AI承認ゲートとベンダーレビューでセクション3で参照されている完全なベンダー評価チェックリストを確認してほしい。
AIインシデント対応プレイブックでセクション5が依存するランブックを確認してほしい。
ステージ1から2へ:Ad-HocからPilotへでポリシーがステージ2要件にどう適合し、なぜ管理されたパイロットの入場券であるかを確認してほしい。
関連記事:
- AI Execute アクションの監査証跡:ポリシーのインシデント報告セクションから直接流れるロギング要件
- GenerateとExecuteの境界:なぜガードレールが重要か:禁止使用リストがエンコードする必要がある区別
- AIトランスフォーメーションが失敗する理由:ノーガバナンスが5つの根本原因の一つである方法

Co-Founder & CMO, Rework