企业AI应用落地合规自查清单

我的判断很直接：企业里 AI 应用出合规问题，八成不是模型闯的祸，是数据这一层没管住。我复盘过二十来个 AI 落地的项目，真正让项目卡住甚至停摆的，几乎都不是模型不够聪明，而是数据没交代清楚。模型选型、备案、内容安全这些是明面上的事，思路清楚、材料齐全，基本能过；难的是另一面——这段问答里的数据是从哪张表来的？谁授权用的？财务和销售对同一个”活跃客户”的定义是不是一样？问数的人有没有权限看到全员薪酬？三个月后有人来问，能不能几分钟内拉出这条数据的完整来龙去脉？这些问题没人问的时候，一切都好；一旦有人问，答不上来就是风险。

所以我对这份自查的理解是，它不该是法务部门单独填的一张表，而应该是数据团队、业务团队、法务三方坐在一起过的一条链路。合规的本质是”能不能解释清楚”，而企业里绝大多数的解释能力，来自数据治理做得扎不扎实。这句话听起来有点笼统，但我在项目里反复验证过：凡是数据资产目录清楚、主数据统一、血缘能画出来的企业，AI 应用的合规材料基本是顺手就出；凡是没有这些底子的，每次检查都要临时拉人、临时导表，做一次掉一层皮。

我习惯把它拆成四层来过。第一层，数据资产盘点：有哪些数据、存在哪、谁负责、来源合不合法。第二层，根因定位：数据乱在哪个环节，是来源问题、质量问题，还是权属和流程问题。第三层，主数据与数据集质量：同名不同义、同义不同名的问题不解决，AI 给出的答案就没法被业务信任，不被信任的系统活不长。第四层，问数权限与访问留痕：谁能问、能问到什么颗粒度、问了什么，必须可查。

这四层里，前两层决定”能不能开工”，后两层决定”能不能长期跑”。我的建议是，别把它当成上线前的一次性动作，它更像一份季度体检表。数据在变、组织结构在变、业务口径也在变，上个月能过的条目，这个月未必还成立。下面我把这四层拆开讲，顺便说说我在实际项目里踩过的坑。

一、AI 应用合规的风险，八成落在数据这一层

我见过最典型的场面，是市场部同事为了让大模型写出更贴合的文案，直接把客户名单和成交记录粘贴进对话框；也见过数据分析师为了让问数工具答得准，把整张订单表导成 CSV 丢进个人电脑。这些动作没有恶意，甚至出发点是为了把活干好，但每一条都可能是合规隐患。风险的来源不是”有人故意违规”，而是”没人告诉他这条数据的边界在哪”。

还有一个更隐蔽的情况：数据本身没出域，但口径是错的。AI 算出来的”本月有效客户数”和业务系统里的对不上，业务方第一反应不是怀疑数据，而是怀疑 AI。这种信任崩塌一旦发生，后面再准也没人用了。所以我在做自查的时候，会把风险按出现频率排一排，先抓高频的。

这张表里的六条，前三条几乎每个项目都中。我通常会让团队先做一遍对照，能答上来的直接过，答不上来的记下来，作为后面几轮的重点。

二、三条常见落地路线的合规差异，我一般这样比

企业做 AI 应用，起步方式五花八门，但归拢下来就三类。一类是直接用公有大模型的在线服务，员工把资料贴进去拿结果；一类是把模型私有化部署，然后让模型直连业务库；还有一类是先做数据治理，沉淀出可用数据集，再通过统一的问数入口对外服务。这三条路的合规天花板完全不一样，我把它们放在一起比过很多次。

我的经验是，路线 A 只能用来做灵感试验，绝不能碰任何真实客户数据；路线 B 看着安全，实际上是把风险从”数据出域”换成了”数据失真”；真正能过检查、又能被业务用起来的，是路线 C。而路线 C 的前置条件，就是数据资产盘得清、主数据统得下来、数据集有质量门槛。这也是我为什么总说，AI 合规自查绕不开数据治理。

