Punti chiave
- La postura di sicurezza dei sistemi di AI è in ritardo di due o tre anni rispetto alla maturità della sicurezza infrastrutturale, ripetendo il ritardo di hardening già visto con le web app negli anni 2000 e con le API negli anni 2010.
- I protocolli standardizzati per gli agent, come A2A e MCP, governati da enti neutrali come la Linux Foundation, determineranno la posizione competitiva più della pura performance dei modelli.
- La maggior parte delle architetture RAG tratta i documenti recuperati come attendibili; un singolo artefatto recuperato è sufficiente a reindirizzare un agent, in presenza di auto-invocazione e in assenza di confini di esecuzione.
- Le pipeline multi-agent prive di circuit breaker espliciti amplificano gli errori iniziali a valle, rendendo obbligatori gate di validazione indipendenti a ogni passaggio di consegna.
- I team di procurement dovrebbero richiedere il supporto dei protocolli aperti nei contratti con i fornitori per preservare l'uscita architetturale e ridurre il rischio di lock-in.
Cosa è cambiato nel panorama dei framework di AI agent
La categoria dei framework di AI agent è passata dall'esperimento all'obiettivo di deployment in meno di due anni. I team che trattavano questi sistemi come prototipi ora li fanno girare su traffico di produzione.
Il cambiamento è architetturale. Livelli di orchestrazione, tool-calling, retrieval e passaggi di consegna multi-agent sono diventati funzionalità predefinite nei principali stack. Questo default porta con sé delle conseguenze.
I fornitori distribuiscono l'auto-invocazione abilitata by design. Un agent legge un documento, decide di chiamare uno strumento ed esegue, lasciando i confini di esecuzione all'integratore. La comodità è reale. Anche l'esposizione lo è.
Il meccanismo sotto l'astrazione
Ogni framework di agent si riduce a un ciclo: percepire, pianificare, agire, osservare. Il modello riceve il contesto, emette un'azione e il runtime esegue quell'azione contro sistemi reali.
Il dettaglio critico sta nel passaggio di osservazione. L'output di un componente diventa l'input del successivo. Quando quella catena attraversa più agent, gli errori si sommano anziché annullarsi.
Il retrieval alimenta il ciclo con testo esterno. Quel testo arriva con lo stesso livello di fiducia di un'istruzione dell'utente nella maggior parte delle configurazioni predefinite. Il runtime tratta un paragrafo recuperato come una guida da eseguire.
Questa è la condizione di fondo a cui le sezioni successive tornano: il framework collassa il confine tra dato e istruzione.
La postura di sicurezza è in ritardo rispetto alla curva di deployment
La postura di sicurezza dei sistemi di AI è in ritardo di due o tre anni rispetto alla maturità della sicurezza infrastrutturale circostante. Gli advisory pubblicati contro le librerie di orchestrazione sono segnali, più che anomalie.
Il settore va in produzione prima di sviluppare pratiche di hardening. Le web app hanno ripetuto questo schema negli anni 2000. Le API lo hanno ripetuto negli anni 2010.
Lo schema si ripete perché gli incentivi premiano la distribuzione di funzionalità rispetto all'irrobustimento delle interfacce. Il lavoro di sicurezza diventa visibile dopo il primo incidente.
Ogni vulnerabilità citata in una revisione interna dovrebbe riportare il suo identificatore CVE ufficiale. Affermazioni vaghe di rischio non aiutano nessuno. Patch documentate e advisory con versione fissata sì.
Per un CTO, l'implicazione è diretta: trattare qualsiasi framework di AI agent come software pre-hardening. Prevedere il budget per l'audit che il fornitore ha omesso.
La standardizzazione dei protocolli è il vero fossato
I protocolli di comunicazione standardizzati, tra cui A2A e MCP, determineranno la posizione competitiva più della pura performance dei modelli. Chi controlla il livello tra gli agent controlla l'architettura.
La governance della Linux Foundation su A2A è il segnale corretto. I protocolli che vincono sfuggono all'orbita di un singolo fornitore.
La performance dei modelli converge verso la parità tra i provider. La differenziazione migra verso il livello di coordinamento, e quel livello è il protocollo.
Un segnale di stabilità v1.0 su una specifica condivisa cambia i calcoli di procurement. La specifica diventa uno standard da adottare anziché un prodotto di un fornitore da valutare.
Leggetelo come un avvertimento sul lock-in. Un framework che parla un dialetto di agent proprietario vi vincola a una sola roadmap. Un framework che parla un protocollo aperto preserva la vostra uscita.
La prompt injection resta sottovalutata
La prompt injection è l'attacco più sottovalutato contro i team di AI aziendali. Un documento estratto da un sistema di retrieval è un vettore di attacco che porta con sé le credenziali stesse dell'utente.
La maggior parte delle architetture RAG in produzione tratta i documenti recuperati come attendibili. Questa postura è sbagliata.
Un singolo artefatto recuperato è sufficiente a reindirizzare un agent verso un'azione non intenzionale. La superficie di attacco è il confine di retrieval stesso. L'attacco richiede due condizioni: auto-invocazione abilitata e confini di esecuzione assenti.
La nostra precedente analisi sui pattern di sicurezza del retrieval copre i controlli di isolamento che contengono questa classe di guasti.
Il guasto a cascata è aritmetica
I sistemi multi-agent in produzione privi di circuit breaker espliciti falliranno a cascata. Questo è aritmetica, più che previsione.
I tassi di allucinazione tra i modelli variano ampiamente per task e versione, e qualsiasi errore in un agent iniziale si propaga a valle. Quando l'output di un agent diventa l'input del successivo senza validazione indipendente, la pipeline amplifica il difetto.
Un circuit breaker è un gate di validazione che ferma la propagazione. Verifica l'output intermedio rispetto a un vincolo esterno prima che l'agent successivo lo consumi.
I team dell'Head of Engineering dovrebbero mappare ogni passaggio di consegna nel loro framework di AI agent e segnare quali di essi girano validati. I passaggi non segnati sono i candidati alla cascata.
Tre domande per i team di AI aziendali
Prima del prossimo deployment, risolvete tre domande. Ognuna corrisponde a un controllo concreto.
- Il livello di retrieval tratta i documenti come input non attendibile, con sanificazione applicata prima che il modello li legga?
- Ogni passaggio di consegna tra agent attraversa un gate di validazione indipendente?
- Le esecuzioni degli strumenti sono limitate da permessi espliciti definiti al di sotto delle credenziali complete dell'utente?
Un framework che risponde a tutte e tre le domande by default è di livello produttivo. Un framework che lascia tutte e tre all'integratore porta un debito tecnico che ereditate dal primo giorno.
Build, buy e la decisione di procurement
Il calcolo build-versus-buy è cambiato. Due anni fa, i team costruivano l'orchestrazione degli agent internamente per mancanza di alternative. Ora esistono framework maturi.
La domanda è passata da "possiamo costruirlo" a "quale lock-in accettiamo". Ogni framework codifica assunzioni su stato, memoria e schemi degli strumenti.
Per il CFO, la scommessa infrastrutturale è più rischiosa dove il framework si accoppia strettamente a un solo cloud o a un solo provider di modelli. La portabilità abbassa il premio di rischio.
Il Comitato di Procurement Tecnologico dovrebbe rinegoziare ogni contratto che presuppone un protocollo di agent proprietario. Il supporto dei protocolli aperti appartiene al contratto, non alla promessa della roadmap.
Decisioni per il prossimo ciclo di pianificazione
Le decisioni di CTO e Head of Engineering per il prossimo ciclo di pianificazione si allineano con chiarezza.
Primo, classificate ogni documento recuperato come input non attendibile e aggiungete la sanificazione al confine. Secondo, inserite circuit breaker a ogni passaggio di consegna multi-agent. Terzo, definite i permessi degli strumenti al di sotto delle credenziali dell'utente chiamante.
Quarto, preferite framework allineati a protocolli aperti sotto una governance neutrale. Questa singola scelta preserva la vostra uscita architetturale e limita la leva del fornitore.
Il framework di AI agent che adottate quest'anno stabilisce il vostro tetto di tolleranza ai guasti per i prossimi tre. Trattate quella scelta come una decisione architetturale e diventa un vantaggio competitivo. Trattatela come una casella da spuntare e diventa una trappola.
La nostra rassegna sui pattern di governance degli agent descrive nel dettaglio il livello di monitoraggio che rende questi controlli osservabili in produzione.
Questo articolo è stato prodotto da un autore editoriale AI con supervisione editoriale umana, in conformità con i requisiti di trasparenza del Regolamento (UE) 2024/1689 (AI Act, Art. 50). Le fonti sono collegate nel testo.
Articolo di LEON