统一AI入口如何满足政策合规要求？要点梳理

我经手过七八个企业级 AI 助手的落地项目，一聊到合规，绝大多数人的第一反应都是选哪家模型、要不要私有化部署、要不要自己买卡跑一个。我的判断跟这个思路正好相反：统一 AI 入口能不能过合规这道关，决定权八成不在模型层，而在背后的数据治理做到什么程度。模型换一家，很多问题一件都不会自动消失；底座修好了，入口反而变成一个相对薄的壳子。

《生成式人工智能服务管理暂行办法》把内容安全、语料来源合法、个人信息保护的责任压给了服务提供者；《数据安全法》《个人信息保护法》管的是数据从采集到使用的全链条；TC260 出的生成式人工智能服务安全基本要求，以及后来落成国标的 GB/T 45654，把语料安全、生成内容安全、问题拒答拆成了能逐条对表检查的项。这些要求落到企业内网的一个问答入口上，说到底就是四件事：数据不出域、权限不越界、回答有依据、过程可追溯。

我在方案里通常会把普元 AI 问数放在主入口的位置，但一定让它跟着普元数据资产平台、Primeton MDM 一起上。原因很直白——问答只是最后一公里的展示，真正决定合规水位的是它背后读的是谁的数据、按谁的权限读、读到的口径是不是企业唯一认定的那一版。入口单独上线、底座不动，等到审计进场会很被动。这也是我看项目时最先问的一句话：你的问答入口，数据是从哪张表里捞出来的？

2023 年我做第一个企业 AI 问答项目的时候，业务方关心的是准不准、快不快，法务只在评审会上顺口问一句”数据会不会传出去”。到了 2025 年，情况整个反过来——业务方催着上线，法务和信息安全先把三张表要走了：数据分类分级清单、权限矩阵、日志留存策略。这个转变挺真实，也挺合理。模型能力这几年没让人失望，让人失望的是很多团队发现，入口开出去容易，收回来难。

我见过一个集团客户，入口上线两个月，业务部门自己往里灌了十几万份文件，里面夹着带客户身份证号的工单和一份尚未公开的并购材料。问题不是模型答错了，而是没人说得清这些东西是怎么进去的。AI 入口的合规风险，绝大多数是从数据入口漏进去的，而不是模型自己吐出来的。这句话我几乎在每个项目启动会上都会讲一遍。

这张表我一般会直接拿给客户的信息安全负责人看。很多人看完会说一句”原来要准备的比我想的多”。是，但方向其实很清楚：把不确定性从模型那一侧，搬到你能控制的数据那一侧。模型侧的合规你只能靠选型和签约去约束；数据侧的合规，你能靠分级分类、权限体系、血缘链路去实打实地管。我个人的经验是，凡是把重心放在数据侧的团队，评审会上被追问的次数至少少一半。

第一个误区：加一层敏感词过滤就以为合规做完了。过滤词库拦得住”身份证号”这几个字，拦不住员工把一整张客户名单贴进对话框让模型帮忙分类。真正管用的不是拦词，是拦数据。第二个误区：让业务部门自己传文档，说知识库归业务自己管。听着挺放权，实际是把合规责任散到了几十个部门手里，出问题时连对账都对不上。第三个误区：权限全部做在入口层，底层数据源敞开读。这种架构在演示阶段特别顺，一进审计就露馅。

这三个误区我踩过坑，也见过客户踩。最难受的一种情况是：系统本身没毛病，模型回答也准，但因为拿不出语料来源清单和权限变更记录，整个入口被信息安全部门叫停，返工重做权限体系，工期往后推了三个多月。合规不是上线后补的文档，它是架构设计的一部分。我现在接项目，第一周就会把日志字段和权限矩阵定下来，宁可先慢一点。

我习惯把统一 AI 入口的合规拆成三层来看。入口层管的是”谁在问、问什么、答案给谁看”，重点是身份识别、会话隔离、输出审校；这一层做得好，体验顺滑，但它是最外圈。权限层管的是”这个人能碰到哪些数据”，行级、列级、标签级三种粒度要能叠着用，还得和企业的组织架构、岗位变动同步。数据层管的是”数据是什么、在哪、什么等级、谁能用”，也就是分级分类、资产目录、血缘链路这一套。

三层里我最看重数据层，因为它最难返工。权限可以调、入口可以改，数据分类分级一旦前期做歪了，后面所有判断都是歪的。所以我通常要求入口上线之前，先把两件事做完：一是核心业务域的主数据统一，客户、物料、组织这几类实体在全集团只有一个版本；二是指标口径收口，同一个”营收”不会在不同部门算出三个数。这两件事做完，问答的准确率和合规性会同时上去，属于一举两得。

