Tag: open source AI

AI & GENAI

Il watermark di Claude e il tool open source che lo smonta

Dal 2 agosto 2026 i nuovi modelli Claude lanciati nell’Unione Europea nascono con un watermark incorporato nel testo che generano, e, dove il formato lo consente, con metadati di provenienza firmati secondo lo standard C2PA. È l’attuazione pratica dell’articolo 50(2) del Codice di condotta europeo sull’AI Act, che Anthropic ha firmato insieme ad altri fornitori di modelli generativi: il funzionamento è descritto nella scheda ufficiale sul marking pubblicata dall’azienda.

La rete, come sempre, ha reagito più in fretta della norma. Su LinkedIn circola uno screenshot con toni da comunicato: non sarebbero passate nemmeno ventiquattr’ore da quando è comparsa una skill capace di ripulire i testi da Claude, Gemini e OpenAI, mille stelle su GitHub in un giorno, cento per cento open source. Il progetto si chiama watermarks-remover, ed è il banco di prova giusto per capire quanto valga davvero, oggi, marcare un contenuto generato da intelligenza artificiale.

Due firme, non una

Il watermark di Anthropic si scompone in due meccanismi distinti, e la distinzione conta perché determina anche dove un tool avversario può colpire. Il primo vive dentro il testo stesso: un segnale statistico intessuto nella scelta dei token, invisibile a occhio nudo, che sopravvive al copia e incolla e in parte anche alle modifiche successive. Il secondo vive nei file: metadati C2PA firmati, applicati a formati come SVG, PNG e JPG, pensati per segnalare se un contenuto è stato processato da Claude e se è stato manomesso dopo.

Anthropic stessa, nella sua scheda di trasparenza, elenca i limiti di entrambi i canali con una franchezza che raramente si vede nella comunicazione di prodotto. Un segnale rilevato non prova la paternità intera del contenuto, perché Claude può aver semplicemente tradotto, riassunto o corretto un testo altrui. E l’assenza del segnale non prova il contrario, perché basta un modello precedente all’agosto 2026, una riscrittura pesante, un passaggio troppo corto o una conversione di formato per far sparire la traccia. È dentro questo margine dichiarato, non contro di esso, che si è mosso chi ha scritto watermarks-remover.

Watermark scomposto in tre livelli

Il repository di Guillaume Meyer, con licenza MIT e oltre trecento fork, separa il problema in tre pezzi con garanzie molto diverse tra loro, e qui la differenza tra teoria e pratica diventa concreta. Il primo livello ripulisce i caratteri Unicode invisibili, spazi esotici, marcatori bidirezionali, tag nascosti che alcuni schemi di marcatura usano come vettore. È un’operazione deterministica, verificabile riga per riga, e non tocca una sola parola del testo visibile: puliscono un file di testo o un Markdown senza alterarne il significato.

Il secondo livello attacca invece i watermark statistici, quelli intessuti nella probabilità con cui un modello sceglie un token piuttosto che un altro, come SynthID-Text di Google o gli schemi in stile Kirchenbauer. Qui non esiste scorciatoia: il segnale è distribuito su quasi ogni frase, quindi rimuoverlo richiede una riscrittura pesante, frase per frase, non un rimescolamento di paragrafi. Gli stessi autori del progetto lo scrivono senza infingimenti nel proprio README, ponendo una domanda che è quasi un autogol dichiarato: se il piano è comunque riscrivere il testo con un modello più economico, che senso ha aver pagato prima un modello premium? La riscrittura degrada tono, voce, precisione, e il risultato non può superare il livello del modello usato per riscrivere.

Il terzo livello ripulisce infine i metadati dei file, dalle proprietà nascoste di un DOCX ai chunk EXIF e XMP di un PNG, passando per PDF, SVG, ODT, HTML. Qui però la matrice di copertura pubblicata dal progetto stesso ammette due buchi precisi: la rimozione dei watermark incorporati nei pixel resta fuori portata, e il cosiddetto soft binding C2PA, quel legame che può ricollegare un file a un manifest remoto anche dopo aver ripulito i metadati locali, non viene toccato. Per la marcatura pixel di SynthID esiste solo uno strumento esterno, non incluso nel pacchetto, che ne misura la probabilità di presenza: la rileva, non la cancella.

Il limite che la letteratura conosce da prima

