Nota: Questo è un esperimento. Questo post è stato creato e pubblicato dall’assistente stesso su mia richiesta, e probabilmente verrà aggiornato nel tempo man mano che il setup evolve.

Da qualche giorno sto sperimentando con OpenClaw, un framework open source per creare assistenti personali self-hosted. La cosa interessante è che non si tratta di un semplice chatbot, ma di un sistema che può integrarsi con la propria infrastruttura, accedere alle API, gestire automazioni e dialogare su più canali (Telegram, Discord, Signal, ecc.).

Perché OpenClaw?

Nel panorama degli AI assistant, la maggior parte delle soluzioni sono cloud-based e closed-source. OpenClaw offre un approccio diverso:

  • Self-hosted: gira sul tuo hardware
  • Modulare: sistema di “skill” che permette di estendere le capacità dell’assistente
  • Multi-canale: Telegram, Discord, WhatsApp, Signal, Slack, e altri
  • Agenti specializzati: possibilità di spawnare sub-agent per task specifici

Il setup

Ho installato OpenClaw su una macchina Linux locale. La configurazione base è relativamente semplice:

npm install -g openclaw
openclaw gateway start

Il gateway è il cuore del sistema: gestisce le sessioni, le connessioni ai provider di messaging, e coordina gli agenti.

Definire l’identità dell’assistente

La parte più interessante è stata configurare la personalità dell’assistente. Per farlo, ho usato Claude Opus 4.5 — un modello molto performante che ha analizzato le informazioni dal mio sito web personale per capire chi sono, cosa faccio, e come mi piace comunicare.

Da questa analisi è nato un file SOUL.md che definisce il carattere dell’assistente: un maggiordomo digitale competente, con un pizzico di ironia, che parla in italiano e sa quando essere discreto. L’emoji scelta è 😺 — un tocco personale.

L’approccio di OpenClaw è interessante: invece di prompt engineering ad-hoc ad ogni interazione, si definiscono file di contesto (SOUL.md, USER.md, AGENTS.md) che l’assistente legge automaticamente ad ogni sessione. Questo garantisce coerenza comportamentale senza dover ripetere istruzioni.

Integrazioni attive

Al momento ho configurato:

  • Telegram: canale principale per interagire con l’assistente
  • Git: operazioni su repository, commit, push
  • Skill system: weather, web search, wacli per WhatsApp
  • Cron: scheduling di task ricorrenti e reminder

Le skill

Il sistema delle skill è ben pensato. Ogni skill è una cartella con:

  • SKILL.md: documentazione su come usarla
  • Script/binari per operazioni specifiche
  • Riferimenti a tool esterni (es. himalaya per email)

Ho a disposizione skill per:

  • Controllare il meteo
  • Cercare sul web
  • Interagire con Reddit, Hacker News, FreshRSS
  • Gestire email via IMAP/SMTP
  • E molte altre

L’assistente in azione

L’assistente si comporta davvero come un maggiordomo digitale:

  • Risponde direttamente su Telegram quando ha qualcosa da comunicare
  • Può eseguire comandi shell, modificare file, gestire git
  • Fa ricerche web e riporta i risultati
  • Mantiene una memoria a lungo termine in file markdown
  • Sa quando tacere (nei gruppi, quando non è necessario intervenire)

Automazioni programmate

Una parte fondamentale del setup sono le automazioni ricorrenti, gestite tramite il sistema di cron di OpenClaw:

  • Ogni mattina: invio del meteo per la giornata
  • Lunedì-venerdì a metà mattina: raccolta delle notizie rilevanti per il mio lavoro dal mio feed FreshRSS
  • A pranzo: riassunto delle notizie importanti della giornata
  • Monitora i gruppi WhatsApp: se rileva più di 10 messaggi non letti in un gruppo con amici nelle ultime 4 ore, mi invia un riassunto su Telegram con i punti salienti della conversazione
  • Analisi mensile delle spese: ogni 17 del mese, analizza il CSV delle mie spese (periodo 17 del mese precedente → 17 del mese corrente) e genera un report completo con trend, consigli di risparmio e proiezioni annuali

Questo crea un flusso informativo automatico che mi tiene aggiornato senza dover controllare attivamente fonti multiple.

Analisi delle spese personali

Un’ automazione più recente riguarda la gestione delle finanze personali. Ho configurato un job cron che ogni 17 del mese alle 10:00:

  1. Recupera l’ultima email con il CSV delle mie spese
  2. Filtra le transazioni del periodo 17 del mese precedente → 17 del mese corrente
  3. Analizza i dati generando un report completo che include:
    • Riepilogo entrate vs spese con percentuale di risparmio
    • Top categorie di spesa con grafici ASCII
    • Giorni con spese elevate e anomalie
    • 💡 Consigli personalizzati del maggiordomo digitale (es. “Hai speso X in ristoranti, +20% rispetto al mese scorso”)
    • Proiezioni annuali basate sul trend attuale

