Come valutare un fornitore che sviluppa con AI: guida alla due diligence tecnica

Sempre più fornitori dichiarano di usare AI per sviluppare software più velocemente: coding assistant, agenti, generatori di test, strumenti di review, automazioni di pipeline. Per chi acquista software, questa informazione non è di per sé negativa — può essere un vantaggio reale se il fornitore controlla bene dati, codice, dipendenze, test e delivery.

Il rischio nasce quando “usiamo AI” diventa una promessa commerciale senza evidenze. Procurement, CTO, CISO e legal devono chiedere prove: quali strumenti sono usati, quali dati entrano nel processo, quali controlli verificano il codice e cosa succede se emerge una vulnerabilità. La due diligence non deve bloccare il fornitore: deve separare chi usa AI in modo governato da chi ha semplicemente accelerato lo sviluppo spostando il rischio sul cliente.

La domanda giusta non è “usate AI?”

Chiedere solo se il fornitore usa AI produce una risposta poco utile. La domanda corretta è: in quali fasi del ciclo di sviluppo viene usata l’AI e con quali controlli? Gli ambiti possono essere molto diversi tra loro — dalla generazione di codice applicativo al refactoring, dalla scrittura di test all’analisi di log e bug report, dalla generazione di pipeline e IaC al suggerimento di dipendenze, fino alla code review assistita, alla documentazione e agli agenti che aprono pull request o eseguono comandi.

Ogni uso ha un profilo di rischio diverso. Un assistente che suggerisce testo per la documentazione non equivale a un agente che modifica autorizzazioni, query, pipeline e dipendenze: trattarli allo stesso modo significa sottovalutare i rischi reali.

Quali dati del cliente entrano negli strumenti AI?

La prima area di due diligence riguarda il data handling. Il fornitore può aver bisogno di log, ticket, repository, dump, payload, screenshot o documentazione per risolvere problemi. Se questi elementi entrano in prompt, chat, agenti o tool non autorizzati, il cliente perde controllo su dati e segreti.

Le domande da fare riguardano se il fornitore può inserire codice cliente nei tool AI, se può inserire log, ticket, dati personali o dati di produzione, se usa account enterprise o account personali, se esistono regole di redaction, se i prompt o transcript sono conservati, se i dati sono usati per training o miglioramento del servizio e se esistono restrizioni contrattuali su subfornitori e tool. La risposta deve essere documentata, non affidata a rassicurazioni verbali.

Quali controlli esistono sulle PR generate o assistite da AI?

Il cliente non deve chiedere ogni dettaglio operativo, ma deve capire se il codice AI-generated viene accettato alla cieca. Le evidenze utili includono la policy interna del fornitore sull’AI coding, la presenza di branch protection e review obbligatorie, esempi di flusso PR, CODEOWNERS o reviewer per aree sensibili, tracciabilità di commit e release, report di Code Review e criteri di blocco merge.

Le aree che richiedono review forte sono auth, autorizzazioni, API, query, dati, pagamenti, segreti, dipendenze, pipeline, cloud e logica di business. Se il fornitore non sa spiegare come le controlla, il rischio resta al cliente.

Test, scanner e remediation: quali prove esistono?

Un fornitore può dichiarare di usare SAST, SCA, secret scanning e test automatici. La domanda successiva è cosa succede ai finding: quali scanner vengono eseguiti e quando, quali severità bloccano la release, chi fa triage, come sono gestite false positive e deroghe, quali test negativi coprono ruoli, tenant, input e abuso, come viene verificato un fix e quali report vengono condivisi con il cliente.

Scanner e test non sostituiscono una verifica indipendente, ma sono segnale di processo. Se il fornitore non produce report o non ha SLA di remediation, i controlli rischiano di essere solo formali.

Dipendenze, licenze e supply chain

L’AI può suggerire librerie, plugin, action, container base image e tool di build. Per il cliente, questo impatta vulnerabilità, licenze, manutenzione, audit e lock-in. Le evidenze da chiedere comprendono l’elenco delle dipendenze principali, la Software Composition Analysis, il license report, l’SBOM quando il perimetro lo richiede, la policy sulle nuove dipendenze, il pinning di versioni e action, la gestione CVE e la provenienza e integrità degli artifact.

Una dipendenza può essere tecnicamente comoda ma non accettabile per policy cliente. Questo va scoperto prima della consegna, non durante un audit.

Segreti, ambienti e accessi

La due diligence deve verificare come il fornitore gestisce credenziali, ambienti e dati di test. I punti da chiarire riguardano l’uso di dati sintetici o reali, la protezione di file di configurazione, chiavi API, token cloud e webhook secret, se le credenziali sono personali o nominative di progetto, la separazione tra staging e produzione, chi può accedere agli ambienti cliente, la presenza di log di accesso e revoca e cosa succede quando un collaboratore lascia il progetto.

