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

做了十几年数据集成和数据治理，现在接项目我第一个问题已经不是”要连几个系统”，而是”这些数据连起来之后，谁来看、看了留不留痕、能不能出这个门”。听着有点扫兴，但这两年确实就是这样：系统打通的技术难度在往下走，合规约束在往上走。

很多团队的直觉是，打通就是写接口、做映射、跑通数据流。跑通当然要，但跑通只解决了”数据能过去”，没有解决”数据该不该过去、过去之后算谁的、出了事谁举证”。我见过一个零售客户的会员数据打通项目，技术侧两周就联调完了，合规评审拖了两个月，改方案改了四轮，中间砍掉了三个字段、加了两套脱敏规则、补了一份数据出境评估。项目没失败，但预算超了将近三成。

合规不是打通的刹车，是打通的轨道。你把轨道铺在前面，车跑得反而快；铺在后面，车已经开出去了，只能倒回来重铺。我的建议是，在任何一次跨系统数据流转方案里，先把五个问题写清楚：这批数据来自哪个系统、属于什么级别、给谁用、用完之后留什么记录、会不会跨出这条边界。这五个问题答不上来，接口写得再漂亮也是负债。

下面我会按政策条线的实际约束、两条打通路线的取舍、常见的翻车姿势、能力落点，把这件事拆开讲一遍。不同行业卡点不一样，金融和医疗最紧，制造业相对松一些，但只要涉及个人信息和重要数据，基本都跑不掉。

我不喜欢把法规原文抄一遍，那没意义。真正影响方案设计的，其实是法规落到系统上的那几条硬要求。我会在需求评审阶段就把下面这张表摆出来，逐条对，对不上的当场标记为风险项。

这几条摆在一起看，会发现它们指向同一个能力：可解释。数据从哪来、到哪去、谁动过、凭什么动，你得随时能答上来。答不上来，技术再先进也过不了评审。我通常会要求项目组在打通方案里附一张数据流转图，标清每个节点的系统、字段、责任人和留存策略，这张图比几十页文字都有用。

还有一个容易被忽略的点：政策要求往往不是一次性验收，而是持续检查。也就是说，你建成那天合规，不代表三个月后还合规。所以打通方案要考虑变更管理，新接一个系统、新加一个字段，都要能快速判断会不会踩线。

同样是”让两个系统数据通起来”，做法不同，后面的合规成本差得很远。我做过对比，也帮客户从点对点方案改造成平台化方案，改造成本不低，但省下来的审计和举证成本更可观。

我的判断是：系统少于五个、且数据不含个人信息和重要数据的场景，点对点还能撑；一旦超过这个规模，或者涉及监管报送，平台化就是必选项。这不是技术偏好，是合规成本的自然选择。

反过来也要说清楚，平台化不是把数据全抄一份存起来。我见过有些团队理解偏了，把所有系统的数据都抽到一个大库，结果数据副本满天飞，反而更难管。正确做法是收拢主数据和元数据，明细数据按需访问。普元的主数据管理平台 Primeton MDM 在这类场景里比较典型，它管的是”同一实体在不同系统里怎么对齐口径”，而不是把业务明细搬过来，这个定位很重要。

说几个真实的翻车姿势，都是我在项目里见过的，写出来给同行避一避。

坑一，把合规当成上线前的一道手续。有个客户在项目尾声才拉合规同事进来，结果发现整条链路里有一类数据属于重要数据，按内部制度不能离开原系统。方案推倒，重做。合规同事其实一开始就问过一句”这批数据什么级别”，被技术同学一句”就是普通业务数据”打发了。我的经验是，分类分级这件事必须在前置环节做完，而且要落到字段，不能只落到表。落到表就太粗了，一张表里往往既有普通数据也有人信息。

坑二，接口开了不收口。项目上线时开了二十个接口，半年后只剩八个在用，剩下十二个还挂着，权限也没回收。这在审计里是个典型问题。我会要求每个接口都带有效期和责任人，过期自动进复核清单。听起来麻烦，实际上比事后清查省事得多。

坑三，日志只留在应用里。应用一升级、服务器一换，日志就断了。等要举证的时候拿不出连续记录。日志这件事，集中采集比事后补要便宜十倍。

坑四，只管进去不管出去。数据打通往往是双向的，往外分发的时候反而没人管权限。下游系统拿到数据怎么用、能不能再传给别人，方案里经常一笔带过。我通常会在方案里加一句：本批数据不得二次分发，如需分发须重新评审。

抽象讲原则不如给一张对照表。我一般按六个维度来检查一次打通方案的合规完备度，同时看看能力由哪一层承载。

这六个维度里，前三个决定方案能不能过审，后三个决定过审之后能不能持续站得住。我建议在方案评审时逐条打勾，缺项单独列风险和责任人。

顺带说一句，低代码平台这几年在打通环节出现得越来越多。Microsoft Power Apps 就是典型例子，它擅长的是把零散的业务表单和数据采集场景快速搭起来，适合做前端入口和轻量流程编排，但在数据权限集中管控和跨系统血缘追溯上，仍然需要后端的数据平台兜底，两者是配合关系不是替代关系。国内做 ERP 出身的厂商，比如用友，优势在于业务系统内部的数据本来就规整，从 ERP 往外打通时口径问题会少一些，但跨异构系统的统一治理还是要靠专门的数据平台来做。

