EU AI Act deployer obligations: Articles 26, 27, 4 and 50

Under the EU AI Act, a deployer is any organisation using an AI system in a professional capacity, as opposed to the provider that develops or supplies it. Deployers must support AI literacy (Article 4) and meet certain transparency duties (Article 50), and for high-risk systems they must follow Article 26 and, in some cases, run a fundamental rights impact assessment (Article 27). Most organisations will meet the EU AI Act as deployers rather than providers. They do not build the models, but they use them in hiring, lending, customer service and operations. The Act gives deployers their own duties, and some of them already apply. This guide sets out what each article asks, as amended by Regulation (EU) 2026/1744, and how to prepare.

Who counts as a deployer

The Act defines a deployer as a natural or legal person, public authority, agency or other body using an AI system under its authority, except in a personal non-professional activity. The Act reaches deployers established in the EU, and deployers outside the EU where the system’s output is used in the EU.

The line between deployer and provider matters. Under Article 25, a deployer becomes the provider of a high-risk system, with the provider’s much heavier obligations, if it puts its name or trademark on the system, makes a substantial modification, or changes the intended purpose of a system so that it becomes high-risk.

Article 4: AI literacy

Article 4 has applied since 2 February 2025 and covers every provider and deployer, whatever the risk level of their systems. Regulation (EU) 2026/1744 replaced its text. The duty is now to take measures to support the AI literacy of staff and others dealing with the operation and use of AI on the organisation’s behalf. It no longer requires the organisation to ensure a sufficient level, and it states that no specific level is required of any individual.

A proportionate response looks like this.

• Basic guidance for everyone who uses AI tools, covering what they are for, what they get wrong and what data must not go into them.
• Role-specific training for people who operate or oversee consequential systems, covering the system’s limitations and how to intervene.
• A record of who was trained on what, and when, so you can show the measures exist.

Article 50: transparency

Article 50’s duties have applied since 2 August 2026. Two fall on deployers.

• Emotion recognition and biometric categorisation. Deployers must inform the people exposed to the system and process their personal data in line with data protection law.
• Deepfakes and AI-generated text. Deployers who generate or manipulate image, audio or video content that is a deepfake must disclose that it has been artificially generated or manipulated. Deployers who publish AI-generated or manipulated text to inform the public on matters of public interest must disclose that too, unless the text has undergone human review or editorial control and someone holds editorial responsibility.

There are limits for evidently artistic, creative, satirical or fictional work and for lawful law enforcement use. The other Article 50 duties, such as telling people they are interacting with an AI system and marking synthetic content in a machine-readable way, fall mainly on providers. Providers of generative systems already on the market before 2 August 2026 have until 2 December 2026 to meet the marking duty in Article 50(2).

Article 26: deploying high-risk systems

Article 26 is the core of a deployer’s obligations for high-risk systems. Following the Digital Omnibus, it applies from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I systems. Its content did not change.

• Use the system as instructed. Take technical and organisational measures to use it in line with the provider’s instructions for use.
• Assign human oversight. Give oversight to people with the necessary competence, training, authority and support.
• Check input data. Where you control the input data, make sure it is relevant and sufficiently representative for the intended purpose.
• Monitor and report. Monitor the system’s operation. If you have reason to think it presents a risk, tell the provider or distributor and the market surveillance authority and suspend use. Report serious incidents.
• Keep the logs. Keep the logs the system generates, to the extent they are under your control, for at least six months unless other law says otherwise.
• Tell workers. Before putting a high-risk system into use at work, inform workers’ representatives and the affected workers.
• Check registration. Public authority deployers must register their use and must not use a high-risk system that is not registered in the EU database.
• Use the provider’s information for your DPIA. Where a data protection impact assessment (DPIA) is needed, use the information the provider supplies.
• Tell affected people. Deployers of Annex III systems that make, or assist in making, decisions about people must inform those people that they are subject to the system.
• Cooperate. Cooperate with the competent authorities.

Financial institutions meet the monitoring and log duties through their existing internal governance and documentation rules. Article 86 separately gives people affected by certain decisions based on a high-risk system’s output the right to a clear and meaningful explanation from the deployer.

Article 27: the fundamental rights impact assessment

Article 27 requires some deployers to assess a high-risk system’s impact on fundamental rights before first use, in a fundamental rights impact assessment (FRIA). It applies to Annex III systems, other than those used in critical infrastructure, where the deployer is a body governed by public law or a private entity providing public services. It also applies to any deployer of a system used for creditworthiness or credit scoring, or for risk assessment and pricing in life and health insurance.

The assessment covers six things.

1. The deployer’s processes in which the system will be used, in line with its intended purpose.
2. The period and frequency of use.
3. The categories of people and groups likely to be affected.
4. The specific risks of harm to those people, taking into account the provider’s information.
5. The human oversight measures, in line with the instructions for use.
6. What the deployer will do if the risks materialise, including internal governance and complaint mechanisms.

The deployer notifies the market surveillance authority of the results, using a template the AI Office provides. The assessment covers first use and is updated when any of these elements changes. The Omnibus amended Article 27 so deployers can cross-reference or incorporate relevant parts of a data protection impact assessment, which avoids doing the same analysis twice.

How to prepare

The high-risk duties are more than a year away for most systems, but the groundwork takes time.

1. Inventory. List every AI system you use with an EU connection, including AI features inside products you already pay for.
2. Classify. Mark which are high-risk, which trigger Article 50, and which carry only Article 4.
3. Literacy now. Article 4 already applies. Put proportionate measures in place and record them.
4. Transparency now. Article 50 already applies. Check where you use emotion recognition, biometric categorisation or publish AI-generated content.
5. Oversight and monitoring. For each high-risk system, name the overseers, set up monitoring and an incident route, and confirm how logs will be kept.
6. FRIA. If Article 27 applies, start the assessment early and align it with your DPIA.
7. Contracts. Make sure provider contracts give you the instructions for use, the information you need for the FRIA and DPIA, and a channel for reporting risks.

Where Aicura fits

A deployer’s duties are mostly operational, and they map onto work Aicura already runs. Training holds the courses people are put on and who completed them, which shows the Article 4 measures you took. Impact assessments record the people affected, the rights involved and the mitigations, the raw material for an Article 27 assessment. Monitoring and alerts cover the Article 26 duty to watch a system in production, and Incidents carry an incident from assessment to final report.

For organisations in the EU, the EU AI Act is available as a framework from the Essentials tier, where assessments apply it alongside your other frameworks. In Pro, incidents include an Article 73 serious incident pathway. Aicura gives guidance and holds the record. It does not give legal advice or decide whether your organisation meets the Act.

---

A note on this page

This guide explains what the rules require and how to do the work. It is general information, not legal advice. How the obligations apply turns on your own circumstances, so read the primary source and take your own advice before you rely on it.

Aicura does not certify, audit or issue a compliance verdict, and it does not produce a score. That decision belongs to your organisation and its people.

Primary source: Regulation (EU) 2024/1689 (the AI Act), EUR-Lex