xAI ha scelto la via giudiziaria per contenere i danni dopo settimane di pressioni su Grok. Martedì l’azienda di Elon Musk ha presentato una denuncia contro Terry Wayne Harwood, arrestato in precedenza con l’accusa di detenzione e distribuzione di materiale pedopornografico. Secondo quanto ricostruito dal procuratore della Carolina del Sud, l’indagato avrebbe utilizzato due account xAI per «svestire» immagini non sessuali di più vittime, fra cui una bambina di appena dieci anni. xAI rivendica di aver collaborato all’indagine, scoprendo l’abuso dopo mesi di attività. Ma la causa non affronta la radice tecnica: Grok può ancora produrre immagini sessualizzate di adulti e minori senza consenso.

L’azione legale è un classico tentativo di circoscrivere il problema spostandone la responsabilità sull’utente finale. Da un punto di vista comunicativo, dire «noi denunciamo chi fa un uso illegale del nostro strumento» ha un indubbio valore tattico: segnala cooperazione con le forze dell’ordine e allontana l’etichetta di piattaforma complice. Tuttavia, sul piano ingegneristico, la capacità del modello di generare immagini pedopornografiche persiste, perché il sistema non è stato privato di quella competenza. Non si tratta di un prompt elaborato che scavalca un filtro ben progettato: è la mancata rimozione in fase di training o di allineamento della rappresentazione interna che trasforma foto in nudi. In altri termini, il modello contiene quella conoscenza e la API la serve.

Cosa significa per chi gestisce LLM in proprio

L’intera vicenda assume contorni diversi quando la si guarda con gli occhi di chi schiera modelli on-premise. Qui il tema non è soltanto la tutela dei minori, ma la sovranità sul rischio. Un’organizzazione che usa Grok via API sa di non avere alcun controllo sull’output: può solo fidarsi delle dichiarazioni pubbliche di xAI e sperare che un domani non venga accusata di aver veicolato contenuti illegali creati dal chatbot. Invece, chi esegue un LLM su infrastruttura propria ha la possibilità – e l’onere – di intervenire prima del deployment: rimuovere la capacità nociva con tecniche di fine-tuning avversariale, integrare guard-model che bloccano l’output indecente, regolare la temperatura e le policy di sistema a un livello più profondo di quanto consentano le interfacce cloud. È una posizione di forza che però richiede risorse hardware adeguate e competenze di alignment che non si improvvisano.

Il paradosso è che la denuncia di xAI, mentre tenta di proteggere l’azienda, rende più fragile l’intero ecosistema cloud. Dimostra che il provider può – e in certi casi deve – individuare l’utente e collaborare con le autorità. Significa che i log di ogni richiesta, compresi quelli apparentemente innocui di una enterprise che usa l’API per business leciti, finiscono sotto scrutinio quando scatta un’indagine. Per chi ha vincoli di dati (sanità, pubblica amministrazione, finanza) questo introduce un ulteriore elemento di diffidenza verso soluzioni che non consentono di tenere inference e telemetria all’interno del proprio perimetro.

Chi vince e chi perde

A beneficiare della linea difensiva di xAI sono innanzitutto i grandi fornitori cloud di LLM, che possono replicare lo schema: processare l’utente malfattore e dichiarare tolleranza zero senza investire nella bonifica del modello. A perderci sono le piccole organizzazioni che non hanno la massa critica per fare self-hosting e restano esposte a un doppio pericolo: un modello che può generare output illegale e un provider che, se succede, ti consegna senza esitazione. In mezzo c’è l’industria on-premise, che vede crescere la domanda di soluzioni «sterilizzate» e verificabili, dove la safety non è un incantesimo legale ma una caratteristica ingegneristica misurabile. Non è un caso che progetti come il alignment via RLHF o i refusal vector vengano aggiunti a pipeline locali, spesso su GPU consumer, da sviluppatori ben prima che i vendor li integrino nelle release pubbliche.

La questione di fondo, che la causa xAI non potrà mai risolvere, è che un ecosistema sano ha bisogno di modelli che non sappiano nudificare. Finché il know-how su come epurare quelle capacità resta appannaggio del singolo laboratorio, la sicurezza sarà sempre una rincorsa e i tribunali faranno da surrogato alla tecnica. Per chi oggi progetta infrastrutture di inference aziendale, la lezione è immediata: la domanda da porsi non è «cosa promette il vendor», ma «posso disabilitare io stesso il comportamento indesiderato». E la risposta spesso dipende da quanta VRAM si ha a disposizione e da quanto controllo si pretende sul ciclo di vita del modello.