作者:中国联通软件研究院 · 计费结算中心 张兴宇
整理排版:蚂蚁密算 曾辉
本文整理自隐语第三届嘉年华现场演讲,中国联通软件研究院基于隐语,从最初的对账试点出发,打造了一套可复制、可监管的跨域协作体系。详细介绍了对等组网、数据分级计算、规则上链存证等工程实现细节,并总结了实际推进中最难解决的部分:不是技术,而是多方协作。最终,这不仅是一套系统架构,更是一种行业共建的新模式。

在数据要素流通全面提速的背景下,我们在一线工程实践中越来越清晰地感受到: 数据安全已经不再只是“合规约束”,而正在直接决定业务是否还能继续发展。
过去很多跨域协作的方式,本质上是把“数据怎么拿到一起”作为默认前提:先汇聚、再计算、最后补合规。但随着监管要求、数据安全责任、以及跨主体协作复杂度同步提升,这条路径越来越难走——尤其是在通信行业这种数据粒度细、规模大、敏感字段多、跨主体协作频繁的场景里。
因此,“原始数据不出域、可用不可见”并不是一个愿景口号,而是在通信行业中,被真实业务一步步推到了工程实现与生产落地阶段。更重要的是,它不是“加一层安全能力”这么简单,而是在重新定义协作方式:从“拿到数据再处理”,转向“在不拿到数据的前提下完成协作”。
从宏观层面看,这一变化并非偶然,而是由多重因素共同驱动:
当这些因素叠加到通信行业,问题被进一步放大:亿级数据规模 + 跨域协作刚需 + 合规红线不可突破,使得传统集中式技术路径开始系统性失效。
在通信行业,跨运营商协作并不是“要不要做”的问题,而是长期存在、无法回避的业务事实。

例如网间详单级对账、跨域核验与监管支撑,本质上都依赖多方数据协同完成。它们的共同点是: 协作主体多、协作频次高、规则变化快、且必须在规定窗口内完成闭环。
但现实约束同样非常清晰,而且是工程层面的硬约束:
这直接导致一个结果:大量在实验室或PoC阶段“跑得通”的技术路线,在运营级业务中根本撑不住。
能“算出来”只是起点,真正的门槛是能否长期稳定地跑、能否支撑规则变化、能否可运维、可审计、可回溯、可复制。
正因为如此,我们在技术选型阶段,并没有把问题定义为“用不用隐私计算”,而是明确了一条更严格的原则:不是“能不能用”,而是“能不能长期跑在运营级业务中”。
这里的“运营级”,意味着它必须同时满足一组工程特征: 稳定性(可长期运行)、时效性(窗口内闭环)、可运维(可定位可回溯)、可扩展(规模上得去)、可治理(规则可控可审计)。

围绕这一目标,我们从工程视角对主流技术路线进行了系统评估,核心维度包括:
在详单级、亿级规模的密态对账场景中,我们最终选择了 隐语SecretFlow,原因是它在真实业务约束下,在工程可演进性与场景贴合度上更接近可持续落地路径——尤其适配规则型密态计算与结构化数据协作的工程需求。
回顾整个建设过程,这并不是一蹴而就的体系设计,而是一条伴随业务演进不断调整的工程路径:
这条路径背后的关键词只有一个:即从小场景、可验证边界切入,用标准和规则把复杂度压缩到可控范围内,再逐步扩大规模与覆盖范围。
在这个过程中,我们并没有一开始就设计一个宏大的“总体架构”。 相反,所有能力都是在真实业务中不断试错、修正、打磨后沉淀下来的。

随着场景逐步稳定,一套可以被复用和推广的方法体系逐渐清晰,也就是现在对外呈现的 中国联通“113N”可信数据空间体系蓝图。
这套体系的出发点不是“平台建设”,而是可信协作如何真正落地:
目标并不只是“搭一个系统”,而是通过真实场景把工程能力跑顺、把规则跑稳,形成 可复制、可持续的协作模式。
随着实践深入,我们逐渐意识到一个关键问题:可信协作不是一个系统能力,而是一种结构性能力。
如果把可信协作只落在单一系统里,短期看似集中统一,但一旦参与方变多、场景变多、规则变多,就会面临治理边界不清、责任难划分、扩展成本高的问题。

因此,在工程实现中,我们没有将所有能力集中到单一平台,而是将协作拆解到不同层次、不同类型的可信数据空间中:
这种方式的好处在于:参与方无需大规模改造现有系统、无需暴露原始数据,就可以在统一规则下持续协作,同时治理边界更清晰、扩展更自然。

