この記事を実践に移す
無料記事で概要をつかんだら、会員ライブラリや料金ページから続きに進めます。
「便利だから貼り付けた」が一番危ない
AI 利用で一番起きやすい事故は、悪意ではなく「便利だから貼り付けた」です。議事録、契約書、顧客名簿、社内資料、メール本文。ChatGPT にそのまま貼り付けて要約させた瞬間に、社外サーバーへ機密情報が渡ります。
事故の出口を塞ぐより、入り口で「渡してよいデータ / 渡してはいけないデータ」の境界を引いた方が確実です。今回は境界の引き方と、入力ガードの作り方を扱います。
渡してはいけないデータ 4 分類
次の 4 分類は、原則として外部 AI サービスに渡しません。
- 1. 顧客個人情報：氏名・連絡先・購買履歴・属性情報
- 2. 未公開の事業情報：未発表の戦略・売上・原価・取引条件
- 3. 第三者の機密：他社から預かった資料・NDA 対象データ
- 4. 認証情報：パスワード・API キー・トークン・社員番号
業種によってはここに「医療情報」「金融情報」「個人を特定できる写真」などが追加されます。法務と情シスで 1 度議論し、自社版の禁止 4-6 分類を作ります。
「条件付きで渡してよい」グレーゾーン
完全禁止だけでは AI が使えなくなります。条件付きで渡せる領域も明示します。
- - 公開済みの資料（プレスリリース・公式サイト・公開済 IR）：自由
- - 個人情報を含まない議事録：マスキング後に渡す
- - 顧客から「AI 使用に同意」を得た案件：契約上の許可下で渡す
- - 業務委託先の中間成果物：契約書の AI 利用条項を確認したうえで
「禁止」「条件付き」「自由」の 3 段階で分類し、条件付きでは何をマスキングするかまで決めます。
入力ガードの仕組み
人の意識だけに頼ると、忙しいときに事故が起きます。次の 3 段階で仕組み化します。
- 1. 教育：四半期 1 回、禁止データ 4 分類の研修を行う
- 2. ツール選定：データ学習に使われない契約形態（API 直接 / Enterprise / オンプレ）を採用する
- 3. ガード：DLP（Data Loss Prevention）やプロキシで、機密パターンの送信を検知する
特に 2 は重要です。同じ AI モデルでも、Web UI 版と API 版・Enterprise 版でデータの扱いが違います。利用規約を読み、「学習に使われない」契約条件で導入します。
社内 LLM という選択肢
外部に渡せないデータが多い業務（医療・金融・法務・大規模製造）は、社内 LLM を立てる選択肢があります。
- - オンプレや専用クラウドにモデルを置く
- - データは社外に出ない
- - 性能は外部サービスより 1-2 段落ちる
- - 運用コストはかかる
「外部 AI で処理速度を取る」「社内 LLM で安全を取る」の二者択一ではなく、業務ごとに使い分けます。一般的な情報は外部、機密は社内、と振り分けられる設計が現実的です。
事故時の対応も決めておく
それでも事故は起きます。発生時の対応手順を事前に決めます。
- - 30 分以内に情シス・法務に通報するルート
- - 漏えい範囲・影響者の特定
- - 顧客への通知判断（個人情報保護法の通知義務）
- - 再発防止の社内通達
事故対応のテンプレも 1 枚作っておくと、当日の判断が早くなります。
この回のまとめ：
- - 「禁止 / 条件付き / 自由」の 3 段階でデータを分類する
- - 顧客情報・未公開事業情報・第三者機密・認証情報は原則禁止
- - 教育・契約形態・ガードの 3 段で仕組み化する
- - 社内 LLM の選択肢も業務単位で検討する
