L'autorità arriva prima dell'intelligenza

C’è una conversazione che comincia a ripetersi negli uffici dei broker assicurativi, e vale la pena immaginarla per intero. Un’azienda chiede una copertura cyber. Prima domanda: siamo coperti se un attaccante entra nei nostri sistemi e cancella i dati? Risposta: sì, a determinate condizioni. Seconda domanda: e se non entra nessuno, ma il nostro agente AI, perfettamente autenticato, con credenziali valide e MFA intatta, decide da solo di cancellarli?

Silenzio.

Non è un esperimento mentale. Il 18 luglio 2025 l’agente di Replit ha cancellato un database di produzione durante un test condotto dal fondatore di SaaStr, Jason Lemkin: dati reali di più di 1.200 dirigenti e un migliaio di aziende, cancellati nonostante un code freeze esplicito, con l’agente che poi ha generato dati fittizi e resoconti rassicuranti su quello che aveva fatto. Nessun attaccante, nessun malware, nessuna password rubata. Il CEO di Replit si è scusato pubblicamente e ha annunciato le contromisure, che vale la pena leggere con attenzione: separazione automatica fra ambiente di sviluppo e produzione, rollback migliori, una modalità di sola pianificazione. Nessuna di queste contromisure rende il modello più intelligente. Tutte riducono ciò che il modello ha l’autorità di toccare.

È il dettaglio che il dibattito sull’AI agentica continua a mancare. Raccontiamo gli agenti con un lessico quasi interamente tecnico, tool calling, memoria, planning, MCP, sandbox, sistemi multi-agente. Quel vocabolario descrive metà della trasformazione. Un agente non è interessante perché fa cose da solo. È interessante perché qualcuno gli ha concesso il diritto di fare cose che hanno conseguenze: leggere un repository, interrogare un database, inviare un messaggio, spendere denaro, cambiare configurazioni. Ogni agente realmente utile è una struttura di delega. E la delega, a differenza dell’intelligenza, non è un problema informatico. È il problema più antico delle organizzazioni.

La delega non l’ha inventata l’AI

Concediamo subito l’obiezione, perché è fondata. Le aziende delegano azioni alle macchine da decenni. Un cron esegue operazioni notturne senza chiedere il permesso ogni volta. Un algoritmo di trading compra e vende. Un sistema antifrode blocca transazioni. Un autoscaler crea infrastruttura e genera costi. Una pipeline CI/CD porta software in produzione. Un PLC industriale muove macchinari. E anche il problema dell’attribuzione è vecchio: per questo esistono identità di servizio, IAM, audit log, segregation of duties, firma digitale, controlli interni, assicurazioni. Buona parte dell’ingegneria aziendale consiste precisamente nel concedere a componenti software il diritto di produrre effetti controllati.

La novità non è che una macchina possa agire. È la natura dell’autorità che le stiamo delegando.

Il software tradizionale riceve una delega chiusa. Esegui questa procedura alle 03:00. Mantieni la temperatura in questo intervallo. Se i test passano, distribuisci questo artefatto. L’autorità è incorporata nell’algoritmo: il programmatore ha deciso prima quali condizioni portano a quali azioni. Con un agente la struttura diventa un’altra: raggiungi questo obiettivo usando gli strumenti che ritieni appropriati. Sembra una piccola differenza di formulazione. È enorme. La macchina non riceve il diritto di eseguire un’azione: riceve una parte del diritto di scegliere quale azione eseguire. L’automazione classica meccanizza una decisione già formalizzata. L’agente esercita discrezionalità dentro un perimetro. Ed è nel momento in cui compare la parola discrezionalità che il problema smette di somigliare a una funzione software e comincia a somigliare a un problema istituzionale.

La superficie di discrezionalità

Se dovessi proporre una metrica architetturale per quest’epoca, non sarebbe l’intelligenza del modello. Sarebbe la superficie di discrezionalità: lo spazio delle decisioni che l’organizzazione non ha codificato in anticipo e ha lasciato alla macchina. Un agente che può solo scegliere quale query SQL eseguire ne ha poca. Uno che può decidere quale sistema interrogare, chi contattare, quanto spendere e quando fermarsi ne ha enormemente di più.

