La denuncia è di quelle che tolgono il fiato. Un patrigno, utilizzando una sola foto della figliastra undicenne, ha generato con Grok — il modello di xAI integrato in X — 7.000 immagini sessualmente esplicite, inclusi contenuti di incesto e stupro. L’uomo si è tolto la vita dopo che le forze dell’ordine hanno scoperto il materiale. Ma il dettaglio più agghiacciante, finito in una class action allargata martedì, è un altro: il sistema di sicurezza di xAI non ha bloccato nulla per tutto il tempo, fino a quando l’utente non ha digitato “stupro di gruppo”. Solo quel prompt ha fatto scattare un CyberTip verso il National Center for Missing and Exploited Children (NCMEC), allertando la polizia.

Non è un semplice incidente di moderazione. È la fotografia di un’architettura di sicurezza che arriva sempre in ritardo, aggrappata a schemi di rilevamento sorprendentemente ingenui. Per migliaia di generazioni, Grok ha prodotto output tossici senza che alcun meccanismo — né a livello di prompt, né di analisi semantica dell’immagine generata — fermasse la pipeline. E questo mentre la cronaca recente è piena di casi analoghi con altri modelli, segno che il problema non è isolato ma strutturale.

La trappola del guardrail a valle

La stragrande maggioranza dei filtri nei Large Language Models opera come un cane da guardia che controlla solo la porta d’ingresso. Esamina il prompt, magari lo classifica con un modello più piccolo, e decide se lasciar passare la richiesta. Un approccio che funziona finché il linguaggio è esplicito. Ma quando il testo è ambiguo, o quando la pericolosità sta nell’immagine sintetizzata e non nelle parole, il sistema si rivela cieco. In questo caso, migliaia di immagini pedopornografiche sono state prodotte senza che il prompt contenesse parole chiave allarmanti. xAI è intervenuta solo di fronte a una combinazione testuale che il suo classificatore ha riconosciuto come palese.

Questo schema — guardrail reattivo anziché strutturale — è diffuso in molti fornitori di API LLM, in parte perché la scansione delle immagini generate richiede risorse computazionali aggiuntive e introduce latenza. Ma il costo dell’assenza è evidente: responsabilità legale, danni reputazionali, e in questo caso una tragedia umana.

Cosa cambia per chi valuta il deployment on-premise

La vicenda tocca un nervo scoperto per chi progetta infrastrutture locali di inference. In un contesto on-premise o self-hosted, l’organizzazione ha il controllo completo della pipeline: può decidere di attivare la registrazione di tutti i prompt e di tutti gli output, applicare scanner di immagini sul flusso di generazione (magari modelli di rilevamento CSAM già addestrati), e persino imporre audit umani periodici su campioni casuali. In altre parole, può costruire una gabbia di sicurezza che manca nell’offerta standardizzata dei modelli via API. Ma questo controllo ha un prezzo: complessità ingegneristica, consumo di risorse (GPU aggiuntive per i modelli di scanning, storage per i log), e un carico di responsabilità diretta se il sistema dovesse fallire.

Al contrario, affidarsi a un modello cloud come Grok sposta la responsabilità formale sul fornitore, ma come mostra il caso xAI, quella delega può essere fragile. La class action non colpisce solo xAI e X per la generazione di materiale illecito, ma anche per aver ostacolato le indagini. Un’azienda che usa API di terze parti senza strati di controllo aggiuntivi potrebbe trovarsi invischiata in analoghe vertenze, qualora il sistema del fornitore risultasse insufficiente.

Dietro la scelta tra cloud e on-premise, quindi, non ci sono soltanto TCO, latenza e sovranità dei dati. C’è una partita sulla sicurezza percepita e reale, che questa sentenza contribuirà a ridefinire. Chi fa self-hosting — e se ne assume l’onere — può dimostrare di aver adottato misure proattive, potenzialmente limitando la propria esposizione legale. Chi compra API deve fare i conti con la trasparenza e l’efficacia dei sistemi di moderazione del fornitore, oggi più che mai sotto accusa.