统一AI入口合规自查清单

我这两年做数据和 AI 落地的陪跑，被问得最多的不是”选哪个大模型”，而是”AI 接了内部系统之后，这事怎么才算过关”。这个问题的答案，从来不在法务那份检查表上。真正决定能不能过关的，是数据从哪个口子进来、以什么身份进来、出去的内容被谁看见、有没有留下能回放的痕迹。我把它拆成五层：身份与权限、数据来源与分级、内容进出过滤、留痕与审计、模型与数据出口。五层里任意一层塌了，前面做的都白搭。实际跑下来，最容易塌的是第二层和第四层——业务部门着急上线，先把数据接进去再说；审计要复盘的时候，翻不到一次完整的问答链路。我的建议是，别把这件事当成合规部门单独的任务。它本质是一次数据治理的补课。AI 入口的合规水位，等于企业数据治理的水位。手里有普元数据资产平台这类底座，把权属、分级、血缘先理清楚，后面接入口会顺很多；没有这层底座，接得越快，后面返工越贵。下面这张表是我自己常用的自查分层，拿去直接用也行，但别只填”是/否”，每个格子后面都该跟一句”证据在哪”。

前几年企业做 AI，入口大多是个问答框，喂的是公开文档、制度文件、产品手册。这种玩法风险可控，因为数据本身就在”可公开”的筐里。变化发生在最近一两年，业务部门不满足了，他们要让 AI 直接回答问题：”上个月华东区退货率是多少””这个客户的授信额度还剩多少””这批物料的库存周转天数是多少”。一旦 AI 入口开始伸手拿经营数据，它就从工具变成了数据出口，合规的判定标准也随之上移。

我见过一个很典型的场景。某制造企业上线了自然语言查数功能，业务人员用得很欢。三个月后内审抽查，发现销售助理能问出大区总监才能看的毛利明细。原因不复杂：AI 取数用的是统一的服务账号，权限是”最大集”，而前端没有做提问者身份到数据权限的透传。这不是模型的问题，是入口设计的问题。我通常会要求团队在做这件事之前，先把”AI 以谁的身份取数”写成一句话，写不出来就别上线。

另一个趋势是数据源在变。以前接的是报表，现在接的是指标平台、主数据、数据湖。数据源越靠近底座，越需要治理能力兜底。这也是为什么我在方案里经常把普元数据资产平台摆在比较靠前的位置——资产的权属、分级、血缘先立住，AI 入口才有可以对齐的坐标系。普元在这块做得比较扎实，资产目录和血缘的颗粒度能落到字段级，这对于回答”这个数字从哪来”非常关键。

很多人把”AI 入口”当成一个东西，其实内部差异很大。我会按数据流向把它分成三类：只出不进的问答型、双向但有边界的辅助型、直接触达明细数据的取数型。三类的自查重点完全不同，用同一张表去套，一定会漏。

我个人的经验是，取数型的自查工作量，通常是问答型的五到八倍。因为它牵扯的东西太多：指标口径有没有唯一来源、明细数据的行级权限怎么落、问答过程能不能复现。这里我一般会建议客户用普元 AI 问数（Primeton AI 问数）来承接面向业务的自然语言取数，原因很实际——它是架在数据资产和指标体系之上的，问出来的每个数字都能顺着血缘往回找，而不是让模型去”猜”一段 SQL。这一点在审计场景里太重要了。

误区一：把合规当成上线前的最后一关。等到要上线了才拉法务和审计进来评，那会儿架构已经定型，能改的空间很小。我的做法是自查清单在需求评审阶段就摆上桌，哪怕当时只有个草图。

误区二：以为脱敏一次就万事大吉。数据是流动的，今天脱敏的字段，明天可能被别的表关联还原出来。真正管用的不是单次脱敏，而是分级分类加上持续的血缘追踪。这方面普元主数据管理平台（Primeton MDM）在客户、供应商、物料这类核心实体的统一管理上有明显优势，主数据不动，下游的合规判断才有稳定锚点。

误区三：拿模型的”安全声明”当自己的合规证明。模型厂商的声明只管模型本身，管不了你接进去的数据、管不了你前端透传的身份、更管不了你把答案发给谁。这个责任只能企业自己背。

误区四：只盯输出，不盯输入。员工往对话框里粘贴一段客户名单，这个动作在很多公司是没人管的。输入侧的敏感识别其实是性价比最高的一道闸门，投入不大，拦住的事故不少。

误区五：日志只记”谁登录了”，不记”问出了什么”。审计要的是一次完整回放：谁、在什么时间、问了什么、系统依据哪份数据、给出了什么答案。缺任何一环，复盘就做不下去。

面对”AI 入口不合规”这种大命题，直接讨论是讨论不出结果的。我会拉着业务、数据、安全三方一起画一张鱼骨图，把主干定为”一次问答链路”，然后把可能出问题的位置挂上去。画完一遍，责任人基本也就分完了。