Se una chiave cliente finisce in prompt, log o repository, il contratto deve prevedere notifica, rotazione, analisi dell’impatto e responsabilità chiare.

Clausole tecniche da inserire o verificare

Le clausole generiche sulle “best practice” non bastano. Per fornitori che sviluppano con AI servono requisiti più concreti, che coprano gli strumenti AI consentiti e i subfornitori, il divieto o i limiti su dati cliente nei prompt, l’obbligo di account aziendali con controlli enterprise, la segregazione tra clienti, la review umana su aree sensibili, scanning e test minimi, la gestione di dipendenze e licenze, la disclosure di vulnerabilità e incidenti, gli SLA di remediation, il diritto di audit o verifica indipendente e la consegna di report, SBOM o evidenze quando richiesto.

Legal e procurement non devono scrivere controlli tecnici da soli: devono tradurre requisiti tecnici in obblighi verificabili.

Quando serve una verifica indipendente

La due diligence documentale è utile, ma non sempre sufficiente. Se il software è critico, esposto, multi-tenant, integrato con sistemi aziendali o tratta dati reali, serve una verifica tecnica che vada oltre la documentazione fornita dal fornitore stesso.

La verifica indipendente può includere una Code Review su codice consegnato, auth, API, segreti, dipendenze e pipeline; un Web Application Penetration Testing su app o API esposte; e una verifica di processo con il Software Assurance Lifecycle se il fornitore lavora in modo continuativo. Il punto non è duplicare tutto il lavoro del fornitore, ma verificare i punti in cui un errore avrebbe impatto diretto sul cliente.

Checklist di domande per il fornitore

• Quali strumenti AI usate nello sviluppo?
• In quali fasi: codice, test, review, pipeline, documentazione?
• Quali dati del cliente possono entrare nei prompt o nel contesto?
• Usate account enterprise, SSO, MFA e logging?
• Il codice o i prompt possono essere usati per training o miglioramento del servizio?
• Come segregate clienti, repository, workspace e ambienti?
• Quali controlli bloccano merge e release?
• Quali aree richiedono review umana obbligatoria?
• Quali scanner eseguite e quali report condividete?
• Come gestite dipendenze, licenze, SBOM e CVE?
• Come proteggete segreti e credenziali cliente?
• Quali SLA avete per remediation e retest?
• Accettate verifica indipendente prima del go-live o dell’accettazione finale?

Segnali di allarme

• Il fornitore parla solo di produttività, non di controlli.
• Non sa dire quali strumenti AI usa.
• Usa account personali o piani free su codice cliente.
• Non ha regole su dati e prompt.
• Non produce evidenze di review, test o scanner.
• Non distingue tra codice generato e codice revisionato.
• Non controlla licenze e dipendenze.
• Non accetta verifiche indipendenti su perimetri critici.
• Non ha SLA di remediation.
• Non sa chi è responsabile in caso di vulnerabilità.

Quando coinvolgere ISGroup

ISGroup può supportare la due diligence tecnica prima della firma, durante l’accettazione di una release o prima del go-live. La verifica migliore è proporzionata: non serve lo stesso livello di controllo per un tool interno a basso rischio e per una piattaforma esposta con dati personali, ruoli e API.

Scenario	Rischio principale	Controllo consigliato
Codice consegnato o PR critiche	Vulnerabilità o regressioni nel codice	Code Review
Web app o API esposte	Abuso applicativo dall’esterno	Web Application Penetration Testing
Fornitore continuativo o sviluppo ricorrente	Processo non verificabile nel tempo	Software Assurance Lifecycle

FAQ

• È rischioso scegliere un fornitore che usa AI?
• Non necessariamente. È rischioso scegliere un fornitore che usa AI senza policy, evidenze, review, test, gestione dati e responsabilità chiare.
• Devo chiedere di vedere tutti i prompt?
• Non sempre. I prompt possono contenere informazioni sensibili del fornitore stesso. Di solito sono più utili policy, report di review, scanner, test, SBOM, finding corretti, clausole contrattuali e diritto di audit.
• Quale documento chiedere per primo?
• Una policy o descrizione del processo di AI coding del fornitore: strumenti usati, dati vietati, review obbligatorie, controlli tecnici, gestione dipendenze e SLA di remediation.
• Quando serve una Code Review indipendente?
• Quando il codice consegnato tocca auth, API, dati, segreti, query, dipendenze, pipeline, cloud o logica di business critica.
• Quando serve un Web Application Penetration Testing?
• Quando l’app o l’API è esposta a utenti, clienti, partner o internet e gestisce dati reali, ruoli, upload, pagamenti o integrazioni.

Fonti e riferimenti

• NIST SP 800-218 SSDF
• NIST AI Risk Management Framework
• OWASP SAMM
• OWASP ASVS
• OWASP Code Review Guide
• SLSA