Provider registration under Article 49 must happen before placing a system on the market or putting it into service, and deployer registration under Article 49(3) must happen before putting a system into service or using it. An entry must then be kept accurate for the system version and use it describes: a change in provider, system version, intended purpose, operator role or deployment use should trigger a check of whether the entry needs correction or a new registration, and whether the technical documentation and monitoring plan need the same update. The registration record should carry the version, the submission date and the review trigger, so an outdated entry is visible before an authority or deployer relies on it.
What is the before-market timing rule?
The timing rule is a sequencing rule, not a filing deadline measured in days. Article 49(1) and (2) require registration before placing on the market or putting into service, and Article 49(3) requires deployer registration before putting into service or using the system. That means the registration step sits in the release and deployment approval path, after classification and before availability to users. A release record should show the registration step as completed, with the system version and the registrant named, before the release is approved. Where a system is made available in stages, each stage that constitutes placing on the market or putting into service for a new version or a new deployment should be tested against the timing rule separately. A single early registration does not automatically cover every later release, and a team should be able to show, for any version in use, when its registration was completed.
What changes should trigger a registration review?
A registration review should be triggered by any change that could make the entry inaccurate. That includes a change in the provider or authorised representative, a change in the named registrant or contact details, a new system version, a change in intended purpose, a change in the Annex III category considered, a change in the Article 6 reasoning, and a change in deployer, deployment site or use. It also includes a change in the database specification or in the Annex VIII item list following an amendment. The review should ask three questions: does the entry still describe the same system, does it still describe the same operator and use, and does it still contain the information the current Annex requires? If the answer to any question is no, the entry should be corrected or supplemented promptly, and the correction should be recorded with the date and the reason. Leaving a superseded entry in place while a new version operates creates a mismatch an authority can identify quickly.
For the broader regulatory framework, see EU database, registration and post-market monitoring.
How should versions be handled?
Versions should be handled by identity, not by assumption. Each system version that is placed on the market or put into service should be identifiable in the registration record, the technical documentation and the monitoring plan by the same identifier, so a reviewer can trace one version across all three records. Where a change is a new version, the team should decide and record whether the change requires a new registration, an update to the existing entry, or no registration action because the entry already covers the version as specified in the current database specification. That decision should be based on the consolidated text and the current specification, not on internal release numbering alone. A version history that lists the registration action taken for each release, with dates and owners, is the simplest way to show that version control was applied, and it should be kept with the product's compliance record.
How does timing connect to conformity and monitoring?
Registration timing sits between conformity and operation. Conformity assessment, technical documentation and, where applicable, the EU declaration of conformity are prepared before market placement, and registration records the outcome of that preparation in the database. Post-market monitoring under Article 72 then begins once the system is in service, and serious incident reporting under Article 73 follows from monitoring. If registration is late, the chain is broken at its first public link, and if monitoring findings are not fed back into the registration and documentation records, the chain is broken at its later links. The practical control is a single lifecycle record per system version that carries the classification, conformity, registration, monitoring and incident entries together, with a shared identifier and a review date. A change in any one part should prompt a check of the others, so the lifecycle record never describes a system that no longer exists.
What should the registration log contain?
A registration log should contain, for each system version, the registration route, the entry identification, the submission date, the registrant and their authority, the specification version used, the Annex items entered, and the review trigger set for the next change. It should also record corrections and updates, with the date, the reason and the person who approved them, preserving the earlier position rather than overwriting it. For deployer registrations, the log should also record the provider entry selected and the deployment approval it supported. The log is an internal record, distinct from the public database entry, and it should be retained with the system's compliance documentation for the period the Act and other applicable law require. A log that only records the first registration, with no update history, cannot show that the entry was maintained, and it should be treated as incomplete.
Continue with registration duties for providers under Article 49.
What does this guide not decide?
This guide does not state the exact database mechanics for correcting or supplementing an entry, which depend on the current functional specification and Commission operational material, and it does not decide whether a particular change requires a new registration or an update. Those questions require the consolidated text, the current specification and the facts of the change to be examined together. The guide also does not set retention periods for registration logs, which depend on the applicable provisions and other law. Where timing or update treatment is uncertain for a release, confirm the position with a competent authority or legal adviser before the system is placed on the market or the change is deployed.
Frequently asked questions
Can registration be completed after launch?
No. Article 49 requires registration before placing on the market or putting into service, and deployer registration before putting into service or use. Registration should sit in the release and deployment approval path.
Does every software update need a new registration?
Not necessarily. The question is whether the change makes the entry inaccurate for the system version, purpose or operator concerned, and whether the current specification requires a new or updated entry. Each change should be reviewed and the decision recorded.
What should be kept when an entry is corrected?
The date, the reason, the person who approved the correction, the earlier position and the specification version used. Corrections should supplement the record rather than silently overwriting the earlier entry.
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, as amended ↗AI Act Service Desk: Article 49 registration ↗AI Act Service Desk implementation timeline ↗