Lo screenshot che circola su LinkedIn parla di “segnali statistici SynthID” gestiti dallo strumento, ed è vero solo a metà: vale per la variante testuale dello schema, descritta da Dathathri e colleghi su Nature nel 2024, non per l’uso più noto di SynthID sulle immagini, dove restare invisibile al watermark resta un’altra storia. La stessa distanza tra rivendicazione social e comportamento reale del codice vale per la cornice temporale: la cronologia delle release, da v0.0.1 a v0.3.2, mostra un lavoro incrementale fatto di hardening della sicurezza, scritture atomiche sui file, limiti di risorse, pipeline CI con firma delle dipendenze. Non è il weekend hack che il post lascia intendere, ed è forse anche per questo che le stelle su GitHub, oggi che scrivo, hanno superato quota tremila: non un picco isolato, un interesse strutturale.

C’è poi un piano più teorico che il caso pratico rende visibile. Zhang e colleghi, in un lavoro presentato all’ICML del 2024, avevano già dimostrato che nessuno schema di watermarking robusto può resistere a un avversario sufficientemente motivato senza pagare un prezzo inaccettabile in termini di qualità del testo. Il costo che gli autori di watermarks-remover ammettono candidamente, quello della riscrittura che impoverisce la prosa, non è un dettaglio implementativo: è la conferma pratica di un risultato che la ricerca aveva già scritto sulla carta, prima ancora che qualcuno lo trasformasse in un tool con trecento fork.

Ne avevo scritto, da un’angolatura diversa, quando affrontavo il tema della realtà sintetica e di quanto sia diventato fragile il confine tra ciò che vediamo e ciò che è stato costruito: lì il problema riguardava le immagini e i deepfake, qui riguarda il testo, ma la domanda di fondo resta identica, chi decide cosa merita fiducia.

L’etica del progetto, dichiarata esplicitamente dagli stessi autori, parla di uso legittimo per la privacy e l’igiene dei propri contenuti, non di frode accademica né di false dichiarazioni di autorialità umana. È una precisazione onesta, ma resta scritta in un file di testo dentro un repository con licenza MIT, dove nessuno controlla davvero chi la legge prima di usare lo strumento. È esattamente qui, nello spazio tra l’intenzione dichiarata e l’uso reale, che la governance deve costruire le proprie fondamenta, non nel codice ma nelle norme, nelle abitudini professionali, nella cultura di chi tratta un contenuto generato come parte di una filiera che merita verifica, non come un dato acquisito.

La trasparenza non vincerà perché un singolo watermark resiste a ogni tentativo di rimozione, quella battaglia l’aveva già persa la ricerca prima ancora che iniziasse. Vincerà se costruiamo un ecosistema di segnali sovrapposti, testo e metadati e strumenti di verifica esterni come l’interfaccia di mediazione tra chi produce e chi legittima un contenuto, capace di alzare il costo della cancellazione anche quando la cancellazione resta tecnicamente possibile. È un lavoro di infrastruttura più che di crittografia, e su questo lavoro vale la pena investire.

Fonti: How Claude marks AI-generated content (Anthropic); watermarks-remover di Guillaume Meyer su GitHub.

AI & GENAI, TECH & BUSINESS

Baseten a 13 miliardi e il paradosso dell’inferenza a basso costo

Il 18 giugno il Wall Street Journal ha scritto che Baseten sta chiudendo un round da 1,5 miliardi di dollari, con una valutazione che arriva fino a 13. Quattro giorni dopo l’azienda lo ha confermato: Series F, guidato da Altimeter, Conviction e Spark Capital. A gennaio la stessa Baseten valeva 5 miliardi, a settembre 2025 ne valeva poco più di due. Sei volte tanto in nove mesi, per una società che non costruisce modelli e non vende intelligenza propria, ma si occupa di farli girare bene una volta che qualcun altro li ha addestrati.

Ecco quello che mi ha fermato, e non è la cifra. Il capitale si sta spostando dalla parte spettacolare dell’AI, l’addestramento dei modelli, a quella operativa, l’inferenza: il lavoro ripetitivo e poco fotogenico di rispondere, milioni di volte al giorno, a chi fa una domanda. La scommessa di Baseten è che lì, sul costo di quel lavoro, ci sia il margine. La domanda che mi porto dietro è un’altra: una valutazione da 13 miliardi su un’infrastruttura che vende risparmio è il segno che il mercato sta maturando, o l’ennesima curva troppo ripida di una corsa all’oro?

L’inferenza è il livello meno glamour dello stack

