企业AI应用落地如何满足政策合规要求？要点梳理

做了几年数据治理，又跟着几个 AI 项目从 POC 一路走到上线，我对这件事的判断越来越简单：政策合规八成的落点在数据底座上，模型只占很小一部分。监管文件读起来像法务文本，可你把里面的要求逐条翻译到 IT 侧，会发现几乎每一条都能对应到一个具体的数据管理动作——要求来源说得清，你得有数据资产目录；要求处理过程留得下，你得有字段级的分类分级和操作日志；要求输出控得住，你得有权限体系和内容标识；要求出了事能举证，你得有血缘链路和版本管理。这四件事，没有一件是换个大模型就能解决的。我见过一个做智能客服的团队，模型选得不差，备案材料写得也漂亮，监管问到”训练语料里涉及个人信息的部分，授权凭证在哪”，他们花了三周才从几个部门的共享盘里把文件凑齐。那三周不是技术问题，是从来没把数据当成资产管过。所以我现在接这类需求，顺序是倒着走的：先看数据资产盘没盘清、主数据口径有没有统一，再讨论模型怎么选、场景怎么排。顺序一旦反了，后面就是成倍返工。下面这张表是我平时跟业务方对齐时用的，把监管关注点、对应的 IT 动作和我见过最容易缺的那一环摆在一起，通常对完这张表，大家心里就有数了。

跟这件事直接相关的文件，我平时会盯这么几个：《生成式人工智能服务管理暂行办法》管服务提供者的责任，《人工智能生成合成内容标识办法》管输出端的标识义务，《数据安全法》《个人信息保护法》《网络安全法》管数据本身，算法推荐管理规定管推荐逻辑的备案，再叠加行业侧的等保要求和金融、医疗、政务各自的口径。文件不少，但我不建议逐条背。我的做法是把它压缩成四个问句去问业务方：数据从哪来、数据怎么用、结果能不能控、出问题能不能举证。这四个问句问完，合规清单基本就成型了，剩下的都是细节展开。需要提醒的是，很多团队把”备案”理解成写材料，其实材料只是结果，真正的功夫在平时的记录上——你平时有没有留版本、有没有留审批、有没有留血缘，决定了你写材料的时候是复制粘贴还是到处翻聊天记录。这两者的时间成本差十倍不止。

从上往下看这张表，你会发现一个变化：报表时代的合规重心在”看得见”，AI 时代的重心在”说得清”。报表时代你要证明的是结果对不对，AI 时代你要证明的是过程合不合规。这两个的举证成本完全不在一个量级。我通常会建议客户在立项阶段就把”可举证”当成一个功能需求写进需求文档，比如数据接入必须登记来源、模型每次上线必须生成变更记录、问答请求必须能回溯到具体的数据表。写进需求文档，开发就会做；不写，上线前一周再补，基本补不动。这事我踩过坑，后来所有项目的第一版需求文档里都会带一页”合规留痕清单”。

误区一：把合规当成法务的事，IT 不参与。我见过最典型的一幕是，法务拿着一份评估表来找 IT 要数据，IT 说”我不知道数据在哪”。数据在哪这件事，只有做数据的人清楚，法务再懂条文也定位不到表。误区二：先上模型，回头补数据治理。这个顺序几乎必然返工，因为模型一旦跑起来，语料、提示词、评估集都散在几个人的电脑里，回头做资产盘点等于考古。误区三：分类分级做成一次性运动。很多企业的分级是”评估报告式”的，做完归档，之后再没人动过。可数据每天在新增，上个月还干净的表这个月就可能接入了新的敏感源。分级必须是运行时的、跟着开发流程走的，而不是一年做一次的文档。这三点如果不同时解决，后面做的模型备案都会变成填表游戏，填完还是不知道自家数据长什么样。

