个人信息保护，大概是这两年在技术圈和数据团队里被反复提起的高频词。去年年初，我们安全组接了一个硬活儿：把之前散落在各业务系统里靠人工审核、正则规则、敏感词库堆出来的隐私保护方案，整体替换成一个专门为个人信息保护场景训练的AI大模型助手，内部代号叫“智御”。这个项目做了大半年，上线之后确实把人工审核的工作量降了大半，更重要的是把很多以前根本发现不了的隐性隐私风险挖了出来。今天把整个项目的拆解思路、技术选型、踩坑记录都整理出来，给正在做数据合规建设、隐私工程或者AI安全产品的同学做个参考。
这个“智御”助手是什么？往大了说，它是一个面向个人信息保护场景的垂直AI大模型应用：能自动识别一段文本里的敏感个人信息，按照行业惯例做分级分类；能在不破坏数据可用性的前提下一代完成脱敏改写；还能对一个业务流程的描述做隐私风险评估，输出风险等级和整改建议。往小了说，它就是团队里所有搞数据、搞运营、搞客服的同学都能用的一个质检和风控接口，没什么神秘感，但把每个点做透之后，效果非常直接。
1. 为什么要做“智御”这个AI助手：背景与需求拆解
1.1 传统隐私保护方案为什么越来越吃力
先说说我们之前的状态，可能很多团队都有同感。早期做个人信息保护，靠三样东西：敏感词库、正则表达式、人工抽检。手机号、身份证、银行卡这类强规则字段用正则确实很稳，匹配准确率能跑到99%以上。但是业务跑起来之后，问题很快浮出水面：
第一，数据形式变得太快。现在用户产生的数据大量是非结构化的，比如客服会话记录、用户投诉描述、产品论坛里的反馈帖、甚至语音转写出来的大段文本。这些内容里被提到的个人电话号码经常是“一三六零零零捌捌捌捌”这种变体，地址也不是标准省市县三级结构，而是“南城那边第三个路口进去的红房子”。正则规则在这种内容面前几乎等于裸奔。
第二，上下文理解完全缺位。一段客服聊天记录里，用户说“我的卡号是尾号8823的那张”，单独看“8823”根本不算敏感数据，但是结合上下文它就是银行卡的一个可识别部分。传统方案要么把它漏过去，要么把整段内容都标红，后者会在后续处理时把大量正常信息误伤掉。
第三，人工审核的瓶颈。我们高峰期每个月要过审的日志和工单大概几十万条，安全组一共就四五个人，抽样比例不到百分之几，大量风险其实是在水面以下的。
后来行业里有了比较成熟的外部数据合规审计需求之后，老板就拍板说：能不能搞一个AI助手，让模型帮我们“读”这些非结构化数据，代替人去做理解和判断。这个需求方向是清晰的。
1.2 大模型做个人信息保护的四个切入点
我们梳理了一圈，最终把“智御”的功能范围锁定在四个核心场景上。之所以这么切，是因为每一块都能独立交付价值，又能共享同一套模型底座，迭代节奏比较可控。
第一个是敏感信息识别与分类。不只是把“手机号”“身份证号”这种实体打上标签，还要能理解“这是用户主动提供的”“这是客服人员记录的”“这是第三人提到的他人信息”这层关系。这是后面所有环节的基础。
第二个是智能脱敏与数据最小化。原始数据里识别出了敏感字段之后，不是简单地把中间四位打星号就完事，而是要生成一份“既保留了业务分析价值、又抹掉了个人信息指向性”的替代版本。比如做用户行为分析时，我们需要知道一个用户所在的城市和年龄段，但不需要知道他的精确住址和身份证号，那么脱敏策略就不一样。
第三个是隐私风险评估。这个场景面向的是业务侧提交的新需求文档、第三方合作的数据接口说明、内部数据流转的流程图描述。模型把它们读一遍，输出风险等级、风险点列表、整改建议。以前这个评审流程靠人和经验，现在至少有一个不知疲倦的初审员。
第四个是数据主体权利响应支持。用户在平台提出“删除我的数据”“导出我的数据”这类请求时，模型要从后台全链路数据字典里定位哪些表哪些字段存了跟该用户相关的数据，加速响应的准备工作。这个场景我们只做了数据定位的辅助，没做自动化删除，涉及系统操作层面的东西还是需要人工确认。
2. 技术方案怎么选：架构设计与模型落地的关键决策
2.1 底座选型：自研大模型还是垂直微调
这个问题的标准答案是：能用开源底座微调就别自己从头预训练。我们当时也认真评估过从头训练一个几B参数的专用模型，但算了一笔账之后迅速放弃了：高质量中文隐私语料的收集成本实在太高，预训练阶段需要的数据清洗团队和算力资源也不是我们一个几十人的安全部门能扛的。
最终方案是采用一个十亿参数级别的中英文双语底座模型，在此基础上做指令微调。多说一句，做这个领域，模型参数量的要求不高但精度的要求特别高，所以“小参数+强微调”比“大参数+通用能力”更务实。专业领域任务单一，没必要为一个实体识别类任务背上几百B的推理负载。
选底座的时候我们横向对比了好几个开源模型，重点考量三件事：中文长文本理解能力、对隐私数据的记忆倾向、推理时的显存占用。有些通用模型在代码和数学任务上很强，但对中文口语化表达的理解比较弱，直接淘汰。团队当时在内部搭了一套跑分脚本，用一千条线上线下收集的真实脱敏样本做基准测试，最后选定的底座在识别F1上比第二名高了将近4个点。
2.2 数据管道：敏感信息识别和脱敏是怎么实现的
整个项目最花时间的地方不是模型训练，而是训练数据的构造。我们走的是“小步快跑”的路线，分了三批数据逐步搭建：
第一批是公开语料加规则增强。从网络公开渠道收集了一大批涉及个人信息的文本，再配合正则工具自动生成一批强规则样本。这批数据量最大，但质量参差不齐，主要用来做模型的冷启动预训练。
第二批是半自动标注。我们把业务系统里经过严格脱敏处理的历史工单、客服会话翻出来，用规则加人工抽检的方式打标签。这批数据质量高，但量不大。这里有一个关键心得：标注规范必须精细化到字段级，比如“姓名”要区分“真实姓名”“昵称”“代称”，“地址”要拆到“国家/省/市/区/街道”五级，不然模型学出来就是囫囵吞枣。
第三批是合成数据。用GPT类模型Generative一批“看起来很像真实场景但全部为虚构”的对话、表单和文档，再人工校对。这么做的好处是可以控制数据的难度分布，专门造一些长尾变体给模型“补课”。比如手机号的各种写法、身份证号和银行卡号的混用、地址嵌套在叙述语句里的情况。
数据管道架构上，我们做了一个有点容易被忽略但非常重要的设计：把标签体系和任务体系分了两层。底层是一个统一的PII实体标签体系，包括姓名、证件、联系方式、金融账户、生物特征、位置轨迹等大类大类细分小类；上层才是各种业务任务。这样新业务场景接入时复用底层标签模型，不用担心任务之间互相干扰。
模型训练工程上用的是LoRA微调。全参数微调在十亿参数级别的模型上我们也试过，过拟合现象更明显，且在新增训练数据时需要完全重训，非常不灵活。LoRA可以在单个消费级显卡上把大部分任务训完，每批新数据增量更新只需几十个epoch，团队迭代效率直线提升。
2.3 对齐与评测：模型的“边界感”怎么训练
做个人信息保护模型，有一个跟其他领域很不一样的地方：模型不能太“聪明”。它需要懂得什么该做、什么不该做，还得对自己的能力边界有判断。
举个例子，我们早期版本在识别出隐私风险后，会顺手生成一段“这个数据泄露可能带来的后果”的描述。结果有一次在内部测试时，模型把一段虚构的医疗记录描述成“患者可能遭受歧视性待遇”“社交关系破裂”，措辞严重、夸大危险。虽然本身没有输出错误信息，但这种带有引导性的风险描述既不专业，也容易让业务方产生恐慌情绪，损害产品公信力。
后来我们专门加了一步对齐训练。方式上不是走传统的RLHF，而是选了更轻量的DPO方案，因为DPO不需要单独训练一个奖励模型，工程复杂度低很多。对齐的重点是两个方向：一是“保守优先”，拿不准的识别结果宁可标为“疑似风险”也不要直接下结论；二是“只做本职”，模型只负责识别、脱敏、评分和建议，不能发散到法律咨询、公关话术建议这些超范围领域。
评测体系我们搭了三层：第一层是标准测试集，来自行业公开的隐私识别基准，主要看整体指标；第二层是业务真实样本回测，每月从线上新数据里抽样做标注，防模型退化；第三层是对抗样本集，专门放各种人类都容易看走的刁钻案例，比如“老王的儿子的班主任李老师今天打电话过来了”这种嵌套关系，确保模型的语义理解真的到位。
3. 核心功能与实操过程：从“能用”到“好用”
3.1 功能一：敏感个人信息自动识别与分类
这个功能是模型的最基础能力，也是所有上层功能的地基。输入可以是一段自然语言文本，也可以是一份JSON结构化的用户数据，或者一个导出文件里的某几列，输出是一个结构化的识别结果清单：每个敏感实体的起始位置、实体类型、置信度、上下文说明。
举一个我们实际测试过的原始文本：
“用户张伟（联系电话138xxxx1234）反馈，他和小李在3月14日于朝阳区某商场餐厅消费了382元，当时使用招行尾号8801的信用卡付款，发票需要寄送到北京市朝阳区阜通东大街6号院3号楼802室。”
“智御”的识别输出包括：人名“张伟”、手机号、消费商户语义信息、信用卡的银行名和尾号、家庭地址细分到街道和楼栋室号。其中比较关键的一点是，模型把“小李”也识别为“姓名-代称”而不是漏掉，同时标注了“该实体为叙述中提及的第三方个人信息，需结合业务场景决定处理方式”。这就是纯正则方案做不到的语义级识别。
这个功能的实际落地方式是做成一个HTTP接口，内部系统把文件内容或者数据库字段灌进来，返回标注结果。我们在工程上做了一层后处理：当模型置信度低于阈值时，再叠加规则引擎复核，规则引擎的优先级高于模型，避免模型“带偏”了强规则字段。
3.2 功能二：智能脱敏与最小化原则落地
脱敏功能在交互上分两种模式：标准模式和自定义模式。
标准模式适合大多数场景：识别出的手机号统一变为“138****1234”，身份证保留前三位后四位，银行卡保留尾号，住址自动泛化到区级。这套规则是跟业务方反复拉锯之后定下来的，因为从安全角度当然希望脱得越狠越好，但业务分析那边会叫苦“我都不知道用户是哪个城市的怎么做地域分析”。最终砍下来一条原则：能满足业务分析的最小粒度数据保留，其余一律抹掉。
自定义模式就灵活多了。用户可以指定某个字段的处理策略是“保留”“替换”还是“泛化”，比如替换成一个合成的假手机号（号码格式真实但是虚构），这样下游测试环境可以直接使用，不会污染数据。
很多团队的脱敏方案还是用正则做替换，我们为什么用模型做生成式脱敏？一个非常典型的差异场景是：一句话里既包含敏感信息又包含重要的业务描述，比如“张伟的订单是3月14号下的，但他坚持说收货地址就是北京朝阳区阜通东大街6号院3号楼802室”。如果按照字段级规则处理，地址被整段脱敏，业务描述就全丢了。模型可以在理解语义之后输出“用户订单日期为3月14日，收货地址为北京市朝阳区（具体楼栋信息已脱敏）”。这就是生成式脱敏的意义：它在保护个人信息的同时，努力保留原句的表达意图和信息结构。
当然模型脱敏也有自己的风险，后面在问题章节里会说。
3.3 功能三：隐私风险场景的主动预警
第三个功能做的是风险评估。我们在内部搞了一个“风险雷达”，输入可以是产品需求文档的某段描述，或一条数据接口的调用说明。模型按照我们预设的风险维度做评分：数据采集必要性、数据留存期限合理性、第三方共享可见性、用户授权明确性等。
每个维度输出低/中/高三档结论，并给出依据文本中的哪些表述。这个环节最重要的不是结论本身，而是“依据的抽取”。我们要求模型在给出风险判定时一定要引用原文出处，否则风控人员没法做复核。这样做还有个好处，可以过滤掉模型的“幻觉式结论”。
比如业务方提了一个需求：“为了提升用户体验，需要采集用户的常驻地址、设备型号、通讯录前三位联系人信息。” 风险雷达会摘出“通讯录前三位联系人”这句话，标记采集必要性为“中风险”，备注“涉及第三人个人信息，需确认是否获得授权”。这些都是以前要专员人工读文档才能发现的问题。
3.4 部署实录：从微调完成到线上服务化的几步
整个模型服务的上线推进，我们把它拆成了几个阶段：
第一步是集中微调。用前面说的三批数据在GPU云主机上跑LoRA微调，一个任务大概8到12小时出结果。训练完先用测试集验证指标，再用对抗样本集做人工抽验，两项都过了才允许进入下一步。
第二步是服务化封装。我们用高性能推理框架做模型加载，对外提供HTTP接口，单卡并发大概能到几十路。推理峰值延迟控制在1秒以内，这个量级对异步审核任务来说足够了。完全不追求毫秒级延迟，因为场景是离线质检和半实时合规审核为主。
第三步是灰度上线。选择两个业务量较小、但数据类型覆盖较全的渠道先跑两周，把模型输出跟人工审核结果做对比。同时保留旧规则引擎作为兜底，双路并行，任何一路判定为高风险，数据就会被拦下来进人工队列。
第四步是全量推广。把接口权限开放给运营、数据、客服三个团队，并搭了一个简单的可视化报表，每周自动统计识别量、风险分布、脱敏成功率。这个报表后来成为跟老板汇报项目价值最有力的素材。
4. 踩过的坑与排查实录：真实项目中的问题清单
4.1 误报率高到让人怀疑人生：长尾数据识别难题
“智御”刚开始内部测试时，敏感信息识别准确率其实没有想象中高。有一次我们拿客服工单数据做回测，发现“地址”类别的误报率高达20%，也就是说每五条识别出来的地址里就有一条是错的。
排查之后发现症结在于长尾变体。比如“梅花园小区南门对过麻辣烫店旁边二楼”这种口语化地址，模型要么识别不全，要么把“麻辣烫店”这种非地址信息也框进来。后面解决分了两步：第一步扩充数据，专门构造了一大批口语化地址变体的合成数据，覆盖各种“小区+地标+方位+楼层”的组合；第二步是给模型加了“地址完整度”的后校验规则，如果识别出来的地址片段里既没有明确行政区划级别信息也没有具体楼栋描述，就降级为“疑似地址”，而不是直接判定为高风险字段。
这个调整几乎花掉了我们整整一周的时间，但效果非常显著，地址误报率从20%降到了6%以内。
4.2 脱敏后数据可用性下降：安全与业务的拉锯
模型刚上线时，我们按照安全团队最理想的标准执行脱敏：凡是能关联到个人的字段全部脱掉。结果数据平台那边炸了锅：用户生命周期分析跑出来的报表跟以前对不上，很多运营指标出现跳变，因为“用户所在城市”被泛化掉之后，地域维度直接不可用。
后来我们坐下来重新梳理每个下游任务真正需要的最小数据粒度。最终定了个用户画像优化方案里面必须保留到城市级、用户行为分析只需要保留年龄段、信用风险评估干脆不能碰原始数据只能接收评分结果。脱敏规则表从安全团队单方面制定，改成了安全、数据、业务三方联合评审，每季度review一次。这个问题本质上不是技术问题，而是流程设计问题，模型只是把这个问题从“看不见”变成“看得见”了。
4.3 模型幻觉引入的新风险：AI自己“编”出隐私风险
这个是所有AI辅助工具都会遇到的老大难。我们曾经遇到过模型把一段完全是虚构产品文案里的“某小区楼盘营销广告”识别成“地址泄露”，理由是文案里包含了楼盘的详细位置。从单纯实体识别角度看它没错，但从风险管理角度这个判定会把大量正常营销内容拖进敏感流程。
更让人哭笑不得的是，有一次模型在风险解释里写“该用户可能因为本次事件遭受到重大财产损失”，但我们输入的那段文本里压根没有涉及任何交易信息。这就触及了之前提到的边界感对齐问题。
解决办法是多管齐下：一是限制模型输出的风险描述必须基于原文引用的实体和上下文，禁止发散性后果推测；二是加入低置信度拒绝机制，模型对单条数据拿不准时直接返回“疑似风险，请人工复核”，不再自动生成解释；三是运营后台加了一个“误报标注”按钮，业务同学可以把模型的错误判断一键反馈上来，这些反馈会进入下一轮微调训练集，形成闭环。
4.4 性能和成本的拉锯战
十亿参数的模型推理一次虽然不贵，但每天的调用量从几百次涨到几万次之后，算力账单就开始触目惊心了。我们两个优化思路，实测下来都有用。
第一是输入裁剪。很多业务场景输入的文本长度远远超过实际需要的段落，比如客服系统会把整个会话历史都传进来。我们做了一个“敏感区域预筛”的前置轻量模型，先用规则和关键词把最可能有敏感信息的段落筛出来，只把这些片段喂给大模型做深度识别。不要小看这个前置过滤，平均能砍掉40%的无效输入。
第二是任务合并。原本敏感识别、脱敏、风险评分分三个接口三次调用，后来我们在内部逻辑层合并成一次调用，模型一次性输出结构化结果，整体推理开销降了接近一半。合并之后对接口的复杂度做了一些妥协，但对内部工具来说完全值得。
成本和安全永远不可能同时做到最优，更务实的思路是让有限的大模型推理资源用在最需要理解能力的地方，简单任务继续交给规则引擎去做。
5. 这个项目后续还可以如何扩展
项目上线稳定跑了一个季度之后，我们开始想下一步的事情。目前“智御”处理的主要是文本和非结构化数据，但个人信息保护的对象远不止这些——图片里的身份证拍照件、表格文件里的批量数据、甚至语音记录里的身份信息，都是正在逼近的下一波需求。
我们目前已经在做图片OCR加实体识别的原形验证，思路是把检测模型做文本抽取，之后接“智御”的语义识别。另外一个方向是把它从“审核员”变成“咨询师”，让业务人员在产品设计阶段就能直接提问“我这个功能需要收集哪些数据，有哪些隐私风险”，让合规介入的时间点从上线前测试提前到需求评审阶段。
还有一个小建议给准备复制这条路线的人：一定要尽早设计反馈闭环。AI模型在垂直领域的维护是一个长期过程，线上反馈、模型重训、效果验证这三个环节如果转不起来，模型效果会随着业务演进而急速退化。我们一直在运营那个“误报标注”快捷入口，它现在的存在感不亚于模型本体的价值。
做这个项目最大的体会是：大模型在个人信息保护领域不是灵丹妙药，它解决的是人类理解能力的瓶颈，但带来的是工程复杂度和安全边界的增量问题。想清楚业务到底要什么、模型能做多少、规则兜住什么底，比追逐更先进的模型结构要紧得多。
