The EU Data Act becomes effective in September 2025, and by September 2026, connected products must be designed for "access by design." This timeline is tight for a regulation that fundamentally changes how manufacturers, service providers, and cloud vendors handle machine-generated data.
Most teams know they need to comply, but they often stumble in their approach. The mistakes aren't about ignorance of the law. They're about misreading the scope, misaligning internal stakeholders, or treating this as a privacy-only initiative when it's actually a cross-functional redesign challenge.
Why These Mistakes Keep Happening
The Data Act sits at the intersection of intellectual property, privacy, competition law, and product design. It's not a GDPR extension, though it references GDPR for personal data. It's not just a cloud portability rule, though it includes switching provisions. It's a horizontal regulation that touches every team involved in connected products: legal, engineering, product management, privacy, security, and commercial.
This breadth is exactly why teams make predictable errors. They assign the work to one department, assume existing frameworks will stretch to fit, or underestimate the technical lift required to make data "directly, securely and easily available" in structured, machine-readable formats.
Mistake 1: Treating This as a Privacy Initiative
Why it happens: The Data Act covers both personal and non-personal data. Teams see the word "data" and route the project to the privacy team, assuming GDPR compliance will carry them most of the way.
The consequence: Privacy teams can handle personal data obligations, but the Data Act's core challenge is non-personal machine-generated data: sensor outputs, telemetry, metadata, operational logs. These datasets raise intellectual property questions, not just privacy ones. If your privacy lead is managing this alone, you're missing the proprietary data protections, trade secret implications, and competitive dynamics that define the regulation.
The fix: Establish cross-functional governance from the start. Your core team should include privacy, legal (especially IP counsel), product engineering, and commercial leads. Each discipline owns a piece: privacy ensures GDPR compliance for personal data; IP counsel manages the "trade secrets handbrake" mechanism; engineering implements access-by-design architecture; commercial teams update user agreements and B2B contracts to reflect data access rights and third-party sharing processes.
Mistake 2: Assuming "Access" Means "Portal Login"
Why it happens: Teams interpret "user access" as a dashboard or API they'll build later. They think compliance means making data theoretically available, not structurally accessible.
The consequence: The act requires data to be "directly, securely and easily available" in structured, machine-readable formats. A PDF report or a manual export process won't meet the standard. If direct access isn't technically feasible, you must provide "readily available data" upon request without delay and at no cost. That's a higher bar than most legacy systems can clear without architectural changes.
The fix: Map every connected product's data flows now. Identify what data is generated, where it's stored, in what format, and how a user would access it today. Then design for automated, structured access. If your product generates vehicle telemetry, industrial sensor readings, or smart appliance usage logs, users must be able to retrieve that data in a format another service provider can ingest. That's not a feature request. It's a compliance deadline: September 2026 for new products.
Mistake 3: Overusing the Trade Secrets Handbrake
Why it happens: Manufacturers worry that sharing operational data will expose production methods, algorithmic performance, or diagnostic logic. The act includes a mechanism to withhold trade secret-protected information, and teams latch onto it as a way to minimize disclosure.
The consequence: The trade secrets handbrake is not a loophole. It's a structured balancing tool. You can identify information you consider a trade secret, require confidentiality safeguards, and in narrow cases refuse disclosure if no adequate protections exist. But you cannot designate all data as proprietary. Users can challenge excessively broad assertions, and regulators will scrutinize blanket refusals. If you treat the handbrake as a default position rather than a last resort, you risk enforcement action and reputational damage.
The fix: Map your telemetry and operational data to identify what genuinely constitutes a trade secret. Document why specific datasets reveal commercially sensitive methods or insights. For data that doesn't meet that threshold, build disclosure workflows with proportionate confidentiality measures: non-disclosure agreements, technical access controls, usage restrictions. Train your team to apply the handbrake selectively, not reflexively.
Mistake 4: Ignoring Downstream Use Restrictions
Why it happens: Teams focus on their obligations as data holders but overlook the restrictions placed on third parties who receive shared data. They assume once data leaves their systems, it's no longer their concern.
The consequence: The act imposes strict obligations on third parties who receive user-designated data. They cannot use shared data to create competing products. They must limit use to the specific purpose agreed with the user. They must handle personal data under GDPR and respect trade secret protections. If a third party violates these terms, the user may face consequences, but so will you if your contracts and technical safeguards failed to enforce the restrictions.
The fix: Update your data-sharing agreements to specify permissible uses, confidentiality requirements, and misuse consequences. Build technical controls that limit what third parties can access and log how they use it. If you're enabling interoperability or multi-vendor maintenance, document the purpose and ensure the third party acknowledges their obligations in writing. This isn't just risk mitigation. It's a requirement.
Mistake 5: Treating B2B Contracts as Exempt
Why it happens: Some teams assume the Data Act primarily affects consumer products. They deprioritize industrial machinery, enterprise software, or B2B cloud services, believing business users have less regulatory protection.
The consequence: The act applies to business users, not just consumers. If your industrial equipment, fleet management system, or enterprise SaaS platform generates usage data, your business customers have the same access rights as individual consumers. They can instruct you to share data with third-party service providers. They can request data in machine-readable formats. The only distinction is that B2B contracts may negotiate certain terms, but you cannot contractually override the user's statutory rights.
The fix: Review every B2B agreement involving connected products or related services. Identify clauses that restrict data access, limit portability, or assign data ownership exclusively to you. Update those terms to reflect user access rights and third-party sharing obligations. If your contract includes service-level commitments, clarify how data access requests will be handled within those timelines.
Mistake 6: Waiting for Enforcement Guidance
Why it happens: Teams know the effective date but hope for clarifying guidance, enforcement precedents, or industry practices before committing resources. They treat September 2025 as the starting gun rather than the finish line.
The consequence: The act is effective now. The September 2026 deadline for access-by-design applies to new products placed on the EU market. If you're waiting for the first enforcement action to understand expectations, you're already behind. Redesigning data architectures, updating contracts, training teams, and implementing technical controls takes months, not weeks.
The fix: Start with a compliance gap assessment. Identify which products fall under the regulation, what data they generate, and whether your current systems support structured access. Prioritize products launching before September 2026. Build a roadmap that includes technical implementation, contract updates, and cross-functional training. If you're uncertain about specific provisions, engage with trade associations or legal counsel now, not after the deadline passes.
Prevention Checklist
- Establish cross-functional governance with privacy, IP, engineering, and commercial leads
- Map data flows for all connected products: what's generated, where it's stored, in what format
- Design automated, structured access mechanisms for user data requests
- Identify trade secret-protected data and document proportionate safeguards
- Update user agreements and B2B contracts to reflect access rights and sharing processes
- Specify downstream use restrictions and confidentiality measures for third parties
- Review B2B contracts to ensure they don't override statutory user rights
- Build logging and audit trails for data access and third-party sharing
- Train product, legal, and support teams on user request workflows
- Prioritize products launching before September 2026 for access-by-design compliance
- Document your trade secrets handbrake process and train teams to apply it selectively
- Test data portability workflows with real user scenarios before the deadline