Nessuno apre una demo vantandosi della latenza. L’addestramento ha preso quasi tutta l’attenzione degli ultimi anni perché era spettacolare, cluster enormi, GPU introvabili, miliardi bruciati per tirare su un modello più grande del precedente. Poi il modello esce, arriva il primo cliente vero, e la bolletta comincia a contare. L’inferenza è quel momento lì, quando il modello smette di essere una promessa e deve produrre una risposta utile, in fretta, a un costo che regga. È lo strato in cui l’intelligenza tocca davvero la persona, ed è lo stesso strato in cui un’azienda scopre se i conti tornano. In Pelle Digitale ho provato a raccontare proprio questa frontiera, la pellicola sottile dove la tecnologia diventa esperienza per chi la usa. Baseten vive lì, prende modelli, spesso open source, e li serve su una rete multi-cloud che oggi processa più di un miliardo di chiamate al giorno, distribuite su 87 cluster e 18 cloud diversi.

Da 2,15 a 13 miliardi in nove mesi

La cadenza degli aumenti è da capogiro. Series D a settembre 2025, valutazione 2,15 miliardi. Series E a gennaio, 5 miliardi, con dentro anche Nvidia. A maggio si parlava già di un round vicino al miliardo a una pre-money di 11. A giugno il round si gonfia a 1,5 miliardi fino a 13. Il fatturato segue una traiettoria altrettanto verticale, dal run-rate annualizzato di circa 200 milioni a 600 nell’arco di un trimestre, una crescita che molti raccontano come ventiplicata anno su anno. Tra gli investitori storici ci sono Greylock, IVP, CapitalG e la stessa Nvidia, che a gennaio aveva messo 150 milioni. Resta che a 13 miliardi parliamo di un multiplo sui ricavi vicino a 22 volte, e un multiplo del genere racconta molto più le aspettative sul futuro che i conti di oggi.

Il prezzo per task conta più del prezzo per token

La tesi di chi mette i soldi è abbastanza diretta. I modelli open source sono diventati buoni abbastanza da rendere superfluo, per molti casi d’uso, pagare il sovrapprezzo di un modello proprietario. Alcuni clienti di Baseten, da Cursor a Mercor a OpenEvidence, dichiarano di spendere circa un terzo di quanto costerebbe loro un’API chiusa. Se quel dato regge, l’unità della competizione cambia: non è più il modello migliore a fare la differenza, è la capacità di consegnarlo veloce e a basso costo. Ne avevo scritto la settimana scorsa a proposito della guerra dei prezzi dell’AI certificata dal Wall Street Journal, dove i volumi corrono verso il basso costo mentre la spesa resta alla frontiera. Baseten è l’altra faccia di quella dinamica, il venditore di pale e picconi per chi non vuole restare incastrato dentro un solo fornitore. Together AI, Fireworks, Modal Labs giocano la stessa partita, e Fireworks starebbe trattando un round a 15 miliardi. Il fondatore Tuhin Srivastava la riassume così: se il cloud è stato la base della generazione precedente di grandi aziende tecnologiche, l’inferenza è la base della prossima. Intanto Baseten ha firmato un accordo di collaborazione con AWS e ha comprato Parsed, una startup di post-training, segno che vuole presidiare tutto il ciclo di vita del modello, non solo il momento della risposta.

Due prezzi nello stesso round

C’è un dettaglio nella struttura del round che dice più della cifra. È diviso in due fasce, alcuni investitori entrano a una valutazione di 11 miliardi, altri pagano 13. È un meccanismo diventato comune nei mega-round del 2026, serve a sbandierare il numero più alto tenendo dentro chi vuole un prezzo d’ingresso più cauto. Lo si può leggere in due modi. Come ingegneria finanziaria che gonfia il titolo, oppure come fotografia fedele di quanto sia diventato difficile mettere d’accordo investitori con appetiti di rischio diversi sullo stesso asset. Tra i nomi del round c’è Wellington Management, un gestore di lungo periodo, non esattamente la firma che ti aspetti quando si parla di schiuma speculativa. La sua presenza è la texture che complica la storia comoda della bolla. A 13 miliardi Baseten viene prezzata come un pezzo della macchina che i team di AI non possono permettersi di sbagliare, più che come un fornitore qualsiasi seduto tra i cloud e i modelli.

Una corsa all’oro è sempre una bolla?

Quindici anni fa scrivevo di un’altra ondata di valutazioni che sembravano slegate dai fondamentali, quella dei social network e delle prime startup mobile, e mi chiedevo se i numeri avessero senso. Molti di quei numeri non lo avevano, alcune di quelle aziende sono sparite, altre sono diventate l’infrastruttura su cui viviamo adesso. La storia della tecnologia raramente sceglie tra bolla e rivoluzione, di solito fa le due cose insieme, gonfia troppo e nello stesso movimento costruisce qualcosa che resta. L’inferenza ha però una caratteristica che la distingue dalla speculazione pura, assomiglia più a una bolletta che a una puntata, torna ogni volta che un utente fa una domanda, a prescindere dall’umore del mercato. Questo non mette al riparo Baseten dal rischio che gli iperscalari, Amazon su tutti, decidano di tirare l’inferenza dentro le proprie piattaforme e schiaccino i margini dello specialista. Spiega però perché un asset manager prudente sceglie di entrare adesso.

