Contesto, valutazione e limiti operativi: i tre elementi essenziali per progettare agenti AI realmente utili
Quando si parla di agenti di intelligenza artificiale, l’attenzione si concentra spesso sul modello utilizzato e sulla qualità del prompt.
Quale modello scegliere? Come formulare istruzioni più efficaci? Quanto deve essere dettagliata la richiesta?
Sono domande legittime, ma rischiano di farci perdere di vista il punto principale: un AI Agent non coincide con il modello linguistico che utilizza.
La sua affidabilità non dipende soltanto dal modello o dalla lunghezza del prompt. Dipende soprattutto dal sistema costruito intorno al modello: dalle informazioni che può consultare, dai criteri utilizzati per valutarlo e dalle regole che stabiliscono cosa può fare, cosa non può fare e quando deve coinvolgere una persona.
- Contesto: ciò che l’agente deve sapere
- Evals: come viene valutato
- Capacità e limiti: cosa può fare e quando deve fermarsi
Questi tre elementi descrivono le dimensioni essenziali di un sistema agentico: ciò che l’agente conosce, il modo in cui viene valutato e le condizioni entro cui può trasformare una decisione in un’azione.
1. Il contesto: cosa deve sapere l’agente
Il primo elemento è il contesto.
Negli ultimi anni, gran parte del dibattito sull’intelligenza artificiale generativa si è concentrato sul prompt engineering. Si è diffusa l’idea che per ottenere un risultato migliore fosse sufficiente scrivere istruzioni sempre più lunghe e dettagliate.
In realtà, un prompt più lungo non è necessariamente un prompt migliore.
Spesso è la capacità di sintetizzare, eliminare le informazioni superflue e fornire soltanto gli elementi rilevanti ad aiutare il modello a lavorare con maggiore precisione.
Il contesto non comprende soltanto il testo inserito dall’utente. Include tutto ciò che il sistema mette a disposizione dell’agente:
- istruzioni operative;
- memoria delle conversazioni precedenti;
- documentazione tecnica e procedure interne;
- fonti informative, come database e archivi;
- servizi e strumenti esterni, accessibili direttamente o tramite API;
- servizi e strumenti esterni, accessibili quando necessario tramite API;
- profilo e autorizzazioni dell’utente;
- stato del processo in corso.
È importante distinguere le informazioni dai meccanismi con cui vengono raggiunte. Un’API non è un dato e non è, di per sé, una fonte di conoscenza: è un’interfaccia che consente all’agente di interrogare un servizio, recuperare informazioni oppure attivare una funzione. Le API appartengono quindi soprattutto al livello delle integrazioni e degli strumenti, mentre documenti, archivi e database costituiscono le fonti informative.
Il problema, quindi, non è soltanto capire come scrivere una richiesta efficace. Occorre progettare quali informazioni il modello deve vedere nel momento in cui deve rispondere o prendere una decisione.
Per questo si parla sempre più spesso di context engineering, cioè della progettazione e dell’organizzazione del contesto necessario all’agente.
Più informazioni non significa più intelligenza
Fornire al modello tutti i dati disponibili può sembrare una scelta prudente, ma spesso produce l’effetto contrario.
Un contesto troppo limitato genera risposte generiche o incomplete. Un contesto eccessivo può invece introdurre rumore, informazioni obsolete, contraddizioni, dati irrilevanti, maggiori costi di elaborazione e difficoltà nel riconoscere le priorità.
La qualità del sistema dipende dalla capacità di stabilire quali informazioni servono, quando devono essere recuperate, da quali fonti, con quale livello di aggiornamento, per quanto tempo devono essere conservate e quali dati non devono essere mostrati al modello.
La progettazione del contesto diventa così una vera attività architetturale.
Un esempio nella Smart City
Immaginiamo un agente incaricato di supportare la gestione della mobilità urbana.
L’agente non ha bisogno di accedere indistintamente a tutti i dati presenti nei sistemi comunali. Per affrontare una specifica richiesta potrebbe aver bisogno di:
- dati sul traffico in tempo reale;
- stato del trasporto pubblico;
- incidenti e lavori stradali;
- condizioni meteorologiche e calendario degli eventi;
- disponibilità dei parcheggi;
- vincoli amministrativi;
- storico delle decisioni adottate.
Il sistema diventa efficace non perché conosce tutto, ma perché riceve informazioni pertinenti, sufficienti e aggiornate rispetto al problema da risolvere.
2. Le evals: come valutare l’agente
Il secondo elemento è rappresentato dalle evals, abbreviazione di evaluations.
Le evals sono test, metriche e procedure utilizzati per verificare se un agente svolge correttamente il compito per cui è stato progettato.
La valutazione non dovrebbe essere introdotta soltanto alla fine del progetto. Dovrebbe essere definita prima della costruzione dell’agente.
Occorre stabilire in anticipo:
- cosa deve saper fare;
- quali risultati sono considerati corretti;
- quali errori sono tollerabili e quali sono critici;
- quando deve chiedere informazioni aggiuntive;
- quando deve interrompere l’attività;
- quali prestazioni deve raggiungere prima di entrare in produzione;
- come verranno misurati qualità, costi e tempi di risposta.
Senza criteri di valutazione chiari, il miglioramento procede per tentativi.
Si modifica il prompt, si aggiunge una regola, si cambia modello e si osserva il risultato. Senza metriche, però, non è possibile sapere se il sistema sia davvero migliorato o abbia semplicemente iniziato a produrre errori differenti.
Dal prototipo alla produzione
Portare un agente da zero a uno può essere relativamente semplice.
Una prima dimostrazione può apparire convincente, soprattutto quando viene testata su pochi casi prevedibili e in condizioni controllate.
La difficoltà emerge quando il sistema deve operare con utenti differenti, su grandi quantità di dati, in situazioni impreviste, attraverso strumenti esterni e su processi che producono conseguenze reali.
È nel passaggio dal prototipo alla produzione che le evals diventano indispensabili.
Non basta chiedersi se l’agente ‘sembra funzionare’. Occorre verificare sistematicamente:
- quanto è affidabile;
- in quali condizioni fallisce;
- con quale frequenza commette errori;
- quali conseguenze producono gli errori;
- quanto costa eseguire il processo;
- quando è necessario l’intervento umano.
Ogni errore deve migliorare il sistema
Un aspetto essenziale riguarda la gestione delle correzioni.
Durante i primi utilizzi è normale accorgersi che l’agente abbia dimenticato un’informazione, seguito una procedura incompleta o interpretato male una richiesta.
Correggerlo nella singola conversazione non basta.
Se diciamo al modello: ‘La prossima volta comportati in questo modo’, quella correzione dovrebbe trasformarsi in un elemento stabile del sistema:
- una nuova istruzione;
- un caso di test;
- un aggiornamento della documentazione;
- una modifica al contesto;
- un controllo automatico;
- una nuova regola di escalation.
L’errore non viene soltanto corretto. Diventa materiale per il miglioramento continuo.
Le evals non servono quindi soltanto ad assegnare un punteggio all’agente. Servono a trasformare il feedback umano in un’evoluzione sistematica e verificabile del prodotto.
3. Cosa può fare l’agente e dove deve fermarsi
Un agente AI non si limita necessariamente a generare una risposta testuale.
Può consultare fonti informative, modificare un documento, compilare un modulo, inviare una comunicazione, aggiornare un sistema gestionale o attivare un processo.
La capacità di portare a termine concretamente un compito viene spesso indicata con il termine fulfillment.
Quando l’agente interagisce con applicazioni o servizi esterni, un’API può essere il canale tecnico che rende possibile l’operazione. Non va confusa con il dato: definisce come richiedere un’informazione o come inviare un comando al sistema collegato.
Più un agente è capace di agire, più diventa necessario stabilire con precisione i suoi limiti operativi.
Occorre definire:
- cosa può fare e cosa non può fare;
- quali strumenti e servizi esterni può utilizzare;
- a quali fonti e dati può accedere;
- quali file può leggere o modificare;
- quali operazioni richiedono un’autorizzazione o una conferma;
- quando deve fermarsi;
- quando deve coinvolgere una persona;
- quali attività devono essere registrate e controllate.
Queste regole vengono spesso chiamate guardrail. Il termine tecnico è utile, ma il concetto è semplice: l’agente deve conoscere il perimetro entro cui può operare.
Un agente affidabile deve sapere non soltanto come svolgere un’attività, ma anche quando non deve svolgerla.
Il ruolo dell’escalation umana
Non tutte le decisioni possono o devono essere automatizzate.
Quando una richiesta è ambigua, comporta conseguenze rilevanti oppure supera le autorizzazioni disponibili, l’agente dovrebbe interrompere il flusso e coinvolgere una persona.
Torniamo al caso della mobilità urbana.
Un agente potrebbe suggerire una modifica temporanea alla regolazione semaforica sulla base dei dati sul traffico. Potrebbe anche essere autorizzato ad applicare automaticamente variazioni minime entro soglie prestabilite.
Se la modifica interessasse un’area critica, un percorso di emergenza o un cambiamento significativo alla viabilità, il sistema dovrebbe invece richiedere l’approvazione di un operatore.
Il limite operativo non rappresenta un ostacolo all’innovazione. È ciò che permette di utilizzare l’innovazione senza rinunciare a responsabilità, sicurezza e controllo.
4. Il vero prodotto è il sistema intorno al modello
Contesto, evals e limiti operativi mostrano che il modello linguistico è soltanto una componente dell’agente.
Il risultato finale dipende dall’intera architettura:
- il contesto determina ciò che il modello conosce;
- le evals verificano la qualità del suo comportamento;
- il fulfillment trasforma le decisioni in azioni;
- le integrazioni collegano l’agente a fonti e servizi esterni, anche tramite API;
- le regole operative delimitano autonomia e responsabilità;
- la supervisione umana gestisce eccezioni e situazioni critiche.
La vera intelligenza del sistema non risiede quindi soltanto nel modello, ma nell’organizzazione delle informazioni, degli strumenti, delle regole e dei controlli che lo circondano.
5. AI Agent e Smart Polis Policentrica
Questo approccio è particolarmente rilevante nel modello della Smart Polis Policentrica.
Una città intelligente non dovrebbe dipendere da un unico agente centrale incaricato di prendere ogni decisione. È più realistico immaginare una rete di agenti specializzati in differenti domini:
- mobilità;
- energia;
- ambiente;
- sicurezza;
- manutenzione urbana;
- servizi sociali;
- partecipazione civica;
- amministrazione.
Ogni agente dovrebbe operare all’interno di un contesto specifico, utilizzare soltanto fonti autorizzate, essere sottoposto a valutazioni dedicate e agire entro limiti chiaramente definiti.
Gli agenti potrebbero collaborare tra loro, condividere informazioni e coordinare le attività, mantenendo però una separazione delle responsabilità.
La supervisione umana non verrebbe eliminata. Cambierebbe forma: dall’esecuzione manuale di ogni attività alla progettazione, osservazione e governance dell’ecosistema.
6. Cinque domande prima di mettere un agente in produzione
Prima di affidare un processo a un agente AI, un’organizzazione dovrebbe rispondere almeno a cinque domande:
- Quali informazioni deve ricevere per svolgere correttamente il compito?
- Come misureremo la qualità dei risultati?
- Quali azioni può eseguire autonomamente?
- In quali condizioni deve fermarsi e coinvolgere una persona?
- Come trasformeremo errori e feedback in miglioramenti strutturali?
Se queste risposte non sono chiare, probabilmente non è ancora pronto l’agente. È pronto soltanto il prototipo.
Conclusione
Costruire un agente AI non significa trovare il prompt perfetto.
Significa progettare un sistema capace di accedere al contesto corretto, misurare il proprio comportamento e trasformare le decisioni in azioni entro confini verificabili.
I tre elementi fondamentali sono:
- Contesto, per fornire all’agente le informazioni realmente necessarie.
- Evals, per misurarne il comportamento e trasformare gli errori in miglioramenti strutturali.
- Capacità operative e limiti, per consentirgli di agire entro regole, autorizzazioni e procedure di escalation chiare.
La vera sfida non consiste nel creare agenti sempre più autonomi a ogni costo.
Consiste nel costruire ecosistemi di intelligenza artificiale affidabili, misurabili, trasparenti e capaci di collaborare con le persone. È questo il passaggio decisivo: dal prompt engineering alla progettazione di sistemi intelligenti.