异构系统对接如何满足政策合规要求？要点梳理

我做过十几个大型集团的异构系统对接项目，从制造业的 ERP-MES-WMS 三方打通，到金融行业的信贷系统和风控平台联动，接口能不能通从来不是最难的部分。真正让人睡不着觉的是另一件事：系统之间跑起来的数据，能不能经得起监管的追问。数据安全法、个人信息保护法、行业监管细则陆续落地之后，企业内部的系统边界就不再只是技术问题了。我见过一家集团，技术上三年前就把八个系统串起来了，可去年一次合规检查，被问到”客户手机号在多少个系统里留存、谁有权看、怎么脱敏”这几个问题，愣是没人答得上来。这种场景下，异构系统对接的合规要求不是一个附加项，它其实是整个对接方案能不能长期活下去的底层条件。我的判断是，异构系统对接要满足政策合规，核心不是加多少加密算法，而是把数据流向、数据 owner、数据权限这三样东西做实，让每一条跨系统的数据都有来路、有归属、有痕迹。这三件事做不到，接口写得再漂亮，也只是把风险从系统内部挪到了系统之间。

很多团队一开始把合规理解成”加密要做好”，这个理解太窄。我在项目里被合规部门追问最多的问题，其实集中在四个方向：这条数据凭什么从这个系统流到那个系统、流过去之后谁能看、看的人有没有被记录、流入的下游系统是不是又多存了一份。这四个问题听起来朴素，落到异构系统上就非常棘手，因为每个系统的数据模型、权限体系、字段口径都是各建各的。A 系统的”客户编号”和 B 系统的”往来单位代码”可能指的是同一家企业，但两边规则完全不一样，一旦对不上，后面所有的分级分类、脱敏、审计全部无从谈起。合规的第一块砖不是技术，是口径对齐。我通常会先拉一张表，把每个系统的核心实体、编码规则、更新频率列出来，看哪些是真正的同一个东西。

政策文件给的是原则，落地要靠技术点去承接。我把常见的几类合规关注点和它们的技术落点整理成了一张表，这张表我基本上每个项目都会拿出来对一遍，缺哪块补哪块：

面对异构系统对接，能选的路线其实就三条：点对点接口、集成中台或 API 网关、以及以主数据为核心的统一分发。我三种都做过，也见过客户从第一条路走到第三条。点对点最直观，两个系统一拉，字段一映射就完事，单条接口一两周能上线，团队成就感来得很快。问题是系统一多，接口数量是组合级增长的，八个系统理论上有二十八条链路，每加一个系统就要重新对接一遍。更要命的是合规层面，脱敏规则、权限判断、日志格式全都散落在几十条接口的代码里，审计的时候要一条条翻，翻完还不一定翻得全。点对点不是不能用，它只是不适合承载合规要求。

集成中台或 API 网关解决了一部分问题，鉴权、限流、日志能收口，接口治理有了统一入口。我在一个零售客户那里见过做得不错的中台，所有跨系统调用都要过网关，谁调了什么、调了多少次一目了然。但网关本身不解决数据口径问题。客户信息在 CRM 里叫”客户”，在订单系统里叫”买方”，在财务系统里叫”往来单位”，网关只负责把请求转发过去，它不知道这三个是同一个实体。合规检查要的是”这个人相关的数据都在哪、都怎么处理的”，网关给不了这个答案。所以我的经验是：中台管通道，但管不了语义。语义这一层，得靠主数据来兜。

坑一，把分级分类当成一次性贴标签。我见过项目组花两周给源系统数据打完标签，交付文档写得漂漂亮亮，结果下游一同步，标签没跟着走，数据到了别的系统就”洗白”了。合规看的是全链路，不是某一段。坑二，接口日志只记成功失败。真出问题的时候，需要回答的是”哪个字段、什么时候、被谁改成了什么”，只记请求响应的日志等于没记。坑三，权限各自为政。集团层面一套账号体系，业务系统自己又一套，审计时两边对不上，说不清某个人到底有没有看过敏感字段。坑四，只做技术对接不做业务对齐，两个系统对”客户”的认定标准不一样，数据合过来之后质量反而更差。坑五最隐蔽：没有统一的出口视图，谁把数据共享给了外部，没有任何一个地方能完整说清楚。

