Due diligence dei fornitori AI: guida pratica per team SaaS

La due diligence funziona quando trasforma un uso proposto in una decisione operativa difendibile. Il team deve capire funzione, dati e persone interessate, fornitori di modelli e infrastruttura, test, ruoli giuridici, impegni contrattuali e monitoraggio dei cambiamenti. L'esito non è un questionario completato, ma approvazione, approvazione condizionata, pilot limitato, escalation o rifiuto motivato con owner.

L'AI Act UE non contiene una checklist universale chiamata “AI vendor due diligence”. La profondità dipende da sistema, finalità, classificazione, ruolo nella catena del valore, trattamento dati e norme settoriali. Un assistente per verbali e un sistema che classifica candidati richiedono review diverse. Partite dal caso d'uso e chiedete evidenze proporzionate alle conseguenze.

Perché la review tradizionale non basta

Accesso, cifratura, disponibilità, subprocessor, incidenti e cancellazione restano essenziali. Ma un servizio AI può cambiare modelli, fonti di retrieval, filtri o uso di prompt e output senza una release convenzionale. La qualità varia per lingua, gruppo o input; un “supporto decisionale” può diventare di fatto decisivo sotto pressione.

Valutate fornitore e sistema: impresa, hosting, modelli, sicurezza, contratto e continuità; poi finalità, utenti, interessati, dati, comportamento, supervisione umana, integrazioni e azioni successive. Separarli ricrea i limiti delle review manuali durante la crescita.

Quando approfondire

Serve review rafforzata se entrano dati personali, riservati, regolamentati o del cliente; l'output influenza decisioni importanti; il servizio agisce autonomamente o modifica la produzione; si collega conoscenza proprietaria; un errore è difficile da rilevare o invertire; la supply chain è opaca; oppure un guasto causa danni materiali.

Non deducete la classificazione dal marketing. Per l'AI Act contano finalità e ruolo. L'articolo 25 può spostare gli obblighi del provider in caso di rebranding, modifica sostanziale o nuova finalità ad alto rischio. Provider di sistemi ad alto rischio e terzi che forniscono componenti devono scambiare le informazioni necessarie tramite accordi scritti. Al 30 agosto 2026 gran parte dell'AI Act è applicabile; le date modificate per l'alto rischio sono 2 dicembre 2027 per l'allegato III e 2 agosto 2028 per prodotti regolamentati. Sono finestre di preparazione.

Evidenze da richiedere

1. Sistema e supply chain: confine, modelli e provider, regioni, integrazioni, fonti, subprocessor, usi consentiti e vietati, limiti, versioni e notifiche.
2. Dati e privacy: scopo, posizione, accesso, retention, cancellazione, training e trasferimento di prompt, upload, output, feedback, metadati e log. Se il vendor è responsabile GDPR, l'articolo 28 richiede garanzie sufficienti e un contratto coerente. L'EDPB descrive una valutazione specifica e continua di competenza, affidabilità, risorse, policy, audit e certificazioni.
3. Sicurezza e resilienza: report e perimetro, vulnerabilità, incidenti, cifratura, identità, isolamento, ripristino e dipendenze. Per GenAI: prompt injection, leakage, tool non sicuri e fonti avvelenate.
4. Performance e impatti: popolazioni e lingue testate, baseline, soglie, condizioni, limiti ed errori. Testate anche la vostra configurazione con input difficili, escalation, override umano e recovery.
5. Governance: owner del vendor per sicurezza, privacy, AI governance, incidenti e avvisi; owner interni business e rischio; reclami, output dannosi e prove disponibili dopo la cessazione.

L'AI RMF volontario NIST propone policy, controlli documentati, contingenze e monitoraggio per AI di terzi. Il profilo GenAI cita due diligence d'acquisto, SLA, assurance report e trasparenza della supply chain. Sono riferimenti progettuali, non prova di conformità legale.

Contratto e workflow

Il contratto deve seguire le evidenze: finalità, utenti e dati; training; modelli, subprocessor, luoghi e avvisi; sicurezza, incidenti e cooperazione; documentazione; limiti e supervisione; cambiamenti; continuità, portabilità, cancellazione e uscita; responsabilità proporzionata. Un contratto non ripara un sistema inadatto, ma tutela informazioni e rimedi.

1. Descrivete finalità, utenti, interessati, input, output, integrazioni, automazione, review umana e azione successiva.
2. Assegnate livello preliminare e ruoli AI Act/GDPR, annotando trasferimenti, norme e incertezze.
3. Chiedete evidenze proporzionate e riutilizzate documenti aggiornati realmente pertinenti.
4. Testate il prodotto configurato con dati rappresentativi leciti; conservate versioni e risultati.
5. Gestite i gap con rimedio, controllo compensativo, ambito ristretto, pilot temporaneo, accettazione o rifiuto.
6. Riesaminate per cambi di finalità, modello, provider, dati, integrazione, autonomia, incidente o legge.

Il record decisionale contiene prodotto e versione, usi permessi e vietati, supply chain, livello, ruoli, motivazione, evidenze, test, gap, contratto, decisione, condizioni, scadenze e monitoraggio. Le nuove aspettative di AI governance richiedono evidenze aggiornate.

FAQ

Qual è lo scopo pratico?

Decidere in modo difendibile se e come usare un servizio specifico, scoprendo presto i gap, assegnando controlli e conservando prove per clienti, audit, incidenti e riesami.

Cosa documentare per primo?

L'uso esatto: utenti, interessati, dati, input, output, integrazioni, supervisione umana e azione successiva. Senza questo confine, risposte e ruoli giuridici non sono valutabili.

Qual è l'errore maggiore?

Trattare la due diligence come scambio documentale unico. Una review solida collega perimetro, prove, test, contratto, condizioni, monitoraggio e trigger di rivalutazione.