Data 機密情報の伏せ字化／Tokenization before LLM

LLMへ送信する前のmasking/tokenizationは、機微データ露出を減らすための一つのcontrolです。ただし「token化したから匿名」「PII detectorを通したから漏えいしない」とは扱いません。検出、変換、token scope、鍵、再識別権限、LLM送信、出力後の復元を別境界として管理します。

• Redaction: 値を削除する。復元不要だがutilityを失い得ます。
• Masking/replacement: *** や型付きplaceholderへ置換する。元値の復元情報を別途持つ方式と持たない方式を区別します。
• Pseudonymization/tokenization: 元値をtokenへ置換します。方式によってreversible/irreversible、deterministic/non-deterministic、referential integrityの性質が異なります。
• Encryption-based token: 鍵と必要metadataがあれば再識別可能です。token自体を匿名データとみなしません。
• Hash-based token: one-wayでも、入力空間が小さい・推測可能・salt/key設計が弱い場合は再識別リスクが残ります。

Google Cloud Sensitive Data ProtectionはAES-SIV deterministic encryption、format-preserving encryption、HMAC-SHA-256等を区別し、reversibilityとreferential integrityの性質が異なります。FPEは形式互換性に有用ですが、同資料はAES-SIV等よりsecurity guaranteeが少ない点も明示しています。

• data classificationとpurposeを確定する。
• LLMに不要なfield/segmentを送らない。
• detectorで対象entityを抽出する。
• entity/classごとにredact/mask/tokenize/encryptを選択する。
• 変換後payloadを再scanし、未変換・secret・quasi-identifierを検査する。
• LLM/providerへは変換後payloadだけを送る。
• 応答側もsensitive outputを検査する。
• re-identificationが必要な場合はLLMとは分離したtrusted boundaryで、認可・purpose・auditを確認して限定復元する。

PII検出は確率的・rule-based detector、辞書、regex、NER等に依存し、false negative/false positiveがあります。Presidioの文書も自動検出が全機微情報を見つける保証はないとしています。したがってdetector PASSを「機微情報なし」の証明にしません。domain-specific identifier、free text、secret、組合せで個人を識別できるquasi-identifierを別途扱います。

deterministic tokenはjoinや会話内coreferenceを維持できますが、同一tokenが広いdataset/session/tenantで再利用されるほどlinkabilityが増えます。必要な相関範囲にtoken scopeを限定し、tenant・purpose・dataset・session等のcontextを設計します。Google Cloudのcontext tweakは同じ入力のtoken相関範囲を変える実装例です。

可逆tokenのkey/token map/deanonymization metadataはLLM context、prompt、tool output、traceへ入れません。復元serviceはleast privilege、purpose check、actor、対象field、request/result locatorを監査します。LLMが任意tokenを指定して復元できるtoolを無制限に与えません。

• detector false negativeでPII/secretがそのまま送信される。
• detector false positiveで業務意味を破壊する。
• deterministic tokenの広域再利用でcross-session/cross-tenant linkabilityが生じる。
• reversible tokenとkey/mapが同じtrust boundaryへ漏れる。
• token形式・placeholderから元entity typeや関係が推測される。
• FPEで形式を保つことを匿名性と誤認する。
• plain hashを低entropy identifierへ使いdictionary/brute-force再識別される。
• masking後のquasi-identifiersの組合せで再識別される。
• output側でmodelが入力外のsensitive informationを生成・再露出する。
• logging/trace/cacheにpre-mask plaintextが残る。
• token mapのretention/deletionと原データのlifecycleがずれる。

「LLM前のmasking/tokenizationは機微データ露出を減らすcontrolであり、匿名化や漏えい防止の保証ではありません。必要データだけを送り、検出漏れ、tokenのlinkability、再識別鍵・mapping、quasi-identifier、ログ／cache、出力側を別々に管理します。可逆tokenの復元はLLMから分離した認可済み境界で行います。」

組織のdata classification、対象法域・purpose、provider data handling、entity taxonomy、detector/version/threshold、custom recognizer、token scope、reversibility要件、KMS/key rotation、token-map retention、re-identification approver、trace/cache policy、quasi-identifier risk、tenant realized behaviorは未確認です。