AI Act e agenti AI: cosa deve fare chi li mette in produzione

Cos'è l'AI Act e a chi si applica

Il regolamento (UE) 2024/1689, pubblicato in Gazzetta ufficiale dell'Unione il 12 luglio 2024, è il primo quadro normativo orizzontale sull'intelligenza artificiale. Non regola la tecnologia in sé: regola gli usi. Lo stesso modello può essere libero da obblighi in un contesto e sottoposto a requisiti pesanti in un altro. È il punto che molte sintesi mancano, ed è quello da cui partire.

I due ruoli che contano sono il fornitore, chi sviluppa un sistema di AI e lo immette sul mercato con il proprio nome o marchio, e il deployer, chi utilizza un sistema di AI sotto la propria autorità in un'attività professionale. Il testo italiano del regolamento usa proprio la parola inglese deployer, senza tradurla. Chi costruisce con CrewAI un prodotto che i clienti usano è fornitore; chi usa quel prodotto in azienda è deployer; una software house che sviluppa e gestisce il sistema per un cliente può trovarsi in entrambi i ruoli, e conviene chiarirlo per iscritto nel contratto.

In Italia il regolamento è accompagnato dalla legge 23 settembre 2025, n. 132, che all'articolo 20 designa AgID e ACN come autorità nazionali per l'intelligenza artificiale: ad AgID le procedure di notifica e accreditamento degli organismi di valutazione, ad ACN la vigilanza sul mercato con poteri ispettivi e sanzionatori.

Il calendario, ad agosto 2026

L'applicazione è scaglionata, e il calendario è cambiato in corsa: il regolamento (UE) 2026/1744 (il pacchetto di semplificazione noto come omnibus digitale, in vigore dal luglio 2026) ha rinviato le scadenze per i sistemi ad alto rischio. Gli obblighi di trasparenza non sono stati toccati.

Tradotto: se oggi metti in produzione un sistema ad agenti, gli obblighi che ti riguardano subito sono i divieti e la trasparenza. Quelli dell'alto rischio arrivano fra il 2027 e il 2028, ma definiscono già la direzione in cui conviene progettare.

Dove si colloca un sistema ad agenti

Nel regolamento non esiste la categoria "sistema ad agenti". Non c'è un articolo sui crew, sull'orchestrazione o sui sistemi multi agente: la classificazione dipende da cosa fa il sistema e su chi produce effetti, non da come è costruito. I livelli sono quattro.

• Pratiche vietate (articolo 5): manipolazione dannosa, social scoring, scraping non mirato di immagini facciali, riconoscimento delle emozioni sul luogo di lavoro. Vietate per chiunque, dal febbraio 2025.
• Alto rischio (articolo 6 e allegato III): sistemi che incidono su salute, sicurezza o diritti fondamentali. Fra i domini: selezione del personale, istruzione, accesso a servizi essenziali come il credito, infrastrutture critiche. Requisiti pieni: gestione del rischio, qualità dei dati, log, documentazione, sorveglianza umana.
• Obblighi di trasparenza (articolo 50): sistemi che interagiscono con persone o generano contenuti. Nessun requisito di certificazione, ma obblighi precisi di informazione e marcatura.
• Rischio minimo: tutto il resto, cioè la grande maggioranza dei sistemi. Nessun obbligo specifico.

Per collocare un caso concreto le domande sono tre: cosa decide o produce il sistema, su chi ricadono gli effetti, in quale dominio opera. Un crew che riassume documentazione interna è rischio minimo. Lo stesso crew che risponde ai clienti ricade nella trasparenza. Un crew che filtra curriculum e scarta candidati rientra nell'allegato III, ed è alto rischio: non perché usa agenti, ma perché decide sull'accesso al lavoro. Se il tuo caso sfiora un dominio dell'allegato III, è il momento di coinvolgere un legale, non di interpretare da soli.

Gli obblighi di trasparenza applicati agli agenti

L'articolo 50 è la parte del regolamento che tocca quasi ogni sistema ad agenti in produzione oggi, ed è operativo dal 2 agosto 2026. Tre obblighi interessano chi costruisce.

Chi interagisce deve saperlo. Un sistema di AI destinato a interagire direttamente con persone fisiche va progettato in modo che le persone siano informate di stare interagendo con un'AI, a meno che ciò non risulti evidente dal contesto. Per un agente che risponde a clienti significa una dichiarazione chiara nell'interfaccia, non una riga nelle condizioni d'uso. L'obbligo è del fornitore, in fase di progettazione: è una scelta di prodotto, non un adempimento a valle.