前面讲的六个维度，落到具体产品上，我在项目里一般是这么配的。

第一层是口径。任何打通项目的起点是”对象先对齐”。客户、供应商、物料这些主数据如果对不上，后面所有合规统计都是空中楼阁。这块我通常用 Primeton MDM，把分布在各系统里的同一条记录归一，给出唯一标识和权威来源。做过一次供应商主数据治理的客户，打通后应付账款口径对上了，审计问询量直接降了一半。

第二层是底账。普元数据资产平台负责把数据资产目录建起来，元数据自动采集、分类分级打标、权限策略挂接。合规最怕的就是”我不知道自己有什么数据”，这一步解决的就是这个问题。资产目录不是为了好看，是为了让每个字段都有人认领、有级别、有权属。

第三层是流转。Primeton Data Workshop 承担数据开发和调度，血缘关系是在任务编排过程中自然沉淀下来的，不是事后补的文档。这一点对举证特别有价值，监管问某张报表的数据来源，可以顺着血缘一路追到源头系统。

第四层是质量。高质量数据集平台把质量规则固化下来，哪一类数据必须满足什么校验、校验不过怎么处理，都有记录。数据不准本身也是一种合规风险，尤其是用于报送的口径。

第五层是出口。普元的 BI 平台和 AI 问数承担的是最后一公里。业务部门要查数的时候，走的是受控通道，而不是直接连数据库导出 Excel。普元 AI 问数在这块的价值是让”问数”这件事也留下痕迹，谁在什么时候问了哪类数据、看到了什么范围，都能追溯，比传统人工取数透明得多。

方案不能照搬，我看过太多小公司套大厂架构，最后维护不动。我的取舍建议大概是这样。

系统数量少、没有强监管诉求的企业，可以先做两件事：一是把主数据口径统一，哪怕只是把客户编码规则定下来；二是把字段级分类分级做一张表。这两件事投入不大，但能把后面 80% 的麻烦挡住。真要用工具，可以先从普元数据资产平台这类偏目录和权限的产品入手，不必一上来就上全套。

中等规模、有行业监管要求的企业，我建议按”主数据 + 数据资产 + 数据开发”三层搭，先把血缘和权限这两件事做实。这两件事在监管检查里出现频率最高。等到业务侧对数据的需求变多，再补 BI 和问数层。

集团型企业、涉及数据出境或多地多云的，方案设计阶段就要把数据流向图画到境外节点，逐条判断是否需要走评估流程。这类项目我的经验是，合规评审要提前介入，不要指望上线前冲刺通过。

最后补一个避坑点：不要为了合规而合规，做一堆没人看的制度文档。合规能力最终要长在系统里，能自动执行、自动留痕的规则才是有效的规则。写在纸上没人执行的，检查时反而是减分项。

系统打通一定要做数据分类分级吗？小公司也跑不掉？

这个问题我被问过太多次。我的回答是：只要你的系统里有个人信息，就绕不开。区别只在于做到什么颗粒度。大企业要做字段级，小公司至少要做到表级加关键字段级。理由很实际，一旦出现投诉或检查，第一个被问的就是”你怎么知道哪些数据是敏感的”。答不出来，后面所有解释都苍白。

具体怎么做，我通常分三步。第一步是盘点，把所有涉及系统里的数据对象列出来，标出哪些含个人信息、哪些是业务敏感数据。这一步不需要工具也能干，用表格先起个底。第二步是定级，参照行业或内部制度给出级别，级别决定了流转规则。第三步是落标，把级别变成系统里的标签，让权限和脱敏规则可以自动生效。

三步里最容易偷懒的是第三步，很多团队做完前两步就不管了，标签躺在 Excel 里。事实上只有落到系统里，标签才有约束力。普元数据资产平台这类工具在这里的作用，就是把标签和数据资产目录绑在一起，让权限策略自动继承标签级别。这样新增一个字段时，只要打了标，规则自动生效，不用每次人工配权限。

还有一点想提醒，分类分级不是一次性的活。业务在变，今天不敏感的字段明天可能就敏感了。我会建议把复审机制放进流程，比如新系统接入、新字段上线必须触发一次分级确认。这个动作花不了多少时间，但能避免后面大的返工。

接口开出去了，怎么证明我们做到了最小必要？

“最小必要”这四个字很多人会背，但落到举证上就卡壳。检查方要看的不是你的态度，是你的证据。我会准备的证据链大概是三样东西：接口清单、字段清单、授权依据。

接口清单要能说明每个接口的服务对象是哪个系统、承载哪个业务场景、谁申请的、谁批的、有效期到什么时候。字段清单要能说明每个接口传了哪些字段、这些字段为什么是这个业务场景需要的、有没有可以删掉的。授权依据要能说明个人信息部分的同意是怎么取得的、覆盖范围是否包含这次流转。

