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

How the EU Data Act and EU AI Act split responsibility in connected products

The easiest way to separate them is to ask whether the issue is about the product’s data or the system’s behaviour. The EU Data Act governs access to and sharing of connected-product and related-service data, including how organisations disclose or protect that data. The EU AI Act governs the AI system itself, especially its risk profile, robustness, transparency, and safety obligations.

That distinction matters because the same connected product can trigger both regimes at once. A system can be well-controlled on AI safety and still mishandle data access duties, while a strong data-access process can still leave model risk, documentation, or oversight gaps unaddressed.

For connected products, teams should treat data flows, user access requests, and trade-secret boundaries as a separate compliance workstream from model lifecycle, deployment, and monitoring. The legal question is not whether the system is “generally compliant”, but which obligation is being tested at each point in the product and data flow.

What the Data Act requires versus what the AI Act requires

The EU Data Act is primarily about making connected-product data usable under defined rules. That includes who can access the data, when it must be shared, and what protections apply when disclosure could expose trade secrets or other sensitive information. In practice, it is about control over data generated by the product and the services around it.

The EU AI Act is about the AI system as a regulated technology. Its focus is on whether the system is prohibited, high-risk, or otherwise subject to duties such as risk management, technical documentation, human oversight, logging, accuracy, robustness, and cybersecurity. For connected products, the AI Act cares about the model or decision logic inside the product, not just the data it emits.

That means the two laws can apply to different layers of the same stack. A connected device may need a lawful data-access interface under the Data Act and, at the same time, a documented AI risk-control process under the AI Act. The compliance evidence will therefore look different: one stream is about access, sharing, and data governance, the other is about system assurance and AI controls.

Where teams usually get the boundary wrong

Teams often assume that satisfying one regime covers the other. It does not. A data-sharing workflow can be lawful under the Data Act and still create AI-specific exposure if the connected product uses an AI system that lacks proper robustness, logging, or oversight. Likewise, an AI programme can be well governed and still fail if it does not meet obligations around product-data access, disclosure, or protection of business-sensitive information.

The boundary is also operational, not just legal. Product, privacy, legal, security, and AI governance teams may each own part of the answer, but no single team usually owns the whole compliance picture. That is why many organisations need separate checklists for connected-product data, model governance, and disclosure obligations, rather than one blended “AI compliance” review.

For teams building or buying AI-enabled connected products, the practical test is whether the obligation attaches to data flows, system behaviour, or both. If the issue is access to telemetry, usage data, or service data, start with the Data Act. If the issue is model risk, transparency, logging, or safety, start with the AI Act.

Risk and Threat Considerations

Connected products create overlapping exposure because the data layer and the AI layer fail in different ways. A product can leak or over-disclose data while still appearing technically stable, and an AI system can behave unpredictably even when its data-access process is sound. The risk is compounded when organisations treat regulatory compliance as a single control set instead of two distinct obligation sets.

Failure mechanism: Misclassifying the obligation leads to incomplete controls, for example, handling product data requests without checking AI-specific documentation, or validating AI safety without governing data-access, disclosure, and trade-secret handling.

Impact: The result can be regulatory non-compliance, unnecessary data exposure, broken customer trust, or a control gap that is only discovered after a complaint, audit, or incident.

Practitioner Guidance

What to verify: Map each connected-product use case to the exact obligation trigger before assigning ownership. Check whether the requirement is about data access, product/service data sharing, or AI-system governance, and keep the evidence separate for each.

Decision rule: If the issue concerns data produced by the connected product, treat the Data Act as the primary lens; if it concerns how the AI system behaves, is documented, or is supervised, treat the AI Act as the primary lens. When both apply, do not merge the controls into one approval step.

Practitioner takeaway: The safest operating model is to design connected-product compliance as two parallel tracks, one for lawful data access and one for AI system assurance, because passing one does not imply passing the other.

Related resources from NHI Mgmt Group

• Guide: EU Data Act Guide
• How should organisations prepare AI systems for the EU Data Act when those systems rely on connected products or related services?
• Why does the EU Data Act create extra compliance risk for AI deployments in connected products?
• How should security teams structure EU AI Act compliance for AI systems?
• How should organisations classify AI systems for EU AI Act compliance?