If your AI system is high-risk, used in areas like hiring, credit, education, health, or law enforcement, it carries the heaviest set of obligations in the Act. But those obligations split in two: the company that builds the system carries most of them, and the company that merely uses it carries a lighter, but still real, set. Most businesses are users, not builders, so knowing which side you are on is the single most useful thing here. And thanks to a recent delay, most of these duties do not bite until December 2027, giving you time to prepare properly.
In Episode 3 we sorted AI into four risk tiers, and in Episode 4 we covered the top tier, the banned practices. This week we look at the tier just below: high-risk. These systems are allowed, but they come with the most demanding requirements in the whole Act. If you determined in Episode 3 that one of your systems is high-risk, this is your guide to what that actually involves, and, importantly, how much of it is really your job.
The most important distinction: builder or user
Before listing any obligations, you need to know which role you play, because the Act treats two roles very differently. A provider is the company that builds the high-risk system, or has it built and puts it on the market under its name. A deployer is the company that uses that system in its own operations. The provider carries the heavy, design-level obligations. The deployer carries a lighter set focused on using the system responsibly.
This matters enormously in practice, because most businesses are deployers, not providers. If you buy or subscribe to a high-risk AI tool that someone else built, say, a hiring-screening system from a vendor, you are the deployer, and you do not have to build risk-management systems or affix CE marking. That is the vendor's job. Your job is to use it correctly. Getting this distinction right saves you from either doing work that is not yours, or missing the work that is.
If you build it: the provider obligations
If your business actually builds a high-risk AI system, the requirements are substantial, and they run across the system's whole life. In plain terms, they are: a documented risk management process that runs continuously, not a one-time checkbox; proper data governance, meaning your training data is quality-checked and evaluated for bias; detailed technical documentation a regulator could audit; automatic logging of what the system does, kept for at least six months; human oversight built into the design, so a person can understand, monitor, and override the system; and safeguards for accuracy, robustness, and cybersecurity.
On top of that, before putting the system on the market, a provider must pass a conformity assessment, draw up an EU declaration of conformity, affix the CE marking, and register the system in an official EU database. This is a serious engineering and documentation effort, which is exactly why it sits with the company that built the system and understands it best.
If you use it: the deployer obligations
This is the section most of you actually need. If you deploy a high-risk system built by someone else, your obligations are real but far lighter. You must follow the provider's instructions for use, not repurpose the system in ways it was not designed for. You must assign human oversight to a real person who has the competence, training, and authority to monitor it and step in. You must keep the logs the system generates. You must monitor how it behaves in practice and report serious incidents. And deployers in many cases must carry out a fundamental rights impact assessment, a check on how the system could affect the people subject to its decisions.
The theme across all of these is straightforward: use the tool as intended, keep a human genuinely in charge, watch it, and speak up if something goes wrong. None of it requires you to understand the system's internal engineering, only to operate it responsibly.
Here is the practical timing. As we noted in Episode 3, the Digital Omnibus pushed most high-risk obligations back: they now apply from December 2027 for the systems listed in Annex III, and August 2028 for a narrower category, rather than 2026. So if you are high-risk, you have real lead time. But do not treat that as a reason to do nothing. The preparation, documentation, human oversight, data governance, is good practice that makes your AI safer and better regardless of the law. The smart move is to build toward it now, calmly, rather than scramble in 2027.
What is at stake
High-risk non-compliance sits in the serious band of penalties, up to 15 million euros or 3 percent of worldwide annual turnover for breaching the core obligations, with proportionally lower figures for smaller companies. But beyond fines, the real risk is operational: a high-risk system deployed without the required oversight and documentation is a system you cannot defend if it makes a harmful decision about someone's job, loan, or education. The obligations exist because these systems affect people's lives, and being able to show you used one responsibly is protection for your business as much as compliance.
Your action this week
Take the high-risk systems you flagged back in Episode 3 and, for each one, answer a single question first: are we the builder or the user? If you built it, you are a provider, and you should begin the heavier readiness work, or get professional help scoping it, well before the 2027 deadline. If you use a tool someone else built, you are a deployer: confirm the vendor has done their part, assign a named, competent person to oversee it, make sure you are keeping logs, and note that a fundamental rights impact assessment may be required. Write down which role you hold for each system, that single classification tells you almost everything about what you owe. Next week, we continue through the high-risk tier with a closer look at data and documentation.
Frequently asked questions
What are the obligations for a high-risk AI system?
They split by role. The provider (who builds it) must have a documented risk management system, quality data governance, detailed technical documentation, automatic logging kept six months, human oversight by design, and accuracy and cybersecurity safeguards, plus conformity assessment, CE marking, and EU database registration. The deployer (who uses it) has a lighter set: follow instructions, assign human oversight, keep logs, monitor, report incidents, and often carry out a fundamental rights impact assessment.
I only use an AI tool someone else built. What do I have to do?
You are a deployer, so your obligations are lighter than the builder's. You must use the system as instructed, assign a competent person to oversee it with authority to intervene, keep the logs it generates, monitor its behaviour, and report serious incidents. In many cases you also need a fundamental rights impact assessment. You do not have to build risk-management systems or affix CE marking, that is the provider's job.
When do high-risk obligations actually take effect?
Later than originally planned. Under the Digital Omnibus, most high-risk obligations now apply from December 2027 for Annex III systems and August 2028 for a narrower category. That gives you lead time, but the preparation is worth starting now, since documentation, human oversight, and data governance improve your AI regardless of the deadline.
What does human oversight actually mean?
It means a real person, with the competence, training, and authority, can understand what the high-risk system is doing, monitor it, and intervene, override, or shut it down when needed. For providers it must be built into the system's design; for deployers it means assigning a capable person to that role. The goal is that a human, not the AI alone, stays genuinely in charge of consequential decisions.
What are the penalties for high-risk non-compliance?
Breaching the core high-risk obligations can bring fines of up to 15 million euros or 3 percent of total worldwide annual turnover, whichever is higher, with proportionally lower figures for smaller companies. Beyond the fine, an undocumented, unsupervised high-risk system is one you cannot defend if it harms someone, so the obligations also protect your business.
Follow the series, get compliant one rule at a time
This is Part 5 of our weekly guide to AI regulation, breaking down one rule at a time so compliance feels manageable instead of overwhelming. Explore more clear, honest guides on AISetApp and follow along each week.
Explore more on AISetApp- EU AI Act (Regulation (EU) 2024/1689), Articles 8 to 15 (provider obligations) and Article 26 (deployer obligations)
- Digital Omnibus on AI (Regulation (EU) 2026/1744) on the revised high-risk deadlines
- 2026 high-risk compliance guides from Openlayer, GDPR Local, Legal Nodes, and McKenna Consultants on provider versus deployer duties, human oversight, and documentation
- EU AI Act high-level summary on provider and deployer obligations and conformity assessment
Reviewed September 2026. This is an explainer, not legal advice. The law is evolving; verify specifics with a qualified professional before acting.
Researched and drafted with AI assistance, reviewed and edited by Yasser El Hardouz, who takes editorial responsibility for this article.