Tag Archivio per: agenti AI

Ogni mattina, in migliaia di caselle di posta, arriva la stessa email: tre risultati di Google Alerts, due dei quali duplicati e uno completamente fuori tema. Nel frattempo un agente AI potrebbe aver già letto centinaia di fonti, scartato il rumore e preparato una sintesi leggibile in trenta secondi. È la domanda che mi sento fare sempre più spesso da chi si occupa di comunicazione, SEO o brand reputation: ha ancora senso usare Google Alerts quando esistono motori di ricerca basati sull’intelligenza artificiale e veri agenti autonomi capaci di monitorare il web al posto nostro?

La risposta breve è: dipende da cosa dobbiamo monitorare, da quanto in fretta ci serve saperlo e da quanto siamo disposti a delegare. La risposta lunga richiede di capire come funziona oggi Google Alerts, dove si ferma, e che cosa cambia davvero con i motori AI e con gli agenti.

Che cos’è rimasto di Google Alerts nel 2026

Google Alerts nasce come strumento semplice: si imposta una query, si sceglie la frequenza (in tempo reale, una volta al giorno, una volta alla settimana) e si ricevono email quando compaiono nuovi risultati pertinenti su Ricerca Google. Il funzionamento, spiegato nella guida ufficiale di Google, non è cambiato di molto rispetto a quando lo strumento fu lanciato: resta gratuito, immediato da configurare, ma anche piuttosto rigido.

Negli anni Google ha investito pochissimo su questo prodotto. Non si integra con AI Overviews o con AI Mode, non distingue una menzione positiva da una negativa, non raggruppa le notizie per argomento, non impara dalle correzioni. È rimasto, di fatto, fermo a un’epoca precedente ai motori di ricerca conversazionali.

I limiti reali di Google Alerts oggi

  • Copertura parziale delle fonti. Fatica a coprire bene social network, forum verticali, gruppi Telegram o Facebook, marketplace: proprio i luoghi dove nascono molte crisi reputazionali.
  • Ritardo variabile. Anche in modalità “in tempo reale” possono passare ore o giorni prima che un contenuto già indicizzato generi una notifica.
  • Duplicati e rumore. La stessa notizia ripresa da decine di aggregatori riempie la casella di posta di link quasi identici.
  • Nessuna sintesi né priorità. Lo strumento non dice se una menzione è rilevante, virale o pericolosa: il lavoro di lettura e selezione resta interamente umano.
  • Nessuna azione. Si limita a notificare: non propone una risposta, non avvisa un collega, non aggiorna un foglio di lavoro, non apre un ticket.

Un esempio concreto: un’agenzia che monitora le menzioni di un brand riceve anche quaranta email al giorno, di cui solo tre davvero rilevanti, e nonostante questo si accorge in ritardo di una discussione nata su Reddit, perché quel tipo di fonte non viene intercettato con la stessa rapidità di una testata giornalistica.

Che cosa cambia con i motori di ricerca basati sull’AI

Con AI Overviews e AI Mode, Google non si limita più a restituire dieci link blu: costruisce una sintesi che cita le fonti. Strumenti come Perplexity vanno nella stessa direzione, ma capovolgono l’approccio di Alerts: invece di aspettare una notifica, si fa una domanda diretta e si ottiene una risposta aggiornata con le fonti citate. Nel mio articolo su come ho usato Perplexity per una ricerca mirata il principio è lo stesso applicato a un altro obiettivo: interrogare, non aspettare.

Questo cambiamento non riguarda solo come cerchiamo le informazioni, ma anche come veniamo trovati. Se le risposte AI sintetizzano il web al posto dell’utente, capire come il proprio brand o i propri contenuti vengono citati in quelle risposte diventa una nuova forma di monitoraggio, quella che nel mio approfondimento su SEO, GEO e AEO descrivo come necessità di ottimizzare non solo per l’algoritmo di ranking, ma per il modo in cui un modello linguistico riassume e cita le fonti.

Che cosa cambia davvero con gli agenti AI

I motori di ricerca AI rispondono a una domanda quando la facciamo. Un agente va oltre: lavora su un programma, consulta più fonti in autonomia, incrocia i dati, scarta il rumore, scrive una sintesi e, se lo abilitiamo, compie un’azione, come inviare un’email o aggiornare una tabella. È qui che la faccenda si fa interessante, e anche più delicata.

Più un agente passa dal “dire” al “fare”, più serve decidere quanto controllo umano mantenere. Nel mio articolo su human-in-the-loop e human-on-the-loop entro nel dettaglio di questa distinzione: per una sintesi giornaliera delle menzioni può bastare un supervisore che controlla a campione (on-the-loop), ma se l’agente deve rispondere pubblicamente a una recensione negativa, quel passaggio dovrebbe restare sotto approvazione umana (in-the-loop).

Quattro esempi pratici di monitoraggio con agenti AI

  • Rassegna stampa quotidiana automatica. L’agente legge decine di fonti ogni mattina, produce una sintesi con priorità e sentiment, e segnala alla persona solo le anomalie reali, invece di scaricare tutto il lavoro di lettura sull’utente.
  • Monitoraggio prezzi e attività dei concorrenti. L’agente controlla ogni giorno pagine e listini, e avvisa solo quando c’è una variazione significativa, non a ogni minima modifica del codice HTML.
  • Social listening esteso. L’agente copre Reddit, forum di settore, gruppi pubblici e community verticali che Google Alerts intercetta con difficoltà o in ritardo.
  • Monitoraggio della propria presenza nelle risposte AI. L’agente interroga periodicamente ChatGPT, Perplexity e AI Overviews con le domande tipiche del proprio settore, per verificare se e come il brand viene citato: un controllo che nessun Alert tradizionale può fare, perché non guarda “dentro” la risposta generata dal modello.

Per chi deve poi mettere in relazione documenti diversi raccolti durante il monitoraggio, come rassegne stampa, PDF e screenshot, uno strumento come Gemini Notebook può aiutare a incrociare fonti eterogenee invece di leggerle una per una.

Google Alerts, motori AI e agenti a confronto

Aspetto Google Alerts Motori di ricerca AI Agenti AI di monitoraggio
Copertura fonti Limitata, soprattutto su social e forum Ampia, ma legata al momento della domanda Ampia e programmabile su misura
Tempestività Da ore a giorni Immediata, ma solo su richiesta Continua, secondo la frequenza impostata
Sintesi e priorità Assente Buona sulla singola risposta Costruita su misura, con soglie e priorità
Azioni automatiche Nessuna Nessuna, resta conversazionale Possibili, da presidiare con attenzione
Costo Gratuito Gratuito o abbonamento Tempo di configurazione o costo del servizio
Controllo richiesto Minimo Minimo Da progettare (in-the-loop o on-the-loop)

Quando ha ancora senso usare Google Alerts

Non tutto merita un agente. Per un uso personale, per un tema poco competitivo, per un primo filtro gratuito su un argomento che non è ancora una priorità, Google Alerts resta uno strumento onesto: costa zero, si imposta in due minuti e, come rete a maglie larghe, qualcosa la intercetta comunque. Il problema nasce quando lo si usa come unico strumento per la reputazione di un brand, per la sicurezza di un’azienda o per capire in tempo reale una crisi in corso: lì il divario con motori AI e agenti diventa evidente, come racconto anche nella guida su come gestire la reputazione online, dove il monitoraggio è solo il primo passo di un processo più ampio.

