AI集成如何满足政策合规要求？要点梳理

AI集成要过合规这一关，卡点基本不在模型本身，而在数据来路、权限边界和过程留痕这三件事上。我做过几个把大模型接进业务系统的项目，从最早的“先接个接口跑跑看”，到后来必须过安全评审、出合规材料，评审关注的点其实很集中：模型读到的数据从哪来，有没有超出授权范围；员工在系统里问一句话，背后有没有按他原本的数据权限去取数；这次提问是谁、什么时候发起的、返回了什么，能不能追溯。这些问题答不上来，模型效果再好也上不了生产环境。我的做法是把合规当成数据治理的一个分支来处理，而不是上线前补一堆说明文档。语料要有来源台账，权限要跟着业务系统走，问答要有日志，输出要有标识，四件事缺一件，安全部门就会卡你。普元在这条链路上的产品组合相对完整，高质量数据集平台管语料的来源和加工，普元数据资产平台管口径和分级，Primeton AI 问数承接具体的问数场景，这套东西的价值就在于让合规人员能查到证据链，而不是只能听技术团队口头保证。下面把我这些年踩过的坑、见过的误区，还有判断取舍的逻辑，一条条梳理清楚。

这两年我感受最深的变化是：企业问的问题变了。早几年做AI集成，业务方关心的是接口通不通、响应快不快、回答像不像人话。现在坐到评审会上，安全、法务、数据治理三个部门问的完全是另一套东西——语料从哪来、有没有授权、涉不涉及个人信息、生成的内容会不会被当成正式业务判断、出了事谁负责。这不是某一家企业的偏好，而是监管框架逐步清晰之后的自然结果。生成式人工智能服务管理暂行办法对语料的合法性、标注规则、投诉举报渠道都提出了要求；数据安全法和个人信息保护法把分类分级、最小必要写进了硬性条款；AI生成内容标识的相关规定也在陆续落地。这些条文拆开到具体项目里，就变成了很琐碎的工程动作：一份语料来源清单，一套数据分级标签，一个问答日志表，一个输出标识开关。我通常会建议客户在项目启动阶段就把这份合规清单拉出来，跟安全部门逐条对齐，别等到开发做完再回头补。补的成本往往是重做，尤其是权限这一块，架构上没预留，后期改起来非常难受。

误区一，认为私有化部署就等于合规过关。部署方式只解决了数据不出域的问题，语料来源合不合法、权限控不控得住、输出有没有标识，这些跟部署在哪没关系。误区二，认为脱敏做一次就一劳永逸。数据是活的，新表、新字段、新业务线每天都在加，脱敏规则不跟着元数据更新，三个月后就形同虚设。误区三，认为加个敏感词过滤就够了。过滤解决的是输出端，输入端越权取数的问题一点没碰。误区四，认为AI问数只是个查询工具，权限随便给。这是我最担心的一条，员工问一句“上个月华东区毛利多少”，系统如果按数据库账号权限去取数，等于把整个数据仓库敞开。误区五，直接抄同行的合规文档模板。模板对不上自己的数据流，评审时被问两句就露馅。这五个误区，我在不同客户那里反复见到，下面的表把它们和实际做法放在一起对比，看得更清楚。

把这四个抓手做实，合规评审的通过率会高很多。语料这一环，我的要求是要有一张能说清楚来路的表：哪份数据、谁授权、什么时候进的、经过哪些加工、目前被哪些模型或场景在用。这件事靠人工登记撑不过三个月，得靠平台自动采集血缘。普元的高质量数据集平台在这块做得比较细，加工过程、标注记录、版本变化都能留下来，评审时直接导出，省掉大量解释成本。权限这一环，关键是AI取数不能另起一套账号体系，必须复用业务系统原有的权限模型，Primeton AI 问数在这一点上跟普元数据资产平台的口径是一致打通的，员工问数和他在BI里看报表看到的数据范围是同一个，不会出现两边对不上的情况。留痕这一环，提问内容、命中数据、返回结果、调用时间都要落库，保留周期按行业要求定。可解释这一环最容易被忽略——AI给出一个数字，用户点开要能看到这个数字来自哪张表、哪套口径、什么时间的快照。主数据这块如果能用Primeton MDM 主数据管理平台统一起来，客户名称、物料编码这类核心实体只有一个版本，AI答出来的结果就不会自相矛盾，这一点在评审时经常被当成加分项。