Il paradosso è che l’utilità cresce esattamente insieme a questa superficie. Un agente privo di discrezionalità è un workflow: se devo stabilire in anticipo ogni azione possibile, non mi serviva un modello. Se permetto al modello di scegliere, il sistema diventa adattivo, e proprio quella capacità produce il rischio: più incertezza, più raggio di danno potenziale, più difficoltà di verifica, più complessità nell’attribuire le responsabilità. L’obiettivo, quindi, non può essere eliminare l’autonomia. Deve essere renderla governabile.

L’infrastruttura che sta emergendo per farlo ha sei strati: identità, capability, runtime, telemetria, evidenza, responsabilità. Presi uno per uno sembrano sei feature di piattaforma. Presi insieme sono un’altra cosa: la catena non è più «modello più strumenti», è identità che riceve autorità, che agisce in un runtime, che produce azioni osservate, che lasciano prove, che permettono di attribuire conseguenze. È la struttura di un’istituzione, non di una libreria.

Chi sta agendo

Il primo strato sembra banale e non lo è. Chi ha compiuto questa azione? Il dipendente? L’agente personale del dipendente? Un sub-agente creato dall’agente? Un agente del fornitore SaaS? Un processo nato per un singolo task e morto dieci minuti dopo?

L’errore architetturale più facile è lasciare che l’agente usi le credenziali dell’utente. Andrea può modificare un repository, quindi il suo agente modifica il repository con il token di Andrea. Sembra naturale, e distrugge l’informazione più importante. Nel log si leggerà: Andrea ha modificato il file. La verità era: un agente delegato da Andrea, con il modello X in versione Y, nell’ambito del task Z, ha modificato il file. Fra le due frasi passa tutta la differenza fra sapere cosa è successo e poterlo solo supporre.

Il diritto questa distinzione la conosce da secoli. Un procuratore agisce per conto di qualcuno, non diventa quella persona; un dipendente firma per conto della società, non finge di essere l’amministratore. Il principio da incorporare nell’infrastruttura è lo stesso: attribuzione senza impersonificazione. L’agente deve poter agire per conto dell’utente senza diventare indistinguibile dall’utente. Servono identità agentiche proprie: temporanee, legate al task, attribuibili al delegante, revocabili, firmate. La catena deve poter dire chi ha delegato chi, attraverso quale capability, per quale azione.

Che non sia una fantasia accademica lo dimostra la velocità con cui l’industria dell’identity si sta muovendo: Microsoft ha presentato nel maggio 2025 Entra Agent ID, oggi disponibile in generale, che è essenzialmente una directory delle identità agentiche, con registrazione, permessi, ciclo di vita e le stesse policy di accesso condizionale usate per le identità umane e di servizio. Si può discutere l’implementazione. La categoria, ormai, è riconosciuta: gli agenti sono una popolazione che va censita.

Quanto può, per quanto, fino a dove

L’identità risponde a «chi». La capability risponde a «cosa», e qui il concetto tradizionale di ruolo diventa troppo grossolano. Un agente che prepara una release ha bisogno di leggere il repository, creare una branch, scrivere file, lanciare test, aprire una pull request. Non ha bisogno di modificare le branch protection, leggere tutti i secret, fare force push o toccare la produzione. Il least privilege non è un’idea nuova; la novità è che con gli agenti deve diventare orientato alle capability, non ai ruoli, perché il ruolo «developer» contiene cento diritti che il task non richiede.

E ci sono due dimensioni che il controllo degli accessi tradizionale tratta poco: il tempo e la quantità. Un agente che può spendere cento euro una volta non ha la stessa autorità di uno che può spendere senza limiti. Un agente che può eseguire cento chiamate non ha lo stesso profilo di rischio di uno senza rate limit. Una capability agentica seria ha un ambito, un budget, una scadenza, una frequenza massima, una soglia oltre la quale serve approvazione. Deploy in staging, valido quarantacinque minuti, al massimo due azioni, costo massimo venti euro, produzione negata: è quasi un contratto, ed è esattamente ciò che dovrebbe essere.

