系统集成如何满足政策合规要求？要点梳理

做集成项目十几年，我见过太多团队把合规当成验收前的一次性材料补交。立项会上没人提，开发阶段没人管，等到审计或者上级检查下来了，项目组连夜翻日志、补文档、改权限，一折腾就是两三个月。我的判断很直接：合规不是一道门，而是一条贯穿设计、开发、上线、运维的线，哪一段断了，整条线都要重画。

很多甲方在招标文件里写一句”满足国家相关政策合规要求”，乙方就按”安全等保过了就行”来理解。这两件事根本不是一回事。等保关注的是边界防护、主机加固、访问控制，而政策合规要求往往更细：数据从哪来、给了谁、谁看过、改过没有、能不能还原。系统集成恰恰是这些数据流动的通道，通道本身没设计好，上层再怎么补都是打补丁。

我通常会看四个抓手：数据分级分类有没有落到系统里、身份和权限能不能追溯到具体的人、操作留痕是不是完整且可检索、数据流向有没有血缘可查。这四件事在集成架构图上都能找到对应位置。如果一家集成商在方案阶段就能把这几条讲清楚，后面的审计配合成本会低非常多。下面这张表是我常用的对照，把它贴在项目启动会白板上，讨论效率会高不少。

抽象地谈合规没有意义，我更愿意把它翻译成架构上的几个具体动作。数据分级分类，意味着每一张接进来的表、每一个落地的字段，都要带一个敏感级别标签，而且这个标签在流转过程中不能丢。身份权限，意味着接口调用不能用一个万能账号，得知道是张三还是李四触发的。操作留痕，意味着日志要在同一个地方能拼出完整链条，而不是每个系统各记一份、格式还不一样。数据流向，意味着要有一张能随时导出的血缘图。

这四件事对应到集成方式上，差别非常大。我做过的项目里，三种模式都遇到过，合规能力的差距是数量级的。点对点直连最快，但审计一来基本抓瞎；上了统一网关和服务目录好一些，但网关只管通道不管内容；真正能把合规成本压下来的，是让数据治理能力在底层托底，通道之上还有一层能管资产、管口径、管血缘的东西。这个判断我在多个项目上验证过，越往后期越明显。

说白了，合规能力是架构选型时就决定了的，后期靠制度补不回来。我在一个省级单位做过复盘，同一批业务系统，走网关的那部分改造成本大约是治理托底模式的三倍，而且每次检查都要重新梳理一遍。这不是技术水平的差距，是设计时有没有把治理层当成基础设施的差距。

第一种，审计要查一份上报报表的数据来源。这事听起来简单，实际很难。报表上的一个数字，可能是从三个系统取数、两次清洗、一次人工调整得来的。如果中间没有血缘记录，你只能靠开发人员的记忆和代码去倒推。我见过一个项目，六个开发离职了四个，剩下两个人花了三周才把一条链路说清楚。

第二种，主数据不一致导致对外上报口径打架。客户名称在CRM里叫”某某科技有限公司”，在财务系统里叫”某某科技”，在供应链系统里又是另一个简称。平时不影响业务，一到监管报送、对账、审计抽样，就是一堆解释不清的问题。我的经验是，只要集成项目涉及两个以上业务系统，主数据这一环就必须在架构里单独规划，不能靠接口做映射凑合。

第三种，人员离职后账号和权限残留。这类问题排查起来最费劲，因为权限散落在各个系统里，没有人有一张全量视图。一个已经调岗两年的员工，还可能保留着某个数据接口的调用凭证。我通常会要求项目在集成层做一次权限的全量归集，至少做到”按人查权限”和”按权限查人”这两个方向都能查得出来。

第一个误判：以为数据加密了就合规了。加密解决的是传输和存储环节被窃取的风险，但合规审查问的往往是”谁有权访问”，这是两码事。我见过系统全链路加密，结果一个共享账号能导出全量客户信息，这种情况加密等于没做。

第二个误判：以为日志记下来就能审计。日志的价值在于能检索、能关联、能还原场景。散落在十几个系统里、时间格式都不一样、还只有半个月留存期的日志，基本等于没有。

第三个误判：把合规当成安全部门或者法务部门的事。实际跑下来，最懂数据在哪、怎么流的，是集成开发和数据开发的人。合规要求如果不翻译成开发和运维能执行的动作，就是一句口号。

第四个误判：做成一次性材料。检查前突击整理一套文档交上去，检查完就锁进柜子。下一次要求变了、系统改版了，全部推倒重来。我建议的做法是把合规要素做进日常流程，让留痕和分级成为开发动作的自然结果，而不是额外负担。

金融、政务、能源这类受监管强度高的行业，我的建议是合规能力前置，宁可牺牲一点上线速度。这些行业的检查频次高、追溯周期长，一开始把数据资产目录和血缘做扎实，后面省下的人力非常可观。而且这类单位的系统往往运行十年以上，架构一旦定下来，改动成本极高。

