可信数据空间建设指南：隐私计算、使用控制与三层架构选型

简介：《数据要素化新阶段的数据基础设施白皮书》是一份面向数据要素研究者、政策制定者、数据基础设施从业者及高校师生的专业PDF文档，聚焦国家数据基础设施的理论、政策与实践，回应数据大规模、高通量、快速率流通与全流程动态安全并重的现实问题。内容围绕数据可信流通利用基础设施展开，涉及“数由空间”“数由器架构”、隐私计算、区块链、数据空间等技术路径，并讨论流通数据冰山模型、公域数据耗尽趋势，以及城市、行业、企业和跨境四类数据基础设施实践，兼顾隐私保护与合规约束。资源包共1个文件，为PDF格式，大小3.06MB，单文件结构便于检索、引用和按章节研读。目前已有44人学习下载，适合需要把握国家数据基础设施建设框架、技术路线与落地案例的读者参考。

1. 从一份 2024 年 11 月的白皮书说起：它解决的是“安全外挂”这个老毛病

某次方案评审上，一位做数据流通的同行被问了一句：你方案里的安全，是长在架构里的，还是事后挂上去的？他当场没答上来。这份 2024 年 11 月发布的《数据要素化新阶段的数据基础设施白皮书》，核心就在回答这个问题——它把数据要素化背景下的数据可信流通利用基础设施，从概念、总体框架、技术组件一路串到城市、行业、企业几类落地场景，把“数据自由”这个偏愿景的词，拆成了可以对着验收的技术清单。它适合三类人：正在写数据流通或数据空间方案的技术负责人，要做隐私计算与使用控制选型的架构师，以及需要向非技术侧解释“为什么要建这套东西”的售前和产品。它不教你敲命令，更像一份带参数、带边界、带时间表的选型底稿，读法和普通技术文档不太一样。

2. 冰山模型与公域数据耗尽：白皮书为什么把问题算得这么“悲观”

很多人对数据要素的第一反应是“数据很多，随便用”，白皮书偏偏先泼一盆冷水：能被你拿到的数据，比你以为的少两个数量级。这一章把它的论证链条拆开看，因为这决定了后面所有技术选型的起点——如果问题不是“数据不够多”而是“高价值数据不敢动”，那你上再多的采集和爬取工具都是白费。

2.1 三个数字撑起的问题定义：20%、4%、80%

白皮书用了一个冰山模型来切分全球互联网上的数据。露在水面上的“可流通数据”约占全部数据的 20%，水下 80% 属于不可流通数据；而在这 20% 的可流通数据里，真正能在万维网上被搜索引擎抓到的，只占 4%，剩下 96% 沉在深网里，深网中 90% 以上是私域数据。

把前两行乘一下，你会得到一个很刺眼的结论：按白皮书自己的统计方式，公开可索引的数据只占全部数据的 0.8% 左右。这个乘法原文没有直接写，但逻辑是原文给的。它解释了一个很实际的现象——凡是靠“爬公开网页”起家的数据团队，做到一定规模必然撞墙，不是技术不行，是池子就那么点大。

提示：这组比例是白皮书援引的行业估算，不同机构口径差异很大，别拿它当精确统计用。它的价值在于给出一个量级判断：公开数据是入口，私域数据才是存量。

对做方案的人来说，这三个数字真正的用处是改写你的问题陈述。原来你写“我们需要更强的数据采集能力”，现在应该写“我们需要在不出域、不泄露原始数据的前提下，让 80% 那部分数据参与计算”。前者买爬虫和调度，后者买隐私计算、使用控制和数据沙箱——预算科目完全不同，评审时被追问的概率也完全不同。

2.2 从互联网爬取到物联网生成：数据生产方式的两次转向

白皮书把数据生产方式的迁移拆成两个方向，这个拆法比很多只讲“数据量爆发”的材料要具体。

第一个方向是往广度走：从互联网爬取，转向物联网设备自动生成。可穿戴设备、智能家电、道路监控、工业互联网感应装置，每时每刻都在产出非结构化数据，这类数据已经成为当前数据来源的主流。但这里有个断层——非结构化数据本身不是高质量数据集，中间必须过一道专业化的数据标注与合成。我见过不少项目把“接入了 5 万个摄像头”当成成果，结果模型训练阶段发现标注成本比采集成本高一个数量级。白皮书把标注与合成点出来，是在提醒你：数据生产链的瓶颈早已从“采”挪到了“洗”和“标”。