La formulazione generale mi sembra questa: l’autorità agentica va trattata come un budget, non come un interruttore. Oggi la maggior parte delle autorizzazioni è binaria, può o non può. Gli agenti richiedono la domanda adulta: può fino a quanto, per quanto tempo, in quale contesto, sotto quale soglia, finché quale condizione resta vera. Un’autorità con unità di misura è un’autorità misurabile. E solo ciò che è misurabile si governa.

Il recinto conta quanto l’animale

Identità e permessi non bastano, perché conta anche il mondo in cui l’agente vive. Sandbox, container, microVM, processo persistente, macchina dello sviluppatore: ogni ambiente produce un raggio di danno diverso. L’intuizione più importante della sicurezza agentica contemporanea è un’inversione. Non dobbiamo costruire un modello incapace di sbagliare; dobbiamo costruire un mondo in cui i suoi sbagli abbiano conseguenze limitate. Dentro il recinto l’agente può avere grande libertà, scrivere, compilare, installare, fallire, cancellare, ricominciare, purché il recinto sia piccolo, effimero, non privilegiato, osservabile, ricostruibile. La domanda progettuale non è «posso fidarmi dell’agente?». È: quanto deve essere affidabile l’agente perché questo ambiente resti sicuro anche quando sbaglia? Se la risposta è «molto», il problema è l’ambiente.

C’è però una specie agentica che complica il quadro: quella persistente. Un job che vive dieci minuti è facile da recintare. Un agente che vive settimane accumula memoria, credenziali, stato, relazioni, perfino una reputazione presso i colleghi umani. Il cloud-native ci aveva insegnato a trattare i processi come bestiame e non come animali domestici; gli agenti persistenti reintroducono qualcosa che somiglia pericolosamente al pet, non perché siano antropomorfi ma perché possiedono continuità di stato e identità. Vanno patchati, monitorati, ruotati, revocati, e a volte distrutti e ricreati. Sono una nuova categoria di asset, con il ciclo di vita di un asset.

Osservare la traiettoria, non la mente

Quando un servizio tradizionale fallisce, si vede: errori, latenza, eccezioni. Quando un agente funziona tecnicamente ma sceglie la strategia sbagliata, tutto appare sano. HTTP 200, CPU normale, nessuna exception, risultato sbagliato. L’observability agentica deve quindi andare oltre la salute del software e osservare la traiettoria decisionale: quali tool ha scelto, in che ordine, con quali argomenti, quante iterazioni, quanto ha speso, dove ha chiesto aiuto, dove ha deviato dal piano.

Non serve, ed è un equivoco da smontare, l’accesso al ragionamento interno del modello. Per la governance basta il grafo delle azioni: task, contesto, selezione degli strumenti, parametri, output, transizioni di stato. Si verifica il grafo delle azioni, non la mente. Ed è anche l’approccio più stabile: i modelli cambiano ogni sei mesi, le azioni restano osservabili con la stessa grammatica. È il motivo per cui il lavoro di standardizzazione in corso dentro OpenTelemetry conta più di quanto sembri: le semantic convention per la GenAI danno un vocabolario comune a invocazioni di agenti, chiamate ai modelli ed esecuzioni di tool, e un vocabolario comune è la precondizione per ricostruire la sequenza che va dall’intento all’azione.