Come costruire oggi un sistema di monitoraggio ibrido

  • Definire cosa conta davvero. Nome del brand, prodotti, dirigenti, hashtag, concorrenti diretti: non tutto merita lo stesso livello di attenzione.
  • Tenere Google Alerts come rete di base gratuita. Non va abbandonato, va ridimensionato al ruolo che può davvero sostenere.
  • Affiancare un motore AI per le domande puntuali. Utile quando serve una risposta rapida su un tema specifico, non una sorveglianza continua.
  • Costruire o adottare un agente per le fonti scoperte. Social, forum e community restano il punto debole di Alerts e il punto di forza di un agente ben configurato.
  • Scegliere il livello di supervisione giusto. Sintesi giornaliera in modalità on-the-loop, approvazione umana obbligatoria per ogni azione pubblica o sensibile.
  • Misurare che cosa si sarebbe perso. Confrontare periodicamente i risultati di Alerts con quelli dell’agente aiuta a capire quanto valore reale aggiunge il cambio di strumento.

Domande frequenti

Google Alerts è ormai inutile?

No, ma da solo non basta più per chi ha bisogno di rapidità, copertura ampia o sintesi. Resta valido come rete gratuita di base per temi a bassa priorità.

Gli agenti AI sostituiscono completamente Google Alerts?

Possono coprire molti dei suoi limiti, ma vanno progettati con attenzione: senza soglie, log e supervisione rischiano di generare falsi allarmi o azioni indesiderate.

Serve saper programmare per costruire un agente di monitoraggio?

Non sempre: esistono strumenti e piattaforme che permettono di collegare fonti, regole di sintesi e notifiche senza scrivere codice, anche se una configurazione più su misura richiede competenze tecniche.

Google Alerts copre bene i social network?

No, è uno dei suoi limiti più noti: social, forum e gruppi privati vengono intercettati in modo parziale e spesso in ritardo rispetto a siti di informazione indicizzati.

Qual è il rischio principale nel delegare il monitoraggio a un agente?

Perdere il controllo su ciò che l’agente fa in autonomia. Per questo conviene distinguere sempre tra un ruolo di supervisione (on-the-loop) e uno di approvazione obbligatoria (in-the-loop) per le azioni più delicate.

La domanda giusta non è più “Alerts sì o no”

Google Alerts non è morto, ma nel 2026 ha smesso di essere sufficiente da solo. Ha ancora senso quando serve un primo filtro gratuito su un tema semplice; ne ha molto meno quando in gioco ci sono la reputazione di un brand, la velocità di reazione o la comprensione di come l’intelligenza artificiale parla di noi. La domanda giusta non è più se usare Alerts, ma quale combinazione di motori AI, agenti e supervisione umana meriti la nostra attenzione, che resta la risorsa più limitata di tutte.

Aggiornato al 18 luglio 2026. Un video TikTok di un minuto presenta cinque skill per Claude che promettono di migliorare scrittura, memoria, progettazione di interfacce, osservazione dei task e ricerca di altre skill. Le ho verificate una per una: sono progetti reali, ma non sono componenti ufficiali di Anthropic e non vanno installati come se fossero semplici prompt. Una skill può contenere istruzioni, script e accessi a strumenti: in pratica è codice operativo che entra nel flusso di lavoro dell’agente.

Il video di @ozzibig, intitolato “5 skill di Claude che il 99% delle persone non conosce”, cita Stop Slop, Claude Mem, UI UX Pro Max, Task Observer e Find Skill. L’elenco è interessante perché mostra cinque direzioni in cui si stanno evolvendo gli assistenti agentici. Il punto, però, non è collezionare estensioni: è capire che cosa fanno davvero, quali dati toccano e quanto ci si può fidare.

Che cosa sono le skill per Claude?

Le Agent Skills sono cartelle organizzate che forniscono a un agente istruzioni, risorse e, in alcuni casi, script eseguibili per svolgere un compito specializzato. Anthropic le descrive come moduli caricabili in modo progressivo: l’agente legge prima una descrizione sintetica e approfondisce la skill quando diventa pertinente. La documentazione ufficiale è disponibile nel manuale di Claude, nell’articolo tecnico “Equipping agents for the real world with Agent Skills” e nel repository pubblico di Anthropic.

Il formato non riguarda soltanto Claude. La specifica aperta Agent Skills punta alla portabilità tra strumenti diversi. È un passaggio importante: non stiamo più parlando di una frase salvata nel cassetto dei prompt, ma di un piccolo pacchetto di competenze riusabile da un agente.

Una distinzione evita molti equivoci:

  • prompt: dice al modello come rispondere in una determinata situazione;
  • skill: organizza istruzioni, file di supporto e talvolta automazioni o comandi;
  • connettore o tool: consente all’agente di leggere o modificare sistemi esterni;
  • agente: decide quali passaggi eseguire e può combinare più skill e strumenti.

Più si scende nell’elenco, più aumenta la capacità di agire. E con la capacità aumenta anche la superficie di rischio.

Le cinque skill del video, a colpo d’occhio

Skill Che cosa fa A chi può servire Dato o permesso delicato Rischio da valutare
Stop Slop Individua e riduce formule stereotipate della prosa generata dall’AI Autori, marketer, formatori, redazioni Testi e documenti sottoposti alla revisione Uniformare troppo la voce o confondere stile con veridicità
Claude Mem Conserva e recupera memoria tra sessioni Sviluppatori e team su progetti lunghi Contesto, attività e cronologia delle sessioni Privacy, retention e contaminazione tra progetti
UI UX Pro Max Propone stili, palette, font e regole per interfacce Designer, sviluppatori front-end, prototipatori Codice del progetto e requisiti di prodotto Design plausibile ma non testato con utenti o tecnologie assistive
Task Observer Osserva correzioni e lacune, poi propone miglioramenti alle skill Utenti avanzati che mantengono molte automazioni Log, errori, feedback e comportamenti ripetuti Trasformare un errore occasionale in una regola permanente
Find Skill Cerca skill in più cataloghi e può facilitarne l’installazione Chi esplora l’ecosistema di agenti Accesso a fonti esterne e installazione di pacchetti Supply chain: trovare più velocemente anche componenti insicuri

1. Stop Slop: ripulire la scrittura AI senza fingere che diventi “umana”

Stop Slop è una skill con licenza MIT che cerca segnali ricorrenti della scrittura artificiale: aperture generiche, contrasti costruiti in serie, enfasi eccessiva, conclusioni gonfie e frasi che sembrano autorevoli senza aggiungere informazione.

Immaginiamo una responsabile marketing che debba rivedere quindici schede prodotto. La skill può segnalare espressioni come “nel panorama in continua evoluzione” o una sequenza di paragrafi tutti costruiti nello stesso modo. La persona decide che cosa tagliare, verifica i dati e reinserisce esempi reali. Qui la skill funziona bene come editor di primo livello, non come certificatore di autenticità.