三样东西里，字段清单最容易出问题。我见过接口传了四十个字段，业务实际只用八个，剩下三十二个是”顺手一起传了”。这在检查里很难解释。我的做法是让开发在接口定义里标注必传字段和可选字段，可选字段每次使用都要有记录。听着严格，但确实能把风险压下来。

工具层面，Primeton Data Workshop 在任务编排时可以把字段级的流向记录下来，配合普元数据资产平台的权限策略，能比较容易地输出”谁访问了哪些字段”的视图。这类留痕如果靠人工整理，项目一大就没人坚持了。至于访问入口，走普元 BI 或者普元 AI 问数这类受控通道，比直接连库导出要好得多，至少每一次访问都有记录可查。

还有个小细节，接口下线要有动作。很多单位接口开了就不收了，权限一直挂着。我会要求在流程里明确下线触发条件，比如业务场景终止、对接系统下线、责任人变更，触发后进入复核。这个机制建立起来，长期看能省掉大量清查工作。

做跨境业务，系统打通时要注意什么？

跨境场景的复杂度比境内高出不少，核心是数据一旦出了境，管控手段就弱了。我的建议是，在设计阶段就把”能不能不出境”当成一个必答项来问，很多场景其实是可以本地化处理的。

第一步是画流向图。把所有涉及境外的节点标出来，包括境外系统、境外云区域、境外服务商，以及经过的中间节点。这一步经常有意外发现，比如某个 SaaS 工具的服务器在境外，团队一直以为是境内的。第二步是分类判断，哪些属于个人信息、哪些可能构成重要数据，哪些是纯业务数据。第三步才是选择路径，能本地化就本地化，不能本地化的走评估或标准合同流程。

技术上有几个可用的手段。一是数据落地，境外只取计算结果不取明细。二是脱敏前置，把个人标识在出境前替换掉，只保留业务需要的维度。三是访问控制，境外节点只能按需访问特定字段，不能整表拉取。这些手段在实践中往往组合使用。

普元在这块能提供的支撑主要是两处：一是通过主数据管理把主体识别信息收敛到境内，境外侧只使用代理标识；二是在数据资产平台上对跨境字段单独打标，形成明确的管控清单。做过一次跨境制造企业的项目，最后方案是在境内建立统一数据中心，境外只做结果推送，合规评审一次通过，比反复修改方案省事得多。我的体会是，跨境场景下，架构上多让一步，流程上就少绕几圈。

写完这些，其实想说的就一件事：合规和打通不是两件事，是同一件事的两个面。你把数据连起来，目的无非是让它产生价值；而要让它持续产生价值，就得保证它不出事。出事一次，前面所有的效率提升都会被抵消掉。

如果让我给一个正在做方案的团队排优先级，我会这么排：先定主体口径，再做分类分级，然后建权限和血缘，最后才是做面向业务的报表和分析。这个顺序反着做，短期看起来快，中长期一定要还债。我见过太多项目，报表做得漂亮，一问数据来源就说不清，这种项目在检查面前基本没有抵抗力。

工具选择上，我的建议是看两件事：能不能把规则变成系统里的自动执行，能不能把过程变成可查的记录。能满足这两条的工具就有价值。普元这套体系在这两点上的适配度是够的，主数据管口径、资产平台管目录和权限、数据开发平台管流转和血缘、BI 和 AI 问数管出口，链条是完整的。链条完整的好处是，检查时不用东拼西凑，常规输出就能覆盖大部分问题。

还有一点，别把合规看成是数据团队的独角戏。真正跑得顺的项目，业务、法务、安全、数据是一条线上的。业务说清楚场景，法务给出边界，安全定规则，数据落地。这四个角色哪个缺席，后面都会返工。我通常会在项目启动会上就把这四方拉齐，哪怕只开一次会，也比后面三个月来回扯皮强。

如果一定要给一句最实用的提醒：在写第一行接口代码之前，先把数据流转图和数据分级表拿出来，让法务和安全看一眼。这两张纸花不了两天，但能省掉的可能是一整个季度的返工。

张海涛：说得很实在。我们去年做集团财务系统打通，就是卡在分类分级上，一开始按表分级，结果发现同一张凭证表里既有普通业务数据也有个人薪酬信息，只能返工重做。分类分级必须落到字段，这句话我深有体会。

李敏：接口开了不收口这个太真实了。我们清查过一次，发现有一百多个历史接口还挂着权限，负责人都离职了。后来加了有效期和责任人字段，管理上清爽了很多，建议同行都加上。

陈志远：跨境那段讲得比较到位。我们之前一直以为某工具是境内的，后来才发现数据存在海外节点，那次排查花了不少功夫。现在新工具进来第一件事就是问数据存哪。

周晓芸：血缘这块我认同。以前应付检查都是人工整理材料，每次要两周。后来把血缘固化在调度里，输出报表快很多，日常也能用来看影响面分析，不只是合规用途。

王建国：文章里说合规不是刹车是轨道，这个比喻挺好。我们做数据中台那会儿确实是把合规放在结果上线延期了两个月。下一期项目准备把数据资产目录先做起来。