EU AI Act for the public sector

Article 27(1) requires a fundamental rights impact assessment before the first use of a high-risk Annex III system. The duty falls on bodies governed by public law, on private entities providing public services, and on deployers of credit scoring and life and health insurance pricing systems. For a public authority, the assessment must be completed before the system goes live, not after a pilot or a procurement milestone. Critical infrastructure systems are excluded from this particular duty, so confirm early whether a planned use falls under that carve-out. The assessment covers the rights a deployment could affect, the people likely to be affected, the specific risks of harm to those rights, and the measures the authority will take if those risks materialize. Your legal counsel should confirm the exact method and the level of detail your national authority expects, because the Act sets the obligation but leaves the working method to the deployer.

The assessment is not a substitute for the GDPR data protection impact assessment, but the two overlap heavily. Article 26(9) requires deployers to use the information the provider supplies under the Act when they carry out a GDPR data protection impact assessment. In practice, the team should request the provider's instructions for use, known limitations, data inputs, and performance information before drafting either document, then record in each assessment where it relied on that material. Keep the two documents cross-referenced so that a reviewer can trace one risk from the fundamental rights analysis to the data protection analysis and the mitigation chosen.

The authority owns the assessment, its conclusions and any decision to proceed. No fact supplied for this page makes an external assessor, auditor or certification body sign it off, so do not describe a third party's review as a legal requirement. You may still choose to commission independent support to prepare the evidence, test the system's behavior against the documented risks, or challenge the reasoning, and that work should be scoped in writing with named deliverables. Store the signed version, the supporting records, and the date of first use together, because the same record set will be needed for the registration duties under Article 49(3) and for any later review.

A public authority that makes a decision based on the output of a high-risk Annex III system owes the affected person a clear and meaningful explanation of the AI's role in that decision and of the main elements of the decision itself. Article 86(1) gives this right to any person affected by a deployer's decision that has legal effects or similarly significant adverse effects on their health, safety or fundamental rights. The right is triggered by the effect on the person, not by the label on the system, so an authority should check each benefit, eligibility or emergency workflow that uses AI output against that test. Annex III point 5(a) covers eligibility decisions for essential public assistance benefits and services, so most of these cases will sit there. Critical infrastructure systems are excluded from the Article 86 right.

Being able to explain a decision depends on records made at the time it was taken. The authority should be able to produce the system's role in the case (the input data, the output score or classification, and the version of the model in use), the human review step with the reviewer's name and the basis for accepting or overriding the output, and the notice or letter sent to the person. Deployer duties in Article 26 point to logs kept for an appropriate period and to the human oversight arrangements that the provider's instructions describe. Ask the provider which fields its logging produces and whether they can be exported per case, because a generic system log rarely explains one decision. Test the process with a sample case that a caseworker must explain without reference to the vendor's documentation.

The wording of notices, explanation templates and appeal routes should be reviewed by legal counsel familiar with administrative law in the relevant Member State, alongside the GDPR rules on automated decisions. The AI Act sets the substance of the explanation, but national procedural rules set how and when it must be given. Confirm with counsel whether the explanation is delivered in the decision letter, on request, or both, and who answers follow-up questions. Budget for that review as a one-time cost per template, plus a recurring check whenever the system or its output changes. An explanation that describes the model in general terms without the main factors in the individual case will not meet the test in Article 86(1).

A public authority deploying a high-risk system under Annex III must be able to show its own evidence set on request. The core items are a system inventory entry for each AI use, the fundamental rights impact assessment (FRIA) record completed under Article 27(1) before first use, the registration confirmation issued after the authority registers itself and the system under Article 49(3), logs kept from the system's operation, written human oversight procedures, and explanation templates for citizens who receive a decision under Article 86(1). The authority owns each of these records, signs off the FRIA, decides who may override the system and answers to the market surveillance authority for them. Before any of this is filed, the authority should confirm that the system appears in the EU database, because Article 26(8) bars deployers from using a system that is missing from it.

A partner can prepare much of the working material behind those records. Typical preparation work includes mapping the provider's documentation to the authority's own inventory, drafting the FRIA worksheets for the authority's legal and data protection staff to review, configuring log retention and export on a self-hosted platform inside the authority's own infrastructure, writing oversight runbooks, and building explanation templates that name the system's role and the main elements of a decision. The partner should not sign the FRIA, select the system on the authority's behalf in a way that removes the authority's accountability, or certify the result. Ask the partner to name, in writing, which artifacts it will produce, which the authority must approve, and where each one is stored.

For most Annex III systems, no independent body is part of the high-risk route. Providers normally use the internal-control conformity assessment described in Annex VI, so the authority should not budget for a notified body unless its specific system or its provider's route requires one, which the provider should confirm in writing. Any independent audit that the authority commissions for its own assurance is a separate purchase and should be scoped as such. DeployOpen prepares systems, controls and evidence for assessments. It does not issue assessments, attestations or certificates, and no DeployOpen deliverable should be presented to a regulator as an independent finding.