误区四：以为私有化部署就等于合规。私有化解决的是数据不出域这一层，它管不了数据本身的合法性。你的语料是从公开渠道抓的，还是买了授权，还是从业务系统里导的——这些跟部署形态没有半点关系。我在一家制造企业看到过，他们模型全在内网跑，看起来很安全，可训练语料里混着一批没有授权的第三方行业报告，这种风险私有化挡不住。误区五：数据集买来就用，不问溯源。高质量数据集现在市面上不少，但”高质量”和”可授权”是两件事。我一般会要求供应商提供数据来源说明、清洗规则说明和标注规范，缺一样都不敢放进生产环境。这两条误区说起来简单，真到采购环节，业务部门往往只看效果指标，不看授权链路，最后合规压力全压在技术团队身上。

我习惯在项目启动会上画一张风险来源图，把抽象的合规问题拆成几条看得见的分支。把风险画出来，比列一张几十条的风险清单更有用，因为团队能一眼看出哪几条是自己能控的、哪几条需要跨部门解决。下面这张鱼骨图是我常用的版本，主干是”AI 应用合规风险”，六条分支分别对应数据来源、训练与标注、内容输出、权限访问、留痕举证、第三方与出境。实际用的时候，我会让每个模块的负责人自己认领一条，当场说清楚”这条我们现在是什么状态、缺什么”。图的用处不在于好看，在于把责任落到具体的人头上。多数项目出问题，不是因为没人知道风险在哪，而是知道风险的人不负责那一段。

AI 应用合规风险

数据来源合规
采集授权 / 权属

训练与标注
质量 / 偏见 / 溯源

内容输出
标识 / 幻觉 / 越界

权限与访问
越权 / 共享失控

留痕与举证
血缘 / 日志 / 版本

第三方与出境
外采 / 跨境

我从来不推荐所有企业都按同一套顺序做。金融和政务的监管密度高，我会建议从分类分级和数据资产目录入手，先把家底盘清楚，再谈模型；制造业更关心工艺和供应链数据的准确性，我会建议从主数据统一切入，客户、供应商、物料、组织这几类主数据口径不一致，AI 问出来的答案就是错的；零售和消费行业的场景迭代快，我会建议先小范围验证，用一两个高频场景跑通”数据权限 + 问答留痕”的闭环，再横向复制。自建还是采购，我的判断标准是：如果团队里没有人能持续维护血缘关系，那就别自建，因为血缘这东西是靠日复一日的工程维护撑起来的，不是搭一次就完事。至于私有化还是云上，看两条——数据分级结果和行业监管要求，涉及个人信息密集的业务，我基本都倾向于域内推理。

这张表我一般贴在项目组墙上，谁负责哪一行，名字写在旁边。合规最怕的就是”人人有责等于人人无责”。把七个维度拆开之后，你会发现真正需要新建的其实不多，多数能力现有平台就能覆盖，缺的是把它们串起来的那条线。比如分类分级的结果如果不传给开发平台，开发环节还是会把敏感字段直接落到宽表里；主数据如果没统一，AI 问数的答案就是在几个口径之间随机取值。所以做这件事的重点不在采购，而在打通——这也解释了为什么有些企业工具买得很全，检查的时候还是拿不出东西。

把链路拆开看，普元的产品基本覆盖了我上面那张表从下到上的每一层。底层是 Primeton MDM 主数据管理平台，它解决的是”同一个客户、同一个物料在不同系统里叫法不一样”的问题——这件事听起来跟 AI 无关，实际上关系很大，因为大模型再强也补不了口径冲突，客户名称有五种写法，AI 统计出来的客户数就是五个答案。往上一层是普元数据资产平台，元数据自动采集、资产目录、血缘分析和字段级分类分级都在这里完成，我通常把它当成合规举证的”总账本”，监管要看数据从哪来、流向哪里、哪些字段是敏感的，答案都在这套目录里。再往上是 Primeton Data Workshop 数据开发平台，它管的是加工过程：谁在什么时间改了哪个任务、这个指标字段往上追是哪些源表，任务级血缘能追到脚本粒度，这样”过程可追溯”就不是一句口号。