Il test vero arriva dopo, quando i soldi saranno atterrati e i clienti dovranno decidere, bolletta alla mano, se affidarsi a Baseten costa davvero meno che cavarsela da soli. A quel punto sapremo se quei 13 miliardi erano la misura di un’infrastruttura diventata essenziale o il prezzo di una puntata fatta nel momento più caldo del ciclo. Per adesso l’unica cosa certa è dove il mercato sta mettendo i soldi veri.

Fonti: TechCrunch, AI inference startup Baseten reportedly raising $1.5B; Baseten, Raises $1.5 Billion to Power the Next Era of AI Inference (comunicato ufficiale). Dati sul round riportati in origine dal Wall Street Journal.

AI & GENAI, TECH & BUSINESS

Sovranità dell’AI: quando un governo può spegnere un modello

Venerdì 12 giugno 2026, ore 17:21 a New York. Anthropic riceve una lettera dal governo degli Stati Uniti e nel giro di poche ore disattiva i suoi due modelli più potenti, Fable 5 e Mythos 5, per l’intera base clienti, ovunque nel mondo. La motivazione, dichiarata nel comunicato ufficiale dell’azienda, è un export control per ragioni di sicurezza nazionale che vieta l’accesso a qualunque cittadino straniero, dentro e fuori dagli Stati Uniti, compresi i dipendenti stranieri della stessa Anthropic.

Screenshot

Non discuto qui chi abbia ragione. Mi interessa una cosa più semplice, e più scomoda, che fino a quella sera in molti trattavano come un dettaglio tecnico: l’accesso ai modelli di frontiera è un permesso, e un permesso lo concede qualcuno che può anche ritirarlo.

Un export control ha messo offline un modello di frontiera

La direttiva è arrivata venerdì pomeriggio, alle 17:21 ora della costa Est. Secondo NBC News a firmarla è stato il Segretario al Commercio Howard Lutnick, con i funzionari del Bureau of Industry and Security, l’ufficio che negli Stati Uniti gestisce le restrizioni all’export. È lo stesso strumento con cui negli anni Novanta Washington trattava la crittografia come un’arma da guerra, soggetta alle regole sull’export militare. Anthropic ha scelto di spegnere i modelli per tutti, perché applicare il divieto ai soli stranieri avrebbe comunque tagliato fuori una parte enorme di utenti, inclusi i suoi stessi dipendenti non statunitensi.

L’azienda si adegua, ma dichiara di non essere d’accordo. Sostiene che la vulnerabilità contestata sia minore, che la prova ricevuta sia finora soltanto verbale, e che la stessa capacità sia già reperibile in altri modelli pubblici, incluso GPT-5.5 di OpenAI, e usata ogni giorno da chi i sistemi li difende. È, per quanto se ne sa, la prima volta che un’azienda AI di primo piano mette offline un modello già distribuito al pubblico per effetto di un intervento federale.

Il contesto pesa più della singola lettera. A febbraio l’amministrazione aveva provato a escludere i prodotti Anthropic dalle agenzie federali, l’azienda aveva fatto causa e un giudice le aveva dato ragione. La settimana scorsa è emerso che la National Security Agency stava usando Mythos per operazioni cyber offensive. E il 2 giugno è stato firmato un ordine esecutivo sull’AI che, tra le altre cose, prevede un meccanismo per dare al governo accesso anticipato, su base volontaria, ai modelli più potenti. Lo stesso modello che lo Stato vuole usare per la propria sicurezza è anche quello che lo Stato può decidere di spegnere, per la stessa ragione.

Permesso, non proprietà

Quando paghi l’abbonamento a un modello hai l’impressione di possederne l’uso. L’accesso non è un bene che possiedi, è un permesso che ti concedono, condizionato, che vive su infrastruttura di qualcun altro e sotto la legge di qualcun altro.

In Pelle Digitale ho provato a raccontare come il digitale sia diventato una seconda pelle, qualcosa che indossiamo senza più accorgercene finché funziona. La dipendenza più profonda è quella invisibile. La vedi solo il giorno in cui qualcuno la stacca, e venerdì centinaia di milioni di persone hanno visto la propria.

Il controllo dell’AI è verticale

