#ai#security#privacy#compliance#enterprise
公開検索に載るチャットログ時代の企業ポリシー設計
何が変わったのか
チャットボットの会話ログが検索結果に露出した事例は、「AI会話は暗黙に非公開」という前提が崩れたことを示しています。露出原因が設定ミスでも、企業側の被害は同じです。契約違反、規制対応、顧客信頼低下が一気に発生します。
したがって、会話ログは“公開され得る記録”として最初から設計する必要があります。
漏えいは境界で起きる
多くの事故は単一バグではなく、境界の積み重ねで起きます。
- 推測しやすい共有URL
- noindex未設定の公開ページ
- 分析基盤へ生ログを複製
- サポートチケットへのスクリーンショット貼付
- 拡張機能や端末同期キャッシュの再配布
1サービスだけ締めても再発します。まず境界全体を可視化することが先です。
会話データ分類を導入する
会話を機密度で段階化します。
- Tier 0：公開しても問題ない汎用質問
- Tier 1：社内運用情報
- Tier 2：顧客情報・構成詳細・契約関連
- Tier 3：規制対象データ・秘匿法務情報
分類に応じて保持期間、共有可否、暗号鍵、監査頻度を変えると統制が実務化します。
“既定で安全”のプロダクト要件
企業向けはオプションではなく初期値が重要です。
- セッションは非公開デフォルト
- 共有リンク作成前に強い警告
- 共有リンクの自動期限切れ
- 秘密情報の自動マスキング
- 外部検索インデックス連携をテナント単位で禁止
安全設定が任意だと、納期圧力で必ず抜け穴が残ります。
監査ログを二層化する
品質改善のためログは必要ですが、生会話を長期保持すると危険です。実装は二層化します。
- 可用性監視用メタデータ（遅延、失敗種別）
- 匿名化・削減済み本文ログ
- 法務保全専用の高権限ボールト
全文保持は短期、匿名テレメトリは長期という分離が現実的です。
露出時の初動手順
検知後24時間でやるべきことを固定します。
- 共有導線とクローラ到達を即時停止
- インデックス痕跡とアクセスログで対象範囲確定
- 法務・プライバシー部門と通知要否判定
- 資格情報ローテーションと悪用調査
- 再発防止策と期限を公表
初動では「完璧な原因分析」より「被害拡大阻止」が優先です。
現場教育のポイント
ドキュメント配布だけでは定着しません。必要なのは業務文脈に沿った具体例です。
- 部門別（営業/開発/CS）に危険プロンプト例を提示
- Tier2/3相当入力でUI警告を強制表示
- 社内ブラウザで貼り付けDLPを実施
- 四半期ごとに漏えい演習を実施
人は規定よりUIとワークフローに従う、という前提で設計するのが実践的です。
まとめ
会話ログ露出は例外ではなく設計課題です。公開前提で最小露出、短期保持、即時失効を組み込めば、AI活用速度を落とさずにリスクを管理できます。
