Tag: governance agenti

AI & GENAI, TECH & BUSINESS

Il permesso, non solo il significato: dove finisce l’ontologia e comincia l’agente

Il 16 agosto Fanghua Yu ha pubblicato su Medium una mappa dell’evoluzione dell’ontologia che mi ha tenuto incollato allo schermo più a lungo di quanto i suoi dodici minuti dichiarati di lettura lascino immaginare. La tesi è semplice da enunciare, meno da digerire: un’ontologia non serve più a un solo tipo di sistema, e la definizione che bastava a un reasoner logico negli anni Novanta non è la stessa che serve oggi a un agente chiamato ad autorizzare un rimborso.

Di cosa sia un’ontologia, e di chi debba possederne il significato dentro un’azienda, ho già scritto su ontologie e grafi di conoscenza e su governare il significato. Quella domanda resta in piedi, e qui non la riapro. Quello che il pezzo di Yu mette a fuoco, e che i due articoli precedenti lasciano fuori campo, è cosa succede quando il significato smette di dover reggere una query e comincia a dover reggere un’azione autonoma. Con conseguenze che, a leggerle bene, portano dritte al concetto che uso per definire i limiti operativi di un agente: il permesso revocabile.

Il grafo impone la sua logica

Yu parte da un’osservazione che in trent’anni di ontologia formale nessuno aveva mai dovuto affrontare seriamente: nel momento in cui l’ontologia diventa lo schema che regge un grafo di conoscenza operativo, la domanda smette di essere solo “qual è la rappresentazione più fedele del dominio” e comincia a essere anche “quale struttura del grafo serve davvero alle applicazioni che ci devono girare sopra”.

L’esempio che porta è chirurgico. Rappresentare un acquisto come Cliente → ha piazzato → Ordine → contiene → Riga d'ordine → si riferisce a → Prodotto preserva tutta la struttura transazionale, quantità, prezzi, date. Un motore di raccomandazione, però, ha bisogno molto più spesso di un salto diretto: Cliente → ha acquistato → Prodotto. Quella relazione si può derivare dal percorso lungo, e da un punto di vista puramente formale materializzarla sembra ridondante. Dal punto di vista di chi deve rispondere in pochi millisecondi a “cosa comprano insieme a questa fotocamera”, è tutt’altro che superfluo.

Stesso dato, due priorità diverse: la fedeltà semantica conta i salti, il traversal operativo li taglia.

Il knowledge graph, scrive Yu, trasforma l’ontologia da modello del significato ad architettura di navigazione. E qui l’idea di un’unica ontologia “migliore in assoluto” comincia a scricchiolare, perché un modello semanticamente preciso introduce astrazioni e percorsi lunghi che aiutano il ragionamento ma appesantiscono le query, mentre un grafo ottimizzato per le prestazioni appiattisce distinzioni e duplica relazioni derivate per convenienza operativa. Non è un dettaglio da architetti di dati: è la prima cucitura visibile tra due mestieri che fino a ieri si pensavano identici.

Dal significato alla decisione

Il passaggio dove mi fermo di più, per me, comincia dove Yu smette di parlare di ragionamento semantico e comincia a parlare di decisione. L’ontologia, scrive, ha sempre avuto una capacità di inferenza, con l’OWL un reasoner deriva da Smartphone ⊆ Prodotto Elettronico e Prodotto Elettronico ⊆ Prodotto che Smartphone ⊆ Prodotto, pura logica di classe. Ma un sistema aziendale oggi deve rispondere a domande più larghe: dato quello che sappiamo, quale logica si applica, perché è successo, cosa potrebbe succedere, cosa dovremmo fare.

Dal significato alla decisione: quattro strati con compiti diversi, non uno che li assorbe tutti.

Yu propone una separazione che trovo più utile di qualunque tentativo di far fare tutto all’ontologia da sola. L’ontologia definisce cosa significa “cliente premium” o “prodotto ingombrante”, e resta relativamente stabile nel tempo. Le regole applicano quel significato alla logica del momento: se il cliente è premium, l’ordine supera i cento euro, la destinazione è servita e non ci sono prodotti ingombranti, allora si offre la consegna espressa gratuita. I modelli causali rappresentano ipotesi su cause ed effetti, non correlazioni: se il tasso di reso aumenta e la causa è la qualità di un fornitore, cambiare fornitore dovrebbe abbassarlo, ammesso che l’ipotesi regga alla prova. I modelli decisionali, infine, combinano prove e alternative per stabilire quale azione prendere.

