Se la tua azienda ha messo in produzione un assistente conversazionale, un agente che smista ticket o un copilota che scrive bozze di offerte, la domanda su AI Act e agenti AI in azienda ha smesso di essere teorica. Dal 2 agosto 2026 il regolamento europeo ha i denti: scattano il regime sanzionatorio nazionale e gli obblighi di trasparenza. Il problema è che il testo non contiene la parola “agente”, e questo lascia i decision maker delle PMI italiane senza una traduzione operativa. Questo articolo prova a darla, con una tesi precisa: la conformità di un agente AI non è un adempimento documentale da produrre a valle, è una proprietà architetturale da decidere in fase di progetto. Nota: quanto segue ha finalità divulgative e non sostituisce un parere legale.
In questo articolo scoprirai:
- AI Act e agenti AI in azienda: perché la norma non nomina gli agenti
- Cosa cambia dal 2 agosto 2026 e cosa è slittato al 2027
- La piramide del rischio applicata agli agenti AI in azienda
- Provider o deployer: l’errore di classificazione che costa di più
- Trasparenza, log e human-in-the-loop: obblighi che diventano architettura
- Il ruolo del partner: onboarding con audit di conformità
AI Act e agenti AI in azienda: perché la norma non nomina gli agenti
Cercare “agente AI” nel regolamento è un esercizio inutile: l’AI Act non definisce l’agente come categoria giuridica autonoma. Questo ha generato la convinzione, diffusa e sbagliata, che gli agenti vivano in un vuoto normativo in attesa di regole dedicate.
È il contrario. Come chiarisce l’analisi di Deeploy sulla regolazione dell’AI agentica, l’AI Office ha confermato che un agente AI è un sistema di AI ai fini del regolamento, e quindi tutte le regole che si applicano ai sistemi di AI si applicano agli agenti. Non esiste alcuna esenzione per il grado di autonomia: il fatto che un sistema agisca senza supervisione continua non lo sottrae al perimetro, lo rende semmai più delicato.
La conseguenza pratica è che la classificazione di un agente non dipende dalla sua architettura ma dal contesto d’uso e dalla funzione. Lo stesso stack tecnologico, un modello linguistico, un layer di orchestrazione, qualche strumento collegato, produce obblighi radicalmente diversi a seconda di cosa gli fai fare. Un agente che riassume documenti interni e un agente che filtra candidature per una posizione aperta sono, agli occhi del regolatore, oggetti incomparabili. Se non hai ancora chiaro cosa sia un agente rispetto a un chatbot tradizionale, conviene partire da cosa sono gli agenti AI e perché sono indispensabili per le aziende: la distinzione tecnica è anche la premessa di quella giuridica.
Cosa cambia dal 2 agosto 2026 e cosa è slittato al 2027
Qui va fatta una precisazione che circola male. Gli obblighi per i modelli GPAI non nascono nel 2026: secondo la pagina ufficiale della Commissione europea, le regole sui GPAI sono diventate effettive ad agosto 2025. Quello che cambia il 2 agosto 2026 è l’esigibilità: diventano applicabili gli obblighi di trasparenza dell’art. 50, il regime sanzionatorio nazionale dell’art. 99 e le ammende della Commissione sui fornitori GPAI previste dall’art. 101. In altre parole, l’AI Act smette di essere un insieme di obblighi senza conseguenze immediate.
Il Digital Omnibus e il nuovo calendario dell’AI Act
Sul fronte opposto, il pacchetto Digital Omnibus, approvato dal Parlamento europeo il 16 giugno 2026 e adottato dal Consiglio il 29 giugno 2026, ha ridisegnato il calendario. Come ricostruisce Iusletter, i sistemi ad alto rischio stand-alone (Allegato III) slittano al 2 dicembre 2027 e quelli integrati in prodotti già regolati (Allegato I) al 2 agosto 2028. Resta invariato il calendario di ciò che è già operativo, incluse le pratiche vietate dell’art. 5, in vigore da febbraio 2025.
Attenzione a come si legge questo rinvio. Non è deregulation: è simplification, e sposta la scadenza degli adempimenti formali mentre gli standard tecnici sono ancora in gestazione. Chi ne deduce “abbiamo tempo fino al 2027” sta ignorando che trasparenza e sanzioni sono già qui. Per la timeline generale, non specifica agli agenti, il riferimento è AI Act Italia: obblighi e scadenze 2026 per le aziende. In Italia la supervisione sui modelli per finalità generali è affidata ad ACN, affiancata da AgID, nel quadro della Legge 132/2025.
La piramide del rischio applicata agli agenti AI in azienda
La Commissione articola quattro livelli: rischio inaccettabile (sistemi vietati), alto rischio, rischio di trasparenza e rischio minimo o nullo, per il quale l’AI Act non introduce regole. La maggior parte degli agenti aziendali italiani vive nei due livelli centrali.
Quando un agente AI diventa alto rischio
L’alto rischio non è una questione di potenza del modello ma di dominio applicativo: lavoro, credito, biometria, istruzione, servizi pubblici essenziali, giustizia. Un agente che automatizza l’estrazione dati dalle fatture passive resta fuori, è il territorio degli agenti AI per il back-office. Un agente che assiste lo screening delle candidature rientra nell’Allegato III, e questo cambia tutto: chi lavora su questi casi d’uso dovrebbe leggere la guida agli agenti AI per le Risorse Umane con la lente della classificazione, non solo dell’efficienza.
Gli obblighi che valgono comunque
Anche gli agenti a rischio minimo non sono liberi. Le proibizioni dell’art. 5 valgono universalmente, e l’art. 50 impone di dichiarare all’utente che sta interagendo con un’AI e di marcare i contenuti sintetici in formato leggibile dalla macchina. Un chatbot che si presenta come una persona è già oggi un problema, indipendentemente da quanto sia innocuo il suo dominio, tema che tocca da vicino chi sta ridisegnando i processi descritti in chatbot AI in azienda: quali lavori stanno cambiando.
Provider o deployer: l’errore di classificazione che costa di più
Questo è il punto che la pubblicistica italiana quasi ignora, e che nel mondo anglosassone viene chiamato senza mezzi termini il rischio più sottovalutato dell’AI Act. Secondo Corporate Compliance Insights, l’errore più costoso non è violare un obbligo: è sbagliare il proprio ruolo, perché genera fallimenti di conformità a cascata su documentazione e trasparenza.
Il ruolo dell’azienda che adotta un agente AI
La distinzione è netta sulla carta. Il provider sviluppa il sistema e lo immette sul mercato a proprio nome; il deployer lo usa sotto la propria autorità. Un’azienda che adotta un agente di terzi è normalmente un deployer, e come nota l’analisi di NicFab sullo stato dell’arte 2026, essere deployer non attiva automaticamente obblighi: dipende dalla classificazione del sistema. Va aggiunto un corollario spesso ignorato: il fatto che il modello sottostante sia perfettamente conforme alle regole GPAI non trasferisce quella conformità all’agente che ci costruisci sopra.
L’articolo 25 e la riqualificazione del deployer
L’art. 25 individua tre circostanze in cui un deployer viene riqualificato come provider, ricostruite con chiarezza da A&O Shearman: apporre il proprio marchio su un sistema ad alto rischio già sul mercato; apportarvi modifiche sostanziali, in particolare alterandone la finalità prevista; riconvertire un modello di uso generale verso un’applicazione ad alto rischio. In quei casi tutti gli obblighi rilevanti si spostano sul deployer, e gli obblighi del provider sono sensibilmente più gravosi.
Tradotto per chi personalizza: più spingi la customizzazione di un agente, più ti avvicini alla soglia di riqualificazione. È esattamente il trade-off discusso in agenti AI custom vs off-the-shelf, che smette di essere una scelta solo tecnica ed economica e diventa una scelta di perimetro regolatorio. Complica ulteriormente il quadro l’architettura multi-agente: la domanda rilevante è se il sistema composito, preso nel suo insieme, costituisca un sistema di AI immesso sul mercato, e chi controlla il layer di orchestrazione può ritrovarsi obblighi di livello provider sull’intero sistema, pur usando modelli di terzi.
Trasparenza, log e human-in-the-loop: obblighi che diventano architettura
Qui la tesi dell’articolo diventa concreta. I tre obblighi più citati per gli agenti non si soddisfano con una policy: si soddisfano con scelte di design che, se non prese all’inizio, richiedono di rifare il sistema.
Log: l’art. 12 e i sei mesi di conservazione
L’art. 12 impone che i sistemi ad alto rischio permettano tecnicamente la registrazione automatica degli eventi lungo tutto il ciclo di vita. Come spiega Help Net Security, il regolamento definisce le finalità e non il formato, e gli artt. 19 e 26 fissano una conservazione minima di sei mesi. Il punto critico: l’art. 12 non richiede esplicitamente log a prova di manomissione, ma un log alterabile silenziosamente ha valore probatorio nullo davanti a un’autorità. Nessuno standard tecnico è ancora finalizzato, vanno seguite le bozze prEN 18229-1 e ISO/IEC DIS 24970. Sostanzialmente, il log deve consentire di ricostruire a posteriori una singola decisione: se l’agente non registra quali fonti ha consultato, non ce la fai. Ed è la ragione per cui l’architettura RAG con citazione delle fonti è, prima che una scelta di qualità, un abilitatore di tracciabilità.
Supervisione umana: l’art. 14 non ammette il rituale
L’art. 14 sulla supervisione umana richiede che il supervisore possa comprendere capacità e limiti del sistema, interpretarne correttamente l’output, restare consapevole del bias di automazione, decidere di non usarlo o di ignorare, sovrascrivere o ribaltare l’output, e che esista un pulsante di stop o una procedura equivalente per portare il sistema a un arresto sicuro. La supervisione deve essere effettiva, non simbolica: un’approvazione umana che l’operatore concede meccanicamente perché non ha strumenti per valutare l’output non è conformità, è teatro. E come argomenta Okta sulla governance dell’AI agentica, la governance va incorporata in identità verificabili per ogni agente, permessi a privilegio minimo e capacità di spegnimento, non in documenti di policy.
AI Act e agenti AI: la compliance è una proprietà del progetto
Mettendo in fila i tre punti precedenti emerge una regola operativa: le decisioni che determinano la conformità di un agente si prendono prima di scrivere la prima riga di orchestrazione. Il confine tra deployer e provider dipende da quanta customizzazione autorizzi. La tracciabilità dipende da come strutturi il log. L’human-in-the-loop dipende da dove piazzi i punti di escalation e da quali informazioni dai all’operatore per decidere. Nessuna di queste tre cose si aggiunge a posteriori senza rimettere mano al sistema.
AI Act e agenti AI: perché legale e fornitore da soli non bastano
Questo è anche il motivo per cui l’AI Act non si affronta né con il solo legale né con il solo fornitore tecnico. Il legale sa classificare il rischio ma non sa dove finiscono i log; il fornitore sa dove finiscono i log ma raramente sa se la personalizzazione che hai chiesto ti ha spostato in area provider. Il quadro si somma poi a quello privacy, le due normative si parlano, come si vede in sicurezza, GDPR e AI. Va ricordato infine l’obbligo di alfabetizzazione AI: la supervisione effettiva presuppone persone formate, e non è un caso che la formazione del team sugli agenti AI sia un requisito e non un benefit. Prima di partire, un check onesto su quanto la tua azienda è pronta vale più di un parere.
Il ruolo del partner: onboarding con audit di conformità
Le PMI italiane non hanno in casa la coppia legal + AI engineering, e assumerla per un progetto è fuori scala. È la ragione per cui, su questo tema, il servizio conta più del modello: la differenza tra un agente conforme e uno da rifare non sta nel modello scelto, sta in chi ha impostato ruoli, log ed escalation al momento giusto. Il ragionamento è sviluppato in AI agent enterprise: perché il servizio conta più del modello, e più in generale in consulenza intelligenza artificiale: perché serve un partner.
Per questo Mimír non consegna soltanto un agente configurato: l’onboarding comprende un audit di conformità, cioè la ricostruzione del ruolo dell’azienda rispetto al sistema, la classificazione del caso d’uso, la verifica che logging e supervisione siano tecnicamente in piedi e non solo dichiarati. È lavoro che si fa una volta, all’inizio, e che evita di scoprire a valle di avere un sistema inutilizzabile. Cosa aspettarsi in concreto da questo tipo di percorso è descritto in consulenza agenti AI per PMI; sui criteri di scelta, come scegliere il fornitore giusto in Italia e cosa deve garantire un SLA.
Se stai valutando un agente AI o ne hai già uno in produzione e non sai in quale casella dell’AI Act ricada, vale la pena affrontare la domanda adesso, mentre le scelte sono ancora reversibili. Puoi partire da una conversazione con il team di Mimír per capire dove sei e cosa serve.
Fonti:
- Deeploy — Are AI agents and agentic AI regulated under the EU AI Act
- Commissione europea — Regulatory framework on AI
- Iusletter — Il Digital Omnibus ridisegna il calendario degli obblighi AI Act
- Corporate Compliance Insights — The most overlooked risk in the EU AI Act
- NicFab — Deployer e AI agents: stato dell’arte 2026
- A&O Shearman — Interplay between deployers and providers in the EU AI Act
- Help Net Security — EU AI Act logging requirements
- AI Act — Articolo 14, sorveglianza umana
- Okta — Agentic AI governance and compliance
