L'agentic AI in pratica: come creare soluzioni AIOps pronte per la produzione con modelli open source

In molti casi, utilizzare l'agentic AI per l'automazione della risposta agli incidenti significa inviare i log dell'infrastruttura ai modelli di IA di frontiera. In questo modo, ogni log di errore dei processi (completo di nomi host, indirizzi IP e topologia di sistema) lascerebbe l'infrastruttura al raggiungimento dell'endpoint di un modello linguistico di grandi dimensioni (LLM), destando forti preoccupazioni nei team che si occupano di conformità in settori fortemente regolamentati come i servizi finanziari e la sanità.

In alternativa, queste organizzazioni potrebbero utilizzare modelli open source ospitati sulla propria infrastruttura, risolvendo i problemi di conformità e di residenza dei dati. Ma i modelli di IA open source sono abbastanza validi da sostituire i grandi modelli di frontiera per le attività operative strutturate? Pensiamo di sì. L'abbinamento di modelli open source con i corretti schemi architetturali (harness per agenti, competenze mirate, isolamento del contesto) consente di ottenere analisi qualitative pari ai modelli di frontiera a una frazione del costo.

Questa è la prima parte di una serie di 3 articoli. In questo primo articolo ti mostreremo esattamente come creare e ottenere soluzioni AIOps scalabili basate su agenti e pronte per la produzione, utilizzando modelli open source. Spiegheremo perché l'open source è pronto per questa sfida, in che modo Red Hat OpenShift AI semplifica le operazioni quotidiane e in che modo un'architettura basata sulle competenze evita il noioso riaddestramento dei modelli.

La sfida: quando le operazioni crescono più rapidamente dei team

Prima di parlare delle soluzioni, ecco la realtà operativa che spinge le organizzazioni verso una risposta agli incidenti potenziata dall'IA.

Il problema aziendale

Nel nostro scenario di utilizzo di esempio, consideriamo un'azienda di servizi finanziari con sede nel Regno Unito, che gestisce un'infrastruttura ibrida: 140 macchine virtuali (VM) Red Hat Enterprise Linux (RHEL) on premise e tre cluster Red Hat OpenShift. Eseguono oltre 600 processi a settimana su Red Hat Ansible Automation Platform per il provisioning, l'applicazione di patch, la scansione della conformità e la correzione degli errori di configurazione.

Quando i processi hanno esito negativo, viene aperta una segnalazione nel sistema di ticketing e inviata una notifica nel canale ChatOps. Sembra un processo gestibile, ma l'azienda deve gestire circa 40 segnalazioni di errori a settimana. Ciascun ticket richiede valutazione manuale, analisi e correzione o escalation.

Costo in termini di tempo: 45-90 minuti dedicati da un Site Reliability Engineer (SRE) per ciascun ticket, a seconda della complessità.

Sfida legata alla scalabilità: se moltiplichiamo questi tempi per l'intero team, tenendo conto dei guasti notturni e dei turni di reperibilità, ci troveremo di fronte a un problema operativo sistemico. L'azienda desidera gestire un'infrastruttura 10 volte superiore senza decuplicare l'organico.

Pressioni normative: in quanto società di servizi finanziari, opera nel rispetto di rigidi requisiti di gestione delle modifiche e di risposta agli incidenti. Ogni interruzione non pianificata o errore di configurazione deve essere documentato (origine del problema, passaggi di correzione, responsabile) entro le finestre definite negli accordi sul livello del servizio (SLA). Il mancato rispetto di tali tempistiche comporta sanzioni normative.

L'autorità di regolamentazione ha segnalato tre violazioni degli SLA nel primo trimestre. Ciascuna violazione è riconducibile a un processo non riuscito su Ansible Automation Platform rimasto in sospeso troppo a lungo. La direttiva era chiara: "Dobbiamo chiudere il ciclo più rapidamente e abbiamo bisogno di controlli che attestino che lo stiamo facendo".

Problematiche attuali

