Il corso di sicurezza OpenAI di SpecterOps porta la difesa degli agenti in laboratorio
SpecterOps ha lanciato il corso di sicurezza OpenAI di SpecterOps, con dieci moduli, laboratori ospitati e un focus sull'attacco e la difesa degli agenti AI. La prima coorte è iniziata il 15 ottobre, dopo l'apertura delle iscrizioni il 30 settembre. La tempistica è importante perché ai team di sicurezza viene chiesto di approvare il rilascio di agenti prima che molti professionisti riescano a testarne in modo affidabile i confini di fiducia.
Chiamato Adversary Intelligence: LLM Tradecraft, il programma tratta molto più del prompting sicuro. Parte dalle basi del machine learning per arrivare ad architettura degli agenti, valutazione, threat modeling, sicurezza del Model Context Protocol e analisi di malware assistita dall'AI. Il Model Context Protocol, o MCP, è uno standard che consente alle applicazioni AI di connettersi a strumenti e dati esterni.
Il conflitto è tra velocità di implementazione e comprensione della sicurezza. OpenAI e altri fornitori di modelli stanno rendendo gli agenti più capaci, mentre i difensori devono stabilire a cosa tali agenti possano accedere, di cosa possano fidarsi e cosa possano modificare. SpecterOps punta sul fatto che le pratiche di sicurezza tradizionali possano colmare questo divario, ma solo se i professionisti lavorano direttamente con la nuova superficie d'attacco.
Il corso di sicurezza OpenAI di SpecterOps collega dieci moduli
Il lancio trasforma la sicurezza AI da una discussione sulle policy in una sequenza di esercizi tecnici.
SpecterOps ha annunciato Adversary Intelligence: LLM Tradecraft il 30 settembre attraverso la propria Tradecraft Academy. L'azienda afferma di aver sviluppato il programma con OpenAI tramite l'OpenAI Daybreak Defense Network. La prima coorte è iniziata il 15 ottobre, con ulteriori coorti previste ogni mese.
L'annuncio ufficiale del corso descrive un programma on-demand per professionisti della sicurezza che devono creare, valutare, testare e difendere applicazioni LLM. I large language model, o LLM, generano risposte prevedendo token a partire da pattern appresi durante l'addestramento.
I partecipanti ricevono 30 giorni di accesso a materiale preregistrato, esercizi guidati e ambienti di laboratorio ospitati. SpecterOps afferma inoltre che ogni coorte include un abbonamento ChatGPT Pro fornito da OpenAI. Il corso richiede un computer con un browser moderno, ma nessuna macchina virtuale locale.
Questo modello di erogazione si colloca tra la formazione statica di sensibilizzazione e una lezione tecnica dal vivo. Gli studenti possono seguire il materiale secondo i propri ritmi, ma l'accesso inizia comunque attraverso coorti mensili. La struttura offre a SpecterOps un modo per aggiornare gli esercizi senza trasformare ogni argomento in un evento di più giorni con docente.
I dieci moduli seguono una progressione intenzionale. Il materiale iniziale affronta il machine learning attraverso esempi di sicurezza come il rilevamento del phishing e la classificazione del malware. Le sezioni successive trattano tokenizzazione, embedding, attenzione, finestre di contesto, strategie di prompting e progettazione del prompt come programma.
Il curriculum si sposta poi verso sistemi in grado di agire. Gli studenti esaminano tool calling, memoria, coordinamento multi-agente, agenti di coding e server MCP. Questo passaggio è importante perché i rischi di un agente non terminano con la risposta del modello.
Un chatbot che produce una risposta scadente genera un problema informativo. Un agente che può interrogare repository, eseguire codice o modificare record genera un problema di autorizzazione. Le revisioni di sicurezza devono quindi esaminare il workflow circostante, non solo il modello.
SpecterOps afferma che i laboratori ospitati comprendono la creazione di modelli di machine learning convenzionali, la realizzazione di workflow agentici e la valutazione delle esecuzioni degli agenti con MLflow. MLflow è una piattaforma per registrare e confrontare esperimenti e valutazioni di machine learning.
Altri esercizi usano Codex per il reverse engineering del malware. Il reverse engineering esamina software compilato per comprenderne il comportamento senza basarsi sul codice sorgente originale. Il corso insegna agli studenti a combinare l'assistenza del modello con strumenti deterministici, test e verifica umana.
Questa combinazione è una scelta distintiva. Il corso non presenta un LLM come sostituto dell'analisi convenzionale. Tratta invece il modello come un componente di un workflow nel quale gli output richiedono prove e controlli ripetibili.
La panoramica del curriculum afferma che i moduli possono essere affrontati singolarmente. I principianti possono iniziare dal materiale fondamentale, mentre i professionisti esperti possono concentrarsi su valutazione, threat modeling, sicurezza MCP o reverse engineering.
Questo design modulare rivela anche il pubblico di riferimento. SpecterOps non si rivolge solo ai ricercatori AI. Indica difensori, ingegneri della sicurezza, ricercatori e responsabili tecnici che devono valutare workflow aziendali abilitati dall'AI.
Il corso risultante è ampio, ma il suo tema unificante è il controllo. Ogni argomento chiede come un'organizzazione possa determinare cosa ha ricevuto un sistema AI, cosa ha deciso, quali strumenti ha invocato e cosa è accaduto in seguito.
Perché l'adozione degli agenti sta mettendo sotto pressione i team di sicurezza
I team di sicurezza subiscono pressioni perché gli agenti combinano un comportamento incerto del modello con l'accesso a sistemi aziendali affidabili.
Le organizzazioni gestiscono da tempo software che legge file, chiama API e modifica record. Gli agenti AI complicano questo modello perché il percorso dall'input all'azione è in parte probabilistico. La stessa richiesta può produrre piani, selezioni di strumenti o ragionamenti intermedi diversi.
Anche i contenuti esterni entrano in questi workflow su vasta scala. Un agente può elaborare email, pagine web, ticket, documenti, codice sorgente o risultati di database. Ognuna di queste fonti può contenere istruzioni in conflitto con l'obiettivo effettivo dell'utente.
La prompt injection sfrutta questa ambiguità inserendo istruzioni ostili nei contenuti che un sistema AI consuma. Le linee guida di OpenAI sulla prompt injection paragonano gli attacchi avanzati al social engineering, perché il contenuto dannoso manipola l'agente all'interno di un contesto plausibile.
Non si tratta semplicemente di bloccare frasi sospette. Un attaccante può nascondere un'istruzione in un documento che all'agente è stato legittimamente chiesto di riassumere. L'agente deve distinguere i dati non attendibili dai comandi, anche se entrambi arrivano come testo.
OpenAI sostiene che il filtraggio degli input da solo non possa risolvere il problema in modo affidabile. I difensori devono anche limitare l'impatto di una manipolazione riuscita. Ciò richiede autorizzazioni circoscritte, confini chiari per i dati, passaggi di conferma e limiti alle azioni irreversibili.
Questi controlli ricordano principi di sicurezza consolidati, ma l'architettura degli agenti modifica il punto in cui i team devono applicarli. La gestione di identità e accessi deve ora coprire attori non umani che selezionano strumenti dinamicamente. La sicurezza applicativa deve considerare il contesto recuperato che può influenzare decisioni successive.
La pressione coinvolge contemporaneamente più gruppi. Gli sviluppatori devono decidere quali capacità siano necessarie a un agente. Gli ingegneri della sicurezza devono testare il workflow risultante. I team di identità devono definire credenziali e autorizzazioni. I team di governance devono documentare rischi che possono cambiare con modelli, prompt e servizi connessi.
I team di procurement affrontano un problema correlato. La descrizione di un prodotto può affermare che un assistente sia in grado di cercare informazioni aziendali o automatizzare il lavoro di routine. Tale descrizione dice poco su come il sistema separi istruzioni e dati, registri le chiamate agli strumenti o contenga un'integrazione compromessa.
La formazione tradizionale sulla sicurezza spesso divide queste questioni tra specializzazioni. I team cloud studiano l'infrastruttura, i team applicativi testano il codice e i red team simulano gli avversari. I sistemi agentici attraversano tutte e tre le aree all'interno di una singola richiesta dell'utente.
Il corso di sicurezza OpenAI di SpecterOps cerca di creare una base tecnica condivisa. Il suo curriculum collega il comportamento del modello con architettura applicativa, autorizzazioni, osservabilità e test avversariali. Questo rende il programma più rilevante per le revisioni di implementazione rispetto a un corso incentrato solo sul prompting.
La tempistica segue anche una relazione più ampia tra le due aziende. SpecterOps è entrata nel programma Trusted Access for Cyber di OpenAI nell'aprile 2026. A giugno, è diventata parte del Daybreak Cyber Partner Program, che offre a partner di sicurezza selezionati accesso a modelli avanzati con capacità cyber per attività difensive legittime.
OpenAI descrive Daybreak come un modo per mettere capacità avanzate a disposizione di difensori e fornitori di sicurezza sottoposti a verifica. Il suo programma partner pubblicato include organizzazioni di servizi, vendor di sicurezza e SpecterOps.
Il corso estende questa relazione dall'accesso alle capacità alla formazione dei professionisti. È un cambiamento significativo. L'accesso controllato aiuta ricercatori selezionati a utilizzare modelli avanzati, ma non insegna automaticamente alla più ampia forza lavoro della sicurezza come valutare agenti già implementati.
I responsabili della sicurezza affrontano quindi una risposta obbligata. Possono sviluppare ora pratiche di test e autorizzazione specifiche per gli agenti, oppure applicare checklist di revisione convenzionali che non intercettano i percorsi d'attacco mediati dal modello. Il corso è progettato attorno alla prima opzione.
La pressione probabilmente persisterà perché il conflitto sottostante è strutturale. Gli agenti più capaci acquisiscono valore ricevendo contesto e compiendo azioni. Le stesse caratteristiche aumentano le conseguenze di obiettivi confusi, contenuti ostili, autorizzazioni eccessive o strumenti compromessi.
La vera sfida è tra velocità di implementazione e comprensione della sicurezza
L'avversario centrale del corso non è un altro fornitore di formazione. È la crescente distanza tra l'adozione degli agenti e la capacità di un difensore di verificarne il comportamento.
Questa impostazione cambia il modo in cui il curriculum dovrebbe essere valutato. Un elenco ampio di argomenti AI non è di per sé utile. Il test utile è se gli esercizi aiutino i professionisti a collegare una debolezza a livello di modello a una conseguenza aziendale.
Si consideri un'applicazione di supporto AI. Potrebbe recuperare la cronologia del cliente, cercare documentazione interna, redigere una risposta e aggiornare un ticket. Ogni passaggio introduce una decisione di fiducia, anche quando ogni componente funziona come previsto.
La documentazione recuperata è un dato, ma un agente può interpretare il testo incorporato come istruzioni. Un record cliente può contenere contenuti ostili. Uno strumento connesso può esporre più funzioni di quelle richieste dal compito. Una risposta generata può indurre un sistema successivo a eseguire un'operazione non sicura.
Il threat modeling mappa questi componenti, flussi di dati, privilegi e confini di fiducia prima che si verifichi un incidente. SpecterOps afferma che il corso utilizza un'applicazione di supporto assistita dall'AI per insegnare questo processo. Lo scenario colloca rischi poco familiari in un workflow aziendale ordinario.
Il curriculum affronta anche l'eccessiva agency, che si verifica quando un sistema AI dispone di più funzionalità, permessi o autonomia di quanto il suo compito richieda. Le linee guida di OWASP sull'eccessiva agency spiegano che azioni dannose possono derivare da allucinazioni, prompt injection o estensioni compromesse.
Il principio del privilegio minimo resta utile in questo contesto. Un agente che deve solo leggere un repository non dovrebbe ricevere uno strumento in grado di eliminarne il contenuto. Se è necessaria un'operazione di scrittura, il workflow dovrebbe limitarne l'ambito e richiedere un'autorizzazione significativa.
Un'autorizzazione significativa è più difficile da ottenere che mostrare una casella di approvazione generica. L'utente deve vedere l'azione effettiva, il bersaglio e il contesto pertinente. In caso contrario, un agente manipolato può trasformare la revisione umana in una formalità.
MCP aggiunge un ulteriore livello. Offre ai modelli un modo comune per individuare e chiamare strumenti esterni, ma ogni server connesso amplia la superficie di fiducia del sistema. Descrizioni degli strumenti, autenticazione, autorizzazioni, dati restituiti e comportamento degli aggiornamenti diventano tutti elementi di sicurezza.
Una configurazione MCP non sicura può esporre credenziali o concedere accessi troppo ampi. Un server compromesso può inoltre restituire contenuti manipolati al modello. Ciò crea rischi di supply chain e di runtime che vanno oltre il modello linguistico stesso.
SpecterOps colloca la sicurezza MCP accanto all'architettura degli agenti, invece di trattarla come un tema infrastrutturale separato. Questo abbinamento ha senso perché il comportamento del modello dipende dagli strumenti e dal contesto disponibili durante un'esecuzione.
Anche la valutazione è altrettanto importante. I team hanno bisogno di qualcosa in più di una serie di demo riuscite. Servono casi di test ripetibili che registrino input, passaggi intermedi, chiamate agli strumenti, output e fallimenti al variare del modello o del prompt.
Il corso usa MLflow per valutare le esecuzioni degli agenti. Questo non trasforma un sistema probabilistico in software deterministico. Offre ai team un modo per confrontare i comportamenti, identificare regressioni e conservare evidenze di ciò che ha fatto una configurazione specifica.
La ricerca sul red teaming del NIST sostiene la necessità di test in evoluzione. La sua analisi di un'ampia competizione pubblica ha rilevato differenze significative nel numero di attacchi riusciti individuati contro i modelli leader.
Il NIST ha inoltre avvertito che le prestazioni di sicurezza non seguivano uniformemente le capacità dei modelli. Un modello che ottiene buoni risultati nei compiti generali non è automaticamente la scelta più sicura per un'applicazione agentica. I team hanno bisogno di valutazioni di sicurezza legate ai flussi di lavoro previsti.
Questo punto mette in discussione una scorciatoia comune nel deployment. Le organizzazioni spesso scelgono un modello leader, lo avvolgono con un prompt di sistema, collegano strumenti e presumono che il lavoro di sicurezza del fornitore copra l'applicazione risultante.
Le protezioni del fornitore sono importanti, ma il proprietario dell'applicazione controlla le autorizzazioni e le integrazioni circostanti. Una configurazione sicura del modello può comunque trovarsi all'interno di un flusso di lavoro pericolosamente permissivo. Al contrario, un'architettura accurata può limitare i danni causati da un errore del modello.
Il corso di sicurezza OpenAI di SpecterOps occupa quindi un utile livello intermedio. Non sostituisce i test del fornitore del modello, la revisione dell'architettura aziendale o gli esercizi di red team dal vivo. Mira a fornire ai professionisti conoscenze condivise sufficienti per collegare queste attività.
Questo obiettivo spiega anche la prospettiva offensiva. I difensori imparano di più tentando l'iniezione di prompt, attaccando l'infrastruttura AI e tracciando confini di fiducia deboli che memorizzando controlli astratti. I laboratori controllati possono esporre le modalità di fallimento senza mettere a rischio i sistemi di produzione.
L'approccio ricorda la consolidata simulazione degli avversari. I team riproducono un percorso di attacco, ne osservano le conseguenze e usano le evidenze per migliorare le difese. La differenza è che ora il percorso passa attraverso prompt, contesto recuperato, decisioni del modello e chiamate agli strumenti.
I laboratori pratici non colmano il divario di verifica
Il lancio è credibile come risposta formativa, ma la sua reale efficacia resta da dimostrare finché gli studenti non applicheranno il materiale al di fuori dei laboratori ospitati.
SpecterOps ha pubblicato dettagli sostanziali su argomenti, esercizi, accesso e destinatari previsti. Non ha pubblicato misurazioni indipendenti dei risultati di apprendimento, dei tassi di completamento o dei miglioramenti della sicurezza dopo il corso. Questa assenza è normale per un corso nuovo, ma limita conclusioni più solide.
Un laboratorio ospitato controlla il modello, gli strumenti, i dati e il percorso previsto. Gli ambienti di produzione raramente offrono tale stabilità. Le imprese combinano modelli diversi, sistemi di retrieval, piattaforme di identità, strumenti personalizzati e applicazioni legacy.
Anche il modello di minaccia cambia con ogni connessione. Un agente che legge pagine web pubbliche affronta rischi diversi da uno che gestisce risorse cloud. Un agente di coding con accesso al repository richiede controlli diversi da un assistente che riassume note di riunione.
Gli studenti devono trasferire i principi tra queste situazioni. Un laboratorio sull'iniezione di prompt dovrebbe portare a migliori confini di fiducia e autorizzazioni, non al semplice riconoscimento di un prompt malevolo noto. Una lezione sulla valutazione dovrebbe produrre test interni ripetibili, non una singola dashboard.
L'ampiezza del corso crea un altro compromesso. Dieci moduli possono stabilire una base comune, ma argomenti come reverse engineering, valutazione degli agenti, threat modeling e sicurezza MCP meritano ciascuno uno studio molto più approfondito.
La modularità aiuta i professionisti esperti a scegliere le sezioni pertinenti. Può anche rendere disomogeneo il percorso di apprendimento. Chi salta le basi può non cogliere assunzioni da cui dipendono i laboratori successivi, mentre un principiante può aver bisogno di più supporto di quanto offra un formato on-demand.
Esiste inoltre un inevitabile rapporto con il fornitore. OpenAI ha contribuito a un corso che include l'accesso ai suoi modelli, a ChatGPT Pro e a Codex. Questi strumenti forniscono ambienti di laboratorio concreti, ma la partnership può influenzare quali flussi di lavoro ricevono maggiore attenzione.
I principi di sicurezza dovrebbero essere trasferibili tra i fornitori di modelli. Confini di fiducia, privilegio minimo, osservabilità, valutazione e test avversariali non sono specifici di OpenAI. Gli studenti dovrebbero poterli applicare ad altri modelli ospitati, modelli locali e stack aziendali misti.
SpecterOps afferma che il corso insegna concetti anziché ricette legate a un singolo modello o framework. È l'obiettivo giusto, ma i professionisti indipendenti dovranno verificare quanto bene il materiale si trasferisca.
La stessa cautela vale per il reverse engineering assistito dall'AI. Gli LLM possono aiutare a spiegare funzioni, proporre nomi o collegare schemi nel codice. Possono anche produrre interpretazioni convincenti che non corrispondono al comportamento del programma.
SpecterOps affronta questo rischio abbinando l'assistenza del modello a flussi di lavoro Ghidra, informazioni sui tipi riutilizzabili, test e strumenti deterministici. Ghidra è una suite di reverse engineering software usata per ispezionare programmi compilati.
Questo abbinamento dovrebbe rimanere centrale. Una spiegazione generata dal modello è un'ipotesi finché gli analisti non la convalidano rispetto al binario e al comportamento osservato. Un'interpretazione più rapida ha valore solo quando preserva il rigore probatorio.
La partnership non elimina nemmeno il conflitto tra capacità offensive e rischio di abuso. Formare i difensori ad attaccare sistemi agentici migliora i test, ma gli stessi concetti possono favorire abusi. L'accesso per coorti e i termini della piattaforma offrono governance, ma non possono eliminare le preoccupazioni legate al duplice uso.
I programmi cyber di OpenAI cercano di gestire questa tensione tramite accesso verificato e monitoraggio. SpecterOps apporta esperienza nelle tecniche degli avversari e nell'educazione alla sicurezza controllata. Il corso verifica se tali controlli possano sostenere un'istruzione pratica senza ridurre il materiale a consigli generici sulla sicurezza.
Le imprese che valutano il programma dovrebbero quindi evitare di considerare il completamento come un controllo di sicurezza. Un certificato non dimostra che un'organizzazione abbia mappato le identità degli agenti, limitato le autorizzazioni, protetto le connessioni MCP o testato l'iniezione indiretta di prompt.
La misura migliore è il cambiamento operativo. Dopo la formazione, un professionista sa produrre un threat model per un agente? Il team sa registrare e riprodurre gli attacchi? Sa spiegare perché uno strumento dispone di una determinata autorizzazione? Sa rilevare quando un aggiornamento del modello cambia il comportamento?
Queste domande offrono anche uno standard più equo rispetto a chiedersi se ogni studente diventi un ricercatore AI. Il programma promette una profondità tecnica sufficiente per valutare e proteggere i sistemi agentici. Il suo valore dipenderà dalla capacità degli studenti di prendere in seguito decisioni di deployment difendibili.
Le organizzazioni hanno bisogno di supporto interno per questo trasferimento. I team dovrebbero conservare appunti dei laboratori, casi di test, threat model e registri delle decisioni in un repository consultabile. Una base di conoscenza ingegneristica strutturata può aiutare a collegare le evidenze formative alle successive revisioni architetturali.
L'incertezza rimanente non riguarda il fatto che il curriculum nomini rischi pertinenti. Li nomina. L'incertezza è se un corso mensile on-demand possa tenere il passo con modelli, protocolli degli strumenti, tecniche di attacco e configurazioni aziendali in evoluzione.
Tre segnali mostreranno se il modello formativo funziona
Il prossimo test sarà capire se il corso produce pratiche trasferibili, materiale aggiornato e un'influenza visibile oltre la prima coorte.
Il primo segnale sono le evidenze della coorte di ottobre. Evidenze utili includerebbero analisi tecniche, metodi di valutazione sanitizzati o esempi di studenti che applicano i laboratori a stack di agenti diversi. Le testimonianze di marketing rivelerebbero meno di un lavoro di sicurezza riproducibile.
Se i partecipanti riusciranno ad adattare i metodi tra fornitori e ambienti, ciò rafforzerebbe l'affermazione centrale del corso. Dimostrerebbe che il curriculum insegna un ragionamento duraturo, anziché procedure specifiche di prodotto.
L'assenza di evidenze pubbliche non dimostrerebbe un fallimento. I team di sicurezza spesso mantengono privati i metodi di test. Tuttavia, lascerebbe gli acquirenti dipendenti dalle descrizioni delle aziende anziché da risultati osservabili in modo indipendente.
Il secondo segnale è la manutenzione del curriculum. La sicurezza degli agenti cambia ogni volta che cambiano modelli, interfacce degli strumenti e controlli difensivi. Le coorti mensili offrono a SpecterOps un'opportunità naturale per rivedere laboratori ed esempi.
Osservate se le future descrizioni del corso identificheranno aggiornamenti significativi. Nuovo materiale su autorizzazione MCP, avvelenamento degli strumenti, attacchi alla memoria o metodi di valutazione mostrerebbe che il programma segue la superficie di attacco.
Moduli statici indebolirebbero la proposta nel tempo. Un laboratorio può rimanere tecnicamente corretto pur perdendo rilevanza quando i fornitori modificano le protezioni predefinite o le imprese adottano modelli di orchestrazione diversi.
Il terzo segnale è la risposta dei programmi di sicurezza aziendali. La convalida più forte sarebbe rappresentata da nuove pratiche di revisione per gli agenti AI, non semplicemente da più iscrizioni al corso.
Cercate team che aggiungano le identità degli agenti alle revisioni degli accessi, registrino le tracce delle chiamate agli strumenti, testino contenuti recuperati ostili e definiscano requisiti di approvazione per azioni sensibili. Questi cambiamenti indicherebbero che la formazione è entrata nelle operazioni.
La partnership esercita inoltre pressione su altri educatori di sicurezza e fornitori di modelli. Devono decidere se la sicurezza AI debba appartenere a corsi specialistici, alla formazione mainstream sulla sicurezza applicativa o a certificazioni specifiche del fornitore.
Una risposta più ampia del mercato rafforzerebbe l'impostazione di SpecterOps secondo cui i difensori necessitano di un corpus distinto di tecniche operative per gli agenti. Una risposta limitata potrebbe suggerire che le imprese preferiscano la formazione interna o i programmi esistenti di sicurezza applicativa.
Per i professionisti, l'azione immediata è confrontare il curriculum con le proprie responsabilità attuali. Chiunque approvi agenti abilitati agli strumenti dovrebbe comprendere l'iniezione di prompt, l'eccessiva autonomia, i confini di identità, l'osservabilità e la valutazione.
Il corso di sicurezza OpenAI di SpecterOps offre un percorso strutturato attraverso questi argomenti. Non stabilisce quali controlli funzionino in ogni deployment e non può sostituire il test di un ambiente reale.
La sua rilevanza risiede nel modo in cui colloca questo lavoro. La sicurezza AI non è più confinata ai laboratori sui modelli o ai documenti di governance. Ora è nelle mani di professionisti che possono tracciare un percorso di attacco, riprodurre un fallimento e limitare ciò che un agente può fare.
Ponetevi una domanda pratica prima del prossimo deployment di un agente: il vostro team di sicurezza può dimostrare come si comporta il sistema quando strumenti fidati ricevono istruzioni non affidabili? Se la risposta non è chiara, il divario formativo sta già influenzando la decisione di deployment.
