引言：建设了平台，是否就形成了数据空间

在可信数据空间建设中，人们通常首先关注技术平台：部署连接器，建立身份认证系统，建设数据目录，配置数字合约、使用控制和日志审计能力。参与主体完成注册和接入以后，平台似乎就具备了数据空间的基本形态。

但在 IDSA Rulebook 2026-1 中，数据空间并不是先形成一个技术平台，再附加一套管理制度。IDSA 将数据空间定义为建立在约定治理框架之上的可信数据共享环境，同时包含政策、语义模型、标准协议、业务流程和支撑服务。技术基础设施只是其中一部分，不能单独定义数据空间。

几个组织部署了能够相互通信的连接器，并不必然形成一个数据空间；一个平台汇聚了大量数据资源，也不能仅凭拥有目录、合约和审计模块，就证明它已经具备数据空间的治理属性。真正需要回答的是：谁可以参与，谁有权制定规则，什么证据能够建立信任，数据按照什么条件共享，以及这些规则怎样进入具体业务和技术执行。

数据空间首先是一套共同规则，然后才是一套由技术支撑的共享环境。Rulebook 的作用不是替代参考架构、协议或连接器，而是在这些技术能力之前确定参与秩序，并在运行过程中持续约束身份、资源、交互、服务和责任。

传统数字平台通常具有明确的技术边界。组织完成注册、账户开通和权限分配后，就进入平台管理范围；数据、接口和业务活动主要发生在平台内部；平台运营者同时承担账户管理、资源组织和运行控制。

数据空间则不必具有统一的技术边界。参与者可以使用不同厂商的连接器和软件代理，部署在本地系统、云平台或边缘节点；资源目录可以集中建设，也可以采用联邦或分布式模式；实际数据可以通过文件、API、消息流、对象存储或者受控计算环境交付，并不一定经过运营方的中央系统。

因此，不能以是否接入同一平台作为判断组织是否属于数据空间的标准。IDSA 认为，数据空间真正的边界来自参与者共同接受的 Data Space Governance Framework。该框架由技术政策、业务规则和适用监管要求共同构成，是定义数据空间的核心约定。

从这一角度看，数据空间首先形成三种边界：规则边界决定参与者共同遵守什么；信任边界决定参与者需要提供哪些身份、资质和能力证据；交互边界则由连接器、目录、身份服务和合约协议把共同规则转化为具体业务。

成员资格也应放在这一逻辑中理解。成员凭证只能证明组织满足了空间的基础准入条件，不能自动赋予其使用空间内全部数据的权利。某项高敏感数据还可能要求使用方具备行业许可、伦理审批、安全计算环境或者特定地域属性。

因此，数据空间通常同时存在成员规则、访问规则、合约规则和使用规则。成员规则决定谁可以获得基础参与资格；访问规则决定谁可以发现或申请某项资源；合约规则决定双方按照什么条件形成协议；使用规则决定数据交付后允许怎样处理。

共同规则需要有人制定、维护和解释。IDSA 将承担这一职责的逻辑角色称为 Dataspace Governance Authority，即 DSGA。DSGA 代表数据空间的集体治理职能，负责提供基本治理框架，确定采用哪些 Dataspace Trust Framework，并在必要时定义业务过程、政策规则和最小共同语义。

DSGA 并不等于一个集中运行的平台，也不意味着所有身份验证、授权、合约和数据交付都必须经过中央系统。需要区分三个层次：DSGA 负责定义共同治理要求；运营和服务主体负责提供部分实施能力；参与者及其软件代理负责在具体交互中作出判断和执行规则。

例如，DSGA 可以规定空间接受哪些成员凭证和安全认证，但具体数据提供方仍然可以针对高敏感数据提出更严格的环境和用途要求。DSGA 确定的是共同底线，并不替代参与者对具体资源作出风险判断。

数据空间运营方也不天然等于 DSGA。运营主体可以负责成员服务、资源组织、场景培育和日常运行；技术服务商可以提供目录、连接器、身份、合约和审计能力；治理主体则负责决定空间目标、参与规则、信任框架和责任机制。

同一组织可以同时承担多项角色，但需要明确不同角色对应的权限和责任。如果平台建设者能够单方面决定成员准入、资源发布、信任规则和争议处理，数据空间就容易重新退化为由平台单方控制的数据交换系统。

DSGA 也不要求采用固定组织形式。在企业数据空间中，治理职能可能主要由链主企业承担；在行业数据空间中，可能由行业协会、核心企业和研究机构共同组成治理委员会；在城市数据空间中，也可能由数据管理部门、运营主体和行业单位分工承担。

去中心化同样不意味着不能使用公共服务。数据空间可以建设统一目录、成员接入服务和公共审计服务。真正需要避免的是这些服务成为不可替换的单一控制点，并使参与者失去对身份、数据和交易的本地决策能力。

