AI Agent: cosa sono e come funzionano in azienda

Se hai sentito parlare di "AI agent" o "agenti autonomi" e non hai capito bene cosa siano e come si distinguano da un chatbot o da un sistema RAG, sei in buona compagnia. Il termine è usato in modo molto vago — a volte per indicare cose completamente diverse. Questa guida vuole spiegarlo in modo chiaro, senza tecnicismi inutili, partendo dall'uso pratico in azienda.

La definizione semplice: un AI agent agisce, non si limita a rispondere

Un chatbot risponde. Un AI agent agisce.

È questa la differenza fondamentale. Un sistema RAG (come un chatbot su documenti) riceve una domanda e restituisce una risposta cercando nei tuoi archivi. Un AI agent, invece, riceve un obiettivo e decide autonomamente come raggiungerlo — eseguendo una sequenza di azioni, usando strumenti diversi, adattandosi ai risultati intermedi.

Come funziona tecnicamente un AI agent

Senza entrare nei dettagli tecnici, un AI agent funziona così:

• Ricezione dell'obiettivo: l'utente o un sistema definisce il task ("Analizza tutti i contratti in scadenza nel prossimo mese e segnala le clausole critiche")
• Pianificazione: l'agent decide la sequenza di passi necessari per completare il task
• Esecuzione con tool: l'agent usa strumenti (tool) — può interrogare un database, leggere file, chiamare API, navigare un sistema aziendale, mandare email, aggiornare record
• Ragionamento sui risultati: analizza cosa ha trovato, adatta il piano se necessario, decide il passo successivo
• Output: restituisce il risultato (un report, un'azione completata, una notifica)

I framework tecnici più usati per costruire agenti sono LangChain e LlamaIndex, che permettono di collegare un modello linguistico (LLM) con strumenti esterni. In Gaulin usiamo Ollama come server per il modello LLM e orchestriamo tutto con LangChain, il tutto installato on-premise.

Differenza tra chatbot, RAG e AI agent: il confronto diretto

Casi d'uso reali degli AI agent in azienda

Non tutti i processi aziendali hanno bisogno di un agent — spesso un buon sistema RAG è sufficiente e più semplice da mantenere. Gli agent hanno senso quando il processo coinvolge più sistemi, richiede decisioni intermedie e produce azioni concrete. Ecco esempi concreti:

1. Agent di riconciliazione contabile

Obiettivo: confronta estratti conto bancari con le registrazioni nel gestionale, identifica discrepanze, propone scritture correttive. Strumenti usati: accesso al database ERP, lettura PDF estratti conto, generazione report. Risultato: 80% del lavoro di riconciliazione automatizzato.

2. Agent di monitoraggio contratti

Obiettivo: ogni lunedì mattina, legge tutti i contratti attivi, identifica quelli in scadenza entro 60 giorni, analizza le clausole di rinnovo, prepara un briefing per il commerciale responsabile e aggiorna il CRM. Strumenti: database contratti, sistema CRM, email. Risultato: zero scadenze mancate senza supervisione umana.

3. Agent di onboarding IT

Obiettivo: quando viene creato un nuovo utente in Active Directory, il sistema crea automaticamente gli account email, configura le autorizzazioni sui sistemi, invia le credenziali cifrate al nuovo dipendente e avvisa il responsabile IT. Strumenti: directory aziendale, API gestionali, email. Risultato: onboarding IT da 3 ore a 8 minuti.

4. Agent di primo livello helpdesk

Obiettivo: riceve i ticket di primo livello, categorizza il problema, cerca nei knowledge base le soluzioni, risponde autonomamente se può, scala al tecnico umano con context completo se non può. Risultato: 65-70% dei ticket risolti senza intervento umano.

5. Agent di ricerca su pratiche e normative

Obiettivo: per ogni pratica (una verifica documentale, una richiesta doganale, un controllo di conformità) l'agent consulta gestionale, archivio documenti e guide interne, incrocia i dati e prepara per l'operatore la risposta con i riferimenti. È il caso tipico degli uffici che perdono ore a passare da un software all'altro. Risultato: tempi di ricerca ridotti da ore a minuti e risposte coerenti, indipendentemente dall'esperienza del singolo operatore.

Come si progetta un AI agent che funziona

Quando un agent sbaglia, chiama la funzione sbagliata o si blocca in tentativi ripetuti, raramente la colpa è del modello. Quasi sempre il problema è come è stato costruito il sistema intorno al modello. Tre regole fanno la differenza.

Partire dal minimo indispensabile

Un agent completo ha più livelli: il modello linguistico, gli strumenti che può usare (collegati sempre più spesso con protocolli standard come MCP, il Model Context Protocol), una memoria separata dalla ricerca nei documenti e un sistema di valutazione che misura se l'agent lavora bene nel tempo. Non servono tutti dal primo giorno. L'errore più comune, anche nelle grandi aziende, è costruire un'architettura elaborata per un problema che ne richiedeva una semplice: meglio partire con modello e pochi strumenti e aggiungere un livello solo quando emerge il problema che lo richiede.

Pochi strumenti, descritti bene

Ogni strumento messo a disposizione dell'agent occupa spazio nella sua memoria di lavoro (il contesto), anche se non viene mai usato. Troppi strumenti, o strumenti con nomi e scopi simili, confondono il modello: sceglie quello sbagliato, riprova, e ogni tentativo fallito peggiora la situazione. Le regole pratiche, che oggi si chiamano context engineering:

• un nome inequivocabile e una descrizione chiara per ogni strumento;
• solo gli strumenti utili al compito in corso, non l'intero catalogo;
• nessuna sovrapposizione tra strumenti che fanno cose simili;
• parametri semplici, con valori ben definiti;
• test su casi reali dell'azienda, non solo su esempi ideali.

Esporre all'agent un'API esistente così com'è funziona per le prove, ma con i dati eterogenei di una PMI genera presto errori: conviene preparare strumenti pensati per l'agent.

Autonomia sì, ma con controlli

I modelli più recenti riescono a portare avanti compiti che durano ore o giorni, come la revisione di contratti su un lungo periodo o il monitoraggio continuo di una casella email, grazie a una memoria che sopravvive tra una sessione e l'altra. Alcuni agent scrivono perfino da soli il piccolo programma che serve per collegarsi a un sistema, invece di usare un connettore preparato in anticipo. In entrambi i casi servono punti di verifica umana nei momenti decisivi e un ambiente isolato in cui il codice scritto dall'agent viene eseguito senza poter toccare il resto dei sistemi.

Prima di partire: le domande da farsi

Rispondere a queste domande prima di scegliere la tecnologia evita il rischio più comune: un sistema sovradimensionato, costoso da mantenere e difficile da spiegare al team.

• Quale processo? I candidati migliori durano più di un'ora, hanno più passaggi in sequenza e si ripetono spesso.
• Quante fonti di dati? Gestionale, CRM, email, cartelle condivise: ogni fonte è uno strumento da costruire e mantenere.
• Serve memoria? Il processo deve ricordare le interazioni precedenti o ogni richiesta è indipendente?
• Quanto sono sensibili i dati? Se l'agent lavora su contratti, dati di clienti o informazioni finanziarie, deve girare in un ambiente controllato, senza inviare nulla all'esterno.
• Chi controlla? Serve una persona che verifichi i risultati, soprattutto nelle prime settimane.

Quando NON usare un AI agent

È importante essere onesti: gli agent non sono la risposta a tutto. Ci sono situazioni in cui un approccio più semplice funziona meglio:

• Se hai solo bisogno di rispondere a domande: un sistema RAG è più semplice, più affidabile e più facile da mantenere
• Se il processo ha un alto rischio di errori con conseguenze gravi: un agent che agisce in autonomia su sistemi critici (es. trasferimenti di denaro, modifiche ai dati di produzione) richiede supervisione umana nel loop — altrimenti il costo di un errore supera il beneficio dell'automazione
• Se hai pochi dati storici del processo: gli agent funzionano meglio quando il workflow è ben definito e ripetibile; processi nuovi o molto variabili sono più difficili da automatizzare

AI agent on-premise: perché è importante per le aziende italiane

Un AI agent, per definizione, accede a dati aziendali reali e compie azioni reali sui sistemi. Se questo agent funziona nel cloud — su server di OpenAI, Microsoft o Google — significa che dati sensibili (contratti, dati clienti, informazioni finanziarie) vengono trasmessi a server esterni ogni volta che l'agent esegue un'azione.

Per un'azienda italiana che opera in settori con dati riservati, questa è spesso una violazione del GDPR — o quantomeno un rischio legale significativo che non viene mai discusso apertamente dai fornitori cloud.

Gli AI agent on-premise di Gaulin operano interamente nella rete aziendale: il modello LLM gira su Ollama, LangChain orchestra le azioni, i tool accedono ai sistemi interni. Nessun dato esce dalla rete. La potenza degli agenti, senza i rischi del cloud.