AIプライバシー・エンジニアリング

Enterprise AIでは、個人情報がuser promptだけに現れるとは限らない。RAGで取得した文書、tool入出力、agent memory/state、生成物、評価fixture、trace/log/cacheにも同じ情報が複製・派生し得る。したがって「LLMへ送る前にPIIを伏せる」だけではprivacy engineeringにならない。公開後アップデートでは、データ最小化、識別可能性の低減、検出、変換、復元可能性、保持、監査をruntime surfaceごとに分離し、製品内蔵filterと組織側controlの責務を混同しない設計が必要である。

Enterprise AI Core: privacy-by-design、data minimization、de-identification/pseudonymization、runtime privacy policy、transformation provenance。 Provider mapping: Google Cloud Sensitive Data Protection、Microsoft Foundry PII filterをcurrent implementation sampleとして扱う。 Implementation/OSS: Presidio Analyzer/Anonymizerを実装precedentとして扱う。 Governance: NIST Privacy Engineering、NISTIR 8053、NIST SP 800-226。UK ICO guidanceはjurisdiction-specific regulatory guidanceとして扱い、global legal ruleへ一般化しない。 Interoperability: prompt/RAG/tool/memory/output/telemetry間のprivacy label・transform state伝播。

Q1. AI privacy engineeringは「PII detector + redaction」ではなく、収集・転送・保持そのものを減らすdata minimizationを第一段に置くべきか。 Q2. anonymization、pseudonymization、mask/redact、tokenization/hash、encryptionを同義語として扱えるか。 Q3. PII detectorの判定はprivacy/compliance上のtruth sourceとして使用できるか。 Q4. de-identified dataに対するre-identification riskと、差分privacy等のPETをどの粒度で評価すべきか。 Q5. provider内蔵filterを組織全体のprivacy controlとして外挿できるか。

• source class: official privacy engineering program / framework resource exact title: Privacy engineering author/org: National Institute of Standards and Technology (NIST) canonical URL: https://www.nist.gov/privacy-engineering publication/update/access date: current page / accessed 2026-09-14 version/release: program page; references NIST Privacy Framework and PRAM supporting locator: PEP overview; Privacy Framework; Privacy Risk Assessment Methodology evidence label: VERIFIED_SPEC relation: support / context established: NIST Privacy Engineering Programはmeasurement scienceとsystems engineeringをprivacy riskへ適用し、Privacy Framework、PRAM等を提供する。privacy controlを単一のredaction機能ではなくsystem risk managementとして扱う根拠になる。

• source class: official NIST publication exact title: De-Identification of Personal Information author/org: Simson L. Garfinkel / NIST canonical URL: https://doi.org/10.6028/NIST.IR.8053 publication/update/access date: published 2015-10-22; NIST page updated 2020-01-27; accessed 2026-09-14 version/release: NISTIR 8053 supporting locator: Abstract; de-identification / re-identification discussion evidence label: VERIFIED_SPEC + RESEARCH relation: support / counter / limit established: de-identificationはprivacy riskを下げられるが、de-identified dataが再識別され得ることが明記される。対象はstructured dataだけでなくfree text、multimedia、medical imageryまで含む。

• source class: official NIST guideline exact title: Guidelines for Evaluating Differential Privacy Guarantees author/org: Joseph Near, David Darais, Naomi Lefkovitz / NIST canonical URL: https://doi.org/10.6028/NIST.SP.800-226 publication/update/access date: published 2025-03-06; accessed 2026-09-14 version/release: NIST SP 800-226 Final supporting locator: Abstract; privacy hazards; differential privacy pyramid; NIST release announcement evidence label: VERIFIED_SPEC + RESEARCH relation: support / limit established: differential privacyはデータに個人が含まれることによるprivacy lossを定量化する数学的枠組みであり、privacy-preserving MLにも適用可能。一方NISTは実装上のprivacy hazard、noise設定、privacy-utility trade-offを評価する必要を強調しており、「DP使用=再識別不能」のような保証へ単純化できない。

