For a long time the EU AI Act sat under future compliance. Important, but distant, and something to revisit once guidance settled and enforcement became clearer. That window has closed. The Act is in force, early obligations are active, national authorities are building supervisory capability, and for organisations already running AI in real business processes this has quietly become an operational issue rather than a legal one.
This is not about AI in theory
One of the biggest misunderstandings is treating the AI Act as a regulation about innovation or emerging technology. It is not. The Act is about how AI behaves once it is embedded in day-to-day operations, which means systems that influence decisions, tools that support or automate services, and models that shape outcomes for customers, staff, or citizens.
In other words it is about production systems rather than labs or experiments. That is why it lands in the same space as ICT risk management, operational resilience, third-party dependency oversight, and incident and recovery planning.
The risk-based model, and why it matters in practice
The AI Act does not ask whether a system is clever or cutting edge. It asks whether it is risky. That is an important shift, because many organisations already run AI that falls into a regulated category even though it was never labelled that way internally.
The four tiers are unacceptable risk, meaning the practices banned outright under Article 5, high risk covering systems affecting safety, fundamental rights, or access to services, limited risk carrying transparency obligations under Article 50, and minimal risk, which attracts no mandatory obligations. From an operational perspective the takeaway is that high-risk AI systems are being treated like other critical systems, with the expectations that follow around documentation, ownership, controls, monitoring, and recovery when things go wrong.
Where the timeline actually stands
The obligations were phased deliberately, and Regulation (EU) 2026/1744, the Digital Omnibus, changed that phasing after it came into force on 27 July 2026. Several elements are already live. The Article 5 prohibitions and the Article 4 AI literacy duty have applied since February 2025. Obligations on general-purpose AI models have applied since August 2025. The Article 50 transparency obligations became applicable on 2 August 2026 and were not deferred.
What moved is the high-risk regime. Annex III standalone high-risk systems now apply from 2 December 2027, and AI embedded as a safety component in products already covered by EU harmonisation legislation from 2 August 2028. Two further dates sit in between. Generative systems placed on the market before 2 August 2026 have until 2 December 2026 to meet the machine-readable marking and detection obligation in Article 50(2), and the two new Article 5 prohibitions introduced by the Digital Omnibus also apply from that date.
Split obligations are harder to manage than a single deadline, and the deferral has been widely reported as though the Act itself were paused. It was not. The parts most organisations are actually caught by are the parts already in force, and the work required for what comes later, meaning identifying AI systems, mapping them to business services, assigning ownership, documenting controls, and planning for failure, cannot be done properly at the last minute.
Where the AI Act meets operational resilience
Looked at through a resilience lens, four pressure points come up again and again.
Knowing where AI is actually used. Many organisations struggle to say where AI is in use, what decisions it influences, and what happens if it produces the wrong output or stops working. If you cannot map AI to business services you cannot assess impact, and if you cannot assess impact you are already behind.
Ownership is rarely clear enough. AI often sits in an awkward organisational gap, owned by innovation teams, data teams, vendors, or nobody in particular. The Act does not tolerate that ambiguity. It pushes organisations to be clear about who owns the system, who is accountable for outcomes, and who decides when it should be paused, overridden, or shut down. That clarity matters as much in a crisis as it does on a compliance slide.
AI failures are incidents whether you call them that or not. When AI goes wrong it can disrupt services, produce unsafe or misleading outputs, trigger regulatory notification duties, and damage trust quickly. Yet most incident response plans still assume cyber or infrastructure events and give no thought to AI-specific failure modes.
Third-party dependence is a bigger risk than it looks. Most AI systems depend on external models, cloud platforms, and functionality embedded inside vendor products. That creates concentration risk and loss of control, which supervisors are increasingly uncomfortable with. From a resilience perspective this is familiar territory, and AI simply adds another layer to an already complex dependency picture.
The trap of treating this as someone else's job
In many organisations responsibility for the AI Act has been handed to legal or to an innovation function. That is understandable and incomplete. When something goes wrong the questions will not be abstract. They will be what happened, who knew, what did you do, and how fast did you recover. Those are operational questions and they land with operational leaders.
What good looks like now
You do not need perfect answers, but you do need movement. Inventory where AI is used, including tools adopted by individual teams without procurement oversight. Link those systems to critical services. Work through failure and degradation scenarios rather than assuming a binary between working and broken. Clarify ownership and escalation. Update incident and continuity plans so they cover AI. And start building evidence rather than only policies, because evidence is what a supervisor asks for.
None of this is exotic. It is the same discipline organisations already apply to other critical technology.
The one thing that matters
The AI Act is already shaping what supervisors, executives, and customers expect an organisation to be able to explain, control, and stand over when AI is in use. If AI influences decisions, services, or outcomes in your organisation today, it needs to be treated like any other critical system, with clear ownership, documented controls, and a practical plan for what happens when it degrades, misbehaves, or fails.
The organisations that struggle will not be the ones moving slowly on AI adoption. They will be the ones caught out when simple questions cannot be answered under pressure. Who owns this system. How does it fail. What do we do when it does.
AI resilience is now inseparable from operational resilience, and if it is not built in deliberately it tends to get tested the hard way instead.
Per claritatem progressus, through clarity, progress.
Primary Regulatory Sources
Morclear resources are independently produced. They do not constitute legal, regulatory, financial, or professional advice.