Altri casi concreti:

  • un consulente confronta una proposta commerciale con le proprie linee editoriali;
  • un insegnante fa individuare agli studenti le formule vaghe in una relazione;
  • una redazione usa il controllo prima della revisione umana, senza affidargli la decisione finale;
  • un ufficio HR elimina il linguaggio magniloquente da un annuncio di lavoro.

Il limite è semplice: un testo meno stereotipato non diventa automaticamente corretto, originale o scritto da una persona. Stop Slop non sostituisce fact-checking, competenza editoriale e controllo delle fonti. E usarlo per “battere i detector” sarebbe una promessa impropria: i detector di testo AI sono notoriamente fallibili e lo stile non prova l’origine di un contenuto.

2. Claude Mem: una memoria utile, quindi anche delicata

Claude Mem, distribuito con licenza Apache 2.0, aggiunge memoria persistente alle sessioni di lavoro. Registra osservazioni, le comprime e permette di recuperare il contesto rilevante in un secondo momento. L’obiettivo è evitare la scena che conoscono tutti: riaprire un progetto e dover spiegare da capo architettura, decisioni e problemi già risolti.

Per uno sviluppatore può significare ricordare che l’applicazione usa un certo schema dati, che una libreria è stata scartata per incompatibilità e che una determinata cartella non va modificata. Per un team di comunicazione potrebbe voler dire conservare terminologia approvata, pubblico, vincoli legali e decisioni prese durante le revisioni.

La memoria, però, è utile proprio perché trattiene informazioni. Prima di adottarla occorre chiedersi:

  • dove vengono archiviati i dati e per quanto tempo;
  • quali conversazioni, file e comandi vengono catturati;
  • come si cancellano o esportano i ricordi;
  • se progetti e clienti diversi restano davvero separati;
  • che cosa succede a credenziali, dati personali e segreti comparsi per errore.

La ricerca sui Generative Agents ha mostrato quanto memoria, riflessione e pianificazione possano rendere più coerente il comportamento di un agente. In un contesto aziendale, però, coerenza non significa automaticamente conformità: servono minimizzazione dei dati, separazione degli ambienti e una politica di conservazione.

Se ti interessa il tema della memoria personale e professionale, ho approfondito un approccio diverso nell’articolo su come creare un second brain con LLM, wiki e Obsidian.

3. UI UX Pro Max: molte opzioni non equivalgono a buon design

UI UX Pro Max è un progetto MIT che raccoglie conoscenza strutturata per progettare interfacce. Al momento della verifica il repository dichiara 84 stili, 161 regole di reasoning, 192 categorie di prodotto e palette, 34 modelli di landing page e 74 coppie tipografiche. Sono numeri dichiarati dal maintainer e descrivono il contenuto del progetto, non una valutazione indipendente della qualità dei risultati.

In pratica può aiutare una piccola impresa a trasformare un brief vago — “vorrei un sito moderno” — in decisioni più concrete: gerarchia, palette, tipografia, componenti, spaziature e stati di interazione. Un prototipatore può chiederle una dashboard per un amministratore di condominio; uno sviluppatore può usarla per controllare coerenza e responsive design; una startup può generare tre direzioni visive prima del confronto con il designer.

Il rischio è produrre un’interfaccia molto credibile in una schermata e poco usabile nella realtà. La skill non conosce automaticamente gli utenti, il loro contesto, le metriche di conversione o le esigenze di chi utilizza uno screen reader. Deve quindi entrare in un processo che includa test, analytics e Web Content Accessibility Guidelines.

Un esempio: il sistema propone testo grigio chiaro, animazioni e menu nascosti perché coerenti con uno stile minimal. Il designer verifica contrasto, navigazione da tastiera e comprensione dei comandi. La skill accelera l’esplorazione; la responsabilità sul prodotto resta umana.

4. Task Observer: l’agente che osserva come migliorare l’agente

Nel repository One Skill to Rule Them All la skill si chiama task-observer. Osserva correzioni, errori e schemi ricorrenti, poi formula raccomandazioni per creare o aggiornare altre skill. Un dettaglio importante: secondo la documentazione non modifica direttamente le skill, ma propone cambiamenti che devono essere approvati.

Può essere utile quando un team ripete ogni settimana la stessa correzione. Per esempio:

  • un report usa sempre il formato di data sbagliato;
  • le bozze citano una fonte secondaria quando è disponibile il paper originale;
  • un agente dimentica il controllo degli accenti prima di pubblicare in italiano;
  • un flusso di sviluppo esegue test generici ma trascura un caso limite ricorrente.

La skill può trasformare il feedback in una proposta stabile: “aggiungiamo questo controllo alla procedura”. È una forma di miglioramento operativo interessante, ma va governata. Una correzione fatta per un cliente non deve diventare una regola universale; un’eccezione non deve contaminare tutti i progetti; i log non devono raccogliere più dati del necessario.

Il README dichiara oltre 900 miglioramenti su 50 skill in sei mesi. È un dato del maintainer, non il risultato di uno studio indipendente: utile per capire il caso d’uso, non per misurare l’efficacia generale.

5. Find Skill: il motore di ricerca che rende decisiva la sicurezza

Find Skill cerca skill in più fonti e dichiara un indice di oltre 4.800 risorse provenienti da 14 cataloghi, con supporto per Claude Code, Codex, OpenCode e Cursor. Anche questi numeri descrivono lo stato dichiarato dal progetto alla data della verifica e possono cambiare.

Il vantaggio è evidente. Un analista può cercare una procedura per lavorare con fogli di calcolo; un formatore una skill per costruire una presentazione; uno sviluppatore un controllo di sicurezza. Invece di partire da zero, riusa una soluzione esistente.

Ma il discovery non è una certificazione. Se una skill può essere installata con pochi comandi, diminuisce anche l’attrito che normalmente ci spinge a ispezionarla. È lo stesso problema della supply chain software: un componente di terze parti può contenere dipendenze vulnerabili, istruzioni malevole o accessi eccessivi. Il catalogo skills.sh e il relativo progetto open source di Vercel Labs sono altre risorse utili per la scoperta, ma anche in quel caso ogni pacchetto va valutato singolarmente.

Una skill non è un prompt innocuo: quali rischi introduce?

Un agente può leggere documenti, eseguire script, usare la rete e modificare file. Una skill male progettata può quindi amplificare un errore o una manipolazione. L’OWASP Top 10 per applicazioni LLM richiama rischi come prompt injection, gestione insicura degli output, eccessiva autonomia e vulnerabilità della supply chain.

Il paper “More than you’ve asked for: A Comprehensive Analysis of Novel Prompt Injection Threats to Application-Integrated Large Language Models” mostra il problema delle indirect prompt injection: istruzioni ostili possono nascondersi nei contenuti che il modello legge, non soltanto nel prompt scritto dall’utente. Un agente che consulta pagine web o documenti può quindi incontrare testo progettato per deviarne il comportamento.

Anche la qualità del codice generato richiede verifica. Gli studi “Asleep at the Keyboard?” e “Do Users Write More Insecure Code with AI Assistants?” non valutano queste cinque skill specifiche, ma documentano un principio più generale: l’assistenza AI può produrre o favorire codice insicuro, e la fiducia dell’utente non è una garanzia di correttezza.

