L'AI Act è il regolamento europeo (UE) 2024/1689, in vigore dal 1° agosto 2024, che stabilisce regole armonizzate sull'intelligenza artificiale nell'Unione. Non regola il codice che scrivi: regola i sistemi di IA che qualcuno, tu o il tuo cliente, mette sul mercato o usa.
Se lavori in una software house e usi un assistente come Claude Code, Cursor o Copilot per scrivere software per un cliente, prima o poi qualcuno ti chiede se l'AI Act ti riguarda. Nella maggior parte dei casi la risposta onesta è che non cambia niente dal punto di vista normativo, e vale comunque la pena scriverla, perché quasi nessuno lo fa: le pagine che si posizionano su questa ricerca spiegano il regolamento, non cosa significa per chi consegna codice a un cliente.
Cosa regola l'AI Act, e cosa lascia fuori?
Il regolamento (UE) 2024/1689 classifica i sistemi di intelligenza artificiale per livello di rischio e impone obblighi diversi a chi li sviluppa (il fornitore, o provider) e a chi li usa (l'utilizzatore, o deployer). Alcune pratiche sono vietate dal 2 febbraio 2025. I modelli di IA per finalità generali, i cosiddetti GPAI, come i modelli dietro Claude o GPT, hanno obblighi propri dal 2 agosto 2025, a carico di chi li sviluppa, non di chi li usa. Gli obblighi di trasparenza, dichiarare quando un contenuto è generato o modificato dall'IA, valgono dal 2 agosto 2026. Gli obblighi più pesanti, quelli sui sistemi ad alto rischio (selezione del personale, scoring creditizio, infrastrutture critiche), sono stati appena spostati in avanti dal Digital Omnibus, in vigore dal 27 luglio 2026: al 2 dicembre 2027 per i sistemi autonomi, al 2 agosto 2028 per quelli incorporati in prodotti già regolamentati. In nessuna di queste date il regolamento dice qualcosa su come il codice è stato scritto.
Usare un assistente IA per scrivere codice cambia la tua posizione?
Quando apri Claude Code, Cursor o Copilot per scrivere software per un cliente, sotto l'AI Act sei al massimo utilizzatore (deployer) di quello strumento: lo usi sotto la tua autorità, in un contesto professionale. Il fornitore del sistema di IA, cioè chi lo sviluppa e lo mette sul mercato con il proprio nome, è Anthropic, Cursor o Microsoft, non tu. Essere deployer di un assistente comporta un obbligo reale ma minimo: dal 2 febbraio 2025 devi garantire un livello adeguato di alfabetizzazione sull'IA a chi lo usa in azienda, cioè che chi lavora con lo strumento ne capisca capacità e limiti concreti, non un corso certificato. Quello che l'uso dello strumento non fa, da solo, è renderti fornitore di un sistema di intelligenza artificiale. Lo diventi solo se il software che consegni è, o contiene, un sistema di IA che tu metti sul mercato con il tuo nome: una web app gestionale scritta da un agente resta una web app gestionale, non un sistema di IA, a meno che non lo sia già per conto suo.
Fornitore o deployer: perché la differenza conta davvero?
La domanda che decide il tuo ruolo non è quale strumento hai usato per scrivere il codice, è cosa consegni. Se il prodotto del cliente ha funzioni di IA proprie, un chatbot, uno scoring, un motore di raccomandazione, e lo consegni sotto il marchio del cliente, di norma è il cliente il fornitore di quel sistema. Se invece vendi un prodotto con funzioni di IA sotto il tuo marchio a più clienti, tipicamente un SaaS con una feature IA integrata, sei tu il fornitore di quel sistema specifico, con gli obblighi e le scadenze che ne derivano, indipendentemente da come è stato costruito. Il regolamento prevede anche che chi appone il proprio marchio su un sistema di IA già esistente, o lo modifica in modo sostanziale, ne erediti gli obblighi da fornitore: un caso che riguarda cosa fai col prodotto finito, non lo strumento con cui lo hai scritto.
Cosa ti chiederà comunque il cliente, a prescindere dalla norma
Anche quando l'AI Act non si applica a te, il cliente prudente fa domande che assomigliano molto a quelle della compliance, perché vuole una risposta prima che gliela chieda qualcun altro.
| Area | Cosa tende a chiedere il cliente | Cosa serve per rispondere |
|---|---|---|
| Provenienza del codice | Quanto del codice è stato scritto da un agente e quanto da una persona | Un registro di cosa ha prodotto l'agente e cosa ha scritto o modificato una persona |
| Revisione umana | Conferma che qualcuno ha controllato prima del merge in produzione | Un'approvazione collegata al commit, non solo la dichiarazione che è stata fatta |
| Ruolo nell'AI Act | Se il prodotto ha funzioni di IA, chi ne è il fornitore secondo il regolamento | Una clausola contrattuale che lo chiarisce, prima che serva |
| Tracciabilità delle modifiche | Chi ha autorizzato cosa, e quando | Un record firmabile, non un messaggio di commit |
Gli ultimi due punti non dipendono da quanto l'AI Act ti riguardi in senso stretto: dipendono da quanto puoi dimostrare, mesi dopo, di aver saputo cosa stava succedendo mentre succedeva. È la stessa domanda che si pone quando una sessione vibe-coded finisce dritta in produzione: il cliente non chiede la conformità a una norma, chiede la prova.
Cosa conviene mettere per iscritto adesso?
Tre cose, indipendenti dal fatto che l'AI Act ti tocchi o no. Primo, documenta che il tuo team ha un livello adeguato di alfabetizzazione sugli strumenti IA che usa: è già un obbligo dal 2 febbraio 2025, e una policy scritta di una pagina vale più di un corso fatto una volta. Secondo, chiarisci per contratto chi è il fornitore se il prodotto consegnato ha funzioni di IA proprie: è una frase, non un capitolo, e toglie un'ambiguità che altrimenti resta aperta fino a quando qualcuno la contesta. Terzo, tieni un registro di cosa un agente ha scritto e cosa una persona ha rivisto: non perché l'AI Act te lo chieda quasi mai direttamente, ma perché è la stessa prova che ti serve per il cliente, per l'assicurazione e per te stesso, il giorno che qualcosa va storto e devi ricostruire in fretta cosa è successo davvero.
Non serve promettere conformità all'AI Act come se fosse una funzione del prodotto: nella maggior parte dei casi, per una software house, semplicemente non si applica. Serve poter rispondere a chi ha scritto, chi ha approvato e chi si è preso la responsabilità di ogni consegna. Detent, l'impianto di delivery end-to-end (detent-ai.com), tiene insieme intento, contesto autorizzato, esecuzione e firma umana dal segnale al rilascio: è il tipo di registro che rende quella domanda una risposta di cinque minuti, non una ricostruzione a memoria.