La collisione del vocabolario: quando un classificatore di sicurezza blocca l'intero dominio

Un classificatore di sicurezza generico si basa su un'assunzione nascosta: che parlare di attaccanti, exploit e riciclaggio di denaro sia raro e sospetto. Applicare questo modello a un prodotto di sicurezza e compliance inverte questa assunzione. In un arco di produzione di 17 giorni conclusosi il 10 aprile 2026, l'alias mistral-moderation-latest di Mistral (che in quel momento risolveva nel modello mistral-moderation-2603) ha segnalato 15 messaggi nella nostra applicazione come dannosi. Tutti erano falsi positivi. La precisione era zero. Non degradata, non rumorosa: zero su quindici.

Si tratta di un risultato specifico e misurato sul nostro traffico, che evidenzia una modalità di fallimento invisibile finché non si leggono le segnalazioni una per una. La chiamiamo collisione del vocabolario: in un dominio specialistico, il vocabolario di pericolo del classificatore coincide con il vocabolario operativo del dominio, quindi il segnale che dovrebbe essere raro diventa la norma.

Le segnalazioni

Delle 15 segnalazioni, 14 sono ricadute nella categoria dangerous_and_criminal_content e 1 in violence_and_threats. Leggendole, il pattern è stato immediato. Erano tutte discussioni legittime di GRC (Governance, Risk & Compliance):

• Reverse engineering dei servizi di un provider cloud, nel contesto degli obblighi di proprietà intellettuale. La norma ISO/IEC 27001:2022 Annex A control A.5.32 è letteralmente "Diritti di proprietà intellettuale"; un utente che lavora su questo controllo deve parlare di reverse engineering per ragionare su di esso.
• Valutazione del rischio scritta in spagnolo, dove "amenazas" (minacce) è la parola ordinaria per ciò che ogni registro dei rischi enumera.
• Attività di antiriciclaggio, dove "blanqueo" (riciclaggio di denaro) è l'argomento, non una confessione.
• Esperienze di red teaming e penetration testing.
• DAST, scansione dinamica di un'applicazione per vulnerabilità.

Niente di tutto questo è contenuto criminale. È il vocabolario quotidiano di professionisti della sicurezza informatica, ufficiali di compliance e auditor. Il classificatore non è difettoso. Sul traffico web generale, un messaggio che parla di reverse engineering dei sistemi di un vendor è un segnale debole di pericolo plausibile, e un classificatore generico è progettato per trattarlo come tale. I nostri utenti sono la popolazione per cui lo stesso segnale ha un significato opposto. Ci si aspetterebbe questa modalità di fallimento da qualsiasi classificatore generico usato allo stesso modo, perché deriva dal framing generico piuttosto che da un'implementazione specifica di un vendor. L'errore è stato nostro: abbiamo trattato una priorità generale come se fosse consapevole del dominio.

Il sovrablocco non è una soluzione sicura

Il riflesso è trattare i falsi positivi come il lato innocuo del trade-off precisione-richiamo. Perdere una minaccia reale significa avere un buco di sicurezza; sovra-segnalare significa, nel peggiore dei casi, solo un po' di rumore. In produzione, però, il rumore aveva dei denti, ed è importante essere concreti sui costi di secondo livello, perché è lì che si trovava il vero danno:

1. L'affaticamento da allerta ha neutralizzato la rete. Ogni evento confermato inviava una email alla nostra casella di sicurezza. Quindici falsi allarmi consecutivi hanno addestrato il team a ignorare le segnalazioni di moderazione. Una rete di sicurezza che tutti hanno imparato a ignorare non è una rete di sicurezza.
2. Un problema di diritto all'oblio. Le discussioni segnalate venivano bloccate contro la cancellazione, in modo che le prove non potessero essere distrutte. Questo è ragionevole per abusi reali. Applicato a un falso positivo, significava che un utente non poteva cancellare la propria conversazione di compliance, creando un rischio per il GDPR Articolo 17 (diritto all'oblio). Questo diritto, soggetto alle proprie condizioni ed eccezioni, copre la cancellazione selettiva, non solo la chiusura di un account.
3. Un'etichettatura errata che non potevamo sostenere. Messaggi benigni degli utenti si trovavano in un archivio la cui semantica era "contenuto pericoloso e criminale". Si tratta di un'affermazione su una persona che non potevamo supportare.

La metrica che ci stava danneggiando era la precisione, non il richiamo, e il suo fallimento non era cosmetico.

Perché le soluzioni ovvie non funzionano

Due soluzioni sembrano ovvie e entrambe sono sbagliate.

Regolare il classificatore. Non è possibile. L'endpoint di moderazione è un classificatore fisso. La sua API accetta un identificatore di modello e una stringa di input e restituisce i punteggi delle categorie. Non esiste un system prompt, un campo di istruzioni, nessun modo per dirgli "questo è un prodotto di compliance". Un classificatore fisso vi offre un controllo senza numeri.

Eliminare le categorie rumorose. Disabilitare dangerous_and_criminal_content e violence_and_threats eliminerebbe tutti i falsi positivi che abbiamo visto. Eliminerebbe anche le uniche categorie sotto cui una minaccia reale nel nostro dominio potrebbe mai emergere. Non si tratta di calibrazione, ma di spegnere la rete e chiamare il silenzio un successo.

La soluzione in due fasi

Manteniamo il classificatore rapido come prima fase; viene eseguito su ogni messaggio. Quando segnala qualcosa, passiamo il messaggio a un giudice di seconda fase: un piccolo modello di chat (Mistral Small) con un system prompt che descrive gli argomenti legittimi di sicurezza informatica e compliance che i nostri utenti discutono effettivamente. Il giudice restituisce uno di due verdetti: CONFERMATO o FALSO_POSITIVO.