Girano decine di schemi dello stack dell’AI. Alcuni lo disegnano come un mercato, con applicazioni e modelli e dati e infrastruttura, altri come un’architettura tecnica a livelli, altri ancora come una pila di governance che sale dalla sicurezza fino al consiglio di amministrazione. Linguaggi diversi per lo stesso oggetto.

Quasi nessuno mette in evidenza la dimensione che venerdì è diventata lampante. Il controllo è verticale. C’è una pila che parte dal silicio e arriva alla governance, con in mezzo il cloud, i pesi del modello, il runtime di inferenza, l’orchestrazione, le applicazioni. Puoi avere model card, audit trail e comitati etici impeccabili in cima, e perdere comunque l’accesso al modello perché una lettera, in un’altra capitale, ha deciso così. Una policy perfetta vale poco se il fondo della pila vive sotto la giurisdizione di un altro Stato.

Dove può intervenire davvero un’azienda privata?

Qui la domanda si fa concreta, e la risposta cambia da livello a livello.

Sul silicio un’azienda privata non interviene. Non progetta i chip, non controlla i grandi produttori, e l’export sui semiconduttori è una leva che si muove tra governi. È il piano geopolitico del controllo, quello su cui un’impresa, per quanto grande, resta sostanzialmente spettatrice.

Dal cloud in su la situazione si ribalta. L’infrastruttura puoi sceglierla, on-premise oppure su un cloud sovrano in giurisdizione europea. Il runtime di inferenza gira su software aperto, dentro il tuo perimetro. Per orchestrazione e agenti esistono standard aperti come MCP. Le applicazioni le disegni o le ospiti tu, e la governance, in cima, è per definizione tua.

In mezzo c’è il livello che decide tutto, il modello e i suoi pesi. Con pesi aperti, scaricati e ospitati sulla tua infrastruttura, il modello è tuo e nessuno te lo spegne da remoto. Con un’API proprietaria, per quanto eccellente, dipendi dalla continuità di servizio di chi te la fornisce, ed è esattamente lì che venerdì è caduta la direttiva.

Controllare l’intera pila, dal chip all’applicazione, è impraticabile per quasi qualunque organizzazione, e costoso anche solo provarci. La scelta sensata non sta nel possedere tutto, ma nel decidere, livello per livello, cosa tenere dentro il perimetro e cosa affittare sapendo bene che cosa si sta affittando.

Il metodo viene prima della tecnologia

Decidere quali livelli controllare è prima di tutto un esercizio di metodo: mappare le dipendenze reali, valutare la maturità dell’organizzazione, architettare quali strati portare in casa e con quale priorità, mettere governance e conformità, con l’AI Act in testa, dentro il progetto dall’inizio e non come timbro finale. È il lavoro che con ZeroFive provo a fare con un framework a cinque fasi, che parte dall’allineamento strategico e dalla valutazione della maturità, passa per l’architettura delle priorità e l’attivazione della governance, e arriva alla misurazione del valore nel tempo, con un’idea fissa, portare metodo dove l’industria porta hype.

Il metodo dice quali livelli pesano per te. Poi serve la tecnologia per tenerli davvero in mano, e sul livello che fa da bivio, il modello e il runtime, la risposta tecnica ha un nome preciso, l’open source. LocalAI è un motore di inferenza aperto, compatibile con le API di OpenAI e indipendente dal modello, pensato per far girare modelli a pesi aperti dentro il perimetro dell’azienda, senza che il dato esca e senza che l’accesso dipenda da una decisione presa da un’altra parte. È il progetto su cui lavoro, e lo cito per quello che è in questo discorso, un modo concreto per riportare il modello dalla parte di chi lo usa. Vale anche per chi si occupa di AI generativa in azienda: la scelta della pila viene prima della scelta del fornitore.

La direttiva del 12 giugno rientrerà quasi certamente, Anthropic stessa la legge come un malinteso, e l’accesso a Fable e Mythos tornerà. La lezione però resta anche dopo. Per chi costruisce in Europa la prossima domanda da portare in consiglio di amministrazione non riguarda quale modello sia il più bravo, ma quanta parte del proprio stack continuerebbe a funzionare il mattino dopo una lettera. Voi quanta parte ne avete?

Fonte primaria: Statement on the US government directive to suspend access to Fable 5 and Mythos 5, Anthropic, 12 giugno 2026. Ricostruzione del meccanismo governativo: NBC News. Contesto regolatorio: ordine esecutivo del 2 giugno 2026.

AI & GENAI

OpenClaw: origine, architettura e guida operativa

Una sintesi necessaria

