Quando un fornitore di sistemi di intelligenza artificiale (AI) promette che «i tuoi dati non escono mai», la frase va tradotta in un elenco verificabile: quali chiamate esterne fa il sistema in funzione normale, se telemetria, licenze, aggiornamenti e supporto remoto contano come uscita dati e quali evidenze puoi mostrare a un cliente o a un controllore. Questa guida ti dà le domande da fare, i controlli tecnici da eseguire e gli impegni da mettere per iscritto. Valgono per qualsiasi fornitore, OverZeus compreso.
Perché la promessa va scomposta
«I dati non escono mai» può voler dire cose molto diverse. Può indicare che i contenuti trattati dal sistema — documenti, registri, richieste degli utenti — restano nella tua infrastruttura. Oppure che nessun dato, di nessun tipo, lascia la rete aziendale. La seconda formulazione è quasi sempre falsa in senso letterale: un sistema moderno comunica con l'esterno per molte funzioni accessorie, anche quando l'elaborazione principale avviene in sede.
La verifica corretta non parte dalla frase di marketing ma da una domanda precisa: elencami ogni chiamata esterna che il sistema effettua in funzione normale. Se la risposta è un elenco breve e documentato, la promessa ha una base. Se è generica — «nessuna, stai tranquillo» — la verifica è appena cominciata.
Questo vale anche per le architetture «in Europa»: una risorsa cloud con regione europea non basta a chiudere il discorso, perché il luogo di elaborazione può dipendere dalla configurazione scelta. Ne parliamo nella guida su le verifiche su Azure e AWS in Europa e nel confronto tra installazione nel CED e API cloud.
Le vie d'uscita nascoste: telemetria, licenze, aggiornamenti, supporto
Quattro canali passano spesso inosservati durante la valutazione, perché non trasportano i documenti che ti preoccupano ma possono comunque portare fuori informazioni:
- Telemetria e diagnostica. Molti prodotti inviano al fornitore statistiche d'uso, rapporti di errore o identificativi dell'installazione. Il contenuto può essere tecnico e anonimo, oppure includere nomi di sistemi, percorsi di file, frammenti di configurazione. Chiedi che cosa viene raccolto, con quale frequenza, verso quali destinazioni e se la telemetria si può disattivare senza perdere funzioni.
- Verifica delle licenze. Il controllo periodico della licenza può richiedere una chiamata verso i server del produttore. Di solito trasporta solo un identificativo, ma è comunque una comunicazione in uscita da conoscere e autorizzare.
- Aggiornamenti automatici. Il download degli aggiornamenti è un canale in ingresso, ma spesso si accompagna a un canale in uscita: segnalazione della versione installata, esito dell'aggiornamento, inventario dei componenti. In un ambiente che deve restare isolato, va chiarito come arrivano gli aggiornamenti e chi li approva.
- Canali di supporto remoto. L'assistenza del fornitore può prevedere una connessione dall'esterno per diagnosi e manutenzione. È legittima se concordata, ma è una porta: va definita per iscritto (quando si apre, chi la autorizza, quali dati attraversa) e chiusa quando non serve.
A questi si aggiunge, nelle configurazioni cloud, il canale verso l'API del modello (l'interfaccia di programmazione con cui il sistema interroga un servizio esterno): ogni richiesta inviata è per definizione un'uscita di dati, che va delimitata per contenuto e destinazione. Anche il collegamento remoto delle persone — per esempio un'app che raggiunge il server dall'esterno — è una comunicazione che esce dal perimetro, per quanto protetta.
In sintesi, per ogni canale servono una domanda e un'evidenza:
| Canale | Domanda da fare | Evidenza da conservare |
|---|---|---|
| Telemetria e diagnostica | Cosa raccoglie, verso dove, e si può disattivare? | Documentazione del fornitore e configurazione applicata. |
| Verifica licenze | Quando chiama casa e con quali contenuti? | Voce nell'elenco delle comunicazioni autorizzate. |
| Aggiornamenti | Come arrivano e chi li approva, anche in ambiente isolato? | Procedura concordata e registro delle applicazioni. |
| Supporto remoto | Quando si apre, chi lo autorizza, cosa attraversa? | Regole scritte e registro delle sessioni. |
| API cloud e accesso remoto | Quali dati escono, verso quale servizio e configurazione? | Configurazione documentata e registri del servizio. |
Le verifiche tecniche: cosa fa davvero il sistema
La risposta del fornitore è il punto di partenza; la verifica si fa osservando il sistema. Tre controlli alla portata della maggior parte dei reparti IT:
- Registro delle connessioni in uscita. Sul firewall o sul sistema che filtra il traffico, osserva le destinazioni contattate dal server o dal servizio AI per un periodo rappresentativo, per esempio alcune settimane. Ogni destinazione va attribuita a una funzione nota: telemetria, licenza, aggiornamento, API concordata. Ciò che resta senza spiegazione va chiarito prima dell'entrata in esercizio.
- Configurazione documentata. Per i servizi cloud, il luogo di elaborazione dipende dalle scelte fatte. Su Azure, la documentazione Microsoft spiega che un deployment di tipo «Global» può elaborare le richieste in qualsiasi geografia in cui il modello è distribuito, anche con dati a riposo in Europa, e che il controllo anti-abuso può prevedere la revisione di campioni da parte di personale Microsoft, salvo modifica per i clienti idonei (Data, privacy, and security — Azure Foundry). Su AWS Bedrock, lo stesso servizio può usare un profilo di inferenza geografico, con elaborazione entro la geografia scelta, oppure globale, con elaborazione in qualsiasi regione supportata nel mondo (Cross-Region inference — Amazon Bedrock). La dicitura «Europa» sulla fattura non risponde a queste domande: risponde la configurazione.
- Prova in condizioni controllate. Prima dell'adozione, fai funzionare il sistema in un perimetro di prova e misura le comunicazioni che genera. È il modo più semplice per confrontare la documentazione con il comportamento reale, senza toccare la produzione.
Gli impegni da mettere per iscritto
Le verifiche tecniche fotografano il presente; il contratto tutela il futuro. Chiedi che l'offerta o l'accordo contengano almeno:
- l'elenco delle comunicazioni esterne previste in funzione normale, con scopo, contenuto e destinazione di ciascuna;
- l'impegno a notificare nuove comunicazioni introdotte da aggiornamenti successivi, prima della loro attivazione;
- per le configurazioni cloud, il tipo di deployment o profilo concordato e le condizioni in cui può cambiare;
- le regole del canale di supporto remoto: attivazione, autorizzazione, registrazione delle sessioni;
- il diritto di verifica periodica, con le modalità concordate.
Una clausola che dice «i dati restano in azienda» senza elencare le eccezioni sposta il rischio su di te: quando scoprirai la telemetria, sarà «sempre stata prevista».
Le evidenze da produrre a clienti e controllori
Se sei tu a dover dimostrare la promessa — a un cliente che ti affida i suoi dati, a un revisore, a un ente di controllo — servono evidenze, non dichiarazioni. Una buona raccolta comprende:
- la mappa dei flussi: quali dati alimentano il sistema, dove sono trattati, quali comunicazioni esterne esistono e perché;
- i registri delle osservazioni: l'esito dei controlli sulle connessioni in uscita, con data e perimetro;
- le prove specifiche del servizio cloud, se lo usi: su AWS, per esempio, CloudTrail registra nella regione di origine un campo che indica la regione in cui la richiesta è stata effettivamente elaborata — un'evidenza concreta da conservare e mostrare;
- le decisioni e le autorizzazioni: chi ha approvato l'attivazione di un canale, quando, con quale motivazione.
La mappa dei flussi è anche il punto di partenza di ogni progetto AI serio: ne parliamo nell'articolo su come documentare dove stanno i dati. Ricorda infine che residenza dei dati in UE, sovranità e conformità sono tre concetti distinti: dimostrare dove i dati stanno non chiude da solo il giudizio complessivo.
Esempio illustrativo: l'audit delle vie d'uscita
Esempio illustrativo. Lo scenario seguente è inventato per mostrare il metodo; non racconta un caso reale.
Uno studio di progettazione sta valutando un sistema di assistenza AI installato su un server nella propria sede. Il fornitore dichiara: «tutto resta in casa vostra». Il responsabile IT chiede l'elenco delle comunicazioni esterne e ottiene: verifica licenza una volta al giorno, telemetria anonima disattivabile, aggiornamenti mensili scaricati su richiesta.
Prima di firmare, attiva una prova di due settimane con il traffico in uscita registrato. Il registro conferma licenza e aggiornamenti, ma mostra anche una connessione quotidiana verso un servizio di analisi degli errori non citato nell'elenco. Il fornitore spiega che si attiva solo in caso di errore, che contiene la versione dei componenti e che si può disattivare. Lo studio chiede la modifica in configurazione e l'aggiunta del canale — disattivato — all'elenco contrattuale. L'elenco aggiornato, i registri della prova e la decisione scritta diventano l'evidenza da mostrare a un cliente che domani chiederà: «i miei disegni tecnici escono dal vostro studio?».
La stessa domanda a OverZeus
Il metodo vale anche per noi, e la domanda «quali comunicazioni esterne fai in funzione normale?» va rivolta a OverZeus come a qualsiasi altro fornitore: l'elenco va concordato e messo per iscritto in fase di progetto, perché dipende dalla configurazione scelta.
Ciò che l'architettura dichiara è il perimetro delle possibilità. Nell'installazione nel CED (il centro elaborazione dati, la sala macchine dell'azienda), agenti e intelligenza artificiale lavorano sui server della tua azienda e il sistema può operare senza collegamento a Internet. Anche questa frase va letta con precisione: aggiornamenti, fonti esterne di intelligence e assistenza remota degradano in isolamento, e l'autonomia effettiva va dimostrata nella prova iniziale, non assunta — esattamente la verifica che questo articolo propone per ogni fornitore. La modalità via API usa invece servizi su Azure o AWS in una regione europea concordata, con servizi, regione e dati da inviare definiti insieme. Il canale dell'app Hermes — una VPN, cioè una rete privata virtuale, su connessione 5G cifrata proprietaria — è un accesso remoto privato dei responsabili: esiste perché serve a portare segnalazioni e decisioni fuori dalla sede, ed è uno dei canali da elencare, non da dimenticare.
Sul piano delle evidenze, due agenti sono costruiti per questo compito. Mnemosyne conserva fonti, timeline, proposte, autorizzazioni ed esiti: se una comunicazione viene attivata, modificata o autorizzata, la traccia resta consultabile. Themis applica privilegi, approvazioni e limiti operativi attraverso controlli esterni al modello AI: un intervento attivo richiede l'approvazione prevista e l'assenza di risposta non autorizza nulla. Durante la prova in modalità Oracle — sola osservazione, senza modifiche alla produzione — puoi registrare le comunicazioni del sistema nel tuo perimetro e confrontarle con quanto dichiarato, esattamente come nell'esempio illustrativo.
Dalla promessa alla verifica
«I tuoi dati non escono mai» non va accettata né rifiutata: va verificata. Chiedi l'elenco delle comunicazioni esterne, osserva il sistema in prova, metti gli impegni per iscritto e conserva le evidenze. Un fornitore che risponde con precisione a queste domande ti sta già dimostrando qualcosa di più della frase di marketing.
Vuoi valutare un'architettura con i dati sotto il tuo controllo? Confronta con noi un’installazione nel CED e una configurazione API europea.
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.