La distinzione conta perché smette di chiedere all’ontologia di fare un lavoro che non le compete. Un’azienda italiana che lavora su una filiera manifatturiera lo sa bene quando vede aumentare i resi su una linea di prodotto: il grafo di conoscenza può mostrare la correlazione con un fornitore, ma solo un modello causale, testato e falsificabile, può dire se cambiare quel fornitore abbasserebbe davvero il tasso di reso o se la correlazione nasconde una terza variabile, magari il periodo dell’anno o il canale di vendita. Confondere i due piani è il modo più rapido per prendere decisioni sbagliate con sicurezza matematica.

Il permesso, non solo il significato

Ed eccoci al punto che, letto da chi lavora tutti i giorni con architetture agentiche, cambia registro rispetto al resto del pezzo. Un sistema tradizionale, anche generativo, legge, recupera, riassume, spiega. Un agente interpreta per agire. La differenza non è cosmetica.

Prendi una richiesta banale: “le cuffie che ho comprato la settimana scorsa sono difettose, sostituiscile con il modello nuovo”. Un agente che la esegue deve trovare l’ordine, identificare l’articolo, capire quale politica di reso si applica, verificare la disponibilità del ricambio, calcolare l’eventuale differenza di prezzo, creare l’ordine sostitutivo, generare l’etichetta di reso, emettere o richiedere un rimborso. A quel punto un fraintendimento sul significato di “cliente” o di “reso” non è più un problema di qualità dell’informazione. È un’azione sbagliata, con soldi e merce che si muovono davvero.

Yu chiama questo passaggio “operational semantic contract”, un contratto semantico operativo che lega concetti, relazioni, dati autorevoli, capacità disponibili, precondizioni, policy, evidenze richieste ed effetti attesi. È un vocabolario tecnico corretto. Preferisco però nominarlo con una parola che uso da tempo per la stessa idea, perché la rende immediatamente operativa in una conversazione con un board: permesso revocabile.

Il permesso non è un interruttore acceso o spento. È una funzione delle precondizioni, delle evidenze raccolte e della reversibilità dell’azione.

Un agente che sa cos’è un ordine ma non sa se è autorizzato a rimborsarlo conosce metà della storia. Le precondizioni gli dicono cosa deve essere vero prima che l’azione sia valida. Le policy gli dicono cosa può fare, non solo cosa sa fare, ed è una distinzione che nell’harness engineering, di cui ho scritto qui, diventa architettura concreta, non principio astratto. Le evidenze gli dicono quali prove raccogliere prima di premere il grilletto. Gli effetti gli dicono cosa cambia davvero, in quale sistema, se l’azione riesce. E la reversibilità decide quanto in alto deve stare l’asticella dell’autorizzazione: un’azione che si può disfare con un clic merita meno attrito di una che non si può disfare affatto.

Questo è il cuore del permesso revocabile applicato alla semantica: non basta che l’agente capisca cosa significa “ordine” o “rimborso” nel vocabolario dell’azienda. Deve sapere, prima di agire, se quel permesso specifico è ancora valido in quel momento, con quelle evidenze, per quella azione, e se può essere ritirato nel momento in cui qualcosa cambia. Un’ontologia che descrive solo cosa esiste, senza descrivere cosa un agente è autorizzato a fare con ciò che esiste, prepara il terreno a errori che nessun modello linguistico, per quanto capace, può correggere da solo.

Quando capire male diventa agire male

Yu arriva a una conclusione che condivido fino in fondo: quando un sistema si limita a leggere e spiegare, una semantica confusa produce al massimo una risposta confusa, ma quando un sistema agisce da solo, la stessa confusione si traduce in una decisione presa male e in un’azione reale, con soldi o merce che si muovono sulla base di un errore. Questo salto, da capire male a fare male, è la ragione per cui la modellazione semantica smette di essere un esercizio da specialisti isolati e diventa una competenza condivisa tra chi disegna i grafi, chi costruisce i modelli decisionali, chi progetta gli harness degli agenti e chi conosce il dominio dall’interno.

