In sintesi

Il 67% delle aziende italiane ha subito incidenti di sicurezza legati a fornitori AI non verificati nel 2024
La verifica preventiva di agenti e vendor AI riduce del 85% i rischi di blocco operativo post-implementazione
Log, policy e permessi vanno definiti prima del contratto, non dopo il go-live
I costi di remediation post-incidente superano di 12 volte quelli di una due diligence preventiva

La chiamata arriva sempre al momento sbagliato. Il sistema AI che gestisce le previsioni di vendita ha smesso di funzionare. Il fornitore dice che serve accesso root ai server. Il responsabile IT rifiuta categoricamente. Nel frattempo, il board aspetta i dati per la riunione di domani. Suona familiare?

Questo scenario si ripete ogni settimana nelle aziende italiane che hanno integrato soluzioni AI senza una verifica fornitori AI strutturata. Il problema non è la tecnologia. È la governance che manca prima della firma del contratto.

Due diligence AI: cosa verificare prima del contratto

La due diligence tradizionale non basta più. Verificare la solidità finanziaria del fornitore o le referenze commerciali è il minimo. Con i vendor AI servono controlli specifici che molti manager sottovalutano.

Prima di tutto: dove risiedono i dati? Un’azienda manifatturiera lombarda ha scoperto solo dopo sei mesi che il suo fornitore di AI predittiva processava i dati di produzione su server in Cina. Risultato: violazione del GDPR, multa da 450.000 euro, contratto da rifare.

Secondo punto critico: quali modelli usa il fornitore? GPT-4, Claude, Llama? Proprietari o open source? La differenza impatta su costi, performance e soprattutto su chi è responsabile in caso di output errati. La due diligence AI deve mappare l’intera catena tecnologica, non solo l’interfaccia che vedete.

Terzo aspetto: i log. Cosa registra il sistema? Per quanto tempo? Chi può accedervi? Un’azienda farmaceutica veneta ha perso una causa da 2 milioni perché il fornitore AI non aveva log sufficienti per dimostrare la correttezza di una decisione algoritmica contestata.

Controlli sicurezza: il framework operativo che serve davvero

I controlli sicurezza per sistemi AI vanno oltre i classici penetration test. Serve verificare tre livelli distinti che spesso si sovrappongono pericolosamente.

Livello infrastrutturale: come si connette l’agente AI ai vostri sistemi? API dirette? VPN? Webhook? Ogni metodo ha implicazioni diverse per la sicurezza GenAI. Un retailer milanese ha subito un data breach perché l’agente AI del customer service aveva accesso diretto al database clienti senza rate limiting.

Livello applicativo: quali permessi richiede realmente il sistema? La granularità conta. “Accesso in lettura” può significare tutto e niente. Serve specificare: quali tabelle, quali campi, con quale frequenza. Un fornitore che chiede accesso admin “per semplificare l’integrazione” è una red flag immediata.

Livello comportamentale: come si comporta l’AI in situazioni anomale? Cosa succede con input malevoli? Ha meccanismi di auto-limitazione? I controlli sicurezza devono includere stress test specifici prima del deployment.

Policy e governance: evitare il caos post go-live

Il momento peggiore per definire le policy è quando il sistema è già in produzione. Eppure l’82% delle PMI italiane (dati Osservatorio Polimi 2024) implementa soluzioni AI senza un framework di governance preventivo.

Le policy devono coprire almeno quattro aree. Prima: escalation. Chi decide quando l’AI sbaglia? In quanto tempo? Con quali criteri? Un’assicurazione romana ha perso 800.000 euro perché nessuno aveva l’autorità per fermare un agente AI che stava approvando sinistri fraudolenti.

Seconda area: modifiche e aggiornamenti. Il modello AI evolve. Chi autorizza gli update? Come si testano? Quali rollback sono possibili? La verifica fornitori AI deve includere clausole precise su questi aspetti.

Terza: accesso ai dati di training. Avete diritto a sapere con cosa è stato addestrato il modello? Potete chiedere re-training con i vostri dati? A quali condizioni?

Quarta: exit strategy. Come recuperate i dati se cambiate fornitore? In quale formato? Con quali tempi? Il vendor lock-in con sistemi AI è particolarmente insidioso perché include non solo i dati ma anche la logica decisionale accumulata.

Due diligence AI: metriche e KPI da monitorare

Misurare le performance di un fornitore AI richiede metriche specifiche che vanno oltre SLA tradizionali. Il tempo di risposta è importante, ma conta di più l’accuratezza delle risposte.

Definite threshold chiari: sotto quale accuratezza il sistema diventa più dannoso che utile? Un’azienda logistica di Bologna ha scoperto che il suo sistema di routing AI aveva un’accuratezza del 94%. Sembra alto, ma quel 6% di errori costava 50.000 euro al mese in consegne fallite.

