Le 10 Domande che i VC Fanno sulla Compliance AI Act in Due Diligence

Fonti: Reg. UE 2024/1689 (AI Act) Artt. 4, 6, 26, 29 · IBA — Data Protection in M&A Transactions · EDPB — Guidelines on AI models and personal data · ACN — Guida AI Act per PMI e startup · AI Office UE — Orientamenti per Deployer

La due diligence su una startup AI nel 2026 non si conclude con l'analisi delle metriche di crescita, del cap table e dei contratti chiave. I general partner dei principali fondi VC che operano nel mercato europeo hanno integrato sistematicamente una sezione dedicata alla governance algoritmica, condotta da legali specializzati in tecnologia e privacy. Le domande che seguono riflettono il livello di dettaglio atteso: non sono domande teoriche, sono richieste documentali concrete con una risposta attesa in forma di evidenza. Per la roadmap completa di preparazione, si veda la guida all'investor readiness AI Act per startup. Per il quadro normativo di riferimento, si veda la guida alle architetture di compliance per SaaS e startup.

Le 10 domande standard della due diligence AI Act

1. Avete classificato tutti i sistemi AI presenti nel vostro prodotto secondo le categorie dell'AI Act?

Questa è la domanda d'apertura. Il legale del fondo chiede di vedere l'inventario architetturale AI: un documento che elenca ogni componente software basato su AI, indipendentemente dal fatto che sia sviluppato internamente o integrato tramite API di terze parti, e la classificazione del rischio associata (Rischio Inaccettabile, Alto Rischio, GPAI, Rischio Limitato, Rischio Minimo).

Risposta attesa: Un documento datato e firmato, non un foglio Excel improvvisato in risposta alla richiesta. Il fondo verifica che la classificazione sia motivata con riferimento all'Allegato III dell'AI Act e non sia una dichiarazione generica del tipo "i nostri sistemi sono a basso rischio".

Red flag: Impossibilità di fornire l'inventario, classificazioni prive di motivazione, o assenza di distinzione tra le diverse componenti del prodotto.

2. Avete funzionalità che potrebbero configurarsi come pratiche vietate dall'Art. 5?

Le pratiche vietate dall'Art. 5 dell'AI Act sono in vigore dal 2 febbraio 2025. Il fondo vuole accertare che il prodotto non includa, nemmeno in forma embrionale o disabilitata di default, sistemi di riconoscimento emotivo in ambienti lavorativi o educativi, sistemi di social scoring, o applicazioni di biometric categorization che traggano inferenze su caratteristiche protette.

Risposta attesa: Una dichiarazione documentata che nessuna funzionalità attiva o in roadmap ricade nelle categorie vietate, con analisi delle funzionalità di confine (ad esempio, sistemi di analisi del tono vocale nelle videochiamate, raccomandazioni comportamentali).

Red flag: Incertezza sulla risposta, o prodotti con funzionalità di analisi emotiva o comportamentale senza una valutazione legale formale.

3. Per i sistemi classificati ad alto rischio, avete condotto una DPIA integrata con la documentazione del Provider?

Per i sistemi AI che ricadono nell'Allegato III (selezione del personale, credit scoring, valutazione del rischio assicurativo, accesso a servizi pubblici), l'Art. 26, par. 9 dell'AI Act impone al Deployer di richiedere al Provider la documentazione tecnica necessaria per condurre la DPIA. Una DPIA condotta senza questa documentazione è incompleta e non supera la verifica.

Risposta attesa: La DPIA completa, con allegata o integrata la documentazione tecnica ricevuta dal fornitore del modello (o la corrispondenza che attesta la richiesta e la risposta del fornitore).

Red flag: DPIA assente per sistemi classificati ad alto rischio; DPIA condotta senza richiedere la documentazione al Provider; confusione tra DPIA GDPR e analisi interna del rischio tecnico.

4. Per i sistemi ad alto rischio che impattano su soggetti pubblici, soggetti finanziari o piattaforme molto grandi: avete condotto una FRIA?

La Fundamental Rights Impact Assessment (FRIA), prevista dall'Art. 29 dell'AI Act, è obbligatoria per specifiche categorie di Deployer: soggetti pubblici, banche, assicurazioni, piattaforme soggette al DSA. Se la startup fornisce sistemi AI classificati ad alto rischio a clienti che rientrano in queste categorie, il fondo verifica se la startup ha supportato i propri clienti nella conduzione della FRIA, fornendo loro la documentazione necessaria.

Risposta attesa: Evidenza che la startup conosce l'obbligo FRIA, sa identificare quali dei propri clienti vi sono soggetti, e ha predisposto pacchetti documentali di supporto. Per i dettagli sulla FRIA, si veda la guida alla FRIA nell'AI Act.

Red flag: Non sapere cosa sia la FRIA; confonderla con la DPIA; non aver informato i clienti obbligati.

5. I contratti con i vostri fornitori di modelli AI (OpenAI, Anthropic, Google, Azure) contengono DPA adeguati con clausole anti-addestramento?

Questa è la domanda che più frequentemente produce sorpresa nei fondatori. Il legale del fondo richiede di vedere i contratti effettivi, non le policy pubbliche dei provider. I punti di verifica includono: presenza di clausole esplicite che vietano l'uso dei dati della startup per l'addestramento del modello; Standard Contractual Clauses (SCC) per i trasferimenti extra-UE; Transfer Impact Assessment (TIA); elenco dei sub-responsabili con diritto di opposizione.

