Start by mapping where AI is embedded in connected products and related services, then trace what data is collected, generated, stored, shared, and exposed to third parties. Align product design, access controls, disclosure notices, and data-sharing processes so users can obtain data easily, securely, and in machine-readable form. Treat GDPR overlap and unauthorized-access controls as separate but coordinated obligations.
Preparing connected products and services for EU Data Act data sharing
The practical challenge is not just legal compliance, it is deciding where the product generates data, who can reach it, and how reliably it can be delivered to the user or a third party without weakening security. For AI-enabled connected products, the preparation work sits at the intersection of product architecture, data governance, and access control, especially where operational telemetry, usage history, or service data can be reused outside the original system.
Start with a data map that covers the product, any companion app, cloud backend, APIs, and downstream service providers. Classify which datasets are in scope for user access or sharing, which are personal data, and which require separate controls because they can expose operational detail, configuration, or sensitive system behaviour. A useful control lens is EU Cyber Resilience Act readiness: if the product is already being designed to limit unnecessary exposure and support secure lifecycle handling, it is easier to meet Data Act sharing obligations without creating new attack paths.
Design the delivery path so data can be exported in a usable format, but do not let “easy access” become “open access.” The user-facing flow should distinguish authenticated retrieval, consent or contractual sharing, and third-party onward transfer. That is especially important where the product ecosystem includes tokenised integrations, cloud APIs, or vendor-managed service layers, because the access route may be more exposed than the underlying device data itself. The same discipline applies whether the data is pulled from a device, a digital service, or a connected platform intermediary.
Where the security and compliance boundaries need to line up
The Data Act does not replace privacy law, and it does not replace product-security controls. Organisations need to treat GDPR questions, such as lawful basis, transparency, minimisation, and data subject rights, as separate from the secure-availability question of whether data can be delivered safely and accurately to the user or recipient. The operational mistake is to merge those workflows and assume one approval path covers everything. It usually does not, because sharing, retention, and access restrictions often differ by data type and by recipient.
Controls should therefore be aligned around the actual sharing path. Notice language, identity checks, API authorisation, rate limits, logging, and revocation procedures should be designed together so the organisation can prove who requested the data, what was provided, and under which conditions. Where a connected product relies on integration credentials or service-to-service access, the risk is similar to a broader access-governance problem: if the system cannot distinguish the user’s entitlement from a third party’s operational access, it becomes difficult to share data safely without oversharing.
This is also the point where organisations should decide how much of the sharing function is automated. Machine-readable delivery is useful, but automated export, forwarding, or connector-based sharing should still be bounded by policy, approval logic, and tamper-evident logging. If a data export can trigger across multiple services, the implementation needs explicit controls for scope, purpose, and recipient rather than relying on the assumption that the downstream consumer will behave correctly.
Building the operating model so sharing stays accurate over time
Preparation is not a one-time design exercise. Product teams, legal, privacy, security, and service operations need a shared operating model for change management, because any new AI feature, telemetry source, supplier integration, or cloud service can alter what data is collected and what must be disclosed or shared. That is where many programmes drift: the published notice is updated late, the API contract changes first, and the operational process follows only after a complaint or audit.
For that reason, organisations should test the end-to-end workflow before launch and after material changes. Verify that the requested dataset is complete, that sensitive fields are excluded or masked where required, that the recipient receives the data in the promised format, and that access logs are sufficient to investigate disputes. For a connected-product estate, a disciplined lifecycle approach matters because the sharing obligation can outlive the original device purchase or service contract, and the product may still generate data long after the first release.
Where AI is involved, keep the model and the data path separate in the architecture review. The presence of AI does not change the legal obligation by itself, but it often changes the data volume, the provenance of outputs, and the number of services that can observe or transform the underlying records. That means product owners should review not only what the AI does, but also which components can retrieve, enrich, retain, or disclose the data that the AI system depends on.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8, NIST AI RMF and NIST SP 800-63 set the technical controls, while EU Cyber Resilience Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| EU Cyber Resilience Act | Secure by design and lifecycle security | Connected products need secure sharing paths and lifecycle controls that complement Data Act preparation. |
| Recommendation — Design export and sharing paths with secure-by-design controls and lifecycle protections. | ||
| NIST CSF 2.0 | PR.AC — Access Control | The answer depends on authenticating users and restricting who can retrieve or share product data. |
| GV.RM — Risk Management Strategy | Preparing for Data Act obligations requires coordinated governance across privacy, security, and product teams. | |
| Recommendation — Enforce access checks for data retrieval, export, and third-party sharing. Set a governance process that keeps data-sharing, privacy, and security decisions aligned. | ||
| CIS Controls v8 | 6 — Access Control Management | Connected-product sharing needs controlled authorization, revocation, and auditability for access paths. |
| 3 — Data Protection | The answer requires knowing what data is collected, exposed, and delivered in machine-readable form. | |
| Recommendation — Review and revoke access paths used for product-data export and sharing. Classify and protect product data before enabling export or onward sharing. | ||
| NIST AI RMF | GOV — Govern | AI-enabled products need governance over data use, disclosure, and accountability for sharing decisions. |
| MAP — Map | Mapping where AI is embedded and what data flows through it is central to this preparation. | |
| MEASURE — Measure | The answer calls for validating that exports are complete, secure, and logged before trust is placed in them. | |
| Recommendation — Establish governance for AI data flows, disclosure rules, and accountability. Map AI components, data sources, and downstream sharing dependencies. Measure export completeness, access logging, and delivery integrity. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Secure retrieval and third-party delivery depend on verifying the requester before data is disclosed. |
| FAL — Federation Assurance Level | Third-party sharing and machine-readable delivery often rely on federated or delegated access flows. | |
| Recommendation — Verify requester identity before releasing connected-product data. Use assured federation when data is shared through external service paths. | ||
Practitioner Guidance
What to prioritise: build one authoritative inventory of data flows across device, app, cloud, and supplier interfaces before writing new notices or export procedures. If the inventory is incomplete, the organisation will almost always under-share some data and overexpose other data.
What to verify: test the actual export path, not just the policy. Confirm that access checks, format conversion, recipient validation, logging, and revocation all work together for the most sensitive data set the product can emit.
Common mistake: treating user access, third-party sharing, and GDPR handling as one combined workflow. They should be coordinated, but each needs its own decision point and evidence trail.
Practitioner takeaway: the safest way to meet Data Act sharing expectations is to engineer controlled data portability into the product from the start, so the organisation can satisfy access obligations without creating a broader disclosure or privilege problem.
Related resources from NHI Mgmt Group
- How should organisations prepare GPAI systems for the EU AI Act before August 2, 2025?
- How do organisations prepare for the EU AI Act without slowing AI adoption?
- How should organisations classify AI systems for EU AI Act compliance?
- How should organisations map AI systems to EU AI Act disclosure duties?
