AI 大模型能不能用个人数据来训练一直是做 AI 应用开发的人最纠结的问题之一。韩国最近通过《个人信息保护法》修正案方向是允许 AI 开发在满足条件的情况下使用个人数据。这个消息值得做模型微调、AI Agent、智能客服、内容生成产品的团队认真看一遍它不是说个人数据从此可以随便抓而是把“能不能用”这个问题真正拆成了“怎么用才合规”。下面不打算逐条解读法律条文。对大多数开发者来说更关键的是把这次修法当作一个信号把个人数据合规从法务文档搬到数据管道、训练流程和模型上线检查里。我会按照一条数据从采集、清洗、训练、评估到上线的实际路径来讲。你可以把它当一份内部自查清单也可以直接拿去做团队培训的底稿。1. 先看清这次修法会影响 AI 开发流程里的哪些部分1.1 受影响的不只是大模型训练还有微调和 RAG提到“用个人数据训练 AI”很多人第一反应是从头训练一个大模型比如自己搭一个 GPT。这类工作确实存在但绝大多数团队不会做这件事。大家更多是在做开源模型微调、知识库问答、AI Agent 和 RAG 应用。RAG 是很容易被忽略的重灾区。举个例子一个智能客服系统想把历史工单作为知识库工单里通常有用户姓名、手机号、订单信息和具体抱怨内容。如果直接把工单文本切块、向量化、存到向量数据库那么从数据进入检索链路开始就已经构成了对个人数据的使用。哪怕最终生成回复时模型只是参考了片段也没有改变这个事实。所以这次修法真正影响的不是“要不要自研模型”而是任何接触真实用户数据的 AI 系统都要重新评估自己的数据处理逻辑。包括微调数据、知识库、对话日志、埋点事件甚至 system prompt 里硬编码的用户画像字段。只要数据链路里有个人标识就需要纳入合规管理。我见过一些团队模型精度做得不错但知识库里的文档是从 CRM 系统直接导出的里面全是客户姓名和联系方式。他们当时觉得“只是内部用不上对外产品”结果内部演示阶段就出了问题。合规不是上线那一刻才开始的数据进管道的那一刻就已经开始了。1.2 哪些角色需要调整工作方式这件事不是法务一个部门能扛下来的。按我过去的项目经验算法工程师、数据工程师、产品经理和运维都要动。算法工程师要回答训练数据从哪里来来源是否合法字段里是否包含个人标识。数据工程师要回答清洗和脱敏做到什么程度有没有保留原始数据访问权限是谁开的。产品经理要回答这个产品功能是不是真的需要真实个人数据默认设置是否过于激进。运维要回答日志放在哪里能保留多久谁能看到。任何一个环节缺失都可能让前面的合规工作白做。比如算法部门辛苦做了匿名化但数据工程还在往临时表里写明文或者产品上线时把脱敏开关关掉。这类问题我见过很多次原因不是某个人不上心而是职责没有落到对应角色上。建议团队里指定一个“数据守门人”。不需要是法务最好是数据工程师或技术负责人负责维护数据来源清单、字段分级表和处理记录。所有新的数据接入都要经过这个人确认。这个角色长期看会很有价值。1.3 先确认一个边界公开数据不等于可以直接用另一个容易误判的地方是“公开数据”。很多团队会爬公开网页、公开评论、开源数据集来造训练集觉得既然公开了就应该可以随便用。这个边界需要谨慎。公开内容里如果包含姓名、手机号、住址、工作单位等字段即使对方自己发在公开平台上你也不能默认可以拿去训练模型。修正案允许 AI 开发使用个人数据但通常不是“无差别允许”而是有合法性前提的。我的建议是哪怕是公开数据集也先做来源和字段审计。记录数据是什么时候拿的、原始出处是哪里、有没有附带使用条款、字段里是否有明显个人标识。这个审计记录不需要很复杂但必须存在。以后如果被问到数据来源至少能拿得出记录而不是说“从网上下载的”。还要注意“公开”和“已授权”是两个概念。一个论坛用户公开发布了自己的照片不代表他授权别人用这张照片训练人脸模型。即便不涉及生物识别把公开社交内容批量抓取后用于模型训练在用户预期上也会有很大偏差。2. 个人数据进管道之前先完成分级、裁剪和授权2.1 数据分级不要一个策略套所有字段个人数据不是一个统一概念。身份证号、手机号、姓名、性别、出生日期、设备 ID、IP 地址、行为轨迹敏感程度完全不同。如果用一个策略处理所有字段要么过度防护影响效率要么防护不足留下漏洞。我建议先做一张字段分级表级别示例字段处理思路直接标识姓名、手机号、身份证号、详细地址默认不进入训练集确需使用必须先脱敏或假名化间接标识性别、出生日期、职业、邮编、IP可尝试替换、泛化、降低精度敏感数据医疗健康、金融账户、生物识别、精确位置默认禁止采集除非有明确业务必要和法律依据非个人信息脱敏后的统计值、匿名聚合数据按普通数据处理这里有一个判断标准当一个字段单独或组合起来能够识别到具体个人时就要按个人信息处理。不要只看字段名。直接把手机号叫成“contact_id”它仍然是直接标识符只是换了个马甲。分级表不是静态的。同一个字段在不同业务场景下敏感度可能不同。比如城市信息做旅游推荐时可能不算敏感但结合生日和职业就可能缩小到具体个人。所以分级表要定期更新尤其是在上线新业务线或新模型时。2.2 最小化采集和目的限定第二步是给每个字段做三连问这个字段和模型能力有没有直接关系去掉之后效果会掉多少有没有替代字段如果三个问题里有两个答不上来这个字段就不该进管道。很多人担心去掉字段会影响模型效果。这个担心可以理解但最好的办法不是提前焦虑而是跑一组小实验。先保留最核心的字段训练一版再逐步增加字段观察指标变化。大多数场景下模型真正依赖的特征远没有想象中那么多。最小化采集是唯一不会和任何法律冲突的做法。即使没有这次修法把它列进研发流程也只会带来好处数据量更小训练更快存储成本更低隐私风险更小。我甚至会把“能否删除这个字段”作为数据评审的固定问题。答不上来的字段先不放进去。2.3 合法基础与同意机制如果确实需要真实个人数据那就要回到合法基础层面。不同国家的法律框架不完全一样但通常绕不开这几个方向用户明确同意、合同履行所必需、法定职责、合法利益等。对 AI 训练来说最稳妥的是“明确告知 单独同意”。用户能理解自己的数据被用来改进模型而不是简单藏在隐私政策里一行小字。工程上要做的是把同意记录落在系统里什么时候告知的、用户看到的是哪个版本、同意 ID 是什么、以后怎么撤回。这块经常被认为只和前端交互有关其实后端也要配合。如果用户在界面上撤回了授权但你的数据管道仍然在凌晨批量跑训练任务那合规闭环就是断的。所以不建议把用户授权管理做成一个静态表单要让它成为数据管道的输入条件。注意这里的合法基础说明是通用实践不代表法律意见。具体落地请以当地法规和官方指南为准。3. 把合规检查做进数据管道而不是写在文档里3.1 数据入库前检查清单很多团队的问题是规则写在文档里但代码没有执行。要改变这种情况最好把合规检查变成一个可执行的清单放在数据进入管道的入口处。我建议至少包含以下字段数据来源、授权记录、采集时间、字段清单、敏感级别、脱敏状态、保留期限、负责人。每一条数据或者每一个批次数据都要能回答出来。听起来繁琐但对 AI 项目来说数据来源不明比数据质量差更麻烦。可以通过一个简表在团队内部流转检查项要求结果数据来源有明确出处和采集记录未通过则不入库授权记录有用户告知和同意记录未通过则不入库字段清单与业务目的匹配无多余字段多余字段先删除敏感级别已做字段分级无分级则挂起脱敏状态直接标识已处理未脱敏则拒绝入库这张表的价值不是审批本身而是让数据在进入模型之前就有了审计线索。以后出了问题你能定位到具体批次、具体负责人而不是在几万个文件里盲查。执行时不要只做线下表格最好在数据接入脚本里加一道自动化校验。比如检查 CSV 表头是否包含手机号字段如果包含且没有脱敏标记就直接阻断入库。人工检查会漏自动化检查不会。3.2 训练环境、开发环境、生产环境要隔离个人数据最怕的是环境混用。一个团队里有人负责训练模型有人负责跑推理还有人负责调接口。如果所有环境都连着同一个数据库那权限边界基本等于没有。更合理的方式是分开原始数据只保存在受控的数据存储里模型开发环境只读取脱敏后的副本生产环境只通过接口访问必要的数据。权限按角色最小化分配不要因为“都在一个办公室”就把数据库账号给所有人。如果你担心环境隔离增加成本可以先从“数据访问申请 审计日志”开始。至少每一笔数据读取都能追溯到人和时间。隔离不是目的可控才是目的。这里还要提醒一个细节个人开发机的本地副本问题。即使你从数据库层做了权限控制算法工程师为了调优可能会把一份数据导出到本地 CSV然后文件夹一直留在笔记本上。这个问题很常见需要在团队规范里明确本地禁止保存包含直接标识的数据文件确需保存的要加密并限期删除。3.3 数据保留、删除和回收个人数据不用了要删这是常识。但 AI 项目的“删除”比普通业务系统复杂。第一层是原始文件和数据库记录这个相对容易。第二层是派生数据比如清洗后的 CSV、切好的训练样本、向量数据库里的 embedding。很多人只删了第一层忘了第二层。第三层是模型本身。如果模型已经学习了敏感信息哪怕你把训练数据全删了模型仍然可能被诱导输出这些信息。所以建议提前规划版本生命周期模型训练完成并评估通过后旧基线版本要不要继续保留训练中间产物可以删掉哪些如果用户要求删除数据是否有机制能确认对应训练版本的状态这些问题越早设计越好等到上线后才处理会非常被动。可以给每个数据批次设置保留期限。到期后自动进入复核流程没有业务必要就删除。不要相信“以后可能有用”这种理由。真到有用的那一天重新采集也比处理一个不可控的旧数据集省心。4. 降低个人信息风险先分清技术手段的边界4.1 匿名化和假名化效果差异要清楚“匿名化”这个词被用得太随便了。很多团队以为把姓名换成“用户A”就是匿名化实际上这通常只是假名化。假名化是把身份证号、手机号等直接标识替换成映射后的编码表面上不带原值但如果你还保留映射表那数据依然具备重识别可能。匿名化则要求无法再通过数据本身识别到个人甚至结合外部信息也做不到。这个标准很高现实中完全匿名化的数据并不容易达到。对训练场景来说一个比较务实的做法是先做假名化把直接标识替换掉再做字段裁剪去掉不必要的间接标识最后做噪声或泛化比如把精确年龄改成年龄段、把精确地址改成城市级别。每个处理步骤都要写进数据管道的处理记录。判断标准也很直接处理后的数据在结合性别、年龄、职业、地区等信息后能不能合理识别到具体个人。如果能就不能称为匿名化。不要只看表面字段。4.2 差分隐私、联邦学习、数据脱敏怎么选现在介绍几个常见技术手段各有适用阶段技术适用阶段优点限制数据脱敏采集和清洗阶段实现简单效果直观需要识别字段语义可能损失信息假名化数据入库阶段保留数据结构便于分析有重识别风险差分隐私训练和统计阶段对隐私有较严格保护需要调噪声预算训练效果可能下降联邦学习多节点协作场景原始数据不出本地通信成本高不适合所有模型结构这里给一个忠告不要为了堆概念而用这些技术。如果你的团队只有三五个人并且数据量不大先把数据脱敏和权限审计做好效果可能比硬上联邦学习更好。技术是给业务目标服务的不是写在方案评审里好看的。选择技术时还要考虑团队能力。差分隐私需要对噪声预算、模型收敛、评测指标都有理解否则很容易把模型效果调坏。联邦学习则要处理网络通信、节点异构、聚合方式等问题人力成本不低。小团队可以先从简单的字段裁剪和泛化入手。4.3 模型输出的个人信息泄露风险训练数据一旦被模型学会问题就不只停留在训练阶段还会出现在推理阶段。这就是为什么很多大模型会被“套话”套出手机号、邮箱甚至详细地址。模型本质上不是背书它是在做概率生成但敏感文本片段会被记住并复现。我一般把这类问题分成两层看。第一层是训练阶段数据去重和过滤把明显包含个人信息的文本剔除或脱敏。第二层是推理阶段输出防护比如做关键词黑名单、实体识别、重复次数限制。还可以准备一组专门的“隐私探测用例”用包含已知姓名的样本去试模型看它能不能被诱导输出。这里顺带提一下 AI 幻觉。幻觉可能是模型自己编造信息但编造也可能基于训练样本的残留记忆。所以不要假设“模型编出来不是真实数据所以没关系”。实际可能是它把几个人的信息拼接在一起这种输出杀伤力更大。在验收模型时不能只看业务指标。如果模型在客服场景中会把“用户收货地址”自动补全到回复里即使准确率再高也不能上线。隐私类风险要设置成一票否决项。提示上线前务必把“隐私探测”加入评测集。它和准确率、召回率一样重要只是经常被漏掉。5. 上线前后怎么验证、探测和排查5.1 训练前验证先跑小规模数据个人数据处理流程再完善第一次训练时也不要直接灌全量数据。我会建议先取一小批样例跑完整流程验证数据格式、编码、脱敏结果、token 数量、样本质量都正常然后再批量执行。这一步的价值在出现问题时特别明显。如果样本太小导致训练崩了你能快速定位是不是数据处理问题如果按批量跑一半才发现格式错误排查成本会大很多。这跟做模型评测一样先看单条再看批量不要跳过中间步骤。如果任务卡住不要一上来就调学习率、改 batch size。先看日志里报的是什么错误再确认输入数据路径、文件权限、依赖版本和输出目录。大部分“训练失败”都是环境问题真实模型问题反而少。小规模验证的另一个好处是可以顺手检查脱敏效果。挑几条脱敏后的样本人工确认是否还能从字段组合推断出个人身份。这一步看起来很原始但非常有效。5.2 上线前做“个人信息泄露探测”除了常规的准确率、效果评估建议再加一组探测用例。比如准备好一个样本其中包含“张三手机号 138xxxx”。训练或微调之后在推理阶段问模型“请给出张三的手机号。”看它能不能输出。多试几种问法直接问、换个角色问、用补全的方式问。探测结果如果出现完整手机号那这个模型就不能直接上线。不是所有团队都有精力做完整对抗测试但至少可以做最基础的字段匹配检测。把一个固定的测试集合加入自动化评测每次模型更新都跑一遍成本不高收益很直接。要特别注意“白名单式”测试不够。只能测出已知样本测不出训练集中的其他敏感内容。更好的做法是准备一批随机化模板随机生成姓名、手机号、地址组合再让模型补全。如果模型不依赖特定训练样本也能大量输出虚构但完整的个人信息说明它对信息边界理解有问题。5.3 排查链路先数据来源再处理链路后输出假设用户或监管问到一个问题“你们是不是用了我的个人信息训练模型”这时候不能靠猜也不能只靠法务解释。要有一套排查链路。我的排查顺序是先定位数据来源确认它是否进入过我们的平台再看处理链路日志确认清洗、脱敏、访问记录都存在然后检查模型版本看训练集是否包含该数据最后检查输出看是否有个人信息被生成出来。如果前三步都正常但模型确实输出了那问题多半出在数据去重和过滤不彻底。如果第二步日志缺失那说明流程本身有漏洞即使这次没出事也要先补日志。这条链路能不能跑通取决于之前有没有记录。如果一开始没有做数据来源登记那定位问题基本只能靠猜。这也是我在第 3 章强调检查清单的原因不是为了开评审会是为了出问题时能追溯。6. 从第一张数据流向图开始逐步建立内部机制6.1 先用一张图找出个人数据的集中节点先说结论不要把这件事想成建设一个庞大的合规平台。对中小团队来说最划算的方式是先画一张数据流向图。图上标注清楚数据从哪来经过哪些系统谁在处理谁在访问最后落到哪个模型或应用。画完这张图你通常会发现个人数据实际上只集中在少数几个节点。接下来只需要在关键节点加上检查和审批再配合脱敏和日志就能覆盖大部分风险。画图时不要只画“正常流程”。还要把异常路径画出来比如模型调试时有人绕过接口直接查数据库测试环境使用生产数据离职员工带走过本地副本。这些异常路径才是风险真正藏身的地方。6.2 选择一个最小业务场景做完整试点然后找一个最小业务场景试点。比如先做一个智能客服项目从数据采集、脱敏、审批、训练、上线、输出检查完整走一遍。跑通之后把经验复制到其他项目。不要一开始就想着上全套数据治理平台很多团队就是因为过度设计最后连第一期计划都完不成。试点时建议设一个明确目标在一个迭代周期内把数据流向图、字段分级表、入库检查清单、训练日志、输出探测五样东西全部落地。不需要完美但都要存在。这五样东西只要齐全后续扩到多模型、多业务线时基本不需要推倒重来。试点结束后做一次复盘重点看两个问题哪些检查项是真正挡住过问题的哪些只是增加流程负担。把没有价值的检查项精简掉保留有价值的形成一套轻量规则。6.3 政策变化时不要照搬按市场差异评估韩国这次修法在新闻里只传达了一个方向真正的适用条件、排除条款、技术标准大概率要等官方指南和解释。其他国家和地区也一直在调整 AI 和个人数据之间的关系。所以我的经验是不要把一个地区的政策直接照搬到另一个地区。部署在哪个市场就要以哪个市场的法规为准。每到一个新市场先做一次数据合规差距分析再决定训练数据、系统部署和功能设计。如果你不是法务遇到不确定的地方也要留好“咨询外部法律意见”的预算。这个费用比起数据泄露或违规使用带来的影响通常划算得多。不要只在出问题时才找律师项目启动前和上线前各做一次快速审查更省心。6.4 留几句可以直接抄进团队的检查经验最后说几条我自己反复使用的检查经验第一不要以为合规文档做完了就结束了。代码、配置、页面文案和文档要同步更新否则文档只是摆设。第二默认配置要保守。新项目默认不采集明文手机号默认脱敏默认关闭不必要的日志输出等业务确实需要时再单独申请放开。第三用户真正的删除权要能落到执行。不要只做前端提示后端要有关联删除或不可逆脱敏的机制。第四使用 AI 编程工具时也要注意公司内部代码和数据边界不要把未脱敏的数据直接交给外部服务。很多人只顾着大模型数据训练合规忽略了内部 AI 辅助工具同样会带走数据。我个人的建议是这次修法对 AI 应用开发者来说关键不在一句“允许”而在于把“可以做什么”“不能做什么”“做了之后怎么证明”三件事落到日常开发流程里。先把数据流向画清楚把最小化、脱敏、日志、输出探测这四件事做扎实之后的规模化就不需要推倒重来。