Aggiornare un'AI senza accesso a Internet: regole e procedure

Un'intelligenza artificiale installata in una rete isolata si può aggiornare, ma non da sola: ogni nuovo modello, regola o componente entra attraverso un canale controllato, viene verificato da persone individuate in anticipo e applicato solo dopo un'approvazione esplicita, con un piano per tornare indietro se qualcosa non funziona. Questa procedura non nasce con il prodotto: va definita in fase di progetto, con ruoli, responsabilità e registrazioni concordati per iscritto.

Il ciclo di vita degli aggiornamenti in isolamento

In una rete connessa, gli aggiornamenti arrivano dai server del fornitore in modo automatico o semiautomatico. In un ambiente isolato questo flusso non esiste: il prezzo dell'isolamento è che la manutenzione diventa un processo organizzativo, non un download. Prima di scegliere un'installazione locale, conviene distinguere che cosa va aggiornato, perché non tutto ha la stessa urgenza:

• il modello di intelligenza artificiale, cioè il componente che elabora e ragiona sui dati: cambia con cadenza lenta, ma ogni versione va valutata;
• regole, policy e soglie, che traducono le tue decisioni in comportamenti del sistema: si aggiornano spesso e sono di tua responsabilità;
• il software di base del server (sistema operativo e componenti): richiede le consuete cure di sicurezza, pianificate;
• le fonti di conoscenza esterna, come elenchi di indicatori di minaccia: in isolamento smettono di aggiornarsi da sole e invecchiano.

OverZeus dichiara che la modalità con installazione nel CED — il centro elaborazione dati dell'azienda — può operare senza collegamento a Internet: questa formulazione riguarda il funzionamento ordinario — monitoraggio, analisi, proposte — non elimina la necessità di manutenzione. Come spieghiamo nell'articolo su cosa resta attivo quando l'AI lavora senza Internet, aggiornamenti e fonti esterne sono esattamente le funzioni che degradano in isolamento e vanno governate con una procedura.

Un ciclo di vita ragionevole per ogni aggiornamento, da adattare al tuo contesto, ha queste fasi:

Come entra un aggiornamento in una rete isolata

La prima domanda pratica è fisica: se la rete non esce su Internet, il pacchetto deve entrare in un altro modo. Le opzioni tipiche, da scegliere in base al livello di segregazione richiesto, sono tre:

• Supporto removibile gestito. Il pacchetto arriva su un supporto registrato, preparato su una postazione esterna e consegnato secondo una catena di custodia: chi lo ha preparato, chi lo ha trasportato, chi lo ha introdotto.
• Stazione di trasferimento. Una macchina dedicata, posta tra l'esterno e la rete isolata, su cui il pacchetto viene scaricato, controllato e poi passato all'interno. Nessun'altra funzione transita da quella macchina.
• Finestra di collegamento controllata. Un collegamento temporaneo e dedicato, attivato solo per il trasferimento e poi chiuso. È l'opzione meno «isolata»: va valutata con onestà, perché per quella finestra la rete non è più segregata.

Qualunque sia il canale, tre controlli restano costanti: il supporto o il flusso attraversa una zona di quarantena con scansione; l'integrità del pacchetto viene verificata confrontando l'impronta di controllo (hash) con quella pubblicata dal fornitore e, dove prevista, la firma digitale; ogni introduzione viene registrata con data, contenuto e persona responsabile. Gli aggiornamenti automatici, per definizione, sono esclusi.

Attenzione anche alle vie d'ingresso laterali: un canale di assistenza remota del fornitore è a tutti gli effetti una porta per gli aggiornamenti, e va trattato con le stesse regole. Su questo tema rimandiamo all'articolo sulle verifiche da fare quando un fornitore promette che i dati non escono mai.

Chi verifica un aggiornamento prima di applicarlo

La verifica non è un solo controllo ma una sequenza con ruoli diversi. Il fornitore attesta che cosa contiene il pacchetto e ne pubblica l'impronta. L'amministratore IT verifica integrità e compatibilità con l'installazione esistente. Un ambiente di prova a specchio — una copia non produttiva dell'installazione — permette di applicare l'aggiornamento su casi concordati prima di toccare il sistema reale: per un modello AI, per esempio, si ripete un insieme fisso di richieste note e si confrontano i comportamenti. Infine il responsabile designato approva per iscritto l'applicazione, con finestra oraria e condizioni.

Questa separazione ha un senso preciso: chi produce l'aggiornamento non lo approva, chi lo approva non lo applica da solo, e ogni passaggio lascia una traccia. In OverZeus questo principio è coerente con l'architettura dichiarata: Themis fa rispettare privilegi, approvazioni e limiti operativi attraverso controlli esterni al modello AI, quindi un'operazione che arriva all'esecuzione senza un'autorizzazione valida resta bloccata e il motivo viene mostrato. Nestor può aiutare il team a recuperare e confrontare manuali, runbook e versioni delle procedure, rispettando i permessi; la revisione e l'aggiornamento dei documenti restano però al proprietario della procedura, nel processo concordato. Nessun agente approva un aggiornamento al posto tuo.

