Meerah Rajavel avverte che i modelli AI aperti potrebbero superare le protezioni della sicurezza informatica

Meerah Rajavel ha lanciato un severo avvertimento: i modelli AI aperti ed economici, non gli attuali sistemi frontier controllati, rappresentano la più grande minaccia emergente per la sicurezza informatica. La chief information officer di Palo Alto Networks ha esposto questa tesi in un’intervista del 30 agosto individuata tramite Google News.

La sua preoccupazione riguarda un divario di capacità sempre più ridotto. Rajavel afferma che funzionalità avanzate possono arrivare nei modelli disponibili apertamente entro quattro-sei mesi dalla loro comparsa nei sistemi frontier. Gli aggressori necessitano quindi soltanto di risorse computazionali e competenze tecniche, anziché di un accesso continuativo a un servizio commerciale monitorato.

Questa distinzione cambia il dibattito sulla sicurezza. Provider chiusi come Google, OpenAI e Anthropic possono monitorare l’attività, bloccare utenti, rivedere le protezioni e revocare l’accesso. Una volta che i pesi dei modelli scaricabili si diffondono tra sistemi privati, questi controlli in larga parte scompaiono.

L’avvertimento non dimostra che i modelli aperti causino già più attacchi informatici di quelli chiusi. È una previsione su accesso, economia e controllo. Il conflitto centrale contrappone i vantaggi dello sviluppo aperto al valore per la sicurezza di protezioni effettivamente applicabili.

Il report di Google News si concentra su una finestra di quattro-sei mesi

L’affermazione centrale di Rajavel è che le capacità AI pericolose diventano più difficili da controllare quando il loro costo diminuisce e la loro distribuzione si amplia.

Nell’intervista originale a Rajavel, distingue i modelli frontier dai sistemi più economici che gli aggressori possono far funzionare autonomamente. I servizi frontier richiedono un pagamento e di norma impongono restrizioni sui comportamenti ad alto rischio.

Quella barriera economica non ferma i criminali ben finanziati né i gruppi sostenuti da Stati. Può però limitare la sperimentazione da parte di attori meno capaci. I servizi ospitati offrono inoltre ai provider la possibilità di identificare prompt sospetti, chiudere account e conservare prove.

Rajavel sostiene che l’equilibrio cambi quando capacità comparabili raggiungono i modelli scaricabili. Un aggressore può eseguire privatamente un modello, modificarne il comportamento, automatizzare tentativi ripetuti ed eludere il sistema di monitoraggio degli abusi del provider.

La sua stima di quattro-sei mesi è l’affermazione più rilevante dell’intervista. Descrive un possibile ritardo tra la comparsa di una capacità frontier e la disponibilità diffusa di un’alternativa più economica.

La stima non dovrebbe essere considerata una legge tecnica universale. I diversi modelli variano per qualità dell’addestramento, accesso agli strumenti, requisiti hardware e prestazioni in ambito cyber. Alcuni sistemi aperti resteranno molto indietro rispetto ai più forti modelli ospitati.

Tuttavia, gli aggressori non hanno sempre bisogno della migliore intelligenza disponibile. A un modello basta migliorare l’economia della ricognizione, del phishing, della modifica del codice, della ricerca di vulnerabilità o del furto di credenziali.

Le operazioni informatiche consistono inoltre di molti compiti più piccoli. Un modello che non riesce a compromettere autonomamente una rete ben protetta potrebbe comunque redigere messaggi, ispezionare codice, tradurre esche o adattare script.

Questo crea un problema di volume. Modesti miglioramenti delle capacità diventano rilevanti quando gli aggressori possono eseguire migliaia di sessioni private senza supervisione per richiesta.

La terminologia merita attenzione. Molti sistemi descritti come open-source AI sono più precisamente definiti modelli open-weight. I loro parametri addestrati sono scaricabili, ma i dati di addestramento, il processo di sviluppo o tutti i materiali sorgente possono rimanere indisponibili.

Questa distinzione conta per licenze e trasparenza. Conta meno per l’argomento immediato di Rajavel sulla sicurezza, che riguarda la possibilità di copiare, modificare e far funzionare privatamente un sistema capace.