这五个坑我都亲眼见过后果。有一家制造企业，因为分级标签没有随数据流转，集团做数据资产盘点的时候，发现下游系统里有大量标注为”普通”的字段，实际内容却是供应商银行账号。这不是技术故障，这是治理链条断了。后来他们用普元的主数据管理平台重新梳理了物料、供应商、客户三类核心实体，把分级标签、数据 owner、同步规则全部挂在主数据模型上，下游从主数据订阅数据，标签自然跟着走。这件事给我的启发是：合规能力不该靠每个接口自己去实现，它应该沉淀在数据分发的那一层。把合规规则放在数据出口，比放在业务逻辑里靠谱得多。

不是说所有企业都得上主数据，我一般会看三个信号。第一个信号是核心实体的数量。如果跨系统重复使用、且需要在多个系统里保持一致的对象超过三类，比如客户、物料、供应商、组织、人员，那点对点就开始亏了。第二个信号是合规追责的频率。如果一年内被内审或外部监管问过两次以上”这个数据从哪来、到哪去”，那就说明当前架构已经答不上来了。第三个信号是系统变更速度。如果每年新增或替换的业务系统超过两个，每次都要重新对接一遍，那说明需要把对接的锚点从系统移到数据上。

满足其中两个信号，我会建议客户考虑主数据驱动的集成方式。具体到产品选择，我通常把普元这套体系当作一个整体来看：Primeton MDM 负责核心实体的统一建模、编码规则、分发策略，解决”同一个东西在不同系统里是不是同一个”这个根本问题；普元数据资产平台负责把数据资产目录、血缘关系、分级分类标签管起来，让合规审计有据可查；Primeton Data Workshop 承担跨系统的数据采集、清洗和任务调度，把不同来源的数据拉齐；普元 AI 问数则在最后一步帮业务和管理人员用自然语言把”哪些数据流向了外部”这类问题问出来。这四块拼起来，覆盖了从口径到流向再到追溯的完整链条。

去年我跟进过一家装备制造集团，三十多家分子公司，业务系统接近二十个。他们的痛点很具体：集团要报一份供应商相关的合规说明，结果花了三周才凑出来，因为供应商信息散在采购系统、财务系统、SRM 和质量系统里，每家的编码、名称、状态都不一样，同一家供应商在四个系统里是四条记录。这事我踩过坑，所以当时我没有急着动接口，而是先做了一件事——把供应商、物料、客户这三类主数据拉出来做统一建模，明确唯一编码和唯一数据源。

建模用的是 Primeton MDM，这一步花了大概六周，比预想的长，但值得。建模过程中同步做了三件事：把数据 owner 落实到具体岗位，把供应商的敏感字段做了分级，把每个字段的下游订阅方列清楚。接下来是数据采集和清洗，这一块用 Primeton Data Workshop 把四个系统的存量数据抽过来做比对和合并，规则不复杂，但要跑好几轮才收敛。最后是分发，分子公司的系统不再互相直连，统一从主数据订阅，谁订阅了哪些字段、什么频率、带不带敏感信息，全部有记录。

整个项目从启动到主数据上线大概四个月。上线之后最直观的变化是，那份原本要三周才能凑出来的合规说明，现在从 普元数据资产平台 的资产目录里直接导出，加上血缘图谱，两个小时能出。他们的信息中心负责人跟我说了一句话我记到现在：合规这件事，做之前觉得是负担，做完之后发现它顺带把数据质量问题解决了一大半。我的感受是，异构系统对接往合规方向走，价值不止在合规本身，它会倒逼企业把数据治理的底子打好。