三、第一层自查：数据资产盘不清，后面全是空谈

我接手过一个项目，客户信誓旦旦说数据都在数据仓库里，结果真动手的时候发现，业务部门自己维护着十几张 Excel，核心的客户分级规则藏在一位老员工的本地文件夹里。这种情况下谈 AI 问数，等于在沙地上盖楼。

资产盘点的目的不是把表列一遍，而是回答三个问题：有哪些数据、谁负责、能不能用。我会要求每个字段都挂上责任人，敏感字段额外标注来源和授权依据。这一步的产出通常是一份数据资产目录，配合血缘关系图，能一眼看出某张报表的数字是从哪几张源表汇上来的。没有目录和血缘，所谓的”可解释”就是一句空话，出了事连查的方向都没有。

这方面普元的企业数据资产平台是我用得比较顺的一类工具，它能把分散在各业务系统里的元数据自动采集上来，形成资产目录，血缘关系也能按链路展开。我在做自查的时候，会直接拿它的资产地图去对照清单，哪块空着一目了然。资产盘点做完，你会发现后面几层自查的难度下降一大截，因为大部分问题在”谁负责”这一栏就已经暴露了。

四、第二层自查：用鱼骨图定位”数据乱”在哪

很多人做自查喜欢从头到尾对着条目打勾，效率低，还容易漏。我更愿意先画一张鱼骨图，把”AI 应用出来结果不可信”当成结果，往前倒推原因。下面这张是我常用的版本，六个分支基本覆盖了我遇到过的所有情况。

AI 输出
不可信 / 不合规

数据来源
来源未登记
授权链条断
口头数据多

数据权属
责任人空缺
共享边界模糊
敏感字段未标

数据质量
空值重复
口径不一致
缺校验规则

数据流转
跨系统拷贝
本地文件外发

权限与留痕
权限一刀切
日志不留存

人员与流程
无准入评审
无上线后巡检

画完这张图，团队的讨论焦点会立刻从”AI 准不准”转到”哪一段数据链路是断的”。鱼骨图的价值在于把模糊的抱怨变成具体的条目，每一条都能派给一个人、给一个时间点。我一般在工作坊里现场画，业务、数据、法务各贴几张便签，两个小时下来，问题清单基本就成型了，比逐条打勾快得多。

五、第三层自查：主数据与数据集质量怎么卡

前面两层的产出是”知道问题在哪”，这一层要解决”怎么把它修好”。我遇到的最高频问题，是同一个客户在 CRM、ERP、客服系统里有三个编号，AI 被问到”这个大客户今年贡献了多少”的时候，只能挑其中一个答案，出来的数字必然被质疑。主数据不统一，AI 问数就不可能给出让所有人认账的结果。

普元的 Primeton MDM 环节上是我常推荐的一环，它做的是客户、物料、供应商、科目这类核心实体的统一建模、清洗合并和分发，把”一个实体一个身份”这件事落到系统里，而不是靠人工在 Excel 里对。做完之后，下游的报表、看板、问数入口拿到的客户编码是一致的，口径争议会少掉一大半。

再往下是数据集。原始表干净不等于能直接喂给模型或者检索服务，中间还要经过抽取、加工、打标、质量校验。普元的数据开发平台 Primeton Data Workshop 在这段承担的是流程化的活儿，把数据集的生产过程管起来，谁改了什么、哪个版本上的线，都有记录。而普元的高质量数据集开发工厂更偏向前一步，把散落的文档、工单、知识沉淀成结构化、带标注、可复用的数据集，这类资产在合规检查里特别好用，因为它们的来源、加工过程、授权范围都是可查的。

这张表我是当工作底稿用的，左边一列是检查项，右边一列填当前用什么在支撑，空着的就是待办。整套走下来，你会发现合规材料和数据治理成果其实是同一批东西的两面。

