. THREE PRACTITIONER INSIGHTS .

01

DORA turned our LLM provider into a systemic risk. We didn't see it coming.

When we first integrated an external LLM API into a business-critical workflow, nobody flagged DORA implications. It was an "AI project," not an "ICT risk" issue. Then our DORA compliance team started their critical-vendor assessment and realized: if this API goes down, a process that 200 employees depend on daily stops working. That makes the provider part of our ICT risk management framework. Suddenly we needed documented exit strategies, concentration-risk assessments, incident response procedures for AI-specific failure modes (hallucinations aren't the same as outages), and service-level monitoring that covers quality, not just uptime. "The API is available" and "the API is returning useful outputs" are completely different statements. We had monitoring for the first. We needed monitoring for the second. If your DORA team isn't talking to your AI team, you have a gap you can't see.

02

A client will eventually ask: "Why did the AI decline my loan?" You need an answer that isn't "it's complicated.

GDPR's right to meaningful information about automated decisions is about to collide with GenAI in a very concrete way. When a model in the decision chain processes an application and the answer is "no," the client has a right to meaningful information about the logic involved. For a logistic regression this was hard but tractable. you could point to coefficients. For a GenAI model in a decision-support chain, it's a genuinely unsolved problem at most banks. "The model considered multiple factors" is not a meaningful explanation. "Based on your debt-to-income ratio of X, against the threshold of Y, and your employment duration of Z" that is. And here's the part worth saying out loud this month: the AI Act deferral does nothing for you here. Article 22 of the GDPR is a separate instrument on a separate timeline — it has been in force for years and the Omnibus did not touch it. Anyone telling themselves "we have until December 2027 to sort out explanations" has confused two different regulations. Build the explanation framework before you deploy, not after a client or regulator forces the issue. This question is coming, and the AI Act calendar has no bearing on when.

03

The DORA-versus-GDPR fight that ran through our own log retention policy.

This is the messiest regulatory collision I've personally had to referee, and it ran straight through a boring question: how long do we keep our LLM prompt and response logs? DORA pulls one direction. Keep enough detail, for long enough, to reconstruct an ICT incident, prove resilience, and answer a supervisor who asks "what exactly happened on the day the system misbehaved." GDPR pulls the opposite direction. Data minimisation and storage limitation, because those logs contain client prompts and therefore personal data, and you are not allowed to keep personal data longer than you can justify. Two regulations, one log file, directly opposed retention instincts. We had genuinely circular meetings on this. The ICT risk people and the data protection people each citing chapter and verse, both correct, neither budging. What broke the deadlock was refusing to treat the log as one thing. We split it: an operational event log (what the system did, when, with what latency, which model version, what error state, retained long, for DORA) and a payload log (the actual prompt and response text containing personal data, pseudonymised, minimised, and on a much shorter retention clock, for GDPR). Same incident, reconstructable from the operational layer. Personal data minimised in the payload layer. It took us about six weeks and three redrafts of the retention policy to get both teams to sign. I'm still not certain we've drawn the line in exactly the right place. The first real incident will tell us whether the operational log alone is enough to reconstruct what happened. The lesson: when two regulations conflict on the same artifact, stop arguing about retention and start arguing about separation. Most regulatory collisions dissolve the moment you stop treating one object as one object.

- Two Use Cases -

→ WIN GDPR-compliant GenAI through architectural elegance

A private banking division wanted to use GenAI for client communication drafting but couldn't send client data to external APIs. Their solution was architecturally simple but operationally disciplined. Stage 1: a local service strips all PII and replaces it with deterministic tokens. Stage 2: anonymized text goes to the LLM API. Stage 3: a local service re-inserts PII. Client data never leaves the bank's perimeter. The approach adds about 2 seconds of latency. Nobody cares about the 2 seconds. The regulators loved the architectural clarity — there's no ambiguity about where data goes. I've since recommended this pattern to three other teams. It's not technically novel. It's simply well-designed. Sometimes the best AI architecture is the one that makes compliance trivially obvious.

→ LESSON The exit strategy that existed on paper and nowhere else

A bank ran its entire AI stack on a single cloud provider's managed ML service. When DORA required a documented exit strategy for critical ICT dependencies, they wrote one: 12 pages, detailed migration plan, cost estimates, timelines. Looked thorough. Then someone asked: "Has anyone tested this?" Silence. When they actually attempted a partial dry run, they discovered the migration would take an estimated 9 months, cost €1.2M, and require rebuilding three custom integrations from scratch. The exit strategy wasn't a plan. It was a wish. DORA requires credibility, not documentation. If your exit strategy has never been through even a tabletop exercise, assume it's fiction and plan accordingly.

◉ THE REGULATORY SIGNAL

[Written July 15th.] Here is a distinction most finance leaders missed in the July coverage. The Digital Omnibus that everyone associates with the AI Act deferral is actually a package — and the European Commission's broader Digital Omnibus, published in November 2025, also proposed amendments to the GDPR and the ePrivacy Directive. The AI Act piece reached agreement and is now law. The GDPR and ePrivacy simplification pieces have not. They are stuck, with no political agreement and no near-term timeline. So the practical signal for anyone running AI on client data: the AI Act got its relief, but GDPR did not, and there is no "GDPR is about to get easier" wave coming to rescue your data-protection workload. Article 22 on automated decisions, the right to meaningful information, the data-minimisation obligations that shaped the log-retention fight I described above — all unchanged, all live, all yours. What to do this month: if anyone in your organisation has been deferring a GDPR control on the theory that "the Omnibus will simplify this," kill that assumption now. The simplification that landed was the AI Act's. The GDPR's did not, and betting your compliance posture on a text that has not reached agreement is the same mistake as betting against the AI Act deferral six months ago — just pointed the other way.