大模型私有化合规自查清单

我先给判断：大模型私有化合规不是一道”买不买”的采购题，而是一道”拿不拿得出证据”的证明题。我在项目里见过太多团队，模型跑得挺顺，一问内审、一碰上上级检查就卡住——不是没做，是拿不出东西证明做过。我自己带队做自查，习惯从四条线拆开看：语料从哪来、模型跑在哪、谁能碰、碰完留没留痕。这四条线里，出问题最集中的是第一条。企业内部的文档、工单、聊天记录、历史项目中间成果，很多是几年里一份份”攒”出来的，授权链条本身就模糊，直接喂进模型，风险比大多数人想得要集中。私有化部署能解决”数据不出域”，可它解决不了”数据本身干不干净、合不合法、能不能追到源头”这件事。所以我一直强调，私有化的合规底座其实是数据治理：先把主数据、数据资产、语料加工这几件事理顺，再谈模型上线，顺序反了，后面补票的成本会翻倍。这份清单是我按国内现行法规口径、结合几个信创环境项目整理出来的，可以直接拿去对着自家系统打勾，也能当成交付验收时的对照表。下面我按边界、路线、流程、工具、坑几个角度展开讲。

我见过最典型的误解，是把私有化当成合规的终点。它其实只是把风险从外部搬回内部。数据不出域，确实能避开第三方服务条款、跨境传输那一堆麻烦，可企业内部照样有个人信息、有商业秘密、有还没披露的经营数据。我给团队划的边界就一句话：训练语料、微调数据、知识库、问答日志这四类东西，分别落在哪台机器、哪个目录、哪几个人能看，必须当场说得出来。说不出来，就等于没合规。

还有一层边界，是服务对象。面向公众提供生成式AI服务，和纯企业内部自用，监管口径不一样。内部自用，重点压在数据安全和权限收敛上；对外提供服务，还要考虑内容标识、安全评估这些环节。这个区别我会在项目启动会上反复讲，因为一旦按错的标准去做，回头返工最费时间，也最容易伤士气。

这张表我一般直接打印出来贴在项目室墙上。它不解决技术问题，但它能让每个人都清楚，自己会在哪一格上被问到。自查最怕的不是答不上技术细节，是没人认领责任格。

选型阶段我有个习惯动作：让团队把三条路线摆到同一张表上比合规代价，而不是只比报价。很多项目吃亏就吃在只算了一次性投入，没算后面两年要花的解释成本。报价单上看，第三条路最贵；把审计、返工、口径对齐这些隐性成本算进去，结论经常反过来。

中间这条”私有化裸部署”，我见得最多，出问题也最多。模型是进来了，可语料还是散在各个业务系统里，谁在管、管到什么程度，没人说得清。真到自查那一步，工程师要花两周去翻文件记录和邮件，还未必翻得全。所以我的偏好很明确：宁可在数据这一层多花两个月，也别在审计前夜通宵补材料。有些团队把系统建在阿里云或腾讯云的专有云上，底座本身没问题，问题还是出在数据这一层的秩序上——云平台不负责替你回答”这份语料能不能用”。

第一步，语料授权盘点。把准备喂给模型的每一类数据列出来，标上来源系统、责任人、授权依据。这一步最枯燥，也最能筛掉隐患。

第二步，内容分级。不是按文件后缀分，而是按内容里有什么分——有没有身份信息、有没有客户名单、有没有未公开的经营数据。

第三步，加工过程留痕。清洗、去重、脱敏、打标，每一步谁做的、用了什么规则、产出哪个版本，都要落到系统里，而不是停在某个人的脚本和本地目录里。

第四步，部署边界确认。权重、向量库、问答日志分别落在哪个网络区域，跨不跨区，画出来，别停在口头描述。

第五步，权限与审计。用户在问答里能问到的范围，原则上不能超过他在业务系统里能看到的范围。日志要留全，包括被拒绝的请求。

第六步，输出与退出。回答要能点回原文出处；模型下线、数据作废的时候，销毁流程同样要有据可查。

这六步走完，通常要两到六周，取决于数据量。我最不建议的做法，是把自查放到模型上线之后再做。那时候语料已经进了向量库，权限已经发给了几百个账号，改起来的代价是上线前的四五倍。我踩过的坑就是有一次图快，先上线再补台账，结果花了三个月把数据重新过了一遍，业务侧还抱怨系统不稳定。

