Un'AI installata su un server nel tuo CED, il centro elaborazione dati aziendale, può continuare a osservare, analizzare e preparare proposte anche quando il collegamento a Internet si interrompe, perché l'elaborazione avviene in locale. Non tutto però resta uguale: aggiornamenti, fonti esterne di intelligence e assistenza remota si fermano o degradano, e ogni funzione dichiarata «operativa senza Internet» va dimostrata in prova, non assunta sulla parola. Questa guida spiega cosa resta attivo, cosa si perde e come verificarlo prima dell'acquisto.
Prima distinzione: isolato, remoto privato, cloud
Quando un fornitore dice «funziona senza Internet», chiedi a quale dei tre scenari si riferisce, perché non sono equivalenti.
- Rete interna isolata. Il server e i sistemi osservati lavorano dentro il perimetro aziendale, senza traffico verso l'esterno. L'elaborazione dell'AI è locale: i modelli girano sul tuo hardware e i dati non escono.
- Accesso remoto privato. Il sistema resta in sede, ma un canale dedicato collega i responsabili da fuori. In OverZeus è il caso dell'app Hermes, che raggiunge il server locale tramite una VPN (rete privata virtuale) su connessione 5G cifrata proprietaria: non richiede l'Internet della sede, ma richiede una connettività propria, attiva e coperta.
- Dipendenza da servizi cloud. L'analisi avviene chiamando API (interfacce di programmazione applicativa) di un provider esterno, per esempio Azure o AWS in una regione europea. Senza connessione verso quei servizi, l'analisi semplicemente non parte.
La differenza pratica è netta: nella scelta tra installazione nel CED e API cloud, la prima può reggere un'interruzione di connettività, la seconda no. E anche nell'installazione locale, il canale verso l'app dei responsabili è un quarto elemento da valutare a parte, con le sue dipendenze. Le differenze tra rete isolata, accesso remoto privato e architetture cloud meritano una trattazione dedicata: qui ci concentriamo su cosa succede quando la connessione manca.
Cosa resta attivo durante un'interruzione
In un'installazione locale correttamente progettata, il cuore del lavoro non dipende dalla rete esterna. Restano operative le funzioni che vivono sul server in sede.
Osservazione e raccolta. Gli agenti continuano a leggere le fonti interne collegate: log, eventi di sicurezza, stato dei servizi, configurazioni. In OverZeus questo è il compito di Argus, che osserva eventi, servizi, rete e dispositivi collegati ed evidenzia anomalie e scostamenti dalla situazione attesa. Finché le fonti sono raggiungibili nella rete interna, il monitoraggio non si interrompe.
Analisi e proposte. L'inferenza, cioè l'elaborazione del modello AI, avviene in locale: il sistema può correlare i segnali e preparare proposte. Ares organizza priorità, indagini ed escalation, e ogni intervento segue un piano con responsabilità e autorizzazioni chiare: preparare il piano non richiede Internet, eseguirlo richiede comunque l'approvazione prevista.
Controlli e memoria. I limiti operativi e la conservazione delle evidenze sono funzioni interne. In OverZeus Themis applica privilegi e approvazioni attraverso controlli esterni al modello AI, e Mnemosyne conserva fonti, timeline, proposte, autorizzazioni ed esiti: anche in isolamento, ogni decisione continua a lasciare una traccia ricostruibile.
Attenzione però a un punto: «resta attivo» riguarda ciò che è stato dichiarato e configurato per il tuo progetto. L'elenco preciso delle funzioni operative senza connettività va messo per iscritto con il fornitore, perché è lì che si gioca la differenza tra una promessa commerciale e un requisito verificabile.
Cosa degrada o si ferma senza connessione
L'autonomia locale ha un prezzo: tutto ciò che vive fuori dalla sede smette di arrivare. Le aree tipiche sono quattro.
Aggiornamenti. Modelli AI, firme, componenti software e patch non si aggiornano da soli in un ambiente isolato. In ambienti con requisiti di isolamento, l'importazione di un nuovo modello o di un aggiornamento diventa una procedura da concordare: pacchetto verificato su un ambiente di test, approvazione del responsabile, applicazione pianificata e piano di rientro documentato. Non è un dettaglio da dare per scontato: chiedi come aggiornare un'AI offline prima di firmare, non dopo.
Fonti esterne di intelligence. Se l'analisi usa informazioni aggiornate dall'esterno, per esempio elenchi di indicatori di compromissione o bollettini sulle vulnerabilità, quelle fonti invecchiano giorno dopo giorno. Il sistema continua a ragionare, ma su un quadro del mondo che si congela al momento dell'interruzione.
Assistenza e supporto remoto. Se il fornitore interviene da remoto per manutenzione o diagnosi, quel canale cade insieme alla connessione. Va chiarito chi può intervenire in sede e con quali procedure.
Il canale verso i responsabili. Se le notifiche arrivano su smartphone attraverso un canale dedicato, la sua disponibilità dipende dalla sua rete, non da quella della sede. Con Hermes il collegamento avviene tramite VPN su connessione 5G cifrata proprietaria: un blackout dell'Internet aziendale non lo interrompe, ma una zona senza copertura o una rete volutamente senza alcun canale esterno sì. In un ambiente a isolamento totale, le approvazioni devono poter avvenire dall'interno, e questo va progettato.
La tabella riassume il quadro per le due modalità.
| Funzione | Installazione locale senza Internet | Analisi via API cloud senza Internet |
|---|---|---|
| Monitoraggio delle fonti interne | Continua, se le fonti sono raggiungibili in rete locale | Le fonti vengono lette, ma l'analisi remota non parte |
| Analisi AI e proposte | Continua in locale | Si interrompe: richiede connessione ai servizi API |
| Controlli di autorizzazione ed evidenze | Continuano sul server in sede | Dipendono da dove risiedono nella configurazione scelta |
| Aggiornamenti di modelli e software | Sospesi: richiedono una procedura concordata | Gestiti dal provider, ma irraggiungibili senza connessione |
| Fonti esterne di intelligence | Si congelano all'ultimo aggiornamento ricevuto | Non raggiungibili |
| Notifiche verso l'app dei responsabili | Dipendono dal canale dedicato (es. 5G), non dall'Internet della sede | Dipendono dalla configurazione concordata |
| Assistenza remota del fornitore | Si interrompe con la connessione | Si interrompe con la connessione |
Per quanto tempo regge l'autonomia
Non esiste una soglia universale: dipende da quanto degrada il tuo rischio mentre il sistema lavora con informazioni ferme. Un impianto isolato per policy può funzionare per mesi con aggiornamenti pianificati e importati con procedura; una sede con un blackout imprevisto deve sapere che il sistema resta operativo, ma con intelligence e protezioni ferme all'ultimo aggiornamento, e che ogni giorno di isolamento allunga l'elenco delle verifiche da fare al rientro.
Due domande aiutano a fissare un limite ragionato per la tua realtà: quanto invecchia in fretta il tuo panorama di minacce, e quali obblighi di aggiornamento hai verso clienti, norme o certificazioni. Le risposte diventano requisiti di progetto, per esempio la frequenza concordata degli aggiornamenti importati e le condizioni che impongono una revisione straordinaria. In OverZeus queste procedure non sono automatismi dati per scontati: vanno definite insieme, con ruoli umani espliciti.
Esempio illustrativo: il blackout del venerdì sera
Esempio illustrativo. Lo scenario seguente mostra come ragionare sull'autonomia; non racconta un evento avvenuto presso un cliente.
Un'azienda alimentare con uno stabilimento in una zona mal servita ha installato il sistema di monitoraggio AI su un server nel proprio CED, perché la connettività cade alcune volte all'anno, anche per ore. Un venerdì sera il collegamento a Internet dello stabilimento si interrompe.
Argus continua a osservare i server di produzione e i controller di linea collegati in rete interna, e rileva un servizio che cresce in modo anomalo nei log. Ares prepara una proposta di indagine con priorità e impatti: il piano arriva al responsabile di turno tramite l'app Hermes, perché il canale VPN su 5G cifrata non dipende dalla linea caduta. Il responsabile approfondisce, scopre che la causa è un'attività pianificata e registra la decisione di non intervenire; Mnemosyne conserva segnale, proposta e motivazione.
Cosa non è successo, in quelle ore: nessun aggiornamento di modello o di intelligence è arrivato, il fornitore non poteva collegarsi da remoto, e se il responsabile si fosse trovato in una zona senza copertura 5G anche l'app sarebbe rimasta muta. Se lo stabilimento avesse scelto l'analisi via API cloud, invece, anche la proposta di Ares non sarebbe mai stata preparata. Il lunedì, al rientro della connettività, la checklist prevede: aggiornamenti accumulati da importare, esito del fine settimana da riesaminare, durata dell'interruzione registrata tra le evidenze.
Come testare l'autonomia prima dell'acquisto
La frase «funziona senza Internet» si trasforma in requisito solo se la provi. Una checklist pratica:
- Elenco scritto delle funzioni. Chiedi quali funzioni sono dichiarate operative senza connettività e con quali limiti, funzione per funzione. Chi non sa rispondere per iscritto non ha progettato l'isolamento.
- Interruzione simulata. Durante la prova, concorda un'interruzione controllata del collegamento esterno in un ambiente che non tocchi la produzione, e osserva cosa si ferma davvero: notifiche, analisi, aggiornamenti, assistenza. Con la prova Oracle in modalità di sola osservazione, OverZeus lavora per settimane su una macchina in comodato senza modificare la produzione: è il contesto giusto per misurare anche l'autonomia, con criteri di successo scritti prima di iniziare.
- Comunicazioni esterne nascoste. Chiedi se il sistema effettua chiamate verso l'esterno in funzionamento normale: telemetria, attivazione di licenze, controlli di validità. Un sistema «isolato» che si lamenta quando non raggiunge il fornitore va conosciuto prima, non durante un blackout.
- Procedura di aggiornamento offline. Fatti descrivere come entra un aggiornamento in ambiente isolato: verifica del pacchetto, approvazione, applicazione, piano di rientro, registrazione dell'esito.
- Canale verso i responsabili. Verifica da dove arrivano le notifiche quando la sede è senza Internet, e cosa succede se anche quel canale manca: chi può approvare dall'interno?
- Evidenze della prova. Ogni test deve lasciare traccia. In OverZeus Mnemosyne conserva fonti, proposte, autorizzazioni ed esiti, così l'esito della simulazione resta consultabile anche mesi dopo.
Le stesse domande valgono per qualsiasi fornitore, OverZeus incluso: portale identiche a ogni demo e confronta le risposte scritte.
Cosa dichiara OverZeus e cosa resta da concordare
Sul sito del progetto OverZeus, la modalità con installazione nel CED dichiara che agenti e intelligenza artificiale lavorano sui server dell'azienda e che il sistema «può operare senza collegamento a Internet». La modalità alternativa usa API su Azure o AWS in una regione europea concordata e richiede connessione ai servizi remoti: su Azure il luogo di elaborazione dipende dal tipo di deployment scelto (standard, DataZone o Global) e su AWS dal profilo di inferenza configurato, quindi anche la configurazione cloud va verificata, non assunta.
Restano da definire insieme, perché non sono automatismi documentati: le procedure di aggiornamento in ambiente isolato, l'elenco puntuale delle funzioni operative senza connettività per il tuo progetto, e il comportamento del canale Hermes quando serve un isolamento totale. Integrazioni, regione di elaborazione e dati condivisi vengono definiti in base alla modalità scelta. Per la continuità operativa del server in sede — alimentazione, ridondanza, manutenzione — vale lo stesso principio: requisiti scritti, prove concordate, evidenze conservate.
Nessuna di queste verifiche richiede di fidarsi: richiede di provare.
Confronta con noi un'installazione nel CED e una configurazione API europea, con l'elenco delle funzioni da verificare in prova.
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.