Data Act Interoperability for Data Spaces: The Standards Your Platform Will Be Measured Against

The interoperability chapter of the Data Act is the part everyone skipped while they argued about who owns the sensor data. It is also the part that quietly sets the technical bar your platform will be measured against once data spaces start to matter commercially.

The Data Act — Regulation (EU) 2023/2854 — entered into force on 11 January 2024 and became applicable on 12 September 2025. Most of the coverage has been about the loud provisions: connected-product data access, business-to-business sharing, the right to switch cloud provider. The interoperability chapter, Chapter VIII, reads like housekeeping by comparison. It is not. It is where the Act stops describing rights and starts describing the shape of the systems that have to honour them. If you build or run a platform that will expose datasets or services inside a common European data space, this is the chapter that decides whether you can participate on equal terms or whether you show up already behind.

What Article 33 actually requires

Article 33 sets essential requirements for participants in a data space that offer data or services to others. Strip the legal phrasing away and it asks for four concrete things:

• Describe the dataset. Content, use restrictions, licences, how the data was collected, and its quality and uncertainty — sufficiently, and where applicable in a machine-readable format. Not a PDF data dictionary a human reads once.
• Publish the structure. Data structures, formats, vocabularies, classification schemes, taxonomies and code lists must be publicly available and consistently documented. The semantics of your data can no longer live only in the heads of the team that built the pipeline.
• Expose the access. The technical means of access — typically APIs — along with their terms of use and quality of service, must be described well enough to enable automatic access and transmission of data. A machine on the other side has to be able to find, understand and call you without a human integration project each time.
• Support automated agreements. Where relevant, provide the means for interoperability of tools that automate the execution of data-sharing agreements, such as smart contracts.

Read that as an engineer, not a lawyer. It is a specification for a well-behaved data product: documented schema, published semantics, a discoverable and versioned API, machine-readable metadata about licence and quality. Firms that have taken a data-product or data-mesh approach already do most of this. Firms whose datasets are exposed through bespoke integrations, undocumented internal formats and a support ticket to the platform team have real work to do, and the work is not cosmetic.

Where the standards are, and where they are not

Here is the honest position: the essential requirements are in force, but the harmonised standards that turn them into a checklist are not finished. That gap is the whole game.

The Act uses the familiar new-legislative-framework pattern. Meet a harmonised standard published in the Official Journal and you get a presumption of conformity with the essential requirements it covers. Where standards are not delivered in time, or prove inadequate, the Commission may adopt common specifications through implementing acts as a fallback. In July 2025 CEN and CENELEC accepted a Commission standardisation request covering the trusted-data-sharing framework, and the joint technical committee working on data spaces — CEN/CLC/JTC 25 — is developing a set of deliverables in support of Article 33. Some are intended for citation in the Official Journal so they can carry that presumption of conformity; others are technical specifications. Treat the specific committee references and deliverable list as live and verify them against the current work programme before you cite them internally.

The practical consequence is that you are building against a moving target, and the target is moving towards you. The choices you make now — formats, vocabularies, API conventions, metadata models — either sit close to where the standards are converging or they diverge from it. Divergence is not illegal today. It is expensive later, because every degree of drift becomes a retrofit once the standards land and counterparties start asking for conformance.

The switching cousin: Article 35

Article 33 governs interoperability inside data spaces. Article 35 governs interoperability between data processing services — the cloud and edge providers — and it sits directly behind the switching rights that got the headlines. It reaches into transport, syntactic, semantic, behavioural and policy interoperability, and points providers towards open interoperability specifications and standards. If your architecture depends on a single provider’s proprietary interfaces, the same standards pressure that makes switching feasible for your customers makes lock-in a liability for you. We have written separately about the switching rights the Data Act gave you; the interoperability requirements are the machinery that makes those rights real rather than aspirational.

What to do before the specs harden

The instinct to wait for the final standard before doing anything is understandable and wrong. You do not need the published standard to reduce your exposure; you need to stop making choices that the standard will punish.

Prefer open, widely adopted formats over proprietary ones wherever a dataset might leave your walls. The table-format consolidation we covered in the piece on Apache Iceberg is the same logic playing out one layer down: interoperability accrues to whoever stops betting on formats that only one engine reads. Treat metadata as a first-class deliverable, not a documentation afterthought — licence, provenance, quality and use restrictions expressed in a machine-readable model, because that is precisely what Article 33 asks you to expose. Version your APIs and publish their terms and quality of service, so an automated counterparty can rely on them. And keep the semantics of your data separable from any one platform, which is the discipline behind being platform-agnostic and data-first in the first place.

None of this is a compliance project you can hand to the legal team. It is an architecture decision about how your data products describe themselves to machines you do not control. The firms that will move cleanly into data spaces are the ones treating interoperability as a design property they own now, not a certificate they will buy later. The rest will discover that a retrofit at standards-conformance scale is the most expensive way to learn what Chapter VIII was asking for all along.