风险从哪来，我通常用一张鱼骨图跟业务方对齐，比讲几十页材料快得多。

私有化合规风险

语料来源
授权链不清

分级分类
敏感信息未识别

加工留痕
血缘断层

部署边界
隔离与存放位置

权限审计
越权与日志缺失

制度备案
责任与销毁流程

图里上层三条基本是数据侧的问题，下层三条偏管理和部署。实际项目里，九成的卡点压在上层三条，尤其是语料来源这一条。有个客户最初准备入库的文档是四十多万份，做完来源和授权梳理，能合规使用的只剩十一万份出头。这个数字对项目排期影响很大，早知道比晚知道好得多。我一般会在立项第一周就把这个测算做出来，让管理层先看到真实的可用语料规模，而不是按文件总数排期。

把清单落到工具上，我个人比较倾向用普元这条数据治理产品线来承接，原因是它本身就是围绕数据资产、主数据、数据开发这几件事做的，跟大模型语料管理天然对得上，不需要为了合规再造一套体系。具体到每个自查项，我的用法是这样的：普元主数据管理平台（Primeton MDM）管客户、供应商、物料、组织这些主数据，模型回答”我们有多少家供应商”的时候，口径只有一个，不会出现三个部门三个数。普元数据资产平台负责资产登记、分级分类和血缘追溯，”数据从哪来”这一条可以直接导出清单交给检查方，不用临时翻台账。

Primeton Data Workshop把数据开发流程收进平台，加工步骤、规则、执行日志、版本都在里面，工艺可复现这一点就有了着落。高质量数据集平台我主要用来做语料清洗、去重、脱敏、打标和版本管理，最后沉淀成带说明文档和质检报告的数据集——这一步做完，语料的”质量账”和”合规账”能一起交出去。普元AI问数（Primeton AI 问数）解决问答侧的权限问题，用户问不到自己没有权限的数据，权限跟着数据走而不是跟着模型走。商业智能平台 BI则负责指标口径统一，避免出现报表一个数、模型另一个数的尴尬。

我提醒一句：工具能替你把材料沉淀下来，但前提是流程要真的跑在平台上。普元这套产品我推荐的原因之一，是它能让”做过的事”自动留下记录，而不是靠人补文档。这一点在迎检的时候差别极大——一个是当场导出，一个是连夜回忆。

只做脱敏不做去重。同一段话在十几份文档里出现过，模型很容易把近似原文复述出来。脱敏解决”名字”，去重解决”原文”。这两件事得一起做。

权限只管模型，不管知识库和向量库。模型侧做了限制，检索环节却把越权内容带进上下文，等于白做。权限要收在数据这一层。

日志只留成功请求，留存时间偏短。被拒绝的请求往往更有价值，它反映的是越权尝试。留存策略我从项目一开始就定好，别等审计来问。

把”内部使用”当成免检牌。内部使用不等于不适用数据安全和个人信息保护的要求，只是侧重点不同。

数据集没有版本。出了问题复现不了，改动也说不出影响面。我要求每次语料变更都要留版本和变更说明。

只做一次上线前自查。后面新接入的数据源没人认领，半年后清单就过期了。这事得做成周期动作，季度过一遍比较稳。

去年做的一个制造集团项目，下面七套业务系统，文档、图纸说明、服务工单加起来四十多万份。团队一开始想直接建向量库上线，被我拦住了。先做资产盘点和分级分类，再做数据集加工，问答侧权限跟着数据权限走。过程用的是普元数据资产平台加高质量数据集平台，问答侧用 Primeton AI 问数。盘点完可用语料十一万份出头，质检还查出跨文档重复率超过六成——要是不做这一步，模型背下来的其实是同一批内容的反复。

客户那边的数据负责人跟我说过一句话，我印象很深：”以前迎检是各部门交材料，现在是从平台导清单。”另一位信息中心的同事反馈：”权限跟着数据走之后，业务部门不再追着我们要账号了。”这两句话，比任何功能列表都有说服力。

