EU Data Act access by design means treating usable product-data access as part of the connected product and related service before release—not as an export request to solve after customers begin using it. For Austrian and DACH teams whose product data feeds AI maintenance, optimisation or decision support, the immediate management question is whether the release architecture can support authorised access without breaking security, privacy or trade-secret controls.
Why does 12 September 2026 change a product architecture decision?
From that date, Article 3(1) applies to newly placed connected products and related services, so access to relevant product data and metadata must be considered in the product design rather than deferred to an improvised support process. The regulation describes access that is easy, secure, free of charge, comprehensive, structured and machine-readable by default and, where relevant and technically feasible, directly available to the user.
An illustrative Vienna release review: the product works, but the data path does not
The device connects and the model produces a recommendation, but technical success has collapsed three questions: can the manufacturer see the data, can the user access it, and can an authorised third party use it safely? The release owner needs a documented answer.
What does “access by design” require at architecture level?
At architecture level, access by design requires a deliberate path from data generation to authorised use, including the metadata, identity controls and operational evidence needed to make that path usable and governable. It is not enough to prove that telemetry exists somewhere in a vendor dashboard.
Which connected products and related services belong in the review?
A connected product is not limited to a consumer gadget. Official EU guidance gives examples including connected cars, health and fitness devices, industrial or agricultural machinery and other products capable of communicating data. A related service is a digital service connected to the product in a way that affects or adapts its functions.
Who owns the decision: manufacturer, data holder, user or third party?
The executive sponsor owns the release decision, but the data-access design must distinguish the operational actors. The manufacturer designs and places the product on the market. The data holder may control readily available data. The user owns, rents or leases the product or receives the related service. A third party may receive data at the user's request, subject to applicable boundaries.
Which data should the architecture expose—and which data may remain outside scope?
Official Commission guidance distinguishes raw and pre-processed data that is readily available to the data holder from inferred or derived data. Relevant metadata needed to interpret and use the accessible data matters as much as the values themselves. An export full of undocumented field codes may be machine-readable in a narrow technical sense but still fail the operating purpose.
Why does this become an AI production-readiness issue?
An AI workflow cannot be more accountable than its data path. If an authorised user cannot identify the source, meaning, time range, quality controls and permitted uses of product data, the model output may be impossible to reproduce, challenge or safely transfer to another service provider.
The six-layer access-by-design readiness map
The map asks six answerable questions. A release owner should be able to point to an accountable person and evidence for every row.
| Layer | Decision question | Minimum evidence |
|---|---|---|
| 1. Scope and roles | Which product, related service, user and data holder are being assessed? | Product boundary, market-placement date, role map and accountable owner |
| 2. Data and metadata | Which raw or pre-processed data is readily available, and what metadata makes it usable? | Field catalogue, provenance, units, timestamps, quality notes and exclusions |
| 3. Access mechanism | Can the user obtain the data easily and in a structured machine-readable form? | Documented API, portal or export path; sample response; availability and latency record |
| 4. Identity and security | How are the user and an authorised third party authenticated, authorised and revoked? | Access-control model, credential flow, rate limits, audit log and incident route |
| 5. Protected boundaries | Where do personal data, trade secrets, product safety or third-country concerns change the path? | Data classification, lawful-basis decision, protection measures and escalation owner |
| 6. Evidence and contracts | Can the organisation prove what was promised, tested, approved and operated? | Pre-contract disclosure, interface test, decision record, change owner and review date |
Four release decisions are better than a binary compliance checkbox
The appropriate management output is not automatically “compliant” or “non-compliant”. It is a controlled product decision based on the unresolved layers and their consequence.
| Decision | Use when | Required record |
|---|---|---|
| Release | Scope, access path, controls, evidence and ownership are clear for the assessed product. | Signed baseline and scheduled review |
| release with conditions | A bounded gap has an owner, deadline, compensating control and rollback trigger. | Condition register and executive acceptance |
| Redesign | The data or metadata cannot be used safely, consistently or independently of an improvised manual path. | New interface boundary, test plan and release gate |
| Stop and obtain specialist review | Applicability, personal-data basis, trade-secret exposure, safety or contractual authority is unresolved and material. | Stop decision, preserved evidence and named legal/security question |
How should privacy, trade secrets and security change the access path?
Access is not permission to ignore other safeguards. The Commission explains that personal data requires a valid legal basis where the requesting user is not the data subject. It also describes protections for trade secrets and limited grounds connected to serious economic damage or product security. These are not excuses for a blanket refusal, nor are they issues an API team should decide alone.
What should the team do in the next seven days?
Freeze the release scope and identify every connected product or related service planned for EU market placement after 12 September 2026. Name the executive release owner, product owner, data holder, security owner and privacy/legal escalation owner. Test one real user request from identity verification to usable delivery, including relevant metadata.
What should be completed within 30 days?
Build the data catalogue, clarify readily available versus inferred data, document the access interface, define third-party authorisation and revocation, and connect product-data changes to change control. Test failure modes: unavailable export, stale metadata, excessive permissions, cross-customer leakage, revocation delay and a third party requesting data outside the agreed purpose.
What should be operational within 90 days?
Move from release preparation to an operating control. Monitor request completion, interface reliability, rejected-access reasons, security events, schema changes and evidence freshness. Re-run the decision when the product, related service, data store, access interface, AI purpose or third-party relationship changes materially.
The minimum product-data evidence pack
When does an Architecture Mandate make sense?
An Architecture Mandate is relevant when one consequential AI or automation workflow depends on connected-product data and the release owner cannot reconcile product scope, access, authority, controls and evidence. The mandate produces a bounded production decision; it does not provide legal advice, certification or a promise to implement the full product.
Bring one product or workflow, the planned market-placement date, the current data-access path, affected users, a system diagram if available and the unresolved release decision.
Frequently asked questions
Does the entire EU Data Act start on 12 September 2026?
No. The Data Act has applied generally since 12 September 2025; the later date concerns the Article 3(1) design obligation for connected products and related services placed on the market after 12 September 2026.
Does access by design always require a real-time API?
No. Direct access is required where relevant and technically feasible; the defensible mechanism depends on the product, the available data, the user need and applicable security and legal boundaries.
Are AI-generated insights and derived data automatically included?
No. Official guidance distinguishes readily available raw and pre-processed data from inferred or derived data, so the data boundary must be documented rather than assumed.
Can a manufacturer refuse access whenever trade secrets are involved?
No. Trade-secret and security protections are conditional and case-specific; they require proportionate measures, documented reasoning and specialist review rather than a blanket refusal.
What should an Austrian product team review first?
Start with one product release: identify the actors, market-placement date, data and metadata, access path, permissions, protected boundaries and the executive who owns the final release decision.
Verified official sources
- EUR-Lex — Regulation (EU) 2023/2854
- European Commission — Data Act explained
- Digital Austria — Data Act overview
- RTR Austria — implementation timeline
- RTR Austria — data access and use
Source review date: 6 September 2026. This article provides operational architecture analysis, not legal advice.
Continue Reading