Search every question across sub-FAQs

No. The Commission FAQ states that Article 36 does not affect national contract law and that the Data Act regulates the computer programs used to execute agreements, not the agreements as such.

Teams should therefore maintain two linked records: the data sharing agreement that sets the parties' rights and obligations, and the smart-contract evidence showing that the automated execution is robust, controllable, auditable, and consistent with those terms. Do not claim that compliant code alone creates, replaces, validates, or overrides the contract.

The Data Act context is the starting point for this answer. Robustness should be treated as both reliability and abuse-resistance. Before deployment, the team should test error handling, boundary conditions, manipulation attempts, dependency failures, and upgrade or migration paths that could change execution outcomes.

Access control needs coverage at two levels. Governance-layer controls should restrict who can deploy, pause, upgrade, terminate, or change parameters. Smart-contract-layer controls should restrict who can trigger functions, submit data, approve transactions, retrieve records, or operate privileged methods.

The Data Act context is the starting point for this answer. The smart contract should include internal functions that can reset, stop, or interrupt operation, especially to avoid accidental future executions. The stop mechanism should be tested before production use and documented so authorized personnel know when and how it can be used.

Recital 104 also says the requirement to interrupt and terminate smart contracts implies mutual consent by the parties to the data sharing agreement. Do not design a one-sided kill switch that conflicts with the agreement terms or later claim that a stop function changes the contract by itself.

If the smart contract is terminated or deactivated, Article 36 expects a possibility to archive the transactional data, smart-contract logic, and code so past operations on data remain auditable. The archive should preserve the relevant version, execution history, stop event, consent record, and agreement link.

The Data Act context is the starting point for this answer. A smart contract can automate execution of a data sharing agreement, but it should not be treated as a substitute for the agreement. The agreement should still state the parties, data, use conditions, access limits, compensation if relevant, trade-secret measures, remedies, and termination terms.

The Commission has published non-binding model contractual terms for Data Act data access and use. Those terms are voluntary implementation tools; they can help structure the agreement that the smart contract executes, but using them does not by itself prove Article 36 conformity.

The Data Act context is the starting point for this answer. Article 36 creates two conformity routes that may matter over time. A smart contract that meets harmonised standards cited in the Official Journal is presumed to conform to the covered Article 36 requirements. If the standards route is unavailable under Article 36 conditions, the Commission may adopt common specifications by implementing act, and meeting those specifications can also create a presumption of conformity for the covered requirements.

The grounding materials show active Data Act standardisation work around a European Trusted Data Framework, trusted data transactions, and Article 33 interoperability deliverables. They do not support telling readers that a specific Article 36 harmonised standard is already cited in the Official Journal for smart contracts. Treat standards status as a live dependency and cite the binding Article 36 text before making conformity claims.

The Data Act context is the starting point for this answer. Keep a small but complete Article 36 evidence pack for each smart-contract deployment used to execute a data sharing agreement. The pack should let a reviewer connect the legal agreement, deployed code, controls, tests, conformity assessment, declaration, and later termination or archiving event without reconstructing the story from tickets.

At minimum, the pack should include the agreement terms being executed, the responsible vendor or professional deployer, code and logic version, deployment address or environment, access-control design, robustness tests, stop and reset tests, archive procedure, conformity assessment, EU declaration of conformity, and review notes for any standard or common-specification updates.

The Data Act context is the starting point for this answer. Avoid saying that Article 36 validates the legal agreement, replaces national contract law, certifies a blockchain protocol, requires a particular ledger technology, or makes all automated data-sharing controls smart contracts. The grounded rule is more specific: it applies essential requirements to smart contracts used by the relevant vendor or professional deployer to execute a data sharing agreement or part of one.

Also avoid using Article 36 to bypass the Data Act rules on data access, trade secrets, unfair contract terms, or technical protection measures. A smart contract can help enforce agreed terms or prevent unauthorized access, but Data Act technical measures must not be used to discriminate between recipients or hinder user and third-party rights.

For smart contracts for data sharing, the Data Act record should identify the source clause, Commission guidance, actor role, dataset, request or contract trigger, and the owner who approved the interpretation.

For smart contracts for data sharing, keep the cited external URL, decision date, reviewer, unresolved assumptions, and implementation artifact together so the answer remains auditable.

If Article 36 controls are reused across teams, note which contract version, deployment environment, and standardization reference the team relied on so later reviews can see why the decision was made.

For smart contracts for data sharing, the Data Act workflow should name the legal, product, procurement, cloud, support, or security owner who can change the affected process.

For smart contracts for data sharing, use one accountable owner per action, then record consulted teams and evidence dependencies separately.

Ownership should also cover follow-up work: keeping the Article 36 evidence pack current, updating the agreement when the deployed logic changes, and checking whether new harmonised standards or common specifications affect the deployment.

The Data Act context is the starting point for this answer. User-directed sharing is the Article 5 route where the user, or someone acting on the user's behalf, asks the data holder to make readily available data and the metadata needed to interpret and use it available to a third party. The data holder must make the data available without undue delay, with the same quality as is available to the data holder, easily, securely, in a comprehensive, structured, commonly used and machine-readable format, and where relevant and technically feasible continuously and in real time.

This is not an open data-publication duty. It depends on a user request, a qualifying user, a qualifying third party, and data generated by the connected product or related service that is readily available to the data holder.

