Errori comuni nella due diligence dei fornitori di IA che i team SaaS continuano a commettere

Gli errori più dannosi sono approvare un uso indefinito, accettare rassicurazioni senza prove, trascurare i flussi di dati e mantenere l’approvazione dopo cambiamenti sostanziali. Esaminate insieme servizio, configurazione e compito previsto. Registrate cosa avete verificato, quali incertezze restano, chi accetta il rischio e quali cambiamenti riaprono la decisione.

Per fondatori e responsabili della conformità, lo scopo pratico è sostenere una decisione di acquisto e implementazione motivata. Un questionario compilato non indica agli sviluppatori quali integrazioni siano consentite né al responsabile clienti quali promesse siano supportate. Una valutazione utile collega queste decisioni a prove e responsabili identificati.

Le raccomandazioni seguenti rappresentano un approccio operativo, non un questionario obbligatorio o una certificazione. Adattatele alle conseguenze degli errori. Uno strumento che riassume documenti pubblici e un agente che modifica i permessi dei clienti non dovrebbero seguire un processo di approvazione identico.

Quando serve questa valutazione

Valutate prima di introdurre dati dei clienti, collegare sistemi interni o impegnarvi per un lancio in produzione. Includete le funzioni di IA aggiunte dai fornitori esistenti: una piattaforma collaborativa approvata non autorizza automaticamente un nuovo assistente ad analizzare ogni documento.

Ripetete i controlli pertinenti quando cambiano finalità, instradamento dei modelli, categorie di dati, autorizzazioni, contratto o supervisione umana. Se il prodotto non usa IA, può bastare la normale valutazione del fornitore. Senza dati personali, alcuni controlli privacy possono non applicarsi; riservatezza, sicurezza, affidabilità e pianificazione dell’uscita possono comunque restare importanti. Motivate ogni esclusione.

1. Approvare il fornitore anziché l’uso

«Fornitore approvato» nasconde il limite essenziale. La stessa azienda può offrire account personali, spazi aziendali e API con controlli diversi. La valutazione positiva di un piano non dimostra che un altro sia adatto a informazioni riservate sul prodotto.

Formulate l’approvazione intorno a un compito: «Preparare risposte di assistenza da articoli approvati; il personale controlla ogni risposta; nessuna modifica agli account». Includete piano, ambiente, utenti, dati ammessi, integrazioni e usi esclusi. Separate le responsabilità del referente aziendale e di quello tecnico.

Prima dell’acquisto, chiedete a uno sviluppatore estraneo alle conversazioni commerciali di spiegare la configurazione consentita sulla base del fascicolo. Se non riesce, l’ambito è ancora troppo vago. Chiaritelo prima che gli acquisti interpretino un ordine firmato come autorizzazione all’implementazione.

2. Considerare i rapporti di assurance prove universali

Un rapporto di sicurezza può sostenere affermazioni specifiche entro il suo ambito e periodo. Non dimostra che un servizio di IA risponda in modo affidabile, rispetti i permessi di recupero dei documenti o soddisfi le esigenze contrattuali. Una dimostrazione brillante risponde a ancora meno domande.

Associate ogni affermazione importante a una prova: sezione pertinente del rapporto, impegno contrattuale, esportazione della configurazione o test riproducibile. Registrate eccezioni e data di esame. Verificate che le prove coprano il prodotto effettivo, compresa la funzione di IA e l’ambiente di hosting pertinente.

Chiedete chiarimenti se la copertura è incerta. Se il fornitore rifiuta le prove, mantenete visibili la lacuna e il suo effetto sull’approvazione. La riservatezza può giustificare un accesso controllato al rapporto; non trasforma una dichiarazione non verificata in un controllo concluso. Considerate un pilota limitato o un altro fornitore quando l’incertezza è rilevante.

3. Confondere i limiti all’addestramento con una protezione completa dei dati

«Non addestriamo sui dati dei clienti» lascia aperte domande importanti. Tracciate separatamente prompt, allegati, documenti recuperati, risultati, feedback e log. Stabilite conservazione, cancellazione, accesso umano, luoghi di trattamento e destinatari successivi per ogni categoria pertinente. Verificate se feedback facoltativi o processi di assistenza cambiano le condizioni.

Per i trattamenti soggetti al GDPR, l’articolo 28 richiede garanzie sufficienti del responsabile del trattamento e condizioni contrattuali adeguate. L’articolo 35 impone una DPIA quando il trattamento può presentare un rischio elevato per le persone. Questi obblighi dipendono dal trattamento, non dall’etichetta «IA». GDPR, articoli 28 e 35.

