Una segnalazione può uscire dal server locale senza aprire la rete aziendale: nel progetto OverZeus l'app dei responsabili si collega al server nel CED (il centro elaborazione dati) tramite una VPN, cioè una rete privata virtuale, appoggiata a una connessione 5G cifrata proprietaria. Sul canale viaggiano la notifica, il suo contesto e la decisione del responsabile; analisi, fonti e dati aziendali restano dentro. E a decidere sugli interventi è sempre una persona autorizzata: la mancata risposta non vale come consenso.
Il desiderio: decidere da ovunque
Chi guida un'azienda non vuole scoprire il lunedì mattina quello che è successo sabato. Vuole sapere, mentre è fuori sede, se un sistema importante ha un problema, e vuole poter dire «procedi» o «fermati» senza dover raggiungere l'ufficio. È una richiesta legittima, che però spesso viene soddisfatta nel modo sbagliato: aprendo varchi nella rete per raggiungere i sistemi dall'esterno, esponendo servizi a Internet o installando strumenti di controllo remoto generici, pensati per la manutenzione e non per la sicurezza.
Ogni varco aperto «per comodità» è anche un varco che qualcun altro può cercare. La domanda giusta, quindi, non è «come faccio a entrare nella mia rete da remoto», ma «come faccio a ricevere le informazioni che servono e a rispondere, mantenendo la rete chiusa». Sono due architetture diverse: nella prima lo smartphone diventa una porta di ingresso verso l'interno; nella seconda esiste un canale dedicato, stretto e controllato, pensato solo per notifiche e decisioni.
Il percorso della segnalazione, passo per passo
Nel progetto OverZeus il viaggio di una segnalazione segue una sequenza precisa, che vale la pena conoscere prima di configurarla:
- Osservazione nel CED. Gli agenti lavorano sul server installato in azienda e leggono le fonti autorizzate. Quando qualcosa cambia — per esempio una regola del firewall modificata — Cerberus, l'agente che sorveglia firewall e separazione delle reti, confronta la configurazione con quella precedente e identifica la variazione.
- Preparazione del messaggio. Hermes raccoglie la segnalazione e la traduce per chi decide: cosa è cambiato, quando, quale effetto ha sugli accessi e quali informazioni mancano ancora. Non un allarme cifrato da tecnici, ma una spiegazione leggibile.
- Consegna sul canale dedicato. L'app dei responsabili si collega direttamente al server locale tramite VPN, su una connessione 5G cifrata proprietaria. La notifica arriva sullo smartphone senza che la rete aziendale esponga servizi su Internet.
- Decisione e ritorno. Il responsabile legge, valuta e risponde: confermare, chiedere una verifica o approvare l'intervento proposto. La decisione rientra dal canale e viene associata al caso.
Un punto da tenere distinto: il canale remoto richiede connettività. Il server nel CED può operare senza collegamento a Internet per le attività di osservazione e analisi — con il limite che aggiornamenti, fonti esterne di intelligence e assistenza remota degradano in isolamento, e che l'autonomia effettiva va dimostrata in prova (Shadow Mode), non assunta; ne parliamo nell'articolo su come funziona l'AI in sede senza Internet — ma la notifica verso lo smartphone viaggia sulla sua rete, la 5G, indipendente dalla connessione Internet della sede. Se manca copertura, il comportamento esatto del recapito va definito in fase di progetto e verificato in prova: è una dipendenza reale, non un dettaglio.
Cosa viaggia sul canale e cosa resta dentro
Un canale ben definito si riconosce da che cosa trasporta. L'obiettivo è portare fuori il minimo necessario per decidere, lasciando il resto nel CED:
| Viaggia sul canale remoto | Resta nel CED |
|---|---|
| La notifica: cosa è stato osservato e quando. | Le fonti complete: log, configurazioni, eventi originali. |
| Il contesto sintetico: sistemi coinvolti, effetto, informazioni mancanti. | L'elaborazione degli agenti, che avviene sul server locale. |
| La proposta di intervento, con le conseguenze previste. | Le evidenze conservate da Mnemosyne: timeline, proposte, autorizzazioni ed esiti. |
| La decisione del responsabile: approvazione, rifiuto o richiesta di verifica. | L'esecuzione degli interventi autorizzati, sui sistemi interni. |
Questa separazione ha due benefici. Il primo è di riservatezza: chi intercettasse il canale troverebbe descrizioni sintetiche, non l'archivio aziendale — e il canale stesso è cifrato, secondo quanto dichiarato dal progetto; i dettagli tecnici della cifratura proprietaria, non essendo documentati pubblicamente, vanno chiesti e verificati in fase di offerta. Il secondo è di chiarezza: la notifica contiene ciò che serve per una decisione, non un flusso di dati grezzi da interpretare sotto stress.
Notifica remota non significa rete aperta
Esistono tre modelli che non vanno confusi. La rete interna isolata non comunica con l'esterno: massima chiusura, ma nessuna visibilità da remoto. L'accesso remoto privato — come il canale Hermes — è un passaggio dedicato e controllato verso un solo servizio: non rende la rete «aperta», ma non è nemmeno isolamento totale, e porta con sé rischi residui propri da gestire (credenziali dell'app, dispositivo del responsabile, copertura della rete mobile). La dipendenza da servizi cloud è un terzo modello ancora: i dati escono per essere elaborati altrove. Le differenze operative tra questi tre scenari sono il tema dell'articolo sulle architetture tra rete isolata, accesso remoto e cloud.
La distinzione conta anche quando si valuta la modalità alternativa di OverZeus, che collega gli agenti ad API di intelligenza artificiale (interfacce di programmazione con cui un software richiede un servizio esterno) su Azure o AWS in una regione europea concordata: è un'architettura diversa, con flussi verso l'esterno da esaminare caso per caso — il confronto è approfondito in AI locale nel CED o API cloud. Attenzione alla dicitura «regione europea»: da sola non chiude la questione. Nella documentazione di Azure, Microsoft spiega che il luogo di elaborazione dipende dal tipo di deployment: con un deployment «Global» i prompt possono essere elaborati in qualsiasi geografia in cui il modello è distribuito, anche con la risorsa creata in Europa. Analogamente, per Amazon Bedrock la documentazione AWS distingue profili di inferenza geografici e profili globali: solo i primi mantengono l'elaborazione dentro la geografia scelta, e la pagina stessa li raccomanda a chi ha requisiti di residenza dei dati. In entrambi i casi, la geografia va verificata nella configurazione effettiva, non sulla fattura.
Approvare o rifiutare: poteri e limiti dell'app
L'app non è un telecomando con poteri illimitati: è il punto in cui una persona autorizzata esercita una decisione prevista dal piano. Tre regole la definiscono:
- Chi decide è un elenco, non «chi ha l'app». I responsabili che ricevono le notifiche e possono approvare vanno indicati per nome e per ruolo in fase di progetto, con eventuali distinzioni: chi può solo confermare attività previste, chi può autorizzare un intervento sui sistemi.
- L'approvazione ha confini tecnici. Themis fa rispettare privilegi, approvazioni e limiti operativi attraverso controlli esterni al modello AI: un intervento che supera i limiti concordati viene bloccato anche se qualcuno lo ha approvato, e un'autorizzazione non più valida non riapre l'azione.
- Il silenzio non autorizza. Se nessuno risponde, l'intervento attivo non parte. Il caso resta visibile e la mancata risposta, con la sua motivazione successiva, entra nelle evidenze conservate da Mnemosyne.
Prima dell'attivazione conviene mettere per iscritto alcune decisioni: quali livelli di gravità generano una notifica e quali restano nel riepilogo; chi riceve cosa e in quali orari; chi è il sostituto se il primo responsabile è irreperibile; con quale cadenza si rivede l'elenco degli autorizzati. Sono scelte organizzative, non impostazioni tecniche, e determinano quanto il canale sarà davvero utile nei weekend e nei periodi di ferie.
Esempio illustrativo: la regola del sabato mattina
Esempio illustrativo. Lo scenario seguente mostra il percorso proposto da OverZeus; non racconta un incidente avvenuto presso un cliente.
Un'azienda di logistica ha il server con gli agenti nel proprio CED. Sabato mattina, mentre il titolare è fuori regione per una fiera, una nuova regola del firewall consente alla rete Wi-Fi degli ospiti del magazzino di raggiungere il server del gestionale. Cerberus confronta la configurazione con quella precedente e identifica la modifica; Hermes recapita la notifica sull'app tramite il canale VPN su 5G: cosa è cambiato, a che ora, quale accesso diventa possibile e quale verifica manca — per esempio se la modifica corrisponde a un intervento del tecnico di turno.
Il titolare ha tre opzioni, ciascuna con le sue conseguenze. Mantenere la regola e chiedere una verifica: nessuna interruzione se la modifica è legittima, ma l'esposizione resta fino alla conferma. Approvare il ripristino della configurazione precedente: la separazione torna quella prevista, dopo aver chiarito se qualche servizio autorizzato usa quel collegamento. Non rispondere: non succede nulla di automatico, perché il silenzio non autorizza; il caso resta aperto e visibile. Qualunque sia la scelta, decisione e contesto restano registrati: il lunedì il referente IT trova la ricostruzione completa, non un messaggio vocale da interpretare.
Un canale si definisce, non si subisce
Ricevere notifiche di sicurezza sullo smartphone con una rete interna chiusa è possibile, a condizione di trattare il canale remoto come un componente da progettare: cosa trasporta, chi lo usa, quali decisioni può veicolare e quali limiti restano fuori dalla portata dell'app. La differenza tra «visibilità da remoto» e «rete esposta» sta tutta in queste definizioni, e va verificata nella configurazione reale — di OverZeus come di qualsiasi altra soluzione — non affidata alle descrizioni generali.
Confronta con noi un'installazione nel CED e una configurazione API europea.
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.