L'infrastruttura degli agenti AI di Mozilla mette le regole al di sopra del giudizio del modello
Mozilla AI ha messo in discussione un presupposto centrale alla base degli agenti di coding: un migliore giudizio del modello, da solo, non può rendere sicuro il lavoro software delegato.
La sua argomentazione sull'infrastruttura degli agenti arriva mentre gli agenti acquisiscono l'autorità di ispezionare repository, modificare codice, eseguire test e preparare pull request. Queste capacità possono comprimere ore di lavoro in pochi minuti. Offrono però anche a sistemi probabilistici l'accesso a operazioni dalle conseguenze durature.
La tesi di Mozilla AI sull'infrastruttura degli agenti trasforma il confronto da capacità contro capacità a istruzioni contro controllo applicabile. Un file AGENTS.md può indicare a un agente ciò che dovrebbe fare. Solo l'infrastruttura può impedire le azioni che non deve mai compiere.
Questa distinzione mette sotto pressione ogni organizzazione che amplia l'autonomia degli agenti. OpenAI, Anthropic, Google, GitHub e gli sviluppatori indipendenti offrono esperienze diverse con gli agenti. Eppure ogni implementazione finisce per affrontare la stessa domanda: cosa resta vero quando il modello fraintende una regola?
Cosa cambia l'infrastruttura degli agenti AI di Mozilla
Mozilla AI sta spostando il dibattito sugli agenti dall'intelligenza del modello ai sistemi che circondano ogni decisione del modello.
Gli agenti di coding non operano più soltanto come interfacce di chat. Possono cercare in una base di codice, modificare diversi file, eseguire comandi shell, avviare una suite di test e assemblare una modifica proposta. Alcuni sistemi possono continuare a lavorare mentre uno sviluppatore si occupa di un'altra attività.
Questa portata più ampia rende l'infrastruttura parte del prodotto, anziché un dettaglio implementativo. Una risposta sbagliata in una finestra di chat crea un tipo di rischio. Un comando errato con accesso a repository, rete o credenziali ne crea un altro.
L'intervento di Mozilla AI è importante perché separa tre responsabilità che i team spesso confondono. Le istruzioni descrivono il comportamento desiderato. I modelli interpretano tali istruzioni. L'infrastruttura decide quali azioni sono tecnicamente possibili.
La distinzione sembra semplice, ma molte implementazioni di agenti ribaltano questa gerarchia. Concedono prima un accesso ampio, poi chiedono al modello di esercitare moderazione attraverso regole in linguaggio naturale. Questo approccio rende il modello sia il lavoratore sia il proprio principale sistema di controllo.
Un'istruzione nel repository potrebbe stabilire di non pubblicare mai direttamente da un feature branch. Potrebbe richiedere un'approvazione prima di modificare il codice di autenticazione. Potrebbe vietare la lettura di file al di fuori di una directory specifica.
Queste affermazioni migliorano il comportamento quando l'agente le legge, interpreta e assegna loro la corretta priorità. Non creano però confini del sistema operativo, policy di rete o controlli di approvazione. Il modello può comunque richiedere un'azione che viola la regola scritta.
Il diffuso formato per le istruzioni degli agenti offre una convenzione utile per il contesto di progetto. Il suo sito pubblico descrive AGENTS.md come un luogo prevedibile per comandi di build, istruzioni di test, convenzioni e considerazioni sulla sicurezza. Riporta inoltre un'adozione in oltre 60.000 progetti open source.
Questa adozione mostra perché le istruzioni portabili sono importanti. I team non dovrebbero riscrivere le stesse indicazioni sul repository per ogni prodotto di coding. Un formato condiviso permette alle regole di viaggiare tra gli agenti e di restare visibili accanto al codice.
Tuttavia, la portabilità non trasforma la prosa in applicazione delle regole. Markdown non ha autorità su una shell, un account cloud, un registro di pacchetti o un database di produzione. Influenza il modello che lo legge, mentre il runtime continua a controllare il mondo raggiungibile.
Mozilla AI sta quindi identificando un livello mancante. Le implementazioni di agenti necessitano di controlli esterni al ciclo del modello, dove un'interpretazione errata non possa concedersi silenziosamente un'eccezione.
Questo non rende AGENTS.md meno prezioso. Assegna al file un compito più chiaro. Le istruzioni dovrebbero comunicare l'intento, mentre l'infrastruttura dovrebbe applicare il confine attorno a tale intento.
L'inversione pratica è significativa. I team hanno considerato un migliore ragionamento come la via verso un'autonomia più sicura. Mozilla AI sostiene che un'autonomia affidabile cominci dall'assumere che il ragionamento a volte fallirà.
Gli agenti di coding trasformano i suggerimenti in effetti collaterali
Più lavoro un agente può completare, meno è accettabile affidarsi al buon giudizio come confine finale di sicurezza.
Gli assistenti di codice tradizionali suggerivano principalmente testo che una persona poteva rivedere. Lo sviluppatore decideva se inserire il suggerimento, eseguire un comando o inviare una modifica a monte. Questa azione umana costituiva un naturale punto di controllo.
Gli strumenti agentici comprimono questi punti di controllo. Un singolo incarico può attivare la scoperta di file, l'installazione di dipendenze, la generazione di codice, l'esecuzione di test e operazioni sul repository. Ogni passaggio crea un nuovo contesto che orienta la successiva decisione del modello.
Questo ciclo è utile perché il lavoro software raramente rientra in un unico prompt e una sola risposta. Un agente deve osservare i risultati, rivedere le proprie ipotesi e tentare un altro approccio. Lo stesso ciclo amplifica anche gli errori iniziali.
Si consideri un agente incaricato di correggere un test di integrazione non riuscito. Potrebbe ispezionare file di ambiente, avviare servizi, aggiornare dipendenze e rigenerare snapshot. Un'istruzione vaga può portarlo ben oltre il test previsto.
Il fallimento non richiede un comportamento malevolo. L'agente potrebbe dedurre che un comando di pulizia distruttivo sia ordinario. Potrebbe interpretare una credenziale di test come usa e getta. Potrebbe fidarsi di testo recuperato da un issue, una dipendenza o una pagina web.
Il prompt injection rende quest'ultimo scenario particolarmente importante. Un agente può imbattersi in istruzioni ostili all'interno di contenuti che gli è stato chiesto di elaborare. Il modello deve quindi distinguere i dati del compito dai comandi, continuando al contempo il proprio lavoro.
Le indicazioni in linguaggio naturale aiutano, ma il modello rimane il componente che decide se altro linguaggio naturale sia affidabile. È un punto instabile in cui collocare il confine finale.
L'infrastruttura di esecuzione può restringere le conseguenze. L'architettura sandbox di OpenAI separa l'harness affidabile dall'ambiente in cui vengono eseguiti i comandi diretti dal modello. L'harness può gestire approvazioni, tracciamento, ripristino e stato al di fuori del contenitore di esecuzione.
Questa separazione illustra il meccanismo più ampio. L'agente può lavorare in un ambiente senza ereditare automaticamente ogni credenziale o risorsa disponibile all'organizzazione. L'infrastruttura media ciò che attraversa il confine.
Un agente di coding incaricato di aggiornare la documentazione non dovrebbe aver bisogno di credenziali per la pubblicazione di pacchetti. Un agente che ripara un servizio non dovrebbe accedere automaticamente a repository non correlati. Un'attività di scrittura di test non dovrebbe comportare permessi sul database di produzione.
Si tratta di decisioni sulle capacità, non di decisioni sulla scrittura dei prompt. Una capacità è un'azione che il runtime consente, come scrivere in una directory o chiamare un endpoint approvato. Una buona infrastruttura concede capacità in base al compito corrente.
La pressione ricade anzitutto sui team di piattaforma e sicurezza. Gli sviluppatori vogliono che gli agenti agiscano con minore supervisione perché l'autonomia genera il guadagno di produttività. I team di sicurezza devono garantire che una supervisione ridotta non diventi autorità illimitata.
Ricade anche sui fornitori. Un'interfaccia per agenti curata può nascondere controlli operativi deboli. Gli acquirenti devono guardare oltre i risultati dei benchmark e chiedere come il sistema gestisca identità, credenziali, approvazioni, log, tentativi e ripristino.
La stessa questione riguarda gli sviluppatori individuali. Un agente locale può sembrare contenuto perché gira su un solo laptop. Tuttavia, quella macchina può contenere codice sorgente, sessioni del browser, credenziali cloud, documenti personali e chiavi di firma.
Un agente non necessita di accesso amministrativo per causare danni significativi. Gli basta una credenziale con più autorità di quanto il compito richieda. L'infrastruttura deve rendere più difficile creare questa discrepanza.
Ecco perché la notizia non è semplicemente un altro appello all'AI responsabile. Mozilla AI sta spostando la responsabilità dal comportamento del modello alla progettazione del sistema. Questo assegna l'onere a componenti che le organizzazioni possono ispezionare e testare.
AGENTS.md spiega le regole ma non può applicarle
Il conflitto principale è ora esplicito: i file di istruzioni esprimono l'intento umano, mentre i controlli runtime determinano ciò che un agente può effettivamente fare.
AGENTS.md risolve un reale problema di coordinamento. Un agente di coding ha bisogno di comandi, convenzioni del repository, requisiti di convalida e avvisi locali. Mantenere questo contesto vicino al codice lo rende visibile, versionato e riutilizzabile.
Il formato permette inoltre ai team di definire istruzioni più specifiche all'interno di repository di grandi dimensioni. Un servizio può avere comandi di test o restrizioni diversi rispetto alla radice del repository. Questo ricorda la documentazione a livelli già usata dagli esseri umani.
Eppure ogni istruzione passa comunque attraverso l'interpretazione del modello. L'agente deve trovare il file rilevante, risolvere regole sovrapposte, applicarle al compito corrente e ricordarle durante un'esecuzione lunga.
Qualsiasi fallimento in questa catena può indebolire la regola. Il file potrebbe essere incompleto. Il contesto potrebbe essere troncato. Un'istruzione annidata potrebbe entrare in conflitto con un'istruzione alla radice. Il modello potrebbe generalizzare un'eccezione in modo troppo ampio.
Nemmeno una perfetta osservanza delle istruzioni può risolvere ogni problema. Una regola può dire di ottenere approvazione prima di pubblicare un pacchetto. L'agente necessita comunque di un meccanismo di approvazione affidabile e di un'identità autorizzata ad approvare.
Se l'approvazione esiste solo come un altro messaggio nel contesto, contenuti non affidabili possono imitarla. Un sistema più robusto rappresenta l'approvazione come stato esterno che il modello non può fabbricare. Il runtime verifica quello stato prima di rilasciare l'azione.
Lo stesso principio si applica ai limiti di spesa. Dire a un agente di risparmiare token è un'indicazione utile. Un budget applicato dal control plane resta efficace quando un ciclo dura più del previsto.
L'auditabilità rivela un'altra limitazione. Un'istruzione può richiedere all'agente di spiegare le proprie scelte. Tale spiegazione non costituisce automaticamente un record completo di input degli strumenti, stato dei permessi, modifiche ai file, tentativi o azioni rifiutate.
Un audit trail affidabile deve acquisire eventi al di fuori della narrazione dell'agente. Dovrebbe mostrare quale identità ha richiesto un'azione, quale policy è stata valutata, quali input hanno raggiunto lo strumento e quale risultato è stato restituito.
Il record dovrebbe conservare anche i fallimenti. Un agente che ha tentato tre azioni vietate prima di trovare un percorso consentito racconta una storia diversa da uno che ha selezionato subito il percorso consentito. Il solo output finale nasconde questa differenza.
Questo conta durante gli incidenti. I team devono ricostruire ciò che l'agente ha visto e quale autorità deteneva in quel momento. La documentazione corrente non è sufficiente se policy, prompt o credenziali sono cambiati in seguito.
L'infrastruttura dovrebbe quindi collegare un'azione a una specifica esecuzione, versione della policy, versione dello strumento e stato di approvazione. Ciò rende la revisione successiva meno dipendente dalla memoria o da trascrizioni di chat ricostruite.
I log supportano anche il miglioramento ingegneristico. I team possono identificare comandi che richiedono ripetutamente interventi, policy che generano falsi positivi e compiti che superano l'ambito previsto. Questi schemi possono guidare permessi più circoscritti e flussi di lavoro migliori.
Gli sviluppatori hanno comunque bisogno di istruzioni ben scritte. L'obiettivo non è sostituire l'intento umano con policy rigide. Molte decisioni software richiedono un contesto che non può essere catturato da una regola del filesystem.
Il design migliore assegna a ogni livello un ruolo appropriato. AGENTS.md indica all'agente come funziona il progetto. Un livello di policy decide se un'azione proposta rientra nell'ambito consentito dal compito.
Un sandbox limita le risorse esposte all’esecuzione. Un servizio di approvazione gestisce le eccezioni con conseguenze rilevanti. Un sistema di audit registra la decisione e il relativo risultato.
Insieme, questi componenti permettono alle regole di sopravvivere alla sostituzione di un modello. Un team può cambiare agenti senza dover ricostruire i propri confini più importanti nel formato di prompt di un altro fornitore.
Questa durabilità è centrale nella tesi di Mozilla AI. I modelli cambieranno frequentemente. La titolarità dei repository, gli obblighi di conformità e i rischi di produzione durano molto più a lungo.
Il control plane diventa il vero meccanismo di sicurezza
Un’infrastruttura affidabile per gli agenti inserisce policy applicabili tra la richiesta di un modello e ogni azione sugli strumenti che produce conseguenze rilevanti.
Un control plane è il livello fidato che gestisce accesso, policy, instradamento, budget e stato operativo. Il modello può proporre un’azione, ma è il control plane a decidere se e come eseguirla.
Questa architettura parte dall’identità. Ogni esecuzione di un agente necessita di un’identità distinta dall’operatore umano e dagli altri processi automatizzati. Le credenziali condivise rendono difficile l’attribuzione e imprecisa la revoca delle autorizzazioni.
Il requisito successivo è il privilegio minimo. Ogni attività riceve soltanto i file, i comandi, i servizi e le destinazioni di rete di cui necessita. Le autorizzazioni dovrebbero scadere con l’attività, invece di restare disponibili per esecuzioni future.
Le linee guida di OpenAI sulla sicurezza dei sandbox raccomandano workload isolati, traffico in uscita limitato, credenziali separate e accesso intermediato ai servizi di terze parti. Questi controlli operano indipendentemente dall’intento del modello.
Le credenziali intermediate sono particolarmente utili. L’ambiente di esecuzione può inviare una richiesta approvata senza vedere un segreto riutilizzabile. Un proxy fidato fornisce le credenziali soltanto per la destinazione consentita.
Questo design riduce il valore di una divulgazione accidentale. Se il codice generato stampa il proprio ambiente, le chiavi di produzione a lunga durata non devono necessariamente comparire. Anche la revoca avviene presso l’intermediario anziché in ogni workspace.
La mediazione degli strumenti offre un ulteriore punto di applicazione. L’infrastruttura può convalidare gli argomenti, rifiutare percorsi pericolosi, limitare le frequenze delle richieste e richiedere approvazione per operazioni specifiche.
Mozilla AI ha esplorato questo schema tramite i plugin di policy mcpd. Mozilla descrive autenticazione, convalida, limitazione della frequenza e logging come funzioni che possono collocarsi tra gli agenti e i server degli strumenti.
Questa collocazione conta perché i server Model Context Protocol possono esporre azioni su file, database e applicazioni esterne. Un intermediario centrale può applicare policy coerenti senza confidare che ogni agente le riproduca correttamente.
Un control plane maturo gestisce anche lo stato. I flussi di lavoro degli agenti possono fallire dopo aver completato alcune azioni ma prima di registrare il successo. Riprovare ciecamente l’intero processo può duplicare effetti collaterali esterni.
L’infrastruttura dovrebbe sapere quali passaggi sono stati completati, quali restano sicuri da riprovare e quali richiedono riconciliazione. Una chiamata per creare una pull request, un’istruzione di pagamento o un messaggio al cliente non possono sempre essere ripetuti come la lettura di un file locale.
L’approvazione umana appartiene a confini selezionati, non dopo ogni passaggio. Richieste di approvazione costanti annullano gran parte del valore della delega. Nessuna approvazione lascia invece le decisioni con conseguenze rilevanti interamente nel ciclo del modello.
La via di mezzo utile è l’escalation basata sul rischio. La lettura di un repository può procedere automaticamente. Anche la scrittura in un branch temporaneo può procedere. Pubblicare, distribuire, modificare autorizzazioni o contattare clienti può richiedere un’autorizzazione esplicita.
Le policy dovrebbero esaminare il contesto dell’azione. Un comando può essere accettabile in un ambiente di test isolato ma vietato in produzione. Una richiesta di rete può essere consentita per la documentazione ma bloccata per endpoint sconosciuti.
I budget richiedono un’applicazione analoga. Un agente che coordina più subagenti può generare costi più rapidamente di una persona che osserva una singola chat. Il control plane può impostare limiti massimi per attività, team, fornitore o risultato.
L’open control plane di Mozilla AI collega questo argomento di governance all’instradamento dei modelli. Otari viene presentato come un livello per l’instradamento, i budget, i controlli di accesso, il deployment e il failover tra fornitori.
L’instradamento non è soltanto un’ottimizzazione dei costi. Attività diverse possono richiedere confini di privacy, obiettivi di latenza o capacità del modello differenti. L’infrastruttura può applicare queste scelte in modo coerente, anziché incorporarle nell’intero codice applicativo.
Questo approccio migliora anche la portabilità. Un’organizzazione può sostituire un modello senza rinunciare alla propria logica di policy, alle tracce storiche o ai controlli operativi. L’agente diventa un componente all’interno di un sistema di proprietà dell’organizzazione.
Per i team di ingegneria, questo può preservare la conoscenza istituzionale. Una base di conoscenza tecnica ricercabile può conservare decisioni architetturali e documentazione locale. Le policy di runtime devono comunque controllare il modo in cui gli agenti utilizzano tale conoscenza.
La chiave è la separazione. La conoscenza informa il modello. La policy ne vincola le azioni. L’audit registra ciò che è accaduto. Il recupero gestisce il lavoro incompleto.
Nessun singolo componente rende un agente affidabile. Il control plane li coordina affinché un singolo giudizio errato non determini l’intero risultato.
L’infrastruttura aperta crea controllo, non sicurezza automatica
Possedere lo stack degli agenti migliora ispezionabilità e portabilità, ma il codice aperto non elimina di per sé il rischio operativo.
Mozilla AI collega il controllo dell’infrastruttura all’apertura. È un collegamento comprensibile. Le organizzazioni non possono ispezionare, modificare o preservare pienamente un sistema di controllo che esiste soltanto oltre il confine del servizio di un fornitore.
L’infrastruttura aperta può ridurre il lock-in. I team possono mantenere le policy cambiando fornitore di modelli. Possono esaminare il codice di applicazione, aggiungere integrazioni e distribuire componenti sensibili all’interno di ambienti sotto il loro controllo.
Può anche mantenere la governance vicina all’organizzazione che sostiene il rischio. Un ospedale, una banca, un’agenzia pubblica o un’azienda software possono richiedere regole di approvazione e policy di conservazione differenti. Un singolo valore predefinito ospitato non può rappresentare ogni obbligo.
Tuttavia, la titolarità trasferisce la responsabilità. Un control plane self-hosted necessita di aggiornamenti di sicurezza, revisioni degli accessi, backup, monitoraggio e recupero testato. Un componente aperto non aggiornato può diventare una nuova debolezza.
La trasparenza non garantisce una configurazione corretta. Un team può distribuire software ispezionabile con impostazioni predefinite permissive, credenziali condivise, logging incompleto o accesso di rete senza restrizioni. Il codice sorgente può essere aperto mentre il deployment rimane non sicuro.
I log creano compromessi propri. Tracce dettagliate aiutano le indagini, ma possono acquisire codice proprietario, informazioni personali, prompt e risultati degli strumenti. Conservare tutto indefinitamente può entrare in conflitto con gli obiettivi di privacy e minimizzazione.
I team necessitano di limiti di conservazione espliciti. Dovrebbero registrare informazioni sufficienti a stabilire la responsabilità senza trasformare il sistema di audit in una copia permanente di ogni input sensibile.
La complessità delle policy è un altro rischio. Un insieme ampio di regole può diventare difficile da comprendere. Eccezioni sovrapposte possono creare lacune, mentre controlli eccessivamente rigidi possono spingere gli sviluppatori verso strumenti non autorizzati.
La risposta non è semplicemente più policy. I team hanno bisogno di controlli piccoli e testabili, legati a rischi specifici. Ogni regola dovrebbe avere un responsabile, una motivazione e un metodo di verifica.
Anche il comportamento del modello rimane rilevante. L’infrastruttura può bloccare operazioni vietate, ma non può garantire codice utile. Un agente può restare entro le proprie autorizzazioni pur producendo un’implementazione errata o trascurando un requisito importante.
Test e revisione umana rimangono quindi parte del sistema. Casi di valutazione privati o mantenuti indipendentemente possono aiutare a rilevare agenti che ottimizzano soltanto per i controlli visibili. Le regole di ownership del codice possono instradare modifiche sensibili verso i revisori appropriati.
Questo è il limite scettico della tesi sull’infrastruttura degli agenti di Mozilla AI. Un’infrastruttura migliore contiene i fallimenti, preserva le prove e rende possibile il recupero. Non trasforma un ragionamento incerto in ingegneria del software deterministica.
Le organizzazioni dovrebbero anche evitare di trattare i log di audit come prova di sicurezza. Un record dettagliato può mostrare esattamente come si è verificato un incidente. Prevenire l’incidente richiede controlli applicabili e policy convalidate prima dell’azione.
Esiste anche una questione di governance su chi controlla il control plane. Una policy centrale può proteggere un’organizzazione, ma può anche creare un’autorità interna opaca. Gli sviluppatori hanno bisogno di visibilità sul perché le azioni siano state rifiutate e su come funzionino le eccezioni.
Un’implementazione aperta aiuta questo scrutinio, ma contano anche i processi. Le modifiche alle policy dovrebbero ricevere revisione, test e versionamento. Le deroghe di emergenza dovrebbero scadere e restare visibili nel registro.
L’approccio più solido considera l’apertura come un modello di titolarità anziché come un’etichetta di sicurezza. Le organizzazioni acquisiscono la capacità di ispezionare e modificare il sistema. Accettano inoltre la responsabilità di gestirlo bene.
Questo compromesso è più credibile della promessa di sicurezza automatica. Riconosce che una delega affidabile deriva dalla disciplina ingegneristica, non da una singola funzionalità di prodotto.
Tre segnali metteranno alla prova la tesi infrastrutturale di Mozilla
Il prossimo test è se le piattaforme per agenti trasformeranno i principi infrastrutturali in impostazioni predefinite che gli sviluppatori possano verificare senza rallentare il lavoro ordinario.
Il primo segnale è la diffusione delle autorizzazioni limitate all’attività. Occorre osservare se gli agenti di coding ricevono accesso temporaneo a repository, directory, comandi e destinazioni di rete nominati. Un’autorità ampia a livello di macchina indebolirebbe nella pratica l’argomento di Mozilla AI, anche se i fornitori promuovono altrove la sicurezza.
Il secondo segnale è la qualità delle prove. Le piattaforme dovrebbero esporre record durevoli di chiamate agli strumenti, approvazioni, decisioni di policy, modifiche ai file e stato dei tentativi. Una trascrizione da sola non risponderà a quale autorità esistesse quando si è verificata un’azione.
Il terzo segnale è la portabilità. I team dovrebbero poter mantenere policy, tracce e stato dei flussi di lavoro quando cambiano modelli o ambienti di deployment. Se la governance resta legata a un unico fornitore, la scelta del modello continua a controllare il sistema circostante.
Questi segnali si rafforzano a vicenda. Le autorizzazioni circoscritte riducono il danno possibile. I record di audit rivelano se tali confini hanno funzionato. La portabilità impedisce che i confini scompaiano durante la successiva migrazione del modello.
Gli sviluppatori dovrebbero anche osservare l’attrito nel flusso di lavoro quotidiano. Un livello di controllo che interrompe costantemente le azioni a basso rischio incontrerà resistenza. Uno che nasconde le decisioni di policy sarà difficile da fidarsi e da sottoporre a debug.
I sistemi efficaci renderanno le operazioni sicure routine e quelle eccezionali esplicite. Permetteranno agli agenti di leggere, ragionare, testare e preparare modifiche all’interno di ambienti delimitati. Si fermeranno davanti ad azioni con conseguenze esterne o irreversibili.
L’argomento di Mozilla AI a favore dell’infrastruttura per agenti sarà rafforzato quando queste funzionalità diventeranno aspettative standard dei prodotti. Sarà indebolito se gli agenti continueranno ad acquisire autorità mentre i controlli restano dashboard opzionali o modelli di prompt.
Per i team che adottano ora agenti di coding, la domanda immediata non è se il modello più recente ottenga un punteggio più alto. Chiedetevi a cosa può accedere l’agente, quali azioni richiedono approvazione e se ogni decisione possa essere ricostruita in seguito. Poi chiedetevi se queste protezioni appartengono alla vostra organizzazione o scompaiono con il fornitore. Un’IA migliore continuerà a essere utile, ma è l’infrastruttura a determinare se questa intelligenza possa essere delegata responsabilmente.