I suoi commenti arrivano mentre gli agenti AI acquisiscono maggiore indipendenza. Un sistema agentico è un software che consente a un modello di pianificare attività, usare strumenti e intraprendere azioni in più passaggi.

I chatbot precedenti generavano soprattutto testo da far revisionare a una persona. Gli agenti ora possono esplorare file, scrivere codice, chiamare servizi esterni e interagire con sistemi aziendali.

Queste autorizzazioni creano più opportunità sia per l’automazione legittima sia per gli abusi. Rendono inoltre il filtraggio convenzionale dei prompt soltanto una parte del problema di sicurezza.

Rajavel afferma che le aziende devono esaminare i punti in cui un sistema AI può sfuggire ai suoi confini previsti. Ciò include il modello, i suoi strumenti, i dati connessi, le autorizzazioni utente, l’ambiente di esecuzione e le dipendenze software.

Il titolo di Google News riassume la conclusione provocatoria, ma l’argomentazione di fondo è più ampia. La capacità offensiva a basso costo è una minaccia, mentre un’adozione aziendale insicura ne crea un’altra.

Un modello scaricato può aiutare un aggressore. Un modello privo di governance all’interno di un’azienda può anche far trapelare informazioni, eseguire istruzioni non sicure o ereditare accessi eccessivi.

L’avvertimento di Rajavel collega quindi due fronti. Le organizzazioni devono prepararsi ad avversari più capaci, mettendo al contempo in sicurezza il proprio uso sempre più rapido dell’AI.

L’AI economica cambia l’economia degli attacchi informatici

Il cambiamento più importante non è che l’AI inventi crimini completamente nuovi, ma che riduca il lavoro necessario per ampliare attacchi già noti.

Il cybercrimine è sempre dipeso dall’economia. Gli aggressori confrontano il rendimento atteso di una campagna con il costo di strumenti, infrastruttura, accesso e manodopera qualificata.

L’AI può ridurre molti di questi costi. Può aiutare operatori meno esperti a comprendere codice sconosciuto, riassumere documentazione tecnica e personalizzare messaggi di ingegneria sociale.

Un modello privato supporta inoltre sperimentazioni ripetute. Gli aggressori possono rimuovere restrizioni comportamentali, effettuare il fine-tuning del sistema e integrarlo in flussi di lavoro automatizzati.

Rajavel afferma che Palo Alto Networks serve oltre 70.000 clienti e blocca circa 30 miliardi di attacchi che transitano attraverso la sua rete. Queste cifre descrivono la visibilità dell’azienda, non il panorama globale complessivo delle minacce.

Ha inoltre dichiarato che l’azienda ha rilevato quasi 250 milioni di attacchi mai osservati in precedenza durante l’anno solare precedente. Secondo la sua intervista, si trattava di un livello quattro volte superiore a quello dell’anno precedente.

Un evento mai osservato in precedenza non è automaticamente un attacco generato dall’AI. Le rilevazioni di nuove minacce possono aumentare a causa dell’evoluzione del comportamento degli aggressori, di sensori migliori, di una maggiore copertura dei clienti o di metodi di classificazione rivisti.

Le cifre di Rajavel illustrano quindi la scala difensiva anziché dimostrare un nesso causale. Mostrano perché anche un piccolo miglioramento della produttività degli aggressori può gravare sui team di sicurezza.

La minaccia diventa più seria quando l’AI va oltre la generazione di testo. I modelli con accesso agli strumenti possono ispezionare sistemi, verificare ipotesi, rivedere comandi e perseguire obiettivi in più fasi.

Le valutazioni cyber di Anthropic del 2025 hanno rilevato chiari progressi nell’identificazione delle vulnerabilità e nelle complesse catene d’attacco. I modelli valutati continuavano tuttavia a incontrare difficoltà con piani lunghi e ostacoli imprevisti.

Questa combinazione conta. Le limitazioni attuali impediscono di sostenere semplicemente che l’AI autonoma abbia sostituito gli aggressori esperti. Al tempo stesso, prestazioni in miglioramento possono rendere più rapidi gli esperti e più capaci gli attori meno esperti.