Solo gli eventi CONFERMATI vengono instradati verso il percorso di allerta e blocco. Gli eventi FALSO_POSITIVO vanno in un archivio separato e soppresso, conservato per audit e rilevamento di derive ma con zero conseguenze visibili agli utenti: nessuna email, nessun blocco della cancellazione, nessuna etichetta criminale. Il giudice viene attivato su circa un messaggio segnalato al giorno, quindi il costo aggiuntivo è trascurabile. E fallisce in modo sicuro: se il giudice commette un errore, va in timeout o restituisce qualsiasi cosa che non sia un verdetto pulito, il messaggio viene trattato come CONFERMATO. Il caso peggiore è la vecchia baseline rumorosa, mai una minaccia silenziosamente ignorata.

Distribuita il 10 aprile 2026, questa soluzione ha portato il nostro tasso di falsi positivi su quelle segnalazioni da 15 su 15 a zero, senza disabilitare alcuna categoria.

L'intoppo: abbiamo spostato il rischio, non l'abbiamo eliminato

Ecco la parte da portare a casa, perché si generalizza oltre la moderazione. Aggiungere una fase di giudizio più indulgente non elimina il rischio. Lo sposta, da un fallimento visibile a uno invisibile.

Prima, la modalità di fallimento era il sovrablocco, ed era rumorosa: ogni falso positivo faceva suonare l'allarme. Dopo, la modalità di fallimento dominante è il giudice che è troppo indulgente e lascia passare silenziosamente qualcosa che avrebbe dovuto confermare. Questo fallimento è silenzioso per costruzione. Scrive su un archivio di cui nessuno riceve email.

Abbiamo avuto una dimostrazione dal vivo di quanto disorientante possa essere il regime silenzioso. Il 14 aprile 2026, quattro giorni dopo la soluzione, le email di allerta della moderazione sono cessate completamente. Dall'esterno, un improvviso zero è indistinguibile da un pipeline rotto: il classificatore che fallisce in modo aperto, un guasto, un trigger perso. È stato necessario leggere i dati sottostanti per distinguere "sano e silenzioso" da "oscurato silenziosamente". Una volta ottenuto l'accesso in lettura all'archivio soppresso, abbiamo revisionato ogni verdetto di Mistral Small accumulato dall'implementazione del 10 aprile 2026: 40 righe soppresse, e dalla nostra lettura nessuna era una minaccia reale erroneamente respinta. Il percorso confermato si è allineato esattamente nello stesso periodo, 23 eventi confermati contro 23 email di allerta. La rete era intatta. Ma l'unico modo per saperlo era revisionare ciò che era diventato silenzioso.

Quindi anche la seconda fase necessita della sua valutazione, secondo il proprio calendario. L'archivio soppresso viene ora controllato mensilmente per rilevare un'eccessiva indulgenza del giudice, e un conteggio quotidiano economico sulla tabella confermata monitora il pipeline che diventa oscuro. La lezione non è "aggiungi un giudice LLM". È: quando si sistema un fallimento visibile con un componente più silenzioso, si deve prevedere l'audit del silenzio, altrimenti si è scambiato un problema misurabile con uno che non lo è.

Una checklist portatile

Se state eseguendo un classificatore generico su un corpus specialistico — medico, legale, di sicurezza, finanziario o di compliance — prima di fidarvi del suo output:

• Controllate per una collisione del vocabolario. Elencate il vocabolario operativo normale del vostro dominio. Se quelle parole si sovrappongono alle categorie di pericolo del classificatore, la sua precisione sul vostro traffico è una domanda aperta, non un'assunzione. Misuratela.
• Leggete le segnalazioni, non limitatevi a contarle. Un numero di precisione nasconde il pattern; i singoli falsi positivi lo rivelano. Quindici segnalazioni non ci hanno detto nulla finché non ne abbiamo lette quindici.
• Valutate onestamente il sovrablocco. Tracciate cosa scatena un falso positivo a valle. Affaticamento da allerta, un blocco della cancellazione che entra in conflitto con un diritto di oblio legale, un'etichetta che non potete sostenere. Il sovrablocco raramente è gratuito.
• Se il classificatore è fisso, avvolgetelo, non combattetelo. Quando non potete istruire il modello, aggiungete una fase consapevole del dominio intorno ad esso piuttosto che disabilitare intere categorie.
• Fallite in modo sicuro sul wrapper. Un errore del giudice deve essere elevato, mai soppresso, quindi un guasto del wrapper non può aprire silenziosamente la rete.
• Date al componente silenzioso il suo audit. Qualsiasi componente che sopprime silenziosamente necessita di una revisione programmata di ciò che ha soppresso, oltre a un controllo di vitalità che distingua "sano e silenzioso" da "oscurato".

Limiti

Questo è un prodotto, un dominio e un campione piccoli: 15 segnalazioni in un singolo arco di 17 giorni conclusosi il 10 aprile 2026, più 40 righe soppresse nelle settimane successive. È un risultato puntuale sull'alias mistral-moderation-latest come risolveva in quel periodo, presentato come nostra misurazione sul nostro traffico. Non è una rivendicazione generale sulla qualità di quel classificatore al di fuori del nostro dominio. Il tasso di errore del giudice stesso è limitato dal fallback sicuro, ma non è zero, ed è esattamente per questo che viene revisionato piuttosto che fidandosi ciecamente. Ciò in cui siamo fiduciosi è il meccanismo: quando il vocabolario del pericolo e il vocabolario del dominio sono le stesse parole, la precisione di un classificatore generico è una misurazione che si deve fare, non una proprietà che si può assumere.