• source class: regulator guidance exact title: What are the appropriate safeguards? author/org: UK Information Commissioner's Office (ICO) canonical URL: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/the-research-provisions/what-are-the-appropriate-safeguards/ publication/update/access date: accessed 2026-09-14 version/release: current web guidance; jurisdiction-specific supporting locator: data minimisation; anonymised information; pseudonymisation evidence label: SOURCE_REPORT + PRODUCT_VOLATILE relation: support / context / limit established: 必要なpersonal dataの最小量を特定し、それ以上保持しないdata minimisationを明示する。anonymous informationを利用できない場合にpseudonymisationを検討し、pseudonymous dataはなおpersonal dataであるとする。

• source class: regulator guidance exact title: Pseudonymisation author/org: UK Information Commissioner's Office (ICO) canonical URL: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/anonymisation/pseudonymisation/ publication/update/access date: accessed 2026-09-14 version/release: current web guidance; jurisdiction-specific supporting locator: Define your goals; Detail the risks; data minimisation / security sections evidence label: SOURCE_REPORT + PRODUCT_VOLATILE relation: support / counter / limit established: pseudonymisationはidentifiabilityを目的に必要な範囲へ減らす手段になり得るが、追加情報の復元・アクセス防止が必要。insider/external attackerによるre-identificationを考慮し、unauthorised reversalを抑止する必要がある。

• source class: author-maintained OSS documentation exact title: Presidio Analyzer author/org: Data Privacy Stack / Microsoft-origin Presidio project canonical URL: https://microsoft.github.io/presidio/analyzer/ publication/update/access date: accessed 2026-09-14 version/release/tag/commit: docs current; exact release tag not fixed in this RUN supporting locator: Main concepts; Creating PII recognizers; Multi-language support; decision process evidence label: OSS_PRACTICE relation: support / limit established: PII detectionはregex、NER、custom logic等のrecognizer集合で実装でき、entity type/span/scoreを返す。custom recognizer、country/language scope、decision tracingが必要になること自体が、detector出力を普遍的truthとみなせないことを示す実装precedentになる。

• source class: author-maintained OSS documentation exact title: Presidio Anonymizer author/org: Data Privacy Stack / Microsoft-origin Presidio project canonical URL: https://microsoft.github.io/presidio/anonymizer/ publication/update/access date: accessed 2026-09-14 version/release/tag/commit: docs current; exact release tag not fixed in this RUN supporting locator: Built-in operators; Deanonymizer; security considerations evidence label: OSS_PRACTICE relation: support / counter / limit established: replace、redact、mask、hash、encrypt等の異なるtransformが一つの“anonymizer”実装に含まれ、encryptはdecrypt可能である。したがってAPI/function名がanonymizeでも、法的・risk上のanonymisationを達成した証明にはならない。referential integrityのためsaltを保持すれば再識別riskが増えるというsecurity trade-offも明示される。

• source class: official cloud product documentation exact title: Sensitive Data Protection documentation / Inspect storage and databases for sensitive data author/org: Google Cloud canonical URL: https://docs.cloud.google.com/sensitive-data-protection/docs publication/update/access date: accessed 2026-09-14 version/release/API revision: current Google Cloud service; PRODUCT_VOLATILE supporting locator: infoTypes; inspection; de-identification; risk analysis; repository scanning evidence label: VERIFIED_SPEC + PRODUCT_VOLATILE relation: support / availability / context established: text/structured data/images等のsensitive data検出、predefined/custom infoTypes、de-identification、k-anonymity/l-diversity等のre-identification risk analysisを提供する。productized privacy engineering building blocksが存在するが、cloud project/region/billing/API limit等の利用条件とは分離すべきである。