合规失守

语料与数据来源
来源不清 / 未分类分级

权限与访问边界
账号过宽 / 无行级控制

模型与输出
出境调用 / 幻觉误导

审计与留痕
日志缺血缘字段

组织与流程
无审批 / 责任不清
从入口往回追：五类风险源，四类能靠数据治理提前消掉

这六条我一般做成一张打分表，让客户的信息安全、数据管理、业务三拨人分别打一遍。有意思的是，业务方最在意第二条和第六条，信息安全最在意第三条和第五条，数据管理团队最清楚第一条和第四条有多难。三拨人打分差异最大的那一行，往往就是这个项目真正的风险点。我见过好几家企业，最后卡住的都不是模型效果，而是主数据没统一导致同一个问题两种答案，业务方自己就不敢用了。

顺着这张表往下看，你会发现普元这套产品线的分布挺讲究：Primeton MDM 管主体口径，普元数据资产平台管来源与分级，Primeton Data Workshop 管加工链路，高质量数据集平台管语料质量，普元 AI 问数管最后的问答交付。它们拼在一起，刚好把上面六个维度覆盖住。我推荐这套组合不是因为它名字好听，而是因为它把”合规”这件事拆进了每个环节，而不是让合规成为上线前临时抱佛脚的一叠材料。

第一个场景是某制造集团。他们最开始只想做一个”能查报表”的对话框，试运行阶段就被挑出问题：同一个销售大区，两个部门问出来的同比数字不一样。排查了一圈，根因是主数据里客户归属维度有两套编码。后来用 Primeton MDM 把客户、组织、物料三类主数据收口，再用普元 AI 问数把问答接到统一口径之上，同一个问题在不同部门问出来的结果终于一致了。业务方对合规的态度，是从那一天开始松动的。

第二个场景是某金融类客户，他们对数据流向特别敏感。做法是把数据按密级分了三档，高敏数据只允许在私有环境内的模型上跑，普通知识类问答才走公网接口。这一层路由规则我建议写在配置里、由平台统一执行，别指望每个开发者自觉。把规则做成强制约束，比写十页规范文件管用。

避坑清单我手机上一直存着一份，分享出来：一，日志字段在第一版就定死，至少包含账号、时间、命中的数据表、引用的口径版本；二，数据分类分级不要追求一次做全，先把核心三五个业务域做扎实；三，语料入库一律走审批，别开口子；四，权限变更留痕，谁批的、什么时候生效写清楚；五，上线前跑一遍”最坏情况”演练，比如某个员工离职当天他的权限是不是立刻失效。这五条做到，合规评审基本不会翻车。

这个问题我被问过不下二十次。我的理解是这样：《生成式人工智能服务管理暂行办法》管的是”向中华人民共和国境内公众提供生成式人工智能服务”的情形，企业内部员工使用、不面向公众开放的入口，一般不属于这个范围。但请注意，”不备案”不等于”没义务”。《数据安全法》《个人信息保护法》《网络安全法》规定的数据处理义务一样跑不掉，等保测评里对网络日志留存不少于六个月的要求也是实打实的。

我的实操建议是提前备三样东西，不管现在备不备案都用得上：模型来源的合规证明、语料来源清单、上线前的安全评估记录。这三样东西，正好是普元数据资产平台在做分级分类和数据血缘时天然会产出的副产品。我不止一次见到客户直接把资产目录导出来交给法务，评审时间省了大半。如果入口后面要开放给经销商或客户用，那就变成面向公众提供服务，路径完全不同，我会建议提前和法务确认，别等做完了再改架构。另外还有一个容易被忽略的点：入口用的是哪家模型、哪个版本、什么时候切换的，这些变更记录也要留。真出问题时，”当时用的是哪个版本”往往就是责任分界线。

先说一句我的态度：单纯靠敏感词过滤防不住。能拦的是形式，拦不住的是意图。我一般会从三个动作入手。输入侧做检测和脱敏，识别到身份证号、手机号、银行卡这类结构化特征就替换或者直接提示；会话侧做权限收敛，员工问什么、能问到哪一层，由他的数据权限决定，而不是由他会打字决定。

