Search every question across sub-FAQs

Use Data Act examples that separate the product, the user, the data holder, and the data. A company operating a connected bulldozer may be the user, while the bulldozer manufacturer is typically the data holder. A connected fridge with an app can involve two data holders: the entity placing the fridge on the market and the provider of the related app.

Vehicle and infrastructure examples are useful because they show the boundary. If a vehicle receives data from roadside sensors or records road conditions and the vehicle data holder has access to that data, the vehicle user may request the vehicle data. But driving on a road does not make the driver a Data Act user of the road infrastructure sensors.

A useful Data Act scope file should be narrow: product identifier, EU market-placement basis, manufacturer or designer, related-service provider if any, user categories, data holder, generated data categories, readiness of access, exclusions applied, and source citation. It should be written so product, legal, engineering, support, and sales teams can apply the same classification.

For each product family, keep the architecture facts that support the decision: sensor list, data fields, metadata, communication routes, storage location, retention period, whether direct access is technically feasible, and where customer disclosures describe access and third-party sharing. If the answer relies on Article 7 SME status, keep the linked-enterprise, subcontracting, and timing evidence.

Keep the Data Act legal basis and the practical facts together. For each scope decision, store the cited clause or recital, the Commission guidance relied on, the product family or service, the data categories involved, the trigger for the review, and the person who approved the classification.

A concise evidence file should also preserve the source URL, the date of the decision, any unresolved assumptions, and the implementation artifact that reflects the conclusion. That makes the classification auditable when the product design, data flow, or contract changes.

Assign one accountable owner who can change the affected process under the Data Act, then record the supporting teams separately. Legal, product, procurement, cloud, support, and security may all be involved, but the scope file should name a single owner for follow-up.

The owner should be the person who can update the product record when architecture, contractual terms, or data flows change and who can trigger a new review when the scope facts move.

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. Article 33 says participants must comply with the essential requirements only for elements under their control, so the evidence should show which metadata, interface, usage-term, or automation component each participant can actually change.

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, QoS 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, QoS 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.

Under the Data Act, keep a short decision record that shows the article or clause relied on, the data-space participant role, the dataset or service in scope, and the person who approved the interpretation. The record should also note the source URL, date, reviewer, and any unresolved assumptions that still need follow-up.

That record should sit next to the implementation evidence, such as the catalogue entry, data model, API description, or smart-contract rule. If a later reviewer opens the file, they should be able to see both why the flow was treated as in scope and what the team changed to satisfy it.

Under the Data Act, assign one accountable owner who can change the affected process, plus the technical and legal contacts who will help maintain the Article 33 profile. That owner should be named in the record, along with the workflow they control, such as catalogue publishing, API maintenance, data-model governance, procurement, or participant onboarding.

Ownership should also include a review trigger. Article 33 profiles become stale when the data space adds a new participant rule, changes a dataset format, updates the API, or adopts a harmonised standard or common specification. The owner should be the person who gets notified when any of those changes happen.

Under the Data Act, the useful evidence is the kind that lets a later reviewer reconstruct the decision without guesswork. That usually includes the relevant clause, the participant's role, the dataset or service, the contract or request trigger, and the external source URL. If the team relied on a standards or governance assumption, that assumption should be written down too.

The same file should also point to the concrete implementation artifact. A reviewer should not have to search separately for the catalogue entry, metadata schema, API note, or smart-contract setting that operationalised the decision.

Under the Data Act, review the decision whenever the participant role, dataset, service, contract wording, or governance rule changes. A new API version, a new data structure, or a new sector rulebook can all change what Article 33 requires in practice.

It is also worth reviewing the decision when new harmonised standards, common specifications, or Commission guidance are published. If the profile already relies on a standards assumption, the review should confirm whether that assumption is still valid or whether the implementation should be updated.

Do not treat the Data Act Article 33 answer as a generic privacy, cloud, or procurement checklist. The right answer depends on the participant role, the data-space governance context, and the exact dataset or service being shared.

Also avoid over-claiming that a technology is mandatory when the source only supports a description, a presumption of conformity, or a standards route. The safer approach is to keep the source note, the implementation profile, and the review trigger aligned.