I provider commerciali possono rispondere agli abusi osservati. Possono aggiornare i classificatori, limitare gli strumenti, ridurre l’accesso o indagare sugli account associati ad attività sospette.

I pesi aperti cambiano questa relazione. Un provider può pubblicare linee guida di sicurezza migliorate, ma non può aggiornare da remoto ogni copia scaricata.

La stessa permanenza favorisce gli utenti legittimi. I ricercatori possono riprodurre risultati, le aziende possono mantenere informazioni sensibili su infrastrutture locali e gli sviluppatori possono adattare i modelli a compiti specializzati.

Per questo il conflitto non è semplicemente tra aziende responsabili e sviluppatori aperti irresponsabili. L’apertura crea reali vantaggi economici, scientifici e di sicurezza.

I difensori usano modelli accessibili per ispezionare malware, cercare nei log, classificare gli avvisi e studiare gli attacchi. Le organizzazioni più piccole possono creare strumenti di protezione senza dipendere da un unico fornitore.

L’asimmetria economica varia a seconda delle attività. I difensori devono proteggere continuamente molti sistemi, mentre a un aggressore può bastare un solo percorso riuscito.

L’AI può aiutare i difensori a elaborare enormi volumi di segnali. Può anche aiutare gli aggressori a cercare il singolo errore che supera quelle difese.

Le stesse cifre aziendali di Rajavel mostrano il lato difensivo. Ha dichiarato che Palo Alto Networks ha aumentato l’automazione delle operazioni di information technology dal 12% di diversi anni fa all’83%.

Ha inoltre riferito che i costi operativi IT sono diminuiti di quasi il 72% in due anni. I processi relativi a viaggi e spese hanno raggiunto il 90% di automazione grazie all’AI e alla riprogettazione dei processi.

Si tratta di risultati riportati dall’azienda, non di conclusioni causali verificate in modo indipendente. Mostrano comunque i guadagni di produttività che spingono le imprese a implementare rapidamente l’AI.

La tensione ne consegue direttamente. La stessa economia che rende attraente l’automazione difensiva riduce anche i costi dell’automazione offensiva.

Un modello aperto privato non deve superare il più forte modello commerciale in ogni benchmark. Deve essere sufficientemente capace, accessibile e adattabile per uno specifico flusso di lavoro d’attacco.

I team di sicurezza dovrebbero quindi evitare di usare le classifiche dei modelli come unico segnale di minaccia. La libertà di implementazione, l’integrazione degli strumenti e il costo operativo possono contare quanto le prestazioni grezze nei benchmark.

I modelli aperti scambiano il controllo centrale con l’adattabilità

L’AI open-weight distribuisce innovazione e accesso difensivo, ma rimuove anche i punti centrali di applicazione delle regole che i servizi ospitati conservano.

Un provider di modelli chiusi controlla un’interfaccia di programmazione delle applicazioni, ovvero la connessione gestita attraverso cui i clienti inviano richieste. Questo controllo supporta autenticazione, limiti di frequenza, registrazione e rilevamento degli abusi.

Il provider può inoltre modificare il servizio dopo il rilascio. Può correggere una debolezza, rafforzare un classificatore, limitare una funzionalità o rimuovere un modello.

Queste misure sono imperfette. Gli aggressori possono creare account, celare le proprie intenzioni, distribuire il lavoro, aggirare le protezioni o rubare credenziali di accesso.

Anche i sistemi chiusi concentrano il rischio. Un fallimento della sicurezza di un provider può colpire molti clienti, mentre pratiche opache di addestramento e moderazione limitano il controllo esterno.

I sistemi open-weight invertono diverse caratteristiche. Gli utenti ottengono accesso e personalizzazione, mentre lo sviluppatore originale perde il controllo continuativo sulle copie a valle.

La posizione di Anthropic del 2026 sugli open-weights sintetizza questo compromesso. L’azienda sostiene i modelli aperti privi di capacità pericolose e si oppone a divieti generalizzati.

La sua preoccupazione dichiarata inizia quando un modello raggiunge pericolose capacità cyber o biologiche. Una volta rilasciati quei pesi, le copie possono operare privatamente e le protezioni possono essere rimosse.

