AI Act europeo per startup: cosa devono sapere i founder

Il Regolamento europeo sull'AI e il primo quadro giuridico completo al mondo sull'intelligenza artificiale. Crea obblighi basati sul livello di rischio di un sistema AI, non sulle dimensioni dell'azienda che lo costruisce. Una startup di cinque persone che distribuisce uno strumento AI per le assunzioni ha la stessa classificazione di una grande azienda che distribuisce lo stesso tipo di sistema. L'entita degli obblighi amministrativi differisce, ma i requisiti sostanziali no.

Vale la pena dirlo chiaramente perche un'idea sbagliata comune tra i founder in fase iniziale e che la regolamentazione sia un problema delle grandi aziende. Non e cosi. Cio che e vero e che il Regolamento include disposizioni specifiche per ridurre il carico amministrativo sulle PMI, tra cui l'accesso a sandbox regolatori e tariffe ridotte. Ma quelle disposizioni esistono all'interno dello stesso framework che si applica a tutti.

La buona notizia e che il framework e basato sul rischio e proporzionato. La maggior parte dei prodotti AI costruiti dalle startup oggi non rientra nelle categorie che attivano gli obblighi piu pesanti. Capire la struttura e la maggior parte del lavoro.

I quattro livelli di rischio

Il Regolamento organizza i sistemi AI in quattro categorie. Dove si colloca il tuo prodotto determina tutto il resto.

La domanda che determina i tuoi obblighi: provider o deployer?

Prima della classificazione, c'e una domanda preliminare. Sei un provider o un deployer?

Un provider e un'organizzazione che sviluppa un sistema AI e lo mette sul mercato o lo mette in servizio, sia in vendita che gratuitamente. Sei un provider se costruisci e distribuisci un sistema AI che altre aziende o consumatori usano direttamente.

Un deployer e un'organizzazione che usa un sistema AI sviluppato da terzi all'interno dei propri prodotti o operazioni. Se costruisci un prodotto sopra le API di OpenAI, Claude di Anthropic, Gemini di Google o qualsiasi altro modello fondazionale senza modificare sostanzialmente il modello sottostante, sei un deployer per quel modello e un provider per il tuo livello applicativo.

Questa distinzione conta enormemente. I provider portano gli obblighi piu pesanti per i sistemi ad alto rischio: valutazioni di conformita prima del deployment, registrazione nel database UE dei sistemi AI ad alto rischio, documentazione tecnica, segnalazione degli incidenti e monitoraggio post-mercato continuo. I deployer hanno un insieme piu leggero di obblighi, focalizzati sull'uso appropriato e sulla garanzia di supervisione umana.

L'alto rischio in pratica: la lista che i founder devono verificare

L'Allegato III del Regolamento elenca i casi d'uso ad alto rischio. Il pattern da riconoscere per i founder e questo: se il tuo prodotto AI prende decisioni o influenza significativamente decisioni su singole persone in uno dei seguenti ambiti, assumi alto rischio fino a quando non hai una specifica motivazione legale contraria.

• Assunzioni e lavoro: screening dei CV, ranking dei candidati, analisi dei colloqui, valutazione delle performance, decisioni di promozione, allocazione dei compiti, monitoraggio dei lavoratori. Questa e l'area in cui la maggior parte delle startup HR-tech AI ha bisogno di un'analisi attenta.
• Educazione: valutazione automatizzata degli studenti, scoring degli esami, sistemi di proctoring che prendono o influenzano decisioni di ammissione.
• Credito e servizi finanziari: valutazione del merito creditizio, credit scoring, classificazione del rischio assicurativo.
• Accesso a servizi essenziali: AI usata da autorita pubbliche o soggetti privati che forniscono servizi essenziali per determinare l'idoneita o la priorita.
• Salute: AI usata come dispositivo medico o nel supporto decisionale clinico che influenza diagnosi o scelte terapeutiche.
• Identificazione biometrica: sistemi che categorizzano persone in base a dati biometrici, sistemi di identificazione biometrica remota.

Nota che questa lista e definita per caso d'uso, non per tecnologia. Un LLM usato per riassumere documenti interni non e ad alto rischio. Lo stesso LLM usato come strumento di selezione che classifica i candidati e alimenta decisioni di assunzione e ad alto rischio. La tecnologia e identica. Il contesto applicativo e cio che conta.

La timeline: cosa si applica adesso

Il Regolamento ha un calendario di implementazione graduale.

La scadenza di agosto 2027 per i sistemi dell'Allegato III e la piu rilevante per la maggior parte delle startup software. Questo non significa aspettare fino al 2027. I prodotti attualmente in sviluppo che saranno sul mercato entro il 2027 devono essere progettati per la conformita dalla fase di architettura. Integrare i requisiti di conformita dopo che il prodotto e costruito e significativamente piu costoso che progettarli dall'inizio.

Cosa controllano gia i valutatori dei bandi europei

Questa e la sezione che conta di piu se stai preparando una proposta EIC Accelerator o Horizon Europe che riguarda l'AI.

Dal 2025, i valutatori di entrambi i programmi sono stati formati per verificare se le proposte relative all'AI dimostrano che il team ha compreso l'ambiente regolatorio in cui opererebbe il loro prodotto. Una proposta che presenta uno strumento AI per le assunzioni o un prodotto AI di supporto alla decisione clinica senza alcun riferimento alla conformita all'AI Act e sempre piu vista come un segnale di analisi incompleta della market readiness, indipendentemente dalla qualita tecnica della tecnologia sottostante.

Cio che i valutatori vogliono vedere non e un documento di conformita legale. Vogliono vedere che il team fondatore ha fatto il lavoro di classificazione di base, sa in quale livello si colloca il suo prodotto, capisce quali obblighi si applicano alla data di go-to-market prevista, e ha un piano credibile per affrontarli. Due paragrafi che dimostrano questo chiaramente valgono piu di un lungo allegato.

Cosa fare nei prossimi 90 giorni

Il punto di partenza pratico e un esercizio di classificazione, non una consulenza legale. Prima di coinvolgere un consulente esterno, il team fondatore dovrebbe essere in grado di rispondere chiaramente a tre domande: in quale livello si colloca il nostro prodotto, siamo provider o deployer per ciascun componente del nostro sistema, e qual e la base fattuale per la nostra classificazione del livello.

Per la maggior parte delle startup, questo lavoro richiede uno o due giorni e produce un documento di una o due pagine che diventa la base per tutto il resto. Se la classificazione e rischio limitato o rischio minimo, le azioni successive sono semplici: implementare le divulgazioni di trasparenza, documentare la motivazione della classificazione, e rivedere il documento annualmente con l'evoluzione del prodotto.

Se la classificazione e alto rischio, le azioni successive sono piu sostanziali ma del tutto gestibili se iniziate durante lo sviluppo piuttosto che dopo il lancio. Le decisioni architetturali chiave da prendere presto sono: come funziona il sistema di logging, dove si trova la supervisione umana nel flusso del prodotto, cosa copre la documentazione tecnica, e come si gestira la valutazione di conformita. Nessuna di queste richiede che il prodotto sia costruito prima di essere decisa. Sono decisioni di design che dovrebbero avvenire parallelamente alle decisioni di prodotto.