What Deployer Duties Apply in the Public Sector, Including Impact Assessment?

How do provider and deployer duties divide in the public sector?

Where a public authority buys a system from a provider, the provider carries the provider duties, including conformity, documentation and registration of the system, and the authority carries the deployer duties, including use in accordance with instructions, oversight, monitoring, logs, registration of its use and impact assessment. Where the authority develops the system in-house, or has it developed under its own name, it can be both provider and deployer, and the duties of both roles must be recorded separately, with the development file and the deployment file distinguished even where the same team produces both. Where the authority substantially modifies a system or changes its intended purpose, Article 25 can make it a provider for the modified system, and that change should be assessed before it is made. The division should be recorded in a responsibility matrix, naming the provider, the deployer, the overseer, the impact assessment owner and the registration owner, so no duty is assumed to belong to another party.

When is a fundamental-rights impact assessment required?

Article 27 requires a fundamental-rights impact assessment, in outline, from deployers that are bodies governed by public law deploying high-risk systems, and from private deployers providing public services where the system is listed in specified Annex III areas, including creditworthiness, insurance pricing and the essential services areas in point 5. The assessment must be carried out before first use, must describe the deployment, the affected people, the risks to fundamental rights, the oversight and the measures to address the risks, and must be notified to the market surveillance authority with a summary published. A public authority should therefore check, for each deployment, whether it is a body governed by public law, which Annex III point the system falls under, and whether the Article 27 scope is met, recording the conclusion with the provision cited. A conclusion that no assessment is required should be as carefully reasoned as a conclusion that one is required, since the assessment duty is a common source of supervisory findings.

For the broader regulatory framework, see finance, insurance and critical infrastructure.

How should an assessment be prepared and used?

An assessment should be prepared from the actual deployment, with input from the operational teams, the data protection officer, the legal team and, where appropriate, the people affected or their representatives. It should describe the processes, the purpose, the context, the period and frequency of use, the affected groups, the specific risks, the oversight, the mitigation measures and the complaints and redress mechanisms, and it should be honest about limitations and open questions. The assessment should drive decisions: where it identifies a risk that cannot be mitigated, the deployment should be changed, restricted or not carried out, and that decision should be recorded. The assessment should be reviewed when the deployment, the population or the system changes, and the review should be recorded with the date and the owner. An assessment that is filed without influencing the deployment, or that is copied from another deployment without adaptation, does not satisfy the provision, however complete its headings appear.

What reasons and challenge route must be provided?

A public authority must be able to give reasons for a decision that affects a person's rights or entitlements, and must provide a route to challenge the decision, under administrative law and, where applicable, the Article 86 explanation right and data protection rights. The reasons should explain the system's role, the main factors, the data used and the human review that took place, in terms the person can understand, and the challenge route should be accessible, timely and capable of changing the outcome where the challenge is upheld. The deployer should record the reasons given, the challenge received and the outcome, and should monitor challenges for patterns that indicate a systemic problem. A decision letter that states only that an AI system was used, without reasons or a challenge route, does not satisfy the authority's duties, and a challenge process that cannot change an outcome is not a remedy. The reasons and challenge design should be tested with a sample decision before the system goes live.

How does the 2 August 2030 deadline work?

Under Article 111(2), providers and deployers of high-risk AI systems intended to be used by public authorities must take the necessary steps to comply with the requirements and obligations in the Regulation by 2 August 2030, even where the general transition for systems already on the market would otherwise apply. That deadline is a fixed compliance date for public authority systems, not an open-ended transition, and it should be planned as such, with classification, documentation, conformity, oversight and impact assessment work sequenced to meet it. Other duties, including prohibitions, literacy, transparency and registration, apply on their own earlier dates and are not postponed by the 2030 deadline. A public authority should therefore maintain two calendars: one for the duties already applying, and one for the high-risk work that must be complete by 2 August 2030, with an owner and a review date for each item. A plan that treats 2030 as a reason to pause all work will miss the duties that are already due.

Continue with public sector benefits and essential services.

What does this guide not decide?

This guide does not decide whether any public authority must carry out a fundamental-rights impact assessment, what any assessment must contain, or whether a public sector decision was lawful. Those questions depend on the authority's status, the system's Annex III point, the deployment context and the consolidated text of Article 27, together with administrative and data protection law, applied to the specific facts with qualified advice. The guide also does not cover procurement law, which governs how a public authority buys a system and can impose its own duties. Where a public sector deployment is planned, confirm the registration, assessment, oversight, reasons, challenge and deadline position with a competent authority or legal adviser before first use.

Frequently asked questions

Continue through this AI Act cluster

• finance, insurance and critical infrastructure
• public sector benefits and essential services
• which deployers must register their use
• sector oversight, evidence and impact assessment
• how AI Act transitions work for systems already on the market
• deployer responsibilities