Immaginate di ricevere domani una richiesta di audit da IVASS sui sistemi AI in uso nella vostra compagnia. Sapreste rispondere con precisione a queste tre domande: quali sistemi rientrano nella categoria “alto rischio” secondo l’AI Act? Avete completato la valutazione d’impatto sui diritti fondamentali per ciascuno di essi? I contratti con i vostri fornitori AI sono conformi? Ovvero, contengono le clausole obbligatorie previste dall’Art. 26?
Se la risposta a una sola di queste domande è “non siamo sicuri”, questo articolo è per voi.
Il 2 agosto 2026 è la scadenza entro cui le compagnie assicurative che utilizzano sistemi AI ad alto rischio devono essere pienamente conformi agli obblighi del Regolamento UE 2024/1689 — il cosiddetto AI Act. Una delle convinzioni più diffuse e più pericolose nel settore è che la compliance sia responsabilità del fornitore tecnologico. Non è così: l’ Art. 26 pone obblighi diretti e non delegabili sul deployer, cioè su chi utilizza il sistema AI nel proprio processo operativo o decisionale.
In questa guida troverete: un metodo rapido per capire se siete coinvolti, la mappa degli obblighi che ricadono direttamente su di voi come deployer, il quadro del doppio regime DORA + AI Act che complica la gestione contrattuale, le sette clausole che ogni contratto con un fornitore AI deve contenere, e una checklist operativa per arrivare pronti all’agosto 2026.
Siete un deployer di sistema AI (utilizzatore AI) ad alto rischio? Scopritelo in due minuti
Prima di occuparsi di clausole contrattuali e valutazioni d’impatto, occorre rispondere a una domanda preliminare: il vostro caso rientra nel perimetro dell’AI Act?
Partite da qui. Nella vostra compagnia, uno o più sistemi AI vengono utilizzati per almeno una di queste attività?
- Calcolo del pricing per polizze vita o salute
- Valutazione del rischio in fase di underwriting
- Scoring automatizzato dei sinistri
- Profilazione di clienti per offerte assicurative personalizzate
Se la risposta è sì, siete deployer di un sistema AI ad alto rischio ai sensi dell’ Allegato III, punto 5(c) del Regolamento UE 2024/1689, che include espressamente i “sistemi AI destinati a essere utilizzati per la valutazione del rischio e la determinazione del prezzo in relazione alle persone fisiche nel caso delle assicurazioni vita e salute.”
Cosa non rientra automaticamente nell’alto rischio?
Non tutti i sistemi AI in uso in una compagnia assicurativa sono classificabili come alto rischio. Restano fuori — salvo eccezioni — i chatbot di customer service, i sistemi di fraud detection generici non collegati a decisioni individuali su assicurati, e i sistemi di ottimizzazione operativa interna (es. scheduling, gestione documentale).
Attenzione: la trappola del “supporto alla decisione”
Il Considerando 47 del Regolamento chiarisce che un sistema che formalmente si presenta come strumento di supporto alla decisione umana, ma che in pratica determina o condiziona sostanzialmente l’esito finale, è comunque da classificare come alto rischio. Se il vostro modello di pricing “suggerisce” un premio e l’operatore lo accetta nel 98% dei casi senza modifiche, quel sistema è ad alto rischio indipendentemente da come è stato contrattualmente inquadrato con il fornitore. La forma non prevale sulla sostanza funzionale.
Il doppio regime DORA + AI Act: i vostri contratti devono fare di più per essere conformi
Per le compagnie assicurative italiane, la sfida non è solo adeguarsi all’AI Act. Dal 17 gennaio 2025 è già in vigore il Regolamento UE 2022/2554 — il DORA (Digital Operational Resilience Act) — che impone un proprio set di requisiti sulla gestione contrattuale dei fornitori ICT. Quando il fornitore AI è anche un fornitore ICT critico, i due regimi si sovrappongono e nessuno dei due sostituisce l’altro.
| DORA (Reg. UE 2022/2554) | AI Act (Reg. UE 2024/1689) | |
| In vigore dal | 17 gennaio 2025 | 2 agosto 2026 (per i deployer) |
| Autorità di vigilanza IT | IVASS | Autorità nazionale competente AI (in definizione) |
| Obblighi contrattuali | Art. 28-30: registro ICT, SLA, audit, exit strategy | Art. 26-27: log, FRIA, supervisione umana, istruzioni d’uso |
| Registro informazioni | Sì — trasmesso a IVASS (scadenza già operativa) | No registro separato, ma documentazione tecnica allegata al contratto |
| Sanzioni | Procedimenti IVASS per violazione gestione rischio operativo | Fino a €15M o 3% del fatturato globale |
Il caso concreto che illustra la complessità. Considerate un fornitore SaaS che offre un sistema di fraud detection automatizzata per la valutazione dei sinistri. Questo fornitore è simultaneamente: un fornitore ICT di terze parti potenzialmente critico ai sensi di DORA — con tutto ciò che ne consegue in termini di contratto standard DORA, iscrizione nel Registro delle Informazioni da trasmettere a IVASS, e diritti di audit; e il provider di un sistema AI ad alto rischio ai sensi dell’AI Act — con obblighi separati di log, FRIA, istruzioni d’uso e notifica delle modifiche al modello.
Il contratto che regola questo rapporto deve coprire entrambi i framework. Non è possibile soddisfare DORA e ignorare l’AI Act, né viceversa. La progettazione contrattuale deve partire da questa premessa.
Un riferimento utile in questo senso è la Comunicazione IVASS del 7 marzo 2025 sulla trasmissione del registro contratti ICT, che chiarisce le aspettative del supervisore italiano sulla gestione dei fornitori tecnologici e offre indicazioni pratiche sulla struttura della documentazione attesa.
Gli obblighi diretti del deployer: Art. 26 e Art. 27
Ora che sapete di essere coinvolti e conoscete il contesto normativo complessivo, è il momento di entrare nel dettaglio di ciò che l’AI Act richiede direttamente a voi, in quanto deployer.
L’Art. 26 è la norma centrale. Non si rivolge al fornitore del sistema AI — si rivolge a chi lo utilizza. Delega al deployer responsabilità che non possono essere scaricate sul fornitore attraverso una clausola contrattuale, perché riguardano scelte organizzative interne.
| Obbligo | Articolo AI Act | In pratica per una compagnia assicurativa | Rischio se non fatto |
| Usare il sistema AI secondo le istruzioni del provider | Art. 26(1) | Non modificare parametri oltre i limiti documentati; rispettare il perimetro d’uso previsto | Responsabilità diretta in caso di danni a terzi derivanti da uso improprio |
| Assegnare supervisione umana qualificata | Art. 26(2) | Designare un responsabile con formazione documentata sul sistema in uso | Nullità della supervisione umana formalmente dichiarata |
| Monitorare le performance in produzione | Art. 26(5) | Rilevare derive del modello (model drift) e segnalarle al provider | Decisioni sistematicamente errate non rilevate né corrette |
| Conservare i log automatici ≥ 6 mesi | Art. 26(6) | I log vanno integrati nel registro DORA se il fornitore è critico | Impossibilità di dimostrare la conformità in sede di audit |
| Informare i lavoratori interessati | Art. 26(7) | Comunicare ai dipendenti che il loro lavoro è monitorato o assistito da AI | Violazione del diritto dei lavoratori all’informazione |
| Completare la FRIA prima del primo utilizzo | Art. 27 | Valutazione d’impatto sui diritti fondamentali — obbligatoria per enti pubblici e per soggetti privati che erogano servizi pubblici o ad ampia scala | Utilizzo del sistema privo di base legale completa |
Una nota sulla FRIA.
La Fundamental Rights Impact Assessment prevista dall’Art. 27 è probabilmente l’adempimento più sottovalutato. Non è una formalità: è una valutazione strutturata che analizza come il sistema AI possa incidere su diritti fondamentali degli assicurati — in particolare il diritto alla non discriminazione e alla tutela dei dati personali. Deve essere completata prima del primo utilizzo del sistema, aggiornata a ogni modifica sostanziale, e deve basarsi su informazioni che solo il provider può fornire. Questo è il motivo per cui “supporto alla FRIA” deve essere una clausola esplicita nel contratto.
Le 7 clausole obbligatorie per contratti con i fornitori AI conformi
Queste clausole non sono negoziabili. Ogni contratto con un fornitore di sistema AI ad alto rischio deve contenerle tutte, con il contenuto minimo indicato. Dove il fornitore è anche un provider ICT critico ai sensi di DORA, la clausola deve soddisfare entrambe le basi normative.
| Clausola | Base normativa | Contenuto minimo |
| 1. Documentazione tecnica e istruzioni d’uso | Art. 26(1) AI Act | Il provider deve consegnare documentazione tecnica completa, allegata o richiamata nel contratto, prima dell’avvio in produzione. Include perimetro d’uso, limiti operativi e parametri non modificabili. |
| 2. Trasparenza e spiegabilità delle decisioni | Art. 13 AI Act (obbligo del provider) + Art. 26 AI Act (enforcement del deployer) | SLA su spiegabilità: il provider deve essere in grado di fornire, su richiesta del deployer, una spiegazione intelligibile di ogni singola decisione del sistema per le persone fisiche coinvolte. Tempi di risposta e formato devono essere definiti contrattualmente. |
| 3. Diritto di audit del deployer | Art. 26(5) AI Act + Art. 30 DORA | Diritto di audit almeno annuale, con accesso ai log, alla documentazione del modello e all’ambiente di test. Per i fornitori ICT critici DORA, il diritto di audit deve essere esercitabile anche su richiesta di IVASS. |
| 4. Notifica modifiche sostanziali al modello | Art. 26(4) AI Act | Il provider deve notificare qualsiasi modifica sostanziale al sistema AI con almeno 30 giorni di anticipo rispetto al deploy in produzione. Il contratto deve definire cosa si intende per “modifica sostanziale” e prevedere una procedura di re-validazione. |
| 5. Conservazione log e tracciabilità | Art. 26(6) AI Act + Art. 25 DORA | Minimo 6 mesi di log per AI Act; 5 anni se il fornitore è classificato ICT critico ai sensi di DORA. I log devono essere esportabili in formato leggibile e trasferibili in caso di cambio fornitore. |
| 6. Supporto alla FRIA | Art. 27 AI Act | Il provider ha l’obbligo contrattuale di fornire tutte le informazioni necessarie per completare la Fundamental Rights Impact Assessment: architettura del modello, dati di training utilizzati, bias testing effettuati, limitazioni note. Deve aggiornare queste informazioni ad ogni modifica sostanziale. |
| 7. Exit clause con portabilità dei dati | Art. 29 DORA | In caso di recesso o non rinnovo del contratto, il provider deve garantire la portabilità di tutti i log decisionali, della documentazione tecnica e dei dati di training eventualmente derivati dai dati del deployer. Il periodo di transizione deve essere definito (raccomandato: minimo 6 mesi). |
Una nota pratica sulle clausole 4 e 6. Queste due sono tipicamente le più resistite dai provider, perché implicano obblighi attivi da parte loro. È utile inserirle esplicitamente tra le condizioni sospensive del contratto o dell’avvio in produzione: il sistema non entra in produzione finché il provider non ha consegnato la documentazione per la FRIA e non ha concordato la procedura di notifica delle modifiche. Questo elimina l’ambiguità e riduce il rischio di avviare il sistema in condizioni di non conformità.
Scarica ora la Checklist gratuita da applicare entro Agosto 2026.
Troverai le 7 verifiche da fare oggi per avere contratti con i fornitori AI completamente conformi
Le sanzioni: cosa rischia concretamente il deployer non conforme
Le sanzioni previste dall’AI Act per i deployer non sono simboliche.
L’Art. 101(4) del Regolamento UE 2024/1689 prevede, per i deployer che violano gli obblighi dell’Art. 26, sanzioni fino a €15 milioni o al 3% del fatturato mondiale annuo, se superiore. Per un provider di sistema AI non conformi, la soglia sale a €35 milioni o al 7% del fatturato.
Ma le sanzioni pecuniarie non sono l’unico rischio. Per le compagnie assicurative italiane, la mancata conformità all’AI Act si sovrappone ai procedimenti IVASS per violazione degli obblighi di gestione del rischio operativo previsti da DORA — con conseguente impatto sul rating di vigilanza e potenziali restrizioni operative.
Il rischio forse più immediato è però di natura civilistica: una decisione automatizzata non trasparente — un rifiuto di polizza, un premio significativamente aumentato, una liquidazione sinistri contestata — espone la compagnia a responsabilità diretta verso l’assicurato in assenza di tracciabilità adeguata e di possibilità di spiegazione. Con il GDPR già in vigore e l’AI Act che rafforza i diritti individuali sulle decisioni automatizzate, il contenzioso in questo ambito è destinato a crescere.
Conclusione
L’agosto 2026 sembra lontano. Non lo è, soprattutto se si considerano i tempi reali di rinegoziazione contrattuale con i fornitori, di completamento della FRIA, di designazione e formazione dei supervisori umani, e di aggiornamento dei sistemi di log.
Il punto di partenza è la mappatura. Una volta identificati con precisione i sistemi ad alto rischio in uso, tutto il resto — obblighi, contratti, adempimenti — segue una logica lineare che questa guida ha cercato di rendere operativa.
Trakti supporta le compagnie assicurative in questa transizione su due fronti concreti. Il primo è contrattuale: Trakti automatizza la generazione delle clausole obbligatorie per AI Act e DORA, riducendo significativamente i tempi di rinegoziazione con i fornitori e il rischio di omissioni. Il secondo è documentale: ogni versione contrattuale viene archiviata su blockchain con timestamp certificato e hash crittografico — immutabile e verificabile in qualsiasi momento, senza intervento manuale. Quando IVASS richiede evidenza che un contratto con un fornitore ICT o AI contenesse determinate clausole in una data precisa, Trakti genera il report di compliance con un click, eliminando il lavoro di ricostruzione documentale.
Questo approccio si traduce anche in un ritorno sull’investimento concreto: la compliance DORA passa da attività manuale e onerosa a processo automatizzato, con riduzione significativa di tempi, costi operativi ed errori. L’automazione del monitoraggio contrattuale e dei registri riduce l’esposizione a sanzioni e audit complessi, mentre la maggiore visibilità abilita decisioni più rapide. In questo modo, la compliance non è più solo un obbligo, ma diventa un fattore di efficienza e vantaggio competitivo.
Vorresti approfondire?