I contenuti generati vanno marcati. Chi fornisce un sistema che genera testo, audio, immagini o video deve fare in modo che gli output siano marcati in un formato leggibile meccanicamente e rilevabili come generati artificialmente. Gli standard tecnici su come marcare sono ancora in definizione, e questo è un punto onesto da ammettere: oggi si può predisporre la marcatura a livello di metadati e documentare la scelta, sapendo che la prassi si sta formando.

Chi pubblica dichiara. Il deployer che usa un sistema per generare testi pubblicati per informare il pubblico su questioni di interesse pubblico deve dichiarare che il contenuto è generato artificialmente, salvo revisione editoriale con responsabilità umana sul contenuto. Per i deep fake la dichiarazione è sempre dovuta. Se i tuoi agenti scrivono articoli o comunicazioni pubbliche, il processo di revisione umana non è solo una buona pratica: è ciò che cambia il tuo obbligo.

Cosa fare in pratica, in produzione

Questa è la parte che gli studi legali non scrivono, perché non è nel loro mestiere. I requisiti che il regolamento codifica per l'alto rischio, agli articoli 12, 14 e 26, descrivono proprietà tecniche precise: registrazione degli eventi, sorveglianza umana effettiva, controllo sui dati di input. Anche quando non sono vincolanti per il tuo caso, sono la griglia giusta per progettare. Punto per punto, con gli agganci in CrewAI.

Registrare le esecuzioni e conservare i log

L'articolo 12 chiede che i sistemi ad alto rischio consentano la registrazione automatica degli eventi per tutto il ciclo di vita; l'articolo 26 impone al deployer di conservare i log generati per almeno sei mesi. In CrewAI il punto di partenza è output_log_file sul crew, che scrive su file il log dell'esecuzione, in JSON se il nome finisce in .json. Il framework produce il log; la conservazione, la protezione e la rotazione sono lavoro tuo, sul filesystem o su uno storage dedicato.

Tracciare quale modello ha prodotto cosa

Un log senza contesto non ricostruisce niente. Per ogni esecuzione serve poter dire quale modello, in quale versione, con quale configurazione ha prodotto quell'output. In CrewAI il modello è dichiarato per agente nel parametro llm: usa identificatori di versione espliciti, non alias generici che il fornitore aggiorna sotto di te. L'oggetto restituito da kickoff() include token_usage, e il crew espone usage_metrics: vanno nel registro insieme a data, versione del codice e input. Per la riproducibilità dei percorsi, i Flows aggiungono uno stato ispezionabile con identificatore univoco e la persistenza con @persist: la stessa esecuzione si può riprendere e ricostruire passo per passo.

Sorveglianza umana e punti di interruzione

L'articolo 14 chiede che le persone incaricate possano decidere di non usare l'output, intervenire o arrestare il sistema; l'articolo 26 chiede che siano persone con competenza, formazione e autorità. In CrewAI il punto di aggancio è human_input=True sul task: l'esecuzione si ferma e attende la revisione umana prima di proseguire. I guardrail aggiungono validazione automatica con rinvio all'agente in caso di esito negativo, e max_iter mette un tetto ai cicli. Il punto organizzativo resta fuori dal codice: qualcuno deve avere il compito, il tempo e l'autorità di fermare il sistema, altrimenti la revisione è un timbro.

Governare i dati di input

L'articolo 26 chiede al deployer, nella misura in cui controlla i dati di input, di garantire che siano pertinenti e sufficientemente rappresentativi rispetto alla finalità. Per un crew significa validare cosa entra prima del kickoff: quali documenti, quali campi, con quali dati personali dentro. Meno dati entrano, meno superficie di rischio hai. L'esecuzione in locale riduce il perimetro alla radice, perché i dati non lasciano la tua infrastruttura; non chiude ogni questione, ma elimina la più spinosa.

Documentare le scelte

Per l'alto rischio la documentazione tecnica è un obbligo formale. Per tutti gli altri è la cosa che distingue chi può rispondere a una domanda dell'autorità da chi deve ricostruire a memoria: quale modello e perché, quali test prima del rilascio, cosa fa il sistema in caso di errore, chi supervisiona. Un file di decisioni nel repository, datato, è sufficiente. L'assenza di quel file non lo è.