治理规则如果只存在于章程、管理办法或者合作协议中，软件代理无法在运行过程中自动使用。系统需要在资源发现、身份验证、合约协商、数据交付和后续使用中判断：谁能够看到某项数据产品，谁有资格提出申请，需要出示哪些凭证，数据允许用于什么目的，以及是否需要记录日志、支付费用或者到期删除。

因此，治理规则需要进一步转化为机器可读政策。规则、政策和执行并不是同一个层次。规则是治理层提出的要求；政策是对规则的结构化表达；执行则是目录、身份组件、策略引擎、连接器、数据网关和受控计算环境按照政策作出判断并落实约束。

一项治理要求只有经过“制度定义—语义解释—规则结构化—身份与策略表达—合约协商—连接器执行—证据复核—治理反馈”，才能真正进入数据空间运行。

机器可读政策通常表达三类内容：许可说明参与者被允许执行什么；禁止说明不得执行什么；义务说明参与者必须完成什么。义务往往最难执行，因为系统不仅要在合约形成时记录义务，还需要在业务运行后持续判断义务是否已经履行。

政策还存在不同层次。空间级政策构成共同底线；参与者可以根据自身风险偏好增加要求；不同数据产品可以配置不同访问和使用条件；具体业务最终通过合约协商形成一组双方接受的政策。

访问政策决定参与者能否发现或查看某项数据资源，但能够看到数据存在，并不等于已经获得实际使用权。真正的使用权需要通过合约协商形成 Agreement。Agreement 应当关联数据资源、双方身份、许可、禁止、义务、期限、交付方式和审计要求。IDSA Glossary 将 Agreement 界定为与特定数据集相关、由提供方和使用方协商接受的具体 Policy。

规则执行也不只有一种方式。低风险数据可以主要依赖合同与法律责任；一般业务数据可以增加监控和审计；高价值数据可以通过 API 限制、加密和访问控制实施技术约束；高敏感数据还可以采用数据不出域的受控计算环境。

共同规则真正成为数据空间基础设施的标志，不是制度文件已经发布，而是它能够被软件识别、被参与者协商、被数据面执行，并由审计证据证明。

数据空间需要成员准入和身份认证，但完成认证并不意味着参与者获得了一个长期、统一且适用于所有业务的“可信身份”。IDSA 将信任定义为参与者针对一次具体交互，根据声明、凭证、政策和业务上下文，对另一方能否按照约定条件行动所作出的判断。信任具有场景、时间和目的范围，并由参与者在本地形成。

信任不是全局的。参与者在一项数据共享中被接受，不代表其可以使用空间中的所有数据；信任不是传递的，A 信任 B 并不意味着 A 必须信任 B 所信任的 C；信任也不是天然对等和永久有效的，双方可以提出不同证据要求，凭证到期、环境变化或风险上升都可能触发重新评价。

成员资格、安全认证和行业资质因此不再直接等同于信任，而是为信任判断提供证据。IDSA 采用基于属性的信任方式：参与者通过可验证声明证明身份、角色、资质、技术能力和运行环境；数据产品政策则规定当前业务需要满足哪些属性。

凭证的数字签名只能证明内容由某个签发方签发，不能自动证明该签发方有权证明相应属性。验证凭证包括两个层次：技术上判断签名、有效期和撤销状态是否正确；治理上判断签发机构是否被接受、凭证是否覆盖当前业务，以及属性是否足以满足政策。

Dataspace Trust Framework 正是用于规定哪些声明可以被接受，哪些机构可以作为信任锚点，属性如何与政策匹配，以及证据不足和规则冲突时如何处理。

动态信任通常按照“识别业务政策—确定所需属性—交换身份与资质凭证—验证凭证来源和状态—将属性与政策匹配—参与者形成本地信任判断—进入合约协商或终止业务”的过程形成。

对于长期API 调用、持续数据流和多阶段联合计算，信任还需要持续维护。凭证撤销、认证过期、处理环境迁移或者用途变化，都可能触发重新验证、暂停交付或终止合约。成员准入建立的是基础资格，可验证凭证提供信任证据，当前政策和业务上下文才决定信任能否成立。

在单一数据空间内部，参与者面对同一个治理框架。DSGA 可以规定协议版本、成员条件、信任框架和核心语义。跨数据空间互联则涉及两个甚至多个独立治理边界。

两个空间可能都采用相同的 DSP，却接受不同身份体系；都要求安全认证，却接受不同认证机构；使用相同政策词汇，却对责任和执行方式形成不同解释。因此，跨空间互联不能只依靠接口和协议完成。

每个空间首先需要具备可识别的身份和自描述能力。空间自描述应当说明：空间由谁治理，哪些主体可以参与，接受哪些身份与资质凭证，采用哪些信任锚点和信任框架，支持哪些协议版本，使用哪些政策与语义，以及争议和责任由谁承担。

空间自描述表达“这个空间要求什么”，参与者自描述表达“这个组织具有什么”。双方通过凭证、声明和政策匹配，判断是否具备进一步协作条件。跨空间身份互认也不应被简化为共享账户或单点登录，而应使另一个空间能够理解和验证参与者已经持有的法人身份、行业许可、安全认证和成员凭证。