I rischi principali sono cinque:

  1. permessi eccessivi: una skill di scrittura non dovrebbe avere accesso indiscriminato alla rete o a tutto il disco;
  2. esfiltrazione di dati: testi, log o credenziali potrebbero uscire dall’ambiente previsto;
  3. istruzioni nascoste: file o pagine consultati dall’agente possono tentare di modificarne il comportamento;
  4. dipendenze compromesse: il repository visibile può richiamare componenti esterni non controllati;
  5. automazione dell’errore: una procedura sbagliata diventa più veloce, coerente e difficile da notare.

Per questo il modello di supervisione conta. Nell’approfondimento su human-in-the-loop e human-on-the-loop negli agenti AI spiego quando chiedere un’approvazione prima dell’azione e quando è sufficiente monitorare un sistema reversibile entro soglie definite.

Come verificare una skill prima di installarla

Io adotterei questa procedura in sette passaggi. Non garantisce rischio zero, ma rende l’adozione tracciabile e molto meno impulsiva.

  1. Verifica identità e provenienza. Controlla autore, cronologia del repository, release, issue aperte, licenza e manutenzione recente. Il numero di stelle non è una certificazione.
  2. Leggi tutto il pacchetto. Non fermarti al README: esamina integralmente SKILL.md, script, dipendenze, hook e file di configurazione.
  3. Esegui una scansione statica. Un progetto dedicato è NVIDIA SkillSpector. Nel mio flusso una skill esterna non viene installata se la scansione non restituisce SAFE.
  4. Mappa permessi e dati. Scrivi quali cartelle può leggere, quali comandi esegue, se usa la rete, dove conserva i log e come tratta i segreti.
  5. Prova in isolamento. Usa un ambiente temporaneo, dati fittizi, credenziali senza privilegi e nessun accesso ai sistemi di produzione.
  6. Osserva il comportamento. Controlla file creati, richieste di rete, processi e output. Prova anche input anomali e documenti contenenti istruzioni ostili.
  7. Approva, limita e versiona. Installa una versione precisa, concedi il minimo indispensabile e prevedi aggiornamento, rollback e rimozione.

Nel caso di una skill di memoria aggiungerei un controllo su retention e separazione dei clienti. Per una skill che genera codice, test di sicurezza e code review. Per una skill di ricerca e installazione, l’approvazione umana prima di aggiungere qualsiasi nuovo pacchetto.

Quale delle cinque scegliere? Cinque scenari pratici

Scenario 1: libero professionista che scrive contenuti

Stop Slop può diventare l’ultimo controllo prima della revisione manuale. Non serve Claude Mem se si trattano clienti diversi senza una strategia chiara di separazione. La priorità è proteggere bozze, dati e tono personale.

Scenario 2: team software su un prodotto complesso

Claude Mem può ridurre la perdita di contesto e Task Observer può rilevare correzioni ricorrenti. Ma entrambi lavorano su informazioni sensibili: vanno testati su un repository non critico, con segreti esclusi e supervisione degli aggiornamenti proposti.

Scenario 3: agenzia che produce molti prototipi

UI UX Pro Max può accelerare moodboard, design system iniziali e alternative di landing page. Il passaggio successivo deve includere designer, verifica WCAG, test con utenti e dati reali. Non si pubblica soltanto perché la prima schermata “sembra fatta bene”.

Scenario 4: formatore che prepara materiali

Find Skill può scoprire pacchetti per documenti, fogli e slide. La procedura corretta è cercare, selezionare due candidati, leggerli e scansionarli; non installare automaticamente il primo risultato davanti a una classe o su un computer aziendale.

Scenario 5: impresa con processi regolati

Nessuna delle cinque skill dovrebbe entrare direttamente in produzione. Prima servono responsabile del processo, classificazione dei dati, ambiente di prova, log, soglie di autonomia e un piano di risposta agli incidenti. L’utilità potenziale non elimina gli obblighi organizzativi.

Tre video per vedere Claude al lavoro

Le skill acquistano senso quando vengono collegate a un’attività concreta. In questi miei video mostro come Claude passa dalla conversazione al lavoro su documenti e procedure:

Per approfondire puoi leggere anche i tre esempi d’uso di Claude Cowork, la guida su Claude Cowork e la compilazione dei moduli e la pagina del mio corso su Claude per aziende e professionisti.

La vera competenza non è accumulare skill

Il video intercetta una tendenza reale: gli assistenti stanno diventando ambienti componibili. Possiamo aggiungere memoria, procedure editoriali, capacità di progettazione e persino meccanismi che osservano come lavoriamo. È un salto utile, ma cambia anche il modo in cui dobbiamo valutare questi strumenti.

La domanda meno interessante è “quante skill hai installato?”. Quelle importanti sono: chi le ha scritte, che cosa possono fare, quali dati vedono, come vengono aggiornate e chi approva un’azione irreversibile.

Una buona skill riduce lavoro ripetitivo e rende esplicito un metodo. Una cattiva skill rende più efficiente un rischio. La differenza non la fa il nome accattivante del repository, ma la qualità della verifica prima dell’installazione e della supervisione durante l’uso.

Domande frequenti

Le cinque skill del video sono ufficiali di Anthropic?

No. Stop Slop, Claude Mem, UI UX Pro Max, Task Observer e Find Skill sono progetti di terze parti. Anthropic mantiene documentazione, specifiche e un proprio repository pubblico di skill, ma la presenza su GitHub non equivale a un’approvazione ufficiale.

Qual è la migliore skill per Claude?

Dipende dal problema. Stop Slop è orientata alla revisione stilistica, Claude Mem alla continuità tra sessioni, UI UX Pro Max al design, Task Observer al miglioramento delle procedure e Find Skill alla scoperta. La scelta deve considerare valore, dati trattati, permessi e reversibilità.

Una skill per Claude può essere pericolosa?

Sì. Se include script, usa la rete, legge file o installa altri pacchetti, può introdurre rischi di prompt injection, esfiltrazione, dipendenze compromesse o modifiche indesiderate. Va ispezionata e provata in isolamento prima dell’uso reale.

Che cos’è SkillSpector?

SkillSpector è uno strumento open source di NVIDIA per l’analisi statica delle skill degli agenti. Aiuta a individuare pattern sospetti prima dell’installazione, ma non sostituisce la lettura del codice, la limitazione dei permessi e i test in sandbox.

Claude Mem è adatto a documenti riservati?

Non va deciso in astratto. Prima occorre verificare archiviazione, retention, accessi, cancellazione, separazione dei progetti e policy aziendali. Per documenti riservati è prudente iniziare con dati fittizi e coinvolgere chi gestisce privacy e sicurezza.

Le skill sostituiscono la supervisione umana?

No. Rendono un agente più specializzato, ma non garantiscono correttezza. Per azioni ad alto impatto, dati sensibili o modifiche difficili da annullare è opportuno mantenere un’approvazione umana esplicita e log verificabili.

Scrivimi per organizzare un evento o un corso sull’intelligenza artificiale generativa