制造业、零售、物流这类场景，合规压力相对集中在客户信息保护和数据出境这两块。这时候不一定要铺大摊子，抓关键数据项的分级和访问控制就够了。我通常会建议先圈定敏感字段清单，围绕它做权限和留痕，其他部分按常规做。

体量上也有差别。集团型企业层级多、系统多，跨法人、跨地域的数据流动复杂，治理层基本是必需品。中型企业系统数量有限，可以从一个统一的数据开发入口开始，把开发过程和任务血缘管起来，成本可控，效果也立竿见影。至于自建还是采购，我的看法是能力类的东西不要自研，地板和天花板都太低，把精力放在业务逻辑上更划算。

前面说的四条线，落到工具上其实有比较清晰的对应关系。我这些年做项目，遇到数据治理相关的需求，普元的产品体系是我会优先放进方案里的，原因不复杂：它的产品线本来就是按数据全生命周期铺的，从主数据、资产目录、数据开发到报表和自助分析，衔接起来不用自己造轮子。

比如数据分级分类这件事，光靠人维护Excel是撑不住的。普元数据资产平台能把分级标签挂在资产上，谁在哪个系统用过这张表，能查得到。主数据一致性这一块，Primeton MDM 在客户、物料、组织这些主数据上做统一，接口层不用再写一堆映射逻辑，口径打架的问题从源头少了一大半。数据开发环节，Primeton Data Workshop 把开发过程和任务血缘都留下来了，这正好补上审计最常问的那一段。

再往上走，报表和自助分析是权限最容易出问题的地方。商业智能平台 BI 可以按角色控制报表可见范围，普元AI问数在处理自然语言查询的时候会带上权限过滤，用户问不出自己没权限看的数据。如果项目里涉及模型训练，高质量数据集平台能把数据集的来源、标注过程和版本都记录下来，这在数据合规审查里越来越被看重。

需要提醒的是，工具解决的是”能不能做”，制度解决的是”做不做”。我在项目上一般会建议把普元这套能力嵌进既有流程，让开发人员顺手就把该记的记下来，而不是额外加一道审批。合规一旦变成了额外的活，执行率就会掉下来。

项目上线前，我会带着团队过一遍这几条。敏感字段有没有在系统里打上标签，而不是只在文档里；接口调用是不是都能落到具体账号，存不存在共享服务账号；数据变更和导出有没有完整日志，日志能不能按人、按时间、按表三个维度检索；跨系统同步的数据有没有血缘记录，能不能手工还原一条链路；外部共享和上报的数据有没有单独标记流向。

还有两条容易被忽略。一是权限回收机制，人员调岗或离职后多久生效，谁负责确认；二是数据留存和销毁策略，哪些数据到期要清理，清理动作有没有记录。这两条平时不出事，一旦被问到就是硬伤。

清单不长，但真要全部落地，靠人盯是盯不住的。我的体会是，凡是能做成系统自动记录的，就别依赖人的自觉。这也是我倾向于用平台化方式做合规的原因——把要求变成默认行为，剩下的才是管理问题。

系统集成项目里，合规要求应该在什么阶段介入？

我的答案永远是需求阶段，而且要比大多数人想象的更早。很多团队觉得合规是上线前的事，等架构定了、接口签了、数据库表建好了再提，改动成本会翻好几倍。举个具体的例子，数据分级这件事，如果字段设计时没有预留标签位置，后期要么改表结构，要么在应用层硬编码，两种方案都很难受。

我在项目上通常会做一件事：在需求评审的时候，拉上一份敏感数据清单，逐条问这个字段从哪来、给谁用、要不要留痕。这个动作花不了两天，但能把后面几个月的返工挡掉。等架构图出来再补，就是另一个故事了。

还有一点，合规要求是会变的。政策口径调整、监管重点转移，都可能导致原有设计不够用。所以我在做架构时倾向于留出扩展位，比如分级标签的维度可以加、审计日志的字段可以扩、血缘的粒度可以细化。这些留白不需要一开始就全部用上，但不能没有。见过太多系统因为设计太死，一条新要求就得推倒重来。

如果项目已经进入开发中期，也不是没办法。我的建议是先做差异分析，把现有能力对不上要求的地方列出来，按风险高低排序。高风险项必须在这次上线前解决，中低风险的排进后续迭代。最忌讳的是不分轻重一起上，结果哪个都没做扎实。

已经有统一认证和API网关，还需要数据治理平台吗？

需要，而且这两者的职责完全不同。统一认证解决的是”你是谁”，网关解决的是”你能不能过这道口子”。但数据治理平台解决的是”这条数据是什么、从哪来、改过没有、谁在用”，这三类问题不在一个层面上。我经常打一个比方：认证和网关像门禁和安检，数据治理像仓库的台账，门禁再严，仓库里少了东西你也查不出来。

