Two regulations, one AI system, and nobody sure who owns the gap
The EU AI Act's high-risk obligations became enforceable on August 2, 2026. If you run a fintech with any AI touching credit decisions, fraud scoring, or KYC risk rating, that deadline is not theoretical anymore. It already passed. What surprises most compliance teams a month in is not the AI Act itself. It is discovering that DORA, the operational resilience regulation that has applied since January 2025, was quietly asking a different set of questions about the same systems the whole time.
Most regulated fintechs I talk to treated these as separate workstreams. Legal owned the AI Act mapping. Engineering and infosec owned DORA's ICT risk framework. Nobody sat both teams in the same room to ask a basic question: does our fraud detection model count as high-risk under the AI Act, and separately, is it a critical function under DORA? The answer, for a lot of operationally important AI, turns out to be no and yes at the same time. That mismatch is where the real exposure sits.
A corporate credit scoring model, a robo-advisory tool for professional clients, or an automated underwriting engine for commercial insurance can all be critical to how your business runs, and none of them are classified as high-risk under the AI Act's narrow test.
DORA does not care about that classification. It treats every AI system as ICT, full stop. If the system supports a function whose failure would materially damage your operations, DORA's resilience obligations apply regardless of what the AI Act says. So you end up with AI systems that carry no AI Act documentation burden but still need incident logging, drift monitoring, business impact analysis, and annual resilience testing under DORA. Treating "we're not high-risk under the AI Act" as a reason to skip AI governance work is a mistake I've seen cost teams months of rework once a supervisor asks for evidence.
Why logging is the part everyone underestimates
Article 12 of DORA requires tamper proof, encrypted logging with a minimum five year retention period, and clock synchronization across every system involved. For AI specifically, that means every inference, every input and output pair, every model version, and every confidence score needs an audit trail. Teams that assumed their existing application logs covered this were wrong almost every time. Application logs tell you a request happened. They rarely tell you which model version produced which output, at what confidence, against what threshold, with what human oversight step attached.
This matters more than it sounds like it should, because incident classification depends on it. DORA requires initial notification of a major incident within four hours of classifying it as such. You cannot classify something in four hours if your monitoring cannot detect it for three days. A model that quietly drifts over six months, degrading fraud detection accuracy without anyone noticing, is not a hypothetical. It is the most common failure mode reported by compliance teams working through their first full audit cycle under this framework.
Vendor concentration is the second blind spot
If your KYC, AML screening, fraud detection, and credit scoring all route through the same foundation model API, you have concentration risk under DORA Article 29, whether or not anyone framed it that way when the contracts were signed. The regulation asks whether you are relying on a provider that is not easily substitutable. Most LLM integrations, with their fine-tuning and deep workflow embedding, fit that description precisely.
Article 30 then sets out what your vendor contracts actually need to contain: quantitative service level agreements with real numbers, not vague uptime language, unrestricted audit rights covering model behavior and training data governance, an exit strategy with a defined transition period, and incident notification terms specific to AI failures. Contracts written before 2024, and there are a lot of them still in force, routinely miss all of this. They were written for software licensing, not for a dependency that makes decisions about your customers.
What actually needs to happen this quarter
Start with an inventory, and be honest about it. Every model, every LLM integration, every ML pipeline is a separate ICT asset under DORA with its own risk profile. Regulators have been explicit that this inventory needs to reflect the real AI footprint, including the AI features that arrived quietly inside SaaS tools you already pay for, not just the systems you deliberately built.
Once the inventory exists, run each system through two tests, not one. First, does it meet the AI Act's high-risk criteria. Second, independent of that answer, does it support a critical or important function under DORA. Systems that fail the first test but pass the second are your governance gap, and they need AI-specific controls even though no regulation technically forces the AI Act's rulebook onto them.
The practical move that several legal teams have landed on is treating the AI Act's high-risk requirements, things like documented risk management, bias testing, and human oversight, as an internal benchmark applied to DORA critical systems, proportionate to how important each one actually is. It is not a legal requirement in the strict sense. But a management body that cannot show it applied a structured, standards based approach to an operationally critical AI system will struggle to argue it met its DORA obligations when a supervisor pushes back.
Finally, revisit your vendor contracts before your next renewal cycle, not after an incident forces the issue. If a contract does not name a data processing location, does not disclose subcontracting down to the underlying foundation model provider, and treats audit rights as optional, it will not survive scrutiny from either regulation.
None of this is glamorous work. It is inventories, contract redlines, and log schemas. But the fintechs that treat it as engineering discipline rather than a legal filing exercise are the ones that will walk into their first supervisory review with answers instead of explanations.