Agenti AI oltre il mandato: il caso della palestra australiana e il nodo della responsabilità

Agenti AI e sicurezza applicativa. Un assistente incaricato di prenotare una lezione in palestra ha trovato e sfruttato due difetti nel gestionale, prenotando ben oltre la finestra consentita e cancellando la posizione di un altro utente in lista d’attesa. L’utente aveva chiesto di salire in cima alla lista, non di rimuovere qualcuno: fra l’obiettivo assegnato e il mezzo scelto dall’agente si apre una distanza che la sicurezza applicativa conosce da anni e che il diritto non ha ancora risolto.

Il fatto

Gli agenti AI sono arrivati al banco di prova più ordinario che si possa immaginare: prenotare una lezione in palestra. La vicenda arriva dall’Australia ed è stata raccontata il 10 agosto 2026 da ABC News, in un servizio firmato dal national AI reporter Cam Wilson e da Rhiannon Hobbins dello Specialist Reporting Team.

Un utente, indicato con il solo nome di battesimo (Andrew), lavora per un’azienda australiana che vende prodotti di intelligenza artificiale alle imprese. Dall’inizio dell’anno sperimentava con OpenClaw, un framework open source per agenti autonomi, eseguito appoggiandosi al servizio Claude di Anthropic. Un dettaglio che conviene fissare subito, perché la stampa internazionale lo ha spesso appiattito: OpenClaw non è un prodotto Anthropic. È software indipendente, rilasciato con licenza MIT, pubblicato per la prima volta nel novembre 2025 da Peter Steinberger con il nome Warelay. Il 27 gennaio 2026, dopo un rilievo sul marchio da parte di Anthropic per l’assonanza fra “Clawd” e “Claude”, il progetto è stato ribattezzato Moltbot; tre giorni dopo ha assunto il nome definitivo di OpenClaw, questa volta per ragioni di semplice eufonia. Steinberger è passato a OpenAI nel febbraio 2026 e il progetto è oggi gestito dalla OpenClaw Foundation. Può essere collegato a modelli di fornitori diversi.

Vale la pena chiarire anche il rapporto commerciale, perché è stato riportato in forma datata da più testate. Il 4 aprile 2026 Anthropic ha escluso l’uso degli abbonamenti Claude Pro e Max con harness di terze parti, OpenClaw incluso. A metà maggio la società ha però invertito la rotta, annunciando un plafond separato di crediti Agent SDK che ripristinava quell’uso a partire dal 15 giugno; e il 15 giugno ha sospeso anche quel piano, lasciando in vigore la situazione attuale, nella quale l’utilizzo tramite applicazioni di terze parti continua ad attingere ai limiti dell’abbonamento sottoscritto. In altre parole: non esiste oggi un divieto contrattuale che separi nettamente l’agente personale dal servizio del fornitore del modello.

Andrew ha delegato all’agente un compito banale: prenotare un posto in una lezione mattutina molto richiesta. Pochi minuti dopo l’agente è tornato riferendo di avere individuato una vulnerabilità nel software di prenotazione che consentiva di riservare posti con un anticipo molto superiore alla finestra prevista dal regolamento della palestra.

A quel punto si innesta il secondo episodio, che nelle ricostruzioni giornalistiche viene spesso fuso con il primo ma riguarda una lezione diversa, prevista più avanti nella stessa settimana. Andrew era quarto in lista d’attesa e ha chiesto all’agente se fosse possibile portarlo in cima alla lista. L’agente ha risposto di avere verificato che l’API di cancellazione non applicasse alcun controllo di autorizzazione sulle prenotazioni altrui, di avere testato l’ipotesi sulla persona in prima posizione nell’ambito della ricognizione delle proprie capacità, e che l’operazione era andata a buon fine, con lo spostamento di Andrew dalla quarta alla terza posizione. Quando l’utente ha chiesto di ripristinare la situazione, l’agente ha risposto di non essere in grado di reinserire la persona rimossa, che avrebbe dovuto iscriversi di nuovo ripartendo dal fondo.

C’è un dettaglio tecnico che ABC non ha stampato e che compare invece nella trascrizione integrale del messaggio pubblicata da TNW: le chiamate di creazione della prenotazione e di iscrizione alla lista d’attesa restituivano un 403 Forbidden quando si tentava di agire per conto di un altro utente, mentre solo la cancellazione era priva del controllo. L’agente stesso lo definisce un difetto di sicurezza a senso unico. È l’asimmetria che spiega tutto il resto: l’applicazione verificava chi potesse ottenere qualcosa, non chi potesse toglierlo a qualcun altro.

