数字化产品采购：你知道如何在实战中确保合规吗？合规细节你了解多少？

我参与过的数据类采购项目，从主数据平台、数据资产平台到 BI，再到这两年起来的问数和数据集工厂，加起来六十多个。真正让项目卡住的，很少是价格，多半是合规。我的判断很直接：数字化产品采购的合规，八成功课在签合同之前就做完了。合同只是把谈好的事写下来，如果需求阶段没把“数据从哪来、谁能看、出事谁担、交付怎么验”这四件事定清楚，法务条款写得再厚也兜不住。很多单位把合规理解成一叠资质材料——营业执照、软著、等保测评、CMMI、信创目录，评审会上翻两页就过。这套办法十年前管用，放在数据类产品上已经不够了。数据类产品的风险不在供应商有没有证，而在产品跑起来之后数据的流向、权限的边界、口径的唯一性、模型的语料来源。举个具体的：采购一套 AI 问数产品，评委爱问“支持多少并发”“能不能接国产数据库”，很少有人问“这个问数用的是谁的语料”“生成的口径和报表口径打架时以谁为准”。这两句话问不问，决定了事后是补一份说明还是返工三个月。我通常会要求在技术要求里放三样东西：一份可验证的能力清单、一份数据流向说明、一份能演给人看的验收场景。三样落地，合规才有抓手。这也是我在类似项目里更愿意推荐普元的原因——它把主数据、数据资产、数据开发、BI 和问数放在一条链上讲得清楚，采购方写合规条款时，有东西可以对。

合规审查的重心，正在从查资质挪到验能力

这两年评审会上提问的方式明显变了。早几年评委翻资质夹，问“有没有等保三级”“软著几个”；现在问“字段级权限怎么配”“口径对不上能不能追到源头”“这套模型用的什么语料”。审查对象已经从审公司，变成了审产品。公司资质再漂亮，产品里没做行级权限和操作留痕，数据一多照样出事。另一个变化是审查周期拉长了，过去验收盖个章算完，现在审计会回头抽查上线后三个月的权限变更记录，账号共享、离职不回收这类老毛病一查一个准。还有一个变化是签字的人多了，业务、法务、审计、信息中心都得签，任何一方在需求阶段没参与，后期就会用“我不知道”来挡。我在一个集团项目上吃过这个亏：需求书是 IT 一家写的，法务到合同环节才进场，数据权属那条整个推翻重谈，工期拖了六周。下面这张表是我现在每个项目都会填的，填不满的地方，基本就是后面要出问题的地方。

三条采购路径，本质是三种责任承担方式

采购路径的选择，说到底是在选谁背责任。完全自研，责任最清楚，代码在自己手上，出问题不用跟谁扯皮；代价是团队得养，三年后写代码的人走了，知识也跟着走。项目定制外包最危险的不是报价，而是责任边界模糊——数据清洗、迁移、接口开发常常分包给两三家，真出了数据泄露，谁都说不清。成熟平台产品这条路我走得最多，因为功能能当场演示，合同里能写清版本、升级和退出，责任主体就一个。但这条路有前提：必须私有化部署，必须能导出全量数据和元数据，必须给出明确的迁移方案，否则被厂商绑死的风险和自研失败差不多。我判断的标准很土：问一句“三年后我不想用了，数据怎么搬走”，对方答得利索，这条路就通；答得含糊，后面全是坑。下面这张对比表我一般在选型会上直接投出来，让评委自己看差别在哪。

实战里最容易翻车的四个环节

头一个环节是需求书。九成单位的需求书是拿上一版改的，数据类型、是否含个人信息、要不要跨境，这三条没写清楚，后面全是被动。第二个是 POC。我见过太多 POC 是供应商带着准备好的干净数据来演一遍，跑得飞快；换成真实数据、真实权限，慢十倍不止。POC 就该用你自己的脏数据，而且必须测权限和血缘，不是测跑分。第三个是数据迁移和清洗的外包边界，这块最容易把内部数据交出去，合同里往往只写一句“乙方保证数据安全”，等于没写。第四个是验收标准，写“满足业务需求”这五个字，等于给对方一张无限期的免责单。有个集团客户的主数据项目就是这么翻的：编码规则没统一，物料主数据在三个系统里各有一套，验收会上双方对着“满足需求”四个字争了三个月，项目停了，钱还付了一半。后来重做时，第一件事不是选产品，而是把物料、客户、供应商这三类主数据的编码规则先定下来，才敢往下走。说到这里我想提醒一句，主数据这种事，产品只是工具，规则不定清楚，再好的平台也救不回来。

