What is the difference between the EU Data Act and the EU AI Act for AI systems in connected products?

The EU Data Act governs how data from connected products and related services is accessed, shared, and protected, while the EU AI Act focuses on risk management, robustness, and safety of AI systems. For teams, the distinction matters because a compliant model can still fail data-access or disclosure duties, and a compliant data process can still leave AI-specific risks unresolved.

How the two laws split the problem in connected products

The cleanest way to separate the eu data act from the eu ai act is to ask whether you are dealing with data rights in a connected product ecosystem, or with the behaviour and safety properties of an AI system. The Data Act is about who can access product and service data, on what terms, and with what protections. The AI Act is about whether the AI system itself is acceptable, well governed, and appropriately controlled for its risk level.

That split matters in connected products because the same product can sit under both regimes at once. A device may need to expose operational data to a user or a third party under the Data Act, while the embedded model or AI feature still has to meet the EU AI Act’s requirements for risk management, robustness, transparency, and oversight. One law governs the data pathway, the other governs the AI behaviour.

The practical consequence is that compliance work should not be collapsed into a single checklist. If teams treat the issue as “AI compliance only”, they can miss data-access and sharing duties. If they treat it as “data access only”, they can miss model governance, logging, human oversight, or high-risk obligations that arise from the AI feature itself. For connected products, those are parallel questions, not substitutes.

What the EU Data Act changes for AI-enabled connected products

The EU Data Act is the more operationally specific rule when the question is access to data generated by connected products and related services. In practice, that means telemetry, usage data, device-generated data, and other product or service outputs may need to be made available to the user or shared with a third party under defined conditions. The law is aimed at reducing lock-in and improving portability, access, and switching.

For AI systems in connected products, the important point is that the Data Act can apply even when the AI layer is functioning normally. If the product produces data that another party is entitled to receive, the organisation must handle access, disclosure, format, and protection correctly. A model may be secure, but the surrounding data pipeline can still fail the legal test if access rights, sharing terms, or commercial restrictions are mishandled.

Teams should also remember that “data from the product” is not the same thing as “training data for the model.” The Data Act is concerned with access to data generated in the product ecosystem, while AI governance concerns may focus on how data is used, retained, and validated inside the AI system. Those boundaries often overlap in engineering, but they are not legally identical.

This is where product design discipline matters. Access controls, export functions, retention rules, API exposure, and contractual flows all become part of the Data Act conversation. For a useful overview of non-human identity governance around secrets, service accounts, and access paths that often sit behind these product pipelines, NHIMG’s Ultimate Guide to NHIs, Regulatory and Audit Perspectives is a relevant companion reference.

Where the EU AI Act starts and the Data Act stops

The EU AI Act does not govern connected-product data sharing in the way the Data Act does. Instead, it governs the AI system as a regulated technology and looks at the risks created by its design, purpose, and deployment context. That includes whether the system is prohibited, limited, or high-risk, and whether the provider or deployer has implemented appropriate safeguards.

For connected products, that means the AI Act becomes central when the embedded AI feature influences decisions, behaviour, safety, or user impact. The relevant questions are whether the system has an acceptable risk posture, whether outputs are reliable enough for the intended use, and whether documentation, oversight, robustness, and transparency are in place. A product can satisfy data-access duties and still have an unsafe or non-compliant AI feature.

The reverse is also true. A well-governed AI model does not automatically satisfy the Data Act. If the connected product’s data-sharing obligations are ignored, the organisation can still fall short even if the model itself is robust, tested, and documented. The legal logic is parallel: one regime protects access to data, the other regulates AI risk.

For teams building AI-enabled devices, the safest mental model is to map each requirement to the layer it governs. Data collection, retrieval, export, and sharing belong in the Data Act workstream. Model controls, human oversight, technical robustness, and conformity assessment belong in the AI Act workstream. Where the same engineering control serves both, it should still be tested against both legal obligations separately. For the AI side of that split, the European Commission’s EU AI Act regulatory framework is the most direct reference point.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST AI RMF, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while EU AI Act define the regulatory obligations.

Framework	Control / Reference	Relevance
EU AI Act	GPAI / High-Risk AI Requirements — Risk Management, Robustness, and Oversight	Directly governs AI system risk, robustness, and safety in connected products.
Recommendation — Classify the AI feature, then apply the appropriate AI Act obligations for risk, oversight, and conformity.
NIST AI RMF	GOVERN — AI Governance	Useful for structuring AI risk ownership and accountability around embedded AI features.
Recommendation — Assign clear AI governance ownership and document accountability for system risk decisions.
NIST CSF 2.0	GV — Governance	Supports separate governance for data-access duties and AI-risk controls across the product lifecycle.
	PR.AC — Access Control Management	Relevant to controlling who can access and share connected-product data under the Data Act.
Recommendation — Establish governance that maps legal duties to the right owners and control evidence. Enforce access control for product data interfaces and sharing paths.
CIS Controls v8	6 — Access Control Management	Applies to restricting and reviewing access to product data, exports, and service interfaces.
Recommendation — Review and limit access paths that expose connected-product data.

Practitioner Guidance

What to verify: Confirm whether the AI feature is only an internal optimisation, or whether it materially affects users, safety, or product behaviour. Then separately inventory what product and service data is generated, who is entitled to access it, and which interfaces actually deliver it.

Decision rule: If the issue is data availability, portability, sharing, or disclosure, treat it as a Data Act problem first. If the issue is model behaviour, safety, robustness, oversight, or AI lifecycle control, treat it as an AI Act problem first. Many connected-product programs need both tracks running in parallel.

Common mistake: Teams often assume that one compliance review covers the whole stack. In connected products, that assumption is fragile because the AI layer and the data-access layer fail in different ways, and each can create independent legal exposure.

Practitioner takeaway: Build the compliance map by layer, not by product branding, because the same connected product can be lawful on AI controls and still fail on data-access duties, or vice versa.