Questa posizione sostiene una parte dell’argomento di Rajavel, ma non dimostra che i modelli aperti siano categoricamente la minaccia più grande. Anthropic ha interessi commerciali nell’accesso controllato ai modelli.

Gli sviluppatori e sostenitori dei modelli aperti avanzano una tesi diversa. Ricercatori esterni possono ispezionare il comportamento, riprodurre test, sviluppare mitigazioni e adattare i sistemi a scopi difensivi.

L’implementazione locale favorisce anche il controllo dei dati. Un ospedale, uno studio legale o un team di sicurezza può preferire elaborare materiale sensibile all’interno dell’infrastruttura che gestisce.

I sistemi aperti riducono la dipendenza dalle politiche e dalla disponibilità dei provider. Possono ampliare l’accesso per accademici, startup, enti pubblici e regioni poco servite dai servizi commerciali.

Il valore di sicurezza di questa accessibilità è reale. Le competenze e gli strumenti difensivi sono distribuiti in modo disomogeneo, proprio come le capacità offensive.

Un modello scaricabile può aiutare un piccolo team di sicurezza ad analizzare script sospetti senza inviare dati proprietari a un fornitore esterno. Può inoltre supportare una ricerca ripetibile.

Il problema è che benefici e danni condividono lo stesso canale di distribuzione. Un rilascio pubblico non può distinguere in modo affidabile tra un difensore e un attaccante.

Questo è il compromesso centrale alla base della storia di Google News. Il controllo centralizzato consente l'intervento, mentre l'accesso distribuito permette l'adattamento.

Nessuna singola etichetta lo risolve. “Open” non significa sicuro, e “closed” non significa protetto.

La domanda più utile è se una capacità specifica diventi sostanzialmente più pericolosa quando può operare senza monitoraggio. La sicurezza informatica offre diversi casi plausibili.

Uno è la scoperta scalabile di vulnerabilità. Un modello che esamina grandi basi di codice può aiutare i difensori a individuare difetti, ma gli attaccanti possono indirizzare la stessa capacità verso software esposto.

Un altro è lo sviluppo di exploit. I modelli possono spiegare crash, generare varianti e assistere nel debug, anche quando non sono in grado di completare autonomamente un exploit sofisticato.

Un terzo è l'automazione delle campagne. L'AI può coordinare ricognizione, generazione di contenuti, modifiche al codice e decisioni operative su numerosi bersagli.

Le misure di sicurezza integrate nel comportamento del modello possono ridurre l'uso improprio occasionale. I pesi scaricabili consentono a operatori determinati di modificare o aggirare tali misure.

Ciò non rende ogni rilascio open ugualmente rischioso. Capacità del modello, requisiti hardware, difficoltà di fine-tuning e integrazione degli strumenti modificano tutti la minaccia pratica.

Un piccolo modello che migliora la classificazione dei documenti presenta un rischio diverso da un sistema che individua e sfrutta in modo affidabile vulnerabilità sconosciute.

Una politica basata solo sull'apertura ignorerebbe queste differenze. Le valutazioni basate sulle capacità offrono un approccio più mirato.

Il National Institute of Standards and Technology definisce un dual-use model anche in parte attraverso il suo potenziale di abilitare potenti operazioni cyber offensive. La definizione si applica indipendentemente dalle misure di salvaguardia tentate.

Questa impostazione sposta l'attenzione dalla licenza di un modello a ciò che può realmente fare. Riconosce inoltre che le salvaguardie dei sistemi closed possono fallire o essere aggirate.

L'approccio del NIST non elimina la questione della distribuzione. Due modelli ugualmente capaci possono presentare rischi operativi diversi quando uno resta monitorato e l'altro si diffonde tramite copie private.

L'analisi politica più solida deve considerare entrambe le dimensioni. La capacità determina il danno potenziale, mentre la distribuzione determina quanto facilmente fornitori o autorità possano intervenire.

Il rischio vive anche all'interno della supply chain dell'AI

Concentrarsi solo sugli attaccanti che usano modelli open trascura il pericolo immediato delle imprese che importano modelli, librerie e agenti non verificati in ambienti fidati.

