Updated 17 October 2026. This article has been revised to separate the policy timeline from the product argument. See the current AI Act timeline for the category-specific dates and primary reference.

A political agreement, formal adoption and entry into force are different milestones. An earlier version blurred those steps. The practical lesson is to track what changed without allowing a headline to become a release requirement.

Keep a regulatory change record

A change record should name the official source, the status of the measure, the date checked and the systems potentially affected. It should separate the text of the change from the team’s interpretation. That makes later corrections possible without rewriting the history of the decision.

Consider a transparency requirement. The team needs to know who must disclose what, to whom, in which circumstances and by when. “Add a watermark” may sound concrete while missing the actual scope. The interface, documentation and operational process may each need a different response.

Where the interpretation is unresolved, assign a reviewer and record the question. Do not turn an announcement into a universal rule through repetition. Three identical slides still count as one assumption.

Keep a regulatory change record: a practical review
Decision Evidence to request
Source status Proposal, agreement or enacted measure
Affected system Purpose and organisational role
Implementation decision Action, owner and unresolved questions
Illustrative product review aid.

I don’t think this is a disaster. Parts of the original AI Act were unworkable on the timeline, and I’d rather have a regulation that ships than one that collapses under its own complexity. The watermarking rule, for example, depended on a technical consensus that didn’t exist.

What to do with this

The useful output is a traceable change to a particular system or process. Keep the previous interpretation available, explain why it changed and identify what must be retested. That is a better response to a moving framework than repeatedly starting the compliance conversation from scratch.

Record the decision, the responsible owner and the evidence still missing. The decision-record example shows a lightweight way to do that. Where a claim concerns system behaviour, connect it to evaluation evidence. These are proposed product practices, not a finding that a system complies with the law.

Primary timeline reference: European Commission, AI Act. The operational recommendations above are my analysis.