前段时间跟朋友吃饭，我们聊起了最近讨论比较多的可信数据空间这个话题。饭桌上的几个人都是做项目的，也多多少少都参与或者知道一些国内的一些大项目，谈到后来一个朋友提了一个问题：“你们说的几个项目中，抛开赚了多少钱、项目多难搞这些不说，为什么听你们说的有些数据空间项目基本上是‘建废’了，为啥会这样？怎么才能‘不建废’？”
我没法直接回答他。因为”不建废”这件事，从来不是靠某一个正确动作，而是靠避开一堆看起来正确的坑。后来陆续有几个可信空间的解决方案的讨论，有试点城市的，有做交付的集成商，聊到最后问题都差不多：该从哪里开始，哪里是成败的关键，哪里其实是在白干。
我后来认真的想了想，从这些年看的项目、做的项目，把看到别人踩的坑和自己踩过的坑做了一下梳理总结。以下十个误区，每个都对应着真实发生过的事，供参考。
误区一：把数据空间当成”数据仓库二期”
这是一个最大的坑，很多项目其实搞不清楚什么是数据空间。或者有时候是明知道什么是什么不是，但是因为自己手里有“锤子就到处找钉子”。
很多人理解可信数据空间，第一反应是”把数据集中起来管”。数据仓库、数据中台干了二十年，逻辑大家都熟：建库、归集、治理、出报表。数据空间听起来也是”把数据弄到一起”，方案里顺手就写成了数据中台的升级版。
但这两件事的底层逻辑完全相反。数据仓库是把数据搬到一个地方，集中管理；而数据空间不一样，它的逻辑是数据不动，价值流动。参与方各自守着自家的数据，通过连接器按约定权限交换，谁的数据还是谁的。如果把数据空间按数据仓库的思路建，建出来的就是一个更贵的数据库，数据提供方没有动力参与，因为把数据交出去对他们只有风险。我见过一个类似的项目，立项时基本是按照“数据中台”的思路写方案，先见大一统的平台，然后让各个委办局把数据汇聚上来，但是项目运行了几个月，能把数据交上来的委办局屈指可数，为啥？大家担心数据失控，谁都担不起这个责任。
所以说，如果看这篇文章的人里有售前工程师或者咨询顾问，当你拿到某个可信数据空间的招标文件或者需求文件时，认真的看一下对方要的是什么。然后回头看自己的方案（评标的专家也可以参考）：方案里如果写的是”汇聚、归集、集中治理”，那大概率还在数据仓库的思维里，哪怕你的方案标题是“xxx可信数据空间建设方案”，并且前面说了一大堆的政策导向和需求痛点，那么这个方案还是一个数据仓库或者数据中台的方案改了改而已。我认为好的方案里可能反复出现的会是”连接、交换、授权、可控”，这样的方案应该才是对路的。
误区二：为了技术而技术
可信数据空间这几个字里带”可信”，很多人下意识就把区块链和隐私计算都塞进来，觉得不上链、不做隐私计算，方案就不够”可信”。
区块链在数据空间里确实有它的位置：做信任锚点、做存证、做跨机构之间的共识记录。但它不是用来存业务数据的，更不是把每次数据交换都写到链上。隐私计算也一样，它解决的是”对方能看到计算结果、但不能看到我的原始数据”这类场景，比如两家机构联合建模但谁都不想交出底数。问题是，很多数据共享场景里，参与方本来就可以看明文。政务数据在授权范围内共享，需要的是权限和审计，不是把数据包在隐私计算的黑盒里算一遍。
我见过一个方案，编写单位是国内的某地方大型IT企业，方案是某市的可信数据空间见识，但是具体到方案层面，到处是把数据共享的每一步操作都设计成链上交易，但是不知道写方案的人是否想过，一笔链上交易的确认时间要花很长时间，客户根本无法使用。隐私计算一样，要先部署一套专门的集群，联邦学习还要各家机构都有建模能力；技术嵌套叠加的越多，性能、成本、运维压力就越大，技术每多一层，负担就多一分，而业务价值未必增加一分。我举一个例子，在一个医疗共同体建的数据空间中，隐私计算要求接入方的节点有多张N卡来完成联邦学习，但是这个硬件成本是很高的，参与方把服务器环境搭起来的费用怎么出，节点谁来维护，这些都是问题。
最早提出可信空间实践标准的是欧盟，他们的EDC方案是联邦式的，也没有强制使用某项技术，而是用SPI的方式根据自身情况扩展。当然，在中国的环境下，区块链和隐私计算确实可以充当数据空间的信任底座，也是很好的技术选型，但不能把技术底座当做业务通道。
误区三：只建平台，不建运营
这是试点项目里最常见的死法。平台建好了，验收通过了，然后呢？没有运营团队，没有数据提供方的激励机制（为啥要提供数据，总得有点利益吧），没有持续的场景迭代（这个到底有少用？），这样的平台可能用不了几个月就沦为了一个”展示系统”，谁都不用它。这个方面的例子就太多了，不用说数据空间，很多项目建设期是两年，验收一过基本就结束了，数据提供方没有激励设计、使用方没有约束设计、监管方和服务方都没有，场景设计更是大难题，最后平台可能只剩下初期演示时设计的那几个场景。
我想说，数据空间本质上是”活”的基础设施，不是交钥匙工程。它需要有人持续地拉数据方进来、撮合供需、处理纠纷、迭代规则。平台建起来只是起点，运营才是常态。立项的时候如果只批了建设费没批运营费，那这个项目从立项那天起就在倒计时。而我见过的一些好的方案，在预算时技术平台的建设费用大概只占30-40%左右，剩下的大部分留给了运营，这样的方案设计是值得借鉴的。
误区四：忽略标准与合规，把”合规”当成验收后的事
先说清楚，合规这件事已经不是”最好做”了，是”必须做”。数据安全法第二十一条白纸黑字写着，国家建立数据分类分级保护制度；2025 年 1 月 1 日施行的网络数据安全管理条例，又把分类分级、数据保护这些要求细化了一层；如果方案里用了区块链，区块链信息服务管理规定要求网信办备案；如果涉及政务系统和关键基础设施，还要过等保、要用国密，密码法和商用密码管理条例都写得明明白白。这一整套下来，合规不是加分项，是准入门槛。
我见过一些项目，数据分类分级、数据安全、国密算法、备案要求，这些东西很多项目是等到验收前才想起来补。结果就是：平台功能都通了，安全评测不过，或者被监管问询，上线时间一拖再拖。朋友公司做的要给项目，是一家省属单位的数据空间，功能全部开发完才开始做安全评估，发现数据分类分级没做、国密算法不满足要求。上线时间推迟了四个月，附带的一个问题是当初做规划的时候没有这笔预算，最后搞得甲方乙方都很头疼。所以，写方案的同仁或者做评审的专家，一定要看看方案里合规这块是怎么写的，考虑周全了没有，预算留够了每一欧。
记住，合规不是验收清单上的一项，它是数据空间能不能让数据方愿意参与的前提。数据提供方愿不愿意把数据拿出来，第一个看的就是你这边的合规底线是否清晰。合规设计应该从需求阶段就进去，而不是最后补。
误区五：技术选型被供应商绑架
很多试点单位不懂技术，选型基本靠供应商说。供应商说什么好就买什么，最后建出来的平台绑死在某一家上，后面想换组件、想对接别的系统，处处受制。
这个误区很多大型项目都有，很多决策人本着“大干快上”的想法，一上来就采购了供应商一整套”全家桶”。然后第二年发现问题了，他们想和另一个行业数据空间对接，发现接口全是私有协议，只能回头找原厂商，报价直接翻倍。尤其是有些既有硬件又有软件能提供全套解决方案的大厂，他们能给你全家桶的方案，客户发现一起软件采购省了很多钱（有的地方甚至能0元中标），然后发现软件是闭源的，并且和供应商的服务器环境深度绑定，买服务器？好的，以前软件的损失硬件补。
可信数据空间这个赛道，技术还在快速演进，选型最怕”锁死”。判断标准很简单：你的底层是不是开放的、接口是不是标准的、将来能不能换掉其中一块而不至于推倒重来。凡是”必须用我们全家桶”的方案，建议多问一句：换了怎么办？
误区六：一上来就大而全，没有最小可行起步
规划写得很完整，五大平台、十几个场景、三年三步走。结果两年过去了，一个场景都没真正跑通。我看到过一个项目，当地大数据局投资了数千万建立一个项目，规划了五大平台，希望能上几十个场景，计划建设三年。但是真正运行起来，一个场景都很难真正跑通，后来把很多开始规划的场景都砍掉了，初期下力气把“不动产登记数据共享”这个场景跑通了，大家看到了这个东西用起来了，数据确实安全的共享了，没有出问题，其他委办局才敢上，接下来才把一个个真实的场景加进去。
数据空间不适合”一步到位”。它适合先选一个真实的小场景，把链路跑通，让参与方看到实实在在的价值，再往外扩。一个跑通的小场景，比十份精美的规划方案更能说服数据方加入。最小可行不是偷懒，是数据空间这种多方协作系统唯一现实的起步方式。
误区七：只想着数据需求方，忽视了数据提供方
我认为做数据空间的人，天然就应该站在”用数据”的立场上，应该每天想的都是是怎么让数据流动起来、怎么让需求方拿到更多数据。
要实现这一点，我认为场景和应用绝对是可信空间真正发挥作用的地方。但是做过信息化项目的同行都知道，乙方（信息化解决方案供应商）懂得是技术，但是不了解甲方的业务。这里最缺的是能把可信空间的技术给甲方的业务人员讲明白的人，让他们知道这是个啥、能怎么用、能解决什么问题。一些数据空间的项目也存在类似的问题。一个数据空间的方案里，场景设计了一大堆，金融风控、精准营销、城市治理，全是站在需求方角度。但没有任何机制回答”数据提供方凭什么把数据拿出来”。平台上线后，需求方想用数据，发现没有数据可用。
但数据空间能不能转起来，卡点从来不在需求方，而在提供方。数据提供方凭什么把数据拿出来？安全怎么办？收益怎么分？责任怎么划？这些问题不解决，提供方就会一直观望。有不少项目都是平台侧热火朝天，数据侧冷冷清清，就是因为从头到尾没人认真回答过”数据方为什么愿意”这个问题。
误区八：把验收当终点
你见没见过这样的项目，项目验收了，团队撤了，运维外包了，然后项目就进入了”没人管”状态，几年过去了，甲方开始盘点信息化资产，发现还有这么个项目，一查每年还要给这个项目的服务器资源付好多钱，但是上面的数据都是当初验收时跑的Demo，之后就再没有数据了，甚至连供应商都找不到了。如果项目验收后，只是把运维外包给一家公司，合同里只写了”保障系统可用”。而场景迭代、数据方运营、规则维护没人管，基本上一年以后，这个空间成了没人用的摆设。
数据空间不是验收完就结束的产品，它是需要持续演进的基础设施。场景会变，数据方会变，规则会变，技术也会变。验收只是项目阶段的结束，不是数据空间生命的结束。一个数据空间建完之后三年还在迭代，说明它活下来了；建完之后就没人动，说明它已经死了，只是还没埋。
误区九：忽略跨域互通，建成一个孤岛
很多试点是”一亩三分地”思维，平台按自己的标准建，接口按自己的习惯定，最后建出来的数据空间只能在自己这一亩地里转。这里我想特别提一下欧盟的EDC项目，这是一个Eclipse基金会在运维的开源项目，他们的思路是用“连接器”把可信数据空间的参与方“连起来”，技术方案只提供接口标准、定义了数据交换的协议，具体实施时各个参与方只要遵循协议就可以完成身份验证、数据查询、数据交换，并且所有的数据交换规则都是可以按照规则写在交换协议里的，这最大化的保证了各个参与方接入的标准化和技术的兼容性。反观一些失败的案例，一些城市的可信数据空间，平台接口和标准全按自己的习惯定，之后国家推进城市间数据互通，发现要和兄弟城市对接，改造量几乎等于重新建一遍。
可信数据空间的最终价值，就在跨域：跨城市、跨行业、跨机构。如果每个试点都各建各的、标准不一、接口不通，那这些空间将来就是新的数据孤岛，只不过从”系统孤岛”变成了”空间孤岛”。建的时候就要想着将来怎么和别人互通，连接器、标准、接口都要按开放的原则设计。
误区十：核心业务人员没有深度参与
最后这个，可能是前面九个的根因。数据空间建设要动的是跨部门的数据、跨部门的利益，这绝不是信息中心一个部门能推动的事。没有一把手出面，数据协调不了、机制建不起来、运营落不了地。很多数据空间项目，牵头单位是区大数据中心。跨部门的数据协调不动，各委办局互相观望，项目推进一年，能拿到的数据还是最初那两三个部门的。这个不仅是可信数据空间项目遇到的问题，很多其他设计跨部门和组织信息互通的项目都有这个问题。要知道像大数据中心这样的单位，他们在各个政府单位和企业中都很难有协调业务部门的能力，并且这个部门的人，从进入之初就是“技术专家”的身份，他们对网络、软件、服务器这些可以说是头头是道，但是具体到业务侧，银行内不同部门的业务需求是什么、政务体系内各委办局办事的流程是什么，这个就是他们的短板了。
我见过的做得好的项目，几乎都有一个共同点：牵头的人是能拍板的人、是业务上的专家。数据空间建设本质上是一场组织变革，技术只是载体。组织保障不到位，再好的技术方案也是白搭。
写到这里，回头看朋友那个问题：怎么才能不把数据空间建废？我认为，没有一个动作能保证它不废，但避开上面这些坑，至少能让它活下来的概率大很多。数据空间这条路，我自己也还在走。上面说的这些误区，有几条我自己当年也踩过，今天写下这些也是给自己提个醒。
最后我想说，做信息化项目的人都知道，很多项目不是你想怎么做就怎么做的，有很多项目都存在“不得已而为之”的情况，这一点我承认，不光中国是这样，其他国家我认为也一样，但是健康的市场并不总是劣币驱逐良币，最终会用真金白银来投票，我们做的事情有价值，自然就会有回报，这应该是社会运行的基本法则和规律。今天写的这十个误区，我觉得其中有一些不只是可信数据空间这类项目有，有些可能是共性的。但是，回过头来说，我一直认为软件行业本质上是一个“服务行业”，我们的存在就是为了给客户解决问题，它和“盖好一栋房子、做好一道菜”没有本质上的区别，房地产上盈利的本质是房子盖的好，饭馆生意好的本质是菜好吃，可信空间项目做的好，是因为它能让数据流动起来产生价值。