differenze, policy e strumenti| ZeroUno

Un server da configurare, una patch da distribuire, un backup da avviare: l’automazione IT nasce per togliere lavoro manuale da attività ripetitive e prevedibili. Ma cosa succede quando un processo attraversa cloud pubblico e sistemi on premise, coinvolge applicazioni diverse, deve rispettare una policy di sicurezza e magari decidere autonomamente come reagire a un evento?

È su questo terreno che il confine tra IT automation e IT orchestration diventa rilevante per CIO e responsabili delle IT operations.

L’automazione definisce ed esegue singoli task; l’orchestrazione combina più task automatizzati all’interno di workflow coordinati, stabilendo sequenze, dipendenze, tempi e risorse. Le due discipline quindi convivono. Senza automazione non c’è orchestrazione; senza orchestrazione, però, un numero crescente di automazioni rischia di trasformarsi in un insieme difficile da governare.

Automazione e orchestrazione: la differenza è nella scala

Prendiamo il patch management. Automatizzare significa, per esempio, distribuire una patch su un gruppo di server senza intervento manuale.

Orchestrare significa gestire l’intero processo: rilevare la vulnerabilità, identificare gli asset interessati, verificare la policy applicabile, aprire o aggiornare il ticket, controllare eventuali dipendenze applicative, eseguire un backup, applicare la patch in una finestra autorizzata, verificare il risultato e, in caso di errore, attivare il rollback e notificare chi deve intervenire.

Sostanzialmente l’orchestrazione va vista come l’assemblaggio di task automatizzati in workflow coordinati e completi. Questo amplia anche il perimetro dell’osservabilità: una piattaforma di orchestrazione può rendere visibile non soltanto se una singola operazione ha avuto successo, ma lo stato del processo nel suo complesso.

Automation e orchestration a confronto

Il rischio dell’automazione a silos

L’approccio all’IT automation è stato spesso a silos, principalmente perché l’automazione locale porta risultati rapidamente: il team cloud automatizza il provisioning, il networking configura le reti, il SecOps automatizza alcuni controlli, il service management gestisce ticket e remediation, DevOps costruisce pipeline proprie.

È un approccio che funziona finché il processo rimane confinato nel proprio dominio. Diventa più difficile quando deve attraversarne diversi. Ogni gruppo può migliorare la propria produttività ma, nello stesso tempo, aumentare la complessità complessiva.

Non a caso la proliferazione degli strumenti sta creando una nuova esigenza di razionalizzazione.

L’orchestrazione, in questa prospettiva, svolge una funzione architetturale: collegare domini che hanno automazioni proprie senza obbligare necessariamente l’azienda a sostituirle tutte.

Dalle procedure alle policy

C’è poi un secondo passaggio, meno visibile ma forse più importante e che vede in campo l’automazione policy-based.

L’automazione tradizionale risponde essenzialmente alla domanda: quali operazioni deve eseguire il sistema?

La policy-based automation aggiunge un altro livello: in quali condizioni è autorizzato a eseguirle e quale stato deve mantenere?

Supponiamo che una macchina virtuale venga configurata in modo incompatibile con la security policy aziendale. Una semplice automazione può eseguire perfettamente l’istruzione ricevuta. Un sistema basato su policy può rilevare il configuration drift, cioè lo scostamento dallo stato previsto e attivare il workflow necessario per ripristinare la configurazione prevista.

Qui entra in gioco anche la Policy as Code (PaC): le regole vengono espresse in forma leggibile dalle macchine e possono essere versionate, controllate e applicate attraverso i processi IT, in modo analogo a quanto l’Infrastructure as Code ha fatto per la configurazione dell’infrastruttura.

Il flusso, in un approccio policy-based automation, diventa in sostanza il seguente:

• regole e policy definiscono i comportamenti ammessi;
• monitoring e telemetria monitorano lo stato dell’ambiente;
• l’automation engine, che può coincidere con un orchestratore, avvia le azioni;
• i meccanismi di enforcement riportano il sistema allo stato previsto quando viene rilevata una deviazione;
• auditing e reporting mantengono traccia di quanto è accaduto.

Per un CIO significa spostare parte della governance dall’intervento umano a posteriori verso controlli inseriti nel funzionamento ordinario dei sistemi.

Compliance: l’automazione deve lasciare tracce

Questo approccio acquista peso con l’aumento degli obblighi normativi.

