What changed on 12 September 2026?

The Data Act has applied generally since 12 September 2025. The Article 3(1)- access by design obligation had a further year’s grace, and that transitional period ended on 12 September 2026. The obligation is now binding.

The rule is a product-design requirement, not only a contractual one. Connected products and related services must be built so that the data generated through their use is accessible to the user by default, easily, securely and free of charge. This covers product data, related service data and the metadata needed to interpret them. 

Three points matter in practice:

• It looks forward. It applies only to new products placed on the market after the deadline and is not retroactive. 

• It is not a redesign mandate. According to a January 2026 summary of the Commission’s FAQs, the Data Act does not impose a strict obligation to redesign products, and manufacturers remain free to design as they see fit while complying. 

• It overlaps with cybersecurity rules. The Cyber Resilience Act’s Article 14 reporting duties started the day before, on 11 September 2026, and cover all in-scope products on the EU market, not only new ones. Manufacturers are handling both deadlines together. 

The Act is also still moving. The Commission’s Digital Omnibus would consolidate several data laws into the Data Act. The Council has been working on its position, and it wants to adopt the Omnibus texts before the end of 2026. The rules that apply today (as on 10 November 2026) may therefore change again soon. 

The gap: access is only half the lifecycle

The Data Act is built to open data up. Article 3(1) makes it easier for users, and through them third parties, to obtain and reuse data. That is good for competition and innovation. But more data in circulation means more data flowing into analytics pipelines and machine-learning systems, and there is little mechanism for taking it back.

AI4POL has been working on this. In The Goldilocks Standard, Pratiksha Ashok argues that the Data Act promotes access, portability and interoperability, all of which look forward, and none addresses removing data’s influence after the fact. The paper adds that the Act is silent on who is responsible when data has passed through a chain of developers, cloud providers and downstream users. 

That silence matters because of how AI works. Personal data used in training shapes a model’s parameters, and those parameters keep reflecting the data after the original records are gone. Deleting a database row does not remove that influence. Machine unlearning is the field that tries to. 

Provenance plus unlearning

AI4POL’s 2026 Guidance Document describing technical methodologies for lawful and secure data exchanges, proposes two complementary tools for this problem:

• Machine unlearning means removing the influence of specific training data from a model, so that organisations can fix the problem without scrapping everything.

• Data provenance means documenting the origin, history and transformation of data across its lifecycle. It tells you which data is the problem and where it went.  

The report’s logic is that without provenance, organisations may not know which data to remove, and without unlearning, the effect of unlawful data on downstream systems cannot be eliminated. Without such tools, the default response may be to invalidate entire datasets or models. That would undercut the innovation the Data Act exists to promote. 

The guidance assesses both exact and approximate unlearning, with attention to the trade-offs between formal guarantees, computational cost and scalability. It recommends provenance-by-design in data-sharing infrastructures, recognition of unlearning as a compliance tool under EU law, and clearer liability in interconnected data ecosystems. 

Connecting the dots

Article 3(1) already requires products to share data together with the metadata needed to use it. If that metadata also carried origin and legal-basis information, product design could become the first link in a provenance chain. Manufacturers building access features now are making architecture choices that either help or hinder later traceability.

The GDPR’s erasure rules rely on reasonable steps that take available technology and cost into account, because requiring perfect deletion would make compliance close to impossible. Unlearning is still maturing, so a proportionate standard is sensible. But a proportionate standard needs technical benchmarks, certification and supervisory expertise. These are the same priorities AI4POL lists. 

What to do now

If you make connected products, treat Article 3(1) as a product-governance task- map your data, check your pre-contractual information duties under Articles 3(2) and 3(3), and document your access mechanisms. Also ask now how your data flows would respond if a dataset had to be traced and cleaned up later.

Access by design is the start of the data lifecycle. The unresolved legal question is the end of it: what happens when data has to be withdrawn which is discussed further in the Guidance Document.