Checklist di due diligence dei fornitori di IA per fondatori e responsabili compliance

Una checklist di due diligence dei fornitori di IA deve stabilire se un servizio specifico, in una configurazione specifica, è adatto all’uso previsto. Prima dell’approvazione documentate uso, flussi di dati, catena dei fornitori, ruoli giuridici, controlli di sicurezza, test delle prestazioni, condizioni contrattuali, supervisione umana e piano di uscita. Assegnate a ogni questione aperta un responsabile e una decisione: risolvere prima del lancio, limitare il progetto pilota, sottoporre a un livello superiore o rifiutare.

Questa checklist è un modello operativo per fondatori e responsabili compliance SaaS, non un questionario imposto dalla legge né una certificazione. Proporzionate le prove al possibile danno. Uno strumento di scrittura basato su materiale pubblico richiede meno verifiche di un sistema che classifica candidati o di un agente capace di modificare account clienti. La reputazione del fornitore non dimostra la sicurezza della vostra implementazione.

Quando eseguire la verifica

Iniziate prima di caricare informazioni reali dei clienti, collegare sistemi di produzione o assumere impegni vincolanti con i clienti. Ripetete la verifica quando un fornitore esistente aggiunge IA, cambia la finalità, entrano nuovi dati, compare un altro modello o sub-responsabile, oppure diminuisce il controllo umano. Il rinnovo è un punto di controllo utile, ma non deve essere l’unico evento attivante.

Usate la checklist per servizi IA acquistati, API integrate e funzioni IA in normali prodotti SaaS. Se una funzione non usa IA, può bastare la normale verifica del fornitore. Senza dati personali, alcune domande sulla privacy possono non applicarsi; sicurezza, riservatezza, affidabilità e contratto possono restare rilevanti. Motivate ogni risposta «non applicabile».

Per ciascun punto registrate risposta, collegamento alle prove, revisore, data e lacune residue. Preferite una clausola datata, un’esportazione della configurazione o un risultato di test a una rassicurazione commerciale generica.

1. Definire l’uso approvato e le responsabilità

• Quale compito preciso svolgerà il servizio e per chi?
• Quali persone potrebbero subire conseguenze da risultati o azioni errati?
• Produce bozze, raccomanda, classifica, decide o esegue azioni?
• Chi risponde del risultato aziendale, della configurazione tecnica e dell’approvazione?
• Quali usi, categorie di dati e integrazioni sono espressamente esclusi?

Scrivete un limite applicabile tecnicamente: «Preparare risposte di assistenza da articoli approvati; un dipendente verifica ogni risposta; nessuna modifica agli account». Evitate di approvare genericamente «IA per l’assistenza». Registrate piano del prodotto e ambiente, perché account di prova e implementazione aziendale possono avere condizioni e controlli diversi.

Prove da conservare: descrizione d’uso di una pagina, responsabili nominati, schema architetturale ed elenco degli usi esclusi. Una responsabilità non assegnata deve bloccare l’approvazione finché qualcuno non la accetta.

2. Identificare la catena di fornitori e modelli

Chiedete quale entità giuridica eroga il servizio, quali modelli usa, dove avviene il trattamento e quali altre organizzazioni ricevono i dati. Stabilite se le richieste possono essere instradate verso modelli diversi e se la configurazione fissa o consente tali scelte.

Richiedete un elenco aggiornato di fornitori e sub-responsabili, documentazione pertinente, informazioni disponibili su modelli e versioni e procedura di notifica delle modifiche sostanziali. Distinguete ciò che il fornitore non può divulgare da ciò che non ha ancora consegnato. I dettagli mancanti devono restare incertezze visibili, spiegandone l’effetto sull’approvazione.

Controllo decisionale: riuscite a identificare organizzazioni e componenti rilevanti per il rischio proposto? Altrimenti limitate il pilota a materiale non sensibile o richiedete una valutazione superiore. Un lungo elenco di loghi non è una mappa dei flussi di dati.

3. Mappare il trattamento e le responsabilità privacy

Seguite prompt, file caricati, documenti recuperati, risultati, feedback, accessi dell’assistenza e log. Chiedete separatamente conservazione, cancellazione, uso per addestramento, accesso umano e regione di trattamento per ogni tipo di dato rilevante. «Non addestriamo sui vostri dati» non chiarisce quanto rimangano i log antiabuso né chi possa consultarli.

Quando si applica il GDPR, determinate i ruoli di titolare e responsabile per ogni attività. L’articolo 28 richiede garanzie sufficienti del responsabile e un contratto conforme; l’articolo 35 impone una DPIA quando il trattamento può presentare un rischio elevato. Considerate base giuridica, trasparenza e requisiti del capo V per i trasferimenti internazionali pertinenti. Queste verifiche dipendono dal trattamento effettivo, non dall’etichetta «IA». GDPR, articoli 5–6, 13–14, 28, 35 e capo V.