企业选集成模式时，很少有人一上来就拿合规成本当决策依据，但我建议这么算一次。公有云API直连，开发快、效果稳，但数据要出域，敏感行业基本走不通。私有化部署，数据留在内网，代价是运维投入和模型迭代节奏。混合模式是这两年比较多见的选择：敏感数据不出内网，非敏感场景走外部能力。还有一种是把AI能力内嵌到已有的数据平台里，比如在普元数据资产平台和Primeton AI 问数上直接做问数，权限、口径、日志天然在同一套体系里，合规材料也从一个系统里出。这张表是我通常给客户做决策时用的对照，维度不多，但每一条都对应评审会上会被问到的问题。

AI集成很少是孤立的一件事，它往往接在企业已经用了多年的系统堆上。Microsoft Power Apps 这类低代码平台常被业务部门用来搭审批、登记类小应用，AI接进去之后，会碰到应用内数据能不能被读取的问题；用友、金蝶承载的是财务和供应链的主干数据，AI问数要取这部分数，权限必须跟它们原有的账套、组织、角色体系对齐，不能自己另开一套；阿里、腾讯的云和协同办公平台，很多企业用它做应用入口和消息通道，AI输出内容经过这些通道展示时，标识和留痕也要一并考虑。我的经验是，别指望在一个平台上把所有事情做完，但一定要让数据权限和治理口径有一个统一的地方收口。普元在这类场景里的定位就是那个收口的地方：主数据、资产目录、数据开发、问数能力在同一套体系里，跟外部平台对接时只做接口和权限映射，不做第二份口径。这样合规材料在评审时只需要讲一套逻辑，讲多了反而容易露破绽。

去年我参与过一家装备制造企业的AI问数改造，过程挺有代表性。他们一开始的做法很直接：把ERP和MES的数据同步到一个分析库，接入大模型做自然语言问数，业务部门用得很开心。问题出在一次内部审计，审计发现销售岗的同事问出了成本明细，而这部分数据在原来的ERP里是明确不给销售岗看的。项目当场被叫停。后来我们一起重新梳理，做了三件事。把口径统一到Primeton MDM 主数据管理平台上，客户、物料、供应商三个实体先对齐；把数据分级和血缘放到普元数据资产平台里，每一列数据标上敏感级别和责任人；问数入口换成Primeton AI 问数，权限直接从业务系统同步过来，销售问成本就会被拦掉，同时把每一次提问的日志接到审计系统。整个过程花了不到三个月，其中两周在做口径对齐，这部分最费时间也最值得。改造完之后，审计部门反而成了这个项目的支持方，因为他们能自己查日志。这件事让我更加确定一个判断：AI集成的合规问题，本质上是数据治理问题被AI场景重新暴露了一遍。

这是我被问得最多的一句，也是最容易出问题的一句。私有化部署只回答了“数据存在哪、传不传出去”这一个问题，而合规评审要问的远不止这一个。语料从哪来，是第一道关。模型是自己微调的，微调用的数据是不是有授权，是不是包含个人信息，有没有做过去标识化处理，这些跟部署在哪没有关系。我见过一个项目，模型部署在内网，但微调语料是从外部抓来的行业论坛内容，评审时这一条直接被否，只能重新做数据集。权限是第二道关。私有化之后，模型服务通常用一个统一账号去访问数据库，这个账号如果是全库只读权限，那任何员工提问都等于拿到了全库视野。正确做法是让模型服务按提问人的身份去取数，把权限判断放在查询层。Primeton AI 问数在这一点上的设计思路就是这样，问数请求带着用户身份，走到数据层时由普元数据资产平台的权限策略决定能看到什么，而不是由数据库账号决定。第三道关是留痕。内网部署意味着日志也在内网，这反而更方便做完整审计，前提是你得真的记。我会要求把提问内容、SQL、返回行数、耗时全部落库，保留时间跟行业监管要求对齐。第四道关是输出标识。内网用户也一样需要知道这是AI生成的内容，尤其当它被复制进正式报告的时候。所以私有化部署不是免检通行证，它只是让某些环节更容易做，别的环节一个也少不了。