OpenClaw è un framework open source per costruire un assistente personale basato su modelli linguistici, pensato per operare dove le persone comunicano già: chat e canali di messaggistica. Non è un chatbot da interfaccia web, ma un agente che vive accanto all’utente, connesso ai suoi flussi quotidiani, dotato di strumenti e di uno spazio di lavoro persistente.

Il progetto si distingue per alcune scelte nette. Un gateway locale funge da piano di controllo, gestendo connessioni, sessioni e sicurezza. Le funzionalità si estendono tramite “skills”, pacchetti di istruzioni modulari. La presenza dell’agente non è episodica, ma può essere continua grazie a un meccanismo di esecuzione periodica che consente all’assistente di “tornare attivo” senza un prompt umano diretto.

La conseguenza è evidente: OpenClaw non è solo un’interfaccia verso un modello, ma un sistema operativo leggero per agenti. Proprio per questo, i temi più rilevanti non sono legati alle capacità linguistiche, bensì al controllo degli accessi, alla gestione dei permessi e alla riduzione del rischio quando un agente può agire su sistemi reali.

Da prototipo a progetto globale

L’origine di OpenClaw è dichiaratamente pragmatica. Il primo prototipo nasce come un semplice relay per WhatsApp, un progetto sperimentale sviluppato in poco tempo per collegare un modello linguistico a un canale di messaggistica reale. In quella fase iniziale il nome era descrittivo, quasi funzionale, e rifletteva l’obiettivo immediato più che una visione di lungo periodo.

Nel giro di poche settimane il progetto cresce, sia in termini di attenzione pubblica sia di ambizione tecnica. Il relay si trasforma in un assistente personale multi-canale, con una mascotte riconoscibile e un branding che contribuisce alla diffusione virale. Questo passaggio segna anche l’inizio di una fase complessa, caratterizzata da più cambi di nome ravvicinati.

Il primo rebrand nasce da esigenze legate ai marchi e alla somiglianza con nomi già affermati nel panorama AI. Segue una fase intermedia, breve e instabile, in cui la community partecipa attivamente alla scelta del nuovo nome. Infine, arriva OpenClaw: un nome più neutro, verificato e pensato per durare, accompagnato da una migrazione coordinata di repository, documentazione e strumenti di installazione.

Questi cambi non sono solo un dettaglio comunicativo. In un progetto open source che fornisce installer, pacchetti e comandi da eseguire, ogni rebrand apre una finestra di rischio. Domini simili, repository clonati e pacchetti contraffatti possono intercettare utenti meno attenti. La storia di OpenClaw rende evidente quanto la gestione dell’identità di progetto e della supply chain sia parte integrante della sicurezza.

Un’architettura pensata per agire

Il cuore di OpenClaw è il gateway. Si tratta di un processo persistente che gestisce lo stato dell’agente, le connessioni ai canali di messaggistica, l’invocazione degli strumenti e l’interazione con l’utente tramite una dashboard locale. Il gateway è il punto di convergenza di tutto: senza di esso l’agente non esiste.

Intorno al gateway ruota il runtime dell’agente. Qui il modello linguistico viene messo in condizione di operare, non solo di rispondere. Può leggere e scrivere file, effettuare chiamate di rete, inviare messaggi, avviare comandi, a seconda dei permessi concessi. Questa capacità è ciò che rende OpenClaw interessante, ma anche ciò che ne aumenta la criticità.

L’estensione delle funzionalità avviene tramite le skills. Una skill è una cartella strutturata che contiene istruzioni e metadati, caricata secondo regole di precedenza ben definite. Le skills possono essere locali, condivise o installate da registri pubblici. In tutti i casi, vengono trattate come codice: entrano nel perimetro operativo dell’agente e ne influenzano il comportamento.

Accanto alle skills, un elemento distintivo è l’heartbeat. Questo meccanismo consente all’agente di eseguire turn periodici, ad esempio per controllare inbox, aggiornamenti o condizioni di sistema. Non è un semplice cron: è un momento in cui l’agente valuta il contesto e decide se intervenire. È anche il punto in cui automazione e costi, sia economici sia di rischio, diventano evidenti.

Canali, presenza e delega

OpenClaw supporta numerosi canali di messaggistica. Alcuni sono più semplici da configurare, altri richiedono pairing e gestione di stato più complessa. In tutti i casi, la filosofia è la stessa: l’agente non è pubblico per default. L’accesso viene mediato da politiche di pairing e allowlist, che rendono esplicita la delega dell’umano.