Prove da conservare: mappa dei flussi, accordo di trattamento applicabile, impostazioni di conservazione, valutazione dei trasferimenti ove pertinente e screening documentato della DPIA. Provate la cancellazione con un campione sicuro invece di supporre che eliminare uno spazio di lavoro rimuova tutte le copie conservate.

4. Verificare ambito e date del regolamento IA

Registrate il ruolo dell’organizzazione, la finalità prevista del sistema e gli obblighi pertinenti. Acquistare un prodotto non rende sempre la vostra organizzazione soltanto un deployer: marchio, modifiche o cambiamento di finalità possono incidere sulle responsabilità. Verificate pratiche vietate e trasparenza applicabile separatamente dalla classificazione ad alto rischio. Regolamento IA, articoli 3, 5, 6, 25 e 50.

Secondo la verifica dell’8 settembre 2026, il calendario modificato applica le principali regole ad alto rischio dell’allegato III dal 2 dicembre 2027 e le corrispondenti regole relative ai prodotti dell’allegato I dal 2 agosto 2028. Non è un rinvio di tutti gli obblighi del regolamento IA. Registrate disposizioni e norme transitorie pertinenti alla vostra implementazione. Commissione europea: entrata in vigore dell’Omnibus IA.

Controllo decisionale: richiedete prove pertinenti al ruolo e al sistema identificati. Una dichiarazione generica di «conformità al regolamento IA» non sostituisce una valutazione motivata dell’ambito. Sottoponete le incertezze a revisione prima di usare il sistema per decisioni rilevanti.

5. Verificare sicurezza e limiti delle integrazioni

Chiedete come il servizio autentica utenti, separa ambienti clienti, protegge segreti, registra accessi e gestisce vulnerabilità. Esaminate ambito e periodo di qualsiasi relazione indipendente di assurance. Controllate che copra servizio IA e configurazione previsti e valutate le eccezioni sostanziali.

Elencate singolarmente i permessi degli strumenti collegati. Un assistente che legge articoli informativi non deve ricevere automaticamente il permesso di esportare tutti i ticket o emettere rimborsi. Provate se i contenuti recuperati possono deviare l’assistente, se informazioni non autorizzate appaiono nei risultati e se le azioni rischiose richiedono un’approvazione separata.

Prove da conservare: configurazione degli accessi, prove di assurance pertinenti, permessi delle integrazioni, risultati dei test e decisioni correttive. Assegnate esplicitamente ai responsabili tecnici la disattivazione degli accessi inutili prima del lancio.

6. Testare utilità, errori e supervisione umana

Definite i criteri di accettazione prima della dimostrazione. Preparate casi rappresentativi con input incompleti, documenti fuorvianti, domande senza risposta supportata, lingue pertinenti e abusi plausibili. Usate materiale sintetico o altrimenti autorizzato. Registrate configurazione e data del test per delimitarne i risultati.

Valutate gli aspetti importanti per il compito: correttezza, tracciabilità, divulgazione inappropriata, trattamento incoerente e arresto sicuro quando il sistema non sa rispondere. Per raccomandazioni rilevanti, verificate che i revisori abbiano informazioni, tempo, autorità e capacità pratica di contestare un risultato.

Il NIST AI RMF organizza il lavoro sui rischi in Govern, Map, Measure e Manage. Può strutturare la verifica, ma adottarlo non dimostra da solo conformità legale. NIST AI RMF Core.

Controllo decisionale: concordate quali errori bloccano il lancio e quali sono controllabili restringendo l’uso. «È coinvolta una persona» non basta se questa accetta abitualmente i risultati senza verificarli.

7. Confrontare contratto e configurazione

Verificate che le condizioni firmate coprano piano acquistato, usi consentiti, trattamento dei dati, riservatezza, impegni di sicurezza, collaborazione negli incidenti, modifiche sostanziali e cessazione. Chiedete chi possiede o può usare input e output, quali restrizioni valgono e cosa accade in caso di reclamo sulla proprietà intellettuale. Non deducete titolarità o protezione dal materiale commerciale.

Confrontate promesse e impostazioni. Se il contratto permette di escludere l’addestramento, stabilite se l’opzione è attiva e chi può modificarla. Se promette cancellazione, registrate processo, esclusioni e prove ottenibili. Chiedete come il fornitore vi aiuterà a indagare incidenti e adempiere ai vostri obblighi.

Prove da conservare: condizioni firmate, allegati pertinenti, eccezioni approvate e riscontri della configurazione. Separate i temi negoziali commerciali dai requisiti da soddisfare prima che il servizio riceva dati di produzione.

8. Registrare decisione, monitoraggio e uscita

