生成AIの社内ルールは何を決める？入力禁止・成果物確認・例外承認・事故対応の設計

生成AIの社内利用を始めたものの、「顧客情報は禁止」「外部公開前に確認」といった注意事項だけが増え、現場が案件ごとに迷っていないでしょうか。禁止を増やすだけでは、安全な業務まで止まり、逆に例外的な利用が個人判断で進むおそれがあります。

結論は、社内ルールを情報の機密性と顧客・事業への影響で分け、入力、出力、実行の3段階へ確認者と承認条件を置くことです。例外申請と事故対応まで一続きにし、利用件数ではなく、手戻り、顧客影響、確認工数、業務成果から毎月見直します。

ツール名別の禁止一覧ではなく、用途と影響で分ける

特定のサービス名だけを並べた規程は、モデルや契約条件が変わるたびに古くなります。最初に、要約、文案、分析、検索、顧客対応、システム実行などの用途を洗い出し、扱う情報の機密性と、誤りが顧客・売上・契約へ与える影響で分類します。

低機密・低影響の社内下書きは承認済み環境で利用しやすくします。高機密なら匿名化、利用契約、学習利用の扱い、保存先を確認します。顧客への送信、価格・返金・契約判断、データ更新など影響が大きい用途は、人の確認と承認を必須にします。高機密かつ高影響なら原則禁止とし、必要性を個別審査します。

入力・出力・実行の3段階でルールを置く

入力段階では、個人情報、問い合わせ履歴、購買情報、未公開の商品情報、契約上の秘密情報を、どの条件なら扱えるかを決めます。「個人情報はすべて禁止」だけで終わらせず、匿名化、集計、承認済み環境、利用目的、保存期間まで示します。詳しい判断はCRMデータを生成AIへ入力する際の基準とそろえます。

出力段階では、事実、根拠、計算、権利、表現、顧客ごとの条件を確認します。全件を同じ強さで見るのではなく、社内メモ、担当者向け提案、顧客向け文面、契約・金額判断でレビュー率と承認者を変えます。実行段階では、送信、公開、顧客抽出、価格変更、返金、CRM更新など外部影響が生じる操作を、AIの提案と分けて承認します。

例外申請は目的・期間・責任者を限定する

ルールにない用途をすべて禁止すると、現場は申請を避けるか、必要な検証が止まります。例外申請には、業務目的、対象データ、利用環境、想定出力、外部利用の有無、確認者、成果指標、終了日を記載します。承認は恒久許可にせず、対象部署、件数、期間を絞った試行とします。

例外が繰り返される場合は、現場の逸脱として片付けず、標準ルールへ昇格できるかを見ます。一方、確認できない情報を扱う、顧客へ無承認で送る、結果を説明できない、停止できない用途は見送ります。事業、情報管理、法務、現場の役割は生成AI利用の責任設計に合わせ、最終判断者を一人に固定します。

事故対応は停止から再開条件まで決める

誤送信、機密情報の入力、誤った顧客案内、無承認の自動実行が起きたとき、最初に該当利用と外部反映を止めます。次に、入力、出力、利用者、時刻、承認履歴、送信先を保全し、責任者へ通知します。顧客、契約、売上、権利、社内業務への影響を確認し、必要な訂正や連絡を行います。

原因が曖昧なまま利用を再開しません。入力制限、プロンプト、参照データ、権限、レビュー、送信前承認のどこで防げたかを特定し、再発防止と再開条件を承認します。追跡に必要な記録項目は生成AIの利用ログ設計で補完できます。

利用率だけでなく、判断の速さと事業成果を確認する

月次では、承認済み用途の利用件数、例外申請数、差し戻し理由、確認時間、手戻り、事故・苦情、利用停止、業務時間、売上や継続率への寄与を確認します。利用が増えても、確認工数や訂正が増え、顧客体験や成果が変わらなければ拡大しません。

例外申請が同じ理由で集中するならルールが実務に合っていません。違反が特定部署へ偏るなら教育だけでなく、承認導線や利用環境を見直します。影響の大きい出力を誰がどこまで確認するかは生成AI回答のレビュー範囲とつなげます。

ルールを作る前に利用環境を整えるべき条件

承認済みツールがない、契約条件を確認できない、利用者と用途を把握できない、問い合わせ先や停止権限がない場合は、文書だけ先に配っても運用できません。まず利用環境、責任者、相談窓口、ログ、停止手順を整えます。小規模な試行なら、対象業務と利用者を限定し、判断記録を集めてから規程へ広げます。

MANAGEWORKSの既存顧客グロース支援では、生成AIを顧客対応やCRM施策へ使う際も、対象顧客、データ、判断、承認、KPI・KDI、現場運用を一つにつなぎます。導入自体を目的にせず、安全に使える条件と、顧客体験・売上改善へ寄与する条件を同時に設計します。