Risposta rapida: cosa serve per creare agenti AI affidabili?
Per creare agenti AI affidabili servono tool e practice integrate: un LLM con tool calling (OpenAI/Anthropic), orchestrazione (LangChain o LlamaIndex), RAG con vector DB, e osservabilità end-to-end. Un agente in produzione deve avere evals, guardrail, osservabilità e un kill switch. Il percorso in 10 passi descritto qui parte dai failure modes e arriva al rilascio controllato, con il controllo dei costi.
Introduzione: perché i tool senza le pratiche producono agenti fragili
Escono di continuo nuovi framework per costruire agenti AI. La demo funziona in pochi minuti, poi qualcuno prova a metterla in produzione e arrivano allucinazioni, costi fuori controllo e passaggi manuali che annullano il valore dell’automazione. Per questo nella consulenza AI di Niuexa seguiamo un percorso in 10 passi, dai failure modes al rilascio controllato.
Un agente AI che funziona in demo e fallisce in produzione di solito non ha un problema di modello, ma di ingegneria: mancano i test, i guardrail, le metriche e il processo che rendono affidabile un prototipo.
Gli agenti arriveranno comunque, spesso dentro software che l’azienda usa già: secondo Gartner (comunicato del 26 agosto 2025) entro la fine del 2026 il 40% delle applicazioni aziendali integrerà agenti dedicati a compiti specifici, contro meno del 5% nel 2025. Lo stesso Gartner (25 giugno 2025) prevede che oltre il 40% dei progetti di agentic AI sarà cancellato entro la fine del 2027, per costi crescenti, valore poco chiaro o controlli del rischio inadeguati. La differenza la fanno le pratiche descritte in questa guida.
Demo vs produzione: cosa si rompe e perché
In una demo, l'agente riceve input puliti, opera in un contesto controllato e non ha vincoli di costo o latenza. In produzione, affronta: input ambigui o maliziosi, dati incompleti, tool che falliscono, utenti che escono dal flusso previsto, picchi di traffico, e budget per token che si esaurisce. Il gap tra demo e produzione non si colma con un modello migliore, ma con engineering practices rigorose.
Definizione operativa di "agente"
In questa guida, per "agente AI" intendiamo un sistema che:
- Pianifica: scompone un obiettivo in sotto-task e sceglie la sequenza di azioni
- Usa tool: invoca API, database, servizi esterni attraverso tool calling strutturato
- Gestisce stato: mantiene memoria della conversazione e del contesto tra i passi
- Gestisce errori: rileva fallimenti dei tool, ripianifica o escala a un operatore umano
- Rispetta policy: opera entro limiti definiti di budget, azioni consentite e dati accessibili
Cosa fare vs cosa evitare
- Fare: definire i failure modes prima di scrivere codice
- Fare: costruire evals automatiche dal giorno uno
- Fare: partire con un perimetro ridotto e allargare dopo la validazione
- Evitare: dare all'agente accesso illimitato a tool e dati
- Evitare: affidarsi solo al prompt engineering per controllare il comportamento
- Evitare: andare in produzione senza metriche automatiche e kill switch
La mappa dei tool: cosa serve nello stack
Lo stack tecnologico di un agente AI in produzione si compone di quattro livelli: il modello di linguaggio, il framework di orchestrazione, il pipeline RAG e i tool di produzione. Scegliere il componente sbagliato in uno qualsiasi di questi livelli compromette l'intero sistema.
LLM + API: criteri di selezione
La scelta del modello non è solo una questione di benchmark. I criteri che contano in produzione sono:
- Supporto nativo al tool calling: il modello deve gestire function calling con schema JSON validabile, non solo testo libero
- Costo per token: con volumi elevati, la differenza di prezzo per milione di token tra un modello e l’altro (anche di un ordine di grandezza) decide la sostenibilità economica
- Latenza P95: non la latenza media, ma il 95° percentile. Un agente che risponde in 2s nel 90% dei casi e in 15s nel restante 10% genera frustrazione
- Context window: per agenti con conversazioni lunghe o documenti da analizzare, la finestra di contesto limita o abilita interi casi d'uso
- Affidabilità del tool calling: percentuale di chiamate a tool con schema valido e parametri corretti (testare empiricamente, non fidarsi dei benchmark)
- Dove gira il modello: API in cloud oppure un modello più piccolo, specializzato sul compito, su infrastruttura propria. Il secondo costa meno per chiamata e tiene i dati in casa, ma va mantenuto e rende bene solo su compiti stretti e ripetitivi
Framework di orchestrazione a confronto
Il framework di orchestrazione è il "sistema nervoso" dell'agente: gestisce il flusso di esecuzione, le chiamate ai tool, la memoria e il recovery dagli errori.
| Criterio | LangChain / LangGraph | LlamaIndex | SDK Custom |
|---|---|---|---|
| Caso d'uso ideale | Agenti multi-step con tool calling complesso e workflow ramificati | Pipeline RAG-intensive, agenti che interrogano knowledge base aziendali | Agenti con requisiti di latenza estremi o vincoli di compliance specifici |
| Punti di forza | Ecosistema vasto, LangGraph per grafi stateful, LangSmith per osservabilità | API semplice per RAG, ottima gestione degli indici, integrazione nativa con vector DB | Controllo totale, zero dipendenze, ottimizzazione specifica per il caso d'uso |
| Quando evitare | Se il caso d'uso è puro retrieval senza logica agenziale; curva di apprendimento ripida | Se servono workflow complessi con branching condizionale e multi-agente | Se il team è piccolo e il time-to-market è critico; alto costo di manutenzione |
Regola pratica
Conviene partire con un SDK minimale (per esempio quello del fornitore del modello, con un’orchestrazione essenziale) e passare a LangChain o LlamaIndex solo quando la complessità del workflow lo giustifica. Il framework aggiunge valore quando ci sono più di 5 tool, branching condizionale e stato da conservare tra le sessioni.
Piattaforme dei fornitori o stack proprio
Accanto ai framework open source, i grandi fornitori offrono piattaforme per costruire e gestire agenti dentro il proprio ecosistema. Sono tecnologie da valutare come le altre, e il criterio più utile è partire da dove l’azienda lavora già: lì ci sono i dati, i permessi e le persone che useranno l’agente.
| Piattaforma | Punto di forza | Ha senso se |
|---|---|---|
| Microsoft Copilot Studio | Agenti dentro Microsoft 365 e Teams, orchestrazione di più agenti, connettori verso i dati aziendali | L’azienda lavora su Microsoft 365 e i dati stanno in SharePoint, Outlook o Dynamics |
| Salesforce Agentforce | Agenti nativi nel CRM, con accesso diretto a clienti, casi e opportunità | Vendite e assistenza vivono in Salesforce |
| Google Cloud (Vertex AI Agent Builder) | Integrazione con Workspace e con i dati in Google Cloud, supporto al protocollo A2A | L’azienda usa Google Workspace o Google Cloud |
| AWS (Amazon Bedrock AgentCore) | Servizi per eseguire, proteggere e monitorare agenti costruiti con qualsiasi framework e modello | L’infrastruttura è su AWS e il team sviluppa in proprio |
Piattaforma o stack proprio
La piattaforma accorcia i tempi e porta con sé permessi e sicurezza dell’ecosistema; in cambio lega l’agente a quel fornitore e lascia meno controllo su test, costi e scelta del modello. Prima di decidere conviene verificare tre cose: se prompt, configurazioni e log si possono esportare, se si possono eseguire le proprie evals sul proprio golden set e come si calcola il costo per conversazione.
Standard di interoperabilità: MCP e A2A
Due protocolli aperti stanno diventando il modo comune di collegare agenti, tool e dati:
- MCP (Model Context Protocol): introdotto da Anthropic a fine 2024, standardizza il modo in cui un agente si collega a tool e fonti di dati. Un connettore MCP scritto una volta, per esempio verso il gestionale, può essere usato da modelli e client diversi
- A2A (Agent2Agent): proposto da Google nel 2025 e oggi gestito dalla Linux Foundation, definisce come agenti di fornitori diversi si scambiano compiti e risultati
La conseguenza pratica è una: chiedere che le integrazioni siano costruite su standard aperti, così da poter cambiare modello o fornitore senza riscriverle. Un server MCP resta comunque un tool come gli altri: va registrato nel tool registry, limitato con allowlist e permessi minimi, e testato.
Memoria, contesto e pipeline RAG
Un agente senza memoria è stateless e riparte da zero a ogni interazione. Un agente con troppa memoria consuma token inutilmente e introduce rumore. Il design della memoria richiede tre decisioni:
- Short-term memory: la conversazione corrente, gestita nel context window del modello. Limitata dalla dimensione della finestra
- Long-term memory: conoscenza persistente tra sessioni, tipicamente un vector DB (Pinecone, Weaviate, Qdrant, pgvector) con embedding del contenuto aziendale
- Working memory: lo stato intermedio dell’esecuzione corrente: quali tool sono stati chiamati, quali risultati ottenuti, quali sotto-task completati
Il pipeline RAG (Retrieval-Augmented Generation) collega il modello alla conoscenza aziendale. I componenti critici sono: chunking strategy (dimensione e overlap dei frammenti), embedding model (trade-off qualità/costo), retrieval strategy (similarity search, hybrid search, re-ranking), e prompt di contesto che integra i risultati del retrieval nell'istruzione al modello.
Tool di produzione: osservabilità, logging, rate limiting
Un agente in produzione senza osservabilità è una scatola nera. I tool di produzione essenziali sono:
- Tracing: LangSmith, Arize Phoenix o Helicone, per tracciare ogni step dell’agente con latenza, token consumati e output
- Logging strutturato: ogni decisione dell'agente, ogni tool call e ogni errore devono essere loggati in formato JSON queryable
- Rate limiting: limiti per utente, per sessione e per finestra temporale per prevenire abusi e costi fuori controllo
- Cost tracking: monitoraggio in tempo reale della spesa per token, per agente e per cliente
- Alerting: notifiche automatiche quando le metriche escono dai range accettabili (tasso di errore, latenza, costo)
Pratiche fondamentali: progettare prima di codificare
I tool migliori non compensano un design scadente. Le pratiche che seguono sono il fondamento su cui costruire un agente che funziona in produzione, non solo in demo.
Scegliere il primo processo da affidare a un agente
Prima del design viene la scelta del caso. I processi da cui conviene partire hanno tre caratteristiche:
- Volume alto: lo stesso compito si ripete molte volte al mese, quindi il tempo risparmiato si vede e si misura
- Regole documentabili: chi lo fa oggi sa spiegare come decide, e quelle regole si possono scrivere
- Errori correggibili: uno sbaglio si intercetta e si corregge prima che arrivi al cliente o nel gestionale
Esempi tipici: richieste di primo livello dei clienti (stato ordini, domande ricorrenti), lettura e smistamento dei documenti in arrivo, abbinamento tra fatture e ordini, preparazione di report ricorrenti, gestione degli appuntamenti.
Riprogettare, non sovrapporre
Un agente appoggiato sopra un processo pensato per le persone eredita passaggi che esistono solo perché a farli era una persona: copie tra sistemi, approvazioni ripetute, controlli doppi. Prima di automatizzare conviene misurare il processo com’è e chiedersi quali passaggi servono davvero. Spesso alcuni si eliminano senza AI, e l’agente lavora su un flusso più corto.
Task decomposition: da obiettivo a sotto-task
Il primo passo è scomporre l'obiettivo dell'agente in una mappa di sotto-task, ciascuno con tool associati e criteri di uscita espliciti. Questa mappa diventa il contratto tra il team di sviluppo e gli stakeholder.
Template di decomposizione
- Obiettivo: es. "Risolvere ticket di supporto L1 senza escalation umana"
- Sotto-task 1: Classificare il ticket (tool: classifier API) → output: categoria + confidence
- Sotto-task 2: Recuperare documentazione pertinente (tool: RAG retrieval) → output: top-k documenti
- Sotto-task 3: Generare risposta (tool: LLM generation) → output: risposta + fonti
- Sotto-task 4: Validare risposta (tool: quality checker) → output: pass/fail + motivo
- Exit criteria: confidence > 0.85 AND quality_check = pass, altrimenti escalation
Contractual prompting: istruzioni + schema + regole testabili
Il prompt non è un suggerimento: è un contratto. Ogni istruzione deve essere verificabile con un test automatico. Il contractual prompting combina tre elementi:
- Istruzioni in linguaggio naturale: cosa deve fare l'agente, in che tono, con quali vincoli
- JSON Schema per ogni tool: definizione formale di parametri richiesti, tipi, vincoli di validazione
- Regole testabili: ogni regola del prompt deve poter essere tradotta in un assertion automatica (es. "Non menzionare mai il nome di un competitor" → test: nessun output contiene [lista competitor])
Se una regola del prompt non può diventare un test automatico, non è una regola ma un auspicio, e in produzione gli auspici non bastano.
Tool design: piccoli, deterministici, con I/O validato
Ogni tool esposto all'agente deve seguire tre principi:
- Single Responsibility: un tool fa una sola cosa. "search_knowledge_base" è un buon tool; "search_and_summarize_and_send_email" non lo è
- Determinismo: a parità di input, il tool restituisce lo stesso output (escluso il componente LLM). Questo rende il testing possibile
- I/O validato: input e output definiti con JSON Schema. L'agente non può chiamare un tool con parametri malformati, e il tool non può restituire strutture inattese
Human-in-the-loop: quando e come
Non tutte le decisioni devono essere automatiche. Il pattern human-in-the-loop prevede tre livelli di intervento umano:
- Approvazione pre-azione: per azioni irreversibili (es. invio email a cliente, modifica database), l'agente propone l'azione e attende approvazione
- Review post-azione: l'agente esegue e un umano rivede un campione (5-20%) per qualità
- Escalation su incertezza: quando la confidence scende sotto la soglia, l'agente trasferisce il caso a un operatore con il contesto completo
Un agente o più agenti: pattern di orchestrazione
Un sistema multi-agente divide il lavoro tra più agenti specializzati, ciascuno con i propri tool e le proprie istruzioni, coordinati da un orchestratore o da regole di passaggio. Ha senso quando un unico agente dovrebbe gestire troppi tool o competenze molto diverse. Ogni agente in più, però, aggiunge chiamate al modello, costo, latenza e punti in cui qualcosa può rompersi.
| Pattern | Come funziona | Adatto a | Rischio principale |
|---|---|---|---|
| Orchestratore e specialisti | Un agente centrale riceve il compito, lo assegna agli specialisti e compone il risultato | Assistenza clienti con richieste di natura diversa, elaborazione di documenti | L’orchestratore diventa collo di bottiglia e punto unico di errore |
| Pipeline | Gli agenti lavorano in sequenza: l’output di uno è l’input del successivo | Documenti che passano per estrazione, controllo e registrazione | Un errore a monte si propaga fino alla fine |
| Collaborativo | Agenti alla pari che si scambiano proposte e critiche | Analisi e ricerca, revisione di testi | Conversazioni lunghe, costi difficili da prevedere, risultati poco ripetibili |
| Gerarchico | Supervisori che coordinano gruppi di agenti esecutori, su più livelli | Automazioni ampie che toccano molti processi | Complessità alta: ricostruire chi ha deciso cosa diventa difficile |
Framework come LangGraph, AutoGen (Microsoft) e CrewAI offrono questi pattern già pronti, e le piattaforme dei fornitori descritte sopra includono un’orchestrazione multi-agente nativa.
Regola pratica
Partire con un solo agente e pochi tool. Dividerlo in più agenti solo quando le evals mostrano che l’agente unico sbaglia perché ha troppe istruzioni o troppi tool, non prima. In un sistema multi-agente il tracing end-to-end e un budget massimo per conversazione diventano obbligatori: ogni passaggio tra agenti va registrato, e ogni scambio tra due agenti deve avere un numero massimo di turni.
Il percorso Niuexa: dall’idea alla produzione in 10 passi
Questo è il processo che seguiamo in Niuexa per portare un agente AI dal concept alla produzione. Ogni passo ha un deliverable concreto e un gate di approvazione prima di procedere al successivo.
-
Obiettivo + KPI + failure modes
Definire l’obiettivo dell’agente in termini misurabili (per esempio la quota di ticket L1 risolti entro un tempo massimo, confrontata con la misura di partenza). Mappare i failure modes: cosa succede se l’agente ha un’allucinazione? Se il tool fallisce? Se il costo per conversazione supera il budget? Ogni failure mode deve avere una contromisura progettata prima di scrivere una riga di codice.
-
Dataset di casi reali (50-200)
Raccogliere 50-200 esempi reali dal dominio: input utente, output atteso, edge case, casi di errore. Questo dataset diventa il golden set per le evals. Senza dati reali, si costruisce sull'intuizione invece che sull'evidenza.
-
RAG evaluation
Se l'agente usa RAG, valutare il pipeline di retrieval indipendentemente dal modello: precision@k, recall@k, MRR (Mean Reciprocal Rank). Un retrieval scadente produce risposte scadenti indipendentemente dalla qualità del modello.
-
Tool registry + policy
Registrare ogni tool con: nome, descrizione, JSON Schema per input/output, policy di accesso (chi può usarlo, in quali condizioni), rate limit, costo stimato per chiamata. Il registry è il contratto tra l'agente e i sistemi aziendali.
-
Evals automatiche
Implementare una suite di test automatici che valuta l'agente sul golden set ad ogni modifica del prompt, del modello o dei tool. Le metriche minime sono: Task Success Rate, Groundedness, Cost per Resolution, Escalation Rate.
-
Red teaming
Sottoporre l'agente a test adversariali: prompt injection, jailbreak, input fuori dominio, richieste di dati sensibili, tentativi di manipolazione. Il red teaming rivela vulnerabilità che i test funzionali non catturano.
-
Rollout controllato (canary 5-10%)
Avviare l'agente su un sottoinsieme del traffico reale (5-10%), con human review al 100% nella prima settimana. Confrontare le metriche con il baseline (operatore umano o sistema precedente). Scalare solo se le metriche superano le soglie definite al passo 1.
-
Monitoring + tracing
Attivare il monitoraggio in tempo reale: latenza per step, costo per conversazione, tasso di errore, distribuzione delle escalation. Ogni conversazione deve essere tracciabile end-to-end per debugging e audit.
-
Retraining / iterazione
Analizzare settimanalmente i casi di errore e aggiornare: il golden set (aggiungendo i nuovi edge case), il prompt (raffinando le istruzioni), i tool (correggendo bug o migliorando le validazioni), il retrieval (aggiungendo o aggiornando documenti nel vector DB).
-
Cost governance
Implementare dashboard di costo per agente, per cliente e per caso d'uso. Definire budget ceiling con alert automatici. Ottimizzare: caching delle risposte frequenti, routing verso modelli più economici per task semplici, compressione del contesto per ridurre i token consumati.
Quanto tempo serve
Dipende dal numero di tool, dalle integrazioni e dalla qualità dei dati disponibili: per questo la durata si stima dopo l’analisi, non prima. Il passo più sottovalutato è il #2 (dataset di casi reali): raccogliere esempi di qualità richiede tempo delle persone che conoscono il processo, e va pianificato fin dall’inizio.
Testing ed evals
Un agente AI senza evals automatiche è un sistema non testato. In produzione, "non testato" significa "inaffidabile". Il testing degli agenti richiede metriche specifiche, dataset curati e automazione in CI/CD.
Metriche fondamentali
| Metrica | Definizione | Come fissare la soglia |
|---|---|---|
| Task Success Rate (TSR) | Percentuale di task completati con successo senza escalation umana | Sopra il risultato attuale del processo, decisa prima dei test |
| Groundedness | Percentuale di affermazioni nell'output supportate da fonti recuperate via RAG | Molto alta per le risposte ai clienti: ogni affermazione deve avere una fonte |
| Cost per Resolution | Costo medio in token + compute per risolvere un caso (inclusi retry e tool call) | Inferiore al costo attuale del processo, supervisione inclusa |
| Escalation Rate | Percentuale di casi trasferiti a un operatore umano | Coerente con la quota di casi che richiedono davvero una persona |
| Latenza end-to-end (P95) | Tempo dal ricevimento della richiesta alla risposta finale, al 95° percentile | Compatibile con l’attesa accettabile per chi usa quel canale |
| Tool Call Accuracy | Percentuale di chiamate a tool con parametri corretti e risultato utilizzabile | Vicina al 100% per le azioni che scrivono sui sistemi aziendali |
Costruzione del golden set (50-200 esempi)
Il golden set è il cuore del sistema di evals. Per costruirlo efficacemente:
- Fonti: ticket reali, chat log, email dei clienti, casi risolti dagli operatori
- Distribuzione: 60% casi tipici, 20% edge case, 20% casi di errore o adversariali
- Formato: per ogni esempio: input utente, contesto disponibile, output atteso, tool call attese, criteri di valutazione
- Aggiornamento: aggiungere 10-20 nuovi esempi al mese dai casi di errore in produzione
- Validazione: ogni esempio deve essere validato da un esperto di dominio (non solo dal team tech)
LLM-as-judge: quando e come ridurre il bias
Usare un LLM per valutare l'output di un altro LLM è potente ma rischioso. Per ridurre il bias:
- Criteri espliciti: fornire al giudice una rubrica con criteri binari o su scala 1-5, non valutazioni soggettive
- Riferimento al ground truth: quando disponibile, il giudice confronta l'output con la risposta attesa, non con la propria "opinione"
- Modello diverso: usare un modello diverso da quello dell'agente come giudice per evitare auto-valutazione favorevole
- Calibrazione: validare il giudice su un campione con valutazioni umane e misurare l'accordo (Cohen's kappa > 0.7)
Test di regressione in CI/CD
Ogni modifica al prompt, al modello o ai tool deve triggerare automaticamente la suite di evals sul golden set. Se una metrica regredisce oltre la soglia, il deploy viene bloccato. Questo richiede:
- Pipeline CI/CD con step dedicato alle evals (es. GitHub Actions, GitLab CI)
- Soglie definite per ogni metrica (per esempio il TSR non può scendere sotto la soglia fissata al passo 1)
- Report automatico con diff tra la versione corrente e la precedente
- Budget di test: stimare il costo in token delle evals e includerlo nel budget operativo
Guardrail, sicurezza e compliance
Un agente AI in produzione opera con dati reali, interagisce con sistemi aziendali e prende decisioni che hanno impatto su clienti e processi. I guardrail non sono un'opzione: sono un requisito.
Policy engine, allowlist, sandbox
- Policy engine: un layer che intercetta ogni input e output dell'agente e verifica il rispetto delle regole (es. "Non rivelare informazioni di altri clienti", "Non eseguire azioni di cancellazione su database di produzione")
- Allowlist di tool e azioni: l'agente può usare solo i tool esplicitamente registrati. Ogni nuovo tool richiede una review di sicurezza prima dell'attivazione
- Sandbox per esecuzione codice: se l'agente genera o esegue codice, questo deve avvenire in un ambiente isolato con risorse limitate, senza accesso alla rete o al filesystem di produzione
- Simulazione pre-deploy: prima di attivare un nuovo tool o una nuova policy, simulare il comportamento dell'agente su un campione di traffico storico per verificare l'assenza di regressioni
Privacy: PII, retention, logging, access control
La gestione dei dati personali è critica, specialmente in Europa con il GDPR:
- PII detection: filtrare automaticamente i dati personali (nomi, email, numeri di telefono, codici fiscali) dai log e dal contesto inviato al modello
- Data retention: definire policy di retention per le conversazioni (es. 90 giorni per debugging, poi anonimizzazione)
- Logging selettivo: loggare le metriche e le decisioni, non il contenuto integrale delle conversazioni con dati sensibili
- Access control: role-based access ai log, ai dati dell'agente e alle configurazioni. Principio del minimo privilegio
Contromisure al prompt injection
Il prompt injection è il tentativo di far eseguire all'agente istruzioni non autorizzate iniettate nell'input utente. Le contromisure principali sono:
- Separazione dei contesti: system prompt e user input devono essere chiaramente delimitati e il modello deve essere istruito a non eseguire istruzioni nell'user input
- Input sanitization: rilevare pattern di injection noti (es. "Ignora le istruzioni precedenti") e bloccarli prima che raggiungano il modello
- Output validation: verificare che l'output dell'agente sia coerente con le istruzioni del system prompt e non con potenziali istruzioni iniettate
- Least privilege: anche se un injection ha successo, l'agente non ha accesso a tool o dati oltre il necessario
Incident response: playbook, audit trail, kill switch
Playbook di incident response per agenti AI
- Rilevamento: alert automatici su metriche anomale (spike errori, costo, latenza)
- Contenimento: kill switch che disattiva l'agente in < 30 secondi e trasferisce il traffico al fallback (operatori umani o messaggio di indisponibilità)
- Analisi: audit trail completo di ogni conversazione e decisione per root cause analysis
- Risoluzione: fix + test sul golden set + red teaming specifico sul failure mode
- Post-mortem: documento con root cause, impatto, timeline e azioni preventive per evitare la ricorrenza
Tre architetture di riferimento
Ogni agente AI ha un contesto specifico, ma i pattern architetturali si ripetono. Ecco tre architetture di riferimento da adattare al proprio caso.
Architettura A: assistenza clienti (RAG, escalation, controllo qualità)
Agente per l’assistenza clienti
- Input: ticket o messaggio chat del cliente
- Step 1, classificazione: classificare intent e urgenza (LLM + classifier)
- Step 2, retrieval: recuperare documentazione pertinente dalla knowledge base (RAG con hybrid search)
- Step 3, generazione: comporre la risposta citando le fonti (LLM con grounding)
- Step 4, quality check: validare tono, completezza, correttezza (LLM-as-judge)
- Step 5, decisione: se quality > soglia, inviare la risposta; altrimenti, escalation con contesto
- Metriche da seguire: TSR, groundedness, soddisfazione dei clienti e quota di escalation, ciascuna con una soglia fissata sulla misura di partenza
Architettura B: operations e IT (ticketing e tool calling controllato)
Agente per operations e IT
- Input: richiesta IT o alert di sistema
- Step 1, triage: classificare priorità e tipo di intervento (P1-P4)
- Step 2, diagnosi: interrogare log, metriche e CMDB (tool calling con allowlist)
- Step 3, azione: eseguire remediation automatica per P3-P4 (restart servizio, scaling, pulizia cache) con approvazione automatica; per P1-P2, proporre l'azione e attendere approvazione umana
- Step 4, verifica: confermare che l'intervento ha risolto il problema (health check post-azione)
- Step 5, documentazione: creare/aggiornare il ticket con timeline, azioni eseguite e risultato
- Metriche da seguire: MTTR per livello di priorità, quota di ticket L1 chiusi senza intervento, nessuna azione non autorizzata
Architettura C: supporto alle vendite (CRM, offerte, conformità)
Agente per il supporto alle vendite
- Input: richiesta del commerciale (preparare offerta, qualificare lead, sintetizzare account)
- Step 1, raccolta del contesto: recuperare dati dal CRM (storico ordini, interazioni, fatturato)
- Step 2, analisi: sintetizzare lo stato dell'account e identificare opportunità (upsell, cross-sell, rinnovi)
- Step 3, offerta: generare proposta economica basata su listino, scontistiche autorizzate e volumi (con guardrail su sconti massimi)
- Step 4, controllo di conformità: verificare che l'offerta rispetti policy aziendali, margini minimi e termini contrattuali standard
- Step 5, output: bozza di offerta e punti di discussione, che il commerciale rivede e approva
- Metriche da seguire: tempo di preparazione di un’offerta prima e dopo, offerte conformi alle policy (tutte), quota del team commerciale che lo usa davvero
Quando NON usare un agente
Non tutti i problemi richiedono un agente AI. Prima di investire in un agente, il team di consulenza Niuexa valuta se il caso d'uso giustifica la complessità agenziale. Evitare l'approccio agenziale quando:
- Il task è deterministico: se l'input mappa direttamente a un output senza ragionamento (es. lookup in tabella), un workflow tradizionale è più veloce, affidabile ed economico
- La latenza è critica (< 200ms): ogni chiamata a un LLM aggiunge in genere da qualche centinaio di millisecondi a qualche secondo. Per risposte sotto il secondo servono sistemi a regole o ML tradizionale
- Il volume è altissimo e il valore per interazione è basso: se il costo per token supera il margine generato dall'automazione, l'agente non è sostenibile
- Non esistono dati per valutare la correttezza: senza un golden set e metriche oggettive, non si può sapere se l'agente funziona o no
- Il dominio vieta decisioni algoritmiche opache: in alcuni contesti normativi (credito al consumo, assunzioni), le decisioni devono essere spiegabili e auditabili in modo che un agente LLM non può garantire
Domande frequenti su tool e pratiche per agenti AI
Quali tool servono per creare un agente AI in produzione?
Per un agente AI in produzione servono almeno cinque categorie di tool: un LLM con supporto nativo al tool calling (per esempio OpenAI GPT-5 o Anthropic Claude), un framework di orchestrazione (LangChain, LlamaIndex o un SDK custom), una pipeline RAG con vector database (Pinecone, Weaviate, Qdrant), una piattaforma di osservabilità (LangSmith, Arize, Helicone) e un sistema di guardrail per applicare le policy e validare gli output.
Qual è la differenza tra LangChain e LlamaIndex per agenti AI?
LangChain è più adatto all’orchestrazione di catene multi-step e di agenti con tool calling complesso: offre molta flessibilità, con una curva di apprendimento più ripida. LlamaIndex è pensato per pipeline RAG e agenti che lavorano soprattutto sul retrieval, con un’API più semplice per i casi d’uso incentrati sulla knowledge base. Per agenti che interrogano dati aziendali LlamaIndex è spesso più rapido da prototipare; per workflow complessi con molti tool LangChain dà più controllo.
Che differenza c’è tra AI generativa e agentic AI?
L’AI generativa produce un contenuto (testo, codice, immagini) in risposta a una richiesta, e una persona decide cosa farne. L’agentic AI riceve un obiettivo, pianifica i passi, usa tool come API, database ed email per eseguirli e gestisce gli errori lungo il percorso. Per questo un agente richiede controlli che un assistente generativo non richiede: permessi minimi sui sistemi, evals, tracciamento di ogni azione e approvazione di una persona per le azioni irreversibili.
Cosa sono i sistemi multi-agente e quando servono?
Sono architetture in cui più agenti specializzati collaborano, coordinati da un orchestratore o in sequenza, per completare un processo. Servono quando un agente unico dovrebbe gestire troppi tool o competenze diverse e le evals mostrano che sbaglia per questo. Negli altri casi un agente solo è più semplice da testare, costa meno ed è più facile da controllare.
Conviene usare la piattaforma per agenti del proprio fornitore?
Spesso sì, se l’azienda lavora già in quell’ecosistema: Microsoft Copilot Studio per Microsoft 365, Salesforce Agentforce per il CRM, le piattaforme di Google Cloud e AWS per chi ha lì l’infrastruttura. Si parte più in fretta e si ereditano permessi e sicurezza. Prima di scegliere conviene verificare se prompt, configurazioni e log si possono esportare, se si possono eseguire le proprie evals e come si calcola il costo per conversazione.
Come si testa un agente AI prima di andare in produzione?
Su più livelli: 1) unit test sui singoli tool con input e output deterministici; 2) un golden set di 50-200 casi reali con risposte attese; 3) metriche automatiche (Task Success Rate, groundedness) con soglie fissate prima dei test; 4) LLM-as-judge per valutare la qualità delle risposte; 5) red teaming con prompt avversariali; 6) test di regressione automatici in CI/CD a ogni modifica. Il golden set va aggiornato ogni mese con i casi di errore raccolti in produzione.
Cosa sono i guardrail per agenti AI e perché servono?
Sono i meccanismi che impediscono a un agente AI di compiere azioni dannose, non autorizzate o fuori policy: un policy engine che filtra input e output, una allowlist di azioni consentite, una sandbox per eseguire codice in sicurezza, la validazione dello schema di ogni tool call, limiti di budget e rate limiting, un kill switch per la disattivazione immediata e un audit trail completo di ogni decisione. Senza guardrail, un agente in produzione può generare costi fuori controllo, esporre dati sensibili o eseguire azioni irreversibili.
Quanto costa mettere in produzione un agente AI?
Non esiste un prezzo di listino. Il costo di sviluppo dipende dal numero di tool, dalle integrazioni con i sistemi aziendali, dalla qualità dei dati, dai requisiti di sicurezza e dal livello di supervisione umana; quello di esercizio da token consumati, infrastruttura (vector database e compute), osservabilità e manutenzione del golden set. Conviene confrontarlo con il costo attuale del processo e farsi dare un preventivo scritto che separi sviluppo ed esercizio. In Niuexa il costo si definisce dopo l’analisi; la prima chiamata di 30 minuti è gratuita.
Quando NON conviene usare un agente AI?
Quando: 1) il task è deterministico e non richiede ragionamento (meglio un workflow tradizionale); 2) la latenza richiesta è sotto i 200 ms (una chiamata a un LLM richiede in genere da qualche centinaio di millisecondi a qualche secondo); 3) il volume è così alto che il costo dei token supera il valore generato; 4) non esistono dati per valutare la correttezza dell’output; 5) il dominio ha requisiti di compliance che vietano decisioni algoritmiche opache; 6) il team non ha le competenze per mantenere evals e guardrail nel tempo.
Conclusione: checklist finale per agenti AI in produzione
Costruire un agente AI che funziona in produzione non è questione di scegliere il framework giusto o il modello più potente. È questione di integrare tool e practice in un processo ingegneristico ripetibile. Questa checklist riassume i requisiti minimi per il go-live.
Checklist di produzione Niuexa
- Obiettivo definito con KPI misurabili e failure modes mappati
- Golden set di almeno 50 esempi reali validati da esperti di dominio
- Pipeline RAG con retrieval evaluation (precision@k, recall@k)
- Tool registry completo con JSON Schema, policy e rate limit per ogni tool
- Suite di evals automatiche con soglie decise prima dei test (TSR, groundedness)
- Red teaming completato (prompt injection, jailbreak, input fuori dominio)
- Guardrail attivi: policy engine, allowlist, PII filtering, kill switch
- Osservabilità end-to-end: tracing, cost tracking, alerting
- Human-in-the-loop configurato per azioni ad alto rischio
- Incident response playbook scritto e testato
- Rollout plan con canary al 5-10% e criteri di go/no-go
- Cost governance: budget ceiling, dashboard costi, ottimizzazione token
Gli agenti AI più affidabili non sono quelli con il modello più potente, ma quelli con il processo di ingegneria più maturo: evals solide, guardrail rigorosi, osservabilità completa e un team che torna ogni settimana sui failure modes.
Ci mostri un processo
Se sta valutando un agente AI, in una prima chiamata di 30 minuti, gratuita, guardiamo insieme il processo e Le diciamo se un agente ha senso, se basta un workflow più semplice o se l’AI lì non serve. Perimetro e costo di un eventuale progetto si definiscono in un preventivo scritto, dopo l’analisi.
Prenoti la prima chiamata