The AI Act doesn’t ask you to give up artificial intelligence. It asks you to know what the system does, on what data, and who answers for it.
As of 2 August 2026, a significant part of Regulation (EU) 2024/1689 applies: the transparency obligations and the full operation of the supervision and penalty system. In July 2026 the simplification package known as the Digital Omnibus amended Article 113 of the Regulation, pushing back the application of the obligations for high-risk systems.
The result is a two-speed framework worth reading carefully, because the delay concerns the deadlines, not the work needed to be ready for them.
The risk-tier logic, in plain terms
The Regulation doesn’t classify technologies. It classifies uses.
The same language model can fall into different categories depending on what it’s asked to do. This is the point most often misunderstood in early internal assessments.
There are four tiers.
Unacceptable risk. Practices banned since 2 February 2025: social scoring by public authorities, manipulation that exploits vulnerabilities, certain forms of biometric identification. It’s a closed list and covers few cases.
High risk. Systems that affect rights, access to essential services, or safety. Annex III includes credit scoring, insurance risk assessment, recruitment and personnel management processes, and access to essential public services. These are the categories that most directly touch banks, insurers and public bodies.
Limited risk. Systems that interact with people or generate content. Here the obligation is transparency: the user must know they’re interacting with an automated system, and generated or manipulated content must be identifiable as such.
Minimal risk. Everything else, with no specific obligations.
The new deadlines, after the Digital Omnibus
As of today, 2 August 2026, the transparency obligations of Article 50 apply, and national authorities have full supervisory powers, with the penalty regime operational.
The obligations for high-risk systems under Annex III will apply from 2 December 2027, in place of the original date of August 2026.
For high-risk systems linked to products already regulated, falling under Annex I, the deadline is 2 August 2028.
For part of the high-risk systems already in use by public authorities, the longer 2030 deadline remains unchanged.
A clarification useful for leadership teams: the delay is not a suspension of the Regulation. It concerns part of the obligations. Transparency, supervision and penalties are operational now, and the banned practices have been so for over a year.
Since this is a recently amended framework, we recommend verifying how your specific situation is classified against the consolidated text and with your legal department before making decisions.
The obligations that actually affect a deployer
Many organizations consider themselves outside the scope of the Regulation because they don’t develop models. That’s an inaccurate reading.
The Regulation distinguishes between those who provide a system and those who deploy it, and sets out obligations of its own for the latter as well. Whoever introduces an AI system into their own processes takes on direct responsibilities. Four areas come up most often.
Transparency toward people. Anyone interacting with an automated assistant must know it. Artificially generated content must be identifiable. This is an obligation already in force, and it has immediate impact on interfaces aimed at citizens, customers and employees.
Human oversight. For high-risk systems, effective human intervention must be possible: understanding on what basis the system produced a given output, being able to correct it, being able to stop it from operating. Effective means the person must have the information, the competence and the authority to intervene. An approval button pressed across dozens of identical cases doesn’t constitute oversight.
Documentation and traceability. A register of purposes, a description of how the system works, operation logs, incident-management procedures. Nothing exotic for organizations already working in a certified context, but it has to be set up during design: reconstructing it afterward is costly and often incomplete.
Data governance. What data feeds the system, on what legal basis, for how long it’s retained, how unintended uses are prevented. This is the natural connecting point with existing GDPR obligations.
For public bodies and for specific cases in the financial sector, a fundamental rights impact assessment is also required before high-risk systems are put into operation.
Why compliance is designed at the start
The reason is practical before it’s legal.
Source traceability, action logging, the points where the system stops and asks for confirmation, data segregation by role: these are architectural choices. Introducing them into a system that’s already built usually means rebuilding it.
The reverse is also true, and it’s why the delay to 2027 doesn’t justify delaying the work. A system designed with an audit trail, human oversight and technical documentation from the start is a better system regardless of the regulation: errors are diagnosable, responsibilities are clear, maintenance is possible.
Sixteen months seem like a lot. For an organization that has to inventory the systems in use, classify their risk, update the documentation and train those responsible, they aren’t.
What the AI Act doesn’t solve
The Regulation doesn’t establish that a compliant system is an accurate one. These are two separate checks: compliance concerns processes, documentation and controls; accuracy is measured on real cases.
It doesn’t remove the organization’s responsibility. It defines it and makes it traceable, which is different.
And it doesn’t replace sector-specific regulations. For a bank or a public body, it adds to an existing framework, one it needs to be coordinated with rather than managed separately.
In closing
The useful question at this stage isn’t whether the Regulation is burdensome. It’s which systems are already in use in your organization, which risk tier they belong to, and who answers for them today.
In most cases, the inventory produces two surprises: some tools adopted by individual offices weren’t known to leadership, and some systems considered critical actually fall under limited risk.
Risk classification is the first step of every assessment we run, before any technical choices. If you’re working through this, we’re available for a conversation on governance and compliance applied to your specific context.
Regulatory sources: Regulation (EU) 2024/1689 (AI Act); amendments to Article 113 introduced by the Digital Omnibus package adopted in July 2026. The deadlines listed are current as of the article’s publication date.