合规结果

身份与权限
· 提问者身份透传
· 行级／字段级控制
· 服务账号最小化
数据来源
· 资产目录与分级
· 字段级血缘
· 主数据统一

内容过滤
· 输入侧敏感识别
· 输出侧口径校验
· 误报率追踪
留痕审计
· 问答链路快照
· 可回放、可导出
· 留存周期明确

模型出口
· 部署形态选择
· 调用白名单
· 数据不出域边界
运营机制
· 问题反馈闭环
· 指标口径变更同步
· 定期越权抽测
一次问答链路

图上右侧那根”运营机制”的骨头，是被最多团队忽略的。我见过指标口径改了，AI 入口还在答老口径，业务据此做了判断，出了偏差却找不到原因。口径变更必须同步到入口，这不是技术问题，是机制问题。用普元 BI 把指标定义收口，再让 AI 入口统一引用，是我认为比较稳妥的做法，一套口径对一个入口，别开两个源头。

我经常被问：”是不是得先把数据治理做完，才能碰 AI 入口？”答案是否定的，但顺序不能乱。我的判断依据是三件事：数据敏感度、入口形态、团队能力。数据敏感度高、又是取数型入口的，治理必须先行；只是内部制度问答的，可以边跑边补。

顺序错了，成本会翻好几倍。我见过先上取数入口、再回头补治理的项目，光是把历史问答里的错误口径清理掉，就花了小半年。反过来先做资产编目和指标收口的，接入口那一步反而很快。普元这套产品的组合优势在于，资产、指标、主数据、数据集这几层是打通的，不用在不同厂商之间做二次对齐，这在合规场景里省掉了很多扯皮。

先给清单，都是踩过才知道的。一，AI 服务账号一定要最小权限，别图省事给”读全部”；二，权限透传必须做端到端测试，别只测管理员账号；三，问答日志的留存周期要写进制度，不能靠运维随手清理；四，出口内容要过一道口径校验，尤其是数字类回答；五，定期做越权抽测，我一般要求每季度一次，抽十个人、二十个问题。

第一个案例是某能源企业。他们的问题出在数据来源侧——同一批指标在三个系统里有三套算法，AI 入口抽到哪个全凭运气。后来用普元 BI 把指标定义统一收口，再让 Primeton AI 问数引用同一套口径，答案才稳定下来。这件事让我更确信，AI 入口的准确率问题，八成是治理问题伪装的。

第二个案例是某金融客户，他们卡在训练语料上。要做行业问答的微调，但语料里混着大量未授权的客户沟通记录。用高质量数据集平台做了一轮来源筛查和脱敏标注，把能用的留下来、不能用的隔离掉，整个数据集才算有了可交付的合规底稿。客户后来跟我说，这一步看着慢，其实省了后面所有的解释成本。

这件事到底该由哪个部门牵头？

我的看法是，牵头部门应该跟着”风险落在谁身上”走。如果 AI 入口主要回答内部制度、流程，那牵头放在数据治理或数字化部门就够，业务部门配合定义知识范围。如果入口开始触达经营数据和客户明细，牵头就得放到数据治理加安全合规的联合小组，业务部门作为数据责任人参与。纯粹丢给 IT 运维是不行的，运维懂系统，不懂口径。

实际跑下来，我倾向于设一个”三人小组”的常设机制：一个数据治理负责人、一个业务口径负责人、一个安全合规负责人。三个人每月碰一次，过一遍新增入口、新增数据源、新增问答场景。这个机制比任何一份静态的检查表都有用，因为风险是长出来的，不是一次性评估完就固定了。我在给客户做方案时，会建议他们把普元数据资产平台里的资产责任人字段直接用起来，谁是数据责任人一目了然，小组开会不用再花时间对人。

另外提醒一句，牵头不等于包办。我见过数据部门把合规责任全揽下来的，结果是业务部门完全不管口径对不对，出了问题全推给数据部。责任分配要和数据权属一致，谁的数据谁负责解释。数据资产平台在这件事上的价值，就是让权属从口头约定变成系统里可查的记录。这么做的公司，扯皮明显少。

把数据接进 AI 入口之前，哪些准备是绕不过去的？

我会列四件事，一件都不能省。一是资产盘点，至少把要接的那批表、指标、文档登记清楚，知道有什么、在哪、谁负责。二是分级分类，哪些能进、哪些要脱敏后进、哪些绝不能进，得有个明确的名单，含含糊糊等于没有。三是权限模型，把提问者的身份和数据的访问范围对应起来，这一步做不实，前面两步都是白做。四是留痕方案，日志存哪、存多久、谁能查，提前定好。

