La maggior parte dei CTO fintech sa che il 2 agosto si avvicina. Quasi nessuno ha tradotto la "conformità all’EU AI Act" in una vera checklist tecnica. Ecco cosa contiene davvero quella checklist.
La maggior parte dei CTO fintech con cui abbiamo parlato quest’anno sa che il 2 agosto si avvicina. Molti meno hanno tradotto la "conformità all’EU AI Act" in una vera checklist tecnica e operativa: qualcosa su cui il team possa lavorare prima della scadenza, non un riassunto legale in un Google Doc che nessuno apre.
Questo articolo è quella checklist. L’abbiamo applicata con clienti del fintech e dei servizi finanziari: quali sistemi rientrano davvero nell’ambito, cosa richiedono in pratica gli obblighi, come DORA complica le cose e cosa si può realisticamente ottenere in 81 giorni di lavoro mirato.
Una premessa: circola una proposta di proroga UE — il pacchetto Digital Omnibus, che potrebbe spostare gli obblighi dell’Allegato III a dicembre 2027. Non costruite il vostro piano su questa ipotesi. I regolatori non hanno dato conferme, e basare la strategia di compliance su una proroga non confermata è proprio il tipo di scelta che chiude carriere quando la proroga non arriva.
L’EU AI Act si applica in base a dove opera la vostra AI o a chi riguarda, non a dove è registrata la vostra azienda. Una fintech lettone che elabora richieste di credito di clienti francesi rientra nell’ambito. Una neobank statunitense con clienti UE rientra nell’ambito. Un’azienda SaaS che vende strumenti AI di valutazione del rischio a banche europee rientra nell’ambito come fornitore, anche se non tocca mai direttamente i dati degli utenti finali.
Il regolamento distingue due ruoli con obblighi diversi:
Molte fintech sono entrambe le cose: deployer per le API LLM che usano e fornitori per i modelli di rischio o i sistemi di scoring che hanno sviluppato e concedono in licenza ai partner.
Se il vostro sistema AI influisce sulla concessione di un prestito, di una polizza o dell’accesso a un servizio finanziario, siete quasi certamente fornitori di un sistema ad alto rischio ai sensi dell’Allegato III. Questo attiva l’intero quadro di compliance, non solo gli obblighi di trasparenza.
L’Allegato III elenca le categorie soggette al regime ad alto rischio. Per il fintech le voci rilevanti sono il punto 5 (accesso a servizi privati essenziali) e il punto 1 (biometria). È qui che la maggior parte dei team ha delle sorprese.
| Sistema AI | Rientra? | Nota |
|---|---|---|
| Credit scoring / valutazione del merito creditizio | RIENTRA | Elencato esplicitamente. Nessuna zona grigia. |
| AI per pricing del rischio assicurativo / underwriting | RIENTRA | Allegato III, punto 5(c). |
| Verifica biometrica / riconoscimento facciale eKYC | RIENTRA | Qualsiasi verifica dell’identità basata sulla biometria. |
| AI per le decisioni di approvazione dei prestiti | RIENTRA | Incide sull’accesso a servizi finanziari essenziali. |
| AI antifrode | ESCLUSO* | Escluso esplicitamente. Serve comunque l’allineamento a DORA. |
| Monitoraggio transazioni / screening AML | DIPENDE | Se gli output limitano l’accesso del cliente, probabilmente rientra. |
| Chatbot di assistenza clienti | RISCHIO LIMITATO | Richiesto solo l’obbligo di trasparenza. |
| Strumenti interni di produttività | NON RIENTRA | Rischio minimo. Nessun obbligo vincolante. |
L’esclusione dell’antifrode sorprende la maggior parte dei team. È esplicita nel testo normativo. Ma, ed è importante, se il vostro sistema antifrode attiva la sospensione dell’account o limita l’accesso del cliente al proprio denaro, l’analisi cambia ed è meglio ottenere un parere legale prima di considerarvi fuori dall’ambito.
Le sanzioni dell’EU AI Act si sommano a quelle del GDPR. Un sistema AI ad alto rischio che tratta anche dati personali in modo non conforme vi espone contemporaneamente a due quadri normativi distinti. Un modello di credit scoring con bias che gestisce male anche i dati personali può far scattare sia una violazione dell’AI Act sia una del GDPR. Impostate fin dall’inizio un programma di compliance che copra entrambi.
Se operate nei servizi finanziari UE, siete soggetti anche a DORA, il Digital Operational Resilience Act, pienamente applicabile dal 17 gennaio 2025. AI Act e DORA si sovrappongono in modo significativo, e la maggior parte delle guide alla compliance li tratta come filoni di lavoro separati.
Costruire due programmi di compliance separati è l’errore più costoso che un CTO fintech possa fare oggi.
DORA richiede un framework di gestione del rischio ICT. L’articolo 9 dell’AI Act richiede un sistema di gestione dei rischi per l’AI ad alto rischio. Estendete il framework ICT già previsto da DORA ai rischi specifici dell’AI, invece di costruire da zero un sistema parallelo.
DORA richiede un Registro delle informazioni su tutti i fornitori terzi di servizi ICT. I sistemi AI di terze parti (API LLM, modelli di scoring, servizi di verifica dell’identità) devono essere nel registro DORA e coperti dai requisiti di documentazione dei fornitori previsti dall’AI Act. Un solo registro, due usi di compliance.
Entrambi i quadri richiedono la segnalazione degli incidenti. Un guasto di un sistema AI che genera un incidente ICT ai sensi di DORA può richiedere anche una notifica AI Act all’autorità di vigilanza del mercato competente. Coordinate questi processi ora, non durante un incidente.
| Articolo | Requisito | Cosa significa in pratica | Impegno |
|---|---|---|---|
| Art. 9 | Sistema di gestione dei rischi | Processo documentato lungo tutto il ciclo di vita per identificare, valutare e mitigare i rischi dell’AI. Va aggiornato di continuo, non solo al deployment. | Medio |
| Art. 10 | Governance dei dati | Dati di addestramento documentati con fonti, risultati dei test sui bias e limiti noti. Pipeline di dati verificabili. | Medio |
| Art. 11 | Documentazione tecnica | Architettura completa del sistema, metodologia di addestramento, benchmark di prestazione. Pronta per la verifica del regolatore su richiesta. | Medio |
| Art. 13 | Trasparenza e logging | Logging automatico a ogni inferenza che produce un output rilevante. I log devono consentire la verifica a posteriori. È un cambiamento di architettura, non di configurazione. | Elevato |
| Art. 14 | Sorveglianza umana | "Una persona può vedere l’output" non basta. Il sistema deve consentire intervento, override e audit reali, non solo osservazione. | Elevato |
| Art. 43 | Valutazione di conformità | Autovalutazione per la maggior parte dei sistemi. Obbligatorie la marcatura CE e la registrazione nella banca dati UE. | Elevato |
Gli articoli 13 e 14 richiedono sempre più tempo del previsto. Il logging a livello di inferenza per un sistema di credit scoring ad alto volume non è un lavoro da weekend. Una sorveglianza umana conforme al regolamento non è una dashboard: è un workflow operativo con percorsi di escalation documentati, personale formato e meccanismi di override testati.
81 giorni sono pochi ma bastano, con le giuste priorità. Il lavoro di sviluppo per logging e sorveglianza umana richiede almeno 4–6 settimane per un sistema già in produzione. Iniziare a luglio significa non finire in tempo.
La risposta onesta: nei primi mesi dopo il 2 agosto i controlli si concentreranno quasi certamente sui casi più gravi, non su ogni fintech in ritardo di 30 giorni con la documentazione. Ma questa non è una strategia.
Il rischio di aspettare non è solo la sanzione: è ogni giorno dopo il 2 agosto in cui il vostro sistema non conforme tratta dati di clienti UE.
L’infrastruttura che costruite per l’EU AI Act (logging delle inferenze, workflow di sorveglianza umana, pipeline di dati verificabili) è la stessa che rende i vostri sistemi AI affidabili, verificabili e scalabili. Il lavoro di compliance e quello di sviluppo sono lo stesso lavoro.
81 giorni. Iniziate questa settimana.
Vi risponderemo entro 1 giorno lavorativo.