自社ホスト型PIIツールがコンプライアンス監査に落ちる理由
GDPRは証拠を求めます。個人情報の削除が毎回同じ方法で行われたことを示さなければなりません。DPAの監査担当者はこれを直接確認します。すべてのデータに適用された明確で一貫した方法を見たいのです。
自社ホスト型Presidioにはここで本当の問題があります。設定の問題ではありません。自社ホスト型NLPツールの根本的な限界です。
環境ドリフトとは何か
自社ホスト型Presidioは開発環境、ステージング環境、本番環境で動作します。これらの各環境は異なる動作をする可能性があります。そのため、同じ入力が各環境で異なる結果を生む場合があります。
これを環境ドリフトと呼びます。主な原因は4つあります。
モデルバージョンドリフト
spaCyモデルはバージョン管理されています。モデル en_core_web_lg 3.4.4 と en_core_web_lg 3.5.1 は異なるデータで学習されました。アーキテクチャも異なります。そのため、同じ文書が各バージョンで異なるNER結果を生む場合があります。
一般的な設定はこのようになります。
- 開発環境：
en_core_web_lg 3.4.4（プロジェクト開始時にインストール） - ステージング：
en_core_web_lg 3.5.0（定期メンテナンス時に更新） - 本番環境：
en_core_web_lg 3.5.1（セキュリティパッチ時に更新）
3つの設定です。3つのモデルバージョン。3つの異なる検出動作。テストはステージングで合格します。しかし本番環境は別のモデルを使います。そのためギャップが隠れたままになります。
依存関係バージョンドリフト
spaCy 3.4.xと3.5.xは文の分割方法が異なります。この変更は、文の境界付近での名前の検出方法に影響します。これらの変更はspaCyのリリースノートに記載されています。しかし多くのチームはPII検出への影響を確認しません。
設定ドリフト
開発環境で設定したスコアのしきい値が本番環境に引き継がれない場合があります。カスタムの単語リストも環境間で異なる場合があります。このようなギャップはよくあります。追跡されることはほとんどありません。監査担当者が何を求めるかはGDPRコンプライアンスガイドをご覧ください。
ハードウェアの違い
NLPモデルの計算は、すべてのCPUとGPUで同一ではありません。ノートパソコンとサーバーでは、スコアが若干異なる場合があります。そのため、ある機械では検出される名前が別の機械では検出されない場合があります。
実際の監査結果
ある銀行が自社ホスト型Presidioの設定をテストしました。
テスト設定： ステージングクラスター上のspaCy 3.4.4を使用したPresidio。 本番設定： 本番クラスター上のspaCy 3.5.1を使用したPresidio。
同じ文書セットを両方のシステムで処理し、結果を比較しました。結果：文書の3%で個人情報削除の結果が異なりました。ステージングでは検出されたが本番では検出されなかった名前がありました。検出されたテキスト範囲が異なるものもありました。
監査結果は明確でした。「当組織は、設定固有の検出出力のばらつきにより、技術的な個人情報削除措置の一貫した適用を示すことができない。」
GDPR第32条は適切な技術的措置を求めています。個人情報削除に関するEDPBのルールは一貫性と再現性を要求しています。月10万件の文書で3%の不一致率は、毎月3,000件の文書で不一致な結果が生じることを意味します。その一部はフォールスネガティブです。ステージングなら検出したはずの個人情報が本番の出力に残ります。これはコンプライアンス違反です。
その後、銀行はマネージドSaaSに移行しました。監査結果は解消されました。マネージド環境での対応についてはセキュリティとコンプライアンスのページをご覧ください。
マネージドサービスが異なる理由
マネージドサービスは1つのエンジンバージョンを実行します。すべてのユーザーが同じバージョンを同時に使用します。モデルの更新は一箇所から適用されます。設定も完全な変更履歴とともに一元管理されます。ユーザーのハードウェアは結果に影響しません。
そのため、今日処理した文書は翌月も同じ結果を生みます。エンジンバージョンが変わった場合、その変更はログに記録されバージョン管理されます。
監査証跡の違いが重要です。
自社ホスト型の監査証跡：
- 「使用：Ubuntu 22.04上のspaCy
en_core_web_lg 3.5.1を使用したPresidio 2.2.35。」 - ステージングと同じバージョンでしたか？不明。
- この文書を処理してからモデルは変わりましたか？追跡していなければ不明。
- テスト時と同じスコアのしきい値ですか？設定管理次第です。
マネージドサービスの監査証跡：
- 「使用：anonym.legal API、エンジンバージョン4.22.1、2025-03-15T14:22:31Z。」
- すべてのユーザーで同じバージョン？はい。
- 変わりましたか？エンジンバージョンは固定されています。バージョン4.22.1は常に同じエンジンを意味します。
- 設定は再現可能ですか？はい。プリセットIDが記録されています。そのバージョンでの設定は取得できます。
マネージド証跡は明確です。自社ホスト型証跡は、多くのチームが省略する慎重な追跡が必要です。
自社ホスト型設定で一貫性を改善する方法
自社ホスティングが必要な場合、4つのステップでドリフトを減らすことができます。
まず、モデルバージョンを固定します。 すべてのデプロイファイルで正確なモデルバージョンをロックします。自動更新をブロックします。ソース管理でバージョンを追跡します。
次に、コンテナイメージを固定します。 正確なモデルバージョンを組み込んだDockerイメージを作成します。各イメージにモデルバージョン、Presidioバージョン、日付でタグを付けます。テストなしにベースイメージを更新しないでください。
また、設定をコードで管理します。 すべてのPresidio設定をバージョン管理されたファイルに保存します。これには検出器、スコアのしきい値、有効な言語が含まれます。設定をアプリとともにデプロイします。
最後に、設定間でテストします。 更新後は、固定されたテスト文書セットを新しい設定で処理します。保存された参照と結果を比較します。このチェックを自動化します。自動化されたPIIリグレッションテストに関するよくある質問はFAQをご覧ください。
これらのステップは役立ちます。しかし作業も増えます。マネージドサービスは追加の手間なく同じ一貫性を提供します。
まとめ
一貫した個人情報削除は製品カタログには載りません。しかし監査担当者が証拠を求めるとき、重要になります。
積極的な管理なしでは、自社ホスト型PIIツールはドリフトします。バージョン変更が静かなギャップを生みます。それらのギャップが監査結果として現れます。
マネージドサービスはデフォルトで一貫性を提供します。エンジンは一箇所から動作します。ユーザーの設定は結果に影響しません。コンプライアンスを重視するチームにとって、これは直接的な優位性です。