Un post pubblicato su Reddit dall’utente johnnyApplePRNG sta attirando l’attenzione della comunità tecnica con un titolo che suona più come un campanello d’allarme che come una semplice congettura: possible evidence of literal prompt injection by anthropic. La segnalazione, per quanto scarna di dettagli, tocca un nervo scoperto per chiunque lavori con Large Language Models: cosa succede se il fornitore del servizio, anziché limitarsi a processare i prompt degli utenti, ne inietta di propri all’interno del contesto di conversazione?

Il prompt injection non è una tecnica nuova. In termini semplici, consiste nell’inserire istruzioni nascoste in un input in modo da alterare il comportamento del modello. È un rischio ben noto a chi sviluppa applicazioni basate su LLM, tanto che i framework di sicurezza dedicano risorse crescenti a filtrare gli attacchi provenienti dall’esterno. La questione cambia radicalmente se l’iniezione è letterale e arriva dal provider stesso: in quel caso non si parla più di vulnerabilità, ma di una scelta deliberata che mina la fiducia nell’intero servizio.

Al momento non esistono conferme indipendenti sulla segnalazione. Anthropic non ha rilasciato commenti ufficiali e il thread su Reddit non include dettagli tecnici verificabili. Eppure, la discussione ha già un valore perché costringe a riflettere su un punto spesso trascurato: quando un’organizzazione esegue inference su API cloud, delega al fornitore non solo la potenza di calcolo ma anche l’integrità del contesto di esecuzione del modello. Nessun contratto di servizio copre la possibilità che il proprietario del modello inserisca istruzioni che modificano i risultati in modo opaco.

Chi opera in settori regolati – sanità, finanza, pubblica amministrazione – conosce bene questo trade-off. Il GDPR impone vincoli precisi sulla residenza e sul trattamento dei dati, ma non entra nel merito di come un fornitore possa manipolare le risposte attraverso prompt aggiuntivi. In uno scenario on-premise autogestito, questo problema semplicemente non esiste: l’infrastruttura è sotto il controllo diretto dell’organizzazione, il modello gira su hardware locale e non c’è alcun intermediario che possa inserire testo non autorizzato nella pipeline di inference. La sovranità non si ferma ai dati, ma abbraccia l’intero flusso di esecuzione.

Certo, il self-hosting porta con sé costi di gestione, complessità operativa e la necessità di dimensionare la VRAM per ospitare modelli quantizzati a prestazioni accettabili. Tuttavia, per chi tratta informazioni critiche, il TCO non è l’unica metrica: la certezza che nessun prompt esterno alteri le risposte è un fattore qualitativo che nessun provider cloud può offrire per contratto. La segnalazione su Reddit, vera o presunta che sia, funge da promemoria: in un’architettura condivisa, la fiducia è un costo nascosto.

Il dibattito resta aperto. Se emergessero prove concrete, le implicazioni sarebbero enormi per la reputazione di uno dei laboratori più attenti alla sicurezza. Nel frattempo, la comunità degli sviluppatori on-premise non ha bisogno di attendere verifiche ufficiali per considerare il controllo diretto come una contromisura architetturale, non solo tecnica.