第二个方向是往深度走：从公域数据转向私域数据。白皮书援引的判断是，随着大模型训练需求暴涨，可供训练的优质公域数据预计在 2028 年前后接近耗尽，原先因为涉隐涉密被尘封的私域数据，正在变成高价值数据集的主要来源。这个预测本身可以讨论，不同口径的估算差别很大，但方向值得重视：越是高价值的语料和业务数据，越是被合规和隐私两道锁锁着。

注意：把“公域数据即将耗尽”当成采购理由要谨慎。它是一个趋势判断，不是可用性承诺；真正落地时你要回答的是“我的业务场景缺哪一类数据，这类数据现在卡在谁手里、卡在什么合规条款上”。

这两次转向对项目的直接影响是：数据集的构建路线要从“广度优先”改成“深度优先”。广度优先的典型动作是扩充爬虫集群、加代理池、做去重；深度优先的典型动作是找数据持有方谈授权、建可信执行环境、设计数据不出域的联合建模流程。前者是工程问题，后者是合规加架构问题，用同一套人马和同一套预算去做，翻车概率极高。

2.3 把结论落到自己的项目上：一张自检表

白皮书的价值不在于让你认同它的判断，而在于让你用它的框架反问自己。下面这张表是我在读完之后整理的，建议在立项评审前对着填一遍，答不上来的那一行就是你的风险点。

第三行值得多说一句。白皮书提到“一次交易一次建立链路”是当前数据流通成本高企的核心原因之一，很多企业每次合作都要重新谈接口、重新做脱敏、重新搭环境。这件事在没有基础设施的情况下无解，因为每次都是定制项目；只有当接入侧有了标准化的接入点，链路才可能被复用。这就是后面第 4 章那套三层架构要解决的问题。

3. 从“车厘子自由”到“数据自由”：把冷链类比拆成技术栈

白皮书里最有传播力的部分，是用“车厘子自由”讲“数据自由”。很多人读完只记住了这个比喻，忽略了比喻背后的技术映射其实相当严谨：冷链不是一项技术，而是一组技术加上一套基础设施化过程；数据流通也一样，指望某一个隐私计算框架包打天下，注定失败。这一章把这个类比逐层拆开，落到具体组件和参数上。

3.1 冯诺依曼架构里缺的那块：安全为什么总是外挂

白皮书的论证起点很硬：现代计算产业架构来自 1944 年提出的五部分结构——控制器、运算器、存储器、输入设备、输出设备。近八十年里，芯片、终端、云平台形态换了无数轮，但这五个部分的划分基本没动过。问题就在这里：这套架构里没有“安全单元”。

后果是安全功能只能外挂。外挂带来的不只是性能损耗，更是技术、产品、产业、管理四条线上的脱节：一边是操作系统、计算芯片、存储芯片的产业，另一边是认证、隔离、密码的信息安全产业，两条线各自演进，接口靠打补丁对齐。你在项目里遇到的“加个加密网关吞吐掉一半”“上了脱敏之后下游全要改字段”，根子都在这儿。

理解这一点，才能理解白皮书为什么反复强调“动态全过程安全”。在静态安全阶段，做法是分级保护、等级保护、认证保护、密码保护、隔离保护，本质是限制流动，追求“进不来、看不懂、拿不走、可溯源”。这套思路在数据不怎么流动的年代没问题，但数据要素化要求大规模、高通量、快速率流通，把数据锁死等于把价值锁死。所以安全范式必须从“围栏”转向“随行”——数据流到哪，管控跟到哪。

这里有个容易混淆的点：动态安全不是“不要静态安全”。等保、密评这些该做的还得做，它们是底座；动态安全是在底座之上，增加对“使用过程”的管控能力。我一般会把两者画成两层：下层是合规底线，上层是流通使能。评审时先说清分层，能省掉很多无效争论。

3.2 冷库、冷藏车、保温盒：三类设施对应三层技术

冷链物流的技术栈是分层的：冷库负责产地和销地的恒温仓储，冷藏车负责中长距离运输，保温盒负责最后一公里。三层解决的是同一个物理问题在不同尺度上的表现。数据侧的分层结构几乎是同构的。

白皮书给出的整体方案正是三层：接入点、基础能力平台、管理服务平台，再辅以动态安全防护和统一服务对接。接入点负责把多方数据源安全可靠地接进来，是“第一道关卡”，它的可靠性直接影响整个空间的效率；基础能力平台提供可信管控、资源互通、共性服务三类能力；管理服务平台做全局目录、供需撮合和运营。

提示：三层里最容易被砍掉的是管理服务平台，因为它不直接产生计算能力。但没有全局目录，接入点就退化成点对点专线，链路复用无从谈起，“一次交易一次建链”的老问题原样回来。

3.3 保鲜技术对照：四类保鲜手段与四类流通技术

