Kimi 吐出简历风波后，我们更应该思考把个人信息拦在模型入口之外｜深度分析 OpenAI 开源模型隐私过滤
据公开报道，当一个用户只是让模型翻译英文，却在对话窗口里收到另一名陌生人的真实简历时，真正被引爆的，往往不只是一次技术失误，而是一个更难回避的问题：个人信息一旦进入模型相关链路，企业后面要面对的，究竟是什么。
2026-04-23，每日经济新闻 报道了一起围绕 Kimi 的争议事件：用户原本只是发起翻译请求，却收到一份包含姓名、电话和工作经历等真实信息的陌生人简历。若报道事实成立，它足以让一个长期被模糊处理的问题暴露出来：在模型时代，个人信息一旦进入训练、索引、日志、评估、审阅和共享链路，后面的难题就不再只是“有没有泄露”，而是这些信息为什么会进去、进去之后是否还在被处理、还能不能被再次抽取出来、如果当事人要求删除、限制处理或反对处理，组织还能不能有效回应。
这正是 OpenAI 新发布 Privacy Filter 值得被讨论的背景。它的意义不在于“又多了一个做脱敏的小模型”，而在于它把一条原本只停留在原则层面的思路做成了可部署的工具：如果后端的匿名化、合法性和权利响应都很难证明，那么更现实的做法，也许是尽量不要让原始个人信息先进入模型链路。
【封面图】
一、Kimi 风波真正戳中的，是模型时代的个人信息法律问题
Kimi 这类风波最容易被误写成一次“模型翻车”。但对企业来说，真正棘手的不是一条错误输出，而是这一条输出背后可能牵出的整套法律问题。
本文不试图判断该事件的具体技术原因，也不对个案法律责任作结论；它更适合作为一个现实入口，提示我们重新审视个人信息进入模型相关链路后的治理难题。
如果公开报道所描述的“陌生人简历在错误场景中重新出现”这一事实成立，组织需要面对的至少包括以下几层：
- 这些个人信息此前是基于什么理由进入系统的；
- 它们进入后，是否仍在模型、索引、日志或其他链路里继续发挥作用；
- 这些信息是否仍可能被再次识别、调取或抽取出来；
- 如果前端处理本身存在问题，后续部署是否会一并受到影响；
- 当事人提出访问、更正、删除、限制处理或反对处理请求时，组织是否还能给出可执行的回应。
也正因为如此，模型时代的个人信息问题，已经不能简单套用传统数据库治理的直觉。过去，问题常常可以被理解成“找到那条记录，再决定删不删”；现在，问题更像是“这份信息是否已经扩散进一个更大的模型相关处理体系，而组织是否还能证明自己对它保持了边界、控制和说明能力”。
二、EDPB 先把模型链路中的法律难题说清楚了
OpenAI 的 Privacy Filter 不是凭空出现的。更早之前，欧洲数据保护委员会 EDPB 已经在 2024-12-17 通过、并于 2024-12-18 发布的 Opinion 28/2024 里，把 AI 模型场景中的关键法律问题先定性了。
第一个问题，是模型能不能当然被视为匿名。EDPB 的答案是否定的。模型是否匿名，必须个案判断。要想主张模型已经匿名，至少要同时满足两层要求：一方面，极不可能直接或间接识别出用于开发该模型的个人；另一方面，也极不可能通过查询从模型中提取出这些个人数据。换句话说，只要模型与个人数据发生过关系，“它已经脱离个人数据”这件事就不能被轻易主张。
第二个问题，是处理的合法基础不只发生在训练阶段，也发生在部署阶段。EDPB 专门讨论了以正当利益作为开发或使用 AI 模型法律基础时的分析框架，强调要看严格必要性、利益衡量以及数据主体的合理预期。也就是说，问题不只是“模型有没有商业价值”，而是为了实现这种价值去处理个人数据，是否真的必要，是否存在侵入性更低的替代路径，以及数据主体是否合理预期自己的数据会被这样纳入模型相关处理。
第三个问题，是开发阶段的违法处理，是否可能继续影响部署阶段的合法性。EDPB 给出的回答很直接：如果一个 AI 模型是基于违法处理的个人数据开发出来的，这种违法性可能继续影响它后续部署的合法性，除非模型已经被适当匿名化。换成更直白的话说，前端数据问题并不会因为“模型已经训练完成”就当然被切断。
第四个问题，是从 EDPB 意见可以进一步推导出的一个实务难点：一旦个人信息进入模型相关体系，数据主体权利响应会变得更难。Opinion 28/2024 并未把访问、更正、删除、限制处理和反对处理单独作为核心问题展开，但其关于模型匿名性、合法基础以及开发阶段违法处理可能影响部署阶段合法性的分析，已经足以说明：组织不能简单以“模型已经训练完成”来切断后续责任。也正因为如此，真正要回答的，不再只是“原文还在不在”，而是这些信息是否仍在模型、索引、日志或其他链路中继续发挥作用。
三、前置过滤的价值，正是在这里显现出来
很多关于隐私治理的讨论，都会自然滑向一个后端视角：既然信息已经进入模型，那就想办法删除、隔离、遗忘或证明匿名化。但 EDPB 的定性恰恰说明，这条后端路径并不轻松。匿名化门槛不低，合法性审查不会因为“模型已经训练好”而自动消失，数据主体权利响应也不会因为系统更复杂就当然豁免。
在这种条件下，前置过滤开始具有明确的法律价值。它至少在做一件非常实在的事：减少真正进入模型相关链路的原始识别信息。
这种价值并不是让过滤工具本身替代合法性判断，而是通过减少原始识别信息进入后续链路，改善数据最小化、必要性论证、暴露面控制和责任证明条件。
这里还需要先限定“前置过滤”的含义。它不是内容安全过滤，不是用来判断暴力、色情、仇恨、违法内容；也不是完整的法律合规审查，不会直接回答处理活动是否具备合法基础、是否需要 DPIA、是否可以跨境传输。它更准确地说，是个人信息和敏感凭证进入模型链路之前的识别与降敏。换言之，它解决的是“什么信息不应原样进入系统”的第一层问题，而不是“整个处理活动是否合法”的最终问题。
这件事的意义，不在于它能自动回答全部法律问题，而在于它会直接改变这些问题的难度。如果进入训练、索引、日志和审阅链路的原始个人信息更少，后面关于必要性、相称性、权利响应、下游暴露面以及后续部署合法性的压力就会一起下降。也正因为如此，前置过滤不应被理解成一个“锦上添花的工具”，而应被理解成一种降低法律压力的系统设计。
四、OpenAI 这次到底发布了什么
放在这个背景下再看 OpenAI Privacy Filter，它的意义就清楚多了。
根据 OpenAI 2026-04-22 的博客和模型卡，Privacy Filter 是一个开放权重模型，采用 Apache 2.0 许可，并已在 Hugging Face 和 GitHub 提供下载。OpenAI 同时明确表示，这次发布的是 preview 版本；而 OpenAI 自己内部已经在隐私保护工作流中使用一个经过微调的版本。
它不是通用生成模型，而是一个面向隐私过滤任务的双向文本标注模型，通过受约束的 Viterbi 片段解码，将逐个标记的预测结果还原为边界更稳定的敏感信息片段。它的工作方式不是生成文本，而是对输入文本做整段标注，再把零散标记解码为连贯的敏感信息片段。换句话说，它更像一个高吞吐的文本筛查器，而不是一个负责“理解和回答”的聊天模型。
从部署角度看，它有几项特别值得注意的特征。
第一，它支持最长 128,000 个标记的上下文，意味着它不仅适合短句和表单，也适合邮件、工单、会议纪要、长文档和日志块这类更接近企业真实场景的文本。
第二，OpenAI 披露的规模是 1.5B 总参数、50M 活跃参数，模型卡还明确写到它可以在网页浏览器或笔记本电脑上运行。它的定位不是“大而全”的通用模型，而是高吞吐、可本地运行、可以插在数据管道前端的小模型组件。
第三，它的标签体系相当务实。除了姓名、电子邮箱、电话号码、住址这类常见个人信息之外，还覆盖账户号码，以及密钥、密码、访问令牌这类敏感凭证。这一点很关键，因为它意味着这套前置过滤不只是服务隐私团队，也同时把敏感凭证治理接到了同一个入口。
但这套标签体系仍然是面向个人信息片段的基础识别，并不等同于 GDPR、PIPL 或行业监管意义上的完整个人数据分类体系。健康数据、生物识别数据、儿童数据、精准定位、设备标识符、广告标识符、画像标签、推断数据等，仍需要在上层另行设计数据分类和法律判断规则。
第四，它不是一个“固定阈值、固定策略”的黑盒。模型卡明确写到，它自带可调的片段解码机制，用户可以在运行时调节准确率与召回率之间的权衡，也可以调整识别片段的长度。换句话说，它不是把一个唯一答案强压给组织，而是把一部分策略控制权交回给部署方。
五、OpenAI 用了一封邮件，让这个模型的用途一眼就能看懂
OpenAI 在博客里放了一个非常典型的示例文本。它不是法律文件，也不是技术日志，而是一封普通得不能再普通的工作邮件：
> Subject: Q2 Planning Follow-Up
>
> Hi Jordan,
正文大意是：发件人感谢对方当天的会议，跟进第二季度项目安排，确认产品将在 September 18, 2026 上线，并附上一个项目编号 4829-1037-5581，最后留下自己的邮箱 maya.chen@example.com 和电话 +1 (415) 555-0124 方便联系。这样的文本看上去再普通不过，恰恰像极了企业每天都在流转的邮件、工单和内部沟通。
OpenAI 展示的处理结果也很直观。模型不会把整封邮件变成一堆乱码，而是只替换真正需要处理的片段：
> Hi [PRIVATE_PERSON],
>
> ... scheduled for [PRIVATE_DATE] ...
>
> ... listed under [ACCOUNT_NUMBER] ...
>
> ... reply here at [PRIVATE_EMAIL] or call me at [PRIVATE_PHONE].
这个例子的重要之处，在于它让人立刻看懂了 Privacy Filter 在做什么。它不是判断一段文本“合不合法”，也不是把所有内容一刀切地删光，而是在尽量保留业务上下文的前提下，把那些会把文本重新指向具体个人的信息先切出来。对于训练语料、知识库入库、日志留存和人工审阅来说，这种处理方式比“要么全留、要么全删”更贴近真实工作流。
模型卡里的命令行示例则把这个过程写得更具体。它既可以直接输出带占位符的删改结果，也可以输出更详细的 JSON 结果，里面包含每个片段的起止位置、标签类别、原文内容和替换占位符。这意味着它不仅能“看出哪里敏感”，还方便被接进企业自己的后续处理链路，比如遮蔽、删改、替换、阻断、告警，或者送人工复核。
OpenAI 还在模型卡里补了一个很有意思的细节：它内部曾把模型进一步微调到另一套标签体系，用来区分某一类信息中的“私人信息”和“公开信息”，例如把私人住址与官方公开住址区分开来。这个细节说明，Privacy Filter 的价值不只是按固定标签查找敏感词，而是它可以围绕组织自己的规则和定义继续适配。
六、Privacy Filter 相比当前行业水位，真正不同在哪里
如果把 Privacy Filter 仅仅理解成又一种 PII 检测工具，它的价值就会被看窄。它和当前行业同类方案的差异，更根本地说，不只是“模型能力更强一点”，而是它更像一套面向 LLM 使用环境的数据进入控制方案。
1. 它是 AI 数据管道组件，不是传统 DLP 工具
OpenAI 对 Privacy Filter 的定位很明确：它服务的是 training、indexing、logging、review 这类数据流，也就是 AI 系统真正吃数据、存数据、过数据的地方。这个定位和传统 DLP 工具很不一样。
传统 DLP、云厂商敏感数据识别服务，更多关注的是另一类问题：数据资产在哪里，里面有没有敏感信息，要不要打标签、遮蔽、加密、审计，以及如何和权限、目录、工单、报表联动。以 Google Cloud 的 Sensitive Data Protection 为例，官方文档强调的是敏感数据发现、内置检测器、自定义检测器，以及遮蔽、删除、令牌化等去标识化转换能力；AWS 体系里也有不同层级的能力：Amazon Comprehend 的 DetectPiiEntities 更偏向自然语言文本中的 PII 实体检测，而 Amazon Macie 则更偏向 S3 数据资产中的敏感数据发现和持续监控。[6][7][8][9]
Privacy Filter 所回答的却是另一组问题：这段文本要不要进入 LLM、RAG、agent memory 或训练语料；进入之前是否应先过滤；过滤之后还能否保留足够的语义可用性。换句话说，它更像是在做 AI 工作流里的数据进入控制，而不是静态数据资产发现。
传统 DLP 并不是失效了，而是控制对象发生了变化。传统 DLP 更擅长回答“企业数据资产中是否存在敏感信息，以及如何对这些资产做发现、分类、遮蔽和审计”；而模型链路中的隐私问题进一步要求组织回答：“哪些文本在什么节点被送入训练、索引、日志、评估、人工审阅、RAG 或 agent memory？” 这不是传统 DLP 完全不能做，而是需要把 DLP 能力重新嵌入 AI 数据管道。
2. 它是开放权重模型，而不只是框架或云端 API
当前行业里，同类方案的形态并不一样。Google Cloud Sensitive Data Protection、Amazon Macie 这类是云服务；Microsoft Presidio 是开源框架；一些 AI guardrails 方案则更像编排层。Privacy Filter 的差异在于：OpenAI 发布的是开放权重模型，而且明确强调可本地运行。
这一点对隐私合规非常关键。因为 PII 过滤本身处理的就是敏感数据。如果为了脱敏而先把原始敏感文本发到第三方 API，很多企业会立刻产生新的合规问题。开放权重和本地运行意味着它更容易进入企业内网、私有化部署、本地开发环境、客户端侧处理，以及那些对训练数据清洗极其敏感的合规流程。这比“先把数据送到云端，再拿结果回来”在合规叙事上顺得多。
3. 它的长上下文能力更贴近文档型、知识库型场景
OpenAI 披露 Privacy Filter 支持最长 128,000 个标记的上下文。这个点非常重要，因为现实中的合规材料很少只是几句短文本。企业真正要处理的，往往是隐私政策、DPIA、处理活动记录、数据处理协议、产品需求文档、SDK 清单、客服与投诉记录、合同、监管文件和内部知识库。
传统 PII 工具在短文本、字段级、规则型场景里通常已经相当成熟。但一旦进入长文档，问题会迅速变成：跨段落实体能不能连起来；某个名字是自然人、公司名还是产品名；某个日期是个人日期还是制度生效日期；某个 URL 是个人主页、企业官网还是接口地址；某个账号编号到底是用户账号、订单号还是内部系统编号。
长上下文并不自动等于法律判断能力，但它确实提高了“上下文感知识别”的空间。而这一点，正好对应知识库、长文档、复杂非结构化材料进入 AI 系统时最痛的地方。
4. 它允许在准确率与召回率之间调运行点
OpenAI 在模型卡里明确提到，开发者可以调节准确率与召回率之间的取舍。这一点在隐私产品里非常实用，因为不同场景的容错方向根本不一样。
训练数据清洗通常要偏向高召回率，宁可多删，也不能漏掉大量个人信息；法律文件审阅更需要平衡，因为过度遮蔽会直接影响法律判断；客服日志入库往往也需要高召回率，因为日志量大，人工复核有限；隐私政策分析可能更需要较高精确率，以免把公司名、服务名误判成自然人信息；而 API key、密码、访问令牌这类敏感凭证检测，通常又会把召回率放得更重，因为漏掉一条的安全代价极高。
这说明它不是一个固定阈值的演示模型，而是更接近可以进入生产管道的组件。
5. 它做的是逐片段标注，而不是生成式改写
这一点在法律和合规场景里尤其关键。
如果直接让通用大模型做脱敏，常见做法往往是：“请把下面文本中的个人信息替换为 [REDACTED]。” 这种方法在演示里看起来不错，但在生产环境里问题很多：成本高、延迟大、输出不稳定、容易改写原文、容易遗漏或过度删除，也很难形成可审计的片段级判断。
Privacy Filter 采用的是文本标注思路，更接近下面这个过程：
原文保持不动
↓
识别哪些片段属于个人信息或敏感凭证
↓
只替换这些片段
这对法律和合规场景非常重要，因为很多时候需要保留原文结构，例如条款编号、表格字段、法律依据、处理目的、数据类型、风险描述和审批意见。也正因为如此，它更适合做一种“最小改动、可审计”的文本脱敏，而不是生成式重写。
6. 但它并没有取代成熟方案
这并不意味着 Privacy Filter 已经全面超过 Google Cloud Sensitive Data Protection、Amazon Macie、Presidio 或企业级 DLP 平台。恰恰相反，它的定位更适合被理解成：在面向 LLM、RAG、agent 和训练数据清洗的场景里，它把行业水位往前推了一步；但它本身还不是完整的数据分类、匿名化、DPIA 或企业数据治理平台。
和传统 DLP 平台相比，它更 AI-native、更适合嵌进模型数据管道，但缺少数据地图、权限管理、审计报表、保留期限、权利响应流程这类完整治理能力。和 Presidio 这样的开源框架相比，它在长文本语义和现成模型权重上更进一步，但标签体系仍然偏基础，企业真正需要的特殊类别数据、行业特定数据和法域差异，仍然需要自己评估和补强。和通用大模型直接做脱敏相比，它更稳定、成本更低、结构保持更好，但它并不替代复杂法律判断。
更长期看，Privacy Filter 代表的可能不是一个单点工具，而是一类 AI-native 合规组件的出现。过去，合规控制常常是系统上线后的制度补丁；现在，合规控制开始变成模型调用链路中的基础层。未来企业的 AI 架构里，很可能会默认存在几类前置组件：隐私过滤、敏感凭证检测、权限校验、数据来源识别、检索结果过滤、输出审计和高风险场景分流。Privacy Filter 只是其中最容易被看见的一层。
七、它适合接在哪里，应该怎么用
Privacy Filter 最适合被理解成一个前置预处理组件，而不是一个法律判断器。
它最典型的接法，是放在下游系统之前。训练语料进入训练或评估流程前，可以先跑一遍过滤；知识库文本进入向量索引或检索增强链路前，可以先把可识别个人信息和敏感凭证处理掉；应用日志、调试日志、链路追踪、工单归档和人工审阅样本被长期保存或跨团队共享前，也可以先做一轮前置筛查。
模型输出的不是“这次处理是否合法”的结论，而是被识别出来的敏感信息片段。组织随后再把这些片段映射成具体动作，比如遮蔽、删改、替换、阻断、分流人工复核，或者直接禁止进入某些链路。运行阈值可以调，领域微调可以做，输出结构也明确，这使它更像一个可接入系统流程的控制点，而不是一个单独存在的实验模型。
八、Privacy Filter 缓解的是哪些法律问题
因此，讨论 Privacy Filter 的法律价值时，要避免两个极端。一种极端是把它看得太轻，认为它不过是一个新的脱敏工具；另一种极端是把它看得太重，仿佛部署之后就能完成匿名化、合法性证明和权利响应。更准确的说法是：它缓解的是数据进入链路之前的暴露面问题，改善的是后续合规证明和治理执行的条件。
它的价值，必须一项项对应回前面提到的法律问题。
第一，它直接服务于数据最小化和设计中的隐私保护。如果组织能够证明，自己不是把整批原始文本原封不动送进模型链路，而是在前置节点尽量剔除了不必要的可识别信息，那么在必要性和相称性层面的论证条件至少会明显改善。
第二，它能减轻后续部署被前端数据问题拖累的压力。如果训练、索引、日志或审阅流程一开始就少进去了很多原始个人信息，那么后面关于模型是否仍可抽取个人数据、是否仍在处理个人数据、后续部署是否继续承接前端瑕疵的问题，至少不会像“原文全量进入”那样尖锐。
第三，它让数据主体权利问题更可治理。这里不能夸大成“有了过滤就解决了删除权”，但如果一开始进入模型相关系统的原始识别信息更少，后续面对访问、更正、删除和限制处理请求时，治理对象会更小，证明负担也可能更可控。
第四，它同时降低了保密性层面的暴露面。敏感凭证标签意味着密码、密钥、访问令牌这类内容也可以被一起拦在入口前。虽然这不等同于数据保护法分析本身，但它会直接影响内部控制、事故暴露面和安全治理成本。
九、企业真正要补的，不是一个模型，而是一组入口控制
如果企业真的要把 Privacy Filter 这类能力落到 AI 系统里，第一步不是“找一个模型部署上去”，而是先梳理哪些文本会进入模型相关链路。用户输入、客服记录、工单、日志、产品需求文档、内部知识库、代码仓库、合同、评测集、RAG 知识库和 agent memory，都是可能的入口。入口不清楚，过滤就会变成零散补丁。
首先，要识别所有可能进入模型链路的文本节点。不同入口的风险并不相同，不能用同一套策略处理。用户输入、客服记录、知识库文本、日志、评测集、人工审阅样本和 agent memory，往往对应不同的暴露面、不同的法律问题和不同的保留逻辑。
其次，要按场景设置不同的过滤策略。训练语料和日志归档通常更偏向高召回率，宁可多删，也要尽量避免原始个人信息进入长期链路；法律文件审阅则需要在召回率和可读性之间平衡，因为过度遮蔽会影响事实判断；密钥、密码、访问令牌这类敏感凭证检测，则应把漏检风险放在更高优先级。
第三，过滤结果不应只对应“替换”一个动作。企业可以根据标签类型和风险等级配置不同处理：遮蔽、删除、令牌化、阻断上传、禁止入库、分流人工复核、触发安全告警，或者只允许在受控环境中继续处理。真正的治理价值来自“识别之后如何处置”，而不是识别本身。
最后，要保留可审计的证据。至少应记录过滤时间、模型版本、阈值配置、命中标签、处理动作、人工复核结果和例外批准记录。否则，即便系统事实上做了过滤，后续面对内部审计、监管问询或事故复盘时，也很难证明当时采取了哪些控制措施。
十、真正要落到的，不是“工具趋势”，而是企业的入口控制
Kimi 风波之后，企业真正需要回答的，已经不是“以后要不要更小心一点”，而是更具体的问题：在任何文本进入模型之前，组织是否已经建立了一道明确的入口控制。
如果没有这道控制，后面的讨论往往都会变得被动。模型是不是还算匿名，前端处理是否污染后端部署，数据主体权利还能不能回应，日志、索引和共享链路里还剩下多少原始识别信息，这些问题都会在事后一起涌上来。到那时，企业面对的就不再是一个产品选择题，而是一组法律、治理和内部控制问题。
也正因为如此，企业不能把 Privacy Filter 简单理解成“自动匿名化”。它更准确的角色，是 AI 数据链路中的入口控制组件。它可以帮助组织在文本进入训练、索引、日志、评估、人工审阅或知识库之前，先识别和处理一部分直接标识符与敏感凭证；但它不能替代合法基础判断，不能证明处理目的相容，不能回答是否需要 DPIA，也不能当然证明数据或模型已经匿名化。
Privacy Filter 的真正价值也正在这里。它不是终局，不是免责证明，也不是把所有风险一键清空的答案。但它至少把一件过去常常只停留在原则层面的事，推进成了一个可以真正接进系统的动作：在文本进入训练、索引、日志和审阅流程之前，先把最不该进去的那部分信息拦下来。
对于今天的企业来说，这种前置动作的意义，并不只是“更安全”或“更规范”。它真正改变的是，组织能不能在风险发生之前，就把一部分最难处理的法律问题压缩掉。
尾注
1. 每日经济新闻，“我的简历竟在大模型上‘裸奔’”！个人隐私为何遭“开盒”式泄露？，2026-04-23，https://www.nbd.com.cn/articles/2026-04-23/4355115.html。本文将该事件作为公开报道的现实入口，而非已被监管或司法最终确认的技术定性。
2. EDPB, EDPB opinion on AI models: GDPR principles support responsible AI, 2024-12-18, https://www.edpb.europa.eu/news/news/2024/edpb-opinion-ai-models-gdpr-principles-support-responsible-ai_en。
3. EDPB, Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models, adopted 2024-12-17, published 2024-12-18, https://www.edpb.europa.eu/our-work-tools/our-documents/opinion-board-art-64/opinion-282024-certain-data-protection-aspects_en。
4. OpenAI, Introducing OpenAI Privacy Filter, 2026-04-22, https://openai.com/index/introducing-openai-privacy-filter/。
5. OpenAI, Model Card for OpenAI Privacy Filter, 2026-04-22, https://cdn.openai.com/pdf/c66281ed-b638-456a-8ce1-97e9f5264a90/OpenAI-Privacy-Filter-Model-Card.pdf。
6. Google Cloud, Sensitive Data Protection documentation, https://cloud.google.com/sensitive-data-protection/docs。
7. Google Cloud, De-identifying sensitive data, https://cloud.google.com/sensitive-data-protection/docs/deidentify-sensitive-data。
8. AWS, DetectPiiEntities - Amazon Comprehend API Reference, https://docs.aws.amazon.com/comprehend/latest/APIReference/API_DetectPiiEntities.html。
9. AWS, Amazon Macie, https://aws.amazon.com/macie/。
10. Microsoft Presidio official site, Presidio: Data Protection and De-identification SDK, https://microsoft.github.io/presidio/。
11. Microsoft Presidio, Text anonymization, https://microsoft.github.io/presidio/text_anonymization/。
12. Microsoft Presidio GitHub repository, https://github.com/microsoft/presidio。
说明：本文件为公众号渲染试稿，建议在浏览器中打开后复制渲染结果，再粘贴到公众号编辑器。