AgenticOps indica l’uso di agenti AI capaci non solo di analizzare gli eventi di rete, ma anche di proporre ed eseguire azioni operative: modificare parametri wireless, deviare il traffico, isolare endpoint sospetti o chiudere incidenti. È un’evoluzione rispetto all’AIOps tradizionale, che spesso si limita a correlare dati e generare raccomandazioni.
Una ricerca Cisco e Omdia pubblicata il 23 settembre 2026 mostra quanto velocemente stia crescendo l’interesse: il 51% degli intervistati dichiara di usare già AI agentica che agisce in produzione e l’82% accetterebbe almeno alcune modifiche senza approvazione preventiva. Questi numeri non significano che ogni impresa debba rendere autonoma la rete. Indicano, piuttosto, che è urgente definire livelli di delega, guardrail, audit e procedure di rollback.
Che cosa cambia dall’AIOps all’AgenticOps
Nel modello AIOps più comune, algoritmi e regole aiutano a ridurre il rumore, identificare anomalie e suggerire una causa probabile. La decisione e l’esecuzione restano generalmente all’operatore. Con AgenticOps, l’agente riceve un obiettivo, osserva più fonti, costruisce un piano e può utilizzare strumenti o API per modificare l’ambiente.
La differenza non è quindi solo tecnologica. Cambia la responsabilità operativa: una raccomandazione errata può essere ignorata, mentre un’azione errata può interrompere un servizio, ampliare un incidente o compromettere le prove utili all’analisi.
| Modello | Ruolo dell’AI | Ruolo dell’operatore | Rischio principale |
|---|---|---|---|
| Monitoraggio tradizionale | Raccolta e soglie | Analisi ed esecuzione | Troppi alert e tempi lunghi |
| AIOps | Correlazione e suggerimenti | Valida ed esegue | Fiducia eccessiva nella diagnosi |
| AgenticOps assistito | Prepara il piano e azioni reversibili | Approva i passaggi critici | Guardrail incompleti |
| AgenticOps autonomo | Decide, esegue e verifica | Definisce intenti e controlla gli esiti | Cambiamenti rapidi su larga scala |
I dati Cisco: utili, ma da leggere nel contesto
Lo studio è stato condotto indipendentemente da Omdia su 1.000 responsabili IT e NetOps di organizzazioni con almeno 500 dipendenti in Nord America, Europa occidentale e Asia-Pacifico. Non rappresenta direttamente la tipica microimpresa italiana e resta una ricerca promossa da Cisco. È però utile per comprendere le pressioni che spingono verso l’automazione.
Le organizzazioni intervistate dichiarano una media di circa 4.100 alert ed eventi al giorno, più della metà legati alla rete. Cisco stima che servirebbero circa 100 specialisti per smaltire manualmente l’intero arretrato quotidiano. Il 95% ritiene che gli strumenti AIOps non agentici mostrino almeno una lacuna significativa; il 92% segnala incidenti che attraversano più domini e richiedono la correlazione di almeno dieci strumenti.
Il problema non è soltanto la quantità. Quasi metà degli alert viene chiusa senza indagine, mentre una quota simile del tempo di analisi è spesa su falsi positivi. In questo scenario, automatizzare la raccolta delle evidenze e le attività ripetitive può essere sensato. Automatizzare ogni modifica di rete, invece, richiede un livello di controllo molto superiore.
Autonomia e fiducia non sono la stessa cosa
L’80% degli intervistati si dichiara a proprio agio con un ruolo elevato o completamente autonomo dell’AI nelle operazioni di rete; il 24% accetterebbe azioni senza supervisione umana. Allo stesso tempo, il 69% richiede spiegazioni dettagliate e il 36% considera indispensabili tracing completo, motivazione sintetica e audit successivo all’azione.
Questa apparente contraddizione chiarisce il punto: l’autonomia è sostenibile solo quando l’organizzazione può ricostruire che cosa è accaduto, perché, con quali dati e con quale effetto.
Quattro livelli di autonomia per non partire dal fondo
Livello 0: osservazione
L’agente può leggere telemetria, configurazioni e ticket, ma non può modificare nulla. Produce riepiloghi, correla eventi e propone verifiche. È il punto di partenza più sicuro per misurare precisione, falsi positivi e qualità delle spiegazioni.
Livello 1: preparazione dell’intervento
L’AI genera comandi, change plan e piano di rollback, ma l’esecuzione richiede l’approvazione di un operatore. In questa fase si può verificare se l’agente comprende dipendenze, finestre di manutenzione e impatto sui servizi.
Livello 2: azioni automatiche reversibili
L’agente esegue attività preautorizzate e a basso impatto, come arricchire un ticket, acquisire diagnostica, riavviare un processo non critico o applicare una modifica temporanea entro limiti precisi. Ogni azione deve avere scadenza, controllo dell’esito e rollback automatico.
Livello 3: autonomia condizionata
L’agente può intervenire su produzione entro un perimetro definito, per esempio isolando un endpoint con indicatori ad alta confidenza. Restano vietate modifiche massive, permanenti o prive di una strada di ritorno. Per i sistemi critici serve ancora un’approvazione esplicita.
I guardrail indispensabili
Identità separata e privilegi minimi
Ogni agente deve operare con un’identità dedicata, riconoscibile nei log e limitata alle API necessarie. Le credenziali non devono essere condivise con gli amministratori. Permessi, segreti e token vanno ruotati, monitorati e revocabili rapidamente.
La gestione tecnica dei token merita test specifici: l’approfondimento EP sulle modifiche ai token di sessione AWS STS mostra perché dimensioni, policy e monitoraggio delle credenziali temporanee possono influire sulle automazioni.
Allowlist delle azioni
È preferibile autorizzare un insieme ristretto di operazioni anziché tentare di elencare tutto ciò che l’agente non deve fare. L’allowlist dovrebbe specificare dispositivi, fasce orarie, numero massimo di oggetti coinvolti, durata della modifica e soglie che richiedono l’intervento umano.
Controllo prima e dopo la modifica
Prima dell’esecuzione l’agente deve verificare stato, dipendenze e presenza di change concorrenti. Dopo, deve misurare l’effetto sugli indicatori concordati. Se il miglioramento non arriva o compaiono effetti collaterali, il rollback deve scattare senza attendere un nuovo ragionamento generativo.
Audit completo e spiegabile
Prompt, contesto recuperato, strumenti invocati, autorizzazioni, comandi, output e decisione finale devono essere conservati con timestamp. La spiegazione deve essere leggibile dall’operatore, ma anche abbastanza dettagliata da consentire una revisione tecnica.
La stessa disciplina è utile durante la modernizzazione descritta nell’articolo EP sulla rete multi-gigabit e il debito tecnico: l’automazione funziona solo se inventario e telemetria sono affidabili.
Dove iniziare in una PMI
Una piccola o media impresa difficilmente registra migliaia di alert al giorno, ma spesso dispone di meno persone e strumenti più frammentati. Il primo caso d’uso dovrebbe quindi ridurre il lavoro ripetitivo senza creare un nuovo punto di rischio.
- Scegliere un problema misurabile: triage degli alert, raccolta di diagnostica o apertura automatica dei ticket.
- Definire una baseline: tempo medio di analisi, falsi positivi, incidenti riaperti e minuti di indisponibilità.
- Partire in sola lettura: confrontare le proposte dell’agente con le decisioni degli operatori.
- Autorizzare una sola azione reversibile: con limite di frequenza, ambito e durata.
- Provare il rollback: non basta documentarlo; va eseguito in un ambiente controllato.
- Rivedere ogni escalation: capire se l’agente ha usato dati incompleti o una regola inadeguata.
Prima di affidare all’AI l’isolamento di dispositivi, è opportuno verificare segmentazione e policy di accesso. L’analisi EP sulla vulnerabilità critica di Cisco ISE ricorda anche che il piano di controllo va protetto e aggiornato: un agente non rende sicura una piattaforma vulnerabile.
Metriche per decidere se aumentare l’autonomia
- Percentuale di diagnosi corrette confermate dall’operatore.
- Riduzione del tempo medio di rilevamento e ripristino.
- Numero di falsi positivi e azioni annullate.
- Percentuale di modifiche con rollback riuscito.
- Incidenti causati o aggravati dall’automazione.
- Copertura e completezza dei log di audit.
- Numero di eccezioni ai guardrail richieste dal personale.
- Tempo risparmiato rispetto ai costi di piattaforma e gestione.
L’autonomia dovrebbe aumentare soltanto dopo più cicli senza eventi critici e con risultati replicabili. La velocità non è una metrica sufficiente: un cambio rapido ma non tracciabile peggiora la resilienza.
Checklist prima di consentire modifiche automatiche
- Inventario e mappa delle dipendenze aggiornati.
- Identità dell’agente separata e privilegi minimi.
- Azioni ammesse definite in allowlist.
- Limiti su dispositivi, sedi, orari e ampiezza del cambiamento.
- Backup delle configurazioni e rollback verificato.
- Log immutabili di input, decisioni e comandi.
- Approvazione umana per servizi critici e cambi massivi.
- Kill switch indipendente dall’agente.
- Responsabile umano e procedura di escalation assegnati.
- Test periodici su scenari errati o dati incompleti.
Domande frequenti su AgenticOps
AgenticOps sostituisce il personale NetOps?
No. Sposta il lavoro dall’esecuzione manuale alla definizione di intenti, limiti, verifiche e gestione delle eccezioni. Servono competenze di rete per valutare le decisioni dell’agente.
È necessario avere una rete Cisco?
Il concetto non è legato a un solo produttore. In ambienti multi-vendor contano disponibilità delle API, qualità della telemetria, controllo degli accessi e capacità di rollback.
Quali azioni non dovrebbero essere autonome all’inizio?
Modifiche massive, cancellazioni, aggiornamenti firmware, cambi di routing critico e interventi senza rollback. Il primo perimetro deve essere limitato e reversibile.
Come si valuta la spiegabilità?
L’agente deve indicare dati usati, causa ipotizzata, alternative scartate, rischio, comando previsto ed esito atteso. Una frase generica non è sufficiente per autorizzare un change.
Che cosa succede se l’agente perde connettività o riceve dati incompleti?
Deve fermarsi in uno stato sicuro. I guardrail devono impedire azioni quando telemetria, autorizzazioni o dipendenze non sono verificabili.
Conclusioni
AgenticOps può ridurre il rumore operativo e accelerare la risposta agli incidenti, ma introduce un nuovo tipo di rischio: software capace di cambiare rapidamente l’infrastruttura. La strategia corretta non è scegliere tra controllo umano e autonomia totale. È costruire una scala di delega, misurare gli esiti e aumentare i permessi solo quando audit, spiegabilità e rollback funzionano davvero.