# AI向けData Classification CURRENT_STATUS: UNKNOWN OBSERVATION: SPEC_ONLY FRESHNESS: UNKNOWN PAGE_TYPE: reference CANONICAL_URL: /tools/ea-061-ai-data-classification CLAIM_IDS: none EVIDENCE_IDS: EVD-EA-061-URL-BFBA4CD5131D, EVD-EA-061-URL-B8F74260B1EE, EVD-EA-061-URL-D3605CE106BF, EVD-EA-061-URL-6D8263C18C14, EVD-EA-061-URL-0CD5A41C0CCC, EVD-EA-061-URL-1DF4C6DA4EEF, EA-061-R11-RESEARCH, EA-061-R11-WEB-READBACK UNKNOWN_IDS: EA-061-UNKNOWN-01, EA-061-UNKNOWN-CURRENTNESS OPS_IDS: none ## Summary 「AI向けデータ分類は、従来の機密区分を捨ててAI専用ラベルへ置き換える作業ではない。既存の正式な分類を起点に、prompt、retrieval、tool、memory、output、logというAI固有のデータ移動面へ分類情報を伝播し、必要に応じて再検出・再評価する。自動検出結果は有力なsignalだが、完全な分類やcomplianceの証明ではない。classification、authorization、destination policyを分離し、実行時に結合する。」 ## Current judgment A. AI向けclassificationは、既存のenterprise classificationを置換する別taxonomyとして導入する根拠は今回確認できなかった。Microsoftは既存sensitivity labelsをAI interactionへ継承し、Googleもsensitive-data detection/classificationをAI workload securityへ接続している。したがってCore候補は「existing authoritative classification + AI-runtime context」の合成とする。INFERENCE / PROPOSAL。 B. detector findingとauthoritative classificationを同一視してはならない。GoogleはinfoType detectorにfalse positive/negativeがありcomplianceを保証しないと明記する。detector resultはOBSERVED/derived signal、組織の正式label/policy decisionは別artifactとして保持する。 C. sensitivityとriskも分離する。Googleのdata profileではriskがsensitivityだけでなくaccess controlsを考慮する。AIでは同じdata itemでも、approved enterprise tenantへのread-only retrievalとconsumer endpointへの送信ではrisk/enforcementが異なる。後半はCoreへのINFERENCE。 D. classification対象をsource documentだけに限定しない。少なくとも user prompt / retrieved context / tool input-output / agent memory / generated output / telemetry-log の各runtime surfaceを対象候補とし、境界通過時にlabel propagationまたはreclassificationを行う設計が必要。これはMicrosoftがprompt/responseでsensitive information typeを検出できること、OWASPがinput/output双方のsensitive disclosureを扱うことからのINFERENCE / PROPOSAL。 E. classification recordには最低でも `source_label`, `detected_info_types`, `detection_confidence/likelihood`, `data_owner`, `purpose/use-case`, `principal`, `provider/tenant`, `region/jurisdiction`, `allowed_operations`, `retention/logging rule`, `derivation/provenance` を分離して保持する候補を採る。単一の「機密/非機密」値へ圧縮しない。PROPOSAL。 F. derived outputの扱いは入力labelの機械的コピーだけでは不十分。要約・変換で機密性が保持される場合、複数sourceから高感度情報が合成される場合、逆に適切なde-identificationで感度が低下する場合がある。自動downgradeは誤判定時の漏えい影響が大きいため、future Workではdowngrade条件を別途証拠化する。HYPOTHESIS / OPEN_UNKNOWN。 ## Scope Enterprise AI Core / organization overlay / governance / security / privacy / implementation / provider mapping ## Confirmed - A. AI向けclassificationは、既存のenterprise classificationを置換する別taxonomyとして導入する根拠は今回確認できなかった。Microsoftは既存sensitivity labelsをAI interactionへ継承し、Googleもsensitive-data detection/classificationをAI workload securityへ接続している。したがってCore候補は「existing authoritative classification + AI-runtime context」の合成とする。INFERENCE / PROPOSAL。 B. detector findingとauthoritative classificationを同一視してはならない。GoogleはinfoType detectorにfalse positive/negativeがありcomplianceを保証しないと明記する。detector resultはOBSERVED/derived signal、組織の正式label/policy decisionは別artifactとして保持する。 C. sensitivityとriskも分離する。Googleのdata profileではriskがsensitivityだけでなくaccess controlsを考慮する。AIでは同じdata itemでも、approved enterprise tenantへのread-only retrievalとconsumer endpointへの送信ではrisk/enforcementが異なる。後半はCoreへのINFERENCE。 D. classification対象をsource documentだけに限定しない。少なくとも user prompt / retrieved context / tool input-output / agent memory / generated output / telemetry-log の各runtime surfaceを対象候補とし、境界通過時にlabel propagationまたはreclassificationを行う設計が必要。これはMicrosoftがprompt/responseでsensitive information typeを検出できること、OWASPがinput/output双方のsensitive disclosureを扱うことからのINFERENCE / PROPOSAL。 E. classification recordには最低でも `source_label`, `detected_info_types`, `detection_confidence/likelihood`, `data_owner`, `purpose/use-case`, `principal`, `provider/tenant`, `region/jurisdiction`, `allowed_operations`, `retention/logging rule`, `derivation/provenance` を分離して保持する候補を採る。単一の「機密/非機密」値へ圧縮しない。PROPOSAL。 F. derived outputの扱いは入力labelの機械的コピーだけでは不十分。要約・変換で機密性が保持される場合、複数sourceから高感度情報が合成される場合、逆に適切なde-identificationで感度が低下する場合がある。自動downgradeは誤判定時の漏えい影響が大きいため、future Workではdowngrade条件を別途証拠化する。HYPOTHESIS / OPEN_UNKNOWN。 ## UNKNOWN - EA-061-UNKNOWN-01: provider横断AI-runtime classification schemaの標準有無、derived outputの安全なdowngrade条件、embedding/vectorへのlabel propagation、agent memoryのclassification lifecycle、classifier drift/version provenance。 - EA-061-UNKNOWN-CURRENTNESS: 外部根拠の再確認日がcanonical body/control-planeで確定していないため、currentnessはUNKNOWNとして保持する。日付を推測補完しない。 ## Evidence - EVD-EA-061-URL-BFBA4CD5131D (RESEARCH): 1) official framework / NIST AI 600-1, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile / NIST / — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence - EVD-EA-061-URL-B8F74260B1EE (RESEARCH): 2) official product documentation / Microsoft Purview data security and compliance protections for Microsoft 365 Copilot and other generative AI apps / Microsoft / — https://learn.microsoft.com/en-us/purview/ai-microsoft-purview - EVD-EA-061-URL-D3605CE106BF (RESEARCH): 3) official product documentation / InfoTypes and infoType detectors / Google Cloud Sensitive Data Protection / Google / — https://docs.cloud.google.com/sensitive-data-protection/docs/concepts-infotypes - EVD-EA-061-URL-6D8263C18C14 (RESEARCH): 4) official product documentation / Classification, redaction, and de-identification / Google Cloud Sensitive Data Protection / Google / — https://docs.cloud.google.com/sensitive-data-protection/docs/classification-redaction - EVD-EA-061-URL-0CD5A41C0CCC (RESEARCH): 5) official product documentation / Sensitivity and data risk levels / Google Cloud Sensitive Data Protection / Google / — https://docs.cloud.google.com/sensitive-data-protection/docs/sensitivity-risk-calculation - EVD-EA-061-URL-1DF4C6DA4EEF (RESEARCH): 6) security guidance / OWASP Top 10 for Large Language Model Applications — LLM02:2025 Sensitive Information Disclosure / OWASP Foundation / — https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf - EA-061-R11-RESEARCH (RESEARCH): EA-061 監査済みresearch / canonical revision binding - EA-061-R11-WEB-READBACK (IMPL): EA-061 Web body identity / canonical readback ## Failure / limits regex/infoType/ML classifierは完全検出器ではない。未検出を「非機密」と確定しない。 ## Failure / limits sensitivity labelが存在しても、対象AI app、file type、encryption rights、tenant/configurationによってenforcement availabilityは異なる。Microsoft public docsを任意tenantの実挙動証明に使わない。 ## Failure / limits classificationだけではauthorizationにならない。identity/principal、purpose、resource ACL、provider boundary、operation typeをpolicy decisionへ結合する必要がある。 ## Failure / limits output filteringだけでは、既にproviderへ送信されたprompt/RAG contextのexposureを取り消せない。pre-send enforcementとpost-generation inspectionを別controlにする。 ## Failure / limits de-identification/redactionはutility lossを起こし得る。精度・task successとのtrade-offを評価せず一律適用しない。 ## Failure / limits embedding/vector、fine-tuning artifact、model memorizationに対して元文書labelがどこまで伝播可能かは今回未確立。 ## Failure / limits authoritative classificationとruntime-derived signalsの分離、主要runtime surfaces、provider実装precedent、detector限界、future Workの追加採集点まで確立したためEA-061初回bounded packetを閉じる。current product availabilityと未確立標準は更新時再確認する。 --- ## Practice Microsoft PurviewのAI interaction protectionは、対象Copilot/enterprise AI/other AI app、sensitivity label configuration、暗号化権限、Purview/Defender機能・ライセンス等で利用条件が変わるためPRODUCT_VOLATILE。Google Sensitive Data Protectionはscan対象、指定infoType、location、service configurationに依存し、検出対象を指定しなければ存在する機密データがprofileへ反映されない場合がある。provider mapping時にcurrent plan/region/tenant supportを再確認する。 ## Practice 実装precedentは十分存在する。Microsoftはsensitivity labels + sensitive information types/trainable classifiersをAI interactionへ接続し、Googleはbuilt-in/custom infoTypes、likelihood、classification/redaction/de-identification、sensitivity/risk profileを提供する。ただしprovider横断で共通のAI-runtime classification schemaまたはlabel-propagation protocolが標準化済みであることは今回確認できなかった。UNKNOWN。 ## Practice 製品のclassifier/detector精度を一般化できる共通benchmarkは今回採集していない。future evaluationでは少なくとも multilingual PII/credentials/proprietary terms、structured/unstructured、prompt/RAG/tool/output/log各surfaceについて precision/recall、false-negative severity、latency、cost、task-utility degradationを測る。detector vendor scoreをcompliance guaranteeへ外挿しない。 ## Practice Security: pre-send classification/enforcementを優先し、output inspectionは追加層とする。classificationはauthorizationと分離する。 Privacy: raw prompt/outputをclassification目的で中央収集すると新たな高感度data storeを作るため、minimization、redaction/tokenization、retention制限が必要。 Audit: policy decision時にresolved classification、detector/version、policy/version、principal、destination/provider、operation、override/approvalを記録する候補。 Cost/Operability: 全surface・全tokenの高精度inspectionはlatency/costを増やす。static label propagation、targeted detector、high-risk boundary inspectionを組み合わせる設計を評価対象とする。 ## Practice 現行辞典のdata governance / RAG permission / logging / provider data-handling節と重複監査し、EA-061はruntime classification propagationとpolicy bindingに限定する。 ## Practice Provider mapping時にMicrosoft Purview、Google Sensitive Data Protection、AWS Macie/Bedrock Guardrails等のcurrent availabilityとlabel inheritance/enforcement差を再採集する。 ## Practice `AI_RUNTIME_DATA_CLASSIFICATION` schema案を作る場合、authoritative labelとdetector-derived signalを別fieldにする。 ## Practice derived output / embeddings / vector store / fine-tuning dataset / agent memoryのlabel inheritance・downgrade規則を次段採集する。 ## Practice safe TEST_PROFILE: synthetic PII/credential-like/non-sensitive multilingual corpusだけを使い、各detectorのfalse positive/negative、redaction後utility、logging exposureを非認証またはsandbox環境で比較する。実tenantデータは投入しない。 ## Practice Authoritative organizational classification, detector-derived signal, sensitivity, risk and authorization remain distinct. No-detection is not proof of non-sensitive data. Pre-send enforcement and post-generation inspection are separate, and prompt/retrieved context/tool I/O/memory/output/telemetry are distinct runtime surfaces. ## WHY_THIS_MATTERS_TO_UPDATE 生成AIではデータが保存時だけでなく、prompt入力、RAG retrieval、tool result、agent memory、model output、telemetry/logへ移動する。従来の文書ラベルだけでは、このruntime dataflow全体に対する許可・変換・記録方針を表現しきれない。公開後更新では、既存Enterprise data classificationを捨てず、AI execution pathへ伝播・再評価する設計として整理する必要がある。 ## SCOPE_ROUTING Enterprise AI Core / organization overlay / governance / security / privacy / implementation / provider mapping ## CLAIM_OR_RESEARCH_QUESTION 1. AI向けdata classificationは独立した新分類体系を必要とするのか、それとも既存classificationをAI runtimeへ伝播・enforcementする拡張として設計すべきか。 2. sensitive-data detectorの結果、組織のconfidentiality label、利用目的・主体・jurisdiction・provider/tenant条件をどう分離するか。 3. prompt/RAG/tool/output/logの各境界でclassificationをどこまで再評価すべきか。 ## EVIDENCE TABLE 1) official framework / NIST AI 600-1, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile / NIST / https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence / published 2024-07-26; accessed 2026-09-14 / NIST AI 600-1 / GenAI risk management companion profile / VERIFIED_SPEC / context-support. 2) official product documentation / Microsoft Purview data security and compliance protections for Microsoft 365 Copilot and other generative AI apps / Microsoft / https://learn.microsoft.com/en-us/purview/ai-microsoft-purview / updated/published page current as accessed 2026-09-14 / current cloud product; PRODUCT_VOLATILE / section “Data classification and AI interactions”: sensitivity labels, sensitive information types and trainable classifiers can apply to AI interactions; encrypted labeled content additionally depends on VIEW/EXTRACT rights / VERIFIED_SPEC + PRODUCT_VOLATILE / support-limit. 3) official product documentation / InfoTypes and infoType detectors / Google Cloud Sensitive Data Protection / Google / https://docs.cloud.google.com/sensitive-data-protection/docs/concepts-infotypes / accessed 2026-09-14 / current service / infoType taxonomy, built-in/custom detectors, likelihood; explicit warning that detectors are not perfectly accurate and do not guarantee regulatory compliance / VERIFIED_SPEC + PRODUCT_VOLATILE / support-counter-limit. 4) official product documentation / Classification, redaction, and de-identification / Google Cloud Sensitive Data Protection / Google / https://docs.cloud.google.com/sensitive-data-protection/docs/classification-redaction / accessed 2026-09-14 / current service / text and storage classification; finding includes InfoType, Likelihood, Offset / VERIFIED_SPEC + PRODUCT_VOLATILE / support. 5) official product documentation / Sensitivity and data risk levels / Google Cloud Sensitive Data Protection / Google / https://docs.cloud.google.com/sensitive-data-protection/docs/sensitivity-risk-calculation / accessed 2026-09-14 / current service / sensitivity and risk are distinct; risk incorporates sensitivity plus access-control state; Unknown exists when scanning cannot determine sensitivity / VERIFIED_SPEC + PRODUCT_VOLATILE / support-limit. 6) security guidance / OWASP Top 10 for Large Language Model Applications — LLM02:2025 Sensitive Information Disclosure / OWASP Foundation / https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf / 2025; accessed 2026-09-14 / LLM02:2025 / sensitive scope includes PII, financial, health, confidential business data, credentials and legal documents; recommends sanitization and data-handling controls / SOURCE_REPORT / support-context. ## FINDINGS A. AI向けclassificationは、既存のenterprise classificationを置換する別taxonomyとして導入する根拠は今回確認できなかった。Microsoftは既存sensitivity labelsをAI interactionへ継承し、Googleもsensitive-data detection/classificationをAI workload securityへ接続している。したがってCore候補は「existing authoritative classification + AI-runtime context」の合成とする。INFERENCE / PROPOSAL。 B. detector findingとauthoritative classificationを同一視してはならない。GoogleはinfoType detectorにfalse positive/negativeがありcomplianceを保証しないと明記する。detector resultはOBSERVED/derived signal、組織の正式label/policy decisionは別artifactとして保持する。 C. sensitivityとriskも分離する。Googleのdata profileではriskがsensitivityだけでなくaccess controlsを考慮する。AIでは同じdata itemでも、approved enterprise tenantへのread-only retrievalとconsumer endpointへの送信ではrisk/enforcementが異なる。後半はCoreへのINFERENCE。 D. classification対象をsource documentだけに限定しない。少なくとも user prompt / retrieved context / tool input-output / agent memory / generated output / telemetry-log の各runtime surfaceを対象候補とし、境界通過時にlabel propagationまたはreclassificationを行う設計が必要。これはMicrosoftがprompt/responseでsensitive information typeを検出できること、OWASPがinput/output双方のsensitive disclosureを扱うことからのINFERENCE / PROPOSAL。 E. classification recordには最低でも `source_label`, `detected_info_types`, `detection_confidence/likelihood`, `data_owner`, `purpose/use-case`, `principal`, `provider/tenant`, `region/jurisdiction`, `allowed_operations`, `retention/logging rule`, `derivation/provenance` を分離して保持する候補を採る。単一の「機密/非機密」値へ圧縮しない。PROPOSAL。 F. derived outputの扱いは入力labelの機械的コピーだけでは不十分。要約・変換で機密性が保持される場合、複数sourceから高感度情報が合成される場合、逆に適切なde-identificationで感度が低下する場合がある。自動downgradeは誤判定時の漏えい影響が大きいため、future Workではdowngrade条件を別途証拠化する。HYPOTHESIS / OPEN_UNKNOWN。 ## LIMITS / COUNTEREVIDENCE / FAILURE ENVELOPE - regex/infoType/ML classifierは完全検出器ではない。未検出を「非機密」と確定しない。 - sensitivity labelが存在しても、対象AI app、file type、encryption rights、tenant/configurationによってenforcement availabilityは異なる。Microsoft public docsを任意tenantの実挙動証明に使わない。 - classificationだけではauthorizationにならない。identity/principal、purpose、resource ACL、provider boundary、operation typeをpolicy decisionへ結合する必要がある。 - output filteringだけでは、既にproviderへ送信されたprompt/RAG contextのexposureを取り消せない。pre-send enforcementとpost-generation inspectionを別controlにする。 - de-identification/redactionはutility lossを起こし得る。精度・task successとのtrade-offを評価せず一律適用しない。 - embedding/vector、fine-tuning artifact、model memorizationに対して元文書labelがどこまで伝播可能かは今回未確立。 ## AVAILABILITY_GATES Microsoft PurviewのAI interaction protectionは、対象Copilot/enterprise AI/other AI app、sensitivity label configuration、暗号化権限、Purview/Defender機能・ライセンス等で利用条件が変わるためPRODUCT_VOLATILE。Google Sensitive Data Protectionはscan対象、指定infoType、location、service configurationに依存し、検出対象を指定しなければ存在する機密データがprofileへ反映されない場合がある。provider mapping時にcurrent plan/region/tenant supportを再確認する。 ## IMPLEMENTATION_STATE 実装precedentは十分存在する。Microsoftはsensitivity labels + sensitive information types/trainable classifiersをAI interactionへ接続し、Googleはbuilt-in/custom infoTypes、likelihood、classification/redaction/de-identification、sensitivity/risk profileを提供する。ただしprovider横断で共通のAI-runtime classification schemaまたはlabel-propagation protocolが標準化済みであることは今回確認できなかった。UNKNOWN。 ## BENCHMARK_OR_EVAL 製品のclassifier/detector精度を一般化できる共通benchmarkは今回採集していない。future evaluationでは少なくとも multilingual PII/credentials/proprietary terms、structured/unstructured、prompt/RAG/tool/output/log各surfaceについて precision/recall、false-negative severity、latency、cost、task-utility degradationを測る。detector vendor scoreをcompliance guaranteeへ外挿しない。 ## SECURITY / PRIVACY / AUDIT / COST / OPERABILITY Security: pre-send classification/enforcementを優先し、output inspectionは追加層とする。classificationはauthorizationと分離する。 Privacy: raw prompt/outputをclassification目的で中央収集すると新たな高感度data storeを作るため、minimization、redaction/tokenization、retention制限が必要。 Audit: policy decision時にresolved classification、detector/version、policy/version、principal、destination/provider、operation、override/approvalを記録する候補。 Cost/Operability: 全surface・全tokenの高精度inspectionはlatency/costを増やす。static label propagation、targeted detector、high-risk boundary inspectionを組み合わせる設計を評価対象とする。 ## SAFE_WORDING_FOR_FUTURE_BOOK 「AI向けデータ分類は、従来の機密区分を捨ててAI専用ラベルへ置き換える作業ではない。既存の正式な分類を起点に、prompt、retrieval、tool、memory、output、logというAI固有のデータ移動面へ分類情報を伝播し、必要に応じて再検出・再評価する。自動検出結果は有力なsignalだが、完全な分類やcomplianceの証明ではない。classification、authorization、destination policyを分離し、実行時に結合する。」 ## UPDATE_WORK_HANDOFF 1. 現行辞典のdata governance / RAG permission / logging / provider data-handling節と重複監査し、EA-061はruntime classification propagationとpolicy bindingに限定する。 2. Provider mapping時にMicrosoft Purview、Google Sensitive Data Protection、AWS Macie/Bedrock Guardrails等のcurrent availabilityとlabel inheritance/enforcement差を再採集する。 3. `AI_RUNTIME_DATA_CLASSIFICATION` schema案を作る場合、authoritative labelとdetector-derived signalを別fieldにする。 4. derived output / embeddings / vector store / fine-tuning dataset / agent memoryのlabel inheritance・downgrade規則を次段採集する。 5. safe TEST_PROFILE: synthetic PII/credential-like/non-sensitive multilingual corpusだけを使い、各detectorのfalse positive/negative、redaction後utility、logging exposureを非認証またはsandbox環境で比較する。実tenantデータは投入しない。 ## OPEN_UNKNOWN provider横断AI-runtime classification schemaの標準有無、derived outputの安全なdowngrade条件、embedding/vectorへのlabel propagation、agent memoryのclassification lifecycle、classifier drift/version provenance。 ## STOP_CONDITION authoritative classificationとruntime-derived signalsの分離、主要runtime surfaces、provider実装precedent、detector限界、future Workの追加採集点まで確立したためEA-061初回bounded packetを閉じる。current product availabilityと未確立標準は更新時再確認する。 --- ## AUDITED_BOUNDARY Authoritative organizational classification, detector-derived signal, sensitivity, risk and authorization remain distinct. No-detection is not proof of non-sensitive data. Pre-send enforcement and post-generation inspection are separate, and prompt/retrieved context/tool I/O/memory/output/telemetry are distinct runtime surfaces. NEXT: /agent/start.json STOP: This is a knowledge projection, not an execution order.