• Volume delle segnalazioni elevato: 40 segnalazioni di errori a settimana, molti dei quali ripetono schemi già noti. I team reperibili sono sovraccarichi e i tempi di risposta sono lenti.
• Frammentazione delle conoscenze: i runbook e le conoscenze di dominio sono frammentati su Confluence e tra i singoli collaboratori. La qualità della risoluzione non è uniforme.
• Controlli onerosi: i report manuali sugli incidenti per la conformità richiedono 2-3 ore per ciascun incidente grave e spesso vengono redatti a posteriori basandosi sulla memoria e sui registri delle chat.
• Divario nei processi di escalation: la scelta è tra "risolvere da soli" e "svegliare qualcuno", poiché manca un meccanismo di risposta graduale e proporzionato.
• Limite di scalabilità: il team attuale non riesce a gestire la crescita prevista. Assumere più SRE non è economicamente sostenibile e non risolve la frammentazione delle conoscenze.

L'opportunità: l'agentic AI è in grado di eseguire il triage, svolgere indagini e intervenire (con un audit trail completo), mantenendo opportunamente il presidio umano per le modifiche ad alto rischio.

Risultati previsti in caso di esito positivo

• Riduzione del tempo medio di risoluzione (MTTR): da una media di 45 minuti a un obiettivo di 12 minuti per le tipologie di errore note.
• Efficienza degli audit: report sugli incidenti generati automaticamente, che il team responsabile della conformità deve solo revisionare invece di redigere da zero.
• Scalabilità: gestione di un volume di ticket 10 volte superiore senza una crescita proporzionale dell'organico.
• Acquisizione delle conoscenze: i pattern degli agenti sintetizzano le conoscenze dei runbook in una knowledge base operativa capace di migliorarsi autonomamente.
• Controllo dei costi: utilizzo di modelli open source sull'infrastruttura di proprietà rispetto alla fatturazione per token applicata da provider esterni.

La sfida tecnica per gli SRE

Dal punto di vista degli SRE, il problema è trovare il compromesso tra velocità operativa e sicurezza operativa.

Volume e varietà: i guasti interessano molteplici domini. Errori negli Ansible Playbook, problemi di gestione dei pacchetti Linux, problematiche del ciclo di vita dei pod OpenShift ed errori DNS/SSH di rete. Un singolo agente non può essere esperto in tutto.

Requisiti di contesto: un'analisi efficace degli incidenti richiede una conoscenza approfondita dell'organizzazione. Quando l'installazione di un pacchetto si interrompe segnalando "Nessun pacchetto python3.14 disponibile", la risposta generica è "verifica la configurazione del repository". La risposta specifica dell'organizzazione fa riferimento a:

• topologia del server Satellite (primario, ripristino di emergenza, pianificazione della sincronizzazione);
• modello di visualizzazione dei contenuti per team (quali team accedono a quali repository);
• processo di escalation (riferimento alle procedure operative standard, SOP), canale Slack ad accesso rapido);
• effettiva presenza del pacchetto per la versione del sistema operativo (OS) in uso.

La risoluzione generica dei problemi fa perdere tempo. Un'analisi sensibile al contesto consente di raggiungere la risoluzione più rapidamente.

Vincoli di conformità: negli ambienti regolamentati, ogni azione deve essere tracciabile. Un agente di IA che opera senza registrazione rappresenta un rischio per la conformità. Un agente che registra ogni elemento (criteri di classificazione, analisi specialistica, punteggi di affidabilità, verifiche del revisore) diventa invece una risorsa preziosa per la conformità.

I revisori della Financial Conduct Authority esaminano regolarmente i registri della gestione delle modifiche e della risposta agli incidenti. Non rispettare le tempistiche dello SLA non significa solo ritardare una correzione, ma comporta sanzioni normative e report di correzione obbligatori. Attualmente questi report vengono redatti manualmente (2-3 ore per ogni incidente grave, spesso ricostruito a posteriori).

Requisiti di sovranità dei dati: ogni chiamata API a un modello di frontiera invia i tuoi dati altrove:

{
  "job_id": "3847",
  "host": "rhel-node-01.meridian.internal",
  "error": "fatal: [rhel-node-01]: FAILED! => {\"msg\": \"No package python3.14 available\"}",
  "playbook": "/var/lib/awx/projects/ansible-plays/install-python.yml",
  "credential": "meridian-satellite-sync"
}

Questo payload espone:

• topologia DNS interna (meridian.internal);
• convenzioni di denominazione dell'infrastruttura;
• identificatori delle credenziali (meridian-satellite-sync);
• dettagli sulla configurazione del sistema.

