Che cos’è un modello «abliterated»? Il rifiuto tolto dai pesi, non dal prompt
8 min di lettura
«Abliterated» non è un prompt astuto che convince il modello a rispondere a qualunque cosa. È un file di pesi modificato in modo permanente: una direzione interna della rete — quella che nei modelli di chat attiva il rifiuto — viene individuata e tolta dai numeri stessi del modello, non dalla conversazione. Il risultato non vive in una sessione: si scarica, si ridistribuisce, si rinomina quasi come l’originale. Chi lo esegue in casa non aggira nulla. Il rifiuto, semplicemente, non c’è più, in nessuna richiesta.
I numeri, verificati il 2 agosto 2026
Interrogando l’API pubblica di Hugging Face per il termine «abliterated» e seguendo la paginazione fino a quando il cursore si esaurisce, i repository restituiti sono 7.170: sette pagine piene da mille risultati più un resto di 170. Non un conteggio provvisorio troncato da un limite — la ricerca è stata spinta fino alla fine. Un numero che cambia di ora in ora e cresce, quindi conviene arrotondarlo per difetto: oltre 7.000, al momento del controllo.
Un’altra misurazione, indipendente e con metodo diverso, arriva da ThreatDown (Malwarebytes): il 21 luglio 2026 riferisce di aver trovato «over 6,000 models published openly on Hugging Face under self-declared guardrail-free labels» — un insieme più largo, che include anche le etichette «uncensored», «heretic», «decensored» e «unfiltered» — «downloaded more than 22 million times in a single 30-day window». Due rilevazioni a meno di due settimane di distanza, con perimetri diversi, che raccontano la stessa scala: non un fenomeno di nicchia.
Ordinando per download, i primi quattordici sommano oltre 4,8 milioni di scaricamenti (dato del 2 agosto 2026, sera, UTC): in cima non ci sono curiosità oscure. wangzhang/gemma-4-31B-it-abliterated (~842.000), Bahushruth/Qwen3.6-35B-A3B-abliterated-v4 (~836.000), mlabonne/Qwen3-30B-A3B-abliterated (~459.000), huihui-ai/Huihui-DeepSeek-V4-Flash-abliterated-ds4-GGUF (~310.000). Gemma, Qwen, DeepSeek: gli stessi tre nomi che aprono i cataloghi enterprise dei modelli a pesi aperti. Fra gli aggiornamenti delle ultime ore, il 2 agosto, compaiono già varianti «Abliterated» e «HERETIC» di DeepSeek V4 Flash — l’ultimo checkpoint della famiglia, datato «0731» nel nome dei repository.
Dietro una parte consistente del volume c’è un solo account: huihui-ai, che si descrive come dedicato «to the study of model ablations» e conta 230 modelli pubblicati, 9.593 iscritti e un ultimo aggiornamento a poche ore dal controllo. Non un episodio isolato: una produzione ricorrente, quasi industriale, applicata a ogni rilascio rilevante entro poche ore o giorni dall’uscita.
Quello che le schede dichiarano
Le abbiamo lette, non solo contate. mlabonne/Qwen3-30B-A3B-abliterated — uno degli autori più citati del filone — avverte in apertura: «This model is still W.I.P. and I do not recommend using it at the moment». wangzhang/gemma-4-31B-it-abliterated è insolitamente rigoroso: dichiara il metodo («direct weight editing: norm-preserving orthogonal projection applied to the base model weights»), misura il tasso di rifiuto prima e dopo — da 99 su 100 prompt a 7 su 100 — e aggiunge un avvertimento che vale per l’intero filone: «most abliteration benchmarks dramatically undercount refusals», perché generano troppi pochi token per lasciare emergere un rifiuto tardivo; invita perciò a «treat these numbers with skepticism». In chiusura, un disclaimer netto: «released for research purposes only […] may reduce safety guardrails». La scheda di huihui-ai/Huihui-DeepSeek-V4-Flash-abliterated-ds4-GGUF è ancora più esplicita: «this model’s safety filtering has been significantly reduced»; raccomanda l’uso solo «for research, testing, or controlled environments, avoiding direct use in production»; chiude scaricando ogni responsabilità («huihui.ai bears no responsibility for any consequences arising from its use»). Una scheda che cita il framework automatizzato «Heretic» accredita, correttamente, il suo autore, Philipp Emanuel Weidmann — e avverte: «this model is completely unaligned. It will output text without filtering, judgment, or warning labels».
Nome uguale, non lo stesso modello
wangzhang/gemma-4-31B-it-abliterated e paperscarecrow/Gemma-4-31B-it-abliterated condividono la stessa base — google/gemma-4-31B-it — quasi lo stesso nome, e insieme centinaia di migliaia di download. Sono due lavori distinti, di due autori diversi, con pipeline e dataset di valutazione differenti: non lo stesso file con un’altra etichetta, due abliterazioni indipendenti che si presentano al lettore in modo indistinguibile finché non si apre la scheda. La stessa cosa succede su Qwen3.6-35B-A3B: la versione di Bahushruth dichiara zero rifiuti su un proprio insieme di appena 16 prompt; quella di huihui-ai, riquantizzata poi da terzi, è una lineage separata. E anche dentro lo stesso percorso di repository l’identità non è garantita nel tempo: la scheda di una quantizzazione FP8 dello stesso Qwen segnala che le versioni caricate prima del 3 maggio 2026 avevano «broken vision input» per un errore di mappatura dei tensori, corretto con una sostituzione dei file sullo stesso nome di repository, senza cambio di versione visibile all’esterno — «text-only output is unaffected», nota la scheda, ma proprio quella frase dice che il nome del repository, da solo, non fissa che cosa gira davvero: serve la revisione esatta.
Il metodo originale, citato una volta sola
La tecnica prende il nome da un lavoro pubblico del giugno 2024: Andy Arditi, Oscar Obeso, Aaquib Syed, Daniel Paleka, Nina Panickssery, Wes Gurnee e Neel Nanda, «Refusal in Language Models Is Mediated by a Single Direction» (arXiv:2406.11717, poi NeurIPS 2024), mostrano che il comportamento di rifiuto in tredici modelli di chat aperti è mediato da un sottospazio a una dimensione. È lo stesso lavoro che l’autore che ha coniato il termine «abliteration», nel suo post di presentazione del 13 giugno 2024, cita esplicitamente come origine del metodo. Non serve altro, qui, se non sapere che la fonte esiste, è verificabile e precede di due anni la produzione di massa che ne è seguita.
Il collegamento con ieri
Il rapporto CAISI su GLM-5.2 misura le protezioni di un modello base, con licenza MIT, così come il fornitore lo distribuisce: tengono quasi sempre in chat, cedono a zero su dieci in configurazione agentica. Il rapporto Unit 42 su un attacco condotto con DeepSeek mostra un attore che sceglie deliberatamente «the most permissive model» perché lo strato di sicurezza dei fornitori occidentali gli oppone resistenza. Entrambi i pezzi arrivano alla stessa conclusione: lo strato di sicurezza sta nella pila che si assembla, non nei pesi originali. Questo pezzo aggiunge il passo che li precede entrambi. Se il rifiuto si può individuare come una direzione nei pesi e togliere chirurgicamente, e il risultato si ridistribuisce con un nome che allude all’originale, allora una valutazione — CAISI, un rapporto tecnico, la licenza del fornitore — riferita al modello base non dice nulla su ciò che gira davvero se sulla vostra macchina è installato un derivato con un nome simile.
Non è un’accusa ai pesi aperti
Di continuità dei pesi quando cambia la policy abbiamo già scritto, e di quello che un rapporto tecnico dichiara e tace pure: qui il problema viene prima di entrambi. Non è se i pesi restino disponibili, non è cosa manchi in un documento — è se il file che avete installato sia proprio quello di cui il documento parla. La conclusione onesta non è che i pesi aperti siano pericolosi: sarebbe falso, e smentito dagli stessi numeri di oggi, dove decine di migliaia di organizzazioni scaricano ogni giorno modelli aperti per usarli esattamente come dichiarato. La conclusione è che la verifica di provenienza — impronta crittografica di ogni file, riferimento esatto della revisione, tokenizzatore, template di conversazione, testo della licenza al giorno del download — smette di essere un formalismo quando esistono migliaia di derivati che si chiamano quasi come l’originale. Chi assembla la pila risponde di ciò che assembla: un file scaricato «perché aveva il nome giusto» non è il modello valutato da nessuno. E vale anche al contrario, ed è la parte onesta: la stessa modificabilità che permette di togliere il rifiuto da un checkpoint è ciò che permette a un’organizzazione seria di adattare un modello al proprio dominio — e di verificarlo, invece di fidarsi di una scatola chiusa il cui fornitore non risponde a nessuna domanda.
Come lo risolviamo noi
La verifica di provenienza, per come la mettiamo in pratica, non è un controllo che si fa una volta e si archivia: gira come processo automatico prima che un modello entri in esercizio — hash, revisione, licenza, comportamento di rifiuto misurato sul file reale, non sul nome del repository — e a cadenza dopo, con la traccia pronta da esibire a un’ispezione. Lo stesso impianto che verifica tiene insieme i dati sparsi dell’organizzazione — archivi, gestionali, sensori, documenti — in un modello operativo unico su cui agenti AI eseguono decisioni con un operatore al comando: per grandi imprese, difesa, pubblica amministrazione e sanità, dove un derivato non tracciato non è un fastidio tecnico ma un rischio che nessun capitolato può ignorare. Lo facciamo in entrambe le modalità di consegna — on-premise, su macchine autonome che non richiedono un’integrazione profonda nella rete del cliente, oppure cloud dedicato con data center in Italia — con la gestione tenuta insieme a voi: non dovete già avere in casa chi amministra questi sistemi.
Avete modelli a pesi aperti in esercizio e nessuno che ne verifichi la provenienza prima dell’uso? Mezz’ora con un nostro esperto: controlliamo hash, revisione e licenza di ciò che gira oggi sulle vostre macchine.