不同空间之间可以形成三类有限互认关系：直接接受，即双方接受相同凭证、信任锚点和政策语义；等效映射，即规则或认证体系不同，但能够在特定场景中提供相近保证；附加约束，即原有条件不足以直接满足要求，但增加受控环境、审计、通知或使用限制后可以开展业务。

有限互认不是要求所有空间采用相同成员制度、身份体系和治理规则，而是在不取消各自治理自主性的前提下，找到一组能够共同接受的条件。

技术互操作只是其中第一层。IDSA 将数据空间互操作区分为技术、语义、组织和法律等方面。相同协议只能保证消息结构和状态交互，并不会自动消除成员制度、政策解释和法律责任的差异。[6]

因此，跨空间治理需要参与者适配，也需要不同 DSGA 之间建立治理桥接，包括成员规则比较、凭证接受范围、政策语义映射、合同责任和争议处理机制。这种桥接不是建设一个凌驾于所有空间之上的超级平台，而是围绕具体场景形成有限协调。

Rulebook 真正改变的，不是增加了若干治理术语，而是重新调整了制度、组织和技术之间的关系。

数据空间从“平台承载规则”转向“共同规则定义空间”。平台、连接器和目录只是规则的技术承载形式，空间边界首先由治理框架确定。

治理从“运营方统一管理”转向“治理职能、运营职能和技术服务职能相互区分”。DSGA 负责共同规则，运营主体组织日常活动，技术服务主体提供能力，参与者保留本地判断。

信任从“平台一次性背书”转向“参与者运行时判断”。成员资格和认证不再直接等于信任，而是作为具体交互中的证据。

政策从“制度文件中的条款”转向“可以被协商、执行和审计的运行链条”。政策需要贯通目录、身份、合约、交付、使用控制和证据。

互操作从“接口兼容”转向“不同治理边界之间的规则协调”。相同协议是必要条件，但跨空间业务还需要语义、组织和法律层面的协调。

这几项变化共同说明，数据空间不能被理解为一种新的数据平台产品。技术可以帮助执行规则，却不能代替规则的形成；凭证可以提供证据，却不能代替参与者的风险判断；相同协议可以连接系统，却不能自动解决治理差异。

Rulebook 也不是所有数据空间治理问题的最终答案。它不能替代适用法律和行业制度，不能自动生成具体业务规则，也不能使所有治理判断完全自动化。它更像一套治理骨架，帮助建设者识别哪些问题必须被规则化、哪些职责必须被组织化，以及哪些要求需要进一步进入技术执行。[7]

第一，在技术建设前形成最小治理框架。最小治理框架至少需要明确空间目标、参与边界、治理主体、成员条件、信任机制、数据共享流程和争议处理方式。项目不必等待所有制度完全成熟，但不能在规则完全缺位的情况下直接进入平台建设。

第二，建立“治理规则—业务流程—技术策略—运行证据”映射。例如，“只有具备特定资质的机构才能使用某类数据”，需要继续明确使用什么凭证证明，在目录、协商还是交付环节验证，验证失败怎样处理，以及哪些日志能够证明规则得到执行。

第三，明确治理主体、运营主体和技术服务主体的权责边界。即使同一单位同时承担多项职责，也需要说明哪些规则可以由运营方调整，哪些事项需要治理委员会决定，成员是否具有申诉权，以及运营方自身如何接受监督。

第四，把信任建设从一次性认证转向动态证据链。身份认证、行业资质、安全评估、连接器兼容和运行审计应当形成可验证、可更新、可撤销的证据，并根据具体业务、数据敏感度和使用目的进行组合判断。

第五，为跨空间互联预留治理接口。空间建设阶段就应形成可公开的规则说明、凭证接受范围、协议版本、语义模型、审计要求和责任机制，使其他空间能够识别其治理边界，而不是等到互联项目启动后再逐项人工解释。

第六，把 Rulebook 理解为持续治理机制，而不是一次性制度成果。规则需要随着业务场景、技术实现、监管要求和运行风险持续更新；更新过程本身也要有权限、版本、通知、生效和追溯机制。

IDSA Rulebook 2026-1 最重要的意义，是把共同规则重新放回数据空间体系的起点。一个数据空间需要说明谁能够参与，谁有权制定规则，什么证据可以建立信任，数据按照什么条件共享，以及不同空间之间如何形成有限互认。

目录、身份、数字合约、使用控制和审计并不是彼此孤立的功能。它们共同承担的是同一项任务：将共同规则转化为可以被参与者理解、被软件代理执行、被业务过程验证并被审计证据证明的运行机制。

因此，可信数据空间建设不应从“采购什么平台和连接器”开始，而应先回答“准备建立什么样的协作秩序”。技术系统能够支撑规则，却不能替代规则本身。

从空间内部的共同治理，到跨空间之间的有限互认：数据空间首先是一套共同规则，然后才是一套由技术支撑的共享环境。