Negli ambienti regolamentati ai sensi del GDPR (articoli 44-49 sui trasferimenti internazionali di dati) e del DORA (Digital Operational Resilience Act), ciò comporta un concreto rischio per la residenza dei dati.

Requisiti operativi Il sistema deve:

• eseguire il triage e classificare i guasti in modo accurato (assegnandoli allo specialista corretto);
• eseguire un'analisi dell’origine del problema specifica del dominio (non una generica risoluzione dei problemi);
• generare report sugli incidenti pronti per l'audit (output idoneo alla conformità);
• supportare un'autonomia graduale (human-in-the-loop per attività ad alto rischio, human-out-of-the-loop per la routine);
• scalare per gestire volumi 10 volte superiori senza cali delle prestazioni;
• consentire rapidi aggiornamenti delle conoscenze (nuove SOP, modifiche all'infrastruttura) senza riaddestrare i modelli.

Il problema della sovranità dei dati

Il 63% delle grandi imprese nell'area EMEA indica i problemi di sovranità come il principale ostacolo all'adozione del cloud. Per i carichi di lavoro basati sull’IA che elaborano dati operativi, la posta in gioco è ancora più alta.

Red Hat ritiene che l'open source sia alla base dell'IA sovrana. I modelli aperti eseguiti su Red Hat OpenShift AI ti offrono il pieno controllo. Puoi scegliere dove eseguire l'inferenza, i tuoi dati non lasciano mai la piattaforma e mantieni la piena verificabilità della catena di distribuzione dell'IA.

Non si tratta di una preoccupazione marginale. Oltre due terzi delle aziende dell'area EMEA hanno indicato la sovranità dei dati come una priorità IT per i prossimi 18 mesi. Per le società di servizi finanziari, inviare l'output dei processi a provider LLM esterni crea un'esposizione normativa non accettabile per i team responsabili della conformità.

Le capacità dei modelli si evolvono

Due anni fa, scegliere un modello open source significava accettare capacità limitate. Un modello aperto da 7 miliardi di parametri era soggetto ad allucinazioni. Un modello da 70 miliardi di parametri faticava con i ragionamenti complessi. I modelli di frontiera erano l'unica scelta praticabile per gli ambienti di produzione.

Oggi non è più così, poiché sono disponibili modelli open source molto più grandi (da 230 miliardi di parametri e oltre).

La rivoluzione dei sistemi agentici ha cambiato tutto

L'avvento dell'agentic AI (framework come Deep Agents di LangChain, Claude Agent SDK di Anthropic e harness personalizzati) ha trasformato il nostro modo di concepire le capacità dei modelli. Un harness per agenti non si limita a inviare un prompt sperando nel risultato, ma:

• gestisce le finestre di contesto, mantenendo l'attenzione solo sulle informazioni pertinenti;
• delega le attività a specialisti, creando sotto-agenti dedicati a domini specifici;
• fornisce competenze strutturate e conoscenze di riferimento caricate in formato markdown;
• analizza e convalida gli output, fornendo risultati strutturati e pronti all'uso.

Questo approccio strutturato può contribuire a colmare il divario di capacità tra i modelli open source e quelli di frontiera. Un harness ben progettato consente ai modelli open source di medie dimensioni di funzionare in modo eccellente per la specifica attività da svolgere.

Esempio: analisi degli errori di gestione dei pacchetti

Ecco un confronto reale tratto dalla nostra pipeline AIOps di produzione. Stesso errore, due modelli diversi.

Modello di frontiera (claude-sonnet-4-6):

Origine del problema: Il gestore di pacchetti DNF segnala "Nessun pacchetto python3.14 disponibile" 
Azione consigliata:  
1. Verifica che il nome del pacchetto sia corretto 
2. Verifica la configurazione del repository 
3. Valuta la possibilità di utilizzare EPEL o di abilitare repository aggiuntivi
Affidabilità: 85%

Modello open source (qwen3-235b in esecuzione su MaaS):

Origine del problema: Il gestore di pacchetti DNF segnala "Nessun pacchetto python3.14 disponibile"  
Analisi: Python 3.14 richiede i repository CRB (CodeReady Builder) ed EPEL. Il gruppo host di destinazione indica un carico di lavoro del team AI/ML. 
Azione consigliata: 
1. Invia una richiesta di visualizzazione dei contenuti in conformità con la SOP v2.3 
2. Richiedi l'abilitazione di CRB + EPEL per la visualizzazione dei contenuti aiml-workloads 
3. Esegui l'escalation tramite canale prioritario #platform-satellite (SLA di 2 ore) 
Affidabilità: 92%

Il modello open source ha prodotto una risposta migliore grazie all'uso di una competenza di IA (fornita come documento markdown che codifica le conoscenze istituzionali sull'infrastruttura Satellite, sul modello di visualizzazione dei contenuti e sui percorsi di escalation). Il modello non ha avuto bisogno di apprendere queste nozioni dai dati di addestramento. Abbiamo fornito la risposta come contesto.