ENISA ricorda che la NIS2 prevede un early warning entro 24 ore dalla conoscenza di un incidente significativo: ricostruire rapidamente eventi, sistemi interessati e azioni intraprese diventa quindi parte della capacità operativa, oltre che della compliance. Occorre sapere quale regola ha attivato un processo, che cosa ha fatto, su quali sistemi e con quale esito.

In un ambiente orchestrato, telemetry, log delle esecuzioni, versionamento delle policy e workflow di escalation possono contribuire a costruire questa evidenza.

Il tema riguarda direttamente anche le aziende italiane che stanno aumentando l’uso di cloud e AI. Secondo l’Osservatorio Cloud Transformation del Politecnico di Milano, il 46% delle grandi organizzazioni segnala difficoltà nel rispettare gli obblighi di tracciabilità e documentazione dei dati previsti dall’AI Act.

Governance e automazione, quindi, iniziano a convergere.

L’AI alza ulteriormente il livello

L’intelligenza artificiale aggiunge un elemento ulteriore: la possibilità che un sistema non esegua soltanto istruzioni predefinite, ma contribuisca a scegliere l’azione.

Se un agente AI individua un incidente e propone una remediation, chi decide se può eseguirla? Su quali sistemi? Entro quali soglie di rischio? Quando deve chiedere l’autorizzazione di un operatore? Come viene registrata la decisione?

Sono domande di orchestrazione e governance prima ancora che di AI.

L’orchestratore come control plane

In passato l’orchestratore aveva soprattutto il compito di mettere in sequenza job e task. Nelle architetture ibride può diventare una sorta di control plane operativo, capace di coordinare automazioni eseguite da strumenti differenti senza necessariamente sostituirli.

Un evento proveniente dall’observability può attivare una policy. La policy seleziona un workflow. Il workflow richiama strumenti IaC, cloud API o script esistenti, interagisce con l’ITSM, richiede eventualmente un’approvazione umana e infine verifica che il sistema sia tornato nello stato atteso.

L’AI può quindi aggiungere autonomia all’automazione, ma aumenta contemporaneamente la necessità di stabilire confini entro i quali quell’autonomia può essere esercitata.

Quanto vale l’automazione intelligente

Misurare il ritorno dell’IT automation resta difficile perché i risultati dipendono dalla maturità dell’organizzazione, dalla qualità dei processi e dal punto di partenza.

Secondo uno studio 2025 dell’IBM Institute for Business Value, le organizzazioni classificate come altamente automatizzate attribuiscono all’automazione intelligente una riduzione del 28% dei costi IT, una diminuzione del 16% del time-to-market dei nuovi prodotti e servizi IT e un calo del 36% dei costi di downtime legati agli incidenti di cybersecurity.

Intendiamoci: sono dati dichiarativi e provengono da una ricerca IBM, quindi non vanno interpretati come benchmark automaticamente trasferibili a qualsiasi impresa. Sono però interessanti perché collegano i risultati migliori non alla semplice quantità di task automatizzati, bensì a maggiore integrazione, visibilità, data governance e maturità cloud.

In altre parole, il valore tende a emergere quando l’automazione smette di essere locale.

Da dove dovrebbe partire un CIO

Tentare di orchestrare l’intero patrimonio IT in un unico progetto sarebbe probabilmente il modo più rapido per aumentarne la complessità.

Un percorso più realistico parte dai processi che hanno tre caratteristiche:

• attraversano più sistemi,
• vengono eseguiti frequentemente,
• hanno un costo misurabile quando falliscono.

Il suggerimento degli analisti è partire proprio da aree ad alto impatto come patch management, controlli dei costi cloud, remediation del configuration drift, misurando risultati quali mean time to resolution, aderenza alle policy e risparmi operativi.

A questi indicatori conviene aggiungere qualche misura specifica dell’orchestrazione: percentuale dei workflow end-to-end automatizzati, numero di interventi manuali richiesti per processo, failure rate, rollback riusciti, tempo trascorso fra rilevazione e remediation, percentuale delle esecuzioni riconducibili a una policy versionata.

Sono metriche meno appariscenti del numero complessivo di automazioni realizzate, ma raccontano meglio il grado di controllo raggiunto.

I tool: l’orchestrazione incontra la policy as code

Non esiste una categoria omogenea di prodotti per la policy-based orchestration. Le funzionalità necessarie sono distribuite tra piattaforme di automazione e orchestrazione, strumenti Infrastructure as Code, policy engine e sistemi di workflow enterprise.

