Un assistente AI in produzione nella Pubblica Amministrazione raramente nasce per servire un solo caso d’uso. Lo stesso impianto tecnologico, la stessa pipeline di acquisizione delle fonti, lo stesso modello, gli stessi controlli di qualità si trovano progressivamente a rispondere a esigenze diverse.
Un cliente chiede di filtrare le ricerche su un sottoinsieme dei dati a lui pertinente; un altro ha bisogno di esporre informazioni strutturate oltre al testo libero; un terzo richiede di limitare l’accesso dell’assistente ai dati sulla base del gruppo di appartenenza dell’utente. A ogni nuova esigenza, una scelta tecnica apparentemente piccola si presenta: come dare all’assistente un nuovo strumento senza dover riscrivere o duplicare ciò che già esiste.
La risposta più naturale, in prima battuta, è costruire di volta in volta uno strumento dedicato: un nuovo componente nel codice, con la sua logica di interrogazione, i suoi parametri, le sue eccezioni. È così che molti sistemi, dopo qualche iterazione, si ritrovano con quattro o cinque varianti dello stesso strumento di ricerca documentale, varianti che differiscono solo per il filtro applicato o per il modo in cui i risultati vengono restituiti, ognuna con il proprio codice da mantenere, replicando la superficie di errore e le vulnerabilità potenziali.
Questo schema funziona, ma non scala. Il collo di bottiglia non è la qualità del modello né l’infrastruttura, bensì la velocità con cui la conoscenza di dominio, di chi conosce la materia, le procedure, le regole, può essere tradotta in nuove funzionalità dell’assistente senza richiedere ogni volta nuovi sviluppi. È un problema noto a chi sviluppa software da tempo: un prodotto che cresce per accumulo di varianti diventa progressivamente più difficile da governare, indipendentemente dalla tecnologia sottostante. La domanda che la PA si trova a porsi, oggi, riguarda proprio l’estensione di questo principio al lavoro di costruzione di assistenti AI.
Indice degli argomenti
Due alternative architetturali e perché non bastano
Prima di vedere come affrontiamo questo problema in CSI, vale la pena considerare due risposte alternative già attualmente in uso in applicazioni di AI agentica.
La prima è quella che si potrebbe definire l’approccio agentico in senso pieno: invece di costruire strumenti specifici per ogni esigenza, si espongono al modello interfacce di accesso ai dati molto generali, leggere file, eseguire query, navigare strutture, e si delega al modello stesso la composizione delle azioni necessarie a rispondere a una domanda. È il paradigma alla base di molti assistenti per sviluppatori e di alcuni recenti agenti autonomi. È un paradigma efficace nei contesti per cui è stato pensato: ambienti in cui l’utente è proprietario dei dati su cui l’agente opera, conosce e può controllare la superficie a cui dà accesso, e si assume direttamente la responsabilità delle azioni che il modello compie.
La seconda, limitata ai casi d’uso di lettura dei documenti, è il ricorso a finestre di contesto molto ampie. La finestra di contesto è la quantità massima di testo che un modello può considerare in una singola interazione; i modelli più recenti accettano centinaia di migliaia, in alcuni casi milioni, di token in input. La proposta è semplice: invece di costruire un sistema di recupero con filtri, fornire all’assistente l’intero corpus rilevante a ogni interazione e lasciare che sia il modello a individuare le informazioni pertinenti.
Figura 1: Tre approcci per estendere un assistente AI (da sinistra a destra): massima flessibilità agentica, estensione finestra di contesto, composizione dichiarativa di capacità governate.
In entrambi i casi, il presupposto comune è quello di spostare l’onere della selezione dal sistema al modello, ed è in effetti un presupposto coerente con la crescita di capacità dei modelli stessi. Ma in un contesto come quello della Pubblica Amministrazione, due osservazioni vanno affiancate a queste proposte.
La prima è di natura economica e operativa, e riguarda soprattutto l’approccio a contesto ampio. Il costo e il tempo di risposta per interazione crescono in modo proporzionale alla dimensione del contesto fornito, e su volumi di produzione, decine di migliaia di interazioni mensili, su sistemi pensati per essere sostenibili nel tempo, questa scelta diventa rapidamente insostenibile. Inoltre, ad un contesto più ampio si accompagna una minore precisione nel recupero delle informazioni pertinenti, aumentando la probabilità di allucinazioni.
La seconda, più sostanziale, riguarda l’auditabilità e la sicurezza dell’accesso ai dati, e tocca soprattutto il paradigma agentico generale. Un assistente che opera per la PA deve poter rispondere alla domanda: su quale fonte specifica si fonda questa risposta, e con quale criterio è stata selezionata? Quando la selezione delle informazioni è interna al modello, ricondurre una risposta a una fonte tracciabile diventa un problema aperto. A questo si aggiunge una considerazione di sicurezza che non dipende dalla bontà del modello: fornire a un assistente conversazionale un’interfaccia generale di accesso ai dati significa esporre, nel perimetro del modello stesso, e quindi della sua interazione con utenti potenzialmente avversari, una superficie più ampia di quella richiesta dal caso d’uso. Nei nostri test automatizzati, condotti anche simulando tentativi di uso improprio dell’assistente, abbiamo verificato che tentativi di forzare il perimetro del caso d’uso, aggirare i filtri previsti o indurre l’assistente a utilizzare strumenti non pertinenti diventano più difficili da governare quanto più generale è l’interfaccia di accesso concessa al modello. Per questo la sicurezza non può essere affidata solo al comportamento atteso del modello, ma deve essere incorporata nell’architettura degli strumenti e dei relativi permessi.
Questi due aspetti non ci spingono a rifiutare il paradigma agentico, ma a definirne il perimetro di azione in modo che la flessibilità che offre non si traduca in moltiplicazione del codice da mantenere o in superficie di accesso non necessaria. La domanda diventa quindi: come si costruisce concretamente un’architettura che permetta questo controllo senza pagarla in tempi di sviluppo?
Strumenti come artefatti dichiarativi: il riuso al posto della riscrittura
La risposta che abbiamo costruito in CSI parte da un’osservazione: la maggior parte degli strumenti che servono a un assistente AI non sono davvero diversi tra loro. Una ricerca semantica filtrata per categoria di documento, una filtrata per area territoriale, una limitata ai soli contenuti accessibili a un certo gruppo di utenti, condividono un’unica logica di base. A cambiare sono i parametri, quale filtro applicare, quale campo dei metadati interrogare, quale soglia di rilevanza adottare, non l’operazione di base sottostante.
Da qui la scelta architetturale: separare ciò che è veramente comune da ciò che è specifico al caso d’uso. La parte comune, l’accesso al motore di ricerca, l’interrogazione strutturata sui metadati, la gestione della memoria conversazionale, viene costruita una volta sola, sotto forma di un piccolo insieme di primitive: componenti generali, mantenuti centralmente, sottoposti a verifiche di sicurezza e a test di regressione. La parte specifica, quale primitiva utilizzare, con quali parametri, esposta all’assistente con quale nome e quale descrizione, viene invece dichiarata in configurazione, in file YAML versionati come ogni altro artefatto di progetto. Aggiungere un nuovo strumento non richiede toccare il codice del sistema: significa dichiarare in configurazione come una primitiva esistente debba essere esposta all’assistente e specializzata per il caso d’uso desiderato, attraverso nome, descrizione, e relativi parametri.
A rendere praticabile questa separazione è stata l’adozione del Model Context Protocol (MCP), uno standard aperto che si sta rapidamente affermando come riferimento per l’integrazione di strumenti negli assistenti AI.
Figura 2: Dalla duplicazione di strumenti e codice alla dichiarazione di capacità riusabili usando primitive comuni.
Questo standard definisce un linguaggio comune con cui un assistente può scoprire e invocare gli strumenti messi a sua disposizione, indipendentemente da come questi siano implementati internamente. Per noi, MCP non è solo un protocollo di interoperabilità: è il punto in cui si appoggia la separazione tra le primitive, costruite e verificate dal gruppo di sviluppo, e la loro composizione in strumenti effettivi, che può essere gestita dagli esperti di materia, ovvero coloro che conoscono meglio i requisiti e le esigenze di ciascun caso d’uso.
Il risultato è una simbiosi tra due nature opposte: uno schema dichiarativo, rigido per costruzione e quindi auditabile, e un modello linguistico, flessibile e capace di gestire le richieste in tutta la varietà del linguaggio naturale. La rigidità è dove serve, nella definizione di cosa l’assistente può fare e su quali dati. La flessibilità è dove conta, nell’interpretazione di ciò che l’utente sta chiedendo e nella scelta dello strumento da invocare.
L’implementazione: un server MCP interno e una catalogazione dichiarativa
Concretamente, l’architettura che abbiamo costruito si articola attorno a un server MCP interno, sviluppato in casa e installato come componente comune dei progetti che ne fanno uso. Il server espone un insieme limitato di primitive: la ricerca semantica su una base documentale combinata con eventuali filtri sui relativi metadati, la lettura e scrittura della memoria conversazionale dell’assistente, e invocazioni di API e servizi esterni, per citare alcuni esempi. Sono operazioni a basso livello, indipendenti dal singolo caso d’uso, e mantenute centralmente da un unico team responsabile della loro evoluzione e della loro sicurezza.
Sopra le primitive si colloca uno strato di configurazione. Ogni strumento esposto a un assistente, quello che il modello vede e invoca, è dichiarato in un file di configurazione che ne definisce nome e descrizione, e lo associa ad una primitiva sottostante, specificando come i parametri ricevuti dall’assistente si traducono in parametri della primitiva. Aggiungere un nuovo strumento di ricerca filtrata su un campo metadati specifico, in pratica, significa scrivere una decina di righe di configurazione: il nome con cui l’assistente conoscerà lo strumento, la descrizione che lo aiuterà a sceglierlo nel contesto giusto, il riferimento alla primitiva di ricerca, e la regola che lega l’argomento ricevuto al filtro applicato. Nessuna riga di codice viene scritta o modificata.
Questa separazione produce un effetto operativo immediato. Le quattro o cinque varianti di strumento di ricerca menzionate all’inizio non sono più quattro o cinque componenti distinti da costruire e mantenere, ma quattro o cinque dichiarazioni di configurazione che si appoggiano alla stessa primitiva. La realizzazione di un assistente per un nuovo cliente, in casi che fino a poco tempo fa avrebbero richiesto 4-5 giorni di sviluppo, oggi può essere espressa in poche ore, dedicate alla comprensione del dominio e alla definizione degli strumenti necessari più che alla loro implementazione tecnica.
Figura 3: Dal codice alla configurazione: mock-up grafico che descrive la futura evoluzione del backoffice chatbot, che consentirà agli esperti di dominio di trasformare esigenze operative in strumenti governati per l’assistente AI.
Il passo successivo, in fase di progettazione, riguarda chi materialmente compone questi strumenti. Stiamo infatti lavorando al prossimo passo naturale in questa direzione: estendere la nostra esistente interfaccia di backoffice chatbot in modo da permettere agli analisti di dominio, chi conosce i bandi, le procedure amministrative, i flussi documentali del cliente, di comporre nuovi strumenti senza intermediari. È il completamento naturale dell’architettura: separare le primitive dalla loro declinazione nei singoli strumenti esposti agli assistenti esprime la sua massima utilità se la composizione può essere fatta in autonomia anche da esperti di materia, e non solo da figure tecniche e sviluppatori.
Tre conseguenze rilevanti per la PA
La separazione tra primitive e composizioni produce tre effetti che meritano di essere considerati nel contesto delle scelte architetturali della PA.
Governance e separazione delle responsabilità. Le primitive definiscono cosa è permesso fare; le composizioni definiscono cosa si fa nel singolo caso d’uso. La revisione di sicurezza si applica a un piccolo insieme di primitive, mantenute centralmente, anziché a ogni nuovo strumento costruito ad hoc. Estensibilità e controllo nascono dalla stessa scelta architetturale, non da compromessi tra le due.
Riduzione del debito tecnico. Una capacità dichiarata in configurazione non è codice da mantenere. La codebase resta piccola anche quando il numero di assistenti e di casi d’uso cresce; il dominio scala separatamente, attraverso file di configurazione versionati. Una correzione apportata a una primitiva si propaga automaticamente a tutti gli strumenti che la utilizzano, senza che sia necessario individuare e aggiornare ogni variante.
Standardizzazione e interoperabilità. L’adozione di un protocollo aperto, invece di un’astrazione interna proprietaria, significa che il lavoro di estensione è leggibile da chiunque conosca lo standard, trasferibile tra progetti e tra organizzazioni, e allineato a un ecosistema in rapida diffusione. È una scelta che riduce il rischio di lock-in tecnologico e che facilita la collaborazione tra enti diversi che adottino la stessa architettura.
Cosa cambia per la capacità di AI nella PA
L’esperienza che abbiamo descritto mostra come una scelta architetturale, separare le primitive dalla loro composizione, modifichi le condizioni operative in cui un’organizzazione costruisce assistenti AI. Il collo di bottiglia si sposta dalla disponibilità di sviluppatori alla disponibilità di esperti di dominio, rendendo più rapida e precisa la traduzione delle specifiche applicative in un prodotto di Agentic AI che vi risponda. Il protocollo è aperto, l’architettura è replicabile: altri enti che si trovino oggi davanti allo stesso problema, più assistenti da costruire di quanti ne possano essere sviluppati uno per volta, possono adottare lo stesso approccio. È una direzione concreta per far crescere l’AI nella PA non solo attraverso nuovi casi d’uso, ma attraverso capacità comuni: componenti riusabili, regole condivise, strumenti governati e un modello di evoluzione sostenibile nel tempo.
Partecipa alla community