冷链里真正决定货架期的，是保鲜技术：真空预冷、气调、辐照、臭氧，各自针对不同的腐败机理。数据侧同样没有银弹，不同技术解决的是不同威胁模型。

白皮书列出的可信管控技术主要是三类：使用控制、隐私计算、数据沙箱。使用控制的做法是预先设置数据使用条件形成控制策略，依托策略实时监测使用过程，动态决定数据操作的许可或拒绝；隐私计算允许在不泄露原始数据的前提下做分析和计算，常见路线有多方安全计算、联邦学习、可信执行环境、密态计算；数据沙箱则是构建应用层隔离环境，让使用方在受控区域内处理数据。

资源互通侧是另外三项：数据标识（给数据资源分配唯一标识符，实现检索定位和全生命周期可追溯）、语义发现（自动分析数据深层含义与关联性，做智能索引）、元数据智能识别（格式转换与属性关系重定义，保证跨系统一致）。共性服务则是接入认证、可信存证、资源目录。

这九项技术经常被销售打包成“一套解决方案”，实际上它们的成熟度和成本差得很远。我的经验是：使用控制和数据沙箱最容易先落地，因为不改数据本身；隐私计算的性能代价最大，适合放在确有必要的高价值场景；数据标识和元数据识别看着最不起眼，却是跨空间互认的前提，越晚做越痛苦。

3.4 三步走时间表：100 倍资源消耗怎么降到 3 倍

白皮书没有回避现实：当前用隐私计算方式传输和计算密文数据，资源消耗是明文传输的 100 倍，效率不到明文的十分之一。这个量级意味着什么？意味着你把一个日处理千万级请求的业务直接套上密态计算，机器成本会涨两个数量级，延迟会让业务方直接否决方案。

所以白皮书给了一个分三阶段的路线，每个阶段都有可量化的判据：

这张表最实用的地方，是给了你一个验收门槛。当供应商说“我们的隐私计算性能很好”，你可以直接问：相对明文的资源消耗倍数是多少，效率达到明文的几分之几，测的是哪类算子、多大数据量、什么网络条件。答不上来的，基本可以判定为演示级产品。三年 3 倍、1/5 效率这个目标，也可以作为你内部立项时的中期指标——如果当前方案离这个数量级差太远，就不要指望靠调优追上，得换路线。

4. 可信数据空间的三大能力与四类角色：照着这张表搭

白皮书对可信数据空间的定义是：基于共识规则，联接多方主体，实现数据资源共享共用的数据流通利用基础设施。这个定义里每个词都能展开，但真正能拿来干活的是后面的“三大能力 + 四类角色”。这一章把它翻译成可验收的问句和可填写的表格。

4.1 三项能力拆成可验收的问句

白皮书列的三项核心能力是可信管控、资源交互、价值创造。原文描述偏概括，落地时容易变成“我们也要建一个空间”这种空话。我习惯把每条能力转成一个必须回答“是”的问句：

第一行是最容易被糊弄过去的。很多项目号称做了可信管控，拆开看只有一套 RBAC 加一个审计日志，缺的是“策略实时生效”这一环。使用控制的本质是策略引擎加执行点，策略写得再漂亮，执行点不在数据通路上，就等于没有。

第三行常被当成商务问题甩给法务，其实它有技术对应物：计量与存证。没有对“数据被用了多少次、用在什么目的”的可靠计量，收益分配就是拍脑袋，提供方迟早退出。

4.2 四类角色的职责边界表

白皮书划了四类参与角色，这个划分看着平淡，实际是合规审查的第一道门槛。

第二行和第三行的组合是最危险的：使用方把加工结果再分发，而加工结果本身可能还原出原始信息。技术上要靠差分隐私、聚合阈值、结果审查来兜，光靠协议约束不住。第四行在很多地方项目里是真问题——监管角色缺位时，空间运营方就会同时扮演规则制定者和受益者，这种结构在合规审查阶段很难通过。

注意：角色分离不是形式主义。同一法人在同一空间内兼任提供方和运营方，至少要引入第三方存证和独立的策略审计，否则一旦出现数据超范围使用，责任无法切分。

4.3 资源目录的字段设计与对接约定

资源交互能力的落地形态就是资源目录。白皮书说它要“按照统一接口标准建设，提供数据、服务等资源的发布与发现能力，可同时被多个可信数据空间使用”。这句话翻译成工程语言，就是你要定义一套字段，并且字段设计要经得起跨运营方对接。

下面是我按白皮书要点整理的一份目录条目模板，用 YAML 写，方便直接放进接口文档：