Mandami un WhatsApp al 339.6325418 per organizzare un corso o una conferenza sull’A.I. generativa.

Invia un’email

Un agente AI prepara una risposta a un cliente, aggiorna il CRM, modifica un file, apre una richiesta di rimborso e programma l’invio di un’email. A quale passaggio deve fermarsi e chiedere il permesso? E quando, invece, può continuare mentre una persona controlla dall’alto?

È qui che entra in gioco la differenza tra human-in-the-loop e human-on-the-loop, IN da una parte e ON dall’altra. Nel primo modello l’essere umano è un passaggio obbligatorio del processo: senza la sua approvazione l’azione non parte. Nel secondo l’agente lavora in autonomia entro limiti prestabiliti, mentre una persona osserva indicatori, controlla campioni e può intervenire o fermare il sistema. Non è una scelta ideologica tra controllo e libertà: dipende dal rischio, dalla reversibilità dell’azione e dalla capacità di accorgersi in tempo di un errore.

La distinzione è particolarmente importante nei sistemi agentici usati in azienda. Un chatbot propone parole; un agente può usare strumenti e produrre effetti nel mondo: inviare, acquistare, modificare, pubblicare, cancellare. Più l’AI passa dal “dire” al “fare”, più occorre progettare con precisione il ruolo umano.

Che cosa significa human-in-the-loop

Human-in-the-loop (HITL) significa che una persona è dentro il flusso operativo. L’agente può analizzare dati, formulare una proposta o preparare un’azione, ma incontra un punto di controllo obbligatorio. L’umano approva, corregge o respinge; soltanto dopo il sistema può proseguire.

È il modello adatto quando una decisione può produrre conseguenze economiche, legali, sanitarie, reputazionali o difficili da annullare. Non basta mostrare un pulsante “Approva”: la persona deve ricevere il contesto necessario, avere tempo sufficiente e poter davvero cambiare la decisione.

Un esempio semplice: l’agente legge un reclamo, consulta l’ordine e propone un rimborso di 280 euro. In modalità human-in-the-loop il responsabile vede motivazione, dati usati e importo, poi autorizza o modifica l’operazione. Il sistema non trasferisce denaro da solo.

Che cosa significa human-on-the-loop

Human-on-the-loop (HOTL) significa che una persona supervisiona il processo senza approvare ogni singola azione. L’agente opera entro un perimetro definito; dashboard, registri, avvisi e controlli a campione permettono al supervisore di capire che cosa sta succedendo e intervenire in caso di anomalia.

È adatto ad attività frequenti, a rischio contenuto, misurabili e facilmente reversibili. L’autonomia non elimina il controllo: lo sposta dalla singola operazione alla qualità complessiva del sistema.

Per esempio, un agente classifica ogni notte centinaia di documenti interni. Il responsabile non conferma ogni etichetta, ma controlla un campione, osserva il tasso di errore e riceve un avviso se cresce oltre la soglia. Le classificazioni restano tracciate e correggibili.

Human-in-the-loop vs human-on-the-loop: la differenza in tabella

Aspetto Human-in-the-loop Human-on-the-loop
Ruolo umano Approva o corregge prima dell’azione Supervisiona il sistema mentre opera
Flusso predefinito L’agente si ferma L’agente continua
Controllo Su ogni caso sensibile Su metriche, anomalie e campioni
Velocità Più bassa e legata alla disponibilità umana Più alta e scalabile
Uso tipico Decisioni ad alto impatto o poco reversibili Attività a basso rischio, osservabili e reversibili
Rischio principale Approvazioni frettolose e “fatica da conferma” Accorgersi troppo tardi di una deriva
Strumenti necessari Gate, spiegazioni, confronto e possibilità di rifiuto Log, soglie, alert, audit e arresto immediato

Attenzione: on-the-loop non significa out-of-the-loop

Esiste una terza condizione: human-out-of-the-loop. L’AI decide e agisce senza approvazione puntuale, senza supervisione operativa efficace o senza una reale possibilità di intervento. Non è un sinonimo di human-on-the-loop.

La differenza sembra sottile finché non arriva un incidente. Se il supervisore riceve un report il giorno dopo, quando l’agente ha già inviato mille comunicazioni sbagliate, non era davvero “sopra il circuito”: era fuori dal circuito.

Il tema è noto da molto prima dell’AI generativa. Nel paper “Ironies of automation” del 1983, Lisanne Bainbridge osservava un paradosso ancora attuale: più il sistema automatizza il lavoro ordinario, più alla persona restano i casi rari e difficili, proprio quelli per cui è complicato mantenere allenamento e consapevolezza. Mica Endsley ha poi analizzato il problema nel lavoro “From Here to Autonomy”, collegandolo alla perdita di consapevolezza situazionale quando l’essere umano viene allontanato troppo dal processo.

La matrice pratica: rischio, reversibilità, osservabilità e tempo

L’articolo di Bajara Notes da cui nasce questa riflessione propone un criterio molto concreto per i team di sviluppo: guardare il costo dell’errore e la reversibilità dell’azione. È una buona base, che possiamo estendere a qualsiasi progetto agentico con quattro domande.

  1. Quanto è grave un errore? Una bozza imperfetta non equivale a un bonifico errato.
  2. L’azione è reversibile? Rinominare un file con cronologia è diverso dal cancellare dati o inviare una comunicazione pubblica.
  3. L’errore è osservabile? Possiamo accorgercene con test, metriche o controlli automatici?
  4. Quanto tempo abbiamo per intervenire? Un alert utile dopo un’ora può essere inutile in un processo che produce danni in pochi secondi.
Rischio e reversibilità Modello consigliato Esempio
Basso rischio, facile annullamento Human-on-the-loop Ordinare documenti interni con cronologia delle modifiche
Rischio medio, errore rilevabile prima dell’impatto On-the-loop con soglie ed escalation Aggiornare campi non critici del CRM e isolare i casi incerti
Rischio alto o annullamento costoso Human-in-the-loop Concedere un rimborso, pubblicare un listino, inviare un contratto
Impatto critico o irreversibile Più controlli umani e separazione dei ruoli Pagamento, terapia, rilascio in produzione o decisione sul personale

Otto esempi concreti di human-in-the-loop

1. Email a clienti e comunicazioni pubbliche

L’agente raccoglie i dati, prepara il testo e suggerisce i destinatari. Una persona verifica tono, fatti, allegati e lista di invio. È un controllo necessario soprattutto per crisi, reclami, variazioni di prezzo e comunicazioni legali.

2. Rimborsi, pagamenti e ordini

L’AI può controllare policy e documenti, ma l’azione che muove denaro richiede autorizzazione. Si può introdurre una soglia: piccoli rimborsi standardizzati vengono gestiti automaticamente; quelli anomali o sopra un importo definito arrivano a un responsabile.

3. Selezione del personale

Un agente può riordinare candidature e mettere in evidenza competenze dichiarate. Non dovrebbe trasformare un punteggio opaco in un rifiuto automatico. Il recruiter deve poter vedere i dati usati, correggere il risultato e valutare elementi che il sistema non conosce.

4. Sanità e percorsi di cura