在技术架构层面,我们始终坚持三条不可妥协的原则:
以隐语SecretFlow为核心,结合Kuscia等组件,支撑跨域联合作业、精密分析与账单核算。这不是“为了用隐私计算而用隐私计算”,而是业务约束下的工程选择。
从工程视角看,跨运营商对账的核心,是将传统集中式对账流程,拆解为一条可以在密态环境下长期稳定运行的计算流水线。

整体思路是:各参与方仍然在本地结算系统中生成详单数据,在进入计算前完成字段标准化与规则映射,确保计算语义一致;进入隐私计算阶段后,原始数据不出域,通过SecretFlow承载的密态计算能力执行规则驱动的对账逻辑。
关键工程特性包括:

这不是算法展示型方案,而是围绕高并发、规则复杂、长期运行场景做过充分工程约束的生产级实现。
在工程设计上,我们将跨运营商对账定义为 双向对等、可验证的协同执行过程,而不是单向“算完给结果”。
发起方与审核方各自在本地运行隐私计算节点,执行同一套对账规则。系统输出可校验的对账报告与差异摘要,并通过链上机制固化关键结果,确保任何一方都无法事后篡改关键结论。
如存在差异,可在密态下进行定位、复核与调整,而不是重新全量重跑。 最终形成原始数据不出域、结果可验证、过程可追溯的对账闭环,也使其能够在运营级场景中长期稳定运行。
针对不同敏感等级的数据,我们采用分级协作策略:


各运营商在本地可信数据空间内部署隐私计算节点,跨域协作通过专线网络和统一安全接入区完成。
工程上强调“最小暴露面”: 系统仅开放标准协议接口(如gRPC、HTTPS),确保原始数据与计算逻辑始终不出域,同时满足合规要求、运行稳定性与可运维性。
在业务层面,对账与结算效率发生质变:对账周期从周级、月级压缩至天级,自动化覆盖接近全量,异常更早暴露、更快定位。

在人力与成本层面,大量依赖人工核对、反复沟通的工作被规则化、系统化协作替代,人力投入明显下降,长期成本持续可控,同时资金周转效率同步提升。
更重要的是,这套能力不再局限于单点场景:推动行业从“点对点对账”走向可复制、可推广的数据协同模式,为后续联合分析、联合运营与生态协同打开空间。
实践中我们深刻体会到:技术不是最大难点,真正的难点在于跨主体长期协作。
因此,我们优先建设可信数据空间的规则底座,通过统一规范,将隐私计算能力固化为可复用、可审计、可监管的协作方式,服务于长期运营。

换句话说,我们要解决的不是“某一次对账能跑通”,而是让协作成为一种长期可运行的机制:规则怎么变、版本怎么管、争议怎么裁、审计怎么做、责任怎么划分,都需要在工程体系内被吸收。

总结来看,我们走出了一条可持续落地路径:
可以概括为:从共识开始,用标准落地,靠规则运行,以经验放大。
我们更愿意将这些成果视为一次 行业与社区协同探索的阶段性结果,而不是某一个系统建设的终点。
在整个实践过程中,隐语(SecretFlow)对我们来说不仅是一个“能跑算法的框架”,更像是一套能够承载真实业务约束、支撑工程演进的技术底座:它让隐私计算从“概念可行”走向“工程可用”,也让我们能够在高敏感、高规模、高稳定性要求的生产环境中把协作真正跑起来。
与此同时,真实生产场景也天然会暴露出大量“只有落地才会遇到”的问题:比如规则型计算在密态下如何组织与复用、亿级规模下的任务拆分与并行策略、失败恢复与回溯机制如何设计、跨主体协作的审计与存证如何做到既可信又可运营……这些问题无法靠单次PoC解决,只能在持续运行中逐步打磨。
因此,我们更愿意把“社区共建”理解为一种双向循环:
我们相信,可信协作的成熟并不是靠某一次“选型成功”完成的,而是在真实生产场景中一步一步验证: 什么是可执行、可运维、可持续的工程能力;什么样的规则体系能够长期运行;什么样的协作模式能够被复制推广。
面向未来,我们期待与更多行业伙伴和社区开发者一起,把生产实践中沉淀出的经验转化为社区可复用的能力:让更多参与方能够在统一的可信协作框架下参与协作、持续演进,并最终让“数据可用不可见”的理念真正走向—— 好用、常用、可复制、可持续。
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/70047764/viewspace-3108487/ ,如需转载,请注明出处,否则将追究法律责任。