The head of compliance at a mid-sized European bank presents the finished to the executive committee. Every AI system the bank uses is listed, with an owner, a purpose, a risk category and the where one applies. The chair thanks her and asks the obvious follow-up: so are we compliant with the EU AI Act now? Her honest answer is that the register shows what the bank has. The EU AI Act obligations are about how the bank runs those systems, every day, for as long as they are in use.
That distinction matters for almost every organisation, because most of them are deployers rather than providers. They do not build the credit model, the recruitment screener or the grid forecasting tool themselves. They buy it, configure it and put it to work. The AI Act gives deployers their own set of duties, and those duties only become real when each register entry is turned into routines, owners and evidence.
Finding the AI you use is the first step, and we described it in Why EU AI Act compliance starts with finding your AI. This article picks up where that one ends: the register exists, and the question is what you now have to do with it.
The dates moved, the work did not
The timeline changed this summer. The Digital Omnibus on AI, Regulation (EU) 2026/1744, entered into force on 27 July 2026 and moved the high-risk obligations for Annex III systems from 2 August 2026 to 2 December 2027 [2]. High-risk AI that is part of regulated products under Annex I follows on 2 August 2028.
It is tempting to read that as a reason to wait. Two parts of the Act already apply, though. The prohibited practices in Article 5 and the duty in Article 4 have applied since 2 February 2025. The Omnibus reframed the literacy duty rather than removing it: deployers still have to take measures to support AI literacy among their staff, and the amended text adds that "This obligation does not require providers or deployers to guarantee any specific level of AI literacy of any individual." [2] You still need to show what you did.
The extra time is best spent on the part that takes longest: building the routines behind each high-risk entry, testing them on one or two systems and fixing what does not work. Fourteen months is not long when procurement, vendors, works councils and model owners all have to be involved.
Six deployer duties, one register entry at a time
Article 26 sets out what deployers of high-risk AI systems must do [1]. Read as a list, it can feel abstract. Read against a single register entry, each duty becomes a concrete question with an owner.
- Use the system according to the instructions for use. Do you have the provider's instructions, and does your actual use match the intended purpose recorded in the register? (Article 26(1))
- Assign to people "who have the necessary competence, training and authority". Who are they, and can they stop or override the system? (Article 26(2))
- Monitor operation and act on risk. Who watches the system in production, and who decides to inform the provider and suspend use when something goes wrong? (Article 26(5))
- Keep the automatically generated logs that are under your control for at least six months. Where are they, and who can retrieve them? (Article 26(6))
- As an employer, inform workers' representatives and affected workers before a high-risk system is used on them. (Article 26(7))
- For Annex III systems that make or help make decisions about people, inform those people that the system is used. (Article 26(11))
None of these duties is technically complex, but they belong to different people. Oversight sits with a business role, logs with IT, worker information with HR, and the decision to suspend with someone who has enough authority to stop a process that the business depends on. A register entry that names a single owner for all six is usually a sign that the work has not been divided yet.
Where the Library says you will need to compensate
The MetroMinds Library scores every use case on , including how well safety and policy rules can be enforced inside the system and how observable it is at runtime. For the 333 use cases that touch an Annex III area in a first screen of titles, we compared the share that scores 2 or lower out of 5 with the rest of the Library.
Safety and policy enforcement stands out. In 71 of the 333 Annex III use cases (21 percent), the system itself offers limited means to enforce the rules it should follow, against 17 percent elsewhere. is weak in 42 of them. In those cases the safeguards have to come from outside the system: the people assigned to oversight, the review steps around them and the monitoring routine. The weaker the controls inside the tool, the more the deployer duties in Article 26(2) and 26(5) carry the load. We looked at what a good monitoring routine involves in Who checks your AI after it goes live?
When you also need a fundamental rights impact assessment
Some deployers have an extra step before they may use a high-risk system. Article 27 requires a from "deployers that are bodies governed by public law, or are private entities providing public services", and from deployers of the systems in Annex III points 5(b) and 5(c): creditworthiness and credit scoring, and risk assessment and pricing in life and health insurance [1].
In the Library, 77 of the 333 Annex III use cases fall in the three areas most closely tied to this duty: public benefits and services (54), creditworthiness (19) and life and health insurance pricing (4). For banks, insurers and public bodies, the assessment is therefore a regular part of putting AI into service.
Informing people is a design task
Two of the duties concern information, and both are easy to underestimate. Informing workers is a conversation with the works council, which goes better when you can show which roles are affected and how their work changes. Informing applicants, customers or citizens means changing letters, portals and scripts owned by teams far from the AI project. Plan both as part of the rollout, with their own owners and deadlines.
Questions for your next compliance committee
- For each high-risk entry in the register, which of the six Article 26 duties has a named owner, and which are still empty?
- Which high-risk systems score low on safety and policy enforcement or runtime observability, and is the human oversight around them sized for that?
- Which entries require a fundamental rights impact assessment, and when will each one be finished?
- Do our vendor contracts give us access to the logs and instructions we need?
- What evidence of AI literacy measures could we show a supervisor today?
How MetroMinds helps you run the register
The MetroMinds portfolio analysis identifies where AI is used across all your applications, including AI features inside vendor software, and feeds every system into the AI register. The register records what the EU AI Act asks you to know per system: purpose, role as provider or deployer, risk category, Annex III area, human oversight, logs, owner and status.
Because each register entry is linked to the portfolio, you see its readiness profile, its capability and the job families whose work changes. That makes it straightforward to assign the Article 26 duties, plan the impact assessment and prepare the conversation with the works council, long before 2 December 2027.
How ready is your organisation to run high-risk AI responsibly? Take the AI Readiness Snapshot
Sources
- European Union, Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 26 "Obligations of deployers of high-risk AI systems" and Article 27 "Fundamental rights impact assessment for high-risk AI systems", Official Journal, 12 July 2024.
- European Union, Regulation (EU) 2026/1744 (Digital Omnibus on AI), amending Regulation (EU) 2024/1689, 8 July 2026, in force since 27 July 2026.
- MetroMinds Library, 4,980 AI use cases with benchmark ranges based on real-world implementations, August 2026.
