In June 2026, the Council of the European Union gave final approval to the Digital Omnibus simplification package, which pushed the compliance deadline for stand-alone high-risk AI systems under Annex III of the EU AI Act from 2 August 2026 to 2 December 2027. High-risk systems embedded in regulated products received a parallel twelve-month extension, to 2 August 2028.
The reaction in a good many compliance functions was to close the file for eighteen months. That is a mistake, for three separate reasons — and the most important of them has nothing to do with deadlines.
This article sets out what actually moved, what did not, how the AI Act interacts with AI used in KYC and AML, and what Swiss institutions should take from a regulation that does not formally bind them.
1. What moved, and what did not
Moved. The obligations for stand-alone high-risk systems listed in Annex III — the provider requirements in Articles 9 to 17 and the deployer requirements in Article 26 — now apply from 2 December 2027. For high-risk AI embedded in regulated products such as medical devices and machinery, the date moves to 2 August 2028.
Did not move. The Article 50 transparency obligations, which require disclosure when a person is interacting with an AI system, remain on their original 2 August 2026 schedule. Only the narrower watermarking requirement for already-deployed systems received a grace period, to 2 December 2026.
That distinction is the first practical point. An institution that deployed a client-facing assistant — an onboarding chatbot, an automated document-request agent, a support interface — is in scope of transparency obligations now, regardless of the high-risk delay. The delay that was widely reported is not the one most financial institutions needed.
2. Is AI used in KYC/AML high-risk?
This is where careful reading matters, because the answer is not a blanket yes and not a blanket no.
The high-risk categories in Annex III that are most frequently invoked in financial services concern creditworthiness evaluation and credit scoring of natural persons, and risk assessment and pricing in life and health insurance. Systems used for the detection of financial crime are treated differently from credit scoring, and the Act's recitals address AML-related fraud detection explicitly.
In practice, an honest assessment of a compliance AI estate usually produces three buckets:
Probably high-risk. Anything that scores natural persons in a way that determines access to a financial service. If a model's output is what decides whether an individual gets an account or a loan, the credit-scoring analysis is the one to run, whatever the system is called internally.
Probably not high-risk, but not unregulated. Sanctions and PEP screening, adverse media analysis, document extraction, UBO structure resolution. These support a compliance determination made by a person; they do not themselves determine access. The AI Act is not the binding constraint here — but sectoral supervision, data protection and your own model governance are.
In scope of transparency regardless. Anything a client interacts with directly.
The assessment that matters is not what the vendor calls the product. It is what the output determines, and whether a human meaningfully decides. A system marketed as decision support that is, in practice, always accepted without review is not decision support. Supervisors have made this point about automated decision-making in other contexts for years, and it transfers directly.
3. The Swiss question
Switzerland has not adopted the AI Act, and Swiss institutions are not directly bound by it. Three reasons why that does not make it irrelevant.
Extraterritorial reach. The Act applies to providers placing systems on the EU market and, in defined circumstances, where the output is used in the Union. A Swiss institution serving EU-resident clients, or a Swiss vendor selling into the EU, should run the analysis rather than assume geography settles it.
The de facto standard effect. As with the GDPR, the practical outcome is that vendors build one product to the strictest applicable standard. Swiss institutions will be offered AI Act-compliant systems and will be asked, by EU counterparties and correspondents, how they govern their models — long before any Swiss rule requires it.
Swiss supervision already covers the substance. FINMA has set out expectations on governance and risk management for AI use by supervised institutions, and the Federal Council has its own roadmap. The absence of an AI Act equivalent does not mean the absence of obligations: it means the obligations arrive through the ordinary channels of operational risk, outsourcing and governance. Our article on the agentic AI compliance copilot looks at what that means for day-to-day use.
And independently of any of this, the FADP applies. Automated processing of personal data in a compliance context raises data protection duties regardless of how the AI Act classifies the system — see data protection in KYC.
4. What the obligations actually require
Strip away the structure and the high-risk requirements amount to a set of practices that good model governance already implies: a risk management system across the lifecycle; data governance covering training, validation and testing data; technical documentation; automatic logging of events; transparency to deployers; human oversight designed in; and appropriate accuracy, robustness and cybersecurity.
Deployers — which is what a bank using a third-party tool usually is — carry a narrower set: use the system per instructions, assign human oversight to people with competence and authority, ensure input data is relevant, monitor operation, and keep logs.
Two of these deserve emphasis because they are where compliance deployments actually fail.
Human oversight has to be real. Assigning a reviewer is not oversight if the reviewer processes two hundred alerts a day and the interface offers a single accept button. Oversight means the person has the information, the time and the authority to disagree. An institution that cannot show cases where the human overrode the model does not have oversight; it has a formality.
Logging is what makes everything else provable. Which model version, which inputs, which output, which human decision, when. This is the same requirement as the audit trail that periodic review and remediation already need — which is the useful insight: if your CLM platform logs decisions properly, most of the deployer evidence already exists.
5. Why waiting until December 2027 is the wrong call
Three reasons, in increasing order of importance.
The transparency obligations are already live. Covered in section 1. If a client talks to an AI, that is in scope now.
The lead time is longer than the delay. Reconstructing the provenance of training data, assembling technical documentation and retro-fitting logging onto a system that was not built to log are multi-quarter exercises. An institution that starts in mid-2027 will discover that the evidence it needs was never captured — and historic evidence cannot be created retroactively. The delay is an opportunity to build calmly, not an eighteen-month reprieve.
Your clients and correspondents will ask first. This is the one that actually determines timing. AI governance questionnaires are already standard in vendor due diligence and increasingly in correspondent banking reviews. The practical deadline is not the regulation's; it is the next counterparty questionnaire — and that arrives well before December 2027.
6. What to do now
- Inventory the AI in use. Including what arrived inside procured tools without a deployment decision. Most institutions underestimate this materially, because AI features ship inside products bought for other reasons.
- Classify each system by what it determines, not by what it is called. Does the output decide access to a service? Does a human meaningfully review?
- Identify client-facing systems and check transparency compliance now, not later.
- Ask providers for documentation. If a vendor cannot produce technical documentation and a clear statement of intended purpose, that is informative — both about the product and about where you will stand as deployer.
- Make oversight measurable. Record override rates. A rate near zero is a finding, not a reassurance.
- Check your logging. Model version, inputs, outputs, human decision, timestamp. If any element is absent, add it now so the historic record exists when it is needed.
- Write the policy once, for all regimes. AI Act, FINMA expectations, FADP and your operational risk framework overlap far more than they diverge. Writing four policies is how institutions end up with four inconsistent ones.
7. The underlying point
The AI Act's high-risk requirements are, in substance, a demand that you be able to explain what your system did and why — with documentation, logs and a human who could have decided otherwise. That is not a new idea in compliance. It is the same requirement that applies to a risk rating, a screening disposition or a decision to exit a client: you must be able to reconstruct the reasoning, years later, from a record rather than from memory.
Institutions whose client lifecycle already produces that record will find the AI Act a documentation exercise. Those relying on tools that output a score without a traceable path from inputs to conclusion will find it a rebuild — and the Omnibus delay buys them time that is only valuable if they use it.
Wecan's approach to AI in compliance starts from that constraint rather than retrofitting it: every automated contribution to a client file is recorded with its inputs, its model version and the human decision that followed, on the same record that carries everything else about the client. The regulation changes the paperwork around that. It does not change what makes a compliance decision defensible.
This article is provided for information purposes and does not constitute legal advice. The AI Act, the Digital Omnibus amendments and applicable Swiss rules should be consulted in their authoritative versions.