• source class: official API documentation exact title: projects.content.inspect / Sensitive Data Protection author/org: Google Cloud canonical URL: https://cloud.google.com/sensitive-data-protection/docs/reference/rest/v2/projects.content/inspect publication/update/access date: accessed 2026-09-14 version/release/API revision: v2 REST surface; current docs supporting locator: InspectConfig / infoTypes; default detector behavior; content/response limits evidence label: VERIFIED_SPEC + PRODUCT_VOLATILE relation: counter / limit / availability established: inspectionはconfigured/default infoType detectorに依存し、default setは時間とともに変化し得る。またrequest/output/処理時間等のlimitsがある。検出結果を不変・完全な分類truthとして保存する設計は不適切で、detector configuration/version相当のprovenanceが必要。

• source class: official provider product documentation exact title: Personally identifiable information (PII) filter author/org: Microsoft Foundry / Microsoft Learn canonical URL: https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/content-filter-personal-information publication/update/access date: updated 2026-07-31; accessed 2026-09-14 version/release: current Foundry PII filter; PRODUCT_VOLATILE supporting locator: Personal data types; Filtering modes evidence label: VERIFIED_SPEC + PRODUCT_VOLATILE relation: support / availability / limit established: LLM completion outputのpersonal dataを検出し、AnnotateまたはAnnotate and Blockで扱える。entity categoryごとに設定可能。ただしdocumented scopeはmodel output側であり、これ単独ではprompt/RAG/tool/memory/logを覆うenterprise-wide privacy controlにならない。

• source class: official AI risk profile exact title: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile author/org: NIST canonical URL: https://doi.org/10.6028/NIST.AI.600-1 publication/update/access date: published 2024-07-26; accessed 2026-09-14 version/release: NIST AI 600-1 supporting locator: publication scope / companion profile to AI RMF 1.0 evidence label: VERIFIED_SPEC relation: context established: GenAI固有riskをAI RMFへ接続するcross-sector profileが存在する。本packetでは個別privacy controlを同文書から推測せず、AI-specific risk-management contextとしてのみ使用する。

• EA-063は「PII削除機能」ではなくprivacy engineering lifecycleとして成立する。第一原則はdetect-and-redactより前のdata minimizationであり、不要なpersonal dataをそもそも収集・検索・toolへ転送・memoryへ書込・logへ保存しない設計が優先される。
• anonymization / pseudonymization / masking / redaction / hashing / encryptionは別概念である。特にpseudonymized/reversible transformは識別可能性を低減しても復元経路を残す。OSS上の“anonymizer”という名称だけでanonymousと判定してはならない。
• PII/sensitive-data detectorは分類器であってauthorization truth sourceではない。entity coverage、language/country、custom recognizer、threshold、context、version/default-set changeによるfalse negative/false positiveがあり得る。not detected = non-personalという推論は禁止する。
• de-identificationはrisk reductionでありcategorical guaranteeではない。直接識別子を除いてもquasi-identifier、外部dataとのlinkage、small-group uniqueness、semantic contextから再識別され得る。
• differential privacyは有力PETだが、単にnoiseを加える機能ではない。privacy parameters、accounting/composition、implementation hazard、utility lossを含めて評価しなければならない。
• provider組込PII filterは有用なdefense-in-depthだが、scopeを確認しなければならない。Microsoftのcurrent filter例はmodel output detectionであり、input、RAG context、tool payload、memory、telemetryを自動的に保護する証拠ではない。
• Core候補は、prompt / retrieved context / tool input / tool output / memory/state / generated output / evaluation fixture / trace-log-cache の各surfaceごとに「必要性→classification→detection→transform→recipient→retention→audit」を評価するPrivacy Surface Matrixである。これは複数一次資料と実装から導くINFERENCE / PROPOSALであり、既存標準の名称ではない。

