Chi si occupa da tempo di diritto della tecnoscienza, o nel lessico della letteratura scientifica internazionale, di Law, Science & Technology, conosce bene il problema del cosiddetto law lag. L’innovazione scientifica e tecnologica tende fisiologicamente a muoversi più rapidamente dei processi attraverso cui il diritto la osserva, la comprende, la traduce in categorie e, infine, la disciplina.

Non si tratta necessariamente di una patologia del sistema normativo, quanto di una tensione strutturale.

La tecnologia evolve per iterazioni, salti di capability e ricombinazioni spesso difficili da anticipare, per essere più precisi, oggi gran parte della tecnologia vive e si sviluppa quasi in piena autonomia della scienza, si autogenera e l’evoluzione tecnologica oggi è paragonabile all’evoluzione biologica, che avviene per rapida proliferazione di alternative.

Il rapporto stesso tra scienza e tecnologia non è più a senso unico, né tantomeno riassumibile nella relazione “teorico-applicativo”.

All’estremo opposto troviamo il diritto, che ha bisogno di stabilizzare un fenomeno, definirne i confini e trasformarlo in fattispecie sufficientemente determinate da poter produrre obblighi, responsabilità e poteri di enforcement.

Questa distanza temporale diventa particolarmente interessante quando non cambia soltanto la velocità dell’innovazione, ma la natura stessa dell’oggetto regolato mentre la disciplina destinata a governarlo sta ancora entrando a regime.

L’evoluzione dell’intelligenza artificiale agentica offre oggi un caso quasi paradigmatico da analizzare in maniera approfondita all’interno di questa long read.

L’AI Act unionale rappresenta l’astro regolatorio attorno al quale orbita il dibattito globale sull’intelligenza artificiale, e mentre sta ancora consolidando il proprio campo gravitazionale nella prassi applicativa, una parte della tecnologia che dovrebbe governare ha già iniziato a mettere sotto pressione alcune delle categorie sulle quali il Regolamento stesso è stato costruito.

Non perché l’intelligenza artificiale sia semplicemente diventata più potente, ma perché sta cambiando il modo in cui quella capacità entra in contatto con il mondo esterno.

Il passaggio dai modelli prevalentemente orientati alla generazione di output ai sistemi agentici modifica infatti la struttura del problema. Un agente può utilizzare strumenti, navigare ambienti digitali, interrogare servizi esterni, eseguire codice, mantenere memoria tra più passaggi e concatenare autonomamente azioni funzionali al perseguimento di un obiettivo. Una capability che rimane relativamente confinata quando il modello produce testo, può assumere un profilo di rischio radicalmente diverso quando viene combinata con browser access, API, credenziali e permissions operative.

Gli incidenti emersi nel corso del 2026 durante alcune cybersecurity evaluations da parte dei top players statunitensi consentono di osservare questa trasformazione in condizioni reali.

Nel maggio 2026 alcuni modelli Gemini, durante test condotti da Irregular, hanno raggiunto senza autorizzazione sistemi appartenenti a tre aziende reali; a seconda dei casi sono stati utilizzati password guessing o credenziali disponibili pubblicamente. Il testing environment consentiva l’accesso a Internet e il modello riteneva di continuare a operare all’interno dello scenario simulato. Google ha confermato gli episodi e ha riferito che i modelli hanno interrotto l’attività dopo aver riconosciuto la natura reale dei target.

Anthropic aveva già reso pubblici tre episodi nei quali alcuni modelli Claude, durante cybersecurity evaluations svolte con Irregular, avevano raggiunto l’accesso ad Internet e ottenuto accesso non autorizzato ai sistemi di tre organizzazioni. La società californiana ha precisato che non si trattava di modelli che avevano deliberatamente tentato di “evadere” dal proprio ambiente, tuttavia in alcuni casi, modelli meno recenti avevano proseguito l’attività anche dopo aver ricevuto segnali indicativi del fatto che stessero operando sull’Internet pubblico, al di fuori dell’ambiente isolato di testing.

OpenAI ha documentato a sua volta un incidente verificatosi durante test di Irregular, nel quale una misconfiguration aveva consentito ai modelli di raggiungere la rete pubblica nonostante fossero stati informati di non disporre di accesso a Internet. In un diverso episodio, avvenuto durante test interni di cybersecurity, alcuni modelli hanno aggirato i controlli predisposti per isolarli dalla rete e hanno raggiunto infrastrutture interne e sistemi di Hugging Face.