from crewai import Agent, Task, Crew, Process

redattore = Agent(
    role="Redattore risposte clienti",
    goal="Rispondere al ticket con dati verificati",
    backstory="Se un dato non è certo, lo segnala e si ferma.",
    llm="gpt-5.4-mini",       # modello e versione vanno nel registro
    max_iter=6,
)

risposta = Task(
    description="Prepara la risposta al ticket {ticket}.",
    expected_output="Bozza pronta per revisione, con fonti interne.",
    agent=redattore,
    human_input=True,      # revisione umana prima di chiudere
)

crew = Crew(
    agents=[redattore],
    tasks=[risposta],
    process=Process.sequential,
    output_log_file="audit/esecuzioni.json",  # log da conservare
)

esito = crew.kickoff(inputs={"ticket": "T-4821"})
print(esito.token_usage)     # nel registro: data, modello, consumo

Il rapporto con il GDPR

L'AI Act non sostituisce il GDPR: sono due impianti distinti che si sovrappongono, e vanno rispettati entrambi. Se gli agenti trattano dati personali, e quasi sempre lo fanno, servono le risposte classiche: una base giuridica per il trattamento (articolo 6), la minimizzazione dei dati (articolo 5), le informative agli interessati.

Il punto più concreto per un sistema ad agenti è il trasferimento fuori dall'Unione. Se il modello è un'API di un fornitore extra UE, ogni prompt che contiene dati personali è un trasferimento, e ricade nel capo V del GDPR: serve una decisione di adeguatezza o garanzie come le clausole contrattuali standard, e la verifica sta a te, non al fornitore del modello. Non esiste una configurazione che chiude la questione una volta per tutte: l'esecuzione locale la riduce drasticamente, i fornitori con regione europea la attenuano, ma la valutazione resta caso per caso ed è terreno da professionista, con il Garante privacy come autorità di riferimento.

Lista di controllo prima di andare in produzione

Dieci domande a cui saper rispondere per iscritto. Non sono un audit di conformità: sono il minimo per non farsi trovare scoperti.

1. Chi è il fornitore e chi è il deployer di questo sistema? I ruoli sono scritti nel contratto?
2. In quale livello di rischio ricade l'uso concreto? Sfiora un dominio dell'allegato III?
3. Gli utenti sanno di interagire con un sistema di AI? Dove è dichiarato, nell'interfaccia?
4. I contenuti generati sono marcati come artificiali? Chi li pubblica li etichetta, o c'è una revisione editoriale con responsabilità umana?
5. Ogni esecuzione lascia un log? Dove viene conservato, per quanto tempo, protetto come?
6. Sapresti dire quale modello, in quale versione, ha prodotto un output di sei mesi fa?
7. C'è un punto in cui una persona può fermare o correggere il sistema prima che l'output produca effetti? Quella persona ha formazione e autorità per farlo?
8. I dati di input sono pertinenti e ridotti al necessario? Per i dati personali, qual è la base giuridica?
9. Il modello gira fuori dall'Unione? Il trasferimento è coperto da adeguatezza o garanzie?
10. Le scelte di progetto sono documentate e datate, in un posto che sopravvive al ricambio delle persone?

Le questioni aperte

Chiudiamo con onestà: molte questioni sono ancora aperte. Gli standard tecnici per la marcatura dei contenuti non sono definitivi. La linea di confine fra fornitore e deployer, per chi personalizza sistemi altrui, è discussa. Il rinvio delle scadenze per l'alto rischio, arrivato a luglio 2026, dimostra che il quadro stesso è ancora in movimento. E la prassi delle autorità nazionali è appena partita: le prime decisioni di ACN e AgID diranno più di qualunque commento. Questa pagina fotografa agosto 2026 e verrà aggiornata; la struttura del lavoro tecnico, però, non cambia con i rinvii: log, tracciabilità, sorveglianza umana e documentazione servono comunque, regolamento o no.

Le fonti primarie usate per questa pagina:

• Regolamento (UE) 2024/1689, testo consolidato su EUR-Lex
• Regolamento (UE) 2026/1744, che modifica il calendario di applicazione
• La pagina della Commissione europea sull'AI Act
• Legge 23 settembre 2025, n. 132 su Normattiva
• La documentazione ufficiale CrewAI per i parametri citati