Questo aspetto è centrale. Chi può parlare con l’agente può anche tentare di manipolarlo. OpenClaw assume che la prompt injection e il social engineering siano problemi strutturali e non risolvibili solo a livello di modello. La risposta progettuale non è “rendere il modello più intelligente”, ma restringere chi può inviare input e cosa l’agente può fare in risposta.

La distinzione tra conversazione e azione è mantenuta tramite strumenti separati e controlli di approvazione. Alcune operazioni, come l’esecuzione di comandi sul sistema, richiedono un consenso esplicito e vengono bloccate se non autorizzate. Questo approccio riconosce un limite fondamentale: un agente non dovrebbe mai essere considerato affidabile di per sé.

Una guida all’uso consapevole

Installare OpenClaw è relativamente semplice. Il percorso consigliato passa da una CLI che guida l’utente nella configurazione iniziale, nella scelta dei modelli, nell’attivazione del gateway e nell’eventuale installazione come servizio in background. I requisiti tecnici sono espliciti e orientati a sistemi moderni.

La parte più importante non è però l’installazione, ma la configurazione. OpenClaw utilizza un file di configurazione che definisce workspace, canali attivi, politiche di accesso e comportamento dell’agente. Se il file manca, vengono applicati default prudenziali, ma la responsabilità finale resta dell’utente.

Collegare i canali richiede attenzione. Ogni piattaforma ha implicazioni diverse in termini di identità, privacy e superficie di attacco. La documentazione insiste sul pairing come default e sulla necessità di approvare esplicitamente chi può interagire con l’agente.

Lo sviluppo di skills è un altro punto delicato. Creare una skill significa introdurre nuove istruzioni operative. Per questo motivo, le skills vanno versionate, revisionate e comprese prima dell’uso. Installare una skill equivale a estendere il perimetro di azione dell’agente.

Sicurezza come prerequisito, non come optional

OpenClaw espone apertamente il proprio threat model. L’agente può fare molto, se glielo si consente. Può anche essere manipolato, se esposto a input non fidati. Il progetto non promette protezione assoluta, ma mette a disposizione strumenti per ridurre il rischio.

Il principio guida è semplice: controlli di accesso prima dell’intelligenza. Identità, scope e permessi vengono prima del modello. L’idea è assumere che il modello possa essere ingannato e costruire barriere tecniche che limitino l’impatto di un errore o di un abuso.

La supply chain è trattata come parte integrante della sicurezza. Plugin, skills e installer possono eseguire codice. I rebrand rapidi del progetto hanno mostrato quanto sia facile sfruttare la confusione per distribuire versioni malevole. La lezione è chiara: verificare sempre le fonti, fissare le versioni e non installare nulla che non sia compreso.

E adesso?

OpenClaw non è importante perché “fa cose spettacolari”. È importante perché rende visibile una transizione in atto. Gli agenti non sono più solo interfacce conversazionali, ma operatori delegati che agiscono in ambienti reali. Questo sposta il dibattito dall’output del modello alla governance del sistema.

Adottare OpenClaw significa fare una scelta precisa: portare l’AI dentro i propri flussi quotidiani, accettando i benefici e i rischi. La storia del progetto, con le sue accelerazioni e le sue frizioni, è istruttiva. Mostra quanto rapidamente un esperimento possa diventare infrastruttura e quanto sia necessario pensare alla sicurezza e alla responsabilità fin dall’inizio.

In questo senso, OpenClaw è meno una curiosità tecnica e più un anticipo di ciò che vedremo sempre più spesso: agenti personali potenti, locali, integrati e, se non governati, potenzialmente problematici. Conoscerne la storia e il funzionamento è il primo passo per usarli in modo consapevole 🙂

AI & GENAI

Da Clawdbot a Moltbot a OpenClaw

Una settimana che ha messo a nudo l’open source agentico

A fine gennaio 2026, un assistente personale open source ha smesso di essere un progetto per addetti ai lavori ed è diventato improvvisamente un oggetto di discussione pubblica. Non per una nuova funzione rivoluzionaria, ma per una sequenza di eventi che ha costretto migliaia di persone a inseguire un nome che cambiava più velocemente del codice.

La vicenda è interessante non perché “un bot è diventato virale”, ma perché mostra cosa accade quando un progetto che abilita agenti autonomi supera di colpo una soglia critica di attenzione. Arrivano utenti, tutorial, fork, estensioni, analisi di sicurezza, opportunisti. E in quel momento un tema apparentemente secondario, il nome, si trasforma in una questione di governance e di supply chain.

Clawdbot: quando un prototipo prende forma e identità