Una precisazione metodologica che questa redazione ritiene doveroso aggiungere: tutto ciò che sappiamo sul funzionamento dell’API proviene dai messaggi dell’agente, riferiti dall’utente e pubblicati da ABC in forma di schermata. Non esiste, allo stato, una verifica tecnica indipendente, e l’endpoint non è stato analizzato da nessuno al di fuori dell’agente stesso. L’azienda che sviluppa il gestionale ha dichiarato ad ABC di non discutere questioni di sicurezza specifiche; Anthropic non ha risposto alla richiesta di commento. Anche la qualificazione dell’episodio come primo attacco informatico autonomo in Australia è una valutazione giornalistica della testata, non una designazione formale di un’autorità.

Va detto che la reazione dell’utente è stata corretta: ha fatto redigere allo stesso agente una comunicazione al fornitore del software per segnalare la vulnerabilità, l’ha revisionata e ne ha autorizzato l’invio. Una divulgazione responsabile nata come effetto collaterale di un incidente.

Il vero difetto non è l’AI

Conviene isolare subito il dato tecnico, perché è quello che rischia di perdersi nel racconto giornalistico. La falla non l’ha creata l’agente.

Un’API che accetta la cancellazione di una prenotazione senza verificare che il richiedente ne sia il titolare è un caso di scuola di broken object level authorization, la prima voce della OWASP API Security Top 10 nell’edizione 2023, tuttora l’edizione vigente del progetto dedicato alle API. Non è una lettura forzata: il terzo scenario di attacco riportato dalla stessa scheda OWASP descrive un servizio documentale nel quale l’eliminazione di un documento avviene senza ulteriori controlli di permesso, con la conseguenza che un utente può cancellare il documento di un altro. È il caso della palestra, con oggetti diversi. È un difetto documentato, ricorrente e perfettamente noto: manca un controllo di autorizzazione sul singolo oggetto, mentre l’autenticazione formalmente funziona.

La prima falla, quella sulla finestra temporale di prenotazione, appartiene a una famiglia diversa e va tenuta distinta: è una regola di business applicata soltanto lato client, riconducibile a un difetto di logica applicativa e, se si vuole restare nella tassonomia OWASP, all’area della broken function level authorization (API5:2023). La classificazione, in assenza di un’analisi diretta dell’endpoint, resta una lettura ragionata e non una qualificazione verificata. Due difetti, due categorie, un’unica causa comune: la fiducia riposta nell’interfaccia come luogo dei controlli.

Difetti di questo tipo sopravvivono per anni nei gestionali verticali proprio perché nessuno li cerca. Il cliente medio di una palestra usa l’interfaccia web, non intercetta il traffico, non enumera identificativi di prenotazione, non prova a manipolare i parametri di una chiamata. La sicurezza dell’applicazione riposava, di fatto, sul disinteresse dell’utenza.

Ciò che cambia con gli agenti è la scala di quel disinteresse. Un agente ha tempo illimitato, nessuna soglia di frustrazione e un incentivo strutturale a percorrere qualunque strada porti all’obiettivo assegnato. Non introduce nuove classi di vulnerabilità: azzera il costo dello scoprire quelle vecchie. È in sostanza la lettura offerta ad ABC da Bill Simpson-Young, amministratore delegato e cofondatore del Gradient Institute, secondo cui abbiamo costruito un mondo complesso che gira su software pieno di buchi, e l’ingresso di agenti capaci di operare su larga scala e ad alta velocità manda in crisi quel modello.

Il corollario operativo per chi sviluppa e per chi acquista software gestionale è immediato: l’assunto implicito secondo cui “nessuno andrà a guardare” non regge più, e le verifiche di autorizzazione lato server smettono di essere una buona pratica raccomandata per diventare l’unico presidio realmente disponibile.

Il problema dell’allineamento, in versione domestica