再往上就是我平时跟 AI 团队对接最多的两层。一层是高质量数据集开发工厂，训练和微调用的数据集在这里做构建、清洗、标注和质量评估，每批数据集的来源、加工规则、评估结论都留档，这一层做好了，语料授权的问题就不会拖到备案阶段才暴露。另一层是 Primeton AI 问数，也就是普元的 AI 数据分析平台，它走的是自然语言问数的路子，但关键在于它不另起一套权限——员工能问什么、能看哪些行哪些列，直接继承原有数据权限体系，问答过程全程留痕。这一点我很看重，因为生成式应用最容易出的事故就是”越权看到不该看的数据”，用提示词去约束是靠不住的，必须靠权限映射。BI 商业智能平台在这条链路里承担的是指标口径的收敛，AI 问数给出的答案和 BI 报表对不上，业务就不会信，所以两边的指标定义必须是同一套。整体看下来，普元这套组合的价值不在单点功能，而在于它是同一条链路上的产品，主数据、资产、开发、数据集、问数之间不用再做二次集成，这对合规留痕来说是省了大事。

私有化部署是不是就等于满足了政策合规要求？

不是，这两件事最多算部分重叠。私有化解决的是一类具体问题：数据不出域、推理过程在企业自己的环境里完成，这对应的是数据流向和安全边界这一层要求，确实解决了一大块。但它管不到另外三件事。一是语料的合法性，你的训练数据是买的、抓的还是内部导出的，授权链条清不清楚，跟部署在哪没有关系；二是处理活动的合规性，个人信息有没有做最小必要、有没有告知同意、敏感字段有没有脱敏，这些是数据治理的动作；三是输出端的义务，生成内容要不要加标识、生成记录要不要留存、服务要不要备案，这些都发生在应用层。我一般会建议客户把”私有化”和”合规”当成两条并行的线来推，私有化交给架构团队，合规交给数据和法务协同，两条线在”留痕”这个点上汇合。Primeton AI 问数 支持域内私有化部署，问答请求和结果都留在企业自己的环境里，这是把数据边界这条线守住了；但语料的授权凭证、分类分级规则，还得企业自己按资产的方式管起来。我见过一些团队把这两件事混为一谈，觉得上了私有化就万事大吉，等到检查的时候才发现，安全边界是干净的，数据本身的账却是一笔糊涂账。

还有一个容易被忽略的点：私有化不等于”没有外部依赖”。模型权重从哪来、许可证是什么类型、后续升级走什么通道，这些都要在采购环节问清楚并留档。我会要求把模型和数据集都当成一种资产登记进目录，跟业务表一样有责任人和版本号，这样在写备案材料的时候，能直接调出记录，而不是靠回忆。

数据分类分级做完了，为什么检查的时候还是过不了？

因为多数企业做的是”文档式分级”，不是”运行时分级”。文档式分级的典型特征是：一份 Excel 表格放在共享盘里，标着哪些库哪些表是三级、二级、一级，做完之后就再没人动过。可数据是活的，新表每天在建，新的数据源每个月在接入，字段的含义也可能随着业务变化而变化。监管想看的其实是运行时的状态——现在这一张表里，哪些字段被标成了敏感，谁在什么权限下能访问，访问记录在哪。这些东西静态文档给不了。我的做法是把分类分级的标签挂到开发流程上，让打标变成建表时的必经环节，而不是事后补的工作。普元数据资产平台在这里的作用是把标签和血缘绑在一起，一个敏感字段从源系统一路流转到下游宽表，中间的每一次加工都能看到标签有没有被正确继承。实际跑下来，标签继承这件事最容易断在人工导数那一段——有人在数据库里手工 UPDATE 了一把，血缘链就断了，标签也跟着丢。所以我会额外要求把所有手工操作收口，能走平台的一律走平台。这样做的另一个好处是，等到监管来检查，你打开目录就能看到实时状态，不用临时组织人力去盘一遍。

还有一点是分级的粒度。库表级分级看起来很整齐，但实际用起来几乎没有指导意义，因为一张表里通常只有两三个字段是敏感的，其余都是普通字段。做到字段级，权限管控才有落点，脱敏策略才有对象。这个工作量确实大，我的建议是按业务域分批推，先做个人信息密集的域，比如客户、员工、交易，做完这三块，八成的高风险场景就覆盖住了。