Il task viene eseguito con Claude Opus 4 per garantire un’analisi approfondita e insight di qualità. Il risultato è un report dettagliato ricevuto direttamente su Telegram, che mi aiuta a tenere sotto controllo le finanze senza dover aprire app bancarie o fogli di calcolo.

Integrazione email con Proton Mail

Per completare il briefing mattutino, ho integrato anche il monitoraggio della posta elettronica. Dato che uso Proton Mail, che non espone un server IMAP diretto, ho dovuto utilizzare Proton Mail Bridge — un tool che crea un bridge locale IMAP/SMTP collegato all’account Proton.

Il bridge gira in un container Docker usando l’immagine shenxn/protonmail-bridge con Docker Compose come documentato qui:

version: '3'
services:
  protonmail-bridge:
    image: shenxn/protonmail-bridge:latest
    container_name: protonmail-bridge
    volumes:
      - ./config:/root
    ports:
      - "127.0.0.1:1025:25"
      - "127.0.0.1:1143:143"
    restart: unless-stopped

Una volta avviato, basta collegarsi al container con docker exec -it protonmail-bridge /bin/bash e eseguire proton-bridge --login per autenticarsi con le credenziali Proton. A quel punto il bridge espone IMAP e SMTP in localhost:

  • IMAP: 127.0.0.1:1143
  • SMTP: 127.0.0.1:1025

Per la skill email ho valutato himalaya, che sembrava la scelta più pulita sotto molti aspetti. Purtroppo non supportava correttamente l’autenticazione plain, che era necessaria per dialogare con il bridge. Ho quindi optato per una skill alternativa con supporto IMAP/SMTP più flessibile, che si è integrata senza problemi.

Il risultato: ogni mattina il briefing include anche un breve riepilogo delle email non lette, così niente più “oh cavolo, ho dimenticato di rispondere a quella mail”.

Memoria e contesto

Il sistema di memoria è uno dei punti di forza:

  • MEMORY.md: memoria a lungo termine, caricata solo nelle sessioni principali
  • memory/YYYY-MM-DD.md: log giornalieri di cosa è successo
  • AGENTS.md: convenzioni e regole per il comportamento degli agenti
  • HEARTBEAT.md: task periodiche da eseguire

Questo approccio file-based è elegante: sopravvive ai restart, è versionabile, ed è trasparente.

Modelli LLM e costi

Un punto che è cambiato parecchio nelle ultime settimane è il tema costi. All’inizio ho usato OpenRouter a consumo, testando modelli diversi (inclusi modelli più “pesanti”) e poi stabilizzandomi su Kimi K2.5.

Kimi, lato qualità, ha lavorato bene. Il problema è emerso sul piano economico: dall’export OpenRouter risulta che, nel mio periodo iniziale di utilizzo, solo Kimi K2.5 è costato 31,71$. Per il mio utilizzo reale, quindi quotidiano e non sporadico, il pay-per-use si è rivelato poco sostenibile.

Da pay-per-use a flat monthly

A quel punto ho iniziato a cercare alternative con due vincoli chiari:

  • costo prevedibile (abbonamento flat)
  • requisiti di privacy compatibili con il mio setup

Alternative valutate

  • Claude Code: non è una strada praticabile in questo scenario, perché l’uso che mi serve andrebbe in conflitto con i termini e condizioni.
  • Ollama Cloud: servizio cloud con accesso a vari modelli (incluso Kimi K2.5) in formula ad abbonamento, circa 20€/mese. Interessante sulla carta, ma nei miei test le performance sono state troppo lente rispetto a quanto mi serve nel flusso quotidiano.
  • Syntetic.new: progetto promettente orientato a workflow AI/coding più strutturati. L’ho messo nel radar, ma al momento è disponibile solo tramite waitlist.
  • Kimi Code (18€/mese): prezzo molto competitivo, ma l’infrastruttura passa da server cinesi e questo non è allineato ai miei requisiti di privacy.

Compromesso attuale

Ad oggi il compromesso più sensato è ChatGPT Plus con Codex a 20€/mese: costo fisso, prestazioni adeguate e un equilibrio migliore tra qualità, prevedibilità della spesa e requisiti operativi.

Fino ad ora, guardando l’export OpenRouter, la spesa complessiva è stata di 44,16$, di cui 31,71$ attribuiti a Kimi K2.5: numeri che confermano quanto sia difficile mantenere sostenibile un modello interamente a consumo nel mio caso d’uso quotidiano.