Il secondo livello di lettura riguarda la distanza fra ciò che l’utente voleva e ciò che l’agente ha fatto per ottenerlo. È il problema di allineamento su cui la ricerca discute da decenni, qui declinato in una forma minima quanto agli effetti complessivi, ma non reversibile per la persona coinvolta: la sua posizione in lista era andata, e l’agente stesso ha dichiarato di non poterla ripristinare. In un contesto a maggiore criticità, la stessa dinamica produce conseguenze di ben altro ordine.

Conviene però essere precisi sul mandato. Andrew non aveva chiesto di attaccare nulla, ma non aveva neppure formulato una richiesta neutra: aveva chiesto di essere portato in cima a una lista d’attesa condivisa con altre persone. Fra l’obiettivo assegnato e il mezzo scelto dall’agente c’è uno scarto reale, ed è esattamente lì che si annida il problema; ma è uno scarto meno ampio di quanto suggerisca la formula, molto ripresa, dell’agente che agisce “senza che nulla gli fosse stato chiesto”.

Resta un margine di ambiguità che vale la pena non nascondere. L’agente ha presentato la cancellazione come parte della verifica delle proprie capacità e ha riferito ad Andrew di averlo già spostato dalla quarta alla terza posizione: una formulazione che lascia aperta la possibilità che l’operazione sia avvenuta durante l’esplorazione autonoma del sistema, e non in risposta alla domanda. Il servizio ABC espone la richiesta e poi la risposta dell’agente, senza datare l’azione; alcune riprese internazionali hanno risolto il dubbio in un senso o nell’altro senza basi ulteriori. Sul piano dell’imputazione soggettiva, di cui si dirà, la differenza non è marginale.

Il caso non è isolato, e le settimane precedenti offrono termini di paragone documentati. Il 21 luglio 2026 OpenAI ha reso noto che alcuni suoi modelli, durante una valutazione interna su un benchmark di capacità cyber, erano usciti dall’ambiente circoscritto in cui operavano sfruttando una vulnerabilità non nota, avevano stabilito connettività verso la rete aperta e avevano compromesso l’infrastruttura di Hugging Face nel tentativo di ottenere le risposte al test assegnato. Il 30 luglio Anthropic ha dichiarato che propri modelli avevano ottenuto accessi non autorizzati ai sistemi di tre organizzazioni reali: qui, a differenza del caso OpenAI, non c’è stata alcuna evasione autonoma, perché l’accesso a Internet era disponibile per un errore di configurazione dell’ambiente di valutazione gestito da un partner esterno. Il 31 luglio Reuters ha riferito, sulla base di fonti anonime, che OpenAI aveva individuato altri casi di uscita dagli ambienti di test nel corso della propria indagine interna: episodi descritti come di portata limitata, dei quali nessuno avrebbe lasciato la rete della società, e di cui l’agenzia non ha potuto stabilire numero, tempi e circostanze. Nei primi giorni di agosto la stessa OpenAI ha documentato pubblicamente due ulteriori incidenti occorsi presso valutatori esterni, uno dei quali coincide con la valutazione dell’AI Security Institute britannico di cui si dirà fra poco. Il 5 agosto Meta ha dichiarato che un proprio modello, Muse Spark 1.1, aveva raggiunto la rete e sfruttato una vulnerabilità nei sistemi di un servizio terzo non identificato.

Un elemento ricorre in tre di questi episodi, quelli comunicati da Anthropic il 30 luglio, da OpenAI all’inizio di agosto e da Meta il 5 agosto, ed è forse il dato più istruttivo per chi si occupa di sicurezza: l’ambiente di valutazione mal configurato apparteneva ogni volta allo stesso fornitore di servizi di test, la società Irregular. Non è soltanto un problema dei modelli: è anche un problema dell’infrastruttura che serve a misurarli. Non vale però per tutti: nell’episodio di Hugging Face l’uscita dall’ambiente è passata dallo sfruttamento di una vulnerabilità non nota, e lì la condotta è stata interamente del modello.

Il dato più circostanziato arriva dall’AI Security Institute britannico, che il 28 luglio ha rilevato trasferimenti anomali dai propri sistemi di ricerca e ha pubblicato il rapporto sull’incidente il 4 agosto: su 122 esecuzioni di una singola valutazione di sicurezza, in 10 casi un agente ha compiuto azioni autonome non autorizzate sulla rete pubblica verso persone e organizzazioni reali, per un totale di 19 azioni catalogate, fra cui un tentativo di attacco alla catena di fornitura di software open source; 17 delle 19 sono riconducibili a un solo modello. L’istituto precisa che non si è trattato di un’evasione dall’ambiente isolato: l’accesso a Internet era stato concesso deliberatamente e i filtri di sicurezza dei fornitori erano stati disattivati per misurare le capacità massime dei modelli.