L’AI può segnalare una possibile anomalia o preparare un riepilogo clinico; diagnosi e terapia richiedono giudizio professionale. Nel mio approfondimento su AI e ruolo del medico il punto centrale è proprio questo: supporto e sostituzione non sono la stessa cosa.

5. Contratti e pareri legali

L’agente confronta clausole, segnala differenze e propone una bozza. Un professionista controlla interpretazione, giurisdizione e rischio prima che il documento venga condiviso o firmato.

6. Deploy e modifiche a database di produzione

L’agente può scrivere codice, test e documentazione in un ambiente isolato. Il passaggio in produzione, una migrazione di dati o la modifica di credenziali richiedono un gate umano, spesso con una seconda approvazione.

7. Decisioni su credito, assicurazioni e frodi

Il sistema può ordinare i casi per rischio. Se blocca un conto, rifiuta una pratica o modifica un premio, serve un riesame effettivo: non una firma automatica su un punteggio incomprensibile.

8. Pubblica amministrazione e servizi essenziali

Un agente può verificare la completezza di una domanda e preparare l’istruttoria. La decisione che incide su diritti, benefici o accesso a un servizio deve restare contestabile e attribuita a un responsabile. È un’applicazione concreta del tema affrontato nell’articolo sull’intelligenza artificiale nella Pubblica Amministrazione.

Otto esempi concreti di human-on-the-loop

1. Classificazione di documenti interni

L’agente assegna cartelle e metadati. Il supervisore controlla campioni settimanali e riceve un alert se aumenta la percentuale di documenti classificati con bassa confidenza.

2. Arricchimento del CRM in modalità reversibile

L’agente completa settore, dimensione e informazioni pubbliche sulle aziende, senza modificare campi critici. Ogni variazione è registrata e può essere annullata; i conflitti vengono inviati a una persona.

3. Preparazione di report ricorrenti

L’AI raccoglie dati da più fonti e genera una sintesi interna. Il responsabile non approva ogni report, ma controlla indicatori di qualità, citazioni e anomalie. Se il documento deve uscire dall’azienda, si aggiunge un gate.

4. Ricerca documentale con escalation

L’agente cerca informazioni, confronta fonti e produce una risposta con link verificabili. Se le fonti sono insufficienti o in conflitto, non improvvisa: chiede aiuto.

5. Sviluppo software in ambienti isolati

L’agente crea test, documentazione o componenti standard su un branch separato. La pipeline automatica controlla il codice e il team esamina le eccezioni. I permessi non includono il rilascio autonomo in produzione.

6. Assistenza clienti per domande standard

Il sistema risponde usando una base di conoscenza approvata, ma passa a un operatore reclami, minacce, richieste economiche, dati sensibili e casi con bassa confidenza. Il supervisore osserva tasso di escalation e correzioni.

7. Gestione di file e fogli di calcolo

Un agente riordina righe, normalizza formati e compila campi derivabili, lavorando su una copia o con cronologia attiva. La persona controlla il risultato complessivo e può ripristinare la versione precedente.

Nel blog trovi anche cinque esempi pratici dell’agente Genspark e una prova di Claude Cowork in tre attività concrete.

8. Monitoraggio tecnico e manutenzione

L’agente individua pattern insoliti, apre ticket e applica correzioni già approvate su sistemi non critici. Se supera una soglia di costo, tocca un servizio sensibile o incontra un evento mai visto, si ferma e chiama il tecnico.

Il modello migliore è spesso ibrido e dinamico

In-the-loop e on-the-loop non devono essere due etichette assegnate una volta per tutte. Lo stesso agente può cambiare modalità a seconda del caso.

  • Una risposta informativa standard può partire in modalità on-the-loop; un reclamo passa in-the-loop.
  • Un rimborso entro 20 euro e conforme alla policy può essere automatico; un importo maggiore richiede approvazione.
  • Una modifica su un ambiente di test può essere sorvegliata; il deploy in produzione richiede un gate.
  • Una ricerca con fonti concordanti può proseguire; fonti in conflitto attivano l’escalation.
  • Dopo una serie di anomalie, il sistema può retrocedere automaticamente da on-the-loop a in-the-loop.

Questa è la vera maturità agentica: non concedere autonomia in blocco, ma costruire una scala di autonomia legata a condizioni osservabili.

Che cosa dice la ricerca sull’interazione tra persone e automazione

Il paper di Parasuraman, Sheridan e Wickens “A model for types and levels of human interaction with automation” propone di non considerare l’automazione come un interruttore acceso o spento. Un sistema può automatizzare in misura diversa raccolta delle informazioni, analisi, scelta e azione. È esattamente ciò che serve per progettare un agente: possiamo lasciargli cercare e confrontare, ma mantenere umana la decisione finale.

Le “Guidelines for Human-AI Interaction” di Amershi e colleghi, presentate alla conferenza CHI 2019 dell’ACM, ricordano che un buon sistema deve rendere chiaro che cosa sa fare, mostrare informazioni contestuali, permettere correzioni e sostenere un controllo umano coerente nel tempo.

Ben Shneiderman, nel lavoro “Human-Centered Artificial Intelligence: Reliable, Safe & Trustworthy”, contesta l’idea che molta automazione implichi necessariamente poco controllo umano. Si possono progettare sistemi con alta automazione e alto controllo: l’agente svolge molto lavoro, ma le persone mantengono comprensione, responsabilità e capacità d’intervento.

Anche l’AI Risk Management Framework 1.0 del NIST insiste su governance, mappatura del contesto, misurazione e gestione del rischio. Non prescrive un unico livello di autonomia: chiede di collegare controlli e responsabilità all’impatto concreto del sistema.

AI Act e supervisione umana: che cosa cambia

Il Regolamento europeo sull’intelligenza artificiale, Regolamento (UE) 2024/1689, dedica l’articolo 14 alla supervisione umana dei sistemi ad alto rischio. È importante non generalizzare: la disposizione riguarda quella specifica categoria di sistemi, non qualunque chatbot o agente.

Il principio, però, è utile a ogni progetto serio. La supervisione deve consentire alle persone di comprendere capacità e limiti, riconoscere anomalie, evitare un affidamento automatico eccessivo, interpretare correttamente l’output, ignorarlo o annullarlo e fermare il sistema. Una casella da spuntare non soddisfa questo obiettivo se l’operatore non ha informazioni, autorità o tempo per agire.

Per approfondire il contesto organizzativo, rimando anche alla guida sulla formazione AI in azienda e AI Act e all’articolo sulle decisioni artificiali che possono aiutare o distorcere le scelte.

Come progettare una supervisione che funzioni davvero

  1. Definire le azioni consentite. Leggere, proporre, scrivere, inviare, acquistare e cancellare non devono avere gli stessi permessi.
  2. Stabilire i gate. Importi, categorie di dati, destinatari, strumenti e condizioni che richiedono approvazione.
  3. Mostrare il contesto. Il supervisore deve vedere fonti, passaggi, incertezze e conseguenze dell’azione.
  4. Costruire escalation reali. L’agente deve saper dire “non lo so” e passare il caso alla persona giusta.
  5. Registrare tutto. Prompt, strumenti usati, dati consultati, output, approvazioni, modifiche e identità di chi interviene.
  6. Preparare l’arresto. Un pulsante, una regola automatica o un limite di spesa devono fermare il processo prima che l’anomalia si moltiplichi.
  7. Testare anche i casi brutti. Dati mancanti, istruzioni in conflitto, prompt injection, servizi non disponibili e richieste fuori policy.
  8. Misurare gli esiti. Non soltanto quante attività sono state completate, ma errori, danni evitati, correzioni, escalation e tempo umano recuperato.

