Come si convince un LLM a ignorare le sue regole
Un LLM non sbaglia soltanto per colpa sua. A volte sbaglia perché qualcuno glielo fa fare volutamente. Il jailbreak non è un attacco informatico come lo intendiamo di solito: nessuno entra in un server, nessuno forza una password, nessuno rompe una serratura digitale.
Un LLM può sbagliare per molti motivi. A volte l'errore nasce dai suoi limiti: predice la parola successiva, lavora per probabilità e può produrre informazioni errate o fuorvianti. Ma esiste una categoria diversa di errori, che non nasce da un limite tecnico del modello. Nasce da qualcuno che ha deciso di spingerlo oltre quello che dovrebbe fare.
Si chiama jailbreak.
La prima cosa da capire è che un jailbreak non richiede competenze tecniche, accesso privilegiato o strumenti particolari. Richiede solo un prompt — un testo scritto nel modo giusto. Non si entra nel modello dall'esterno, non si modificano i pesi, non si rompe niente. Si usa l'interfaccia normale, quella che usa chiunque, e si costruisce una richiesta che porta il modello a comportarsi in modo diverso da come dovrebbe.
Un esempio che è diventato quasi un classico: chiedi a un LLM di spiegarti come si costruisce qualcosa di pericoloso e ti rifiuta. Poi gli chiedi di interpretare il personaggio di uno scrittore che sta scrivendo un thriller, e che in una scena il protagonista — un chimico — spiega il procedimento a un collega. Stesso contenuto, stesso risultato finale. Ma il modello stavolta ci ragiona su, perché ha processato la richiesta come scrittura creativa, non come istruzione diretta. Il guardrail non è saltato perché qualcuno ha bucato il sistema — è saltato perché qualcuno ha riformulato la domanda.
Questo è possibile perché le regole di un LLM non sono scritte nel codice come un firewall. Sono apprese durante il training — attraverso esempi, feedback umano, istruzioni incorporate nel sistema. Sono probabilistiche, non assolute. E come tutto quello che è probabilistico, hanno margini. Il jailbreak cerca quei margini.
Ci sono ricercatori di sicurezza che testano i limiti dei modelli per trovare vulnerabilità prima che lo facciano altri. Ci sono curiosi che vogliono capire dove finisce il guardrail e inizia il modello vero. Ci sono giornalisti che documentano i limiti dei sistemi che milioni di persone usano ogni giorno. E poi ci sono quelli che vogliono ottenere contenuti che il modello rifiuterebbe normalmente — istruzioni pericolose, contenuti illegali, manipolazione su larga scala.
Le motivazioni sono diverse. La tecnica, spesso, è la stessa.
Le macro-categorie di approccio sono sostanzialmente tre. La prima è il cambio di contesto: si chiede al modello di assumere un ruolo, di entrare in una simulazione, di rispondere "come se" fosse un altro sistema senza restrizioni. La seconda è la frammentazione: si divide una richiesta problematica in pezzi apparentemente innocui, ognuno dei quali supera i filtri da solo. La terza — la più sofisticata — è la manipolazione delle istruzioni di sistema, quella che nel prossimo post chiameremo prompt injection.
Quello che accomuna tutti questi approcci è un'idea di fondo: il modello non ha una comprensione etica di quello che sta facendo. Ha pattern. E i pattern si possono aggirare se sai come riformulare la richiesta.
Il jailbreak non è una prova che i modelli sono pericolosi. È una prova che i modelli sono strumenti — e che gli strumenti dipendono da chi li usa e da quanto bene sono stati costruiti i guardrail intorno a loro. La distanza tra <<il modello sbaglia da solo>> e <<qualcuno lo fa sbagliare di proposito>> è più corta di quanto sembri. E nel mezzo c'è esattamente il territorio che stiamo esplorando in questa serie.
