我有一次在一个数据空间工作组的会议上，听到两个参与方吵起来了。
提供方说：”我们在协议里写得很清楚，数据只能用于统计分析，不能用于模型训练。”
使用方说：”技术上我怎么知道我用的是统计分析还是模型训练？你们的API返回的就是一个结果，我拿到结果后拿它干什么，你们管得着吗？”
这就是典型的”协议断层”，管理协议上写了一条规则，但技术协议上没有对应的执行机制。
数据空间的协议体系，必须同时覆盖两个层面：管理协议和技术协议。
管理协议：法律层面的”游戏规则”
管理协议做的事，是把”法律要素”转化为”可执行的规则”。
三个核心方面：
合约框架。 参与数据空间的每一个角色，需要签署什么样的加入协议？数据提供方的数据授权协议长什么样？使用方的合规承诺怎么写？这些不是简单的合同模板——它们需要被形式化为机器可读的结构化条款，才能在下层被技术协议自动执行。
强制性与非强制性条款。 不是所有规则都是”死命令”。管理协议需要清晰区分：哪些是所有人必须遵守的强制性义务（如”不得对个人数据进行重识别”），哪些是参与方可以自由约定的权利（如”数据使用费的定价方式”）。前者需要嵌入数据空间的底层治理架构，后者留给参与方在具体交易中协商。
协同协议设计。 这是管理协议中最有工程难度的一环。参与者角色、价值主张、法律框架、服务条款——所有这些维度需要在同一个协议框架下被”联合起草”，而不是每个参与方各写各的、最后冲突频发。
一个实际案例：在医疗数据空间中，管理协议需要规定”患者数据的使用范围”——A医院提供的数据集，B医学院只能用于联合科研，不能用于商业药物开发。如果B医学院违规使用，管理协议需要明确赔偿责任和纠纷仲裁机制。这些规则一旦经过注册，就写入数据空间的治理架构，成为所有参与者共同遵守的”空间宪法”。
技术协议：工程层面的”对接规范”
管理协议写了规则，技术协议负责执行。技术协议做的事情有三个层次：
接口规范。 数据空间中的每一个组件（连接器、控制器、数据目录、身份认证服务）都应该有标准化的API接口。A厂商的连接器能跟B厂商的连接器通信，不是因为两家写了兼容代码，而是因为它们都实现了同样的接口规范。这是互操作性的根本保障。
数据交换格式。 数据怎么打包？元数据怎么描述？使用控制策略用什么语言表达？在欧洲数据空间的实践中，最常见的选择是基于JSON-LD的数据封装格式和基于ODRL（开放数字权利语言）的策略表达语言。好消息是，这些已经经过数年实践验证，不必”重新发明轮子”。
安全协议。 传输加密的算法是什么？身份认证的握手流程是什么？存证数据的签名标准是什么？安全协议不是”选择一种加密方式”那么简单——它需要在通信性能与安全强度之间找到平衡点。比如，全字段加密保证了最高级别的数据保护，但会严重拖慢查询速度——技术协议需要在安全级别上预留弹性空间。
两套协议的衔接：从”说了”到”做了”
回到开头的那个争吵场景。管理协议写了”数据只能用于统计分析，不能用于模型训练”——但技术协议上没有对应的执行机制。结果就是：管理协议上的规则是一纸空文，技术执行上各方各说各话。
正确的做法是两套协议协同设计。管理协议在写规则的同时，就要明确”这条规则在技术上如何落地”——是用使用控制策略语言表达、是在连接器层面配置权限、还是通过隐私计算技术做”半透明”的数据使用约束。
管理协议解决的是”应该怎么做”的问题，技术协议解决的是”实际怎么做”的问题。两套协议缺一个，数据空间就跑不通——只有管理协议没有技术协议，规则落不了地；只有技术协议没有管理协议，系统没有行为准则。
数据空间的协议体系不是一份合同，是一个从”法律规则”到”工程执行”的完整传导链路。管理协议断了，规则是摆设；技术协议断了，系统是摆设。两端必须同时拧紧。
我是BSN联盟成员。有着十年区块链与隐私计算的产品开发和方案咨询经验，先后参与多个国家重大课题，亲手建过区块链、隐私计算、可信数据空间的落地项目。不追概念，写真的。