. THREE PRACTITIONER INSIGHTS .

01

We over-classified 60% of our AI systems. Then we spent two weeks fixing it.

When the EU AI Act requirements first crystallized, my team's instinct was caution: classify everything as high-risk, apply maximum governance, protect the bank. The result was absurd. An internal chatbot that helps employees find HR policies was classified alongside our credit scoring model. Same documentation requirements. Same review cadence. Same board reporting. I called a two-week "declassification sprint." We read Annex III carefully (most of my team hadn't), and reclassified 60% of our systems from high to medium or low risk. The high-risk systems got more attention because we weren't drowning in paperwork for the low-risk ones. Here's why I'm raising this again now: the Digital Omnibus just bought everyone sixteen extra months, and over-classification is exactly the kind of quiet rot that creeps back in when the pressure comes off. With the deadline at December 2027 instead of this month, nobody feels the cost of misclassifying a system today. They'll feel it in 2027, when their "high-risk" pile is three times bigger than it needs to be and the assessor queue is full. Over-classification isn't conservative. It's negligent and a relaxed deadline makes it more tempting, not less.

02

Conformity assessments are an engineering discipline, not a compliance form. The extra time is for building it properly, not deferring it.

I had a frustrating conversation with a consultant who pitched EU AI Act conformity assessments as "a structured questionnaire your compliance team fills out." That's exactly the approach that fails on first supervisory inspection. Conformity assessments require technical documentation of data lineage, model performance under distribution shift, bias testing across protected characteristics, and monitoring procedures with defined thresholds and escalation paths. This is a living engineering artifact your data science team maintains across the model lifecycle, not a Word document on a SharePoint nobody updates. The deferral to December 2027 changes exactly one thing about this: it gives you time to build it as the engineering artifact it should be, instead of the crash-documentation project most banks were about to run this summer. That is the entire value of the extra sixteen months. If your conformity assessment still lives in a document, you haven't used the time. You've just postponed the panic.

03

The classification debate that took my team four hours and taught me the actual test.

Last month two of my data scientists genuinely disagreed about whether our loan-document extraction tool is a high-risk AI system. One argued yes: it sits inside the credit process, it touches loan agreements, credit decisions flow from its output, Annex III, full governance. The other argued no: it extracts and presents data, a human reads every field, and the creditworthiness assessment happens entirely downstream in a separate, non-AI process. Four hours of back-and-forth, two camps, no resolution. So we did what we should have done first: we went back to the actual text and the recitals instead of arguing from intuition. The high-risk trigger for credit isn't "does this AI touch the lending process." It's whether the AI is used to evaluate the creditworthiness of, or establish the credit score of, a natural person. Our tool does neither, it reads a PDF and fills fields; it never scores anyone. Not high-risk. The thing I'll admit honestly: I'm about 85% confident in that classification, not 100%, because the line between "decision support" and "decision" is genuinely fuzzy once analysts start trusting the extracted fields without re-checking the source. So we documented the reasoning, set a review trigger if usage patterns change, and moved on. The lesson I keep relearning: the high-risk question is about the subject of the decision, a natural person's access to something — not the importance of the process the AI sits inside. When your team is split, stop debating and read the recital. The answer is usually there, and the debate is usually about a word nobody looked up.

- Two Use Cases -

→ WIN Compliance by design: we built to the draft, and the deferral proved it right

One approach I'm genuinely proud of. Eighteen months ago, well before any harmonised standards existed, we mapped the projected EU AI Act requirements directly into our development lifecycle. Every stage (ideation, development, testing, deployment, monitoring) got specific compliance checkpoints. Risk classification happens at ideation, not retroactively. Technical documentation auto-generates from development artifacts in our platform. Here's the part the deferral makes interesting: the harmonised standards still aren't fully finalised — and that incompleteness is one of the reasons the deadline moved to December 2027 in the first place. We didn't wait for the standards. We built to the draft requirements and the published guidance, and we'll reconcile to the final standards when they land. My team's response to the deferral was a shrug, the same shrug they'd have given the original deadline: we were already doing the work. Compare that to the crash projects I'm hearing about from peers who are now telling themselves they have until 2027 to start. They have until 2027 to finish. Those are not the same date. Compliance by design isn't just ethically right. It's the only approach where a moved deadline is good news instead of a reason to stall.

→ LESSON The AI inventory that was 40% wrong within four months

A peer institution built an elaborate AI registry, a beautifully structured Confluence page listing every model, its owner, risk level, deployment date, and last review. Four months later, a routine audit revealed 40% of entries were outdated. Three models had been decommissioned but were still listed. Two new models were in production but unregistered. One model's risk classification had been changed informally over email but never updated. The registry was worse than nothing, it created a false sense of control. The lesson: if your AI inventory isn't automatically populated from your deployment pipeline, it's already wrong. We integrated ours into our CI/CD process, every deployment automatically creates or updates its registry entry. Manual registries are fictions that age into liabilities. And the inventory is the one artifact that a moved deadline does not give you permission to neglect: it is the first thing a supervisor asks to see, and "we're rebuilding it" is not an answer in 2027 any more than it is today.

◉ THE REGULATORY SIGNAL

[Written July 12th.] The headline everyone read in July was "high-risk deadline moves to December 2027." The headline almost nobody read: most of the AI Act did not move at all. Now that the Digital Omnibus is published and in force, here is the operational trap. The deferral covers the high-risk obligations under Annex III — the conformity assessments, the technical files, the registration. It does not touch the obligations that have been enforceable since February 2025: the prohibited-practices ban (Article 5) and the AI literacy requirement (Article 4). It does not touch the transparency obligations under Article 50 — disclosing to a person that they are interacting with an AI system, and labelling AI-generated content — which apply on their own timeline regardless of risk tier. And the same Omnibus package added new Article 5 prohibitions. So the bank that reads "deadline moved" and quietly demobilises its whole AI compliance programme is now non-compliant on the obligations that were already live, while congratulating itself on the one that was deferred. What to do this week: split your obligation list into two columns — "deferred to December 2027" and "live right now." The live column (prohibited practices, AI literacy, Article 50 transparency) is short, it is enforceable today, and it is the column a supervisor can act on immediately. Make sure the deferral headline did not cause anyone on your team to stop maintaining it.