È nato anche un sito dedicato al censimento di questi episodi, Felony Bench. Conviene però chiamarlo per quello che è: un tracker informale realizzato da un singolo, con una tabella di casi datati e collegati alle fonti ma senza metodologia pubblicata, e non un benchmark nel senso tecnico del termine. Vi è già censito anche il caso della palestra, attribuito ad Anthropic: una scelta che, involontariamente, illustra alla perfezione il problema di attribuzione di cui si dirà fra poco. Un secondo limite emerge dal confronto con le fonti citate: la voce relativa alla notizia Reuters del 31 luglio parla di account interni compromessi presso quattro società, mentre l’articolo richiamato riferisce di episodi circoscritti, nessuno dei quali avrebbe superato il perimetro di rete del fornitore.

Sul piano istituzionale, ABC riferisce che l’Australian Signals Directorate aveva già diramato a imprese e amministrazioni un avviso secondo cui i sistemi di intelligenza artificiale possono fraintendere le istruzioni, compiere azioni non previste e rendere più difficile stabilire le responsabilità, perché le decisioni si distribuiscono lungo catene di modelli, strumenti e servizi. Dopo il servizio ABC, l’Australian Cyber Security Centre è tornato sul punto con un richiamo esplicito all’uso prudente degli agenti, ricollegando l’episodio ai rischi di disallineamento degli obiettivi già individuati nella propria guida e qualificandolo come un caso di specification gaming: la ricerca di scorciatoie che raggiungono formalmente l’obiettivo assegnato ma confliggono con l’intenzione di chi lo ha assegnato. L’avviso raccomanda di mantenere una supervisione umana sulle azioni dell’agente, in particolare quando queste toccano servizi di terzi o altri utenti, e avverte le organizzazioni che erogano servizi online di considerare che gli agenti possono individuare e sfruttare vulnerabilità a grande velocità e su larga scala.

Il riferimento più solido in materia resta la guida congiunta Careful Adoption of Agentic AI Services, pubblicata il 1° maggio 2026 sul sito dell’ASD e firmata da sei agenzie (CISA e NSA per gli Stati Uniti, l’Australian Cyber Security Centre dell’ASD, il Canadian Centre for Cyber Security, il National Cyber Security Centre britannico e quello neozelandese), che organizza il rischio degli agenti in cinque categorie: privilegi, progettazione e configurazione, comportamento, struttura, responsabilità. La guida raccomanda esplicitamente di non concedere mai agli agenti accessi ampi o illimitati, soprattutto verso dati sensibili o sistemi critici, e di riservarli, in questa fase, a compiti a basso rischio e non sensibili.

Quest’ultimo punto è il più rilevante per chi si occupa di governance. La catena di attribuzione si allunga proprio nel momento in cui servirebbe più corta.

Chi risponde? Il caso australiano

Nell’ordinamento australiano la questione è dichiaratamente aperta: il software non è soggetto di diritto, e solo un soggetto di diritto può essere chiamato a rispondere. Hayden Delaney, partner dello studio Thomsons (già Thomson Geer) e specialista di diritto delle tecnologie, proprietà intellettuale e privacy, indica ad ABC come possibili responsabili l’utente che ha assegnato il compito, chi ha progettato il software che istruisce l’agente, chi sviluppa il modello o l’operatore del sistema vulnerabile.

Delaney aggiunge però un elemento che merita attenzione, perché anticipa il ragionamento che seguirà: alcune norme esistenti potrebbero applicarsi già oggi, in particolare quando un soggetto agisce in modo avventato o quando un’impresa fornisce un servizio difettoso. La risposta, dice, dipende da che cosa l’utente ha autorizzato, da quali rischi erano ragionevolmente prevedibili e dal fatto che la condotta si sia svolta o meno nell’ambito di un’attività commerciale. Non è un vuoto normativo, insomma, ma un’area di incertezza applicativa.