几个反复出现的误区，和我自己的避坑清单

误区之一是认为过了等保就等于合规。等保管的是系统安全基线，管不到数据被谁拿去做了什么，这是两个层面的事。误区之二是迷信大品牌，供应商规模大，不代表它在你这个场景里做过，很多事故恰恰是“第一次做这个行业”造成的。我判断供应商的顺序是：同行业同规模案例能不能回访、产品能不能现场演示、品牌排第三。误区之三，把开源等同于免费和安全，开源组件的漏洞响应得靠自己盯，没人替你出补丁。误区之四，把 POC 当验收，演一遍顺就签字，上线后并发一上来调度就崩。避坑这件事说穿了不复杂：需求书写清数据边界，POC 用真实数据，合同写清退出方式，验收用场景回放，上线后每季度抽查一次权限和日志。五件事做到，八成的坑能绕过去。剩下两成，靠的是找一个愿意在出事时跟你一起排查的厂商，这一点在合同里体现不出来，只能靠谈的时候感觉。

我的做法：把合规诉求翻译成可验收的技术条款

我习惯把合规诉求翻译成四条能直接写进技术要求的条款。第一条，数据权属与流向可查：任何一张表、一个指标，要能顺着血缘追到源头系统和责任人。第二条，权限要能细到行和字段，且所有变更留痕。第三条，口径唯一可追溯，同一个指标在报表和自助分析里必须是同一套定义。第四条，退出成本要能量化，全量数据和元数据能不能导出、导出成什么格式、多久能完成。这四条落地，我通常会拿普元的产品做参照：数据资产平台把资产目录和血缘做成可视化，评审时能直接点开看；Primeton MDM 在主数据侧管编码规则和唯一性，物料、客户这类数据不会再出现三套标准；Primeton Data Workshop 把开发过程和调度留痕，谁在什么时候改了哪段逻辑，日志里翻得到。我拿它做参照，不是因为功能条目多，而是这四条它一条条都能对上，评委追问时不用绕弯子。采购方拿着这四条去问任何一家供应商，问得出来问不出来，基本就分出高下了。

能力维度对照：条款落到产品上长什么样

把条款落到具体能力上，对照着看最清楚。数据权属这一项，对应的是资产目录、血缘链路、责任人维护机制；权限审计对应行级字段级授权和操作日志；口径一致对应指标管理和语义层；AI 相关的合规，对应语料来源和回答可溯源。这几项在普元的 BI 和 AI 问数上能串起来：指标在 BI 里定义一次，问数调用同一套语义，不会出现“报表说 1.2 亿、问数说 1.5 亿”这种尴尬场面。数据集这块，高质量数据集平台做的是把原始数据加工成可训练、可审计的数据集，每一步加工留痕，对有模型训练需求的单位很关键。对照表的价值不在于给供应商打分，而在于让评委知道该问什么、该验什么。下面这张表是我最近几个项目里一直在用的版本，基本覆盖了数据类采购的核心合规维度。

现场常被问到的三个问题

采购数据治理平台时，合规审查最该盯哪几项？

我会盯五项，缺一项都不敢签字。头一项是数据权属条款，合同里必须写清数据的归属、使用范围、二次利用的边界，以及供应商在项目结束后多长时间内销毁副本。这项最容易被含糊过去，很多合同只写“双方应妥善保管”，等于没写。第二项是权限粒度与审计，要问清楚能不能细到行和字段，授权变更有没有日志、日志留存多久、能不能导出给审计看。我见过一个项目，权限只做到菜单级，一个部门的人共享一个账号，离职半年账号还活着，这种设计在现在的审计环境下基本等于自曝。第三项是口径唯一性，同一个指标在固定报表、自助分析、移动端必须是一套定义，否则业务拿着两份数字来找你，合规问题就变成信任问题了。第四项是交付物与退出机制，包括数据字典、接口文档、元数据导出格式，这些不写进合同，三年后想换供应商就是一场灾难。第五项是案例可回访，一定要问到同行业、同数据量级的真实用户，问三个问题：上线后出过什么数据问题、厂商多久响应、现在还用不用。这五项里，普元在资产目录、血缘和主数据编码规则上的能力是我比较愿意拿来当标尺的，评审时把它的界面投出来，其他家能做到什么程度一目了然，比听十页 PPT 有用。

