Under Article 49(3), before putting into service or using a high-risk AI system listed in Annex III, other than a system referred to in Annex III point 2, deployers that are public authorities, Union institutions, bodies, offices or agencies, or persons acting on their behalf, must register themselves, select the system and register its use in the EU database. Private deployers are not subject to this deployer registration duty, although they carry other deployer obligations under the Act. Deployer registration therefore records the use of a system by a public body, and it is distinct from the provider's registration of the system itself.
Which deployers does Article 49(3) cover?
Article 49(3) covers deployers that are public authorities, Union institutions, bodies, offices or agencies, or persons acting on their behalf. The test is the nature of the deployer, not the sector alone: a public authority deploying an Annex III high-risk system for its own operations is within the provision, and a contractor acting on behalf of such a body can also be within it where it deploys the system for that body. A private company deploying the same system for its own commercial purposes is not covered by the deployer registration duty in Article 49(3), although it remains subject to the deployer duties in Article 26 and other applicable provisions. A deployer that is unsure of its status should record the legal basis for its conclusion, including its public-authority character and any acting-on-behalf arrangement, rather than assuming that registration is either required or unnecessary.
What does a deployer register?
A covered deployer registers itself, selects the system in the database and registers its use. The information it enters is the data listed in Section C of Annex VIII, which concerns the deployer and the use, as distinct from the provider and system information in Sections A and B. Selecting the system, rather than creating a new system entry, is the mechanism that links the deployer's use to the provider's registration of the same system, and it depends on the provider's entry existing and being identifiable. A deployer should therefore confirm before deployment that the system has been registered by its provider, record the system identification used, and keep the link between its own use record and the provider's entry. Where the system cannot be found, or where the entry does not match the system version supplied, the deployer should raise the discrepancy before putting the system into service rather than creating a duplicate or inaccurate record.
For the broader regulatory framework, see EU database, registration and post-market monitoring.
When must deployer registration happen?
Deployer registration must happen before putting the system into service or using it. That timing makes registration part of the deployment decision, alongside instructions, oversight arrangements, staff competence and any fundamental-rights impact assessment that may be required for the use. A public body that deploys first and registers later has missed the sequence the Act prescribes, and the gap can be visible to a supervisory authority because the use itself will have generated logs, decisions or outputs before any entry existed. The practical control is to add registration to the deployment approval checklist, with a named registrant, the Section C information prepared, and the system selection verified before the go-live decision is signed. Where deployment is phased across sites or teams, each phase should be checked against the registration record rather than assuming the first registration covers every later use.
How does deployer registration differ from provider registration?
Provider registration and deployer registration answer different questions. Provider registration records that a system exists, who provides it and what it is intended to do. Deployer registration records that a particular public body is using that system, for what purpose and under whose authority. The two entries must be consistent on system identity and intended purpose, but they are owned by different operators and carry different information. A change in provider, system version or intended purpose can therefore require action on both entries, and a change in deployer, deployment site or use can require action on the deployer entry alone. Keeping the two records in separate ownership, with a named owner for each and a shared system identifier, prevents a provider update from silently invalidating a deployer record, or a deployer change from being mistaken for a provider change.
What about sensitive and national registrations?
The deployer duty is subject to the same sensitive-system and national-route limits as the provider duty. For high-risk systems in Annex III points 1, 6 and 7 in the areas of law enforcement, migration, asylum and border control management, registration under Article 49(4) sits in a secure non-public section with only the specified Annex VIII and Annex IX information, and access is limited to the Commission and the national authorities referred to in Article 74(8). For Annex III point 2 systems, registration is at national level under Article 49(5). A public-authority deployer in a sensitive area must therefore identify its access category before registering, and must not enter information beyond the specified items or in a public section where a restricted section applies. Where the category is unclear, the deployer should seek confirmation from the relevant authority before submitting, and should record the advice received with the registration record.
Continue with what is public and what is restricted in the EU database.
What does this guide not decide?
This guide does not decide whether a particular organisation is a public authority, whether a contractor is acting on behalf of a public authority, or whether a particular use must be registered. Those questions depend on the organisation's legal status, the deployment arrangement and the system's Annex III category, and they require the consolidated text and the specific facts to be examined together. The guide also does not cover fundamental-rights impact assessment, data protection or procurement duties that may apply to the same deployment, which are separate obligations with their own triggers. Where deployer registration or public-authority status is in doubt, confirm the position with a competent authority or legal adviser before the system is put into service.
Frequently asked questions
Must a private company register its use of a high-risk system?
No, not under Article 49(3). That duty covers deployers that are public authorities, Union institutions, bodies, offices or agencies, or persons acting on their behalf. Private deployers carry other deployer obligations, including those in Article 26.
Does deployer registration replace provider registration?
No. The provider registers the system, and a covered deployer registers its use by selecting that system. The two entries are distinct, owned by different operators, and both must be accurate for the system version concerned.
What if the provider's system cannot be found in the database?
The deployer should raise the discrepancy before putting the system into service, confirm the system identification with the provider, and avoid creating a duplicate or inaccurate record. The mismatch should be recorded with the deployment decision.
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 ↗