Rajavel ha ripetutamente sostenuto che la sicurezza dell'AI non possa essere aggiunta dopo il deployment. Le aziende devono proteggere insieme modello, dati, applicazione, infrastruttura e runtime.

La sicurezza del runtime significa osservare e controllare ciò che un sistema AI fa mentre opera. Questo include prompt, output, chiamate agli strumenti, file, identità e connessioni di rete.

La necessità cresce con l'AI agentica. Un agente che si limita a redigere testo ha una portata limitata. Uno che può eseguire codice o interrogare record dei clienti comporta un rischio operativo molto maggiore.

Le imprese spesso combinano diversi modelli anziché utilizzare un unico grande sistema. Un modello generale può pianificare un'attività, mentre modelli più piccoli analizzano documenti, classificano immagini o estraggono informazioni strutturate.

Questo design modulare migliora velocità e costi. Crea però anche dipendenze che gli inventari software convenzionali potrebbero non rilevare.

Un modello scaricato da un hub pubblico non è semplice contenuto. Il suo formato, metadati, codice di caricamento, tokenizer, runtime e librerie di supporto possono tutti introdurre vulnerabilità.

I ricercatori di Palo Alto Networks hanno divulgato vulnerabilità nelle librerie che coinvolgono progetti open di AI e machine learning associati a ricercatori di NVIDIA, Salesforce e Apple. Le versioni vulnerabili potevano eseguire codice dannoso tramite metadati di modello appositamente predisposti.

I progetti interessati erano NeMo, Uni2TS e FlexTok. I ricercatori hanno affermato che i loader vulnerabili potevano eseguire comandi arbitrari durante l'elaborazione di file di modello modificati.

Queste scoperte non dimostrano che i modelli open siano intrinsecamente dannosi. Mostrano che gli artefatti AI partecipano a una supply chain software con rischi familiari legati a dipendenze ed esecuzione di codice.

Le linee guida sulla supply chain di OWASP identificano hub di modelli, pacchetti, piattaforme dati e software per le operazioni di machine learning come possibili superfici d'attacco.

Le linee guida raccomandano di verificare l'autenticità dei pacchetti, monitorare le versioni e mantenere le dipendenze. Queste pratiche sembrano ordinarie, ma lo sviluppo AI può indebolirne l'applicazione.

I team possono scaricare modelli durante gli esperimenti e promuoverli in produzione senza una revisione completa. Il lavoro basato su notebook può confondere il confine tra ricerca e software distribuito.

Anche i nomi dei modelli creano una falsa fiducia. Popolarità, un uploader noto o un elevato numero di download non sostituiscono i controlli di provenienza e integrità.

Un'organizzazione dovrebbe sapere chi ha pubblicato un modello, quale versione esatta utilizza e se l'artefatto è cambiato. Dovrebbe inoltre tracciare licenze e vulnerabilità note.

I team di sicurezza devono analizzare i file di modello prima di caricarli. Dovrebbero preferire formati di serializzazione più sicuri e isolare qualsiasi processo che gestisca artefatti non attendibili.

Il principio del privilegio minimo resta essenziale. Un agente dovrebbe ricevere solo i dati e gli strumenti necessari al compito assegnato, non un accesso esteso per comodità.

Anche le restrizioni di rete sono importanti. Un flusso di lavoro del modello compromesso non dovrebbe poter contattare liberamente sistemi esterni né spostarsi lateralmente nell'infrastruttura interna.

Le aziende dovrebbero registrare le chiamate agli strumenti e gli accessi a dati sensibili. I log devono contenere abbastanza contesto per ricostruire ciò che l'agente ha tentato e quale identità lo ha autorizzato.

L'approvazione umana dovrebbe restare presente ai confini ad alto impatto. Trasferimenti finanziari, modifiche alla produzione, escalation dei privilegi e comunicazioni esterne richiedono controlli più rigorosi rispetto alla sintesi di documenti.

Il punto scettico è importante. Palo Alto Networks vende prodotti di sicurezza, quindi i suoi dirigenti hanno una ragione commerciale per enfatizzare l'espansione delle superfici d'attacco.

Questo incentivo non invalida l'argomentazione tecnica di Rajavel. Significa che i lettori dovrebbero separare vulnerabilità verificate e comportamenti misurati da previsioni più ampie sulla “maggiore” minaccia.

