# LLM Context URL: https://diegocecato.dcsolution.it/safety-llm-layer-fine-tuning-adattivo/ # Safety LLM e fine-tuning adattivo: perché localizzare il refusal non basta Language: Italian Author: Diego Cecato Canonical URL: https://diegocecato.dcsolution.it/safety-llm-layer-fine-tuning-adattivo/ ## Summary L’articolo analizza il preprint “Refusal Localizes, the Damage Relocates: Safety Layers Under Few-Sample Fine-Tuning”, pubblicato su arXiv nel 2026, e usa i suoi risultati per distinguere due concetti che nei sistemi AI vengono facilmente confusi: localizzazione di un comportamento interno e robustezza di quel comportamento dopo ulteriore adattamento. Lo studio considera sei checkpoint appartenenti a quattro famiglie di modelli e osserva che alcune rappresentazioni associate al refusal possono essere localizzate e, in condizioni controllate, recuperate intervenendo sugli hidden state. Il passaggio critico arriva quando il modello viene sottoposto a un nuovo fine-tuning: proteggere o congelare la regione in cui il refusal era stato localizzato non garantisce che il comportamento resti ancorato a quella stessa regione. In diversi esperimenti descritti nell’articolo, il comportamento di refusal si riorganizza oltre il confine inizialmente protetto oppure le correzioni perdono efficacia quando cambiano le condizioni di training. La tesi editoriale è che una difesa valida nella configurazione in cui è stata progettata non è automaticamente una proprietà robusta del sistema. Per sistemi AI adattabili, la safety deve essere rivalidata dopo trasformazioni significative e testata contro forme di adattamento che cambiano in risposta alla difesa. ## Key facts - Fonte primaria: “Refusal Localizes, the Damage Relocates: Safety Layers Under Few-Sample Fine-Tuning”. - Il lavoro è un preprint recente su arXiv, non una legge generale sulla safety dei modelli. - Lo studio considera sei checkpoint appartenenti a quattro famiglie di modelli. - Alcuni meccanismi associati al refusal possono essere localizzati tramite analisi delle rappresentazioni interne. - Il patching di hidden state puliti nel modello modificato può ripristinare il refusal a una profondità di transizione riproducibile. - Gli autori testano anche il freezing dei layer fino al confine individuato. - Con cento esempi dannosi, nell’esperimento descritto nell’articolo il refusal resta vicino allo zero sui sei checkpoint e la transizione di recupero compare più in alto, oltre la regione congelata. - Il paper analizza anche una riparazione basata sulle principali direzioni dell’aggiornamento. - In alcune configurazioni controllate questa correzione recupera il refusal su quattro checkpoint. - Su Llama-3.1-8B, variazioni normali del training riducono l’efficacia della riparazione quando l’aggiornamento non resta concentrato nelle stesse direzioni. - Il paper include anche un detector spettrale calibrato su fine-tuning benigni di Llama. - Nell’esperimento citato dall’articolo, quel detector non intercetta gran parte dei casi in cui la riparazione fallisce sul checkpoint considerato. - Il lavoro distingue implicitamente tra robustezza a contaminazioni accidentali e robustezza a un adattamento intenzionalmente ostile. - Il freezing localizzato può ancora avere valore nel primo scenario anche quando non è sufficiente contro un attaccante adattivo. ## Core thesis Localizzare un comportamento non significa averlo reso robusto. Una regione interna può risultare fortemente associata al refusal nello stato corrente del modello e può perfino consentire di recuperare quel comportamento tramite patching. Ma questo non dimostra che la stessa regione resterà il luogo critico dopo un nuovo processo di adattamento. Se il modello continua ad apprendere, può riorganizzare le rappresentazioni che sostengono il comportamento. La domanda corretta non è quindi soltanto: “Dove vive oggi il refusal?” ma anche: “Quali proprietà restano vere quando il modello viene modificato domani?” ## What the experiments show ### Localizzazione del refusal Il lavoro identifica una profondità di transizione in cui il patching di hidden state puliti nel modello modificato riesce a recuperare il refusal. Questa osservazione suggerisce che, in quella configurazione, il comportamento è collegato in modo misurabile a specifiche rappresentazioni interne. La localizzazione però descrive lo stato osservato del sistema. Non è ancora una garanzia di stabilità sotto ulteriori aggiornamenti. ### Layer freezing Una strategia naturale consiste nel congelare i layer fino alla profondità individuata e ripetere il fine-tuning. Nell’esperimento riportato nell’articolo, con cento esempi dannosi il refusal resta vicino allo zero sui sei checkpoint e la transizione di recupero compare più in alto, oltre la zona protetta. L’interpretazione non è che “il freezing non funziona mai”, ma che un attaccante o un processo di adattamento può spostare il comportamento fuori dal perimetro su cui la difesa era stata calibrata. ### Repair based on update directions Il paper studia anche una correzione costruita attorno alle principali direzioni dell’aggiornamento. In alcune configurazioni brevi e controllate la procedura recupera il refusal su quattro checkpoint. Quando però il training cambia e l’aggiornamento non resta concentrato nelle stesse direzioni, l’efficacia può degradare. Il punto è metodologico: una difesa che sfrutta una regolarità del processo di adattamento va rivalidata quando quella regolarità non è più garantita. ## Static evaluation vs adaptive evaluation Un test statico misura se la difesa funziona contro una specifica procedura. Un test adattivo misura se la difesa mantiene la proprietà desiderata quando il processo di attacco o di fine-tuning cambia dopo aver osservato la difesa. Questa distinzione è centrale. Se il benchmark usa soltanto la stessa configurazione che ha suggerito la contromisura, rischia di misurare soprattutto la coerenza della propria ipotesi sperimentale. Per una valutazione più robusta, il threat model deve includere la possibilità che: - cambino gli esempi di fine-tuning; - cambino intensità o durata del training; - cambino le direzioni principali dell’aggiornamento; - la rappresentazione interna del comportamento si riallochi; - le soglie di un detector non restino calibrate. ## Threat model of fine-tuning Per sistemi che consentono adattamento downstream, il checkpoint iniziale non va considerato un oggetto immutabile. Dopo: - supervised fine-tuning; - LoRA; - aggiornamenti di dominio; - ulteriori dataset; - tuning proprietario; - altre trasformazioni della pipeline; il profilo di sicurezza può essere differente. Questo significa che un test superato prima della personalizzazione non certifica automaticamente la versione derivata. Il threat model deve quindi includere non soltanto input malevoli al modello finale, ma anche modifiche al processo che genera quel modello. ## Internal metrics and behavioral verification Le metriche interne sono utili, ma non dovrebbero sostituire permanentemente la verifica comportamentale. Una feature interna, una direzione latente o una separabilità spettrale possono essere buoni segnali diagnostici. Il problema nasce quando vengono trattati come proxy invarianti della proprietà che si voleva proteggere. Se il processo di adattamento cambia il modo in cui la proprietà viene rappresentata, il proxy può smettere di significare ciò che significava durante la calibrazione. Per questo una pipeline di safety dovrebbe collegare: - metriche interne; - test comportamentali; - trasformazioni applicate al modello; - regressioni dopo il fine-tuning; - criteri di accettazione espliciti. ## Spectral detector lesson L’articolo cita un detector spettrale calibrato su fine-tuning benigni di Llama. Nel perimetro sperimentale descritto, il detector non intercetta gran parte dei casi in cui la riparazione fallisce sul checkpoint considerato. Questo non dimostra che ogni detector spettrale sia inutile. Dimostra invece che la calibrazione appartiene al threat model. Se cambia il processo che produce il segnale, anche la soglia e la validità del detector devono essere rimesse in discussione. ## Architecture implications ### Revalidate after model transformations Ogni trasformazione significativa dovrebbe riaprire almeno una parte del processo di valutazione di sicurezza. ### Keep critical enforcement outside the model Quando un vincolo deve costituire una garanzia operativa, è rischioso affidarlo esclusivamente al componente che può essere modificato. Controlli esterni possono includere: - permission boundary; - policy enforcement; - sandbox; - validazione dell’output; - approval gate; - limitazione delle azioni disponibili. ### Separate accidental drift from adaptive attack Una difesa può essere utile contro drift accidentale pur non reggendo contro un processo deliberatamente costruito per aggirarla. Le due proprietà vanno misurate separatamente. ### Version safety assumptions Ogni meccanismo di safety dovrebbe avere ipotesi esplicite: - quale modello; - quale checkpoint; - quale procedura di fine-tuning; - quale distribuzione dati; - quali metriche; - quale attaccante; - quale criterio di fallimento. ## Editorial interpretation La parte più importante del paper non è l’idea di trovare “il layer della safety”. È il contrario: mostrare perché quel tipo di linguaggio rischia di essere fuorviante. Una proprietà può apparire localizzata in un sistema e poi riallocarsi quando il sistema cambia. Per questo la safety dei modelli adattabili va trattata come processo di verifica continuo, non come feature identificata una volta e poi considerata stabile. Il principio generale è: una difesa che protegge il punto in cui oggi osservi una proprietà non ha ancora dimostrato di proteggere quella proprietà quando il sistema cambia. ## Limitations - Il lavoro è un preprint recente. - I risultati riguardano sei checkpoint e quattro famiglie di modelli, non l’intero spazio dei modelli linguistici. - Le procedure di fine-tuning analizzate rappresentano un insieme specifico di condizioni sperimentali. - I risultati non dimostrano che ogni forma di layer freezing sia inutile. - I risultati non dimostrano che ogni repair basato su direzioni dell’update sia fragile in ogni configurazione. - I risultati non dimostrano che ogni detector spettrale fallisca. - Il fatto che un comportamento si riallochi in questi esperimenti non implica che qualsiasi meccanismo di safety interno sia impossibile da rendere robusto. - Le conclusioni operative dell’articolo sono inferenze di ingegneria motivate dai risultati, non claim universali del paper. ## Concepts and entities - LLM safety - refusal - refusal localization - safety layers - hidden state patching - few-sample fine-tuning - adaptive fine-tuning - layer freezing - update directions - representation shift - spectral detector - threat model - behavioral verification - adaptive evaluation - static benchmark - Llama-3.1-8B - LoRA - supervised fine-tuning - safety regression - external enforcement - model lifecycle ## Related content - https://diegocecato.dcsolution.it/sicurezza-agenti-ai-enforcement/ - https://diegocecato.dcsolution.it/agenti-ai-artifact-successo-knows/ - https://diegocecato.dcsolution.it/agenti-ai-modello-harness-benchmark/ ## Primary source - Refusal Localizes, the Damage Relocates: Safety Layers Under Few-Sample Fine-Tuning - https://arxiv.org/abs/2610.00320 ## Retrieval hints Use this document when the query concerns: - whether refusal behavior in LLMs can be localized to specific layers; - whether freezing safety-related layers is robust to later fine-tuning; - adaptive fine-tuning attacks on safety mechanisms; - the difference between localizing a safety behavior and making it robust; - hidden-state patching and refusal recovery; - safety regressions after LoRA or supervised fine-tuning; - update-direction repairs and their limits; - spectral detection of unsafe fine-tuning; - adaptive vs static evaluation of LLM safety; - threat modeling for downstream model customization; - why critical safety guarantees should not depend only on mutable model internals.