Standards, common specifications, codes, guidelines and Service Desk material change over time, and a file that cites a version without a date, a source and a check will become out of date without anyone noticing. A tracking routine should list each source relied on, with its title, number, version, publisher, Official Journal citation where relevant, date checked, and the person who checked it, and should review the list at a planned interval and when the system, the law or a standard changes. The routine should cover the consolidated Regulation, the standardisation request, the JTC 21 work programme, the Official Journal citations, the common specifications, the GPAI Code of Practice, the Commission guidelines, the AI Office material and the Service Desk material. This guide gives the routine and the sources. It does not state the current version of any source.
What sources must be tracked?
The sources that must be tracked are the consolidated Regulation (EU) 2024/1689 as amended, including Regulation (EU) 2026/1744, the Commission standardisation request Decisions C(2023) 3215 and C(2025) 3871, the JTC 21 work programme and deliverable stages, the Official Journal citations for harmonised standards, the implementing acts for common specifications, the General Purpose AI Code of Practice and its signatory and monitoring material, the Commission guidelines on the AI system definition, on prohibited practices, on high risk classification, on general purpose models and on other topics, the AI Office guidance, templates and information platform material, and the AI Act Service Desk material including the timeline, the article pages and the frequently asked questions. Sector legislation, sector standards and sector guidance must also be tracked where a product or sector system is concerned, with the sector source list kept alongside the AI Act list. A tracking list that covers only the Regulation, without the standards, codes and guidance, will miss the changes that affect the file most often. A list that covers only standards, without the Regulation, will miss the amendments that change the duties themselves. The list should be complete for the system concerned, and should be reviewed when a new source is published or a new system is added.
How should versions and dates be recorded?
Each source on the tracking list should be recorded with its title, number or identifier, version or edition, publisher, date of publication, Official Journal citation where relevant, date checked, checker, and the systems or files that rely on it. The record should state the version relied on, not only the title, because a title can cover several versions with different content. For a standard, the record should state the number, the year, the version, the citation status and the parts applied. For a guideline, the record should state the title, the date, the version and the provisions it addresses. For Service Desk material, the record should state the page, the date checked and the proposition relied on, with a note that Service Desk material can reproduce the original 2024 text and that amended dates should be checked against the consolidated law, as the existing site About page notes. For a code, the record should state the version, the chapters signed or adopted, and the monitoring position. The record should be kept in a single register, with a change log, so that a reviewer can see what changed, when, and what file was updated as a result. A register that is kept in several places, with different versions in each, will create confusion and will be difficult to audit.
For the broader regulatory framework, see codes, standards and sandboxes overview.
How often should sources be rechecked?
Sources should be rechecked at a planned interval, and on defined triggers. The planned interval should be short enough to catch changes that affect the file, and long enough to be sustainable for the team. A monthly or quarterly interval is a reasonable starting point for a small team, with a shorter interval for a system that is approaching placing on the market, that is in a sandbox or test, or that is subject to a notified body assessment. Triggers for an immediate recheck include a Regulation amendment, a new standardisation Decision, a new Official Journal citation, a new common specification, a new Code version, a new Commission guideline, a system change, a substantial modification, a serious incident, or an authority question. The recheck should be recorded with the date, the checker, the result, and the action taken, including a nil return where no change was found. A recheck that is not recorded will not be visible to a reviewer, and a reviewer will assume that no recheck was done. The interval and the triggers should be written into the quality management or governance procedure, with a named owner, so that tracking does not depend on the memory of one person.
How should changes be handled in the file?
When a tracked source changes, the file that relies on it should be assessed for impact, updated where needed, and re reviewed. The assessment should state the change, the requirements affected, the systems affected, and the action: no action, a file update, a retest, a new conformity assessment, or a customer or authority notification. The update should be version controlled, with the old version retained, the new version dated, and the change described. Where a standard is withdrawn or superseded, the file should state the replacement, the coverage comparison, and the action taken, as described in the common specifications guide. Where a guideline changes an interpretation, the file should state the old interpretation, the new interpretation, and the reasoning for the change in the classification or the file. Where the Regulation is amended, the file should state the amending instrument, the provisions changed, and the application dates, with the verified date list updated. Changes should be communicated to the people who need them, including the development team, the deployers and the customers where the change affects use, with the communication recorded. A change that is handled silently, without a file update or a communication, will create a gap between the file and the system.
What tools and habits support tracking?
Tracking can be supported by simple tools and habits, without expensive software. A single register, kept as a spreadsheet or a document with version control, is sufficient for a small team, provided that it is kept up to date and is reviewed. Alerts from EUR-Lex, from the Official Journal, from the Commission standardisation page, from the AI Office and from the Service Desk can help, provided that the alerts are reviewed and the results are recorded, rather than accumulating unread. A calendar with the review interval, the standardisation milestones, the guideline consultations and the application dates can help the team to plan. A habit of checking the source before citing it, rather than copying a citation from an earlier file, will prevent the propagation of out of date citations. A habit of recording the date checked, on every citation in a file, will make out of date citations visible. A habit of reviewing the register at a team meeting, with the owner reporting changes and actions, will keep tracking alive. Tools and habits should be proportionate to the team and to the portfolio, and should be reviewed when the portfolio grows.
Continue with harmonised standards process.
What does this guide not state?
This guide does not state the current version, citation status or content of any standard, specification, code, guideline or Service Desk page, and it does not list the current deliverables, citations or guidelines. Those matters change, and they must be checked on the official sources on the date of use, with the register recording what was found. A guide that stated a current list would become out of date quickly, and a file that copied that list without checking would be unreliable. This guide gives the tracking routine, the source types and the habits, not the current list. A team that follows the routine will have a register that is current on the date it is checked, and that is the only current list that matters for its file.
Frequently asked questions
How often should the standards register be checked?
At a planned interval, such as monthly or quarterly for a small team, and immediately on triggers including a Regulation amendment, a new Official Journal citation, a new specification or Code version, a new guideline, a system change, a serious incident or an authority question. Each check should be recorded with date, checker, result and action, including a nil return.
What should be recorded for each source?
Title, number or identifier, version, publisher, publication date, Official Journal citation where relevant, date checked, checker, and the systems or files that rely on it. For standards, the parts applied. For guidelines, the provisions addressed. For Service Desk material, the page, date checked and proposition relied on, with the consolidated law checked for amended dates.
Can Service Desk material be relied on alone for dates?
No. Service Desk material can reproduce the original 2024 text, and amended dates should be checked against the consolidated Regulation as amended by Regulation (EU) 2026/1744. The Service Desk timeline is a useful checking route, but the consolidated text is the legal source for application dates.
What happens when a standard is superseded?
The file should be assessed for impact, the replacement and coverage comparison recorded, and the file updated, retested or reassessed as needed, with version control and communication to affected people. Continuing to cite a withdrawn or superseded standard without that assessment will leave the file out of date.
Continue through this AI Act cluster
This article is an informational overview, not a legal determination. Check the current legal text and official implementation guidance for your system and role.
Consolidated Regulation (EU) 2024/1689 ↗European Commission AI Act standardisation ↗AI Act Service Desk timeline ↗