DLP

生成AIへの機密データ入力が招く学習データ流出の現実

ChatGPTをはじめとするLLMを業務に組み込む際、誰もが一度は背筋が凍る思いをするはずである。従業員が未発表の製品仕様や顧客リストを平気でプロンプトに放り込むからである。

悪意はない。ただ便利だから使うだけである。

しかし、入力されたデータが生成AIの学習に回されれば、他社のプロンプトへの回答として自社の機密が漏れ出す。この惨劇を防ぐための防波堤がDLPである。単なるアクセス制御ではなく、通信の中身を解析して機密情報の流出を検知する。

本当にそこまで必要なのか。

現場のエンジニアとしては、開発スピードが落ちるため入れたくないのが本音である。だが、一度でもデータがLLMの重みとして吸収されれば、それを取り消す手段は存在しない。

パターンマッチングとマスキングによる通信遮断の裏側

DLPがどうやって機密を嗅ぎ分けるのか。基本は正規表現を用いたパターンマッチングである。マイナンバーやクレジットカード番号など、特定のフォーマットを持つ文字列をAPIのペイロードから瞬時に識別する。

検知した後のアクションはいくつかある。

通信そのものを遮断してエラーを返すか、該当部分だけをアスタリスクなどに置き換えるマスキング処理を行うかに懸かっている。実務上、どちらを選ぶかは非常に悩ましい。遮断すれば安全だが業務が止まる。マスキングなら処理は続くが、文脈が壊れてLLMがまともな推論を返せなくなることが多い。

最近は単純なパターンだけでなく、文脈から機密性を判定する機械学習ベースの検知も増えた。ただ、日本語の揺らぎに対応しきれず誤検知を連発する製品も少なくない。カタログスペックを鵜呑みにすると痛い目を見る。

法務と人事での活用事例と代表的ツール

法務部門がNDAのドラフトをAIにレビューさせる際、取引先名や金額がそのまま外部に送信されるリスクがある。ここでMicrosoft PurviewのDLP機能が活きる。Officeアプリと密結合しているため、Word上の機密ラベルを読み取り、AIへのコピペをOSレベルでブロックできる。

人事部門ではどうだろうか。

採用候補者の職務経歴書を要約させる際、氏名や住所が漏れる。Google Cloud DLPのAPIを社内システムに組み込めば、テキストストリームから個人情報をリアルタイムで除去してからLLMに渡せる。

また、従業員が勝手に外部のAIサービスを使うシャドーIT対策には、Netskopeのようなクラウドプロキシが効く。通信経路でプロンプトを監視し、ポリシー違反を弾く。

ゼロトラスト環境下の過剰検知が招く業務停滞

DLPを導入すればコンプライアンス要件は満たせる。ゼロトラストの原則に従い、すべての通信を疑ってかかる体制が整う。経営陣はこれで安心するだろう。

だが、現場は地獄である。

最大の敵はフォールスポジティブ、つまり誤検知である。例えば、社内向けのダミーデータや、公開済みのプレスリリースまで機密扱いされてブロックされる。その度にセキュリティ担当者に解除申請が飛び、AIのレスポンスを待つ前に人間がになる。

検知ルールを緩めればすり抜ける。厳しくすれば仕事にならない。このチューニングの落とし穴にハマり、結局DLPの機能をオフにしてしまう企業をいくつも見てきた。セキュリティと利便性のバランスをどこで取るか、判断が分かれるところである。

CASB連携とデータ主権を見据えたアーキテクチャ設計

どのDLPを選ぶべきか。機能一覧のマルバツ表を作っても意味がない。

まず考えるべきは、既存のインフラとの相性である。すでにCASBを導入しているなら、その拡張機能としてDLPを有効化するのが手っ取り早い。ネットワークの出口で一括して網をかけられるからである。

欧州の顧客データを扱うならGDPRへの対応も無視できない。

データが物理的にどのリージョンで処理され、DLPの検知ログ自体に個人情報が含まれていないかまで問われる。ログの保管場所すら法的な火種になるのである。

結局のところ、ツール単体で完結する話ではない。社内のデータ分類ルールが形骸化していれば、どんな高価なDLPを入れてもゴミしか検知しない。自社のデータ資産をどれだけ正確に把握できているか。それが導入の成否を分ける。