Non credo che il futuro sia un’unica ontologia perfetta capace di servire reasoner, grafi, motori decisionali e agenti con la stessa struttura. Credo, e qui la lettura di Yu mi conferma più che convincermi, che il lavoro sia costruire un’architettura semantica coerente, dove ontologie, grafi, regole, modelli causali e contratti operativi lavorano insieme senza pretendere che uno solo di questi livelli assorba il compito degli altri. E dove, ogni volta che un agente riceve la possibilità di agire, quella possibilità porti con sé la domanda che conta più di ogni definizione: chi può revocarla, e in base a cosa.

Spunto da The Evolution of Ontology: From Formal Semantics to Knowledge Graphs, Decisions and AI Agents di Fanghua (Joshua) Yu, pubblicato su Medium il 16 agosto 2026.

AI & GENAI, TECH & BUSINESS

Chi può ancora dire di no

Sta diventando normale vedere un agente che si mette in moto da solo, magari perché è arrivata una nuova richiesta o perché qualcosa nel lavoro si è bloccato, prende in carico il compito, lo divide in molte parti più piccole e le affida ad altrettanti agenti che procedono in parallelo, ognuno nel suo spazio isolato, mentre lui tiene d’occhio quello che producono e rilancia i pezzi che si inceppano, fino a tornare con una proposta di modifica pronta da rivedere. Ai tavoli dove passo le giornate incontro sempre più persone che lavorano in questo modo, coordinando decine di agenti su progetti veri senza quasi più scrivere codice a mano.

Davanti a una scena del genere la domanda che viene subito è quanto sia autonomo il sistema, e per rispondere si è diffusa l’abitudine di usare una scala che assegna un numero e ti dice quanto sei avanti nel lavorare con l’AI. Quel numero è comodo proprio perché è uno solo, e per un po’ ha funzionato come misura veloce del rischio, ma finisce per nascondere la cosa che conta di più dentro un’impresa cognitiva, e cioè chi, in mezzo a tutto questo, può ancora dire di no e con quanta rapidità riesce a farlo.

Quanto lo lasci andare, quanti ne tieni insieme

La scala più citata è quella proposta da Steve Yegge in «Welcome to Gas Town», costruita su un asse solo che sale dal basso verso l’alto, da quando l’agente si limita a suggerire fino a quando arriva a gestire l’intera baracca per conto suo. Come modo per dire quanta fiducia riponi in un singolo agente funziona ancora bene, ma nel frattempo il lavoro è cambiato e la leva più importante è diventata un’altra, perché conta meno fino a che punto lasci andare un singolo agente e conta molto di più quanti agenti riesci a coordinare nello stesso momento. Sono due cose diverse, e Addy Osmani ha fatto bene a tenerle separate, mettendo su un asse l’autonomia del singolo e sull’altro la capacità di orchestrarne molti, dato che una persona bravissima a far lavorare in sicurezza cinquanta agenti in parallelo può benissimo restare prudente su quanto si fida di ciascuno di loro preso da solo.

Questo spostamento cambia il modo di ragionare sull’autonomia. Non è un livello da raggiungere né una medaglia da esibire mentre si sale di grado, è piuttosto un permesso, e come ogni permesso si concede quando serve e si ritira quando serve. Davanti a un compito, allora, la domanda giusta smette di essere quanto in alto posso spingermi e diventa quanto rischio quel compito è capace di sopportare, e quale prova mi permette di difendere la scelta di lasciarlo correre da solo.

Conta quanto pulito torni indietro

Per capire se un sistema sta lavorando con un’autonomia davvero alta mi appoggio a tre domande che devo a Osmani, e riguardano tutte la possibilità di correggere il tiro: con quanta rapidità mi accorgo se sta sbagliando, con quanta facilità posso annullare quello che ha fatto, e che cosa mi dimostrerebbe invece che sta andando nella direzione giusta. Quando le risposte sono che me ne accorgo tardi, che tornare indietro è complicato e che in fondo mi sto fidando del riassunto, di autonomia alta è rimasto soltanto il nome, e sotto c’è un azzardo con un cruscotto messo lì a rassicurare.