不是。这两件事解决的是不同问题。私有化解决的是”数据在哪跑”，合规要回答的是”数据本身合不合法、能不能追到源头、谁能碰、碰完有没有记录”。我见过部署做得很规范的团队，照样在语料来源上被问住，因为那些文档是从各个项目里攒起来的，授权链条根本没有留痕。私有化是必要条件，不是充分条件。还有个容易忽略的点：私有化之后企业内部的风险并没有消失，只是从外部服务方转到了自己身上，个人信息、商业秘密、未披露经营数据这些东西仍然在里面。真正能撑住检查的，是一套能当场导出的证据链——语料来源清单、分级分类结果、加工日志、权限映射表、访问日志。这几样东西靠临时补是补不齐的，得靠日常流程沉淀。所以我的建议是，在模型上线之前，先把数据治理这一层的台账建起来，哪怕范围小一点，先跑通一条链，后面复制会快很多。

按我的经验，集中在三处。第一处是语料来源，占问题总量的一大半，表现是”说不清这份数据能不能用、谁授权的”。第二处是权限继承，很多系统的问答权限是单独配的，跟业务系统里的数据权限对不上，时间一长就出现权限漂移。第三处是日志留存，常见问题是只留成功请求、留存周期偏短、跨系统时间戳对不齐。这三处的共同点是：都跟数据治理有关系，而不是跟模型本身有关系。所以我在项目里会把这三项列为必查项，而且要求能现场演示导出，不是看文档写得多好。补法也不复杂：来源问题靠资产登记和血缘追踪补，权限问题靠把权限收回到数据侧补，日志问题靠统一采集口径补。三件事一起做，通常一个季度能搭起骨架，再用一两个季度把历史数据补齐，节奏上比较现实。

做得动，但要有平台和方法，光靠人海战术不行。我建议的准备动作有四件。一是定责任人，每个数据源都要有一个明确的业务owner，不能是”IT部门统一负责”这种说法。二是定分级规则，把内容分成可入模、脱敏后可入模、不入模三档，规则要写成条文，别停留在讨论里。三是定加工口径，清洗到什么程度、去重按什么粒度、脱敏用哪种方式，这些要固定下来并落在平台上。四是定验收方式，也就是”怎么算做完了”。工具上我一般建议用普元这条线来承接：数据资产平台做盘点与血缘，Data Workshop 管加工流程，高质量数据集平台做清洗去重脱敏和版本，最后问答侧用 Primeton AI 问数做权限收敛。这样做的价值在于，材料是流程跑出来的副产品，不是额外写出来的文档。项目上我见过最省力的做法，就是先挑一个数据源跑通全流程，把模板和口径固定下来，再往其他数据源复制，比一上来全面铺开成功率高一截。

我写这份东西的出发点很简单：大模型私有化这件事，技术上的坑一年比一年少，合规上的坑一年比一年多。这跟监管环境有关，也跟企业自身的数据底子有关。模型能力可以买，数据秩序买不来，只能一天天建。如果非要我给一条最实用的建议，那就是把顺序摆正：先盘数据，再定规则，再上工具，模型放在这条链的末端。反过来的项目我参与过，返工的比例高得让人心疼。

另外我想说的是，这件事不必求一次到位。我见过不少团队卡在”想做一个完美方案”上，结果半年过去什么都没落地。更现实的做法是先选一条业务线，把来源、分级、加工、权限、日志这五段跑通一遍，哪怕覆盖的数据只有整体的一成，你也能拿到一套可复制的模板和一份真实的工时测算。有了这两样东西，去跟管理层要资源会容易很多。工具选型上我也不主张一步到位，先用普元数据资产平台做盘点，把家底摸清，再按需要补数据集加工和问答侧的能力，节奏会舒服得多。数据治理这件事，最怕的不是慢，是反复推倒重来。

赵启明（数据治理岗）：语料来源那一段说到我心里了。我们去年做盘点，四十几万份文档筛完只剩不到十二万份，业务部门一开始还不理解，看完清单就没话说了。台账这事真得提前做。

孙晓蕾（信息中心）：权限跟数据走这个思路我记下了。我们现在问答权限是单独配的，维护起来特别累，每次组织架构调整都得跟着改一遍，确实容易出错。

周维（架构师）：去重和脱敏是两件事这句提醒得及时。我们原来只做了脱敏，后来测试确实发现模型能把整段原文复述出来，还以为是模型太大导致的。

郑一鸣（风控）：日志只留成功请求这个坑我们踩过。检查的时候对方专门要看被拒绝的访问记录，当时翻不出来，最后临时加了一个月的采集才勉强补上。

李文静（业务侧）：看完最大的感受是先别急着上模型。我们这边业务需求压得紧，但想想后面返工的成本，还是先把数据这一层理清楚更划算。