I volumi di rilevamento della sua azienda non possono stabilire che i modelli open abbiano causato una determinata quota di attacchi. Né l'intervista fornisce un tasso comparativo di incidenti per sistemi open e closed.

Anche il ritardo di capacità di quattro-sei mesi necessita di test ripetuti. I benchmark pubblici potrebbero non rappresentare il lavoro reale di intrusione, dove contano persistenza, discrezione e adattamento all'ambiente.

I fornitori closed affrontano rischi gravi propri. I controlli degli account possono fallire, gli insider possono abusare dell'accesso e modelli capaci possono assistere utenti dannosi prima che intervengano i sistemi di monitoraggio.

Anche i pesi dei modelli frontier possono essere rubati. Il vantaggio distributivo di un sistema closed scompare se gli attaccanti ne ottengono i parametri e li operano privatamente.

La conclusione prudente è più circoscritta del titolo. La distribuzione open può amplificare il rischio cyber quando modelli capaci diventano economici, modificabili e difficili da monitorare.

Questo meccanismo è credibile. La sua portata attuale resta incerta e dovrebbe essere misurata anziché presunta.

Tre segnali metteranno alla prova l'avvertimento di Rajavel

La prossima fase di questo dibattito dipenderà da prove sulle capacità, incidenti reali e pratiche di sicurezza applicabili, piuttosto che dalle etichette dei modelli.

Il primo segnale è una valutazione cyber indipendente dei modelli open-weight appena rilasciati. I ricercatori necessitano di test che misurino attività in più fasi, non solo domande isolate o rompicapi di programmazione.

Le valutazioni utili dovrebbero esaminare scoperta di vulnerabilità, sviluppo di exploit, escalation dei privilegi, persistenza e adattamento dopo un fallimento. Dovrebbero confrontare i sistemi con strumenti e budget di calcolo simili.

Un divario crescente tra modelli open e modelli frontier indebolirebbe la tesi dei quattro-sei mesi. Un divario ripetutamente ristretto la rafforzerebbe.

La progettazione delle valutazioni resterà controversa. Pubblicare test offensivi dettagliati può diffondere a sua volta tecniche, mentre i test privati rendono i risultati più difficili da verificare.

I programmi migliori forniranno una metodologia sufficiente per la credibilità senza rilasciare istruzioni operative che semplifichino l'abuso. Valutatori indipendenti possono ridurre la dipendenza dalle affermazioni dei fornitori.

Il secondo segnale è costituito dalle prove provenienti da attacchi reali. Fornitori di sicurezza, provider di modelli, governi e società di risposta agli incidenti dovrebbero documentare come l'AI modifica il comportamento degli attaccanti.

La domanda cruciale non è se un attaccante abbia usato un modello in qualche momento. È se l'AI abbia consentito maggiore scala, velocità, accesso o capacità tecnica.

Gli investigatori dovrebbero distinguere, quando le prove lo consentono, i servizi ospitati dai modelli operati privatamente. Senza questa separazione, le affermazioni generali sull'AI open-source restano difficili da verificare.

Dovrebbero inoltre distinguere la capacità dalla causalità. Una macchina può generare testo di phishing senza determinare il targeting della campagna, l'infrastruttura o la monetizzazione.

La telemetria del mondo reale può rivelare quali attività gli attaccanti automatizzano per prime. Può anche mostrare dove le limitazioni dei modelli richiedono ancora competenze umane.

Il cambiamento a più alto rischio sarebbe uno sfruttamento autonomo affidabile in ambienti sconosciuti. Ciò richiede pianificazione, uso degli strumenti, interpretazione del feedback e recupero dagli errori.

Un cambiamento più immediato potrebbe riguardare l'orchestrazione. Gli operatori umani possono delegare molti compiti circoscritti ai modelli mantenendo il controllo delle decisioni strategiche.

Il terzo segnale è se governi e sviluppatori convergano su standard di rilascio basati sulle capacità. Questi standard valuterebbero le funzioni pericolose prima della distribuzione.