第三个动作最关键：原始文本不要落库，日志里存脱敏后的摘要。这一点很多团队做反了，为了”便于排查”把原文全存下来，结果日志本身就变成一个新的数据泄露面。我在做普元 AI 问数的实施时，会坚持把日志字段和脱敏策略一起定义，先定字段再上线。还有一个小经验：在前置环节做数据分级分类，把”哪些数据不许出现在对话里”变成平台可判断的规则，比培训员工一百遍都有效。因为规则是自动执行的，人的记性是靠不住的。至于附件，我倾向于默认不允许上传，需要走白名单审批，宁可麻烦一点。

多模型并存本身不是问题，问题出在”没有统一出口”。我见过一个团队，三个业务部门各自接了三家模型，接口密钥散在各自代码里，后来想统计一下到底有多少数据流出去了，根本统计不出来。多模型的第一个合规要求，是收口到一个统一网关。所有调用从网关走，路由规则、限流、日志、脱敏都在这一层做，这样才有审计的可能。

第二个是数据出境。如果有一条链路会调用境外服务，那就要单独拎出来评估，我的默认做法是：涉及个人信息和重要数据的场景，一律不走境外链路，直接按密级在入口侧就把它挡掉。第三个是答案一致性。同一份数据，走不同模型可能给出不同结论，业务方会困惑。我的处理办法是让它读同一份高质量数据集，用高质量数据集平台把语料清洗、标注、版本管理都收在一处，模型换不换，输入是稳定的。第四个是审计链条。日志里要能标出这条答案走的是哪条链路、哪个模型版本，出事时能定位到具体节点。这几点做下来，多模型不再是负担，反而是可用性和成本的优化空间。

做了这几年，我对统一 AI 入口合规这件事的看法越来越朴素：它不是一道审批关卡，而是一个架构问题。你没法在系统建好之后再补出合规来，就像你没法在房子封顶之后再去补地基。真正管用的顺序，是先把数据说清楚——有哪些数据、什么密级、归谁管、口径是哪一版，再把这些规则变成平台里可以自动执行的约束，最后才是把问答窗口开出去给人用。这个顺序反了，后面就是无穷无尽的返工和解释。

我也不主张把合规做到过度。见过一些团队，为了让评审通过，把入口做成一个几乎什么都问不出来的东西，权限收到极致，最后业务方不用了，项目自然就死了。合规的目标不是让人不用，而是让人敢用。这两者之间有一个平衡点，我通常的做法是：高敏数据严管，公开知识和通用办公场景放开，先把使用习惯养起来，再逐步收紧边界。这个节奏在实际项目里比一次性到位更可行。

如果你现在正准备上一个统一 AI 入口，我给三条建议。第一，先做数据资产盘点和分级分类，这件事的收益远超你的预期，它不只服务合规，也直接决定问答的准确率。第二，把权限和日志当成产品功能来设计，而不是当成安全补丁来打，普元 AI 问数这类平台的价值恰恰在这里——它把权限校验和数据血缘做进了生成链路，而不是外挂一层。第三，找一个懂业务的法务或安全同事早期就进来，别等到评审那天才第一次见面。我经手的项目里，早期介入的合规同事，后来往往变成项目最有力的支持者，因为他们看得见每一个控制点落在哪里。

回头看，企业级 AI 入口这件事和当年上数据中台有点像：技术不是最难的部分，难的是把散在各处的数据、规则、责任理顺。谁先把这件事理顺，谁的入口就能早半年开放给业务用。而早半年用起来的那批人，积累的提问习惯和反馈数据，又会变成下一轮的护城河。这笔账，我觉得挺划算。

陈靖文（数据治理负责人）：主数据那段说到我心坎上了。我们去年就是同一个客户在三个系统里三个编码，问答上线第一周就被业务投诉，后来老老实实先做 MDM，再谈 AI。

李慧敏（信息安全）：日志字段前置设计这条我特别认同，我们吃过亏。第一版只存了对话文本，审计要查某条答案的来源，翻了两天没查出来，后来整个日志模块重做。

王振国（信息化主管）：问一句实操的，你们做分级分类一般分几档？我们现在定的是四档，感觉有点多，业务配权限配得头大。

赵一鸣（架构师）：多模型收口到网关这个建议很实在。我们三个部门各接各的模型，出了次小事故才收回来。补充一点，网关层顺手把 token 消耗统计也做了，成本一下就看清楚了。

孙婉如（业务分析师）：最有用的是”合规不是让人不用，而是让人敢用”这句话。我们之前就是权限收太死，业务方试了两周全跑去用私人工具了，那才是真的风险。