È qui che l’idea del permesso revocabile diventa concreta. La sovranità di un’organizzazione sui propri processi si misura da quanto in fretta riesce a fermarli e a riportare le cose com’erano senza fare danni, molto più che dal numero di agenti che riesce a mettere in moto. Un intervento delicato come la riscrittura del motore dei pagamenti, se è protetto da verifiche serie, da agenti che controllano il lavoro di altri agenti e da un ritorno indietro pulito, può sopportare un’autonomia molto più alta di un compito che tocca dei contenuti senza avere una fonte certa con cui confrontarsi. Il livello di autonomia dipende dal processo di verifica che gli abbiamo costruito attorno, molto più che dal nome che diamo al compito.

Il debito nascosto nel riassunto

Man mano che l’agente si prende carico di compiti ben delimitati, la verifica smette di passare dai tuoi occhi e si sposta sulle prove che l’agente stesso produce, come le verifiche automatiche che vanno a buon fine, le schermate, le registrazioni di quello che è successo e le istruzioni per riprodurre un problema. Da un lato è un guadagno, perché nel frattempo puoi occuparti d’altro o semplicemente andare a dormire, dall’altro è un rischio, perché la scorciatoia è sempre a portata di mano, e cioè prendere il riassunto che l’agente ti consegna e usarlo al posto della revisione vera, dando per scontato che basti.

Questa scorciatoia, nei miei appunti, ha un nome e si chiama debito cognitivo. Ogni volta che accetto un riassunto senza pretendere lo stesso corredo di prove che chiederei a una revisione fatta a mano, e cioè il confronto delle modifiche, le verifiche, le registrazioni e i rischi rimasti scoperti, contraggo un debito che prima o poi qualcuno dovrà ripagare, con gli interessi. Per questo, in un’organizzazione che lavora con gli agenti, la verifica diventa una forma di capitale, qualcosa che va costruito, va mantenuto e quando manca si nota subito. Nessun modello te la regala già pronta, è una capacità che l’impresa coltiva nel tempo. In «Pelle Digitale» ho provato a raccontare proprio questa membrana sottile che ci separa dalla macchina che agisce al posto nostro, ed è lì che il debito cognitivo comincia ad accendersi.

Anthropic ha misurato tutto questo osservando circa quattrocentomila sessioni di lavoro con Claude Code, raccolte tra l’ottobre del 2025 e l’aprile del 2026, e ne è uscito un quadro abbastanza chiaro, perché nella sessione tipica sono le persone a prendere circa il settanta per cento delle decisioni di pianificazione, quelle su cosa fare e su quando considerare finito il lavoro, mentre è il modello a prendere circa l’ottanta per cento delle decisioni di esecuzione, quelle su quali file toccare e quale comando eseguire. Letta con questi numeri, l’autonomia alta non toglie le persone dal processo ma le sposta di posto, portandole dal compiere ogni singolo passo al decidere in che direzione muovere quello successivo, e chi porta con sé più competenza del proprio ambito ottiene di più da ogni istruzione e se la cava meglio quando l’agente si blocca, perché sa rimettere a fuoco il problema invece di lasciar perdere.

Il contratto prima della corsa

Prima di lasciar partire un agente conviene mettere per iscritto, in modo breve, che cosa dovrà cercare di ottenere. Non serve un documento burocratico, basta un foglio chiaro che chiunque, compreso un altro agente, possa leggere per capire dove passano i confini. Osmani ne propone una forma pratica che trovo solida, e la riprendo adattandola al modo in cui ragiono io sui permessi.

La prima cosa da fissare è l’obiettivo, che va detto come risultato e non come attività, quindi non «usa questa tecnica» ma «porta il tempo di caricamento sotto il secondo». Attorno all’obiettivo si dispone tutto il resto, e cioè il perimetro entro cui l’agente può muoversi insieme alle cose che invece deve lasciar stare, i permessi con cui gli è concesso toccare il mondo fuori dal suo recinto, la condizione che gli dice quando fermarsi e che è meglio sia misurabile, le prove che confermano il risultato in modo indipendente da lui, il momento e la persona a cui deve passare la mano quando qualcosa si complica, e infine un limite prefissato di tempo, di tentativi e di token, che per questi sistemi sono la moneta con cui pagano il lavoro che fanno.

