AI辅助整理：本文基于下方列出的公开原始来源改写，不代替原文。
核心摘要： AWS在官方博客中介绍了一套基于大模型的PII（个人可识别信息）检测方案，特点是模型无关、由指令驱动。检测逻辑写在提示词里，后端通过统一接口可切换Amazon Bedrock托管模型或自建GPU上的开源模型。方案在五个公开PII语料、约4.9万条记录、八种语言上评测，九种检测器的核心F1在74.9%至83.1%之间。通过扩展配置增加领域实体定义后，扩展实体F1从约12%提升到约73%，且无需重新训练。
业务背景：训练语料里的个人信息是隐形风险
企业在做模型微调时，训练语料往往来自真实业务文本：客服对话、HR记录、聊天日志。这些文本里天然包含姓名、住址、邮箱、电话、身份证号、银行账号和出生日期。
AWS在原文中指出，用未清洗文本训练的模型可能记住这些数据，并在后续被本不该触发它们的提示词中复现出来，从而泄露真实个人信息。
问题：传统检测工具被“固定标签”锁死
常见的做法是双向token分类模型，每个token在训练时就被固定打上某类标签。问题在于，企业特有的标识类型——比如员工编号或加密钱包地址——恰恰是自定义语料引入的，落在固定标签体系之外。
要新增一类，就得重新标注、重新训练；而且这类工具通常绑定单一模型和单一部署方式，迁移成本高。
AI怎么落地：把检测逻辑写进提示词
方案把大模型当作可配置、可替换的组件。输入文本被包进一段指令，指令里定义要检测的实体类型和输出格式，模型返回结构化的实体列表。
由于检测逻辑完全存在于指令和一层轻量解析中，它与具体模型的特性无关；后端通过统一接口接入，既可以是Amazon Bedrock上的托管模型，也可以是自建GPU上的开源模型，从而覆盖无法访问托管服务的隔离环境。
模型只负责识别文本中的敏感片段并打标签，不负责给出字符位置；位置由后处理用正则表达式在原文中定位，并做去重与标签归一。
实施步骤：四步跑通自有数据
第一步，准备Python 3.11以上环境，安装依赖并配置可调用Amazon Bedrock的凭证与区域。第二步，选择后端模型，托管路径可直接调用，自建路径需提供适配器。第三步，在提示词中定义实体集合，按需增删类别。第四步，把检测出的片段连同精确字符偏移交给脱敏环节，让清洗后的文本进入训练流程。
结果证据与边界
原文给出的评测覆盖五个公开语料、49,365条记录、222,114个核心标注跨度、八种语言。九种检测器的核心F1在74.9%至83.1%之间，其中OpenAI PrivacyFilter为80.7%。
在扩展配置下，扩展实体F1从约12%提升到约73%，核心F1不变或略有提升，且在所有测试模型上都成立。原文同时指出，日期类实体是共同弱项，约50%，因为跨度边界和格式本身存在歧义。
需要说明的是，这些数字来自公开语料评测，并非某家企业的生产结果；原文未披露具体企业客户的使用数据。
可复制动作：先小样本验证再扩实体
建议先用自有语料的小样本跑一遍，观察哪些内容被标记、哪些被漏掉；再按行业特点补充实体定义，例如内部工号、合同编号、门店编号；最后把检测结果接入脱敏流程，并保留人工抽检环节。对数据不能出境的场景，优先选择自建后端。
证据与边界
- 原文称评测覆盖五个公开PII语料、49,365条记录、222,114个核心标注跨度、八种语言。
- 原文称九种检测器核心F1在74.9%至83.1%之间，OpenAI PrivacyFilter为80.7%。
- 原文称扩展配置把扩展实体F1从约12%提升到约73%，核心F1不变或略升。
- 原文称日期类实体是共同弱项，约50%。
企业今天可以做什么
建议企业先用自有语料样本跑一遍检测，观察误报与漏报；再根据行业特点补充实体定义，例如内部工号、合同编号；最后把检测结果接入脱敏环节，让清洗后的文本进入训练或分析流程。对数据不能出境的场景，可选择自建后端。