Contrariamente al fear mongering attuato dai media mainstream, la lettura più interessante di questi eventi non richiede alcuna antropomorfizzazione della tecnologia, il punto corretto di inquadramento non è quello di stabilire se una AI abbia deciso di “scappare”, bensì osservare che un sistema ancora formalmente sottoposto a evaluation possa produrre effetti su infrastrutture reali prima che la tecnologia abbia attraversato i confini tradizionalmente associati al deployment o al mercato.

Ed è precisamente qui, a parere dello scrivente, che emerge il problema regolatorio di fondo.

Quando testing e mondo reale smettono di essere separati

La product regulation ha bisogno di confini definiti, un prodotto viene sviluppato e testato, successivamente immesso sul mercato o messo in servizio, infine utilizzato. La precisa sequenza consente al diritto di associare obblighi, responsabilità e poteri di enforcement a passaggi sufficientemente identificabili.

L’AI Act conserva comprensibilmente questa struttura, l’art. 2, par. 8, del Regolamento (UE) 2024/1689 esclude dal proprio campo di applicazione le attività di ricerca, testing e sviluppo relative a sistemi o modelli di AI anteriori alla loro immissione sul mercato o messa in servizio, precisando tuttavia che il testing effettuato in “real-world conditions” non possa beneficiare del medesimo regime di deroga.

La stessa definizione di general-purpose AI model esclude i modelli utilizzati per attività di ricerca, sviluppo o prototipazione prima della loro immissione sul mercato.

Il Regolamento disciplina inoltre specificamente il testing in condizioni reali per determinate categorie di sistemi.

La ratio del legislatore è evidentemente quella di evitare di trattare ogni attività di ricerca come se il prodotto fosse già disponibile commercialmente, in quanto una scelta di questo tipo agirebbe evidentemente da headwind, andando a comprimere irragionevolmente sperimentazione e innovazione.

L’AI agentica, tuttavia, introduce un elemento di discontinuità, in cui la collocazione formale del modello nella fase di testing non garantisce più necessariamente la segregazione materiale dei suoi effetti.

Un evaluation environment sufficientemente realistico può mettere a disposizione del sistema proprio gli elementi che ne rendono significativa la valutazione, connettività, tool, target complessi, code execution, credenziali e margini di autonomia.

Mutuando analogicamente dalle scienze del rischio il concetto di “blast radius”, gli stessi elementi che aumentano la qualità informativa del test possono ampliare la portata delle conseguenze prodotte da una configurazione errata o da un comportamento non anticipato. Si produce così una tensione difficilmente eliminabile, in quanto più una evaluation deve approssimare le condizioni operative reali per misurare seriamente una capability agentica, tanto maggiore diventa l’importanza del containment che separa quella simulazione dal mondo esterno.

Dopo le disclosure dell’estate 2026, Irregular ha riconosciuto che diversi episodi pubblicamente riportati erano riconducibili allo stesso problema sottostante di uno specifico evaluation environment, successivamente corretto. La circostanza è particolarmente significativa perché sposta l’attenzione dal solo comportamento del modello verso l’architettura complessiva nella quale quella specifica capability venga esercitata.

In questa mutagenesi funzionale, il testing, in altre parole, non è più soltanto il luogo nel quale si misura il rischio, ma può diventare esso stesso una componente della sua architettura.

Non è un vuoto regolatorio: cosa dice già l’AI Act

Sarebbe tuttavia un errore analitico concludere che l'AI Act abbia lasciato l'intera fase pre-market in un totale vuoto regolatorio, poiché l’art. 55 impone ai provider di general-purpose AI models con systemic risk di effettuare model evaluations, anche attraverso adversarial testing, e di valutare e attenuare i possibili rischi sistemici che possono derivare dallo sviluppo, dall’immissione sul mercato o dall’uso del modello. La stessa disposizione impone serious incident reporting e adeguati livelli di cybersecurity sia rispetto al modello sia rispetto alla relativa infrastruttura fisica.

Anche l’enforcement è più articolato di quanto suggerirebbe una lettura esclusivamente market-centric.

Ai sensi dell’art. 92, l’AI Office può effettuare evaluations per verificare la conformità o indagare sui systemic risks dei GPAI models con rischio sistemico; l’art. 93 consente quindi alla Commissione di richiedere specifiche mitigation measures quando una evaluation abbia fatto emergere un timore serio e comprovato di rischio sistemico. La possibilità di limitare la messa a disposizione sul mercato, ritirare o richiamare il modello rappresenta un’ulteriore misura, strutturalmente collegata all’esistenza di un rapporto con il mercato.