Per orientarsi in un panorama così frammentato può essere utile distinguere tre funzioni fondamentali: decisione, enforcement ed esecuzione. A monte di queste funzioni si colloca naturalmente la definizione delle policy, cioè delle regole che guidano i comportamenti del sistema. Alcune soluzioni sono specializzate nella valutazione di tali regole e nella conseguente presa di decisioni, altre nella loro applicazione, altre ancora nell’esecuzione e nell’orchestrazione delle attività operative. Nella pratica, molte piattaforme combinano questi ruoli, ma raramente attribuiscono lo stesso peso a ciascuno di essi.

Sul versante della policy as code, Open Policy Agent (OPA) è uno degli esempi più rappresentativi. Progetto open source della Cloud Native Computing Foundation, separa deliberatamente la decisione di policy dai sistemi incaricati di applicarla: valuta le regole e restituisce una decisione, senza eseguire direttamente l’operazione. Un’impostazione analoga entra nel ciclo di provisioning con HCP Terraform, che consente di sottoporre i Terraform run a policy definite, fra gli altri, attraverso Sentinel e OPA e di bloccare un provisioning non conforme.

Nel cloud native, invece, i ruoli possono essere distribuiti fra componenti differenti. Kubernetes orchestra i workload containerizzati; Kyverno e OPA Gatekeeper aggiungono controlli sulle risorse e sulle configurazioni. Una policy può così impedire l’introduzione di una configurazione non ammessa prima ancora che questa raggiunga l’ambiente operativo oppure rilevare successivamente condizioni non conformi.

Con Red Hat Ansible Automation Platform il baricentro si sposta verso automazione ed esecuzione. La piattaforma coordina attività su infrastrutture, cloud, networking e applicazioni; Event-Driven Ansible permette inoltre di associare eventi e condizioni ad azioni attraverso regole definite nei Rulebook. È un esempio di come l’orchestrazione possa tradurre un evento o una decisione in una sequenza operativa che coinvolge sistemi diversi.

Un’altra prospettiva è quella di ServiceNow, dove l’orchestrazione parte dal workflow enterprise: eventi, ticket, approvazioni, API e sistemi esterni possono essere collegati all’interno dello stesso processo. Broadcom Automic Automation e Stonebranch Universal Automation Center arrivano invece dalla workload automation e ne estendono il perimetro verso il coordinamento di workflow distribuiti fra applicazioni, infrastrutture on premise e cloud.

Le sovrapposizioni fra queste categorie sono numerose e destinate ad aumentare. Rimane però utile distinguere le funzioni: un policy engine decide sulla base delle regole; l’enforcement fa rispettare quella decisione; l’automation engine esegue le azioni; l’orchestratore coordina azioni, dipendenze e stato del processo. Una singola piattaforma può coprire più ruoli, oppure questi possono essere distribuiti fra prodotti differenti.

Per il CIO la valutazione si sposta così dalle singole feature all’architettura complessiva: dove risiedono le policy? Chi può modificarle? Quale componente prende la decisione? Chi è autorizzato a eseguirla? Come vengono gestite eccezioni e approvazioni umane? E, infine, è possibile ricostruire l’intera sequenza evento → decisione → enforcement → esecuzione → risultato?

Sono domande destinate a pesare ancora di più con l’ingresso degli agenti AI nelle operations. Quando un sistema può non soltanto eseguire un’azione, ma anche proporla o selezionarla autonomamente, separare decisione, controllo ed esecuzione diventa una scelta di governance prima ancora che tecnologica.

Il rischio opposto: automatizzare la complessità

Resta però una trappola. Un processo inefficiente, una volta automatizzato, può diventare semplicemente un processo inefficiente che gira più velocemente.

L’orchestrazione aggiunge inoltre dipendenze: complessità di integrazione, vendor lock-in e difficoltà nel modificare workflow molto articolati. Nell’automazione policy-based si aggiunge poi il fenomeno del policy sprawl: regole ridondanti, sovrapposte o persino contraddittorie.

Per questo il lavoro architetturale viene prima della scelta del tool: mappare le dipendenze, identificare i process owner, definire gli stati desiderati, stabilire le eccezioni e decidere dove sia necessaria l’approvazione umana.

L’automazione riduce il lavoro manuale. L’orchestrazione riduce i passaggi manuali tra automazioni diverse. Le policy, infine, stabiliscono entro quali confini il sistema può agire.

È questa stratificazione a preparare l’IT a un passaggio che l’AI rende ormai concreto: sistemi capaci di osservare un evento, interpretarlo e avviare autonomamente una risposta.