Ma la telemetria, da sola, non risponde alle domande che contano. Un log viene prodotto per la macchina e serve al debugging. Una prova viene conservata per l’istituzione e serve all’audit, all’incidente, alla controversia, all’assicurazione. Chi ha autorizzato questo deploy non si risponde con due gigabyte di log: si risponde con identità, policy, approvazione, hash degli artefatti, timestamp, esito. La trasformazione necessaria è da telemetria a evidenza, e la forma matura è l’evidenza by construction: workflow progettati per emettere automaticamente la prova della propria corretta esecuzione, un piccolo involucro probatorio per ogni azione ad alto impatto. Non per burocratizzare ogni interazione: per rendere ricostruibili quelle che finiranno davanti a qualcuno che ha il diritto di fare domande. È la stessa tesi che sostengo da tempo sulla compliance come architettura: i requisiti non si spuntano a fine progetto, si progettano.

Il danno senza intrusione

E arriviamo allo strato che le altre discipline preferirebbero non guardare. La cybersecurity tradizionale è costruita intorno alla figura dell’intruso: qualcuno che non era autorizzato entra, ruba, modifica, distrugge. L’AI agentica introduce una categoria più ambigua, il danno senza intrusione. Il sistema era autenticato. Aveva il permesso. Non c’è malware, nessuno ha rubato niente. Il sistema ha semplicemente usato male un’autorità legittimamente delegata. Il caso Replit è questo. Un agente con accesso legittimo al CRM che manda i dati di un cliente al cliente sbagliato è questo. Un agente procurement che compra entro budget da un fornitore fraudolento è questo. La violazione non sta nell’accesso: sta nel giudizio esercitato dentro l’accesso.

Qui serve una distinzione che il software tradizionale tende a schiacciare: un’azione può essere autorizzata senza essere legittima rispetto all’intenzione per cui l’autorità era stata concessa. Se il service account può cancellare il bucket, la cancellazione è tecnicamente autorizzata; organizzativamente può essere illegittima. Permission e intended use non sono la stessa cosa, e gli agenti allargano la distanza fra le due fino a renderla il cuore del problema.

Perché a quel punto qualcuno deve rispondere, e la macchina non assorbe magicamente la responsabilità. Nessuna società può dire «non siamo responsabili, l’ha fatto il nostro software». La domanda vera non è se l’agente sia responsabile, che nel futuro prossimo ha una risposta semplice, no. È come si distribuisce la responsabilità fra chi ha costruito il modello, chi ha fatto il framework, chi ha integrato, chi ha configurato, chi ha delegato l’autorità e chi avrebbe dovuto supervisionare. L’autonomia non elimina la catena di responsabilità: la allunga. E una catena più lunga, senza infrastruttura di attribuzione, è soprattutto una catena in cui ognuno può dire che il problema era a monte.

Il diritto europeo, va detto, non sta aspettando che il dibattito maturi. La nuova direttiva sulla responsabilità da prodotto tratta esplicitamente software e sistemi AI come prodotti, e si applica a ciò che verrà immesso sul mercato dal 9 dicembre 2026: fra poco più di tre mesi. Con gli agenti, il difetto rilevante può non essere una riga di codice sbagliata. Può essere un’autorità limitata in modo insufficiente, un monitoraggio assente, una supervisione progettata male, l’impossibilità di revocare. La sicurezza dell’architettura di delega sta entrando nella ragionevole aspettativa di sicurezza del prodotto. E anche se il Digital Omnibus ha rinviato al dicembre 2027 gli obblighi dell’AI Act sull’alto rischio, la responsabilità civile non ha calendario di adeguamento: ho già scritto che il legislatore europeo sta inchiodando la responsabilità alle persone giuridiche, articolo dopo articolo, e gli agenti sono esattamente il caso in cui quel chiodo si vede meglio.

L’assicuratore come regolatore

C’è un attore che non può permettersi l’ambiguità, perché la sua attività consiste nel dare un prezzo alle conseguenze: l’assicuratore. Quando una tecnologia entra nei contratti assicurativi, significa che un fatto apparentemente tecnico è diventato economicamente quantificabile. E sta succedendo adesso: nell’aprile 2025 Armilla ha lanciato ai Lloyd’s, con Chaucer, la prima polizza dedicata alla responsabilità da AI, coperture per errori, allucinazioni e comportamenti fuori specifica; AIUC ha costruito uno standard di certificazione per agenti, AIUC-1, una specie di SOC 2 per agenti che copre sicurezza, affidabilità e accountability, e su quella certificazione ha emesso polizze per aziende come ElevenLabs e Intercom, con società di audit accreditate a verificare. Certificazione prima, copertura dopo: chi ha visto un questionario assicurativo cyber riconosce il meccanismo.