• anonymisedと称するdataでも、contextやauxiliary datasetとのlinkageで再識別可能性が残り得る。NISTIR 8053はこの限界を明示する。
• PII detectorはknown entity patternに強くても、自由記述中の間接識別、希少属性の組合せ、業務固有ID、画像内文字/object、複数言語ではcoverageが変わる。provider/OSS間のentity taxonomyも一致しない。
• false positiveを強くblockすると業務utilityを壊す。false negativeを減らそうとしてcontextを広げれば、privacy処理自体がより多くのraw dataへ触れる場合がある。
• reversible tokenization/encryptionはmapping/key/saltを守る別security problemを生む。復元情報を同一trust domainへ置けばpseudonymizationの分離効果が弱まる。
• output filterのみでは、providerへ送信済みのinputやretrieved contextを後から保護できない。pre-inference minimization/controlとpost-generation filteringを別層で持つ必要がある。
• Differential Privacyのbenchmark/数学保証を個別LLM会話の秘密保持保証へ外挿しない。用途・adjacency definition・privacy budgetが異なる。
• ICO guidanceはUK jurisdictionのguidanceであり、他法域へそのまま法的結論として転用しない。

• Detector: supported entity/infoType、language/locale/country、file modality、custom recognizer、threshold/likelihood、request size、latency/output limits。
• Transform: irreversible vs reversible、mapping/key/salt custody、KMS/HSM availability、referential-integrity requirement。
• Provider: service/region、SKU/billing、tenant/admin setting、filter mode、supported model/deployment、API revision。
• Workflow: whether control is applied before provider transmission, after generation, at storage/logging, or only at one surface。
• Governance: jurisdiction、purpose、lawful/approved processing basis、retention/deletion rule。法的適否の最終判断は当該組織の法務・privacy governanceと分離する。

VERIFIED implementation building blocks exist: NIST risk-engineering guidance、Google Sensitive Data Protection、Microsoft Foundry PII filter、Presidio等。しかしprovider-neutralな「AI Privacy Gateway」標準が確立しているとは確認できない。

PROPOSAL / INFERENCE for future Core: Privacy Gateway / Data Reduction Layerをinference前段だけに限定せず、各runtime surfaceへ適用する。最低限のrecordは surface, purpose, source_classification, detector/config revision, detected entity/infoType, transform, reversibility, mapping/key custodian, destination/recipient, retention, policy decision, exception/approval, provenance。ただしauditのためにraw PIIを重複保存しない。raw valueそのものではなくpolicy/transformation eventを記録する設計を優先する。

Privacy evaluationは単一accuracy scoreで閉じない。後続Work向けTEST_PROFILE（未実施）: A. synthetic PII corpusを用い、entity type × language × formatting × contextごとのprecision/recallを計測する。 B. direct identifiersだけでなくquasi-identifiers、業務固有ID、複数属性組合せをfixture化し、detector missを観測する。 C. redaction/tokenization後にtask completion/answer utilityがどこまで壊れるかを同時測定する。 D. reversible transformでは、mapping/key分離、unauthorized recovery、key rotation/失効、auditを試験する。 E. de-identified datasetではknown auxiliary informationを使ったlinkage/re-identification testを隔離synthetic dataで行う。 F. DP採用時はepsilon等のparameterだけでなくcomposition/accounting、implementation、utilityをNIST SP 800-226に沿って評価する。 実在個人データ、秘密情報、認証済みtenantへの危険なlive testは使用しない。

Privacy: minimizationを最初のcontrolに置き、必要な場合のみ検出・transformを重ねる。anonymous/pseudonymous/reversibleの状態を混同しない。 Security: mapping table、encryption key、stable salt、custom detector rule、raw quarantineは高価値資産として分離・least privilege化する。 Audit: detector/config/model version、transform policy、decision/override、destination、retention、re-identification test結果を記録する。一方、証跡のためにraw personal dataを新たに複製しない。 Cost: full-content inspection、OCR/image scan、NER、custom classifier、DP processingはlatency/compute/API costを持つ。全surfaceの同期inline scanが適切とは限らず、risk classに応じてinline/batchを分ける。 Operability: detector taxonomy drift、provider feature更新、language coverage差に備え、golden synthetic corpusで回帰試験する。block policy変更はEA-058 configuration management、EA-059 canary/feature flagと接続可能。