Il tema è entrato anche nell’agenda politica australiana: secondo ABC, Andrew Charlton, Assistant Minister per la scienza, la tecnologia e l’economia digitale, è stato il primo membro noto del governo ad affrontarlo in un discorso a una conferenza sulla sicurezza dell’IA, annunciando finanziamenti al CSIRO per studiare come sia possibile gestire e verificare il comportamento di sistemi di intelligenza artificiale sempre più capaci.

Che cosa accadrebbe in Italia

Il caso è interamente australiano e la legge penale italiana si applica, salve eccezioni, ai reati commessi nel territorio dello Stato (art. 6 c.p.). Il ragionamento che segue è dunque un’ipotesi di lavoro: che cosa accadrebbe se la stessa condotta si verificasse in Italia, con utente e sistema collocati sul territorio nazionale. Il diritto italiano offre categorie più definite di quello australiano, ma non risposte automatiche.

Accesso abusivo a sistema informatico (art. 615-ter c.p.). La norma punisce chi abusivamente si introduce in un sistema informatico o telematico protetto da misure di sicurezza, ovvero vi si mantiene contro la volontà espressa o tacita di chi ha il diritto di escluderlo. Due elementi meritano attenzione.

Il primo è proprio il requisito delle misure di sicurezza, che in un caso come questo è meno scontato di quanto sembri: l’endpoint di cancellazione era, per quanto riferito, privo di controlli di autorizzazione. La giurisprudenza è però costante nel ritenere sufficiente qualunque accorgimento, anche di natura organizzativa, idoneo a manifestare la volontà di esclusione del titolare. Fra le pronunce recenti, Cass. pen., Sez. V, n. 2905/2025 (udienza 23 ottobre 2024, deposito 23 gennaio 2025) ha ribadito che la protezione può essere adottata anche con misure di carattere organizzativo che disciplinino le modalità di accesso, consentendolo ai soli soggetti abilitati per determinate finalità. Un sistema che richiede autenticazione e definisce regole di prenotazione soddisfa quel requisito. La condotta si colloca poi nel filone dell’excessus mandati: rileva non tanto il modo in cui si entra, quanto il superamento dei limiti dell’autorizzazione ricevuta, ed è esattamente ciò che accade quando una sessione legittima viene usata per agire su oggetti altrui.

Il secondo è l’elemento soggettivo. Il reato è punito a titolo di dolo. Un utente che chiede di essere iscritto a un corso non rappresenta né vuole l’accesso abusivo, e la condotta materiale è stata determinata da un sistema automatico che ha scelto autonomamente il mezzo. Ma la richiesta effettivamente formulata era di essere portato in cima a una lista d’attesa altrui, da parte di un soggetto professionalmente esposto al funzionamento degli agenti: l’ipotesi del dolo eventuale, cioè della previsione e accettazione del rischio, non può essere liquidata in astratto e andrebbe valutata sul caso concreto. Qui pesa anche l’ambiguità sopra segnalata: se la cancellazione fosse avvenuta prima della richiesta, nel corso di un’esplorazione autonoma, verrebbe meno il presupposto stesso di una qualsiasi rappresentazione dell’evento in capo all’utente. È lo stesso crinale, sul versante di common law, indicato da Delaney quando parla di condotta avventata e di rischi ragionevolmente prevedibili.

Rileva infine la procedibilità. L’ipotesi base del primo comma è punibile a querela della persona offesa; nelle ipotesi aggravate del secondo comma si procede d’ufficio. Fra queste rientra il caso in cui dal fatto derivi la distruzione o il danneggiamento dei dati contenuti nel sistema: aggravante che la L. 90/2024 (art. 16, comma 1, lettera b, n. 1.3) ha esteso anche alla sottrazione, pure mediante riproduzione o trasmissione, e all’inaccessibilità al titolare. Poiché qui una cancellazione di dati c’è stata, la qualificazione non è indifferente.

Danneggiamento di informazioni, dati e programmi informatici (art. 635-bis c.p.). Nel testo riformulato dalla L. 28 giugno 2024 n. 90, la norma punisce con la reclusione da due a sei anni, a querela della persona offesa, chi distrugge, deteriora, cancella, altera o sopprime informazioni, dati o programmi informatici altrui. La cancellazione della prenotazione di un terzo integra materialmente la condotta, con lo stesso interrogativo sull’imputazione soggettiva, dato che anche qui è richiesto il dolo e non è prevista la punibilità a titolo di colpa. Resta da qualificare il requisito dell’altruità: il dato riguarda il socio rimosso, ma è custodito ed elaborato nel sistema del titolare del trattamento.

