スクリプト一本では足りない
データサイエンスチームなら、こんなコードを書いたことがあるはずだ。
import re
def anonymize_email(text):
return re.sub(r'[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}', '[EMAIL]', text)
これはメールアドレスを置換するだけだ。それ以上ではない。データセットには名前、電話番号、医療IDがまだ含まれている。GDPRの監査に合格しないだろう。
「メールを匿名化した」と「このデータセットはGDPR準拠だ」の間には大きな差がある。チームは常にこれを過小評価している。
GDPRがMLトレーニングを制限する理由
GDPR第5条(1)(b)が重要な規定だ。目的制限原則と呼ばれる。個人記録は収集された目的のためにのみ使用できる。
顧客注文は注文処理のために収集された。レコメンデーションモデルのトレーニングのためではない。医療記録は治療のために収集された。再入院予測モデルのトレーニングのためではない。アンケート回答は製品フィードバックのために収集された。感情分類器のトレーニングのためではない。
これらの記録をMLトレーニングに使用するには、チームは次の三つのいずれかが必要だ。
- ML目的のために各個人からの明示的な同意 — 取得が難しく、遡って取得するのはしばしば不可能
- ML使用が収集と互換性があることを示す正当な利益評価 — 法的に不確実で、データ保護当局に依存する
- 匿名化 — 個人情報を置換または削除し、データセットがGDPRの下で個人情報でなくなるようにする
適切な匿名化が最大の法的確実性を提供する。課題は毎回正しく実施することだ。
単発スクリプトの問題
データセットごとに新しいPythonスクリプトを書くチームは、積み重なる問題を生む。
不完全な対象範囲。 一つのスキーマのために作られたスクリプトは新しいフィールドを見逃す。六ヶ月前に追加された臨床メモ列？ 正規表現に含まれていない。ミドルネームのフィールド？ スクリプトは姓と名のパターンしか処理しない。
一貫性がない。 データセットAはscript_v1で処理された。データセットBはscript_v3で。データセットCは別のチームメンバーが処理した。結合されたトレーニングセットには三種類の手法が混在する。DPOはこれを認証できない。
監査証跡がない。 スクリプトが実行された。何を変更したのか？ どのエンティティが見つかったのか？ 処理記録がなければ、コンプライアンスは不可能だ。当局の審査官が「このトレーニングセットが適切に処理されているとどうやって分かるのか？」と尋ねたとき、「Pythonスクリプトを実行しました」という回答では不十分だ。
モデルのドリフト。 2023年に機能していた正規表現パターンは、2024年の新しい識別子形式を検出しない。スクリプトは自動更新されない。
バッチ処理のデモンストレーション
医療AIチームが8,000件の患者記録を匿名化する必要がある。米国チームはEUのオフィスからアクセスが必要だ。Schrems IIが適用される — EU起源の記録は適切な保護措置なしに米国インフラに転送できない。
従来のアプローチ： データエンジニアがカスタムスクリプトを書く。開発に二〜三日。DPOレビューに一〜二日。修正に一日。合計：四〜六日。MLプロジェクトが遅延する。
バッチ処理アプローチ：
- 8,000件の記録をCSVとしてエクスポート
- バッチ処理にアップロード
- エンティティタイプを設定：PERSON、EMAIL_ADDRESS、PHONE_NUMBER、US_SSN、MEDICAL_RECORD、DATE_OF_BIRTH、LOCATION
- 手法を選択：置換（構造を保持するためにリアルな合成値に置換）
- 処理：8,000件の記録に45分
- クリーンなCSVをダウンロード
- DPOが処理メタデータを確認 — レコードごとのエンティティ数、適用された手法：2時間
- DPOが承認。転送が実施される。
合計時間：45分プラスDPOレビュー2時間。四〜六日の代わりに。
これらのステップがArticle 10の義務をどのように満たすかについては、EU AI法トレーニングガイドを参照してほしい。
MLに使う置換と黒塗り
匿名化の手法はモデルの品質に影響する。
黒塗りはPIIを**[黒塗り]のようなトークンに置換する。PII検出モデルには機能する。他のタスク — 感情分析、分類、推薦 — には有害だ。モデルは[黒塗り]**が特殊トークンであることを学習する。名前や値の自然な分布から学習できなくなる。
置換は「John Smith」を「David Chen」に交換する。「jsmith@company.com」を「dchen@synthetic.com」に交換する。構造はそのまま保たれる。エンティティの配置、共起パターン、文の流れ — すべて保持される。モデルはリアルなコンテキストから学習する。
MLトレーニングセットには、置換が正しい選択だ。モデルは偽の値を学習しない。その周囲のパターンを学習する。それが重要なことだ。
Schrems IIと国境を越えたデータ転送
Schrems II判決（CJEU、2020年）はEU-米国プライバシーシールドを無効にした。EU起源の記録は適切な転送保護措置なしに、米国MLインフラ — AWS US-East、GCP US-Central — に転送できない。
三つの主な保護措置は以下の通りだ：
- 転送影響評価を伴う標準契約条項
- グループ内転送のための拘束的企業規則
- 匿名化された記録のための特例 — 適切に匿名化されたファイルはGDPRの下でもはや個人情報ではなく、転送規則の適用外となる
EU起源のデータセットで米国インフラを使用するチームにとって、適切な匿名化はSchrems IIの問題を完全に解消する。クリーンなデータセットは個人情報ではない。自由に転送できる。
これはバッチ匿名化の最も強力な実用的メリットの一つだ。GDPRの準拠を超える。国境を越えた障壁を完全に取り除く。
転送制限の詳細については、GDPRデータ最小化ガイドを参照してほしい。
DPOに提供するもの
クリーンなトレーニングセットをDPO承認のために提出する際、これら五つの項目を含めること：
- ソースの説明。 元のデータセットは何か？ 収集目的は何か？ どの個人カテゴリが含まれていたか？
- 匿名化設定。 どのエンティティタイプが検出・置換されたか？ どの手法が適用されたか？
- 処理メタデータ。 レコードごとのエンティティ数、信頼スコア、処理されたレコードの総数。
- 残余リスク評価。 個人が再識別される確率はどれくらいか？ 構造化テキストで273のエンティティタイプを使った置換手法の匿名化では、この確率は非常に低い。
- 意図する使用目的。 どのモデルをトレーニングするか？ トレーニングの目的は何か？
バッチ処理は項目2と3を自動的に提供する。項目1、4、5はデータサイエンティストが提供する。
詳細はanonym.legalバッチAPIを参照してほしい。
得られるもの
GDPRに準拠したMLトレーニングセットは、カスタムスクリプトなし、数日の遅延なし、モデル品質を犠牲にせずに達成できる。
置換手法は、NLPトレーニングに重要な自然言語特性を保持する。GDPRリスクを生む個人情報を除去する。
45分のバッチ処理が、コンプライアンスレビューの遅延とシンプルなDPO承認の差だ。