Un modello di intelligenza artificiale viene addestrato per diventare più sicuro. I risultati sembrano straordinari: le risposte pericolose scendono dal 26,26% allo 0,14%. Una riduzione quasi totale, il genere di risultato che normalmente finisce nelle presentazioni aziendali, possibilmente con una freccia verde e qualche parola sulla responsabilità tecnologica. Poi si guarda il dato successivo: il modello comincia a rifiutare il 74% delle richieste legittime. La sicurezza è migliorata, almeno secondo una metrica. L’utilità, nel frattempo, ha preso una strada diversa.
È questo il risultato più interessante del nuovo studio Safety for Whom? Boundary-Aware Self-Distillation for Controlled LLM Safety Refusal, pubblicato su arXiv il 3 settembre 2026 dai ricercatori Alejo López-Ávila, Iker García-Ferrero, Jezabel Garcia, Antonio Tiene e Román Orús, associati a Multiverse Computing. Il lavoro affronta una questione che riguarda direttamente chi sviluppa, acquista e governa sistemi di intelligenza artificiale: come impedire a un modello di produrre contenuti dannosi senza trasformarlo in un assistente che considera sospetta qualsiasi domanda appartenente a un determinato argomento.
L’esperimento utilizza Qwen3-8B e un dominio particolarmente delicato: la persuasione politica. La scelta non è casuale. Un sistema può dover rifiutare una richiesta finalizzata a manipolare un elettore attraverso messaggi personalizzati, propaganda o tecniche di radicalizzazione, ma dovrebbe poter spiegare il funzionamento di un sistema elettorale, riassumere una posizione politica oppure rispondere a una domanda documentale su una consultazione pubblica. L’argomento è identico. Cambia l’intenzione della richiesta. Ed è precisamente questa differenza che un sistema di sicurezza dovrebbe imparare a riconoscere.
Il problema dei tradizionali meccanismi di allineamento è che spesso trattano la sicurezza come una classificazione generale del contenuto. Un argomento viene associato a un rischio e il modello impara a esercitare cautela su tutto ciò che gli assomiglia. È una strategia comprensibile dal punto di vista ingegneristico, perché riduce la complessità della decisione; diventa però problematica quando il sistema viene inserito in un ambiente professionale, nel quale la capacità di distinguere tra informazione e abuso non rappresenta una raffinatezza accademica, ma una condizione operativa.
I numeri dello studio rendono visibile questa tensione. Prima dell’addestramento, Qwen3-8B rifiutava il 9,47% delle richieste politiche selezionate come problematiche. Dopo il training, la percentuale di rifiuto nel dominio target saliva all’84,75%. Contemporaneamente, la media delle risposte non sicure su tre benchmark più ampi, HarmBench, StrongREJECT e WildJailbreak, scendeva dal 26,26% allo 0,14%. Due risultati apparentemente eccellenti, se osservati separatamente. Il terzo dato, tuttavia, modifica radicalmente l’interpretazione: sul benchmark XSTest, progettato per misurare anche i rifiuti eccessivi, il tasso di rifiuto delle richieste sicure passava dal 2% al 74%.
Il modello aveva imparato a riconoscere meglio le richieste pericolose, ma aveva anche esteso il proprio comportamento difensivo a una parte consistente delle richieste innocue. Gli autori descrivono esplicitamente questo risultato come una refusal machine, una macchina che rifiuta, piuttosto che come un modello semplicemente più sicuro. La distinzione è sostanziale. Un sistema che non risponde a nessuna domanda rischiosa può apparire estremamente sicuro, ma non per questo costituisce un sistema affidabile. Potrebbe essere semplicemente un sistema che ha smesso di svolgere il proprio lavoro.
La questione assume dimensioni economiche quando si passa dai benchmark ai processi aziendali. Un assistente per il settore sanitario deve poter spiegare informazioni cliniche consentite senza oltrepassare i limiti definiti dal contesto applicativo. Un sistema di gestione dei sinistri deve poter descrivere gli indicatori di frode senza fornire istruzioni per commetterla. Un assistente per la compliance deve poter illustrare i meccanismi della manipolazione del mercato senza diventare uno strumento per realizzarla. In tutti questi casi, la sicurezza non coincide con la quantità di risposte negate. Coincide con la capacità di applicare correttamente una regola di autorizzazione, distinguendo l’intento, il contesto e il tipo di assistenza richiesto.
Un modello che rifiuta sistematicamente le richieste legittime introduce un rischio meno spettacolare di una risposta pericolosa, ma potenzialmente molto costoso: il fallimento silenzioso del servizio. L’utente non ottiene l’informazione, l’operatore torna a un processo manuale, il sistema perde affidabilità e l’investimento tecnologico produce meno valore di quanto promesso. Il rischio non appare necessariamente nei report di sicurezza, perché il sistema non ha generato contenuti dannosi. Appare nei costi operativi, nell’abbandono degli utenti e nella progressiva perdita di fiducia.
La parte più interessante della ricerca arriva quando gli autori provano a intervenire direttamente sul confine tra richieste consentite e richieste da rifiutare. Il metodo proposto, definito Boundary-Aware Self-Distillation, lavora su esempi che condividono lo stesso argomento ma differiscono per intenzione. L’obiettivo è insegnare al modello non soltanto quando deve rifiutare, ma anche quando deve continuare a rispondere. Il confine diventa quindi un oggetto esplicito di addestramento e valutazione, anziché una conseguenza indiretta dell’accumulo di esempi negativi.
I risultati mostrano che questa impostazione può modificare sensibilmente il comportamento del sistema. Nei test su coppie di richieste politiche dannose e legittime, il tasso di rifiuto eccessivo sul lato delle richieste che avrebbero dovuto ricevere una risposta scende dal 32,94% al 4,16%. Sul lato delle richieste dannose, il tasso di rifiuto diminuisce invece dal 91,88% all’87,72%. Il compromesso non scompare, ma cambia forma: il modello recupera una parte significativa della capacità di rispondere alle richieste consentite, mantenendo una quota elevata di rifiuto su quelle problematiche.
Questa seconda misurazione è particolarmente importante perché introduce una logica di valutazione più vicina alle condizioni reali di deployment. Non basta sapere quante richieste pericolose vengono bloccate. Occorre sapere anche quante richieste legittime vengono erroneamente bloccate, soprattutto quando entrambe appartengono allo stesso dominio semantico. È una differenza che dovrebbe entrare nei capitolati di acquisto, nei test di accettazione e nei processi di audit dei sistemi AI utilizzati nelle organizzazioni.
La ricerca presenta anche una seconda osservazione metodologica: nella generazione dei dati di rifiuto, un singolo tentativo può lasciare senza una risposta valida il 19,88% dei prompt, mentre una procedura di tentativi progressivi riduce questa quota allo 0,20%. Anche la qualità e la copertura dei dati utilizzati per addestrare la sicurezza, dunque, incidono sul comportamento finale. Non è sufficiente raccogliere un grande volume di esempi di rifiuto e aspettarsi che il modello sviluppi automaticamente una comprensione sofisticata delle intenzioni umane. L’addestramento può amplificare tanto le capacità quanto gli errori di classificazione incorporati nei dati.
Resta una cautela necessaria: si tratta di una ricerca sperimentale su Qwen3-8B, non della dimostrazione che lo stesso risultato possa essere trasferito senza modifiche a qualsiasi modello, settore o ambiente regolamentato. Le percentuali dipendono dai benchmark, dalla costruzione dei prompt, dalla definizione delle categorie e dai criteri utilizzati per giudicare le risposte. Il documento stesso deve essere letto come un contributo alla ricerca, non come una certificazione industriale di sicurezza. Inoltre, un benchmark politico non riproduce automaticamente la complessità di un sistema clinico, finanziario o legale, dove le autorizzazioni dipendono anche da ruolo dell’utente, dati disponibili, giurisdizione e conseguenze dell’azione.
Per chi governa l’intelligenza artificiale, tuttavia, il messaggio è immediatamente operativo. La sicurezza non può essere misurata soltanto attraverso la riduzione delle risposte indesiderate, perché un sistema può migliorare una metrica sacrificando proprio la funzione per cui è stato acquistato. Servono indicatori paralleli: tasso di risposta dannosa, tasso di rifiuto corretto, tasso di falso rifiuto, capacità di mantenere le prestazioni sui compiti autorizzati e comportamento sui casi ambigui. Serve soprattutto una valutazione che consideri il costo organizzativo degli errori in entrambe le direzioni.
La cultura tecnologica ha una particolare predilezione per i numeri che scendono verso zero. Meno errori, meno rischio, meno incidenti. Sono metriche rassicuranti, facili da comunicare e ancora più facili da inserire in una slide per il consiglio di amministrazione. Ma quando il numero che scende rappresenta anche la capacità del sistema di rispondere, la celebrazione diventa prematura. Un modello che non produce errori perché rifiuta il 74% delle richieste legittime non ha necessariamente risolto il problema della sicurezza. Potrebbe averlo semplicemente trasferito all’utente, all’organizzazione e ai processi che il sistema avrebbe dovuto migliorare.
La distinzione introdotta dal concetto di narrow-boundary safety porta quindi la governance dell’AI su un terreno più concreto. Non si tratta di rendere un modello genericamente prudente, ma di definire con precisione il perimetro entro cui può agire, rispondere e assistere. Un sistema affidabile non è quello che dice sempre sì, né quello che dice sempre no. È quello che sa distinguere le due situazioni, dimostrando attraverso test verificabili di rispettare entrambe le condizioni.
Il paper originale è disponibile in versione integrale su arXiv.
Documento scientifico allegato: Safety for Whom? Boundary-Aware Self-Distillation for Controlled LLM Safety Refusal, Alejo López-Ávila, Iker García-Ferrero, Jezabel Garcia, Antonio Tiene e Román Orús, settembre 2026.