A local authority deploying a chatbot, a public body using AI for recruitment, and a social security agency relying on a case-processing support tool do not face the same obligations. The EU AI Act first requires each system to be classified according to its intended purpose, its risk level and the role of the public body. Since the AI Omnibus entered into force, the timeline for high-risk AI systems has changed, but several rules already apply.<\/p>\n\n\n\n
The Regulation covers two categories of operators that are particularly relevant to public bodies. The deployer<\/strong> is the body that uses an AI system under its own authority. The provider<\/strong> is the body that develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark.<\/p>\n\n\n\n In practice, a city council that buys an AI tool from a software vendor to use in its activities will generally be a deployer. If it develops an AI system, or has one developed, and puts it into service under its own name, it may be a provider and must then meet the obligations that come with that role. Using an external solution therefore does not exempt a public body from identifying its role under the EU AI Act and the responsibilities that follow from it.<\/p>\n\n\n\n The EU AI Act’s obligations apply in stages, according to the following timeline:<\/p>\n\n\n\n Note:<\/strong> Public bodies using high-risk AI systems have a timeline adapted to their situation. Providers and deployers of high-risk systems intended to be used by public authorities must, in any event, take the necessary steps to comply by 2 August 2030 at the latest. This regime must be checked for each AI system individually. It is not a general exemption for existing projects.<\/p>\n\n\n\n Some uses are not just a matter of compliance: they are prohibited when the conditions set out in Article 5 are met. Examples include social scoring that leads to certain types of detrimental treatment, and systems designed to infer emotions in the workplace or in education institutions, subject to the exceptions in the text. Real-time remote biometric identification in publicly accessible spaces for law enforcement purposes is also prohibited, except in strictly defined situations.<\/p>\n\n\n\n For example, before testing a tool meant to infer students’ emotional state during an exam, an institution must check whether it falls under a prohibition. Running a trial or buying the tool through public procurement does not make a prohibited practice lawful.<\/p>\n\n\n\n Annex III lists areas in which certain AI systems are considered high-risk because of their intended purpose. These include:<\/p>\n\n\n\n For example, a social security agency that uses an AI system to recommend granting or refusing an essential public assistance benefit must check whether this use falls under Annex III. The fact that a staff member makes the final decision does not, on its own, rule out classification as high-risk: under Article 6, the system’s influence on the outcome of that decision must be assessed.<\/p>\n\n\n\n Since 2 August 2026, systems intended to interact directly with people must be designed so that those people know they are interacting with AI, unless this is obvious from the context. This design obligation falls on the provider. For AI-generated or manipulated text published to inform the public on matters of public interest, the deployer must disclose that AI was involved, subject in particular to the exception for content that has undergone human review or editorial control with editorial responsibility.<\/p>\n\n\n\n For example, a local authority that publishes an information page generated by an AI tool to inform the public on a matter of public interest must disclose that the text was generated or manipulated by AI. This obligation does not apply, however, when the content has undergone human review or editorial control and a natural or legal person holds editorial responsibility for its publication. If the local authority offers a chatbot to help people with administrative procedures, it must also make sure they know they are interacting with an AI system, unless this is obvious from the circumstances and context of use.<\/p>\n\n\n\n From the applicable deadline, the deployer must use the system in accordance with its instructions for use. In particular, it must assign human oversight to people who have the necessary competence, training, authority and support, and then monitor how the system operates. It must also keep the automatically generated logs under its control for a period appropriate to the system’s intended purpose, and for at least six months unless other applicable provisions state otherwise. If using the system may present a risk, or if a serious incident is identified, Article 26 sets out measures for suspending use and informing the relevant parties, depending on the case.<\/p>\n\n\n\n For example, for a tool that supports staff recruitment, having a “human validator” is not enough. The body must specify who reviews the recommendations, how that person can challenge them, and what procedure to follow if a result looks abnormal. Human oversight must be exercised effectively, not reduced to a formal sign-off.<\/p>\n\n\n\n When the public body is the provider<\/strong> of a high-risk AI system, it must ensure the system complies from the design stage and throughout its lifecycle. This includes setting up a risk management system to identify, assess and control risks to health, safety and fundamental rights. It must also apply data governance practices to training, validation and testing datasets, in particular to check their relevance, representativeness and possible biases. On top of these requirements come technical documentation, a quality management system, and the applicable conformity assessment before the system is placed on the market or put into service.<\/p>\n\n\n\n Before deploying a high-risk AI system listed in Annex III, the bodies governed by public law concerned must carry out a fundamental rights impact assessment. The assessment covers how the AI system will actually be used: the processes it is part of, the people likely to be affected, the risks of harm, the human oversight arrangements, and the measures planned if those risks materialise. The results must then be notified to the market surveillance authority, except where the Regulation provides otherwise. When a data protection impact assessment already covers some of these elements, the body can refer to it or reuse the relevant parts, but this does not replace the assessment required by the AI Act.<\/p>\n\n\n\n Registration is a separate step. Before putting into service or using a high-risk system listed in Annex III, a public authority deploying an AI system must, for the systems concerned, register in the EU database, select the system and register its use. Systems under point 2 of Annex III are registered at national level, and specific arrangements also apply to certain sensitive uses. The provider has its own registration obligations.<\/p>\n\n\n\n For example, before using an AI system to assess eligibility for an essential public assistance benefit, a public body must document how the system is classified and analyse the effects of its use on applicants. It can then define how staff will oversee it, notify the results of the assessment where required, and complete the applicable registration formalities before putting the system into service or using it.<\/p>\n\n\n\n In practice, public bodies can start by taking an inventory of their systems and documenting, for each one, its intended purpose and the body’s role. Next, they can rule out prohibited practices, classify potentially high-risk use cases, and then assign an owner and a timeline to each obligation. This mapping must be updated whenever the use, the system or its context of use changes. It lets public bodies deal with the rules that already apply while preparing for the 2027 and 2028 deadlines.<\/p>\n\n\n\n For a public body, the challenge is not only to know the EU AI Act. It is to record every use of AI, justify how each one is classified, and track compliance actions over time. The Naaia AI management platform brings together a system registry, risk classification features, compliance workflows and dashboards. Discover the Naaia platform<\/a> to structure the governance of your AI projects and prepare for upcoming regulatory deadlines.<\/p>\n\n\nDifferent timelines for different obligations<\/h3>\n\n\n\n
\n
2. Which uses of AI require particular care from a public body?<\/h2>\n\n\n\n
Prohibited practices: a first filter that already applies<\/h4>\n\n\n\n
High-risk systems: use cases defined in Annex III<\/h4>\n\n\n\n
\n
3. What does a public body need to do in practice?<\/h2>\n\n\n\n
For the systems concerned, inform people<\/h3>\n\n\n\n
For high-risk systems, govern use and ensure effective human oversight<\/h3>\n\n\n\n
Before deployment, assess the impact on fundamental rights and check registration<\/h3>\n\n\n\n
4. Where to start with managing compliance?<\/h2>\n\n\n\n
Move from mapping to managing with Naaia<\/h3>\n\n\n\n