Le competenze svolgono il lavoro più impegnativo

Ecco come si presentava questa competenza:

---

name: analyze-package-management-failure

descrizione: Analisi degli errori di gestione dei pacchetti con conoscenze aziendali

--- # Analisi degli errori di gestione dei pacchetti 
## Conoscenze aziendali: Infrastruttura Satellite 
**Modello di visualizzazione dei contenuti (per team):** 
- base-rhel9: Tutti i server RHEL, solo i pacchetti del sistema operativo di base 
- ops-tooling: Team SRE, monitoraggio, strumenti diagnostici 
- aiml-workloads: Team AI/ML, Python 3.11+, CUDA, librerie di data science (con CRB + EPEL abilitati)
**Percorso di escalation:** 
- Standard: Content View Request SOP v2.3 
- Canale prioritario: canale #platform-satellite (SLA di 2 ore per i carichi di lavoro AI/ML)

Il modello ha fornito il motore di ragionamento. La competenza ha fornito le conoscenze aziendali. Insieme, hanno fornito un'analisi di qualità superiore rispetto ai modelli di frontiera perché abbiamo codificato il nostro specifico contesto operativo.

Il calcolo dei costi

La determinazione dei prezzi dei modelli di frontiera cresce rapidamente in un ambiente operativo.

• Fatturazione per token: ogni analisi di incidente comporta più chiamate LLM (classificazione, ragionamento specialistico, revisione).
• Scalabilità dei volumi: Con oltre 40 errori a settimana, i costi dei token diventano una voce di spesa rilevante.
• Nessun tetto di costo massimo: i picchi di utilizzo durante gli incidenti determinano costi imprevedibili.

I modelli open source eseguiti sulla propria infrastruttura hanno un costo di elaborazione fisso.

Modello di costo per i modelli di frontiera: 
- US$15 per milione di token (input) 
- US$75 per milione di token (output) 
- Incidente medio: circa 50.000 token (classificazione + analisi + revisione) 
- 40 incidenti/settimana × 52 settimane = 2.080 incidenti/anno 
- Costo annuale: circa US$7.800 solo per le tariffe delle API LLM 
Modello di costo per i modelli open source: 
- infrastruttura GPU fissa (Nvidia A100 o H100) 
- sottoscrizione a Red Hat OpenShift AI 
- nessuna fatturazione per token 
- costo annuale prevedibile indipendentemente dal volume degli incidenti

Se elabori centinaia di incidenti a settimana, la convenienza economica pende decisamente verso l'open source.

Red Hat OpenShift AI Model-as-a-Service (MaaS)

Red Hat OpenShift AI offre Model-as-a-Service (MaaS), un portafoglio di modelli open source eseguiti su OpenShift con accelerazione dell'inferenza vLLM su diverse GPU.

Ecco alcuni esempi dei modelli disponibili con MaaS.

In produzione non utilizzi un solo modello. Puoi combinare modelli diversi per ciascun agente:

• ops_manager (agente di orchestrazione): qwen3-235b (richiede una classificazione e una delega solide);
• sre_linux (specialista): gpt-oss-120b (dominio mirato, output strutturato);
• reviewer (validatore): gpt-oss-20b (controllo di coerenza semplice).

Questo approccio a più livelli ottimizza i costi garantendo la qualità. Il tuo agente per il triage non necessita di 235 miliardi di parametri per verificare se un log indica "Nessun pacchetto X disponibile".

L'architettura: agenti di seconda generazione

Ciò che consente ai modelli open source di svolgere attività operative complesse è l'harness, il framework che racchiude e guida il modello linguistico di grandi dimensioni (LLM), evitando che agisca senza supervisione.

Agenti di prima generazione a confronto con la seconda generazione