# 资源目录条目模板：字段名保持英文，取值约定保持稳定可比 resource_id: "urn:ds:city-a:traffic:2024:0001" # 全局唯一标识，建议 urn 风格，含运营方与域 title: "城区路口信号配时统计" # 人类可读名称，仅用于展示 provider: "org:city-a:transport" # 提供方主体标识，与接入认证体系对齐 resource_type: dataset # dataset / api / model / service capability: # 可用计算方式，决定使用方怎么接 - desensitized # 脱敏后可出域 - sandbox # 仅在沙箱内可用 - mpc # 支持多方安全计算 sensitivity_level: L3 # 分级，与提供方内部定级映射 schema_ref: "schema:traffic-signal:v2" # 指向元数据定义，避免字段各说各话 access_policy: # 使用控制策略，下发到执行点 max_calls: 1000 # 调用次数上限 expire_at: "2025-06-30" # 授权到期时间 purpose: "交通拥堵分析" # 用途限定，配合审计比对 proof_endpoint: "https://proof.example.org/v1" # 存证接口，全过程记录上链锚定 semantic_tags: ["交通", "信号配时", "城市治理"] # 供语义发现做关联与检索

几个字段值得单独说。resource_id用 URN 风格而不是自增数字，是因为跨运营方对接时你无法保证编号不冲突，URN 里带上运营方与域，天然去重。capability是数组而不是单值，因为同一份数据可能既支持脱敏后出域，也支持在沙箱内做联合分析，使用方按自己的能力选择路径。schema_ref指向独立的元数据定义，这是元数据智能识别要解决的问题——把属性、关系、规则重新定义一遍，保证不同系统里的同一个字段含义一致。

access_policy这一段是使用控制的落地位置。次数、期限、用途三件事必须同时写，只写其中一两项的策略基本没有约束力。proof_endpoint则对应可信存证，白皮书的要求是保存数据流通全过程信息记录且不可篡改，为清算审计、纠纷仲裁提供电子证据。全过程四个字是关键，只存最终结果在纠纷场景下毫无用处。

4.4 接入点、能力平台、管理平台三层分工

白皮书描述的架构是三层加两条纵向能力。落地时最常被问的问题是：这三层分别部署在谁的机房里、由谁运维。我的回答通常是按数据边界来切。

接入点放在参与方侧，这是整个架构里最关键的一个决定。它意味着数据不出本方机房就能参与计算，合规压力小得多；也意味着接入点的可靠性直接决定体验，网络抖动、证书过期、策略版本不一致，都会在接入点暴露。基础能力平台放在节点侧，是为了让算力和沙箱能力被多主体复用，避免每家都自建一套隐私计算集群。管理服务平台放中心侧，做全局的事，它不碰原始数据，只碰目录和存证。

两条纵向能力——动态安全防护和统一服务对接——是横切的。动态安全贯穿三层，从接入点的传输加密到平台侧的沙箱隔离再到运营侧的审计；统一服务对接则负责和外部体系衔接，比如合规数字证书、区块链存证、数据交易所。这两条在架构图上最不起眼，实际工作量最大，因为它们要和一堆外部系统对齐接口和字段。

5. 避坑清单：五类翻车现场与排查顺序

白皮书是理论加实践的综合体，读起来很顺，但把它搬到项目上时，坑几乎都集中在“技术选型和场景不匹配”以及“角色和边界没切干净”这两类。下面五条是我在实际对接中反复见到的，按现象、原因、解决三段写，方便你直接对照排查。

5.1 全量上密态计算，POC 通过但上量就崩

现象：小样本 POC 跑得很漂亮，接真实流量后 CPU 打满、端到端延迟涨十倍以上，业务方当场否掉方案。

原因：白皮书给的数字很明确，密文传输计算的资源消耗是明文的 100 倍量级，效率不到十分之一。POC 阶段数据量小、并发低，这个倍数被掩盖了；上量之后乘数效应直接体现。

解决：做分级通道，不要一刀切。明文通道走公开或低敏数据，脱敏通道走需要保留统计特征的场景，密态通道只留给真正高价值、且确实不能出域的那部分。分级的依据是敏感级别加场景必要性，不是技术先进性。同时把 3.2 节那张能力表拿出来，逐条确认哪些场景非密态不可。

5.2 买了一个可信执行环境，就宣称空间建成

现象：验收材料里写“已具备可信管控能力”，实际只有一台 TEE 机器和一套准入名单，数据流通过程中的操作无法拦截也无法追溯。

原因：三大能力里，TEE 只覆盖可信管控的一小部分，且它保护的是运行时环境，不解决“谁在什么目的下用了多少次”的问题。资源交互和价值创造两项能力完全缺失。