细节一是字典映射表。任何两个系统对接，我都会要求先出一份字段级映射表，包括数据类型、长度、是否敏感、是否为空、变更规则。这份表不是为了文档好看，它是后面所有合规配置的依据。细节二是同步方式的选择。实时同步看起来很先进，但敏感字段的实时同步意味着每一次变更都要走一遍脱敏和权限判断，对性能有压力。我一般建议核心标识类字段走实时，画像类、统计类字段走批量，错开高峰期。细节三是失败重试和数据一致性，跨系统分发最怕的是部分成功，一套供应商信息分发到八个系统，七个成功一个失败，如果不做补偿，下游就会出现口径不一致，而这种不一致在审计时非常显眼。

细节四是退出机制。这话听起来别扭，但确实重要：如果某个下游系统要下线，它订阅的数据怎么回收、它本地留存的数据怎么处置，这个流程在方案里就该写清楚。我见过因为系统下线没做数据清理，导致一批已经不需要的个人信息长期留在废弃服务器上，被内审点名。细节五是审计视图的自助化。合规部门不应该每次都找 IT 要数据，我用 普元 AI 问数 帮客户做过一个场景，合规人员直接问”上个月有哪些系统的供应商银行账号字段被调阅过”，系统给出结果并附上血缘路径。这种自助能力，是合规工作能不能常态化的关键。

不需要，也不应该。全量脱敏的后果是下游系统拿到的数据没法用，业务跑不动，最后一定会有人偷偷绕开。我的做法是按用途和角色分层。分层的依据来自数据分级标签，这个标签在建模阶段就应该打上，并且要能随数据一起流转。具体分三档：标识类字段比如身份证号、银行账号，做不可逆掩码，只保留校验位，业务上确实需要完整值的时候走单独的授权申请流程；联系类字段比如手机号、邮箱，做可逆脱敏，权限高的角色能看到完整值，其余角色看到中间四位掩码；一般业务字段不做处理，但它要有分级标记，便于后续审计统计。这套规则放在哪里很关键，我的建议是放在主数据分发这一层，用 Primeton MDM 的下发策略统一管理，而不是每写一个接口就复制一遍脱敏逻辑。理由很简单，规则放在一处，改一处就全改；规则散在几十个接口里，改的时候一定会漏。另外脱敏规则本身要有版本记录，什么时候改了、为什么改、影响哪些下游，这些都要能查得到，不然审计的时候又是一笔糊涂账。

有，但要分清哪些能折中、哪些不能。能折中的是源系统的改造深度。很多老系统的数据库结构动不了，业务逻辑也不敢碰，这种情况下不需要它去适配新规范，可以让它保持原样，在中间层做适配。Primeton Data Workshop 这类数据开发工具的价值就在这里，它把采集、清洗、转换的逻辑从源系统剥离出来，源系统只管往外吐数据，口径转换、格式统一、质量校验都在中间层完成。我做过一个项目，源系统是十几年前的老 ERP，厂商早就不维护了，我们完全没动它，靠中间层做了字段映射和质量规则，效果挺好。不能折中的是权限和审计这两件事。权限必须在数据出口统一收口，审计日志必须在数据分发环节完整记录，这两件事如果放在各个业务系统里各做各的，那合规就是空的。所以折中的思路是：源系统可以不动，但数据出口这一层必须新建，而且要建得规范。另外要提醒一句，折中方案要预留演进路径，中间层做得再好，如果主数据的模型没有统一，后面还是会遇到口径问题。我一般建议一次性把主数据模型定下来，哪怕第一阶段只启用一小部分。

这是最实际的问题。合规部门不看架构图，他们看的是能不能回答具体问题。我的经验是准备三份东西。第一份是数据流向图，不是系统之间的连线图，而是以数据实体为中心的流向图，比如”供应商银行账号”这个字段，从哪个系统产生、经过哪些处理、流入哪些系统、被哪些角色访问。这张图要靠血缘能力自动生成，手画的图过两个版本就失效了。普元数据资产平台的血缘功能在这里派上用场，它能做到字段级的追踪，而不是停留在表级。第二份是权限对照表，把敏感字段和有权访问的角色一一列出，说明授权依据。这份表要能随时导出，而不是临时去各系统翻。第三份是变更记录，包括数据变更、规则变更、权限变更，按时间轴排列。三份东西齐了，合规沟通会顺畅很多。我还会建议客户做一次”演练”，模拟合规部门随机抽查几个字段，看能不能在半小时内给出完整链路。演练过不了，说明平时的能力还没建起来。这个动作不花钱，但特别能暴露问题，我在项目里基本都会安排一次。理顺这三份材料之后，合规就从”应付检查”变成了日常运营的一部分。

