Deadline roundups have a habit of listing everything at the same volume, which is not much help when you are deciding what to do this week. So this is four dates, sorted by what they actually ask of you, with the source for each one so you can check it rather than take our word for it.
Every date below was read in the instrument itself at its primary source on 29 September 2026, not in a summary. The article numbers are given so you can check each one rather than take our word for it.
Two of them still land this quarter. Two have already been running for a while. And one of the four is a different kind of thing altogether, which is where most of this post goes.
What is still to come this quarter
9 December 2026: the new product liability rules must be in national law. Directive (EU) 2024/2853 replaces the 1985 product liability regime, and Member States have to bring it into force by that date. Because it is a directive rather than a regulation, what binds you is your own country's implementing law, so the detail will vary. The direction will not.
24 December 2026: digital identity wallets. Under Article 5a(1) of Regulation (EU) 2024/1183, each Member State must provide at least one European Digital Identity Wallet within 24 months of the implementing acts entering into force. Those acts were published on 4 December 2024 and take effect on the twentieth day after publication, which puts the deadline on 24 December 2026. Both instruments were re-verified at their primary source on the day this was written. For most organisations the useful question is not the date itself but whether anything in your onboarding or signing flow quietly assumes a wallet that is not there yet.
What has been running for a while
Since 2 August 2026: the AI Act's transparency duties. Article 113 of Regulation (EU) 2024/1689 sets the general application date, and Article 50, which carries the marking and disclosure obligations for generative systems, follows it. It is roughly two months in. What changes from here is not the rule, it is how much patience anyone has for having done nothing about it.
Since 2 August 2025: the copyright policy duty for general purpose AI. Article 113 brings Chapter V into application on that date, and Article 53(1)(c) sits inside it. Providers of general purpose models have had to put a copyright policy in place for over a year, including respecting reservations of rights. If you publish work, the counterpart obligation is that your reservation has to be expressed in a form a machine can act on. Prose in your terms of service does not do it.
Our fuller treatment of the transparency side is on the EU AI Act page, and there is a practical Article 50 checklist if you want to work through it.
The one that is a different kind of thing
Three of those four are compliance in the ordinary sense. You read the rule, you change something, you are done. The product liability directive is not like that, and two provisions are the reason.
Software is a product. Article 4 defines a product as all movables, and says in terms that it includes electricity, digital manufacturing files, raw materials and software. If you ship software, you are inside this regime in a way you were not under the 1985 rules.
A court can order you to hand over your own evidence. This is the part worth reading twice. Under the directive's disclosure provision, where a claimant has presented facts and evidence sufficient to support the plausibility of their claim, the defendant is required to disclose relevant evidence that is at the defendant's disposal.
Read that as a sequence. Somebody makes a plausible claim. A court then tells you to produce what you hold. You do not get to decide at that moment what your records look like. That was decided months or years earlier, by whatever you were doing routinely.
What that actually asks of your records
Nothing in the directive says anything about how you keep records. It does not have to. An obligation to disclose relevant evidence is only as comfortable as the evidence is, and there are three questions a disclosure order tends to expose.
Can you show when something existed? A modification date on your own file server is a claim your own system makes about itself. It moves when files are copied, restored or migrated. It is not nothing, but it is not independent.
Can you show who produced it? Most systems can tell you which account touched a file. An account is not a person. If the question is whether a named individual made a decision or authored a design, account activity is weaker than it sounds, particularly after someone has left.
Can you show it has not changed since? Version history in a document tool is maintained by the same tool that holds the document. If the integrity of the record is the thing in dispute, an answer that depends on the disputed system is not much of an answer.
None of that is an argument for a project. It is an argument for one habit: when something matters, produce a record of it that does not depend on you, at the moment it is made rather than at the moment it is challenged.
The check worth doing this week
Take one thing your organisation produced this month that would hurt to be wrong about. A design decision, a client approval, a model card, a safety assessment.
Ask who would have to be believed for your version of events to stand. If the answer is your own file server, your own version history, or a colleague's memory, that is the gap. It is a small gap today and a large one in a disclosure order.
The dates matter less than the direction
Two of these four land this quarter and two have been live for months, but the useful pattern is not the calendar. It is that the questions are converging. The AI Act asks you to disclose how something was made. The product liability rules ask you to disclose what you hold once a claim is plausible. The wallet work asks who a person actually is.
Different instruments, the same underlying demand: be able to show it, to somebody who is not obliged to take your word for it. That demand does not have a date on it, which is exactly why it is easy to keep postponing.
