A cura di Giovanni Masi
Un chatbot che risponde bene durante una dimostrazione può essere costruito in pochi giorni. Il vero lavoro comincia quando quello stesso sistema deve servire migliaia di persone, consultare documenti aziendali, rispettare permessi differenti e mantenere un livello di qualità accettabile dopo ogni aggiornamento.
È in questo passaggio che molti progetti di intelligenza artificiale generativa mostrano la propria fragilità. Una risposta sbagliata può dipendere dal modello, ma anche da un prompt modificato male, da un documento non aggiornato o da uno strumento esterno che ha restituito informazioni incomplete. Individuare la causa richiede una disciplina operativa specifica.
LLMOps nasce per rispondere a questa esigenza. Riunisce metodi e strumenti impiegati per sviluppare, valutare, distribuire e sorvegliare applicazioni fondate sui large language model. Nel frattempo, il settore si è mosso oltre i primi chatbot. Alle pratiche di LLMOps si affiancano oggi espressioni come GenAIOps e AgentOps, ancora prive di una tassonomia condivisa, che riflettono l’ingresso in produzione di sistemi più articolati e capaci di agire.
Il modello è soltanto la parte visibile
Una moderna applicazione generativa raramente coincide con una singola chiamata a un LLM. Dietro la risposta possono esserci un prompt di sistema, un motore di ricerca semantica, un archivio vettoriale, filtri di sicurezza, servizi aziendali e regole che stabiliscono quale modello utilizzare.
Questa composizione rende l’applicazione flessibile, ma aumenta il numero dei punti nei quali qualcosa può andare storto. Cambiare il modello di embedding può alterare i documenti recuperati. Una nuova versione del prompt può migliorare alcune richieste e peggiorarne altre. Persino un aggiornamento della base documentale, se non controllato, può introdurre contenuti duplicati o informazioni non più valide.
Per ricostruire il comportamento del sistema occorre versionare l’intera configurazione. Codice, prompt, modelli, parametri di inferenza, indici documentali e criteri di accesso devono essere associati a una precisa release. La riproducibilità, scontata in altri settori del software, diventa qui una conquista tecnica.
La qualità non si misura con una sola percentuale
I modelli predittivi tradizionali possono essere confrontati attraverso metriche relativamente stabili. Le risposte linguistiche sono più difficili da valutare. Due formulazioni diverse possono essere entrambe corrette; un testo impeccabile dal punto di vista grammaticale può contenere un errore sostanziale.
La valutazione deve quindi partire dal caso d’uso. Un assistente destinato al supporto clienti richiede test diversi da quelli necessari per un sistema che analizza contratti o produce codice. Servono raccolte di domande realistiche, casi limite, errori già osservati e risultati attesi definiti con il contributo degli esperti del dominio.
A questo patrimonio di esempi vengono applicati controlli automatici, regole deterministiche, revisioni umane e valutatori basati su altri modelli. Questi ultimi, spesso indicati come LLM-as-a-judge, permettono di analizzare grandi quantità di risposte, ma non costituiscono arbitri infallibili. Possono privilegiare una forma espositiva, interpretare male un criterio o assegnare un buon punteggio a un testo convincente ma poco fondato. La loro utilità cresce quando i giudizi vengono calibrati sulle valutazioni umane e riesaminati periodicamente.
Ogni risposta deve lasciare una traccia
I normali log applicativi indicano se una richiesta è andata a buon fine. Per capire il comportamento di un sistema generativo serve una registrazione più profonda.
Una traccia può mostrare quale prompt è stato inviato, quali documenti sono stati recuperati, quanto tempo ha richiesto ogni passaggio e quante risorse sono state consumate. Nei sistemi agentici registra anche gli strumenti selezionati, gli argomenti utilizzati e gli eventuali tentativi ripetuti.
Queste informazioni modificano il modo di affrontare gli errori. Una risposta imprecisa non viene più attribuita genericamente all’“allucinazione del modello”. Si può verificare se il documento corretto fosse presente, se il retriever lo abbia trovato e se il modello abbia utilizzato davvero il contenuto ricevuto.
OpenTelemetry sta consolidando convenzioni semantiche dedicate all’AI generativa per descrivere in maniera uniforme chiamate ai modelli, token, prompt e tool call. Il lavoro è ancora in evoluzione, ma indica la direzione del settore: integrare l’osservabilità dell’AI negli strumenti già usati per controllare applicazioni e infrastrutture.
Quando il chatbot comincia ad agire
Il salto più delicato arriva con gli agenti. Un assistente conversazionale produce una risposta; un agente può interrogare database, eseguire codice, modificare file o attivare processi aziendali. Il risultato finale racconta soltanto una parte della sua condotta.
Nel gennaio 2026 OpenAI ha descritto un agente interno progettato per analizzare una piattaforma composta, secondo l’azienda, da oltre 600 petabyte distribuiti in circa 70.000 dataset. Il sistema è accessibile da Slack, interfacce web, ambienti di sviluppo e strumenti collegati tramite Model Context Protocol. Dietro una domanda in linguaggio naturale si sviluppa una sequenza di ricerca, selezione delle tabelle, scrittura delle query e verifica dei risultati.
Un’architettura simile chiarisce perché non basti giudicare l’ultima frase. Occorre controllare il percorso seguito, i dati consultati, il numero di passaggi e le autorizzazioni utilizzate.
L’impiego di un agente, peraltro, non è sempre giustificato. Nei processi prevedibili una pipeline tradizionale può offrire maggiore velocità e controllo. I sistemi agentici hanno senso quando il compito è aperto, richiede decisioni intermedie e non può essere descritto in anticipo come una sequenza rigida.
La sicurezza dipende da ciò che il sistema può fare
La prompt injection rimane uno dei rischi più difficili da contenere. Le istruzioni malevole possono arrivare direttamente dall’utente oppure essere nascoste in una pagina web, in un documento o in una comunicazione acquisita dall’applicazione.
Il pericolo aumenta quando il modello dispone di strumenti operativi. OWASP ha dedicato una classificazione specifica ai sistemi agentici, includendo rischi come il dirottamento degli obiettivi, l’uso improprio degli strumenti, l’abuso dei privilegi e l’avvelenamento della memoria.
Affidare la difesa al solo prompt è insufficiente. Le protezioni più efficaci agiscono intorno al modello attraverso permessi minimi, credenziali temporanee, ambienti isolati e validazione delle operazioni. Le azioni sensibili richiedono conferme o supervisione umana. Un agente può comunque commettere un errore; l’architettura deve impedirgli di trasformarlo in un incidente esteso.
Anche l’osservabilità presenta un rovescio della medaglia. Prompt e tracce possono contenere dati personali, segreti industriali e informazioni di autenticazione. Registrare ogni passaggio senza politiche di minimizzazione e conservazione significa creare un nuovo archivio sensibile.
Costi e latenza entrano nella definizione di qualità
La qualità percepita non dipende soltanto dall’accuratezza. Una risposta corretta che arriva troppo tardi o costa più del valore prodotto difficilmente sostiene un servizio su larga scala.
Prompt molto lunghi, retrieval eccessivi e catene di agenti possono moltiplicare consumi e tempi. LLMOps rende visibili questi compromessi attraverso metriche come costo per attività completata, latenza, token utilizzati, numero di chiamate e frequenza dell’intervento umano.
In molti casi conviene instradare le richieste semplici verso modelli più piccoli e riservare quelli più potenti alle operazioni realmente complesse. Altre ottimizzazioni riguardano il caching, la riduzione del contesto e l’eliminazione dei passaggi che non migliorano il risultato. Il modello con le prestazioni migliori in un benchmark generale può rivelarsi una scelta mediocre all’interno di un prodotto reale.
La governance diventa parte dell’architettura
La gestione operativa comprende infine responsabilità, procedure di approvazione e possibilità di tornare rapidamente a una versione precedente. Questi elementi hanno assunto un peso ulteriore con l’entrata in applicazione dell’AI Act europeo.
Gli obblighi destinati ai fornitori di modelli di intelligenza artificiale per finalità generali si applicano dal 2 agosto 2025. Il 2 agosto 2026 scatteranno i poteri di enforcement della Commissione europea, comprese le sanzioni. Per i modelli immessi sul mercato prima dell’agosto 2025 è previsto un periodo più lungo, fino al 2 agosto 2027.
Non tutte le organizzazioni che utilizzano un modello diventano automaticamente fornitori ai sensi del regolamento. Le responsabilità dipendono dal ruolo ricoperto e dall’entità delle modifiche apportate. Resta però evidente la convergenza tra pratica ingegneristica e conformità: documentare versioni, rischi, dati e incidenti non è più un’attività separata dalla costruzione del prodotto.
Dalla demo a un sistema verificabile
LLMOps descrive ormai qualcosa di più ampio dell’amministrazione di un modello linguistico. È l’ingegneria del sistema che lo circonda, dal retrieval alla valutazione, dalle tracce ai permessi concessi agli agenti.
La maturità di un’applicazione generativa si riconosce quando una risposta può essere ricostruita, un aggiornamento può essere confrontato con quello precedente e un errore può essere contenuto. Senza questa struttura, anche il modello più avanzato rimane il motore di una dimostrazione fragile. Con processi solidi, può diventare una componente affidabile dell’infrastruttura digitale.
Bibliografia
Databricks Documentation, “LLMOps workflows on Databricks”
MLflow, “Evaluating LLMs and Agents”
MLflow, “LLM Tracing and Agent Observability”
OpenTelemetry, “Inside the LLM Call: GenAI Observability with OpenTelemetry”
Google Cloud Architecture Center, “Choose a design pattern for your agentic AI system”
OpenAI, “Scopri l’agente dati interno di OpenAI”
OWASP GenAI Security Project, “Top 10 for Agentic Applications for 2026”
NIST, “AI Agent Standards Initiative”Commissione europea, “Guidelines for providers of general-purpose AI models”