Dovrebbero restare fuori dall'ambito operativo degli agenti AI i sistemi dove un errore non è reversibile in tempi accettabili: controllori di linea, sistemi di sicurezza fisica, gestione di identità amministrative e piattaforme di backup sono i candidati tipici. La decisione non è «fidarsi o non fidarsi», ma stabilire per ogni sistema cosa l'agente può osservare, cosa può proporre e cosa non può toccare in nessun caso — e scrivere questi confini in controlli tecnici che li fanno rispettare, non solo in un documento.
Questa guida propone un metodo in tre passi per chi gestisce sistemi di produzione: classificare i sistemi, rendere i divieti applicabili e regolare chi può modificare i confini. Il privilegio minimo, trattato nella guida sui privilegi minimi per gli agenti AI, regola ciò che resta dentro l'ambito; qui si decide cosa resta fuori.
Classificare i sistemi per criticità e reversibilità
Il criterio più utile non è la tecnologia del sistema, ma due domande combinate: quanto danno fa un'azione sbagliata su quel sistema, e in quanto tempo si può annullare. Un riavvio di un server di stampa è reversibile in minuti; una scrittura su un controllore di linea o la cancellazione di un punto di recupero possono non esserlo affatto, o esserlo solo fermando la produzione.
Da queste due domande nascono classi semplici, da adattare alla propria realtà:
| Classe | Esempi tipici | Cosa può fare l'agente |
|---|---|---|
| A — Vietato | Controllori e sistemi di controllo di processo, sistemi di sicurezza fisica (safety), protezioni delle piattaforme di backup. | Nessun accesso in scrittura, in nessuna condizione. Osservazione solo se concordata e senza impatto sul processo. |
| B — Osserva e proponi | Rete OT di supervisione, gestionali di produzione, sistemi con finestre di fermo pianificate. | Lettura, correlazione, proposte documentate. L'esecuzione spetta sempre a una persona, con gli strumenti dell'impianto. |
| C — Intervento autorizzabile | Configurazioni di rete perimetrale, account utente, servizi interni con ripristino rapido. | Proposta ed esecuzione solo dopo l'approvazione prevista, su risorse e operazioni elencate, entro i limiti di policy. |
Tre avvertenze pratiche. Primo: la classificazione riguarda il sistema e l'azione, non il sistema in astratto — lo stesso firewall può essere in classe C per una regola di una rete ospiti e in classe B per una regola che separa la produzione. Secondo: nei sistemi OT (tecnologia operativa degli impianti) il controllo di processo e la sicurezza fisica restano responsabilità di chi gestisce l'impianto; un agente non sostituisce queste funzioni e non dovrebbe avere canali per modificarle. Terzo: la classe più restrittiva vince in caso di dubbio, e il dubbio va risolto da persone, non dal modello.
Il NIST AI Risk Management Framework, pubblicato nella versione 1.0 a gennaio 2023 come riferimento volontario, serve proprio a incorporare considerazioni di affidabilità nella progettazione e nell'uso dei sistemi AI; il 7 aprile 2026 il NIST ha annunciato una concept note per un profilo dedicato all'AI affidabile nelle infrastrutture critiche, ancora lavoro in corso. Segno che il tema dei confini operativi sui sistemi critici è ormai riconosciuto a livello istituzionale, non solo prudenza di chi gestisce impianti.
Definire divieti applicabili, non solo dichiarati
Un divieto scritto in una policy documentale ma non tradotto in un controllo tecnico è una dichiarazione d'intenti: vale finché nessuno — persona o modello — prova a violarlo. Per essere applicabile, un divieto deve avere tre caratteristiche:
- Un confine tecnico. L'agente non ha credenziali, token o connettori verso i sistemi di classe A. Se il canale non esiste, il divieto non dipende dal comportamento del modello. È lo stesso principio del modello zero trust descritto dal NIST nella pubblicazione SP 800-207: nessuna fiducia implicita, ogni accesso autorizzato separatamente.
- Un controllo fuori dal modello. Anche dove l'accesso esiste (classi B e C), la decisione finale su cosa può essere eseguito passa da un livello esterno che verifica risorsa, operazione e autorizzazione prima dell'esecuzione — non dalla ragionevolezza della proposta. Ne parliamo nella guida ai controlli fuori dal modello.
- Una formulazione verificabile. «Non toccare la produzione» non è verificabile. «Nessuna operazione in scrittura verso i dispositivi della rete di cella 3, elencati nell'inventario X» lo è: si può controllare, registrare e far rispettare.
Documenta i divieti con la stessa cura delle autorizzazioni: per ciascuno indica i sistemi coperti (con riferimento all'inventario), le operazioni vietate, le eventuali eccezioni previste e chi le approva, la data dell'ultima verifica. Un divieto senza proprietario e senza riesame tende a degradare man mano che sistemi e integrazioni cambiano.
Esempio illustrativo: la rete di confezionamento
Esempio illustrativo. Lo scenario seguente è inventato e serve a mostrare il metodo; non racconta un caso reale.
Un'azienda alimentare ha una linea di confezionamento con controllori di macchina, una rete di supervisione e la rete degli uffici. In fase di adozione, il responsabile IT/OT classifica: controllori e safety in classe A (nessun accesso in scrittura per gli agenti, nessun connettore configurato); rete di supervisione in classe B (lettura e proposte); firewall perimetrale e account utente in classe C.
Una sera un dispositivo di supervisione inizia a contattare una destinazione non prevista. L'agente propone una restrizione di rete mirata sul firewall perimetrale — classe C, eseguibile solo dopo approvazione — e contemporaneamente segnala che un possibile riavvio del dispositivo è fuori ambito: quel dispositivo è in classe B, quindi l'eventuale intervento spetta al tecnico dell'impianto, con gli strumenti previsti dalla manutenzione. Il responsabile approva la restrizione in perimetrale e convoca il manutentore per il dispositivo: due percorsi diversi, decisi dalla classificazione scritta prima dell'incidente, non improvvisati durante.
Chi può modificare i confini, e come
I confini operativi non sono immutabili: nascono nuovi sistemi, cambiano i processi, un'eccezione temporanea può essere necessaria. Quello che non deve accadere è che il confine si sposti per inerzia — perché «serviva per questa volta» e poi nessuno l'ha ripristinato. Serve una procedura breve e scritta, con tre ruoli distinti:
- Chi propone. Chiunque rilevi un'esigenza (tecnico, manutentore, fornitore) presenta una richiesta che indica sistema, operazioni, motivazione e durata. Le richieste di allargamento temporaneo devono avere una scadenza esplicita.
- Chi approva. Per i sistemi di produzione conviene un doppio consenso: il proprietario del sistema (chi risponde della continuità operativa) e il responsabile della sicurezza. Un allargamento di un confine di classe A dovrebbe richiedere un livello ancora più alto e una motivazione documentata, o essere semplicemente escluso.
- Chi verifica. Una terza persona o un riesame periodico controlla che le modifiche approvate siano state applicate come deciso e che le eccezioni scadute siano state chiuse. Senza questo passaggio, la procedura si erode.
Ogni modifica dei confini va registrata come qualsiasi altra decisione operativa: proposta, motivazione, approvazioni, scadenza, verifica. La stessa logica della tracciabilità delle azioni degli agenti si applica alle decisioni sui confini: fra un anno devi poter ricostruire perché quel sistema è entrato o uscito dall'ambito, e chi lo ha deciso.
Come OverZeus applica i confini operativi
Nel modello OverZeus i confini non sono un suggerimento al modello, ma controlli applicati all'esterno. Due agenti sono direttamente coinvolti:
- Themis fa rispettare privilegi, approvazioni e limiti operativi attraverso controlli esterni al modello AI: un'operazione che arriva al controllo di esecuzione senza un'autorizzazione valida, o verso una risorsa fuori ambito, viene bloccata prima dell'avvio e il motivo viene presentato. Il silenzio non autorizza: in assenza dell'approvazione prevista, l'intervento non parte.
- Cerberus sorveglia regole del firewall e separazione delle reti, proponendo e applicando solo le correzioni consentite dalle policy: la separazione tra rete di produzione e altre reti, decisa nella classificazione, diventa una configurazione sorvegliata, le cui variazioni vengono mostrate con regola, orario ed effetto prima di qualsiasi intervento.
Le proposte e le decisioni passano dall'app dei responsabili, dove l'intervento viene spiegato prima dell'autorizzazione; evidenze, autorizzazioni ed esiti restano conservati per il riesame. Su overzeus.it il percorso completo — osservazione, proposta, approvazione, esecuzione entro i limiti — è descritto insieme ai ruoli dei singoli agenti; per un quadro del funzionamento generale si può partire dalla guida alla scelta di un SOC AI.
Resta un punto fermo: la classificazione dei sistemi e la procedura di modifica dei confini sono decisioni dell'organizzazione. OverZeus le applica come policy tecniche e le rende verificabili, ma non le decide al posto tuo — e non certifica da solo la conformità a obblighi di legge o standard.
Confini scritti, confini applicati
Decidere cosa un agente non deve toccare mai è il passaggio che rende possibile tutto il resto: con i confini chiari, l'adozione sui sistemi non critici smette di essere una questione di fiducia generica. Classifica per criticità e reversibilità, traduci i divieti in controlli tecnici verificabili, regola chi può spostare i confini e registra ogni modifica. Poi riesamina: sistemi, rischi e integrazioni cambiano, e i confini devono cambiare solo per decisione esplicita.
Guarda come vengono presentati e autorizzati gli interventi degli agenti.
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.