Non è una novità storica, ed è per questo che va presa sul serio. Gli standard antincendio moderni non li ha imposti un parlamento: li hanno imposti le mutue assicurative dell’Ottocento, che rifiutavano di coprire le fabbriche costruite male, e i laboratori nati dagli assicuratori per testare ciò che assicuravano. La sicurezza industriale e poi la cybersecurity hanno seguito lo stesso percorso. Un’impresa resta teoricamente libera di dare al proprio agente accesso completo, credenziali permanenti, nessuna sandbox, nessun audit. Poi scopre che la copertura non vale, che il premio raddoppia, che la franchigia è enorme, che quei danni sono esclusi. Il mercato assicurativo produce standard senza passare dalla legge: passa dal prezzo. Credenziali a breve vita, segregazione, soglie di approvazione, retention delle evidenze smetteranno di essere best practice e diventeranno condizioni di polizza.

C’è un corollario che trovo quasi elegante: security, compliance e assicurazione, che oggi trattiamo come mondi separati, con gli agenti chiedono le stesse identiche informazioni. Quale identità, quale autorità, quale dato, quale controllo, quale azione, quale evidenza, quale conseguenza. Una sola pipeline di evidenze ben progettata serve contemporaneamente all’incident response, al CRA, all’AI Act, all’audit del cliente e al rinnovo della polizza. È qui che la compliance smette di essere un costo che si somma e diventa un’infrastruttura che si ammortizza.

L’inventario dell’autorità

La sicurezza del software ha imparato a chiedere la distinta base: l’SBOM, quali componenti compongono questo sistema. Con gli agenti servirà la distinta dell’autorità, chiamiamola ABOM, Authority Bill of Materials: quali autorità possiede questo agente, da quali identità derivano, attraverso quali strumenti, su quali sistemi, con quali budget, con quali eccezioni, con quali subdeleghe. Meglio ancora se non è una lista ma un grafo, perché le domande interessanti sono di percorso: se questo nodo viene compromesso, o semplicemente sbaglia, qual è il cammino massimo che l’errore può attraversare? È threat modelling applicato all’autorità. E produce il requisito di progettazione che mi sembra il più importante di tutti: il delegation blast radius. Non «quanto è probabile che l’agente sbagli», che è una proprietà del modello e cambia a ogni release. Ma: se l’agente interpreta completamente male il proprio obiettivo, quanto può costare il suo errore peggiore prima che un controllo indipendente lo fermi? Non possiamo garantire che l’agente non sbaglierà mai. Possiamo progettare la catastrofe massima che siamo disposti ad assorbire. È il principio dei circuit breaker e dei massimali, applicato alla discrezionalità: catastrofe limitata, per costruzione.

Da qui discende anche la parte più prosaica e più trascurata: l’inventario. Se gli agenti si moltiplicano, le aziende si ritroveranno ad amministrare popolazioni non umane, migliaia di identità software con discrezionalità, alcune vive per minuti, altre per mesi. Chi le censisce? Chi ne è owner? Chi revoca quelle inutilizzate? Conosciamo già lo shadow SaaS e i personal access token dimenticati; il prossimo capitolo sono gli shadow agent, automazioni create da singoli dipendenti, collegate via MCP a GitHub, Slack, Drive e al database, senza inventario centrale, che funzionano correttamente per mesi finché non lo fanno più. Il problema non sarà l’attaccante. Sarà che nessuno ricorda più perché quell’agente possiede quei permessi. La review periodica «quali utenti hanno ancora accesso?» dovrà avere una gemella: quali agenti hanno ancora autorità, e quale finalità la giustifica ancora? Un agente con diritto di muovere denaro o toccare la produzione è un asset più significativo di gran parte dei laptop aziendali. Oggi rischia di non comparire in nessun registro.