Affidate ai referenti privacy la valutazione di ruoli, base giuridica, informative e trasferimenti internazionali pertinenti. I responsabili tecnici confermano le impostazioni. Provate la cancellazione con dati campione autorizzati e documentate copie conservate o esclusioni. Un accordo di trattamento firmato e una configurazione verificata rispondono a domande diverse: conservateli entrambi.

4. Accettare una dichiarazione generica di conformità all’AI Act

La frase «conforme all’AI Act» richiede spiegazioni su ruolo, sistema, finalità, disposizioni e date di applicazione considerate. Fate documentare anche la vostra posizione. Le responsabilità del fornitore del modello non descrivono automaticamente quelle dell’azienda che integra il servizio.

Verificate classificazione e responsabilità nella catena del valore rispetto alla legislazione vigente, compresi gli articoli 3, 6 e 25. Esaminate separatamente pratiche vietate e requisiti di trasparenza. Chiedete una valutazione per singola disposizione quando marchio, modifiche o una nuova finalità possono incidere sull’analisi. AI Act, testo consolidato.

Secondo la verifica del 10 settembre 2026, il calendario modificato fissa le principali regole ad alto rischio dell’allegato III al 2 dicembre 2027 e quelle relative ai prodotti dell’allegato I al 2 agosto 2028. Queste proroghe non rinviano ogni obbligo. Registrate disposizioni e transizioni pertinenti al vostro uso. Commissione europea: entrata in vigore dell’omnibus sull’IA.

5. Testare una dimostrazione anziché il proprio processo

Una dimostrazione curata raramente include i vostri documenti problematici, istruzioni contraddittorie, lingue non supportate o limiti di autorizzazione. Definite i criteri di accettazione prima dei test. Usate materiale sintetico o altrimenti autorizzato che rappresenti il compito, inclusi casi in cui la risposta corretta sia rifiutare o coinvolgere un responsabile.

Per un assistente di recupero documentale, verificate se un utente può ottenere documenti non autorizzati. Per un agente, testate se contenuti non attendibili possono deviare le azioni e se i permessi limitano i danni. Includete input incompleti, errori plausibili e ripristino dopo interruzioni. Registrate versione del modello o servizio se disponibile, impostazioni, data e risultati.

Attribuite ai problemi gravi una conseguenza chiara: bloccare il lancio, eliminare la capacità, limitare il pilota o richiedere correzione e nuovi test. Una media qualitativa non deve nascondere un errore che espone informazioni di un altro cliente. Fate concordare al referente aziendale gli esiti inaccettabili prima di valutare le risposte riuscite.

6. Nominare un revisore umano senza rendere praticabile il controllo

«Human in the loop» non descrive un controllo completo. La persona deve avere informazioni, tempo, autorità e accesso sufficienti per contestare il risultato. Se un addetto deve approvare decine di suggerimenti in pochi secondi, un pulsante può offrire scarso controllo effettivo.

Specificate cosa controlla, quali fonti può consultare, come rifiuta un risultato e quando procede all’escalation. Provate il processo con suggerimenti errati. Confermate che la persona possa impedire un’azione prima dell’esecuzione e che l’alternativa non dipenda dallo stesso risultato inaffidabile.

Conservate prove dell’esercitazione e adattate personale o progettazione se il processo fallisce. Misurate correzioni ed errori ricorrenti per individuare problemi, evitando incentivi che scoraggino i rifiuti. Trattate la supervisione come parte del processo operativo, con un responsabile identificato.

7. Scollegare contratti, impostazioni e incidenti

Promesse commerciali, termini firmati e configurazione implementata possono descrivere accordi diversi. Confrontate il piano acquistato con impegni su uso consentito, riservatezza, conservazione, addestramento, cooperazione negli incidenti, cambiamenti e cessazione. Verificate diritti e limitazioni su input e risultati senza dedurne la proprietà dal marketing.

Per ogni promessa importante configurabile, registrate impostazione, responsabile e modalità di rilevamento delle modifiche. Per gli incidenti, identificate un contatto utilizzabile e le informazioni necessarie: servizi interessati, log pertinenti, cronologia, contenimento e seguito. Negoziate una collaborazione adeguata ai vostri obblighi e impegni verso i clienti.

Separate le preferenze commerciali dalle condizioni necessarie prima dell’accesso in produzione. Una condizione irrisolta sui dati non deve diventare un’attività ordinaria perché il lancio è vicino. Documentate eccezione accettata, motivazione, approvatore autorizzato e scadenza.

8. Lasciare che l’approvazione sopravviva ai suoi presupposti

La valutazione diventa obsoleta se uno strumento di scrittura inizia a inviare messaggi o un assistente in sola lettura ottiene diritti di scrittura. Il rinnovo contrattuale da solo è un cattivo evento di attivazione. Assegnate un responsabile per avvisi, incidenti, reclami, valutazioni fallite e ampliamenti d’uso.