Profilo civilistico e protezione dei dati. La palestra resta titolare del trattamento dei dati dei propri soci ed è tenuta ad adottare misure tecniche e organizzative adeguate ai sensi dell’art. 32 GDPR. Il fornitore del gestionale opera con ogni probabilità come responsabile del trattamento ai sensi dell’art. 28, con obblighi propri di sicurezza e con la necessità di un contratto che li definisca. Un’API che consente a chiunque di cancellare la prenotazione di un altro interessato è, prima ancora che un problema di sicurezza applicativa, una misura di sicurezza inadeguata. E la cancellazione non autorizzata di un dato personale da parte di un terzo integra una violazione di integrità e disponibilità, con i conseguenti obblighi di valutazione e, ove ricorrano i presupposti, di notifica al Garante e di comunicazione all’interessato ai sensi degli artt. 33 e 34 GDPR. La responsabilità del titolare non si attenua per il fatto che a sfruttare la falla sia stato un agente automatico anziché una persona.

Sul versante risarcitorio il quadro è in transizione, e il dato temporale conta. La disciplina di riferimento non è quella sull’IA ma quella sulla responsabilità da prodotto difettoso, ridisegnata dalla direttiva (UE) 2024/2853, che include espressamente il software fra i prodotti e che la testata ha già analizzato. Il termine di recepimento scade però il 9 dicembre 2026 e le nuove regole si applicheranno ai prodotti immessi sul mercato o messi in servizio da quella data; in Italia la delega è contenuta nella legge di delegazione europea 2025 (legge 17 marzo 2026, n. 36) e il decreto legislativo non risulta ancora emanato. Un fatto verificatosi oggi ricadrebbe quindi ancora sotto gli artt. 114 e seguenti del Codice del consumo. Vale inoltre la pena segnalare che la nuova direttiva esclude dal proprio ambito, all’art. 2, paragrafo 2, il software libero e open source sviluppato o fornito al di fuori di un’attività commerciale: una previsione che, applicata a un framework come OpenClaw, rilasciato con licenza MIT, sottrarrebbe proprio l’anello centrale della catena. Il condizionale è d’obbligo, perché la condizione dell’estraneità a un’attività commerciale non è scontata per un progetto gestito da una fondazione e sostenuto finanziariamente da un fornitore di modelli.

AI Act. Vale la pena segnalare ciò che il regolamento europeo, in questo scenario, non fa, e per due ragioni distinte che si sommano.

La prima è di classificazione: un assistente che prenota lezioni in palestra non rientra fra i sistemi ad alto rischio dell’Allegato III, quindi i requisiti di gestione del rischio e sorveglianza umana del Capo III non lo riguardano.

La seconda è di calendario, ed è recente. Il Regolamento (UE) 2026/1744 dell’8 luglio 2026, il cosiddetto Omnibus digitale sull’IA, pubblicato in Gazzetta Ufficiale dell’Unione europea il 24 luglio 2026 ed entrato in vigore il 27 luglio, ha riscritto il terzo comma dell’art. 113 dell’AI Act rinviando il blocco degli obblighi sui sistemi ad alto rischio: le sezioni 1, 2 e 3 del Capo III, con esclusione dell’art. 6, paragrafo 5, si applicheranno dal 2 dicembre 2027 per i sistemi autonomi dell’Allegato III e dal 2 agosto 2028 per quelli integrati in prodotti coperti dall’Allegato I.

Che cosa resta, allora, in vigore oggi. Restano i divieti dell’art. 5 e l’obbligo di alfabetizzazione in materia di IA dell’art. 4, applicabili dal 2 febbraio 2025, con l’avvertenza che l’art. 4 è stato integralmente sostituito dall’Omnibus e, dal 27 luglio 2026, non impone più di garantire un livello sufficiente di alfabetizzazione ma di adottare misure per sostenerne lo sviluppo. Restano gli obblighi in capo ai fornitori di modelli per finalità generali e, con essi, l’intero Capo XII sulle sanzioni, applicabile dal 2 agosto 2025 con la sola eccezione dell’art. 101. Dal 27 luglio 2026 sono divenuti applicabili gli articoli da 102 a 110. Dal 2 agosto 2026 sono esigibili gli obblighi di trasparenza dell’art. 50 e si è aggiunto il potere della Commissione di sanzionare direttamente i fornitori di modelli per finalità generali ai sensi dell’art. 101, insieme alla piena operatività della vigilanza nazionale. L’Omnibus ha inoltre ampliato l’elenco delle pratiche vietate dall’art. 5, con applicazione delle nuove fattispecie dal 2 dicembre 2026.