La due diligence AI deve stabilire anche metriche di drift. Quanto può degradare la performance prima di richiedere intervento? Chi monitora questo degrado? Con quali strumenti?

Importante: concordate metriche di fairness e bias. Il vostro agente AI discrimina involontariamente alcuni segmenti di clienti? Come lo verificate? Un e-commerce italiano ha rischiato una class action perché il suo sistema di pricing dinamico penalizzava sistematicamente utenti di certe aree geografiche.

Controlli sicurezza nel ciclo di vita: dal PoC alla dismissione

I controlli sicurezza cambiano in base alla fase del progetto. Durante il proof of concept, dati sintetici e ambienti isolati bastano. Ma cosa succede quando si passa in produzione?

Serve un protocollo di transizione chiaro. Quali dati reali possono essere usati? Con quali anonimizzazioni? Chi ha accesso ai risultati? Un’azienda sanitaria toscana ha dovuto rifare tutto il PoC perché aveva usato dati reali non anonimizzati, violando il GDPR.

In produzione, i controlli devono essere continui, non episodici. Audit trimestrale non basta. Serve monitoring real-time di comportamenti anomali, pattern di accesso sospetti, derive nelle risposte.

Alla dismissione, la bonifica è cruciale. Cosa rimane nei sistemi del fornitore? Nei backup? Nei log? La verifica fornitori AI deve prevedere certificazioni di cancellazione verificabili.

Il costo reale del non verificare: casi italiani recenti

I numeri parlano chiaro. Secondo l’ultimo report di Assintel (ottobre 2024), il 43% delle aziende italiane che hanno implementato soluzioni AI senza due diligence strutturata ha dovuto affrontare costi imprevisti entro i primi 6 mesi.

Costi diretti: remediation tecnica, consulenze legali, penali contrattuali. Ma sono i costi indiretti a fare più male. Tempo perso del management, rallentamenti operativi, danni reputazionali. Un’azienda di servizi finanziari milanese ha calcolato che un incidente con un chatbot non verificato le è costato 3,2 milioni considerando tutti i fattori.

La prevenzione costa una frazione. Una due diligence completa su un fornitore AI medio richiede 15-20 giorni e 20-30.000 euro. Il ROI è evidente: ogni euro speso in verifica preventiva ne risparmia 12 in gestione delle crisi.

Verificare agenti e fornitori AI non è paranoia manageriale. È gestione del rischio intelligente. La differenza tra chi lo fa e chi lo rimanda si misura in milioni di euro e, spesso, nella sopravvivenza stessa del progetto di trasformazione digitale.

Il momento migliore per implementare un processo strutturato di verifica era prima di firmare il primo contratto. Il secondo momento migliore è ora, prima che sia troppo tardi per correggere.

FAQ

Quali sono i documenti essenziali da richiedere durante la verifica fornitori AI?

Certificazioni ISO 27001, report di penetration test recenti, documentazione API completa, data flow diagram, politiche di data retention, piano di disaster recovery, evidenze di compliance GDPR e registro dei sub-processor utilizzati.

Quanto tempo richiede mediamente una due diligence AI completa?

Per un fornitore enterprise servono 15-20 giorni lavorativi. Per soluzioni SaaS standard bastano 7-10 giorni. I tempi si allungano se il vendor opera extra-UE o usa catene complesse di sub-fornitori.

Come valutare i controlli sicurezza di un agente AI conversazionale?

Verificate rate limiting, meccanismi anti-jailbreak, logging delle conversazioni, crittografia end-to-end, gestione delle sessioni, validazione input e sandbox per l’esecuzione di codice generato.

Quali clausole contrattuali sono irrinunciabili con fornitori AI?

Right to audit, SLA su accuratezza oltre che su uptime, responsabilità per output errati, clausole di re-training, exit strategy dettagliata, divieto di uso dati per training di modelli di terzi.

Come verificare se un fornitore AI rispetta il GDPR?

Richiedete DPIA specifica, verificate localizzazione server, controllate base legale per il trattamento, esaminate meccanismi di portabilità dati e confermate procedure per richieste di cancellazione.

Quali metriche includere nel monitoraggio post-implementazione?

Accuratezza per categoria di task, tempo di inferenza, costi per query, drift del modello, false positive rate, bias score per segmenti demografici e consumo risorse computazionali.

Come gestire la verifica di fornitori AI che usano modelli open source?

Verificate licenze dei modelli base, controllate modifiche apportate, richiedete documentazione su fine-tuning, esaminate dipendenze software e confermate processo di aggiornamento security patch.

Quali sono i red flag immediati durante la due diligence AI?

Rifiuto di fornire log di training, mancanza di versioning del modello, assenza di meccanismi di rollback, richieste di accesso admin non giustificate, impossibilità di audit indipendenti.