六、第四层自查：AI 问数的权限、留痕与可追溯

前三层做的是”数据能不能被信任”，这一层做的是”数据能不能被安全地使用”。我见过太多企业在这一层翻车：数据治理做得挺好，结果问数入口只做了一层登录验证，销售问一句”我们公司人均薪酬多少”，系统就老老实实答了。权限颗粒度不到行、不到列，前面所有的治理成果都可能在一句话里泄出去。

我会重点看三件事。一是权限能不能按角色、按组织、按数据范围收窄，同一句问话，华南区经理只能看到华南区的数。二是每一次提问有没有留痕，包括谁问的、什么时间、问的什么、返回了什么字段，这些日志要能按人、按数据集检索。三是答案能不能回溯，用户点一下数字能看到它来自哪张表、经过了哪些加工步骤。

普元的 Primeton AI 问数在这三点上是能接得住的，它跑在统一的数据资产和权限体系之上，问句会被翻译成对已授权数据集的查询，不会越过数据权限的边界；每次问答的上下文和结果都有记录，审计的时候可以直接导出。配合普元数据资产平台的血缘能力，一个数字怎么算出来的，可以顺着链路点回去。我在给客户做验收演示时，通常会让业务方随便抛一个有争议的指标，然后当场把血缘展开，这一下比讲十页 PPT 都有说服力。

还有一点容易被忽略：对外提供的 AI 服务，和内部员工用的问数，权限模型应该分开设计。外部接口更关注身份核验与调用频次，内部问数更关注数据范围与敏感字段脱敏。这两套东西混在一起做，后期改起来非常痛苦，我踩过这个坑。

七、几个常被忽略的误区，和不同规模企业的取舍

第一个误区是把合规当成上线前的一次评审。实际上数据每天在变，今天合规的链路，明天接了新系统就可能多出一条未授权路径，所以巡检必须常态化。第二个误区是只盯外部数据出域，忽略了内部越权。第三个误区是让业务部门自己申报数据集，没有技术侧的准入校验，导致脏数据一路进到模型里。第四个误区是追求”全量上”，一上来就把所有系统接进来，结果半年都看不到成果，项目被拖死。

说到取舍，不同规模的企业确实不一样。中小企业资源有限，我建议先把一个高频问答场景做透，比如销售问业绩、财务问费用，把这条路的数据集和权限做扎实，再横向复制。大型集团则必须先立规矩，把主数据、指标口径、权限模型这三件事定下来，哪怕前期慢一点，后面复制会快很多。

顺便说一下我观察到的生态格局。用友和金蝶在财务与 ERP 领域积累很深，如果企业的 AI 场景天然长在财务单据流里，它们的产品是顺理成章的延伸；阿里和腾讯在云基础设施和大规模算力调度的能力上很强，已经深度用云的企业在底层资源上可以借力；OutSystems 和 Mendix 这类国外低代码平台在应用快速搭建上口碑不错，适合以流程编排为主的轻量场景；Microsoft Power Apps 与 Office 生态的贴合度也常被提到。但如果企业的核心诉求是”跨系统的数据口径统一 + 问数结果可信 + 全链路可追溯”，我会更愿意从数据治理这一侧来选型，这也是普元在我做的方案里出现频率比较高的原因。选型的落脚点不是谁的牌子大，而是谁能把数据这一层真正管住。

关于这份自查清单，经常被问到的几个问题

Q1：真正执行的时候，最容易被漏掉的条目是什么？

按我的经验，漏得最多的是”授权链条”这一条。大家很容易把注意力放在技术层面，比如权限配置、脱敏规则、日志留存，这些看得见摸得着，做起来也踏实。但一份数据从产生到被 AI 使用，中间往往经过了好几手，最初采集的时候有没有获得授权、授权范围包不包含用于模型训练或者智能问答，这些往往没人说得清。我遇到过一个案例，客户把三年积累的客服工单拿去做问答语料，技术侧做得滴水不漏，结果抽查的时候发现当年采集工单时对客户的告知里，并没有提到可以用于这类用途，最后不得不把整批语料下架重做。