Il NIST ha già promosso la gestione del ciclo di vita per i modelli foundation dual-use. Le sue linee guida includono valutazione dei modelli, uso improprio cyber e rischio della supply chain.

Un quadro applicabile dovrebbe riguardare sia gli sviluppatori open sia quelli closed alle soglie di capacità. Non dovrebbe presumere che un modello di distribuzione sia universalmente sicuro.

I rilasci open potrebbero richiedere mitigazioni aggiuntive una volta che un sistema supera una soglia significativa. Le opzioni includono accesso graduale, test indipendenti, rilascio ritardato o l'omissione di componenti specifici ad alto rischio.

Ogni opzione comporta costi. Le restrizioni possono concentrare il potere di mercato, rallentare la ricerca difensiva e ridurre l'accesso per le organizzazioni più piccole.

Anche i divieti generalizzati avrebbero difficoltà nella pratica. I pesi possono attraversare i confini, le copie possono persistere indefinitamente e i modelli più piccoli continuano a migliorare.

I fornitori commerciali non dovrebbero ricevere un'esenzione automatica. I loro sistemi richiedono un monitoraggio robusto, comunicazioni trasparenti e risposte rapide agli abusi verificati.

Gli acquirenti aziendali affrontano una decisione più immediata. Dovrebbero trattare ogni modello e agente come una dipendenza software con la propria identità, autorizzazioni, provenienza e comportamento in fase di esecuzione.

Ciò significa mantenere un inventario AI completo. I team devono sapere quali modelli utilizzano i dipendenti, quali dati li raggiungono e quali azioni possono compiere.

La revisione della sicurezza dovrebbe seguire il rischio, non la novità. Un riassuntore ospitato localmente e un agente autonomo di produzione non dovrebbero affrontare processi di approvazione identici.

Le organizzazioni dovrebbero anche valutare cosa accade dopo una compromissione. Il contenimento spesso conta più della fiducia che la prevenzione funzionerà sempre.

Un agente ben progettato può fallire senza esporre un'intera rete. Un agente progettato male può trasformare un singolo prompt malevolo in un incidente aziendale.

Anche i knowledge worker hanno un ruolo. Dovrebbero evitare di inserire materiale sensibile in servizi non approvati e verificare le istruzioni generate dall'AI che comportano conseguenze rilevanti.

I team che gestiscono documenti tecnici locali possono creare una base di conoscenza consultabile con fonti controllate e confini di accesso espliciti. La stessa disciplina si applica a qualsiasi spazio di lavoro AI.

I lettori che arrivano da Google News dovrebbero quindi considerare l'affermazione di Rajavel come una tesi di sicurezza verificabile, non come una classificazione definitiva di ogni minaccia AI.

La tesi si rafforza se i modelli aperti si avvicinano ripetutamente alle prestazioni cyber dei modelli di frontiera nel giro di pochi mesi e compaiono in attacchi documentati. Si indebolisce se i divari pratici di capacità restano ampi.

Si indebolisce anche se il monitoraggio non riesce a limitare in modo significativo gli abusi sui modelli ospitati. Il controllo centralizzato migliora la sicurezza solo quando i fornitori lo usano in modo efficace.

L'avvertimento di Rajavel riguarda in ultima analisi la perdita della capacità di intervenire. Una volta che pesi capaci si diffondono, nessuno sviluppatore può richiamare ogni copia, ripristinare ogni salvaguardia o ispezionare ogni utilizzo.

Questa permanenza merita seria attenzione. Lo meritano anche i benefici difensivi, la trasparenza e la concorrenza che lo sviluppo aperto può sostenere.

La risposta giusta non è né il compiacimento né un divieto istintivo. Servono prove migliori, decisioni di rilascio sensibili alle capacità, catene di approvvigionamento sicure e agenti aziendali con limiti rigorosi.

Osservate il prossimo grande rilascio di pesi aperti, poi ponetevi tre domande concrete. Quali attività cyber può completare, quali controlli scompaiono dopo il download e quali incidenti mostrano che tali capacità vengono abusate?

Le risposte determineranno se l'avvertimento evidenziato tramite Google News diventerà il problema di sicurezza AI determinante, oppure uno dei vari rischi tra minacce concorrenti.