Nel giugno 2026 il Consiglio dell'Unione europea ha approvato in via definitiva il pacchetto di semplificazione «Digital Omnibus», che sposta la scadenza di conformità per i sistemi di IA ad alto rischio autonomi dell'allegato III dal 2 agosto 2026 al 2 dicembre 2027. Per i sistemi ad alto rischio incorporati in prodotti regolamentati la proroga parallela porta al 2 agosto 2028.
In molte funzioni di compliance la reazione è stata chiudere il dossier per diciotto mesi. È un errore, per tre ragioni distinte — e la più importante non ha nulla a che vedere con le scadenze.
1. Che cosa si è spostato e che cosa no
Si è spostato: gli obblighi per i sistemi ad alto rischio autonomi dell'allegato III, articoli 9-17 per i fornitori e articolo 26 per i deployer, ora applicabili dal 2 dicembre 2027.
Non si è spostato: gli obblighi di trasparenza dell'articolo 50, che impongono di segnalare quando una persona interagisce con un sistema di IA, restano al calendario originario del 2 agosto 2026. Solo il più ristretto obbligo di marcatura per i sistemi già in uso ha ottenuto una proroga, al 2 dicembre 2026.
Chi ha messo in produzione un assistente rivolto al cliente — chatbot di apertura, agente di sollecito documentale, interfaccia di supporto — rientra già ora negli obblighi di trasparenza, a prescindere dal rinvio sull'alto rischio. Il rinvio ampiamente riportato non è quello di cui la maggior parte degli istituti aveva bisogno.
2. L'IA usata in KYC/AML è ad alto rischio?
Né un sì né un no generali. Le categorie dell'allegato III più invocate in finanza riguardano la valutazione del merito creditizio e lo scoring delle persone fisiche e la valutazione del rischio e la tariffazione nelle assicurazioni vita e malattia. I sistemi di rilevazione della criminalità finanziaria sono trattati diversamente dallo scoring creditizio.
In pratica si ottengono tre gruppi: probabilmente ad alto rischio tutto ciò che valuta persone fisiche determinando l'accesso a un servizio finanziario; probabilmente fuori, ma non non regolato, screening, stampa avversa e risoluzione delle strutture di titolarità, che sostengono una valutazione umana; e soggetto a trasparenza in ogni caso tutto ciò con cui il cliente interagisce direttamente.
Ciò che conta non è il nome commerciale ma che cosa determina l'output e se un essere umano decide davvero. Un sistema presentato come supporto decisionale ma sempre accettato senza esame non è un supporto decisionale.
3. La questione svizzera
La Svizzera non ha adottato l'AI Act. Tre ragioni per cui ciò non lo rende irrilevante: la portata extraterritoriale; l'effetto di standard di fatto, poiché i fornitori costruiscono un unico prodotto sullo standard più severo e le controparti UE chiederanno come governate i modelli ben prima che una norma svizzera lo imponga; e il fatto che la vigilanza svizzera copre già la sostanza, avendo la FINMA formulato aspettative su governance e gestione del rischio nell'uso dell'IA. Indipendentemente da tutto ciò si applica la LPD — si veda protezione dei dati nel KYC.
4. Che cosa richiedono davvero gli obblighi
Un sistema di gestione del rischio lungo il ciclo di vita, governance dei dati di addestramento, validazione e test, documentazione tecnica, registrazione automatica degli eventi, trasparenza verso i deployer, sorveglianza umana progettata, accuratezza, robustezza e cibersicurezza adeguate. I deployer portano un insieme più ristretto.
La sorveglianza umana deve essere reale. Nominare un revisore non è sorveglianza se quel revisore tratta duecento alert al giorno e l'interfaccia offre un solo pulsante di accettazione. Chi non sa mostrare casi in cui l'umano ha contraddetto il modello non ha sorveglianza: ha una formalità.
La registrazione è ciò che rende dimostrabile il resto. Versione del modello, input, output, decisione umana, momento. È lo stesso requisito della pista di audit già necessaria per revisione periodica e remediation.
5. Perché attendere dicembre 2027 è la scelta sbagliata
Gli obblighi di trasparenza sono già in vigore. I tempi di preparazione superano il rinvio: ricostruire la provenienza dei dati, assemblare la documentazione e aggiungere la registrazione a un sistema non progettato per registrare sono lavori di più trimestri, e una prova storica non si crea retroattivamente. Soprattutto, clienti e corrispondenti chiederanno prima: i questionari di governance dell'IA sono già standard nella due diligence fornitori. La scadenza pratica non è quella del regolamento, è il prossimo questionario di controparte.
6. Che cosa fare ora
- Inventariare l'IA in uso, compresa quella arrivata dentro strumenti acquistati per altri motivi, senza una decisione di adozione. La maggior parte degli istituti sottovaluta questo punto in misura rilevante, perché le funzioni di IA viaggiano dentro prodotti comprati per tutt'altro.
- Classificare ogni sistema per ciò che determina, non per come si chiama. L'output decide l'accesso a un servizio? Un essere umano esamina davvero?
- Identificare i sistemi rivolti al cliente e verificarne subito la conformità agli obblighi di trasparenza.
- Chiedere la documentazione ai fornitori. Un fornitore che non sa produrre documentazione tecnica e una chiara indicazione di finalità è un'informazione di per sé — sul prodotto e sulla vostra posizione di deployer.
- Rendere misurabile la sorveglianza. Registrare i tassi di contraddizione: un tasso prossimo a zero è un rilievo, non una rassicurazione.
- Verificare la registrazione. Versione del modello, input, output, decisione umana, marca temporale. Se manca un elemento, aggiungerlo ora perché lo storico esista quando servirà.
- Scrivere la policy una sola volta, per tutti i regimi. AI Act, aspettative FINMA, LPD e quadro di rischio operativo si sovrappongono assai più di quanto divergano. Scriverne quattro significa ritrovarsene quattro incoerenti.
7. Il punto di fondo
I requisiti per l'alto rischio chiedono, in sostanza, di poter spiegare che cosa ha fatto il sistema e perché — con documentazione, registri e un essere umano che avrebbe potuto decidere diversamente. Non è un'idea nuova nella compliance: è lo stesso requisito di un rating di rischio, della chiusura di un alert o della decisione di uscire da una relazione.
L'approccio di Wecan all'IA nella compliance parte da questo vincolo invece di aggiungerlo dopo: ogni contributo automatizzato a un dossier cliente è registrato con i suoi input, la versione del modello e la decisione umana che ne è seguita, sullo stesso record che porta tutto il resto.