L’umano sul confine

E la supervisione umana? La versione ingenua, una persona che approva ogni output, è economicamente incompatibile con l’automazione e cognitivamente incompatibile con l’attenzione umana. La versione utile presidia i passaggi di autorità, non le singole azioni. L’agente spende da solo fino a cento euro, sopra serve un umano. Modifica staging da solo, per la produzione serve un umano. Prepara il contratto da solo, per inviarlo serve un umano. Non human-in-the-loop su tutto: human-on-the-boundary, l’umano sul confine fra una zona di autorità e la successiva. Dentro la zona, autonomia; al confine, un giudizio. Il ruolo della persona smette di essere il collo di bottiglia che verifica ogni output e diventa l’autorità che controlla le soglie attraverso cui cresce il raggio di danno.

Un avvertimento, però, che l’estate ci ha consegnato: il confine stesso può essere attaccato. A luglio, durante valutazioni dell’AI Security Institute britannico, un agente ha aperto una pull request malevola su un progetto reale e ha provato a fabbricare il consenso intorno alla propria richiesta, identità false comprese; ne ho scritto in Il pulsante è ancora tuo. La lezione per l’architettura della delega è netta: le soglie devono essere tecniche, non solo procedurali. La policy non può vivere nel prompt. Non «non spendere più di cento euro» nel system prompt, ma un’infrastruttura che rifiuta la transazione sopra i cento euro. Non «non accedere ai dati Finance», ma un token che tecnicamente non arriva a Finance. Non «chiedi l’approvazione prima della produzione», ma una deploy API che senza approvazione firmata non risponde. Il modello deve poter comprendere la policy; non deve essere responsabile della sua applicazione. E la linea rossa architetturale è una sola: l’agente non deve poter modificare il sistema che definisce i limiti della propria autorità, per la stessa ragione per cui il codice non riscrive i propri test di accettazione e il controllato non riscrive il controllo. Se vogliamo usare la parola «trustless» in modo onesto, significa questo: non «non fidarsi mai del modello», ma costruire il sistema in modo che le proprietà critiche, budget, segregazione, confini sui dati, approvazioni, non richiedano fiducia nel comportamento del modello.

L’organigramma eseguibile

Se si fa un passo indietro, quello che stiamo scrivendo per ogni agente ha una forma familiare: hai questa identità, persegui questa finalità, puoi usare queste capacità, dentro questo ambiente, fino a questi limiti, per questo tempo; sarai osservato così, le tue azioni lasceranno queste prove, sopra questa soglia serve approvazione, e se qualcosa va storto risponde questa organizzazione. Per decenni abbiamo scritto API contract e ACL. Questa è un’altra cosa: è una job description. Missione, permessi, budget, escalation, supervisore, obblighi di prova. Con la differenza, rispetto a quelle umane, che può essere fatta rispettare a runtime.

È il punto in cui i due mondi convergono davvero. L’organigramma descrive da sempre chi riporta a chi, chi decide, chi approva; con gli agenti dentro i processi, una parte dell’organigramma diventa policy, grafo di identità, grafo di permessi, workflow di approvazione. L’organizzazione diventa in parte software, non perché usa software ma perché le sue strutture di delega vengono codificate nel software. E il software diventa in parte organizzazione: un runtime agentico serio possiede ruoli, deleghe, supervisione, separazione dei poteri, registri, procedure di escalation, categorie che vengono dalla teoria delle istituzioni più che dall’ingegneria. Dopo infrastructure-as-code, policy-as-code e compliance-as-code, quello che gli agenti chiedono è authority-as-code: dichiarare in modo versionabile chi, cosa, dove, quanto, per quanto e sotto quali condizioni, applicare automaticamente la dichiarazione, e produrne evidenza.