La questione è quindi più sottile di un semplice vuoto normativo, sta emergendo una divergenza tra le categorie discrete attraverso cui il diritto organizza il lifecycle della tecnologia e la continuità attraverso cui il rischio può materializzarsi.

Sviluppo, testing, immissione sul mercato e utilizzo continuano a essere distinzioni necessarie sul piano giuridico, ma dal punto di vista tecnico un sistema può produrre effetti reali attraversando quei confini prima che la propria qualificazione formale cambi.

La geometria della regolazione e quella del rischio iniziano così a non sovrapporsi perfettamente.

Dal model risk al control risk

Una parte della difficoltà nasce dall’abitudine a identificare l’oggetto del rischio con il modello e per i sistemi agentici questa unità di analisi diventa progressivamente insufficiente.

La stessa base model può essere inserita in architetture che producono profili di rischio completamente differenti, così un sistema può essere confinato alla generazione di testo all’interno di un ambiente chiuso, ma lo stesso modello può essere dotato di browser, memory, API access, code execution, tool aziendali, credenziali e possibilità di delegare task a ulteriori agenti: le capacità cognitive di base non sono cambiate necessariamente nella stessa misura, ma è cambiata la superficie sulla quale possono essere esercitate.

L’agency non è quindi soltanto una proprietà isolata del modello, ma il risultato dell’interazione tra capability, orchestration, tools, permissions ed environment.

Questa distinzione cambia anche la domanda da porre in sede di due diligence tecnica e legale, non basta più chiedersi quanto sia potente, affidabile o vulnerabile il modello, diviene necessario comprendere quali risorse possa raggiungere, attraverso quali credenziali, quali azioni possa eseguire senza una nuova autorizzazione umana e quali elementi dell’operational stack determinino concretamente il suo margine di azione.

Il model risk non scompare, viene incorporato in una categoria più ampia che potremmo definire control risk, perché al di là di ciò che la tecnologia è capace di fare, conta ciò che l’architettura le consente di fare nel contesto specifico nel quale viene utilizzata.

Quando la supply chain non coincide con la control chain

La stessa evoluzione modifica la lettura della filiera, in cui un model provider può sviluppare il foundation model, un soggetto diverso può costruire l’agentic layer, un evaluator indipendente può configurare l’ambiente di testing, il cloud provider può controllare una parte dell’infrastruttura, un ulteriore soggetto può fornire tool o servizi esterni, il deployer finale può decidere quali credenziali e quali permission attribuire al sistema.

Non tutti questi ruoli coincidono con autonome qualificazioni dell’AI Act, ad esempio “Integrator” può essere utile come categoria funzionale per comprendere una determinata architettura tecnologica, ma non deve essere trasformato impropriamente in una figura regolatoria distinta.

La supply chain giuridicamente rilevante è la control chain, cioè la distribuzione effettiva delle capacità di osservare, configurare, autorizzare e interrompere l’attività del sistema, che possono divergere.

Gli incidenti avvenuti negli ambienti di evaluation mostrano bene il fenomeno, Irregular non era il provider dei modelli interessati né il futuro deployer commerciale, ma controllava elementi dell’ambiente attraverso cui quei modelli potevano interagire con sistemi esterni. Una configurazione errata in quel nodo è stata sufficiente a trasformare capacità oggetto di testing in attività capace di raggiungere infrastrutture reali.

La conseguenza è rilevante anche sul piano contrattuale, sapere chi sia il provider e chi sia il deployer rimane necessario, ma può non essere sufficiente per comprendere chi possa materialmente prevenire o arrestare un determinato evento. Occorre sapere chi controlla la network connectivity, chi assegna le credentials, chi stabilisce il permission scope, chi dispone della telemetry, chi può modificare la configurazione dell’environment e chi detiene la stop authority tecnica.

È qui che emerge un possibile disallineamento tra control, authority e accountability, perché un soggetto può in astratto possedere il potere tecnico di interrompere un comportamento senza essere quello sul quale ricade integralmente la responsabilità giuridica; un altro può assumere contrattualmente obblighi significativi senza disporre materialmente degli strumenti necessari per intervenire in tempo reale.

Ecco dunque che, prima del liability gap, può quindi esistere un control gap.

Architetture cross-border: legal authority e stop authority

