What supervisory authorities actually look for in DORA and EU AI Act compliance

There’s a question I keep hearing inside EU regulatory conversations: “Are we compliant yet?”

Supervisory authorities tend to ask a different one: “Can you demonstrate that you understood your operational risk and acted reasonably to govern it?”

That difference is the whole game. Most modern ICT and AI regulation is no longer a document-based compliance exercise — it’s a governance-maturity assessment. You see it most clearly in two places right now: EU AI Act deployment governance, and DORA ICT third-party risk. Plenty of organizations have started both. Far fewer have built something that would survive an actual supervisory review.

The AI Act: the wrong starting question.

Most AI Act discussion is about whether a given use case is “covered.” That’s usually the wrong place to start. The first operational question is simpler: if a supervisory authority asked tomorrow for evidence of reasonable due diligence on your AI deployments, what would you hand them?

Most SMEs and mid-sized firms don’t fail that test because they ignored the regulation. They fail because AI adoption happened diffusely — through SaaS platforms, embedded productivity features, CRM enhancements, support tooling, HR automation, analytics, and vendor AI that business teams switched on incrementally. The result is a much larger AI footprint than leadership thinks: in practice, somewhere between 5 and 20 AI-adjacent systems, even when only one or two are formally acknowledged. You can’t govern what you haven’t identified.

Defensibility starts with four controls, and none of them require a consultant:

1. A documented AI inventory — not just ChatGPT, Copilot, or Gemini, but the embedded scoring, recommendation engines, AI-assisted customer interactions, document summarization, recruiting filters, and the third-party SaaS quietly using generative models behind its interface. The inventory matters because regulators expect you to know where algorithmic influence actually operates.
2. A visible risk-classification rationale — not a 40-page legal memo per app. Evidence that someone reviewed each use case, considered whether prohibited or high-risk (Annex III) categories apply, weighed human oversight, and wrote down the reasoning. Regulators distinguish between absence of governance and imperfect-but-demonstrable governance. The second is survivable; the first is dangerous.
3. Article 50 transparency that actually exists operationally — this gets surprisingly little attention. Usually the problem isn’t technical sophistication; it’s that no disclosure exists, the AI interaction is ambiguous, or staff can’t tell when AI output is being surfaced externally. The language doesn’t need to be theatrical. It needs to be visible, understandable, and applied consistently. A short disclosure implemented properly beats a sophisticated policy nobody operationalized.
4. Named accountability — “IT,” “Legal,” or “Innovation” collectively is not an owner. Authorities expect a named person, a contact path, and escalation responsibility. Modern regulation increasingly tests whether governance ownership is operationally real, not organizationally abstract.

DORA exposes the same weakness in a different shape.

DORA has been in force since January 17, 2025. Most in-scope financial entities have now built some version of an Article 28 ICT third-party register — vendor names, service categories, criticality fields, contract references — and many believe the exercise is finished. But supervisory scrutiny is moving toward something more operational: concentration risk. And that’s where most registers turn out to be weaker than their owners assume.

A register is not automatically a risk picture. Often it’s just a procurement inventory. What authorities increasingly want to understand is operational dependency, systemic concentration, substitutability, exit feasibility, and resilience under disruption — in plain terms, what happens if one of your critical providers fails? That matters most exactly where organizations are concentrated: hyperscalers, core banking vendors, ERP providers, security platforms, outsourced infrastructure, managed-service ecosystems. Many firms document the vendors without understanding the operational blast radius behind them.

Article 28(5) is explicit that competent authorities assess ICT concentration risk at both entity and sector level, and the EBA, ESMA and EIOPA have been clear they will look. A register that’s ready for that answers three questions:

1. How concentrated is critical ICT dependency — not just by vendor count, but by spend concentration, operational dependency, critical-function mapping, and recovery feasibility? (The EBA treats more than 30% of ICT spend on a single provider as a flag.) Organizations routinely discover too late that a large share of critical operations depends on a surprisingly small provider cluster.
2. Is the exit strategy operational or theoretical? Most contracts contain termination clauses. Far fewer organizations have realistic migration sequencing, tested export procedures, dependency maps, replacement timelines, or viable fallback planning. A contractual right to exit is not the operational ability to exit — and supervisors increasingly know the difference. The test is whether it would actually work in a 90-day exit scenario.
3. Would portability actually work under stress? A data-portability clause that looks fine in procurement review is a different thing during a compressed transition, a provider dispute, degraded cooperation, or a cyber incident. A clause that only functions during ideal commercial goodwill is not a resilience control.

The shift underneath both.

Across the AI Act and DORA, the regulatory direction is the same. Authorities are moving away from “does a policy document exist / was the checkbox ticked / was the statement signed,” and toward whether the organization actually has operational awareness, governance traceability, accountable ownership, dependency visibility, and defensible decision-making. That’s a different maturity model than most compliance programs were built for.

And the organizations that do best under supervisory engagement usually aren’t the ones with the biggest compliance budgets. They’re the ones that can show they identified their exposure, assigned ownership, documented their reasoning, understood their dependencies, and treated governance as an operational discipline rather than a documentation exercise. In the end, supervisory resilience comes down to something simpler than “perfect compliance”: being able to say, credibly, we understood the risks, we assessed them seriously, and we built governance around them before the regulator asked.