La scorsa settimana, chi provava a decomputare il firmware di una smart TV con Claude Code non si è imbattuto in un errore di compilazione, ma in un controllo di sicurezza. Poco dopo, un utente X raccontava di aver visto il proprio account OpenAI sospeso per aver usato Codex su televisori Samsung. In pochi giorni il progetto Reverse Engineer Anything, celebrato per dare nuova vita a dispositivi abbandonati, si è ritrovato nel mirino delle policy delle grandi piattaforme.

Il punto non è la singola decisione di moderazione. Tarun Gogineni, ingegnere di OpenAI, ha scritto che i blocchi sono in gran parte incidentali e che non esiste un divieto di reverse engineering con Codex. Ma anche se la spiegazione tecnica è credibile, il danno strutturale è già visibile: quando un account può essere limitato per un uso legittimo su hardware di proprietà, l'intero flusso di lavoro diventa fragile. Gli utenti non possono dipendere da un'API cloud per interagire con dispositivi che hanno in casa, soprattutto se il provider considera la decompilazione un caso limite di 'cyber abuse'.

La vicenda segnala un'asimmetria più profonda. Le grandi aziende AI hanno costruito i loro LLM anche su contenuti raccolti su larga scala; ma quando le stesse capacità vengono usate da un singolo per rimuovere gli annunci da una TV o ripristinare un dispositivo IoT abbandonato, scattano guardrail che proteggono, di fatto, i vincoli commerciali dei produttori hardware. Non serve attribuire un'intenzione esplicita: basta osservare che il costo di un falso positivo è scaricato sull'utente, mentre il costo di un falso negativo in termini reputazionali o legali ricade sul provider. La conseguenza è un ambiente in cui il reverse engineering assistito diventa tollerato finché non tocca territori commerciali sensibili.

Il secondo ordine di conseguenze riguarda il deployment. Se i modelli in cloud diventano inaffidabili per questo tipo di lavoro, la via d'uscita è spostare l'inference su modelli aperti eseguiti in locale. Qui però il problema non sparisce: cambia forma. Un modello open-weight non può bloccare l'account, ma richiede hardware, VRAM e una pipeline di esecuzione che molti utenti consumer non hanno. La stessa opera di liberazione di un baby monitor o di un vecchio set-top box, prima possibile con poche chiamate API, diventa un problema di self-hosted inference, quantization e gestione dei runtime. È un passaggio che migliora il controllo, ma alza la soglia di competenza e il TCO. Per chi valuta il deployment on-premise, i trade-off non sono solo economici o di privacy: riguardano anche la disponibilità di modelli che non applichino policy remote, un tema su cui AI-RADAR mette a disposizione framework analitici.

Il terzo ordine è meno intuitivo. Questa storia mostra che la censura non è un attributo del modello, ma del livello di servizio. Lo stesso LLM può essere permissivo in locale e restrittivo via API. Le aziende che devono decidere se affidarsi a un'API o a un'infrastruttura propria dovrebbero leggere la vicenda come un segnale: quando il confine tra uso consentito e abuso diventa 'difficile da tracciare', la continuità operativa dipende da chi controlla il deployment. Non è una questione ideologica, ma di responsabilità e di incentivi.

Il progetto Decomp.wtf ha chiuso, alcuni utenti migrano già verso alternative locali. La correzione annunciata da OpenAI potrà riaprire qualche account, ma difficilmente riporterà indietro la consapevolezza che un'API cloud può interrompere, in un attimo, un progetto personale su dispositivi di proprietà. Il reverse engineering assistito non muore: si sposta dove il provider non può premere il pulsante.