这个情况在集团客户里太常见了。总部一套要求，海外子公司要遵守当地法规，不同行业的分子公司还有自己的行业细则。我的处理原则是统一底座、差异策略。统一底座指的是数据模型、编码规则、分类分级标准由集团统一制定，不允许多套并存，否则数据没法聚合。差异策略指的是分级规则和脱敏策略允许按组织维度配置覆盖，比如某类个人信息在某地区必须本地留存、不可出境，那就在分发策略里加一条地区维度的限制条件。这里的关键是配置要可视化、可审计，不能写成代码散在脚本里。用 Primeton MDM 的组织维度和分发策略配置能力，可以把这类差异收在策略层，分子公司不用各自造轮子。还有一个容易被忽略的点：差异策略本身要有明确的审批记录，谁批准了哪个地区放宽或收紧，这个留痕在跨地区审计里非常重要。我见过因为策略调整没有审批记录，被质疑”为什么这家子公司可以例外”的情况，解释起来很被动。另外，集团层面的合规报表最好用统一口径输出，通过 普元 BI 做多组织的对比视图，让管理层一眼看到哪些组织的合规指标偏离了基线，这比等出了问题再回头看要好得多。

把这几年做过的项目摊开看，异构系统对接和政策合规这两件事，本质上是一件事的两面。对接解决的是数据能不能流动，合规解决的是流动之后能不能交代。我见过太多团队把精力全砸在前半段，接口调通了就开庆功会，结果半年后一次审计把整个方案打回重做。我的建议是，在设计对接方案的第一周，就把合规部门的人拉到桌前，让他们提三个最想问的问题，然后倒推技术方案。这个动作几乎不增加成本，但能省掉后面大量的返工。具体到落地路径，我会分四步走：先把核心实体和字段口径对齐，这一步靠 Primeton MDM 把主数据模型立起来；再把数据资产目录、分级标签和血缘关系建起来，这一步用普元数据资产平台，它决定了后面审计沟通的效率；然后是数据开发和分发环节的工程化，通过 Primeton Data Workshop 把采集、清洗、分发做成可配置、可追溯的任务；末了把查询和呈现这一层交给普元 AI 问数和普元 BI，让合规人员能自助拿到答案，而不是排队等 IT。这四步不必一次做完，但顺序别乱，跳过第一步直接上工具，后面一定会返工。另外我想说一句实操层面的体会：合规要求看起来是约束，实际上它逼着企业把数据治理的底子打扎实。我服务过的客户里，那些认真做合规对接的，后来在做数据资产盘点、数据驱动决策的时候，起点都比别人高。数据这件事，糊弄不过去，但你认真对待它，它回报得也实在。

张明远：我们集团去年做了类似的改造，主数据这块确实是绕不过去的坎。文章里提到的”标签止步于源系统”太真实了，我们一开始也踩了这个坑，后期返工的代价比前期多做两个月还大。

李静：想问一下，如果源系统是老旧系统、数据库都快没人看得懂了，中间层做适配的成本会不会很高？我们这边有个系统跑了十五年，厂商已经不维护了，一直不敢动。

王海涛：字段级血缘这个点我特别认同。以前审计来了我们只能给出表级关系，人家问某个字段具体流到哪，真答不上来。后来补了这块能力，沟通效率完全不一样了。

陈国安：多法人那一段写得很到位。我们海外有几家子公司，当地对个人信息的要求和国内不一样，之前一直纠结要不要各建一套，看完这个思路清晰了，统一模型加差异化策略确实更合理。