Risposta attesa: Contratti firmati o DPA specifici negoziati con i provider, non semplici accettazioni online dei termini di servizio standard.

Red flag: Utilizzo dei piani consumer o delle API senza DPA specifico; DPA generici senza clausole anti-addestramento; assenza di TIA per provider con server negli Stati Uniti.

6. Avete istituito una funzione formale di supervisione umana sui sistemi AI ad alto rischio?

L'Art. 26 dell'AI Act impone al Deployer di designare personale specifico responsabile della supervisione umana dei sistemi AI ad alto rischio. Questo non significa che un dipendente "dia un'occhiata agli output ogni tanto": la funzione deve essere documentata, il personale deve essere formato, e devono esistere procedure scritte per l'intervento, la correzione e l'interruzione del sistema.

Risposta attesa: Organigramma con il ruolo designato, job description con responsabilità di oversight, procedure operative scritte per l'intervento umano, evidenza di formazione specifica.

Red flag: Rispondere che "il team monitora i risultati in modo generale"; assenza di una designazione formale; nessuna procedura documentata per l'interruzione del sistema in caso di anomalia.

7. Avete un piano di AI Literacy per il personale, come richiesto dall'Art. 4?

L'Art. 4 dell'AI Act impone a Provider e Deployer di garantire che il personale che sviluppa, supervisiona e utilizza sistemi AI possieda un livello adeguato di alfabetizzazione sull'intelligenza artificiale. La scadenza era il 2 febbraio 2025. Un piano di AI Literacy non è un corso online da 30 minuti: è un programma documentato con obiettivi per ruolo, contenuti specifici, test di verifica e attestati.

Risposta attesa: Il piano formativo con cronogramma, gli attestati di completamento per i ruoli chiave, i materiali formativi o i riferimenti ai provider di formazione utilizzati.

Red flag: Assenza di documentazione formativa; formazione esistente ma non documentata; piano formativo generico senza distinzione tra profili tecnici e non tecnici.

8. Avete una procedura documentata per la notifica degli incidenti e il reporting alle autorità?

L'AI Act prevede obblighi di incident reporting verso l'autorità nazionale competente (ACN in Italia per i profili AI Act) in caso di incidenti gravi che coinvolgano sistemi ad alto rischio. Il GDPR prevede la notifica al Garante entro 72 ore per i data breach. Il fondo verifica che la startup abbia procedure operative scritte che integrino entrambi i regimi.

Risposta attesa: Una SOP (Standard Operating Procedure) per l'incident response con threshold di attivazione, catena di escalation, template di notifica e referenti interni ed esterni.

Red flag: Assenza di procedure scritte; procedure che non integrano AI Act e GDPR; nessuna evidenza che il team conosca i referenti istituzionali (ACN, Garante Privacy).

9. I vostri clienti enterprise hanno firmato DPA aggiornati che riflettono l'uso di AI nel prodotto?

I DPA firmati con i clienti prima dell'entrata in vigore dell'AI Act molto probabilmente non contemplano le elaborazioni AI. I clienti enterprise, a loro volta, stanno conducendo vendor assessment sulla conformità AI Act dei loro fornitori tecnologici. Un DPA non aggiornato espone la startup a richieste di rinegoziazione in corso di due diligence e a potenziali contestazioni contrattuali.

Risposta attesa: I template DPA aggiornati, con sezioni specifiche sulle elaborazioni AI, le garanzie sul modello utilizzato, le clausole anti-addestramento nei confronti dei clienti, e la lista dei clienti che hanno già firmato la versione aggiornata.

Red flag: DPA non aggiornati con l'entrata in vigore dell'AI Act; assenza di clausole specifiche sulle elaborazioni AI; clienti enterprise non informati dell'uso di modelli di terze parti nel prodotto.

10. Avete documentazione sui dati di addestramento dei modelli che avete sviluppato internamente, incluse licenze e base giuridica?

Per le startup che sviluppano modelli proprietari (anche fine-tuned), il fondo verifica la provenienza dei dati di addestramento: sono stati raccolti con base giuridica GDPR valida? Le licenze copyright dei dataset pubblici sono compatibili con l'uso commerciale? Esistono contestazioni o rivendicazioni di diritti da parte di terzi?

Risposta attesa: Documentazione della pipeline di raccolta dati di addestramento, con base giuridica identificata per ciascuna fonte, licenze verificate, e, dove applicabile, accordi di licenza specifici con i proprietari dei dataset.

Red flag: Dataset raccolti senza verifica della base giuridica; utilizzo di dati di scraping web senza valutazione delle licenze; assenza di documentazione sulla provenienza dei dati.

Come prepararsi prima dell'apertura del round

Le dieci domande riportate non sono una lista esaustiva, ma rappresentano lo scheletro di ogni due diligence AI Act condotta da un fondo europeo strutturato. La preparazione ottimale prevede un audit interno di pre-due diligence a tre mesi dall'apertura del round, condotto da un consulente legale specializzato che simuli le verifiche del legale del fondo.

La coerenza interna tra i documenti è fondamentale: una classificazione del rischio che indica "rischio limitato" per un sistema che poi risulta oggetto di DPIA (riservata ai trattamenti ad alto rischio) è una contraddizione che il legale del fondo rileva in pochi minuti e che non ha spiegazioni credibili.

Articolo aggiornato al 26 maggio 2026. Le domande riportate riflettono le prassi di due diligence osservate nel mercato VC europeo e le disposizioni dell'AI Act in vigore. Per supporto specifico, contatta lo studio.