异构文档环境的现实
问任何合规官员他们需要为 DSAR 响应匿名化哪些文档格式，得到的列表是可预测的：Word 合同、PDF 发票、Excel 客户数据、CSV 系统导出，有时还有 JSON 日志或 XML 数据流。
问他们使用什么工具，答案通常是：三到五种不同的工具，每种工具覆盖不同的实体、不同的配置界面和不同的审计日志格式。
这种碎片化并不是由于规划不善造成的。它反映了缺乏一个真正能够以相同能力处理所有生产文档格式的单一工具。每种格式都有专门的工具。能够以相同引擎、相同实体类型和相同审计跟踪处理所有格式的统一工具在历史上一直很少。
这造成的合规问题是：跨多个文档类型的 DSAR 响应使用多个工具进行匿名化，标准各异。由此产生的不一致性——实体 X 在 PDF 中被匿名化，但在 Excel 导出中没有，因为 Excel 工具使用不同的实体列表——正是数据保护机构（DPA）审计所揭示的那种合规差距。
格式特定的挑战
每种文档格式对于个人身份信息（PII）检测都提出了不同的技术挑战：
PDF 可以是原生文本（可选择）或基于图像（扫描）。基于图像的 PDF 在文本分析之前需要进行光学字符识别（OCR），这会引入错误率。原生 PDF 可能有文本片段（每个单词作为单独的文本对象存储），这会干扰跨单词边界的实体检测。多列布局需要在文本分析之前重建阅读顺序。
Word (DOCX)
DOCX 文档在 XML 中包含文档文本，但还包括：页眉、页脚、注释、跟踪的更改、文本框和脚注。页眉/页脚中的 PII（信头地址、联系信息）通常会被仅分析主体的工具遗漏。跟踪的更改可能包含在渲染文档中不可见的 PII 删除文本，但在文件结构中存在。
Excel (XLSX)
Excel 的二维结构意味着 PII 可以出现在数百列和数千行中的任何单元格。列标题提供上下文信号（"SSN"、"Email"、"Phone"），NER 模型仅从文本分析中无法接收。单元格值可能以数字形式存储（日期、没有破折号的 SSN），需要格式感知解释。多个工作表可能包含相关的 PII，必须一致处理。
CSV
CSV 在结构上与 Excel 相似，但在许多实现中没有列标题。"notes" 或 "comments" 列中的字段值是自由文本，可能包含 PII 和非 PII 内容。编码问题（UTF-8 与 Latin-1）可能导致对欧洲 PII 中非 ASCII 字符的检测失败。
JSON
嵌套结构意味着 PII 可能深嵌（user.address.street.line1）。数组值需要迭代。同一字段名称在不同对象中可能具有不同的 PII 特征。模式感知分析（知道 "email" 字段始终包含电子邮件地址）必须与基于内容的检测相结合。
为什么格式间的不一致是合规问题
GDPR DSAR 场景具体说明了不一致风险：
数据主体提交 DSAR 请求，要求提供关于他们的所有个人数据。合规团队找到：
- 3 个 Word 文档（合同、通信）
- 2 个 PDF 文档（发票、支持记录）
- 1 个 Excel 电子表格（客户账户数据）
- 1 个 CSV 导出（系统访问日志）
合规团队使用工具 A 处理 PDF（覆盖良好），工具 B 处理 Word（覆盖良好但遗漏页眉/页脚），使用 Excel 宏处理 XLSX（覆盖明显列，遗漏自由文本字段），对 CSV 没有工具（手动审核）。
数据主体收到一个匿名化的包裹。在 Excel 电子表格中，“经理备注”自由文本列没有被宏处理。在 Word 文档中，页眉中的信头地址被工具 B 遗漏。这两个项目都包含数据主体的记录显示他们请求匿名化的 PII。
根据 GDPR 第 17 条（删除权）或第 15 条（访问权），合规团队产生了一个不完整的 DSAR 响应。如果数据主体或 DPA 发现这个差距，不一致的工具就是合规失败的一个因素。
格式一致性作为合规要求
最严格的 DSAR 合规框架不仅规定必须匿名化哪些 PII 类型，还规定在给定响应中，所有格式必须适用相同的匿名化标准。
这意味着：
- 在 Word、PDF、Excel、CSV 和 JSON 中检查相同的实体类型
- 应用相同的置信阈值
- 使用相同的替换标记（在单个响应集中的文档之间一致的匿名化标记）
- 覆盖所有格式的单一审计跟踪
单一平台格式支持使得配置预设能够在所有格式中一致应用。为您的组织配置的 "DSAR EU Individuals" 预设在 PDF 合同、Excel 客户记录和 CSV 系统日志中检查相同的 32 种实体类型——因为相同的引擎处理这三者。
批处理混合格式集
为了大规模的 DSAR 合规，批处理必须作为一个单元处理混合格式集：
输入： 包含 15 个不同格式（PDF、DOCX、XLSX、CSV）的文件的文件夹，代表一个数据主体所持有的所有数据。
处理：
- 每个文件的格式检测
- 每种格式的适当解析器（PDF 文本提取、DOCX XML 解析、XLSX 单元格迭代、CSV 字段解析）
- 对所有格式提取的文本应用相同的 NLP 管道
- 对批处理中的所有文件应用相同的预设配置
- 一致的匿名化标记池（如果 "John Smith" 出现在 3 个不同文档中，则在所有 3 个文档中使用相同的替换标记）
输出：
- 所有 15 个文件的匿名化版本，保持其原始格式
- 跨格式审计报告，显示所有检测到的实体、文档来源、置信度和采取的行动
跨格式审计报告是合规文档：一份单一文档证明所有 15 个文件都以相同的标准、相同的实体覆盖和相同的配置进行处理。
对于 DPA 审计，这比 "我们用 Adobe 处理 PDF，用宏处理 Excel，手动处理 CSV" 更具防御性。
DSAR 团队的实际集成
对于处理常规 DSAR 量的合规团队，统一格式支持的工作流程：
- 收集数据主体的所有文档（从系统手动收集）
- 在匿名化平台上创建 DSAR 批处理（拖放所有文件，无论格式）
- 选择 "DSAR EU Individuals" 预设（覆盖所有 GDPR 要求的实体类型）
- 运行批处理
- 下载匿名化输出和合并审计报告
- 质量检查：对批处理输出中的 2-3 个文档进行抽查
- 为数据主体响应打包匿名化文档
- 将审计报告附加到 DSAR 案件记录中
手动收集（步骤 1）仍然是主要的时间成本。步骤 2-8 对于一个典型的 DSAR 批处理不到 10 分钟。步骤 5 中生成的审计报告提供了 GDPR 责任原则要求的合规文档。
来源：