Piano di rientro e registrazione degli esiti

La terza domanda è quella che si dimentica più spesso: se l'aggiornamento crea problemi, come si torna indietro? Il piano di rientro va scritto prima dell'applicazione, non improvvisato dopo. Tre elementi lo rendono praticabile:

• La versione precedente resta ripristinabile. Configurazione, modello e dati necessari al ripristino vengono conservati in forma utilizzabile, non solo elencati. Un ripristino mai provato è un'ipotesi, non un piano.
• I criteri di esito sono decisi in anticipo. Si definisce che cosa osservare nella finestra successiva all'aggiornamento e chi dichiara il successo o avvia il rientro. Senza criteri, ogni anomalia diventa una discussione.
• L'esito viene registrato comunque. Anche un aggiornamento andato bene lascia evidenze: versione, verifiche, approvazione, esito. Serviranno al prossimo aggiornamento e a chiunque dovrà ricostruire la storia del sistema.

In OverZeus Mnemosyne conserva fonti, timeline, proposte, autorizzazioni ed esiti, aiutando a ricostruire il percorso di ogni intervento: in un processo di aggiornamento concordato, è il punto in cui decisioni e risultati restano consultabili nel tempo. Il NIST AI Risk Management Framework, riferimento volontario per la gestione del rischio dei sistemi AI, indica nella documentazione delle decisioni un elemento centrale della governance: utile come lessico per organizzare queste registrazioni, senza che citarlo equivalga a una certificazione.

Esempio illustrativo: un modello nuovo in un ambiente segregato

Esempio illustrativo. Lo scenario seguente mostra come potrebbe svolgersi la procedura concordata; non racconta un caso avvenuto presso un cliente.

Un'azienda con un ambiente regolamentato ha l'installazione locale di OverZeus nel proprio CED, senza uscita verso Internet. Il fornitore rilascia una nuova versione del modello. Il pacchetto viene consegnato su supporto registrato, con note di versione e impronta di controllo. L'amministratore lo porta nella stazione di trasferimento, verifica l'impronta e lo passa alla quarantena per la scansione. Sull'ambiente specchio l'aggiornamento viene applicato e testato con un insieme fisso di richieste concordate: le risposte vengono confrontate con la versione precedente.

Il responsabile riceve il piano nell'app — versione attuale, versione proposta, esiti delle prove, finestra di applicazione, condizioni di rientro — e approva. L'applicazione avviene nella finestra concordata, con la versione precedente pronta. Nei giorni di osservazione un criterio non viene soddisfatto: il responsabile dichiara il rientro, la versione precedente viene ripristinata e Themis verifica che il ripristino rientri nei limiti autorizzati. Mnemosyne conserva l'intero percorso: pacchetto, verifiche, approvazione, esito e rientro. Al rilascio successivo, quella registrazione è il punto di partenza.

E se invece l'AI lavora via API in Europa?

Il problema cambia forma ma non sparisce. Con la modalità via API — interfacce di programmazione con cui il tuo sistema interroga i modelli del provider attraverso la rete — su Azure o AWS in una regione europea, il ciclo di vita del modello è gestito dal provider: le versioni evolvono secondo le sue regole, non secondo il tuo calendario. Ciò che resta di tua responsabilità è la configurazione: sulla documentazione Microsoft su dati, privacy e sicurezza dei modelli in Azure Foundry, il tipo di deployment (standard, DataZone, Global) determina dove avviene l'elaborazione; sulla guida AWS all'inferenza cross-region di Bedrock, la stessa scelta passa dal profilo di inferenza, geografico o globale. Anche qui servono versioni concordate, verifiche prima di un cambio e un modo per registrare quale configurazione era attiva. Il confronto completo tra i due modelli è nell'articolo su AI locale nel CED o API cloud europee.

Checklist prima del primo aggiornamento

Queste procedure non sono una funzione già pronta del prodotto: sono requisiti da mettere per iscritto in fase di progetto. Prima che arrivi il primo aggiornamento, la tua organizzazione dovrebbe poter rispondere a queste domande:

• Quali canali di ingresso sono ammessi, e chi può introdurre un pacchetto?
• Come si verifica integrità e provenienza di ogni aggiornamento?
• Esiste un ambiente di prova a specchio, e quali casi copre?
• Chi approva l'applicazione, con quale forma e quali tempi?
• Che cosa garantisce il ripristino della versione precedente, ed è stato provato?
• Dove restano registrati esiti, decisioni e rientri, e per quanto tempo?

Se una risposta manca, è meglio scoprirlo ora che durante un aggiornamento urgente di sicurezza.

Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.

Tutti gli articoli OverZeus