Gli agenti di prima generazione (classico pattern ReAct) mostrano difficoltà nelle operazioni composte da più passaggi:

• contesto limitato alla cronologia della conversazione;
• calo delle prestazioni dopo circa 50 chiamate agli strumenti ("dumb zone");
• assenza di stato persistente al di fuori della conversazione;
• condivisione di una sola finestra di contesto per ogni attività.

Gli agenti di seconda generazione (Deep Agents, Claude Agent SDK) si basano su quattro pilastri architetturali:

1. pianificazione esplicita (elenchi di attività come ancoraggi di contesto persistenti);
2. file system persistente (spazio di lavoro virtuale per note e artefatti strutturati);
3. creazione di sotto-agenti (delega a specialisti con contesti puliti);
4. isolamento del contesto (ogni specialista vede solo ciò di cui ha bisogno).

Esempio: pipeline di risposta agli incidenti

La nostra pipeline AIOps utilizza il pattern Deep Agents:

ops_manager (Deep Agent a esecuzione prolungata)   
  ├── Riceve il webhook per gli errori dei processi AAP2   
  ├── Classifica il dominio di errore (ansible/linux/openshift/networking)   
  ├── Crea un sotto-agente specializzato (temporaneo)   
  │   └── sre_linux (fresh context)   
  │		  ├── Carica le competenze: analyze-linux-failure, create-ticket, common   
  │		  ├── Analizza i dati degli incidenti   
  │       └── Restituisce un TicketPayload strutturato   
  ├── Crea un sotto-agente reviewer (temporaneo)   
  │   └── reviewer (convalida la coerenza dei ticket)   
  └── Invia il ticket a Jira e invia una notifica a Rocket.Chat

Ciascun sotto-agente sre_* è temporaneo (creato su richiesta ed eliminato dopo l'uso). Ecco cosa significa.

• Isolamento del contesto: l'errore di un pacchetto non contamina il contesto dell'errore di una sessione SSH
• Competenze mirate: ogni agente carica solo le competenze specifiche del proprio dominio
• Stato pulito: ogni analisi inizia da zero, con una cronologia pulita

Un modello open source da 235 miliardi di parametri offre prestazioni ottimali per l'attività corrente poiché non deve "ricordare" 50 incidenti precedenti. Deve solo elaborare l'evento in esame, con l'esatto set di competenze caricate.

Sovranità dei dati + costo + qualità = idoneità alla produzione

Tre fattori consentono di ottenere modelli open source pronti per la produzione nei carichi di lavoro basati su agenti.

1. Sovranità dei dati: i log rimangono sulla tua infrastruttura (nessuna violazione di GDPR/DORA);
2. Costi: costi infrastrutturali fissi in alternativa a una fatturazione per token imprevedibile;
3. Qualità: gli harness per agenti e le competenze offrono risultati equivalenti a quelli dei modelli di frontiera.

Utilizziamo questa soluzione in produzione da sei mesi, gestendo oltre 40 incidenti infrastrutturali a settimana. Il nostro MTTR è sceso da 45 a 12 minuti per i modelli di errore noti. Il nostro team di conformità è soddisfatto dal registro degli audit. I costi della nostra infrastruttura sono prevedibili.

Il modello open source gestisce:

• errori negli Ansible Playbook e problemi con le credenziali;
• gestione dei pacchetti Linux ed errori di systemd;
• ciclo di vita dei pod OpenShift e problemi relativi al controllo degli accessi basato sui ruoli (RBAC);
• DNS di rete e problemi di connettività.

Stessa pipeline. Stesse competenze. Stessi prompt. Modello diverso. E funziona.

Provalo

Vuoi acquisire un'esperienza pratica nella creazione di una pipeline AIOps basata su agenti con modelli open source? Prova il workshop completo contattando il tuo rappresentante Red Hat.

Risorse

• Red Hat OpenShift AI
• Deep Agent di LangChain
• L'open source come base dell'IA sovrana
• La sovranità digitale si rivela la principale sfida del cloud per le aziende dell'area EMEA.

Informazioni su questo articolo: questo articolo si basa su un workshop pratico creato per le dimostrazioni di Red Hat. Le tecniche descritte sono operative in ambienti SRE di produzione ed elaborano incidenti infrastrutturali reali. Contatta il tuo rappresentante Red Hat per provare il laboratorio completo.