「AIのプライバシー対策は、PIIを見つけて黒塗りすることだけではない。まず業務目的に不要な個人情報を取得・検索・転送・保持しない。必要な情報には、検出、仮名化、削除、暗号化などを目的に応じて使い分ける。『検出されなかった』『anonymizeという関数を通した』ことだけで匿名化済みとは判断できない。識別可能性は周辺情報や復元鍵、外部データとの結合でも変わるため、入力、RAG、tool、memory、出力、ログまで処理面ごとに確認する必要がある。」

• 公開後本編ではEA-061 Data Classificationの分類結果をEA-063のprivacy actionへ接続する。classificationとPII detector findingは別フィールドにする。
• AI Privacy Surface Matrixを作る。rows: user input / system-provided context / RAG retrieval / tool input / tool output / memory-state / model output / eval dataset / trace-log-cache。columns: necessity / classification / detector / transform / reversibility / recipient / retention / residency / audit / owner。
• anonymization / pseudonymization / redaction / masking / tokenization / hashing / encryption / aggregation / differential privacyを別用語として定義し、可逆性・linkability・utility・適用対象をcrosswalkする。
• publication時にNIST Privacy Framework最新status、NIST SP 800-226 revision、ICO anonymisation guidance revision、Google detector/API docs、Microsoft Foundry PII filter availabilityを再確認する。
• Presidioは公開時点のrelease/tag/commitを固定し、supported recognizer/language listとknown issuesをauthor repoから再採集する。今回のdocs currentだけでversion保証しない。
• TEST_PROFILE-PRIV-001（未実施）: synthetic多言語PII + quasi-identifiers + domain IDsでprovider/OSS detector比較。precision/recallだけでなくtask utilityとlatency/costも測る。
• TEST_PROFILE-PRIV-002（未実施）: prompt → RAG → tool → memory → output → telemetryを通るsynthetic identifierにcanary markerを付け、どのsurfaceへ残存するかを非破壊sandboxで追跡する。
• EA-062 Residency/Sovereigntyへtransform前後dataのregion/recipientを接続し、EA-051 Telemetryへlog minimization、EA-055 Forensicsへprivacy-preserving evidence、EA-058へdetector/policy versioningをcross-referenceする。
• 法規制crosswalkはjurisdiction別の別層で作り、engineering controlの存在から法令適合を自動推定しない。

• provider横断で通用するAI-runtime privacy transformation metadata schemaの有無。
• embedding/vector representationからのmembership/inversion/re-identification riskを、Enterprise運用向けにどの試験でbounded評価するか。
• multimodal PII detectionについてtext/image/audio/videoで同等のcoverageを保証できるprovider-neutral手法。
• LLM memory/stateの削除・forget操作と、backups/log/eval copiesを含む実効削除の統一contract。
• anonymizationの十分性を各jurisdiction/用途でどのthresholdに置くか。engineering packetから法的thresholdは確定しない。
• NIST Privacy Framework次版の最終statusは公開後更新時に再確認する。

EA-063の初回Evidence Packetとして、privacy engineeringのsystem scope、主要techniqueの非同義性、PII detectorの限界、de-identification/re-identification、DP、provider/OSS実装precedent、safe wording、TEST_PROFILEまで採集できたためbounded unitを閉じる。PRODUCT_VOLATILEなprovider機能・guidance revisionと上記OPEN_UNKNOWNは公開後Workで再採集する。

---

NIST Privacy Framework 1.1 is Initial Public Draft/not final; NIST SP 800-226 is Final. Microsoft Foundry PII filtering is scoped to documented model-output scanning. Google detector behavior/config/version can drift and does not guarantee compliance. Presidio must be release/config pinned. No-detection is not non-personal proof.