解决：按 4.1 节的验收问句逐条过。特别要确认策略执行点是否在数据通路上，以及存证是否覆盖全过程而非仅结果。TEE 可以作为能力平台的一个组件，但不能当作能力本身。

5.3 两个空间对接，字段对不上直接返工

现象：和另一个运营方的空间做互联，发现同一份“企业能耗数据”在两边分别是字符串和数值、单位一个千瓦时一个兆瓦时、时间粒度一个按日一个按小时，联调两周没打通。

原因：缺少统一的数据标识与元数据规范。白皮书把数据标识、语义发现、元数据智能识别列为资源互通技术，就是冲着这个问题去的。很多项目先建目录后定标准，顺序反了。

解决：先定 schema 再建目录。资源目录里的schema_ref必须指向受控的元数据仓库，字段变更走版本号；标识用 URN 风格带运营方前缀。对接前先做一次字段映射演练，把冲突项列成清单，比联调时抓瞎强得多。

5.4 存证只存结果，纠纷时拿不出证据链

现象：出现数据超范围使用的争议，平台能证明“某次调用成功”，但拿不出调用前后的策略版本、授权依据和数据处理轨迹。

原因：可信存证的要求是保存流通过程的全过程记录且不可篡改。只存成功日志，等于只留了结论没有过程，无法支撑清算审计和纠纷仲裁。

解决：存证范围覆盖策略下发、策略变更、每次访问的上下文、结果交付四个节点，每条记录带时间戳和操作主体标识，并做链上锚定或第三方时间戳。存证接口在资源目录里就要暴露出来，别等出事再补。

5.5 提供方兼运营方兼监管方，合规审查卡住

现象：方案里同一家单位既提供数据、又运营空间、还负责监督，评审时被要求重新划分角色。

原因：四类角色的划分是为了让权利、义务、责任可切分。三者合一之后，一旦出现超范围使用，无法判断是提供方授权过宽、运营方执行不力还是监督缺位。

解决：至少做到运营与监管分离，监管角色由第三方或主管部门授权主体承担；提供方与运营方如果必须是同一法人，引入独立第三方存证与策略审计，把“谁改了什么策略”记录成不可抵赖的证据。这一条改起来最麻烦，但它是前面所有技术手段能否被信任的前提。

6. 把它当“选型底稿”用：三个具体技巧和一条引用规矩

这份白皮书最常见的误用，是被当成汇报材料读完就放进网盘。我的做法是把它当底稿，配合项目文档一起用，具体有三个技巧。

第一个是建一张“能力—技术—组件”三列映射表。左列抄白皮书的三大能力和九项技术，中列写你项目里对应的实现方案，右列写具体产品和版本。填不满的格子就是你的缺口，填了但写不出产品名的，多半是纸面能力。这张表在评审时非常好用，因为它把“我们很重视安全”这种话逼成了可核对的条目。我一般还会加第四列“验收方法”，写明这一项用什么测试验证，比如策略生效用一次故意越权的调用来验。

第二个是用参数目标当技术门槛。白皮书给的三年目标是资源消耗降到明文 3 倍左右、效率达到明文 1/5，这个量级可以直接写进选型要求。问供应商时不要问“性能好不好”，要问“相对明文的倍数是多少、测的什么算子、多大数据量、什么网络条件、有没有第三方报告”。答得含糊的，基本可以判定还在演示阶段。同时把当前 100 倍这个基线记住，任何声称已经接近明文性能的方案，都值得要求现场复测。

第三个是按场景挑章节精读。城市、行业、企业三类场景在技术组合上侧重不同：城市侧偏交通与金融，重资源目录和跨部门互认；行业侧偏医疗与公共安全，重沙箱和联合建模；企业侧偏内部数据与外部数据的安全交换，重接入点和策略执行。读的时候直接跳到对应章节，把里面的技术组合抄成自己的架构草图，比从头读到尾效率高得多。我自己是把这几类场景的架构图各打印一份，开会时直接在上面圈改。

还有一条规矩得单独说：白皮书的版权声明明确要求，在其它作品、研究、报告、演示中引用其内容时，须标明出处并确保引用准确。我吃过一次亏——早期做的一份方案里引了它的冰山模型比例，忘了标注来源，后来对外发布前被合规退回重改。从那以后我每次引用外部材料，都会在文档末尾强制走一遍来源清单，写清文件名、发布月份和引用页码，宁可比别人多花十分钟。这份白皮书也一样，引用它的比例、时间表和能力框架时，把出处带上，既守规矩，也让你的方案显得有据可依。

希望帮到你。

本文还有配套的精品资源，点击获取