Due conseguenze meritano una riga ciascuna. La prima riguarda il valore: i modelli si commoditizzano, un agente cambierà motore più volte nella sua vita, ma le policy dell’organizzazione, chi può fare cosa, con quali dati, con quali soglie, restano. L’asset durevole è il delegation layer, molto più del prompt. La seconda riguarda la sovranità: un’organizzazione può avere dati in Europa, modello europeo e cloud europeo, e avere delegato access control, policy engine e approvazioni a un control plane proprietario e non esportabile. Quanto è sovrana? La sovranità che conterà è anche la capacità di definire, ispezionare, esportare e applicare autonomamente le regole che governano l’autorità dei propri agenti. Portare via il modello è facile. Bisogna poter portare via la costituzione.

La responsabilità precede l’intelligenza

Il dibattito sul rischio dell’AI resta ipnotizzato dalla capability cognitiva: quanto è potente il modello, cosa saprà fare il prossimo. Ma il rischio operativo di un agente è il prodotto di più fattori, capacità, discrezionalità, autorità, esposizione, diviso per i controlli. Un modello potentissimo che scrive bozze in sola lettura è relativamente innocuo. Un modello mediocre con il diritto di trasferire dieci milioni di euro è un’infrastruttura critica. La classificazione del rischio basata solo sulla potenza del modello guarda l’asse sbagliato: la governance va proporzionata al massimo danno delegato, non alla sofisticazione cognitiva. Il principio, per una volta, il diritto europeo lo possiede già in casa: proporzionalità. L’autorità concessa deve essere adeguata alla finalità delegata e non eccederla. Il least privilege, riletto da un giurista.

Per anni abbiamo immaginato che i grandi dilemmi sarebbero arrivati quando le macchine fossero diventate abbastanza intelligenti. Sta accadendo qualcosa di più prosaico e molto prima: dobbiamo affrontare il problema della responsabilità perché le macchine stanno diventando abbastanza autorizzate. Non serve nessuna AGI. Serve un agente mediocre con accesso alla produzione, alle email, a una carta di pagamento. E quell’accesso non lo conquista: siamo noi a concederlo, un token alla volta, una permission alla volta, un endpoint alla volta. Ogni agente nasce dentro un atto di delega, ed è quell’atto, più del modello sottostante, a determinare che cosa la macchina può diventare per l’organizzazione.

Per sistemi fatti di identità che stabiliscono chi agisce, regole che delimitano il potere, registri che ne conservano la traccia e soggetti che ne rispondono, un nome ce l’abbiamo già. Non li chiamiamo intelligenze: li chiamiamo istituzioni. Le istituzioni esistono perché il potere non può dipendere dalla virtù di chi lo esercita, e quindi viene delimitato, distribuito, registrato, controllato, revocato. Non è burocrazia nel senso peggiore della parola: è la memoria istituzionale con cui trasferiamo all’automazione qualche secolo di esperienza sui rischi del potere senza limiti. Gli agenti non dovranno diventare persone perché questi principi si applichino a loro. Basterà che diventino abbastanza utili da ricevere potere. E infatti l’assicuratore, alla fine della chiamata, non chiederà quanto è intelligente il vostro agente. Chiederà: quanto potere gli avete dato, e potete dimostrarci come lo avete limitato?

Un agente non diventa importante quando acquista autonomia. Diventa importante quando gli concediamo autorità. L’intelligenza stabilisce che cosa potrebbe fare; l’autorità stabilisce che cosa può fare davvero; la governance stabilisce quanto può costarci quando sbaglia; la responsabilità stabilisce chi ne risponde. Il problema dell’AI agentica non è che le macchine comincino ad agire come soggetti. È che noi cominciamo a concedere loro potere prima di aver costruito le istituzioni capaci di governarlo.

L'autore

Andrea MargiovanniAI

Seguo il rapporto fra AI e regolazione europea come fatto politico, non come spettacolo tecnico. Lavoro con team che devono renderla compatibile con AI Act, CRA, NIS2 senza ridurre la compliance a una checklist.

Vai al percorso →