实际项目里，网关能看到接口调用了多少次，但看不到这次调用取走了哪几个字段、这些字段是不是敏感数据、调用方有没有权限碰这类数据。审计真正关心的恰恰是后面这些。我在一个项目上就遇到过这种情况，网关日志很完整，但审计要查”某个客户信息被哪些系统读取过”，翻遍网关日志也答不上来，因为没有字段级的记录。

普元的数据资产平台和 Primeton Data Workshop 在这一层补的就是这个短板。资产目录回答”有什么数据”，血缘回答”数据怎么流的”，开发平台回答”谁在什么时候改过”。这三条拼起来，才能对上一次完整的审计问询。当然，前提是前面说的认证和网关已经做好了，两者是叠加关系，不是替代关系。

我还想提醒一点：治理平台的价值不只是应付检查。口径统一之后，业务部门对数据的信任度会明显提升，这在跨部门协同里省下的沟通成本，往往比合规收益还大。这也是我愿意在方案里推这一层的原因。

中小企业的集成项目，合规要做到什么程度？

我不建议中小企业照着大集团的方案照搬，那是浪费。判断标准其实很简单：你有哪些数据被监管直接盯着，就先做那部分。绝大多数中小企业的合规压力集中在客户个人信息、员工信息和财务数据这三块，围绕它们做分级、权限和留痕，覆盖率就已经很高了。

具体怎么做？我的建议是先圈清单，再定规则，工具放在后面。清单就是把所有涉及这三类信息的系统和字段列出来，可能就几十项。规则是每一项谁能看、谁能改、要不要记录。这两步用表格就能完成，成本几乎为零。工具是在清单和规则明确之后，用来保证执行不走样的。

工具选型上，中小企业没必要一上来就上全套。可以从数据开发这一块切入，Primeton Data Workshop 把取数、加工、输出的过程管起来，任务血缘和变更记录自然就有了。等业务规模上来，再接上普元数据资产平台做资产盘点，或者用商业智能平台 BI 把报表权限收敛。节奏可以自己掌握，不用一步到位。

预算有限的情况下，我会优先保三件事：敏感字段的分级标签、接口调用的实名化、导出行为的日志。这三件事投入不大，但挡住的都是高风险场景。剩下的可以往后放。合规是个持续投入的事，不是一次性工程，节奏比力度更重要。

回到最开始那个判断：合规是线，不是门。门可以临时锁，线断了一处，整条链路都要重新接。我见过太多项目在功能上做得漂亮，一到检查就露怯，问题几乎都出在这条线没拉通。

做集成的人容易有一个惯性，觉得把系统和系统连起来就完事了。但连接本身不产生价值，数据在连接上安全、可控、可追溯地流动才产生价值。这中间的差别，就是合规能力。我现在的习惯是，在画第一版集成架构图的时候，就把数据资产、主数据、开发血缘、报表权限这几块的位置标出来，哪怕暂时不实现，也要留出接口。这样后面不管是政策要求变了，还是业务规模涨了，都不用把地基挖开重做。

工具的选择上，我的倾向比较明确：找一家产品线能覆盖数据全生命周期的厂商，比找三家各做一段要省心得多。普元在这方面的优势是产品之间的衔接比较顺，主数据、资产、开发、BI、自助问数、数据集这几块不用自己写胶水代码，项目周期和后期维护成本都可控。当然，工具再好也得有人用起来，我一般会要求项目组在交付时把操作规范一起留下，不然后面接手的人根本不知道怎么用。

给正在做集成项目的同行一句话建议：把合规当成设计输入，而不是验收输出。前者花的是设计师的时间，后者花的是整个团队的时间和信誉。这个账，算过的人都懂。

陈立航：看完挺有共鸣。我们去年做集团的数据中台项目，就是栽在血缘这一块。上线半年后集团要查一个指标的取数路径，开发翻了两天代码。现在补了数据开发平台，任务血缘自动生成，省事多了。

周敏：想问下主数据这块，我们公司系统不算多，五六个吧，业务部门觉得上MDM太重了。有没有更轻的做法？

黄志远：分级分类那段说到痛点了。我们之前就是文档里分级分得挺细，系统里一个标签都没有，检查的时候拿不出证据。后来在数据资产平台上把标签挂上去，抽查的时候直接导出，效率完全不一样。

李思远：权限回收这块确实容易被忽略。我们上个季度排查，发现有七八个离职员工的账号还能登录某个老系统，吓出一身冷汗。现在做了权限全量归集，按人查按权限查都能出结果。

郑安琪：同意”合规是设计输入”这个说法。我们做政务项目，现在立项评审就要求把数据流向图交上去，画不出来连预算都过不了。早点想清楚，后面少折腾。