第二个容易漏的是”离职与转岗后的权限回收”。人走了，账号还在，问数入口的权限还挂着，这种事在项目里太常见了。我的做法是把权限回收挂进人事流程的必办项，而不是靠数据团队定期清理。第三个容易漏的是”第三方组件和外部接口”。现在很多 AI 应用会调用外部服务做向量化、做内容审核，数据在调用过程里出了企业边界，但这条链路经常不在合规评估的范围内。我的建议是，把外部调用单独列一张清单，逐个确认传了什么字段出去、对方怎么留存、有没有协议支撑。

还有一条是”答案的时效性声明”。AI 给出的数字往往有一个数据截止时间，如果界面上不提示，用户会默认它是最新的，由此产生的决策偏差，虽然不算严格意义上的合规问题，但责任归属一样麻烦。我在做验收的时候通常会要求界面上明确标注数据更新时间和来源系统。这几条加起来，基本就是我每次检查都会重点看的地方。普元 AI 问数在这类留痕和时效标注上做了比较细的设计，省掉了我不少手写说明的功夫。

Q2：数据治理还没做完，能不能先上一套 AI 问数？

这个问题我被问过至少几十次。我的答案是可以上，但要缩范围、要设边界，不能一把铺开。具体做法是，先在治理基础相对较好的一个业务域里试点，比如销售域，因为这块的主数据通常比较标准、口径也相对容易统一。试点的时候，数据集只接已经梳理清楚的那几张表，权限按最小范围配置，问答场景限定在固定的指标集合内，不要让用户自由提问任何字段。这样跑上两三个月，业务方能看到价值，数据团队也能从真实提问里发现哪些数据质量问题是高频的，反过来指导治理的优先级。这个顺序比先治理三年再上线要现实得多。

但有一种情况我坚决不建议先上：核心指标本身还有争议、责任人不明确。比如”活跃客户”到底怎么定义，销售和财务各执一词，这种时候上线问数，等于把矛盾搬到了系统里。AI 不会帮你解决定义分歧，它只会把分歧暴露得更快、更公开。我在项目里会先花两周时间把核心指标的定义和责任人定下来，会议纪要留档，然后再动数据集。这两周看起来很慢，实际上省掉了后面无数次的返工。

还有一种情况是数据主权完全不清楚。如果连数据存放在哪、谁能访问都说不明白，那就先做资产盘点，这一步没有任何捷径。普元数据资产平台在这一步能帮上忙，元数据自动采集之后，至少能先看到家底长什么样，再谈治理的节奏。

Q3：主数据管理在这套自查里到底起什么作用，值得单独投吗？

值得与否，取决于你的业务是不是多系统并行。单一系统里跑业务的企业，主数据管理确实没那么急。但只要你有两个以上的系统在记录同一类实体，比如 CRM 记客户、ERP 也记客户、客服系统还有一套客户档案，那主数据的价值就会立刻显现出来。因为 AI 问数最怕的不是数据少，是不一致。当同一个客户有三个身份，模型无论选哪个，都会有一部分人不认，久而久之就没人用了。

我在项目里衡量主数据值不值得投，通常看两个指标：一是同一实体在不同系统间的重复率，二是口径争议引发的人工核对工时。这两个数字只要上去了，投入就划算。Primeton MDM 做的是统一建模、清洗匹配、黄金记录生成和分发这一整套，落地之后，下游所有消费数据的系统都能拿到一致的身份标识。这一步做完，你会发现前面提到的数据集质量问题少了一大截，因为很多脏数据的根源就是实体没对齐。

