EU Data Act Data Spaces Interoperability FAQ

Article 33 targets participants in data spaces that offer data or data services to other participants. The relevant question is not whether an organisation mentions a data space in marketing copy; it is whether the organisation is offering data, a data-sharing service, or a service used by other participants inside a purpose-specific, sector-specific, or cross-sector data-sharing framework.

For architecture and contract work, identify the participant role for each flow: data provider, data holder, data recipient, catalogue operator, API provider, data intermediation provider, analytics service, or governance body. Recital 103 explains that participants should comply with the essential requirements insofar as elements under their control are concerned, so the evidence should show which metadata, interface, usage-term, or automation component each participant can actually change.

An organisation that only consumes data is not automatically covered. A catalogue or access operator is covered when its own offered service meets the trigger; assess each flow separately.

Article 33 requires descriptions that make data findable, accessible, usable, and technically exchangeable. The required descriptions cover dataset content, use restrictions, licences, collection methodology, data quality and uncertainty; data structures, formats, vocabularies, classification schemes, taxonomies and code lists where available; technical means of access such as APIs, terms of use, and quality of service; and, where applicable, means for interoperable automation of data-sharing agreements such as smart contracts.

The practical output should be a participant-facing interoperability profile, not a generic compliance memo. For each offered dataset or data service, document the catalogue fields, machine-readable metadata, accepted formats, semantic assets, API or bulk download route, quality-of-service terms, access conditions, licence or usage restriction, and any smart-contract or policy-automation mechanism used for the exchange.

Common European data spaces are EU-supported data infrastructures and governance frameworks for trusted data pooling and sharing in strategic sectors and domains of public interest. Commission material describes the original strategic fields as health, agriculture, manufacturing, energy, mobility, financial, public administration, skills, the European Open Science Cloud, and the Green Deal, with further areas such as media and cultural heritage emerging later.

This matters because Article 33 is horizontal, while data-space practice is often sector-specific. A manufacturer, cloud provider, public-sector platform, research infrastructure, or mobility service should therefore separate the horizontal Article 33 requirements from the sector's own governance rulebook, participant agreements, catalogue profile, identity model, and data-quality conventions.

No single named technical standard is mandated by Article 33 itself. The Data Act creates essential requirements and a standards route: the Commission requests European standardisation organisations to draft harmonised standards, participants using harmonised standards cited in the Official Journal can benefit from a presumption of conformity for covered requirements, and common specifications are a fallback when the standardisation route does not deliver as required.

As implementation context, CEN and CENELEC announced that Mandate M/614 on the European Trusted Data Framework was accepted on 7 July 2025, with CEN, CENELEC, and ETSI agreeing to develop standardisation deliverables to support Article 33. Teams should monitor those deliverables and any Official Journal citations, but should avoid writing contracts or product requirements that falsely say Article 33 already requires one specific named technology across all data spaces.

Treat interoperability as a published contract between participants. Architecture work should make the data discoverable, the meanings stable, the access route documented, and the governance constraints enforceable. In practice, that means versioned catalogue metadata, data dictionaries, semantic mappings, API or file-transfer specifications, licence and restriction fields, quality and uncertainty fields, authentication and authorisation rules, audit logs, error handling, and service-level descriptions.

The architecture should also distinguish data-space interoperability from cloud-switching interoperability. Article 33 is about interoperability of data, data-sharing mechanisms and services, and common European data spaces. Separate Article 30 and Article 35 work for data processing services, open interfaces, exportable data, and the central Union standards repository from Article 33 work for data-space participation.

Keep evidence that proves the participant did more than connect systems. A useful file includes the Article 33 scope assessment, participant role map, data-space governance rulebook or participation terms, catalogue extract, metadata schema, data-quality and uncertainty fields, licence and use-restriction fields, API or transfer specification, quality-of-service description, semantic mappings, standards tracker, and test results for automated access or transmission.

Also keep a standards watch record. It should show which harmonised standards, common specifications, sector rulebooks, and data-space technical profiles were checked; whether any Official Journal citation or implementing act is relevant; why any named technology was selected; and which owner must update the profile when the data space, source dataset, access route, or standardisation status changes.