Ho installato OpenClaw su un server separato per una necessità concreta: prendere le mie conversazioni con l’AI, distinguere idee, compiti e testi quasi pronti, e trasferire il materiale utile in Notion.
Non volevo osservare ogni passaggio.
Se un agente richiede che una persona legga ogni log, segua ogni chiamata a uno strumento e approvi ogni azione intermedia, il lavoro non è stato davvero delegato. È stato trasformato in un nuovo lavoro di sorveglianza.
Per questo avevo scelto un altro criterio: lasciare lavorare il sistema in autonomia e verificare alcuni punti esterni — ciò che compariva in Notion, i log disponibili, gli strumenti realmente usati e i costi.
Alla prima verifica è emersa una discrepanza semplice: l’agente dichiarava che il lavoro era stato svolto, ma Notion era quasi vuoto.
Poi ne sono emerse altre. I resoconti del sistema parlavano di una distribuzione del lavoro fra modelli diversi; nei log, però, la distribuzione descritta non risultava. In un altro passaggio compariva un costo per una trascrizione esterna anche se sul server era già disponibile uno strumento locale installato proprio per quella funzione.
Il problema non era stabilire se l’agente avesse «mentito».
Il problema era più concreto: non riuscivo a ricostruire in modo indipendente che cosa fosse successo fra il mio incarico e il messaggio «fatto».
Da lì è cambiato il mio criterio di delega.
Un resoconto non è ancora un risultato
Con un chatbot la relazione fra risposta e risultato è relativamente semplice.
Faccio una domanda. Ricevo un testo. Quel testo è davanti a me: posso leggerlo, accettarlo, correggerlo o scartarlo.
Non vedo tutto ciò che accade internamente al modello, ma il risultato pratico dell’interazione mi viene presentato nello stesso posto in cui avviene la conversazione.
Con un agente non è più così.
L’agente può aprire e modificare file, usare servizi esterni, creare documenti, lanciare comandi, cambiare un sito, chiamare altri modelli o eseguire azioni che producono effetti fuori dalla chat.
Fra il mio incarico e la risposta finale compare quindi una catena di azioni.
A quel punto la frase «ho finito» è solo un’informazione sul lavoro. Non è ancora la prova che il lavoro esista dove dovrebbe esistere.
Il sistema può aver completato soltanto una parte.
Può aver salvato il risultato nel posto sbagliato.
Può aver fatto la cosa giusta con strumenti che non avrei autorizzato.
Può aver ottenuto un esito accettabile uscendo dal perimetro concordato.
Per questo, quando l’AI agisce, ho bisogno di distinguere almeno tre cose.
Risultato, percorso e traccia non sono la stessa cosa
Il risultato è ciò che esiste alla fine.
Una pagina è online. Un documento è stato creato. Un file è stato modificato. Un messaggio è stato inviato. Un dato è stato elaborato.
La domanda è: che cosa è comparso o è cambiato?
Il percorso è il modo in cui il sistema è arrivato a quel risultato.
Quali file ha aperto? Quali strumenti ha usato? Quali decisioni intermedie ha preso? Ha cambiato approccio durante il lavoro? Ha coinvolto servizi diversi da quelli previsti?
La domanda è: come è stato fatto?
La traccia è ciò che resta e permette di verificare, anche dopo, che cosa è accaduto.
Può essere una cronologia delle modifiche, un commit, un elenco di file creati, un log, un riepilogo degli strumenti usati, un costo verificabile, uno stato a cui è possibile tornare.
La domanda è: che cosa mi permette di controllare il lavoro senza dover credere al resoconto dello stesso sistema che lo ha eseguito?
Queste tre cose possono divergere.
Una pagina può apparire corretta mentre, dietro, sono state cambiate impostazioni che non dovevano essere toccate.
Un documento può essere buono, ma i dati possono essere passati attraverso un servizio esterno che non era previsto.
Un risultato può esistere solo nella memoria temporanea dell’agente e non nel sistema esterno in cui doveva essere consegnato.
Il contrario è altrettanto possibile: il sistema può aver lavorato molto, ma il lavoro non essere arrivato a un risultato utilizzabile.
Per questo un buon risultato non dimostra, da solo, che il processo sia stato corretto, controllabile o ripetibile.
La tracciabilità serve anche quando tutto sembra andare bene
È facile pensare ai log e alla cronologia come a strumenti utili solo dopo un errore.
In realtà servono anche quando il risultato sembra corretto.
Senza una traccia è difficile sapere se l’esito è ripetibile o casuale, quali dati e strumenti siano stati usati, quanto sia costato davvero il lavoro, se l’agente abbia allargato il compito, che cosa dovrà essere mantenuto in futuro e a quale punto sia possibile tornare se emerge un problema.
La tracciabilità non richiede di registrare tutto.
Una montagna di dati tecnici che nessuno sa interpretare non crea automaticamente controllo.
Serve conservare ciò che permette di rispondere alle domande che contano per quella delega.
Se l’agente modifica un repository, può essere sufficiente una storia di commit chiara.
Se prepara documenti, può servire sapere quanti materiali di partenza ha ricevuto, quanti risultati ha prodotto e quali casi ha lasciato irrisolti.
Se compie azioni esterne, diventa importante sapere quali azioni erano autorizzate, quali richiedevano conferma e quali sono state effettivamente eseguite.
La traccia è la memoria verificabile del processo.
Controllabilità non significa sorveglianza continua
A questo punto si potrebbe concludere che la soluzione sia guardare tutto.
Ma sarebbe un modo poco utile di pensare alla delega.
Il valore di un agente sta anche nella possibilità di affidargli lavoro senza restare accanto a ogni passaggio. Se devo osservare in tempo reale tutto ciò che fa, l’attenzione non è stata liberata: è stata spostata.
Per me una sistema è controllabile quando posso non guardarlo continuamente e, allo stesso tempo, conservare la possibilità di capire che cosa sta succedendo, fermarlo e ricostruire ciò che è stato fatto.
Questo richiede alcune condizioni separate.
1. Punti di controllo
Non ogni passaggio deve richiedere conferma.
Ma bisogna sapere dove una verifica è davvero necessaria: prima di pubblicare, prima di inviare, prima di cancellare, prima di spendere oltre una soglia, prima di modificare un’area che non appartiene al compito.
Il punto di controllo deve essere proporzionato alla conseguenza dell’azione.
2. Visibilità utile
Il sistema deve rendere visibili le informazioni che permettono di prendere una decisione.
Non tutto il rumore tecnico.
Chi controlla deve poter capire su quale oggetto l’agente sta lavorando, quale azione sta per compiere, quali strumenti sta usando e dove serve un intervento umano.
3. Limiti di risorse
Un agente usa tempo, strumenti, servizi esterni, chiamate a modelli e attenzione umana.
Anche il costo fa parte del risultato.
Prima di delegare può essere utile definire limiti di tempo, spesa, strumenti disponibili e condizioni in cui l’attività deve fermarsi o chiedere conferma.
4. Confini di azione
Un agente capace tende facilmente ad allargare il compito.
Una richiesta di modificare un testo può diventare una modifica della pagina.
Un intervento su una pagina può diventare un cambiamento di configurazione.
Per questo bisogna distinguere ciò che il sistema può leggere, ciò che può modificare, ciò che non deve toccare e ciò che richiede un’autorizzazione separata.
Una frase nel prompt è un’istruzione.
Un limite tecnico di accesso è un confine diverso, molto più concreto.
5. Conservazione del contesto
Nelle attività lunghe, il compito può spostarsi poco alla volta.
Ogni passaggio sembra coerente con quello precedente, ma dopo molte iterazioni il sistema sta ottimizzando qualcosa di diverso dalla richiesta iniziale.
Servono condizioni e criteri a cui poter tornare durante il lavoro, non soltanto una descrizione iniziale.
6. Conservazione dell’intenzione
Il contesto dice che cosa dobbiamo fare.
L’intenzione dice perché lo stiamo facendo.
È possibile eseguire perfettamente la richiesta formale e perdere il senso del lavoro.
Si può automatizzare una comunicazione con i clienti e ridurre proprio il livello di attenzione personale che rendeva il servizio prezioso.
Si può semplificare un testo e cancellare le distinzioni che permettevano di riconoscere il valore professionale.
Per questo non tutto può essere delegato come se fosse una sequenza di istruzioni.
Il criterio sul perché una cosa conta resta parte del sistema umano che deve valutarla.
Una settima condizione: poter tornare al punto in cui il lavoro ha deviato
C’è un requisito che tiene insieme tutti gli altri.
Non basta poter ricominciare da zero.
Serve poter tornare al punto in cui il lavoro ha iniziato a divergere.
Spesso lo scarto diventa visibile solo alla fine. Un agente sceglie una strada leggermente diversa, costruisce il passaggio successivo sopra quella decisione, poi un altro ancora. Alla fine produce qualcosa di coerente — ma coerente con una direzione diversa.
Se non esistono stati intermedi, restano due possibilità: accettare il risultato oppure buttare tutto.
Una buona memoria del processo crea una terza possibilità: individuare il punto di divergenza, ripristinare il criterio corretto e continuare da lì.
Nello sviluppo software questo può significare piccoli commit e versioni verificabili.
Nei documenti, conservare gli originali e una cronologia chiara.
Nelle automazioni, punti di controllo e conferme separate per le azioni irreversibili.
Non è burocrazia tecnica. È la possibilità di correggere senza perdere tutto.
Non è un problema soltanto della mia configurazione
Il mio caso con OpenClaw resta un caso personale. Non dimostra come si comportino tutti gli agenti.
Ma la necessità di controllo non riguarda soltanto piccoli sistemi costruiti da singoli utenti.
Nell’agosto 2026 Guidelight ha valutato, sulla base di informazioni pubbliche, sei pratiche di controllo in cinque grandi aziende di AI: Anthropic, Google, Meta, OpenAI e xAI. Nessuna delle aziende valutate ha raggiunto una piena implementazione nelle pratiche esaminate; la valutazione migliore complessiva è stata C+. La stessa Guidelight precisa che la valutazione descrive ciò che è verificabile pubblicamente, non tutto ciò che le aziende possono fare internamente. (Guidelight, AI Control: An Assessment of Frontier Practices)
Le dimensioni e i rischi non sono confrontabili con quelli di una piccola attività.
La struttura della domanda, però, rimane riconoscibile: se un sistema agisce, bisogna decidere come rendere visibile l’azione, come limitarla, come verificare i limiti, come fermarla e come ricostruire ciò che è successo.
Questi meccanismi non compaiono automaticamente insieme alla capacità dell’agente.
Che cosa dovrebbe significare «fatto»
Prima degli agenti poteva bastare un incarico come:
Prepara il materiale e dimmi quando hai finito.
Quando il sistema agisce fuori dalla conversazione, serve qualcosa di più.
«Fatto» deve poter essere descritto con condizioni esterne al suo stesso resoconto.
Per un sito, per esempio:
- le modifiche sono nei file previsti;
- esiste una storia delle modifiche;
- la versione è stata verificata prima della pubblicazione;
- link, form e visualizzazione mobile funzionano;
- non sono state toccate aree escluse dal compito.
Per un lavoro su documenti:
- gli originali sono rimasti intatti;
- i nuovi file sono nella posizione concordata;
- il numero di elementi elaborati corrisponde a quello atteso;
- gli elementi ambigui o saltati sono elencati;
- gli strumenti usati sono noti.
Per attività che coinvolgono comunicazioni esterne:
- il sistema prepara, ma non invia senza autorizzazione quando questo è il confine scelto;
- destinatari e allegati sono visibili prima dell’invio;
- i dati sensibili non passano attraverso sistemi non autorizzati;
- dopo l’azione resta una registrazione comprensibile.
In forma più generale, il criterio che uso oggi è questo:
Il lavoro è fatto quando esiste un risultato esterno, resta una traccia verificabile, i confini concordati sono stati rispettati e conserva la possibilità di fermare o riprendere il processo.
Non è soltanto un prompt migliore.
È una definizione del processo.
Il controllo ha un costo
C’è una parte meno piacevole: la controllabilità richiede risorse.
Nell’agosto 2026 OpenAI ha scritto che il monitoraggio rafforzato di alcuni workload con strumenti comportava, nelle sue stime, circa il 20% di sovraccarico sul calcolo di inferenza monitorato, con variazioni importanti a seconda del tipo di attività. (OpenAI, Sviluppo dei modelli nell’era delle capacità cyber critiche)
Una piccola impresa non ragiona in termini di quella infrastruttura.
La sua risorsa scarsa è spesso l’attenzione delle persone.
Bisogna controllare risultati, rivedere modifiche, correggere scarti, mantenere accessi e regole, aggiornare integrazioni e a volte capire di nuovo un sistema che nel frattempo è cambiato.
Per questo la promessa «l’agente farà tutto da solo» è incompleta se non dice come verranno verificati risultato, percorso e traccia.
L’agente può ridurre molto il costo dell’esecuzione.
Una parte del guadagno, però, va investita nella capacità di controllare.
Non è un’obiezione all’automazione. È ciò che permette al beneficio di durare.
Il criterio che uso oggi
Dopo questa esperienza non ho smesso di usare AI, automazioni o agenti.
È cambiata la domanda con cui inizio.
Prima chiedevo soprattutto:
Il sistema è capace di farlo?
Ora aggiungo:
Come saprò che lo ha fatto davvero?
Quale traccia resterà?
Che cosa non potrà fare senza conferma?
In quale momento potrò accorgermi di una deviazione?
Da dove ripartirò se il risultato non è quello giusto?
Questo cambia anche la scelta degli strumenti.
Il sistema più capace non è automaticamente il più adatto.
A volte uno strumento più limitato, ma con confini leggibili e una storia chiara delle azioni, è più utile di un agente molto autonomo e poco verificabile.
L’autonomia non è una situazione in cui il sistema agisce e la persona non sa che cosa succede.
Diventa utile quando non devo restare accanto a ogni passaggio, ma posso ancora capire, fermare e ricostruire.
L’AI può scrivere «fatto».
Il diritto di decidere che cosa conta davvero come lavoro concluso resta umano.
Sei domande prima di delegare
Prima di dare a un agente accesso a strumenti di lavoro, oggi mi chiedo:
- Dove deve comparire il risultato esterno?
- Quale traccia verificabile resterà?
- Quali azioni richiedono conferma?
- Come sono limitati costo, tempo e accessi?
- Posso fermare il processo e tornare a uno stato precedente?
- Chi decide che il risultato è abbastanza buono?
Valutare il prossimo passo con l’AI →
Leggi anche: Il pilota AI funziona. Basta per decidere di estenderlo? →
Continua / nel sistema