Case study · Data platforms and regulation

Access by design: building an EU Data Act-ready data platform for a maker of connected equipment

A European manufacturer of connected heating and ventilation equipment collected rich product data, but only its own service teams could use it. The EU Data Act turned that into an obligation: users must be able to access the data their products generate and share it with others. The goal was to build that into the product platform rather than bolt on a support process.

Case studyManufacturing · European UnionSumanta Mukhopadhyay9 min read
#data#architecture#governance
CASE STUDY · CASE STUDY · DATA PLATFORMS AND REGULATION29 Oct 2026 · 14:40 GST
At a glance
SectorManufacturing · European Union
My roleFractional CTO and data architect
EngagementArchitecture, delivery leadership and product strategy
ScopeProduct data model, ingestion, user data access, third-party sharing, trade secret controls, cloud portability
What changed
  • 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
Device telemetry over OTLPOpenTelemetry Collector gatewaysEvent streamingProduct data catalogueUser data access APIConsent and sharing serviceLakehouseTerraform

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

Products
Heat pumpstelemetry and eventsVentilation unitstelemetry and eventsCompanion apprelated service data
Ingest
Collector gatewaysload-balanced, per regionEvent streamraw product data
Data
Product data cataloguewhat each field meansRaw data storeuser-accessibleDerived modelsproprietary, separated
Access
User data APIand downloadSharing servicethird parties, consent, revocationPartner onboardingterms and protections
Platform
Open formatsportable by defaultTerraformreproducible on another cloudAuditwho accessed what
Raw product data and proprietary derived models live apart, so sharing the first never exposes the second.

The data flow, end to end

  1. EmitDevices send telemetry and events through regional gateways
  2. CatalogueEach data point is described: meaning, units, frequency, personal or not
  3. StoreRaw data kept per device and owner, separate from derived models
  4. AccessThe user downloads or queries their data through the app or API
  5. ShareThe user authorises an installer or app; the sharing service issues scoped access
  6. RevokeAccess ends when the user says so; every access is logged
The user, not the support team, controls access and sharing.

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.

Diagram of a telemetry source sending data to a load balancer, which spreads it across three OpenTelemetry Collector instances in gateway mode before it reaches the destination
Collectors in gateway mode behind a load balancer: one scalable front door for all product data. Source: OpenTelemetry blog, Adriana Villela · CC BY 4.0

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

Product and legal
  1. Which data is in scope
  2. Trade secret measures
  3. Partner terms
Platform engineering
  1. Collector gateways
  2. Catalogue and raw store
  3. User API and sharing service
Device teams
  1. OTLP firmware support
  2. New models designed for access
  3. Field update plan
Legal decided what is shared and how it is protected; engineering made sharing self-service.
Phase 1Inventory
  • Data per product line
  • Personal data mapping
  • Trade secret review
Phase 2Ingest
  • Collector gateways
  • Raw store
  • Catalogue
Phase 3Access
  • User API and download
  • App integration
  • Audit
Phase 4Share
  • Sharing service
  • Partner onboarding
  • Portability checks
New product models were designed for access from the start; older fleets followed through updates.

Key decisions and trade-offs

DecisionAlternativeWhy
Self-service access and sharingData requests through supportThe obligation is about design; support processes do not scale
Separate raw data from derived modelsOne store for everythingShare raw data freely while protecting know-how
Open telemetry protocol and formatsProprietary device protocolEasier access, portability and partner integration
A data catalogue users can readRaw field dumpsData is only useful if people know what it means
Infrastructure as code, open formatsDeep use of one cloud's proprietary servicesKeeps 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.

References
  1. 1
  2. 2
    Data ActEuropean Commission
  3. 3
  4. 4
  5. 5
    OpenTelemetry Collector AntipatternsOpenTelemetry blog (Adriana Villela) · 1 Mar 2024
FAQ

Common questions

What does the EU Data Act require for connected products?

For connected products and related services placed on the EU market after 12 September 2026, product data must be designed to be accessible to users, and users can ask for it to be shared with third parties of their choice. Personal data in that data remains subject to the GDPR.

Can a manufacturer refuse to share data to protect trade secrets?

The Data Act allows trade secrets to be protected through agreed measures, and only in limited cases to refuse or suspend sharing. Designing the data model to separate raw product data from proprietary derived models makes this much easier.

How does the Data Act affect cloud contracts?

It includes rules to make switching between data processing services easier, and switching charges, including data egress charges for switching, are prohibited from 12 January 2027.

Keep reading

Related

Open to advisory, fractional CTO & select builds

Let's talk about what you're building.

The fastest route is a free 30-minute call. Prefer to write? Send a message and I'll reply personally within two business days.

Start a conversation

How would you like to reach me?

Book a 30-min callFastest. Pick any open slot on my calendar.→ Write in GmailOpens a pre-filled draft in your browser.→ Use my email appOutlook, Apple Mail or your default client.→

I reply personally within two business days. Time zones from the Americas and Europe to the Middle East and Asia-Pacific.