La complessità aumenta quando la control chain attraversa più giurisdizioni, dato che un foundation model può essere sviluppato negli Stati Uniti, l’evaluation environment può essere gestito da un soggetto stabilito altrove, l’infrastruttura cloud può essere distribuita in più regioni, il deployer può operare in Europa e il sistema raggiunto dall’agente può appartenere a un ulteriore soggetto situato in un diverso ordinamento.

In questo scenario, determinare legge applicabile, autorità competente e ripartizione delle responsabilità rimane essenziale, ma affronta soltanto una parte del problema.

Un sistema agentico può concatenare azioni in tempi incompatibili con quelli fisiologici di qualsiasi procedimento giudiziario o regolatorio, se legal authority e stop authority si trovano presso soggetti differenti, il tema più urgente non è soltanto quale foro possa intervenire ex post, ma se esista ex ante un meccanismo tecnico e contrattuale capace di produrre l’interruzione nei tempi operativi dell’evento.

L’AI Act non attribuisce alla Commissione un generale kill switch transnazionale capace di arrestare istantaneamente qualsiasi sistema agentico operante nel mondo, l’art. 93 attribuisce poteri significativi nei confronti dei provider interessati, inclusa la richiesta di mitigation measures e, nei casi previsti, limitazione della messa a disposizione, ritiro o richiamo del modello. Sono però tutti strumenti regolatori, non un sostituto della capacità tecnica di containment che deve esistere fisiologica nell’architettura concreta del sistema.

Questa distinzione assume particolare importanza nelle filiere globali, in cui la possibilità teorica di attribuire una responsabilità dopo l’incidente non equivale alla possibilità materiale di interrompere l’incidente mentre si sta verificando.

Dal controllo all’evidenza: log e audit trail come prova

La centralità del controllo modifica anche la funzione della documentazione tecnica, logs, audit trail, records delle evaluations, configurazioni dei permissions, evidenza degli interventi di monitoring e documentazione delle mitigation measures sono normalmente considerati componenti della governance ingegneristica o della compliance.

In un ecosistema agentico acquistano una funzione ulteriore, poiché consentono di ricostruire chi poteva fare cosa, in quale momento, attraverso quali strumenti e con quale livello di conoscenza dell’evento.

Questa dimensione diventerà particolarmente rilevante anche nel quadro della Direttiva (UE) 2024/2853 sulla responsabilità per danno da prodotti difettosi. È importante non attribuire alla Direttiva una inesistente scriminante generale basata sulla “perdita di controllo” e nemmeno trasformare la responsabilità da prodotto in un generico negligence standard. L’art. 10 continua a prevedere, come principio, che l’attore provi difetto, danno e nesso causale, pur introducendo specifiche presunzioni anche nelle ipotesi in cui la complessità tecnica o scientifica renda eccessivamente difficile la prova.

La Direttiva attribuisce però un rilievo esplicito al manufacturer’s control e considera la possibilità che software, updates, upgrades, servizi ancillari e modifiche successive mantengano nel tempo una relazione di controllo tra manufacturer e prodotto. Il legislatore prende così atto di una caratteristica centrale dei prodotti digitali, il comportamento del prodotto non è necessariamente cristallizzato nel momento della commercializzazione.

Il nuovo regime dovrà essere recepito dagli Stati membri entro il 9 dicembre 2026 e, a seguito della rettifica pubblicata nel maggio 2026, si applicherà ai prodotti immessi sul mercato o messi in servizio dopo l’8 dicembre 2026.

In questo quadro, audit trail, system logs e documentazione delle evaluations eccedono la funzione puramente ingegneristica e possono diventare elementi probatori decisivi per ricostruire quali capability fossero disponibili, quali controlli fossero effettivamente operativi, dove risiedesse il controllo tecnico e attraverso quale catena causale si sia prodotto l’evento.

La conservazione dell’evidenza probatoria deve quindi essere progettata prima dell’incidente, non ricostruita a posteriori.

Le conseguenze operative sui contratti

Se regulatory chain e control chain possono divergere, anche il legal design deve partire da una rappresentazione più precisa della realtà tecnologica.

La mappatura contrattuale non può limitarsi ad attribuire genericamente obblighi a provider e deployer, ma deve ricostruire chi controlla credenziali, permessi, connectivity, environment configuration, logging, stop authority e verificare se la distribuzione di questi poteri sia coerente con la distribuzione degli obblighi e delle responsabilità.