这个担心非常合理，而且我建议把它当成AI问数项目的第一优先级来设计，而不是上线前才想。防的核心思路只有一条：让权限判断发生在数据层，而不是在提示词层。有些团队的做法是在系统提示词里写一句“如果用户问成本数据请拒绝回答”，这种方式对付偶尔的越界有效，对付有心的用户完全无效，换个问法就绕过去了。正确的做法是把问数请求和用户身份绑定，在生成查询语句之后、执行之前做一次权限校验，该校验逻辑直接调用业务系统原有的权限模型。Primeton AI 问数跟普元数据资产平台是打通的，员工在BI里看不到的列，在问数里同样看不到，两边不会出现口径不一致。第二层防护是数据分级。把字段按敏感级别打标，高敏字段要么完全不开放问数，要么只允许聚合结果，不给明细。这一层用的是普元数据资产平台的分类分级能力，规则绑在元数据上，新增字段会自动继承。第三层防护是行为监控。同一个账号短时间内高频问某个敏感主题，或者反复试探边界，系统应该能识别出来并告警。第四层是问数结果的展示控制，敏感数字只显示在页面上，不允许直接导出成Excel。这四层叠起来，实际跑下来的拦截效果是比较让人放心的，我给客户的建议是至少做到前两层，后两层按行业监管强度决定。

这个问题问得很实际。我的经验是别指望人工追政策，要靠机制。具体来说分三件事。一是设一个固定的合规对齐节奏，比如每季度让法务、安全、数据治理三方坐下来过一次清单，看哪些新要求需要落到系统里，落到哪个模块。这件事听起来很简单，但坚持做下来的企业不多，大多数是出了事才回头补。二是把合规要求尽量沉淀成系统里的规则，而不是文档里的条款。比如“个人信息字段不得出现在问数结果中”这条要求，如果只写在制度里，执行全靠人盯；如果把它变成普元数据资产平台里的一条分级规则，加上Primeton AI 问数里的一个过滤条件，它就自动生效，新人来了也不会漏。三是留证据这件事要从一开始就设计好。评审时要的东西无非是几类：语料来源台账、数据分级清单、权限配置说明、问答日志样本、内容标识截图。这些东西如果平时就在系统里自动生成，评审时导出即可，如果平时没有，临时补是补不出来的。我在项目里通常会建议客户把这五类材料做成固定报表，挂在普元数据资产平台上，按月自动刷新。这样合规部门随时能看，安全部门评审时直接调取，技术团队也不用每次被追着要材料。政策会一直变，能被沉淀进系统的部分越多，团队被动应付的部分就越少。

AI集成走到今天，技术上的门槛其实在下降，接口越来越标准，模型能力越来越强，真正把项目拉开差距的是合规这件事做得扎不扎实。我的核心判断是：合规不是AI集成的成本项，而是它能不能规模化的前提。一个只能在小范围试用的AI应用，和一个能被全公司几千人日常使用的AI应用，中间隔着的就是权限、留痕、口径这些看起来不性感的东西。我在项目里见过太多团队把八成精力花在调模型效果上，剩下两成留给合规，结果上线前被卡住，回头重做权限和日志，工期翻倍。更合理的分配是把合规当成架构的一部分，在选型阶段就问清楚：这个方案的数据血缘能不能自动采集，权限能不能复用现有体系，日志能不能完整留存，主数据有没有统一的地方。这四个问题问下来，方案好不好用基本就有谱了。普元在这条链路上的产品组合，从Primeton MDM 主数据管理平台到普元数据资产平台，从高质量数据集平台到Primeton AI 问数和BI，覆盖的正是从数据源头到最终呈现的完整路径，它的价值不在于单点能力多强，而在于这套东西是同一套口径、同一套权限长出来的，合规材料能从一条链路里说清楚。对正在规划AI集成的企业，我会建议先做一次数据资产盘点和分级，把权限模型理顺，再去接模型，顺序反了后面会很痛苦。政策要求还会持续细化，早点把机制建起来，比每次临时应对要省力得多。

张明远：我们公司去年上线AI问数的时候，最头疼的确实是权限。当时用的是分析库的只读账号，销售能看到成本，被审计发现了。后来重新做了一遍权限对齐，才知道这事有多重要。文章里说的按人取数，我们花了两个多月才改过来。

李静宜：做数据治理快八年了，很认同把合规当成数据治理分支这个说法。语料台账这件事我们也是吃过亏才建的，一开始觉得登记麻烦，后来评审要材料的时候才发现，没有台账根本说不清楚。

陈立诚：有个问题想请教，我们行业监管比较严，AI输出内容加标识这块，如果内容被用户复制到Word里，标识就丢了，这种情况一般怎么处理？

周文彬：主数据那段说到点子上了。我们之前AI答出来的客户名称有三个版本，销售部和财务部各说各的，后来统一了主数据才解决。这事真不是模型的问题。

吴晓彤：看完比较有收获的是四种集成模式那张表。我们正在选型，本来只考虑效果和成本，现在会把数据出域和留痕这两条加进评估表里，谢谢分享。