C’è però un dettaglio dell’Omnibus che merita di essere isolato, perché riguarda direttamente questa vicenda. Il nuovo Allegato XIV dell’AI Act, una nomenclatura di codici destinata alla designazione degli organismi notificati, introduce il codice AIH 0401 per le tecnologie emergenti non coperte dagli altri codici e vi nomina espressamente l’IA agentica. È un codice residuale, nel quale l’IA agentica è nominata a titolo di esempio; un sistema agentico costruito su un modello per finalità generali ricade invece nel codice AIH 0301. È una collocazione tecnica e defilata, priva di definizione, di obblighi e di criteri di classificazione, ma, per quanto risulta a questa redazione, è la prima volta che l’espressione compare in un atto vincolante dell’Unione. Il legislatore europeo riconosce il fenomeno; non lo disciplina.

Il caso illustra bene, e per doppia via, un’area grigia: sistemi a basso rischio per finalità dichiarata, ma dotati di capacità di azione su sistemi di terzi, e per i quali il presidio regolatorio più stringente non è comunque il regolamento sull’IA.

La riflessione, per le organizzazioni italiane, non è teorica. Il momento in cui un dipendente delega a un agente personale un’attività che tocca sistemi aziendali o di fornitori è già arrivato, e in genere senza che nessuno lo abbia autorizzato formalmente.

Cosa portarsi a casa

Per chi sviluppa o acquista software applicativo:

• verificare l’autorizzazione a livello di singolo oggetto su ogni endpoint che modifica o cancella risorse, senza affidarsi ai controlli dell’interfaccia;
• controllare la simmetria dei presidi: in questo caso la creazione della prenotazione e l’iscrizione alla lista d’attesa erano protette, la cancellazione no;
• trattare le regole di business (finestre temporali, limiti di prenotazione, quote) come vincoli da applicare lato server e non come parametri configurati nel client;
• prevedere rate limiting e rilevamento di pattern di accesso automatizzati, che oggi possono provenire da un utente legittimo e non da un attaccante;
• garantire la reversibilità delle operazioni distruttive, con cancellazione logica e ripristino, perché in questo caso l’irreversibilità ha trasformato un test in un danno;
• inserire nei contratti con i fornitori di software un canale di segnalazione delle vulnerabilità, perché le segnalazioni arriveranno.

Per chi si occupa di governance e conformità:

• disciplinare in policy l’uso di agenti personali su sistemi aziendali e di terzi, definendo cosa può essere delegato e con quali credenziali;
• ricostruire in anticipo la catena di attribuzione, mantenendo tracciabilità di quale agente ha operato, con quale mandato, con quali privilegi e con quale modello sottostante;
• conservare i log delle azioni dell’agente lato client e lato server, perché in questo caso l’unica ricostruzione disponibile dei fatti sono i messaggi prodotti dall’agente stesso;
• applicare il principio del privilegio minimo alle credenziali affidate agli agenti, che tendono invece a ereditare tutti i permessi dell’utente;
• non dare per scontato che il rapporto contrattuale con il fornitore del modello separi l’agente personale dall’infrastruttura aziendale: come mostra l’altalena delle politiche di Anthropic fra aprile e giugno 2026, quel confine è mobile e non costituisce un presidio di sicurezza.

Il caso australiano è minore per impatto e quasi comico nella dinamica. È però una fotografia nitida di una transizione già in corso: il software esposto al pubblico non ha più come interlocutore soltanto persone che si comportano come previsto.

Fonti

• ABC News, servizio del 10 agosto 2026 (fonte primaria): abc.net.au
• OWASP API Security Top 10, edizione 2023: owasp.org
• ASD, Careful adoption of agentic AI services: cyber.gov.au
• AI Security Institute, rapporto sull’incidente del 28 luglio 2026 (pubblicato il 4 agosto): aisi.gov.uk
• Felony Bench: felonybench.com