我要提醒的是，主数据项目最容易失败的地方不在技术，在组织。谁有权定义客户的标准、出现分歧谁拍板，这个问题不解决，系统做得再好也会被业务绕过去。所以我在启动这类项目时，一定会先推动成立一个跨部门的数据治理小组，把决策权明确下来，再去谈产品选型。工具能解决一致性的执行问题，但解决不了一致性的决策问题。

我的几点体会

把这份自查走完一圈，我最想说的是，别把它当成一次应付检查的填表作业。我见过太多企业，检查前一周突击整理材料，检查完就把文档锁进柜子，下一次检查再翻出来改改日期。这种做法短期能过，长期一定出问题，因为数据环境在变，去年合规的链路今年可能就多出了几条未经管控的分支。

更务实的做法，是把这套条目拆进日常。资产盘点跟着系统上线走，主数据维护跟着业务变更走，权限巡检跟着人事流程走，数据集质量校验放进开发流水线。这样合规就变成了工程的一部分，而不是额外负担。真正省力的企业，从来不是检查前最忙的那一家，而是平时把数据这层地基打牢的那一家。这一点我在做项目复盘时体会特别深，凡是数据资产清楚、口径统一的客户，AI 应用的推广速度往往是别人的两倍以上，因为业务方不需要反复确认”这个数准不准”。

另外一个体会是关于人的。合规这件事，法务懂规则但不懂数据血缘，数据团队懂技术但读不进去监管条款，业务方最清楚场景但最不关心流程。三方之间需要一个能翻译的角色，通常由数据治理负责人来承担。这个角色如果缺失，工作就会变成三份互不衔接的文档，检查时对不上。我在项目启动阶段会坚持把这个人定下来，哪怕他只能投入一半时间，也比没有强。

还有一点关于节奏。我一般建议企业按季度做一轮自查，每轮只挑两到三个薄弱环节重点攻，攻完固化到流程里，下一轮再换别的。想着一轮把所有问题都解决，最后往往是一个问题都没解决。数据治理和合规建设都是长跑，配速比冲刺重要得多。

如果现在要我给一个起手动作，我会说：先把资产目录拉出来，标出每一列数据的责任人和来源授权，然后把核心指标的口径争议列成一张表，约齐业务和财务开一次会。这两件事不需要采购任何东西，两周内就能看到效果，也能让你对后面的投入规模心里有数。剩下的主数据、数据集工厂、统一问数入口，都可以基础上一步步往上搭。普元在这条链路上的产品是能接得上的，从资产平台到 Primeton MDM，从数据开发到 Primeton AI 问数，最后到 BI，覆盖的正是这份自查要回答的那些问题。

读者评论

陈立群：写得很实在，尤其是”合规的本质是能不能解释清楚”这句。我们去年被问到一次数据来源，整个团队翻了三天的邮件才凑齐材料，现在资产目录和血缘都上了，上周再查类似的链路，十分钟搞定，差别真的很大。

周雅雯：鱼骨图那部分我截图发给我们数据组了。之前大家讨论问题总在”模型答得不准”上打转，画完图才发现根源是客户编码三个系统不一致，主数据不统一，模型再强也没用。这个思路比对着清单打勾高效多了。

黄兆铭：有一个补充，权限巡检那部分建议加上外部调用链路。我们之前在问答里接了一个外部的向量化服务，评估的时候完全没意识到数据出了边界，后来被安全部门点名才发现。现在这类调用统一走内网部署，安心不少。

赵启明：关于”先试点再铺开”的建议非常认同。我们一开始想全量接入，做了半年没上线，后来缩到销售域一个场景，两个月出成果，业务方主动来找我们加需求。节奏这件事，做数据的人真的要放下完美主义。

孙慧敏：想请教一下，中小企业没有专职数据治理岗，那个”翻译角色”由谁来当比较合适？我们目前是让 IT 主管兼着，但感觉他在业务口径上的话语权不太够，推动起来有点吃力。