All’origine non c’era un grande disegno strategico, ma un prototipo concreto: un semplice gateway per portare un agente AI dentro WhatsApp. Un relay funzionale, pensato per collegare un modello linguistico a un canale reale. In questa fase iniziale il nome era poco più che descrittivo, legato all’idea di “artiglio” come metafora dell’azione.

Il salto avviene quando al progetto viene data un’identità visiva e narrativa. Compare una mascotte, un’aragosta spaziale, e con essa il nome Clawdbot. L’immaginario funziona. Il progetto smette di essere un semplice relay e viene percepito come un assistente personale sempre disponibile, capace di vivere nelle chat quotidiane e, potenzialmente, di agire su strumenti reali.

È qui che il nome inizia a pesare. Clawdbot richiama inevitabilmente l’ecosistema Claude, anche se tecnicamente il progetto è indipendente. Finché l’attenzione resta limitata, la sovrapposizione è tollerabile. Quando l’adozione accelera, diventa un problema.

Moltbot: la prima muta, forzata e pubblica

Il primo cambio di nome non nasce da una scelta di marketing, ma da una necessità. Arriva una richiesta formale legata al trademark: l’associazione visiva e nominativa con Claude non può reggere su larga scala. Non è uno scontro legale spettacolare, ma una situazione tipica quando un progetto cresce troppo in fretta rispetto alle sue fondamenta.

La risposta è rapida: Clawdbot diventa Moltbot. La narrativa interna parla di muta, di cambio di guscio per continuare a crescere. Il nome è coerente con la lore dell’aragosta, ma introduce un problema inatteso. Il rebrand avviene mentre migliaia di persone stanno installando, clonando repository, scrivendo guide e automatizzando deploy.

In quel breve intervallo si apre una finestra di rischio. Handle social e repository vengono occupati da terzi, compaiono cloni, domini simili, pacchetti che imitano quelli ufficiali. Non serve una campagna sofisticata: basta confusione. In un progetto che gira localmente sulle macchine degli utenti, il nome non è solo comunicazione, è un identificatore operativo.

La lezione è brutale nella sua semplicità: quando il software è installabile ed eseguibile, un rebrand è un’operazione di sicurezza, non un restyling.

OpenClaw: la stabilizzazione necessaria

A distanza di pochissimi giorni arriva un secondo cambio di nome. Moltbot non convince fino in fondo, e soprattutto non risolve il problema di fondo: serve un’identità stabile, verificabile, difendibile. Nasce così OpenClaw.

Questa volta il rebrand non è solo nominale. Viene accompagnato da una pulizia dell’ecosistema, dal consolidamento dei repository ufficiali, da un rafforzamento dichiarato delle misure di sicurezza e dall’ampliamento del gruppo di maintainer. È il passaggio da progetto individuale a infrastruttura condivisa.

Il messaggio implicito è chiaro: quando un framework per agenti autonomi diventa mainstream, non può più permettersi ambiguità. Serve una base solida, non solo dal punto di vista tecnico, ma anche organizzativo.

Cosa racconta questa storia

La sequenza Clawdbot > Moltbot > OpenClaw è compressa nel tempo, ma estremamente istruttiva. In pochi giorni ha reso visibili tre livelli di fragilità tipici dell’open source agentico.

Il primo è la supply chain dell’identità: nomi, domini, repository, script di installazione. Quando questi elementi non sono allineati, diventano vettori di abuso.

Il secondo è la supply chain dell’ecosistema: estensioni, plugin, tutorial, pacchetti non ufficiali. La domanda improvvisa crea spazio per soluzioni “plausibili” ma malevole.

Il terzo è la governance tecnica: un agente personale ha accesso a strumenti, file, rete. Se la distribuzione e l’identità non sono sotto controllo, il rischio non è teorico ma operativo.

Questa storia non parla solo di un progetto. Parla di un cambio di fase. Gli agenti non sono più demo o chatbot isolati, ma componenti che vivono vicino ai sistemi reali delle persone. In questo contesto, nomi, processi e responsabilità contano quanto il codice.

Una lezione importante

OpenClaw rappresenta una stabilizzazione, non una conclusione. La velocità con cui tutto è accaduto dimostra quanto l’ecosistema non sia ancora maturo dal punto di vista delle pratiche condivise. Ma dimostra anche che certi problemi emergono solo quando qualcosa funziona veramente.

La vera eredità di questa vicenda non è il meme del “triplo rebrand più veloce della storia open source”. È l’evidenza che l’open source agentico, quando esce dalla nicchia, deve essere trattato come infrastruttura critica. E che la maturità di un progetto non si misura solo in feature, ma nella capacità di reggere il mondo reale quando arriva tutto insieme.