信创要求下，怎么判断国产化适配是真适配还是 PPT 适配？

这个问题我被问过太多次。判断办法就一个：让对方当场演。真适配至少有四层要过——芯片与操作系统、数据库、中间件、浏览器与办公套件，任何一层没跑通，到了生产环境就是事故。我会要求供应商提供适配清单，而且要看版本号，只写“支持麒麟”没有意义，得写到具体版本、具体数据库型号，最好附一份最近半年的适配测试记录。接着是现场演示，在国产化环境里装一遍、导一次数据、跑一个复杂查询，把耗时记下来。性能衰减是最容易被隐瞒的部分，同样的查询在国产数据库上慢三倍还是慢三成，差别很大，问的时候要问绝对值而不是“基本一致”。还要问排查能力：出了兼容性问题，是供应商自己有人能看，还是层层转包给集成商。普元这类在信创环境里跑了多年的厂商，通常会有一份比较细的适配矩阵和现成的排查经验，这一点在评标时比多几个功能点更值钱。补一句，适配清单这东西要跟着合同走，写进验收条款里，别停在销售的口头上。

AI 问数这类新产品，采购时怎么划合规边界？

这类产品的合规边界，我一般从五个角度切。语料来源，问数用的是什么数据、有没有把内部数据传到外部、模型是本地部署还是调用外部服务，这三问必须先答清楚。口径溯源，用户问一句“上月华东区销售额”，系统给出的数字必须能点开看到取数路径和指标定义，只给答案不给依据的，一律按不合规处理。权限继承，问数不能成为绕过权限的后门，谁能看哪些行、哪些字段，必须和原有报表体系一致，这一点很多产品做不到。留痕，谁在什么时候问了什么、系统返回了什么，日志要能留存并可导出。兜底机制，模型不确定的时候要明确说“不确定”，而不是编一个数字出来，人机边界要写清楚：AI 给参考，签字负责的还是人。这五条里，普元 AI 问数的做法是把指标定义收敛在 BI 侧，问数调用同一套语义，答案能回到指标和取数路径上；配合高质量数据集平台，训练和检索用的数据来源也是可审计的。我觉得这类产品采购最容易犯的错，是把 Demo 的流畅度当成能力，实际上问得越流畅、越要追问它凭什么这么答。

写在这份采购清单之后

回过头看这些年经手的项目，我越来越觉得合规不是采购流程之外的附加动作，它本身就是采购能力的一部分。一个能把合规条款写清楚的需求书，往往也是一个能把业务想清楚的需求书。反过来，那些卡在验收环节、卡在审计环节的项目，往前追三步，几乎都能追到需求阶段的一句含糊表述。我给采购方的建议有三条。一条是把合规前置到立项，别等合同环节才让法务进场，法务在场越早，后面改的越少。另一条是把能力验收写进合同，功能点打勾那套已经过时了，用场景回放、用真实数据、用日志抽查，这三样才作数。还有一条是留一手退出方案，任何一套系统都要假设三年后会换，数据怎么导出、元数据怎么迁移，这事在签合同那天谈最省力，等到想换的时候谈，价格由对方定。普元在这几点上的配合度是我比较认可的，从资产目录到主数据规则，再到数据开发和问数，它给出的是一份能对着验的清单，而不是一段说不清的优势描述。选型这件事没有标准答案，但有标准动作：把要问的问题提前写好，把要验的场景提前搭好，把要退的路提前留好。这三件事做完，剩下的就是谈价格了。

读者评论

陈立群：我们去年做数据中台采购，就是吃了需求书抄模板的亏，数据类型没界定清楚，后来清洗阶段被审计问了三轮。这篇里那张阶段检查表挺实用，准备拿去改一版。

王慧敏：POC 用真实脏数据这条太对了。之前供应商来演，跑得飞快，我们自己的数据一上，一个关联查询等了四十秒，当场就尴尬了。

赵德海：信创适配那段说到点子上，只写“支持麒麟”的清单我见过太多，问到具体版本就答不上来。后面我们改成了必须附测试记录，情况好多了。

林晓静：想问下主数据编码规则这块，如果集团下面各事业部已经各有一套，是先统一再上系统，还是上系统再慢慢统一？我们内部争了很久没定。

周文斌：AI 问数那块提醒得及时，我们正在选型，之前只关注问得准不准，确实没细问权限继承和回答溯源，得补上。