- Product and related-service data described in a catalogue users can understand
- A self-service API and download for users to access their own product data
- Sharing with third parties the user chooses, with consent and revocation
- Trade secrets identified and protected through agreed measures, not blanket refusal
- A platform built to switch cloud providers without lock-in
Anonymised composite. Client names, identifying details and confidential figures are withheld; public facts are cited in the references.
The situation
A manufacturer of connected heat pumps and ventilation units sold across the European Union. Its devices streamed temperatures, energy use, fault codes and runtime data to the cloud, where service teams used it for diagnostics and the product team used it to improve designs. Homeowners, installers and energy advisers saw only a slice of it in an app, and there was no way for a customer to take their data to someone else.
Why now. The EU Data Act gives users rights over the data their connected products and related services generate, including access and sharing with third parties they choose12. Its access-by-design obligation applies to connected products placed on the market after 12 September 2026, and commentators stress that it is an engineering obligation that has to be built into the product3. Separately, the Act's cloud switching rules prohibit switching charges from 12 January 20273. For a product line launching new models, both dates landed in the middle of the roadmap.
What had to be true
- Users can get their data easily, in a usable format, without raising a support ticket.
- Users can share it with an installer, energy adviser or app of their choice, and revoke that.
- Personal data handled under the GDPR, because household energy patterns can identify people4.
- Trade secrets protected through agreed measures, not used as a blanket excuse.
- No cloud lock-in in the platform itself, in line with the switching rules.
Architecture
The data flow, end to end
- EmitDevices send telemetry and events through regional gateways
- CatalogueEach data point is described: meaning, units, frequency, personal or not
- StoreRaw data kept per device and owner, separate from derived models
- AccessThe user downloads or queries their data through the app or API
- ShareThe user authorises an installer or app; the sharing service issues scoped access
- RevokeAccess ends when the user says so; every access is logged
The hard part: ingestion that scales with the fleet
Access by design starts at ingestion: if data is dropped, summarised too early or locked into a proprietary pipeline, users cannot get it later. The team standardised device telemetry on OTLP and placed a tier of OpenTelemetry Collectors in gateway mode behind a load balancer in each region, so data keeps flowing as the fleet grows and individual collectors can be replaced without loss5.

You cannot share data you never kept. Access by design is decided at ingestion, years before a user asks.
The second hard part was the line between raw data and know-how. Raw readings went into the user-accessible store; the predictive maintenance models and efficiency algorithms built from them stayed separate, with sharing partners bound by terms to protect anything sensitive. More on related patterns in OpenTelemetry Collector deployment patterns and data contracts.
How it ran
- Which data is in scope
- Trade secret measures
- Partner terms
- Collector gateways
- Catalogue and raw store
- User API and sharing service
- OTLP firmware support
- New models designed for access
- Field update plan
- Data per product line
- Personal data mapping
- Trade secret review
- Collector gateways
- Raw store
- Catalogue
- User API and download
- App integration
- Audit
- Sharing service
- Partner onboarding
- Portability checks
Key decisions and trade-offs
| Decision | Alternative | Why |
|---|---|---|
| Self-service access and sharing | Data requests through support | The obligation is about design; support processes do not scale |
| Separate raw data from derived models | One store for everything | Share raw data freely while protecting know-how |
| Open telemetry protocol and formats | Proprietary device protocol | Easier access, portability and partner integration |
| A data catalogue users can read | Raw field dumps | Data is only useful if people know what it means |
| Infrastructure as code, open formats | Deep use of one cloud's proprietary services | Keeps switching realistic as the rules intend |
What I'd do again, and differently
Again: treat the catalogue as a product, because it made the data useful to customers and partners, not just compliant. Differently: settle the trade secret approach with legal before building the stores, since it shaped the data model more than any technical choice. Related reading: lakehouse catalogue strategy and the EU AI Act roadmap.
If you build connected products for the European market, my work with European companies explains how I approach it, or analyse your challenge and bring the result to a call.
- 1Regulation (EU) 2023/2854 (Data Act)EUR-Lex · 13 Dec 2023
- 2Data ActEuropean Commission
- 3Data Act developments: 2026 and beyondMcCann FitzGerald · 2026
- 4
- 5OpenTelemetry Collector AntipatternsOpenTelemetry blog (Adriana Villela) · 1 Mar 2024