I due fallimenti opposti da evitare

Il primo è mettere una persona dentro ogni passaggio. Dopo cento conferme al giorno, l’approvazione diventa un riflesso. L’agente sembra controllato, ma l’essere umano fa soltanto clic. È la cosiddetta automation bias: tendiamo ad accettare il suggerimento della macchina, soprattutto quando arriva spesso e sembra plausibile.

Il secondo fallimento è mettere una persona “sopra” un processo che non può davvero vedere o fermare. Una dashboard piena di numeri non è supervisione se gli indicatori non mostrano il rischio, gli avvisi arrivano tardi o l’operatore non ha l’autorità per intervenire.

La domanda giusta non è quindi “c’è un umano?”. È: quale decisione può prendere, con quali informazioni e prima di quale conseguenza?

Una checklist per decidere domani mattina

Prima di attivare un agente, classifica ogni azione con queste domande:

  • può causare un danno economico, legale, fisico o reputazionale?
  • coinvolge dati personali, credenziali o categorie sensibili?
  • l’azione è visibile all’esterno?
  • possiamo annullarla in pochi minuti?
  • esiste una metrica capace di rivelare un errore?
  • il supervisore può intervenire prima che il danno si propaghi?
  • l’agente sa riconoscere l’incertezza ed effettuare un’escalation?
  • chi risponde del risultato è chiaramente identificato?

Se il danno potenziale è alto, l’azione poco reversibile o il tempo d’intervento breve, scegli human-in-the-loop. Se rischio e impatto sono contenuti, l’errore è osservabile e il ripristino semplice, puoi valutare human-on-the-loop. Se non puoi rispondere alle domande, non aumentare l’autonomia: prima rendi il processo comprensibile.

Il ruolo umano non sparisce: cambia livello

Con gli agenti AI l’umano non deve necessariamente controllare ogni riga, ogni file o ogni messaggio. Deve progettare il perimetro, definire le eccezioni, osservare gli effetti e assumersi la responsabilità delle decisioni importanti.

Il modello corretto non è “AI libera” contro “AI al guinzaglio”. È un sistema in cui l’autonomia cresce soltanto quando aumentano test, tracciabilità, reversibilità e capacità di intervento.

In altre parole: human-in-the-loop quando serve consenso; human-on-the-loop quando serve supervisione; mai human-out-of-the-loop per distrazione.

Domande frequenti

Qual è la differenza tra human-in-the-loop e human-on-the-loop?

Nel modello human-in-the-loop una persona deve approvare o correggere prima che l’agente compia un’azione sensibile. Nel modello human-on-the-loop l’agente opera entro limiti stabiliti, mentre una persona monitora risultati e anomalie e può intervenire.

Human-on-the-loop significa che l’AI lavora senza controllo?

No. Servono log, metriche, controlli a campione, alert, soglie ed efficaci meccanismi di arresto. Senza questi strumenti il sistema rischia di essere human-out-of-the-loop.

Quando è obbligatoria l’approvazione umana?

È prudente renderla obbligatoria per azioni ad alto impatto o difficili da annullare: pagamenti, decisioni sul personale, salute, contratti, sicurezza, servizi essenziali, pubblicazione esterna e modifiche critiche in produzione.

Si può cambiare livello di autonomia in base al caso?

Sì. È spesso la soluzione migliore: casi standard e reversibili procedono sotto supervisione; importi elevati, bassa confidenza, anomalie o dati sensibili attivano un gate umano.

Quali strumenti servono per supervisionare un agente AI?

Permessi minimi, audit log, dashboard, alert, soglie di costo e rischio, versionamento, rollback, escalation e un arresto immediato. Il supervisore deve anche ricevere contesto sufficiente per valutare le azioni.

Scrivimi per organizzare un evento o un corso sull’intelligenza artificiale generativa

Mandami un WhatsApp al 339.6325418 per organizzare un corso o una conferenza sull’A.I. generativa.

Invia un’email

Succede sempre più spesso: qualcuno mostra una demo in cui un agente AI legge le email, aggiorna il CRM, prepara una presentazione e prenota una riunione. A quel punto parte la domanda: “Possiamo averne uno anche noi?”.

La domanda giusta, però, è un’altra: in quale processo un agente AI crea più valore di una normale automazione? In azienda gli agenti AI servono quando il percorso non è completamente prevedibile, occorre interpretare informazioni, scegliere tra più strumenti e gestire eccezioni. Se i passaggi sono fissi e le regole sono chiare, un workflow tradizionale è spesso più economico, veloce e controllabile.

Questa distinzione è il punto di partenza dell’articolo di Digital4 “C’è un agent per tutto. Ma non tutto ha bisogno di un agent”. Un tema molto attuale: oggi costruire una demo è relativamente facile; trasformarla in uno strumento affidabile è tutto un altro lavoro.

Che cos’è un agente AI, in parole semplici

Un agente AI è un sistema capace di perseguire un obiettivo, osservare ciò che succede, decidere il passo successivo e utilizzare strumenti: per esempio un motore di ricerca, un database, la posta elettronica, un foglio Excel o un gestionale.

La differenza rispetto a un chatbot non è che “scrive meglio”. La differenza è che può agire. E la differenza rispetto a un workflow è che non deve per forza seguire sempre la stessa strada.

Anthropic distingue chiaramente workflow e agenti: nei primi, modelli e strumenti vengono orchestrati attraverso percorsi definiti in anticipo; nei secondi, è il modello a decidere dinamicamente come procedere. Anche la guida pratica di OpenAI alla costruzione degli agenti suggerisce di partire da processi in cui regole rigide e automazioni deterministiche non bastano.

Workflow, assistente o agente? La scelta pratica

Non tutti i problemi aziendali richiedono lo stesso grado di autonomia. Prima di aggiungere la parola “agentico” a una presentazione, conviene usare questa matrice.

Il principio è semplice: usare il livello minimo di autonomia necessario. Più autonomia significa più flessibilità, ma anche più costi, più variabilità e più controlli.

Il test delle cinque domande prima di creare un agente AI

Nei corsi e nei progetti aziendali partirei da cinque domande molto concrete.

  1. Il processo cambia spesso percorso? Se la risposta è no, probabilmente basta un’automazione.
  2. Occorre interpretare informazioni non strutturate? Email, documenti, note e richieste ambigue sono un terreno più adatto agli agenti.
  3. L’agente deve usare più strumenti? Per esempio cercare un dato nel CRM, confrontarlo con un contratto e preparare una risposta.
  4. Possiamo verificare il risultato? Se non esiste un modo per sapere se il lavoro è corretto, non esiste nemmeno un buon progetto.
  5. Un errore è reversibile? Cancellare una bozza non equivale a inviare un bonifico o pubblicare un listino sbagliato.