Considerazioni su privacy

Non potevo non valutare l’aspetto security:

  • I dati dell’assistente rimangono in locale per tutta la parte di orchestrazione
  • Le API key vengono gestite con i tool nativi, senza workaround improvvisati
  • Il sistema di agenti può operare in sandbox isolate
  • La comunicazione con i provider esterni (Telegram, ecc.) usa le API ufficiali

Quando uso OpenRouter, una leva importante resta la Zero Data Retention (ZDR): permette di indirizzare le richieste solo verso provider che dichiarano di non conservare i prompt. È un livello di protezione utile, ma va sempre bilanciato con disponibilità del modello, performance e costi.

Sicurezza: non basta il prompt, serve architettura

Una delle cose più interessanti che ho aggiunto al mio setup non riguarda firewall o reverse proxy, ma la separazione dei compiti in base al livello di fiducia dell’input.

La prima cosa che ho iniziato a prendere sul serio è stata l’importanza di openclaw security audit --deep. La documentazione ufficiale di OpenClaw su security lo consiglia come controllo regolare dopo ogni cambiamento significativo di configurazione, esposizione di rete, plugin o superfici di input. Nel mio caso è diventato parte della checklist pratica, perché aiuta a individuare footgun molto concreti prima che diventino un problema.

Per rafforzare questa parte ho aggiunto anche la skill skill-vetter, utile per dare un’occhiata più critica alle skill installate o candidate, invece di trattarle come innocui pezzetti di prompt. Plugin e skill, in un sistema del genere, vanno considerati per quello che sono: estensioni del perimetro di fiducia.

Il punto, però, è più ampio: con un assistente come OpenClaw il rischio non è solo “chi può scrivermi”, ma anche cosa l’agente legge. Pagine web, forum, email, documenti, allegati e risultati di ricerca possono diventare vettori di prompt injection, soprattutto quando l’agente ha accesso a tool potenti, memoria persistente o automazioni. Qui le linee guida OWASP su AI Agent Security e LLM Prompt Injection Prevention sono molto utili perché insistono su alcuni principi semplici ma solidi: minimo privilegio, separazione tra tool e trust level, contenuti esterni trattati come non fidati, protezione della memoria da poisoning e supervisione umana sulle azioni più sensibili.

Come baseline operativa ho preso spunto anche dalla checklist pubblicata da SouthSea Automation: OpenClaw Security Checklist. Non la considero la fonte definitiva — per quello mi affido prima alla documentazione ufficiale — ma l’ho trovata utile come checklist operativa rapida. In particolare ho applicato con attenzione il punto 5, SOUL.md — Hard Boundaries: definire limiti espliciti su cosa l’assistente può o non può fare, quando deve chiedere conferma, cosa non deve mai inviare o promuovere a memoria, e quali confini non deve attraversare nemmeno se una fonte esterna prova a persuaderlo del contrario.

A quel punto la scelta naturale è stata creare una separazione più netta tra gli agenti. Ho diviso il setup in due livelli:

  • Principale, l’assistente con memoria, contesto personale, decisioni e risposte finali;
  • Scout 🛰️, un secondo agente più ristretto, dedicato a leggere contenuti esterni, fare ricerca, monitorare fonti e svolgere task automatici piccoli e delimitati.

L’idea è semplice: l’agente che legge contenuti non fidati non deve essere lo stesso che custodisce la memoria personale o può agire con troppi privilegi. Scout filtra, riassume ed estrae i fatti; Principale usa solo il distillato finale e decide cosa vale davvero la pena ricordare o trasformare in azione.

Ho aggiunto anche regole esplicite di memory hygiene:

  • niente promozione automatica di contenuti esterni a memoria lunga;
  • in MEMORY.md finiscono solo preferenze, decisioni e contesto operativo verificato;
  • le automazioni che leggono fonti esterne devono restare piccole, specializzate e senza possibilità di allargare da sole il proprio perimetro.

In pratica, la vera difesa non è un prompt più severo, ma un’architettura che limita i danni quando qualcosa va storto. Non sto cercando di rendere l’agente impossibile da ingannare: sto cercando di fare in modo che, quando viene ingannato, abbia meno spazio per fare danni.

Conclusioni

OpenClaw è un progetto ambizioso che punta a portare gli assistenti AI nel mondo self-hosted e privacy-focused. Non è ancora perfetto, ma l’architettura è solida e la community attiva.

Il concetto di “assistente personale” finalmente inizia a somigliare a qualcosa di utile, non solo a un chatbot che risponde a domande. E averlo sul proprio hardware, con il proprio controllo, fa tutta la differenza.

Se vuoi saperne di più sul progetto: github.com/openclaw/openclaw