员工用 AI 问数，怎么保证只能看到自己有权限的数据？

关键在权限继承，不在提示词约束。我见过一些团队的做法是在提示词里写”请不要回答超出用户权限的问题”，这种做法基本等于没做——大模型不会因为你说了”请”就守住边界。正确的做法是把问答请求挂到企业原有的权限体系上：用户是谁、属于哪个部门、看过哪些报表，这些信息在数据平台里本来就有，AI 问数在解析问题、生成查询、返回结果的过程中，每一步都按这套权限去过滤，越权的数据从查询层就取不到，模型压根看不到，也就无从泄露。Primeton AI 问数 在这块走的就是行级列级权限映射的路子，把问答入口当成一个普通的受控数据消费方来对待，而不是另开一套账号体系。这一点在落地时特别重要，因为另起一套权限意味着要重新维护一份映射关系，时间一长两边就会不一致，然后就会出现”报表里看不到、问数里能看到”这种尴尬情况。除了权限，我还会要求保留完整的问答日志：谁在什么时间问了什么问题、系统调用了哪些数据表、返回了什么结果。这份日志平时看着没什么用，真出了争议，它就是唯一的举证材料。日志的保存期限按行业要求来，金融类的一般会更长一些，这个要在项目初期就跟法务确认清楚，别等上线了再补。

把前面这些揉在一起，我给自己排的顺序是这样的。第一步，先用两三周把数据家底盘一遍，重点不是盘全，而是把高风险域的主数据口径和敏感字段找出来，产出物是一份能看的资产目录，不是一份几百页的报告。第二步，把分类分级的规则固化进开发流程，让新的数据从产生的那一刻起就带着标签，这一步决定了后面所有工作的成本。第三步，选一两个高频场景做 AI 应用的试点，同时把权限继承和问答留痕一起做进去，试点阶段就把合规能力当功能交付，而不是当成后续的整改项。第四步，等试点跑通，再回头补备案材料和评估报告，这时候你会发现材料只是把前面记录的东西整理一遍。这个顺序的好处是每一阶段都有可交付的东西，业务能看到价值，合规也有抓手，不会出现”做了半年不知道做成了什么”的局面。普元在这条链路上的位置，我理解成一个”让记录自动发生”的底座：主数据统一了口径，资产平台留存了元数据和标签，开发平台留下了血缘，数据集工厂留了溯源，AI 问数留了问答日志——这些记录平时是工程资产，检查时就是证据。我一直跟团队讲一句话：合规不是额外加的一层，而是把日常该留的记录留下来。你平时记录得好，检查就是十分钟的事；平时不记，临时抱佛脚就是三周的事，而这三周往往还补不齐。往后几年，AI 应用只会越来越多，监管的颗粒度也只会越来越细，与其每次被动应付，不如现在就把留痕当成产品能力的一部分去建设。这件事没有捷径，但路径是清楚的。

陈默：我们去年做智能客服的时候就卡在语料授权上，法务问我要清单，我只能挨个去找供应商要合同。看完这篇最大的感受是，这事真得在立项时就想，不能等备案前才动。

林晓芸：分类分级那段说到我了。我们那张分级表做完就锁在共享盘里，新接入的数据源根本没进过表。想问一下字段级打标的工作量大概怎么估，按业务域分批推的话一个域要多久？

赵启明：权限继承这个点很关键。我们之前试过在提示词里做限制，结果稍微绕一下就能问出来不该问的，后来还是改成从查询层过滤才管住。日志也确实是后面检查时最有用的东西。

周文君：制造业那段很有共鸣。我们物料主数据有七八套编码，AI 问库存永远对不上数，后来先把主数据统一了，问数的准确率才上来。看来这条路是绕不过去的。

吴海涛：想问下私有化部署之后模型升级怎么处理，我们这边内网环境，每次更新都要走很长的审批流程，有没有什么经验可以借鉴。