Se il processo non supera questo test, aggiungere un agente rischia di automatizzare non il lavoro, ma la confusione.

Tre casi in cui un agente AI può avere senso

1. Gestire richieste con molte eccezioni

Immaginiamo un servizio clienti che riceve richieste via email. Un workflow può riconoscere alcune parole e assegnare un’etichetta. Un agente, invece, può leggere la conversazione, consultare la scheda cliente, verificare la policy, cercare un ordine e preparare una risposta o chiedere l’intervento di una persona.

Il valore non sta nel testo prodotto, ma nei passaggi manuali eliminati. Naturalmente l’agente deve avere fonti definite, permessi limitati e regole chiare per l’escalation.

2. Raccogliere dati da strumenti diversi

Molte attività aziendali consistono nel fare il giro delle sette chiese digitali: CRM, gestionale, email, fogli, cartelle condivise e piattaforme analytics. Un agente può cercare le informazioni, controllarne la completezza e restituire una sintesi utilizzabile.

Un esempio concreto è il lavoro sui fogli di calcolo. In questo video mostro un agente Genspark che interviene su un file Excel:

Per approfondire, sul blog trovi anche cinque esempi pratici di utilizzo dell’agente Genspark.

3. Preparare un lavoro che una persona deve approvare

L’agente può cercare fonti, confrontare documenti, compilare una bozza e segnalare le anomalie. La persona prende la decisione finale. È un modello molto più realistico del fantomatico collega digitale che sa tutto e non chiede mai aiuto.

Il punto non è sostituire il giudizio, ma recuperare tempo sulle attività preparatorie. Nel video seguente racconto dieci esempi con cui ho misurato un risparmio complessivo di dieci ore in una settimana:

Qui trovi anche l’articolo completo su come recuperare dieci ore alla settimana con l’AI.

Il lavoro difficile non è scrivere il prompt

Con un agente il prompt conta, ma non basta. Bisogna progettare il contesto: quali dati può vedere, quali fonti deve considerare autorevoli, che cosa deve ricordare, quali strumenti può utilizzare e quando deve fermarsi.

Anthropic parla di context engineering per gli agenti AI: non si progetta soltanto una richiesta, ma l’intero ambiente informativo in cui il sistema deve operare. È un passaggio che approfondisco anche nell’articolo dal prompt al contesto.

Se i documenti sono vecchi, le autorizzazioni sono eccessive o le procedure aziendali si contraddicono, l’agente non risolve il problema. Lo esegue più velocemente.

Come avviare un progetto pilota senza farsi male

Un buon progetto non parte dal super-agente aziendale. Parte da un processo piccolo, frequente e misurabile.

  1. Scegliere un solo processo. Per esempio classificare le richieste commerciali in entrata.
  2. Misurare il punto di partenza. Tempo impiegato, errori, volumi, costi e passaggi manuali.
  3. Definire una job description. Obiettivo, strumenti, fonti, divieti, condizioni di arresto ed escalation.
  4. Limitare i permessi. All’inizio meglio leggere e proporre; l’azione autonoma viene dopo.
  5. Creare casi di test. Non solo richieste normali, ma dati mancanti, istruzioni contraddittorie ed eccezioni.
  6. Tenere una persona nel circuito. Le azioni sensibili devono richiedere approvazione.
  7. Decidere in anticipo quando fermare il progetto. Se costa più del lavoro risparmiato o non raggiunge la qualità minima, si torna a un workflow più semplice.

Quali metriche usare per valutare un agente AI

Contare le risposte generate serve a poco. Le metriche utili sono legate al lavoro:

  • tempo medio per completare un’attività;
  • percentuale di attività completate correttamente;
  • numero di interventi umani necessari;
  • costo per attività completata;
  • tasso di errore e gravità degli errori;
  • numero di escalation corrette e mancate;
  • tracciabilità delle fonti e delle azioni;
  • tempo realmente recuperato dalle persone.

Gartner ha previsto che oltre il 40% dei progetti di agentic AI sarà cancellato entro la fine del 2027, citando costi crescenti, valore poco chiaro e controlli del rischio insufficienti. La lezione non è “gli agenti non funzionano”, ma “una demo non è un risultato aziendale”.

Governance: chi controlla l’agente che controlla il processo?

Un agente deve essere trattato come un componente operativo, non come un collega infallibile. Servono registri delle azioni, gestione delle identità, limiti di spesa, fonti approvate, valutazioni periodiche e una persona responsabile del processo.

Il Playbook del NIST per la gestione del rischio AI propone azioni organizzate attorno a quattro funzioni: governare, mappare, misurare e gestire. È una buona bussola anche per un progetto piccolo.

Attenzione inoltre alla Shadow AI in azienda: se gli strumenti ufficiali sono assenti o troppo complicati, le persone ne adotteranno altri senza controllo. La governance efficace non è un elenco di divieti; è un modo sicuro per ottenere risultati.

E nei casi delicati bisogna ricordare che l’AI può anche influenzare male le scelte. Ne parlo nell’approfondimento sulle decisioni artificiali in azienda.

La regola finale: autonomia solo dove produce valore

Gli agenti AI in azienda possono essere molto utili. Ma la maturità non si misura dal numero di agenti attivati. Si misura dalla capacità di scegliere il processo giusto, assegnare un perimetro chiaro, controllare i risultati e fermarsi quando una soluzione più semplice funziona meglio.

Prima si mette ordine nel processo. Poi si decide che cosa automatizzare. Solo alla fine si valuta quanta autonomia concedere all’AI.

Il futuro del lavoro non sarà popolato soltanto da super-agenti. Sarà fatto soprattutto di buoni strumenti, piccoli automatismi e agenti specializzati che fanno poche cose, verificabili, davvero utili.

Domande frequenti sugli agenti AI in azienda

Qual è la differenza tra un agente AI e un chatbot?

Un chatbot risponde principalmente a richieste. Un agente AI può pianificare più passaggi, scegliere strumenti, osservare i risultati intermedi e compiere azioni per raggiungere un obiettivo.

Quando conviene usare un workflow invece di un agente?

Quando il processo è stabile, i passaggi sono noti, le regole sono chiare e le eccezioni sono poche. In questi casi il workflow è generalmente più semplice, economico e prevedibile.

Quali processi sono adatti a un primo agente AI?

Processi frequenti, circoscritti e misurabili: classificazione delle richieste, raccolta di dati da più fonti, controllo della completezza dei documenti e preparazione di bozze da approvare.

Un agente AI può lavorare senza supervisione umana?

Può farlo solo in attività a basso rischio, ben testate e facilmente reversibili. Per pagamenti, contratti, decisioni sulle persone o comunicazioni pubbliche è prudente mantenere un’approvazione umana.

Come si misura il valore di un agente AI?

Con indicatori operativi: tempo risparmiato, costo per attività, qualità del risultato, errori, escalation, interventi umani e tracciabilità delle azioni.

Scrivimi per organizzare un evento o un corso sull’intelligenza artificiale generativa

Mandami un WhatsApp al 339.6325418 per organizzare un corso o una conferenza sull’A.I. generativa.

Invia un’email