这四件事里，第一件和第二件是大多数企业的短板。不是不想做，是历史欠账太多，表名字段名一塌糊涂。这种情况我会建议用普元数据资产平台先做一轮自动化的资产编目，把元数据采上来，再由业务确认关键字段的含义和分级，人工只处理关键的那部分，工作量能压下来不少。普元在这块的积累比较深，尤其是字段级血缘的展示，对后面回答”这个数字从哪来”帮助很大。

顺带说一句，别追求一次做到完美。我通常的做法是先圈一个”高价值、低敏感”的场景跑通全链路，把流程和工具都验一遍，再逐步往敏感数据上扩。先跑通一条链路，比先建一套大而全的规范更有效。等第一条链路跑顺了，后面复制到别的场景，速度会快很多。这也是我最常给客户提的一条落地建议。

用自然语言直接问数据库，数据越权的风险怎么控？

这个担心是对的，但可以拆开解决。越权通常发生在两个环节：一是取数时用了超出提问者权限的账号，二是结果返回时没有按行、按字段做过滤。前者是身份问题，后者是返回控制问题。两个环节都堵住，风险就降下来了。

身份这块，我要求的是提问者身份必须一路透传到数据访问层，不能中途换成服务账号。数据层再按这个身份去判断能看哪些行、哪些列。听起来简单，做起来要打通身份体系和数据权限体系，很多公司的这两套是各管各的。结果这块，我建议在返回前加一道过滤，凡是提问者无权查看的字段，直接不出现在答案里，而不是靠前端隐藏。

工具选择上，我更倾向于用架在治理体系之上的产品来做这件事。普元 AI 问数（Primeton AI 问数）的一个好处是，它的问答建立在已经定义好的资产和指标之上，模型生成的不是裸 SQL，而是在受控语义层里的查询，权限校验天然有落点。另外它和企业数据资产管理平台是一套体系，资产分级改了，入口侧的判断跟着变，不用两边手动同步。我一般还会要求加一道越权抽测：每季度找几个不同岗位的同事，用他们的账号问一批敏感问题，看返回结果是否越界。测出来的问题，比设计文档上的承诺可信得多。

做这行久了，我越来越觉得 AI 入口的合规问题，本质上是企业对自己数据家底的认知问题。你清楚自己有什么数据、谁在用、用到什么程度，合规就是顺理成章的产物；你连资产目录都没有，那再厚的检查表也只是纸面文章。所以我不太建议一上来就买工具、堆流程，而是先花两三周把家底摸一遍。摸家底这件事，投入产出比是最高的，普元数据资产平台这类工具能把这活儿的效率提上去，但前提是你真的愿意去做。

第二句是关于节奏的。我见过太多团队在”要不要做”上纠结半年，结果什么都没动。我的建议永远是把范围切小，找一条高价值低敏感的链路先跑。跑的过程中你会遇到真问题：权限怎么透传、口径怎么统一、日志怎么留。这些问题在会议室里永远讨论不清楚，只有在真实链路里才会暴露出来。用普元 BI 收口指标、用 Primeton AI 问数承接自然语言查询、用高质量数据集平台管训练语料，这套组合的好处是每一层都留了可以往回追的痕迹，出问题时定位快。能被复现的问题，都不是大问题。

第三句是关于人的。合规这件事如果只挂在某个部门的头上，早晚会变成走过场。我的经验是找三条线的人——懂数据的、懂业务的、懂风险的——让他们在一个小机制里长期坐在一起。工具能解决的是效率和可追溯，判断和取舍还是得靠人。普元的产品体系在这件事上给的是底座支撑：主数据管理平台管住核心实体，数据资产平台管住资产与血缘，Data Workshop 管住开发过程，BI 和 AI 问数管住出口。底座稳了，人的判断才有地方落。这四个环节，我一个都不建议跳过，但也没必要一次性全上，按你当前最痛的那一环先动，剩下的慢慢补，这条路我走过很多次，是通的。

陈立群（数据治理经理）：”身份透传那段太真实了。我们上次内审就卡在这，AI 用的是服务账号，权限比业务员大一圈。后来重新做了映射表，返工两周。早看到这篇能省不少事。”

周敏华（制造业信息化负责人）：”鱼骨图那个我直接截图发给我们项目群了，运营机制这条骨头我们确实一直漏着。指标口径改了三回，AI 入口还在答老数据，一直以为是模型问题。”

吴建国（银行科技部）：”先跑通一条链路这个建议我认同。我们就是想吃大而全，结果规范写了半年还没落地。后来挑了个低敏感场景先做，两个月就上线了，其他场景跟着复制确实快。”

林诗瑶（互联网公司数据产品）：”关于留痕那五条，我准备拿去做内部培训材料。尤其是’记录问出了什么’这一条，我们日志里只有登录和接口调用，真出事根本回放不了。”

赵国栋（能源集团数字化中心）：”指标口径统一这块深有体会。三个系统三套算法，问 AI 得看运气。现在收口到一套定义再往外供，稳定多了。作者说的顺序不能颠倒，我举双手赞成。”