Usate esiti espliciti: approvato entro l’ambito, approvato con condizioni, pilota limitato, sottoposto a valutazione superiore o rifiutato. Registrate rischi residui, persona autorizzata ad accettarli, scadenze e prossima revisione. Un ostacolo al lancio irrisolto non deve diventare una normale attività successiva solo perché il rilascio è vicino.

Assegnate un responsabile al monitoraggio di modifiche sostanziali, incidenti, controlli qualità falliti, reclami e ampliamenti d’uso. Decidete quali eventi richiedono nuova verifica. Confermate che il team possa revocare accessi, rimuovere integrazioni, esportare documenti necessari, chiedere cancellazione e continuare il processo se il fornitore diventa indisponibile.

Prove da conservare: decisione firmata e procedura di arresto o alternativa testata. L’approvazione deve essere comprensibile a chi non ha partecipato alle chiamate. Collegatela alle prove per la due diligence degli investitori, senza ricostruire ogni volta il dossier.

Un verbale pratico di approvazione

Usate questo schema compatto per un fornitore e un uso. Allegate le prove invece di copiare intere relazioni.

| Campo | Cosa registrare | | --- | --- | | Ambito | Servizio, piano, finalità, utenti, dati, integrazioni, esclusioni | | Responsabilità | Responsabile aziendale, tecnico, revisore privacy/legale, approvatore | | Risultanze | Riferimenti alle prove, test, incertezze, ambito giuridico | | Decisione | Esito, motivazione, rischi residui, eccezioni accettate | | Condizioni | Azione necessaria, responsabile, scadenza, dipendenza del lancio | | Seguito | Data di revisione, eventi attivanti, contatto incidenti, procedura di uscita |

Una regola utile di completamento richiede prove o una lacuna esplicita per ogni domanda obbligatoria, una gestione per ogni lacuna e un responsabile per ogni condizione. «Questionario ricevuto» è una tappa di avanzamento, non una decisione di approvazione.

Esempio: assistente per bozze di supporto

Supponiamo che un team SaaS voglia un assistente per preparare risposte ai clienti. La proposta iniziale collega l’intero archivio ticket e consente invio automatico. La verifica rileva allegati privati, conservazione dei log incerta e passaggi di risoluzione talvolta inventati.

Un pilota limitato potrebbe usare articoli approvati, ticket sintetici, nessun invio automatico e revisione documentata dei dipendenti. Prima della produzione, il team chiarirebbe la conservazione, limiterebbe gli accessi al recupero, proverebbe errori rappresentativi e approverebbe il contratto pertinente. Sono controlli esemplificativi, non una garanzia di accettabilità per ogni impiego nel supporto.

Se in seguito si attivano rimborsi, l’approvazione originaria non descrive più l’uso. Riaprite la verifica di permessi di scrittura, abusi, autorizzazione e ripristino. Un verbale riutilizzabile è quindi più utile di un’etichetta «approvato» per l’intero fornitore. Riduce anche le duplicazioni illustrate nella guida alle verifiche manuali del rischio fornitori.

Errori comuni e domande frequenti

Basta un certificato di sicurezza?

No. Può sostenere specifiche affermazioni di sicurezza nel proprio ambito. Non stabilisce se uso dei dati, ruolo giuridico, risultati, integrazioni e contratto siano adatti. Conservatelo insieme alle prove specifiche dell’implementazione.

Ogni fornitore IA richiede la stessa verifica?

No. Applicate controlli leggeri agli usi reversibili a basso impatto e approfonditi per dati sensibili, decisioni rilevanti o ampi permessi. Documentate motivazione della profondità e condizioni che la cambierebbero.

Cosa dovrebbe documentare prima un fondatore?

Partite da uso esatto, categorie di dati, responsabile aziendale e permessi. Questi fatti permettono agli specialisti di richiedere prove pertinenti. Senza di essi, anche un questionario dettagliato può descrivere il servizio sbagliato.

Se il fornitore rifiuta prove importanti?

Registrate rifiuto e incertezza risultante. Considerate prove alternative, un’implementazione più limitata o un altro fornitore. Non chiudete il punto solo perché il fornitore dichiara riservata l’informazione.

Quando è completa la checklist?

Per la decisione attuale, quando ambito, prove, lacune, condizioni e approvatore responsabile sono registrati. Il processo operativo continua con monitoraggio e rivalutazione. Iniziate questa settimana con un fornitore proposto e rendete il verbale riutilizzabile.

Fonti e credito fotografico

I collegamenti accanto alle affermazioni rimandano al GDPR, al testo consolidato vigente del regolamento IA, all’aggiornamento della Commissione europea e al NIST AI RMF Core. Checklist operativa ed esempio sono raccomandazioni editoriali, non ulteriori requisiti legali.

Immagine: riunione del team Wiki Loves Monuments a Vienna, fotografata da Manfred Werner (Tsui), tramite Wikimedia Commons, CC BY-SA 4.0. Ridimensionata. Illustra una verifica collaborativa; non implica approvazione o sostegno.