The Data Act context is the starting point for this answer. For Chapter II sharing, the practical scope is raw and pre-processed data generated from the use of a connected product or related service that is readily available to the data holder, plus relevant metadata. Commission guidance gives examples such as sensor data on temperature, pressure, flow rate, audio, pH value, liquid level, position, acceleration, or speed.

Do not include inferred or derived information merely because it came from the same product ecosystem. The Commission explains that inferred or derived data, highly enriched data, and content such as audiovisual material are outside the Chapter II scope.

Before users need to exercise the right, Data Act transparency rules require information on how the user can request that data be shared with a third party and, where applicable, end that sharing. During the request, the data holder may verify user or third-party status, but it must not require more information than necessary and must not keep third-party access information beyond what is needed for execution, security, and infrastructure maintenance.

Where the data holder is obliged to make data available to a data recipient, Article 8 requires fair, reasonable, non-discriminatory, and transparent terms. The data holder cannot make data available to a data recipient on an exclusive basis unless the user requested it under Chapter II.

The Data Act context is the starting point for this answer. The third party may process the data only for the purposes and under the conditions agreed with the user, and must erase the data once it is no longer necessary for the agreed purpose unless the user agreed otherwise for non-personal data. If personal data is involved, Union and national data-protection law and data-subject rights still apply.

Article 6 also blocks several recipient behaviours: manipulating the user interface or user choices, profiling unless necessary to provide the service requested by the user, onward sharing without a user contract and trade-secret measures, sharing with a designated gatekeeper, using the data to develop a competing connected product, harming security, undermining trade-secret safeguards, or preventing a consumer user from sharing the data with others.

The Data Act context is the starting point for this answer. No, not through Article 5 user-directed sharing. An undertaking designated as a gatekeeper under the Digital Markets Act is not an eligible third party for Article 5. The gatekeeper also must not solicit or commercially incentivise a user to make data available to one of its services or ask the data holder to do so.

Article 6 adds a downstream control: a third party that received the data must not make the data available to a designated gatekeeper.

The Data Act context is the starting point for this answer. Trade secrets are not a blanket reason to ignore Article 5. They must be preserved and may be disclosed to third parties only to the extent strictly necessary for the purpose agreed between the user and the third party. The data holder or trade secret holder must identify protected data, including relevant metadata, and agree proportionate technical and organisational confidentiality measures with the third party.

If measures are not agreed, the third party fails to implement them, or confidentiality is undermined, the data holder may withhold or suspend sharing of the identified trade-secret data, give a duly substantiated written decision to the third party without undue delay, and notify the competent authority. Refusal is reserved for exceptional case-by-case circumstances where the trade secret holder can demonstrate a high likelihood of serious economic damage despite the measures.

Security is relevant, but the Data Act frames it narrowly. Users and data holders may contractually restrict or prohibit access, use, or further sharing where the processing could undermine security requirements of the connected product laid down by Union or national law and result in serious adverse effects on the health, safety, or security of natural persons.

A recipient also must not use the data in a way that adversely affects the security of the connected product or related service. Security controls should therefore be tied to legal security requirements and the specific risk, not used as a generic objection to third-party access.

The Data Act does not supersede GDPR. It complements Union data-protection and privacy law and does not create a new legal basis for providing access to personal data where the user is not the data subject. If personal data generated by a connected product or related service is to be made available to a third party and the user is not the data subject, the data holder needs a valid Article 6 GDPR legal basis and, where relevant, conditions for special-category data and ePrivacy terminal-equipment rules.

Where data contains several people's personal data, teams should separate, anonymise, pseudonymise, or otherwise control delivery as needed. The Commission FAQ also warns that privacy-enhancing technologies should not be used simply to circumvent Data Act sharing obligations where data remains readily available.

The Data Act context is the starting point for this answer. Article 5 says the data must be made available to the third party free of charge to the user. Separately, Article 9 allows reasonable and non-discriminatory compensation agreed between a data holder and a data recipient in business-to-business relations, and says compensation may include a margin.

There is a special cap for SME data recipients and not-for-profit research organisations that do not have linked or partner enterprises outside the SME category: compensation must not exceed the costs incurred for making the data available. The data holder must provide enough detail on the calculation basis for the data recipient to assess whether Article 9 requirements are met.

Use a simple sequence: first confirm the request comes from the user or someone acting on the user's behalf, then confirm the recipient is eligible, then check the data scope and any GDPR issues. If the request is valid, make the data available without undue delay and in the required format. If trade secrets or security concerns apply, use the Article 5 or Article 4 safeguards, and if the issue cannot be resolved, withhold, suspend, or refuse only within the conditions in the Data Act.

A good internal workflow also records the request, the data categories shared, the legal checks performed, the confidentiality measures agreed, the delivery date, and any authority notification or dispute route used.

The Data Act context is the starting point for this answer. Keep a request record that shows the user authority, recipient identity and eligibility, requested data categories, personal-data assessment, trade-secret and security assessment, recipient purpose, delivery route, delivery format, compensation position if any, and final outcome. These records should be enough to explain why data was shared, limited, suspended, withheld, or refused.

For recipient misuse, Article 11 supports remedies such as erasure of data and copies, ending production or use of goods or services produced from unlawfully used data where the legal test is met, informing the user of unauthorised use or disclosure, and compensation for misuse or disclosure of unlawfully accessed or used data.