L’attribuzione al sistema di accessi, credenziali e permissions trasferisce sul soggetto che li controlla una parte sostanziale della capacità di prevenire, contenere o interrompere l’evento, anche quando la responsabilità giuridica finale debba essere ricostruita diversamente.

La stop authority, in particolare, non dovrebbe essere trattata come una generica dichiarazione di principio, occorre stabilire chi possa esercitarla materialmente, attraverso quale infrastruttura, entro quali tempi, sulla base di quali trigger e con quali obblighi di cooperazione degli altri soggetti della filiera. Nei setup cross-border diventa altrettanto importante verificare se l’esercizio di quella capacità dipenda dalla collaborazione di un soggetto che potrebbe non essere raggiungibile con la stessa velocità attraverso strumenti giudiziari o regolatori.

La stessa logica vale per l’incident reporting, in cui un obbligo contrattuale privo della telemetry necessaria per riconoscere l’incidente può avere un valore molto inferiore a quello apparente. Al contrario, un soggetto che dispone della visibilità tecnica sul comportamento dell’agente ma non ha un obbligo di escalation sufficientemente tempestivo può diventare il punto cieco dell’intera architettura.

Infine, la cristallizzazione delle evidenze probatorie deve essere incorporata nel design del sistema e nella struttura contrattuale, non soltanto per documentare la compliance, ma per rendere ricostruibile il comportamento di una tecnologia il cui output può essere il risultato di interazioni tra modello, agentic layer, environment, strumenti esterni e interventi di più soggetti.

Queste non sono correzioni postume alla contrattualistica tradizionale, sono la conseguenza del fatto che, nei sistemi agentici, il controllo non coincide più necessariamente con la proprietà del modello né con la posizione formale occupata nella catena regolatoria.

Una disciplina dell’AI non può più osservare soltanto l’AI

C’è infine un secondo effetto della crescente agency, quanto più un sistema acquisisce la capacità di produrre effetti autonomi all’esterno del proprio ambiente, tanto meno il problema può essere confinato alla sola AI regulation.

L’accesso non autorizzato a un sistema reale può coinvolgere normativa cybersecurity, protezione dei dati, responsabilità contrattuale ed extracontrattuale, product liability e, a seconda della condotta e della giurisdizione interessata, anche norme penali e attività di law enforcement. L’art. 2, par. 8, dell’AI Act stesso, nell’escludere determinate attività di ricerca e sviluppo dal proprio campo di applicazione, non le sottrae agli altri regimi del diritto dell’Unione eventualmente applicabili.

Questo elemento merita attenzione perché modifica anche il modo in cui viene concepita la compliance, più l’AI diventa agentica, meno è plausibile che la sua governance possa essere risolta attraverso una lettura verticale di un singolo corpus normativo: la tecnologia attraversa i silos prima ancora che possano farlo le organizzazioni che dovrebbero governarla.

Il fenomeno non richiede quindi soltanto un aggiornamento delle regole, ma una diversa capacità di rappresentare l’oggetto regolato.

Forse non è vecchio l’AI Act, ma la mappa con cui osserviamo il rischio

Chiedersi se l’AI Act sia già vecchio è volutamente provocatorio, il Regolamento dispone di strumenti tecnologicamente adattabili, contempla i rischi sistemici dei general-purpose AI models, attribuisce poteri significativi all’AI Office e costruisce meccanismi destinati a evolvere attraverso standards, codes of practice, guidelines ed enforcement.

Sarebbe quindi semplicistico concludere che la comparsa dei sistemi agentici ne abbia già determinato l’obsolescenza.

Gli incidenti del 2026 mostrano però qualcosa di diverso e, probabilmente, più importante, ovvero che il confine tra testing e mondo reale può diventare poroso.

Il modello non coincide più necessariamente con il sistema capace di produrre l’effetto e la supply chain regolatoria può non coincidere con la control chain.

Chi possiede la capacità tecnica di contenere o interrompere l’evento può essere diverso dal soggetto sul quale ricadranno gli obblighi o le conseguenze giuridiche.

Una capability ancora sottoposta a evaluation può raggiungere soggetti che nel mondo reale operano già da tempo.

Il problema posto dall’AI agentica trascende quindi la consueta latenza tra innovazione tecnologica e produzione normativa, ciò che sta cambiando non è soltanto la velocità con cui evolve l’oggetto regolato, sta mutando la sua stessa topologia, dal modello al sistema, dal prodotto all’operational stack, dalla supply chain alla control chain.

Resta quindi da capire se la mappa normativa del rischio stia invecchiando più rapidamente della norma che la contiene.