Mantenete condizioni esplicite di riapertura e collegatele alla gestione delle modifiche tecniche. Conservate lo storico per capire quale configurazione è stata accettata e perché. Provate revoca delle credenziali, rimozione delle integrazioni, esportazione dei documenti necessari, richiesta di cancellazione e continuità del compito durante un’interruzione o l’uscita.

Il quadro volontario NIST AI RMF organizza il lavoro continuo in Govern, Map, Measure e Manage. Può strutturare il processo senza certificare la conformità giuridica. NIST AI RMF Core. Prove riutilizzabili riducono anche le duplicazioni descritte nell’articolo sulle valutazioni manuali dei fornitori.

Un processo per correggere un’approvazione esistente

Iniziate con un servizio di IA attivo che gestisca dati o permessi rilevanti. Verificate il processo su quel servizio prima di avviare questionari in tutta l’azienda.

1. Ricostruite l’ambito. Registrate compito, piano, dati, integrazioni, responsabili e permessi attuali. Confrontateli con l’approvazione iniziale.
2. Individuate i presupposti senza prove. Segnalate evidenze mancanti, controlli non testati, esclusioni immotivate e modifiche non esaminate.
3. Contenete le lacune sostanziali. Limitate dati o capacità mentre gli specialisti valutano. Ogni azione deve avere responsabile e termine.
4. Decidete esplicitamente. Approvate entro l’ambito, approvate con condizioni, limitate il pilota, procedete all’escalation o rifiutate. Indicate le condizioni che bloccano la produzione.
5. Programmate il seguito. Registrate prossima revisione e condizioni di riapertura. Verificate il completamento con prove anziché rassicurazioni verbali.

Mantenete un fascicolo sintetico con collegamenti alle prove, risultati, rischi residui, eccezioni accettate e nome dell’approvatore. Un collega deve capire la decisione senza ricostruire una catena di chat. Riutilizzate il fascicolo per clienti e investitori, con adeguati controlli di accesso.

Esempio: un assistente di supporto ottiene permessi di rimborso

Immaginate un team SaaS che abbia approvato un fornitore per preparare risposte da articoli pubblici. Tre mesi dopo, prodotto abilita il recupero di ticket privati e l’avvio di rimborsi. Il fornitore è lo stesso, ma cambiano entrambi i confini approvati di dati e azioni.

Il team dovrebbe riaprire la valutazione prima di attivare tali capacità. Potrebbe mantenere la redazione mentre verifica accesso ai ticket, conservazione dei log, autorizzazione dei rimborsi, abusi e ripristino. Un pilota limitato potrebbe usare ticket sintetici e rimborsi simulati finché le questioni aperte non sono risolte.

L’approvazione descriverebbe poi permessi accettati, prove dei test, controlli umani e restrizioni residue. Se fallisce il test di autorizzazione dei rimborsi, un buon punteggio di redazione non giustifica i pagamenti. L’esempio illustra un processo decisionale; non stabilisce che uno specifico uso di assistenza o pagamento sia giuridicamente consentito.

Domande frequenti

Qual è l’errore principale?

Trattare l’approvazione come una proprietà permanente del fornitore. Approvate un uso definito con prove, condizioni, responsabili e criteri di riapertura. Mantenete il fascicolo allineato all’implementazione.

Un piccolo fornitore va rifiutato automaticamente?

No. Valutate prove e rischi del servizio previsto. Possono essere accettabili prove alternative o un uso più ristretto. Registrate l’incertezza anziché sostituire la valutazione con dimensioni o reputazione.

Cosa dovrebbe documentare per primo un fondatore?

Compito reale, dati ammessi, autorizzazioni e responsabile. Questi fatti consentono a sicurezza, privacy, legale e prodotto di porre domande pertinenti anziché richiedere un pacchetto documentale generico.

Quando si può procedere nonostante informazioni mancanti?

Solo entro un ambito espressamente approvato con condizioni che affrontino la lacuna. Un pilota limitato può raccogliere prove, ma chiamarlo pilota non rende accettabili trattamenti sensibili o permessi ampi. Sottoponete i blocchi irrisolti a chi è autorizzato a decidere.

Fonti e credito fotografico

I riferimenti giuridici sono stati verificati il 10 settembre 2026. Le disposizioni GDPR collegate, l’AI Act consolidato, l’aggiornamento della Commissione e il quadro NIST sostengono i riferimenti specifici sopra indicati. Gli esempi operativi e il processo consigliato costituiscono indicazioni editoriali.

Foto: Team Meeting, woodleywonderworks, CC BY 2.0. Miniatura Wikimedia ridimensionata a 1280 × 482 pixel. Illustra collaborazione e non rappresenta una valutazione di un fornitore di IA.