个人信息保护大概是这两年在技术圈和数据团队里被反复提起的高频词。去年年初我们安全组接了一个硬活儿把之前散落在各业务系统里靠人工审核、正则规则、敏感词库堆出来的隐私保护方案整体替换成一个专门为个人信息保护场景训练的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模型在垂直领域的维护是一个长期过程线上反馈、模型重训、效果验证这三个环节如果转不起来模型效果会随着业务演进而急速退化。我们一直在运营那个“误报标注”快捷入口它现在的存在感不亚于模型本体的价值。做这个项目最大的体会是大模型在个人信息保护领域不是灵丹妙药它解决的是人类理解能力的瓶颈但带来的是工程复杂度和安全边界的增量问题。想清楚业务到底要什么、模型能做多少、规则兜住什么底比追逐更先进的模型结构要紧得多。