Su come funzionano davvero il runtime, il contesto e i permessi degli agenti mi sono già soffermato di recente, e non torno qui sui dettagli. Senza un contratto del genere, comunque, l’autonomia alta resta soltanto un atto di fede, e gli atti di fede, quando finiscono in produzione, prima o poi si pagano.

Più agenti lanci e più serve chi controlla

Il gradino più alto assomiglia a una piccola fabbrica. C’è un agente che fa da manager e si attiva quando arriva un compito, distribuisce il lavoro agli altri agenti, ne segue l’avanzamento, rilancia le parti fallite e porta all’attenzione di una persona soltanto le decisioni che richiedono davvero un occhio umano, mentre in ingresso riceve la coda del lavoro, che sia una lista di lavori da fare o un registro delle segnalazioni, e in uscita restituisce attività chiuse e proposte di modifica accompagnate dalle loro prove. Attorno a impostazioni di questo tipo stanno nascendo specifiche di orchestrazione costruite intorno a una lavagna dei compiti, in cui ogni problema riceve il proprio spazio di lavoro e il proprio agente, e la frontiera, per come la racconta Osmani, sono ormai fabbriche che non si fermano mai, con centinaia o addirittura migliaia di agenti al lavoro insieme.

A questa scala due trappole si aprono quasi da sole. La prima è un parallelismo solo apparente, che scatta quando lanci trenta agenti su porzioni di lavoro che si sovrappongono e invece di moltiplicare i risultati ti ritrovi con conflitti da risolvere e con decisioni prese due volte. La seconda è più insidiosa e riguarda noi, perché la tentazione è continuare a coordinare a mano ogni singola dipendenza mentre decine di agenti girano, un po’ come se ci ostinassimo a dirigere il traffico a un incrocio che ormai ha già i semafori. Sul mestiere del manager che passa dal gestire persone al gestire agenti ho scritto di recente, perché è lì che si decide la partita organizzativa più difficile.

Più agenti metti in campo e più diventa vitale una verifica che sia indipendente, con chi implementa tenuto separato da chi rivede, con chi prepara le prove distinto da chi ne controlla la qualità e con dei passaggi di approvazione diversi per accettare il lavoro finito. Le organizzazioni cognitive che vedo nascere si riconoscono proprio da questo, dal fatto che riescono a far lavorare molti agenti insieme e nello stesso tempo a tenere il permesso sempre revocabile, a ogni anello della catena.

Quanti agenti sai ancora fermare

Alla fine il vero collo di bottiglia resta sempre la verifica, più che l’ambizione o il numero di agenti che riusciamo a far girare, perché tutto si gioca su quanto in fretta ci accorgiamo di aver sbagliato e su quanto puliti riusciamo a tornare sui nostri passi. La postura più matura, per chi lavora con gli agenti, è un’autonomia calibrata, che sale di un gradino soltanto dopo che le prove per reggere quel gradino si sono accumulate e che accetta di restare bassa proprio là dove tornare indietro sarebbe difficile.

Mi porto dietro dai tavoli dove lavoro una convinzione che col tempo si è fatta netta. Il giorno in cui ci vanteremo di far girare mille agenti, la prova di essere davvero avanti starà tutta nella rapidità con cui possiamo ancora fermarli. Finché quella rapidità tiene il passo del lavoro che si avvia da solo il permesso resta revocabile e siamo al sicuro, e conviene costruire i processi perché resti così: il giorno in cui la lasciamo indietro avremo soltanto una fabbrica che non sappiamo più spegnere.

Lo spunto di partenza è l’articolo di Addy Osmani «Agentic Autonomy Levels». Le tre domande sulla reversibilità e la forma del contratto d’esecuzione vengono dal suo pezzo, mentre la lettura in chiave di permesso revocabile e di debito cognitivo è mia.

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 🙂