La risposta breve: non esiste un'architettura giusta per tutti. L'installazione locale nel CED conviene quando certi dati non devono lasciare l'azienda o quando il servizio deve continuare anche senza Internet; le API — interfacce di programmazione, cioè servizi remoti a cui il software aziendale si collega — su Azure o AWS in Europa sono accettabili quando i dati inviati sono selezionati con cura e la configurazione del servizio è verificata per iscritto. La scelta va fatta caso per caso, con criteri scritti che il CIO (Chief Information Officer, il responsabile dei sistemi informativi) possa spiegare alla direzione senza slogan in nessuna delle due direzioni.
Le due architetture spiegate semplicemente
Installazione locale. Un server nel CED — il Centro Elaborazione Dati, la sala macchine dell'azienda — ospita modelli e agenti di intelligenza artificiale. L'elaborazione avviene su hardware aziendale e, come previsto dal progetto OverZeus per la sua modalità in locale, può operare senza collegamento a Internet. Questo non significa autonomia totale: aggiornamenti dei modelli, fonti esterne di intelligence e assistenza del fornitore richiedono comunque momenti di collegamento o procedure concordate, da pianificare in fase di progetto.
API su cloud europeo. L'azienda invia a un servizio AI esterno — per esempio Azure o Amazon Web Services (AWS) — solo i dati necessari all'analisi, verso una regione europea concordata. È la seconda modalità prevista da OverZeus: servizi, regione e dati da inviare vengono definiti insieme. Richiede una connessione funzionante verso i servizi remoti e una verifica della configurazione, perché la dicitura «Europa» da sola non basta.
Il motivo è tecnico e documentato. Su Azure, la pagina Microsoft su dati, privacy e sicurezza dei modelli spiega che è il tipo di deployment a decidere dove avviene l'elaborazione: con un deployment standard l'elaborazione resta nella geografia indicata, con un deployment «DataZone» può avvenire in qualsiasi paese della zona, con uno «Global» in qualsiasi geografia dove il modello è distribuito nel mondo. Su AWS, la guida di Amazon Bedrock sull'inferenza cross-region distingue profili geografici — la richiesta resta dentro la geografia scelta, per esempio l'Unione europea — e profili globali, che possono elaborare in qualsiasi regione supportata nel mondo a un costo indicativamente inferiore. La stessa pagina consiglia il profilo geografico a chi ha requisiti di residenza dei dati. In entrambi i casi: la residenza europea è una configurazione da scegliere e verificare, non il default automatico. Approfondiamo il tema nell'articolo sulla differenza tra residenza dei dati in UE e sovranità.
Criteri di scelta: dati, continuità, dipendenze
Quali dati e processi rendono preferibile l'installazione locale
Tre famiglie di situazioni spingono verso il CED:
- Dati che non devono uscire. Se il perimetro concordato esclude l'invio di certe informazioni a terzi — per policy interna, accordi con clienti o cautela del titolare — l'elaborazione in sede evita il passaggio verso il fornitore cloud. Restano comunque i doveri dell'organizzazione sulla protezione dei dati, che non si esauriscono con la collocazione del server.
- Processi che non si fermano. Se monitoraggio e proposte devono continuare anche quando la connettività della sede cade, l'autonomia locale conta. Va però dimostrata in prova, non assunta: cosa resta attivo senza Internet dipende dalle fonti e dalle dipendenze effettive del progetto, come vediamo nell'articolo sull'AI che funziona senza Internet in sede.
- Controllo diretto dell'hardware. Chi deve poter toccare, spegnere o segregare fisicamente il sistema trova nel CED un confine chiaro.
Quando le API europee sono accettabili
Le API su Azure o AWS in Europa sono una scelta ragionevole quando: i dati inviati sono selezionati e minimizzati; il tipo di deployment o il profilo di inferenza è quello corretto e verificato; la dipendenza dalla connettività è compatibile con il servizio; il contratto e le impostazioni del fornitore sono stati letti, non solo la pagina marketing. Microsoft dichiara che prompt e risposte non sono usati per addestrare i modelli foundation senza permesso esplicito né condivisi con altri clienti, e prevede un controllo anti-abuso su campioni che i clienti idonei possono chiedere di modificare; AWS registra nei log di CloudTrail la regione in cui ogni richiesta è stata elaborata. Sono impegni da leggere e da trasformare in evidenze di configurazione, come spieghiamo nell'articolo sulle verifiche da fare su regioni europee di Azure e AWS.
Dipendenze e continuità
Ogni architettura sposta la dipendenza, non la elimina. Il server locale dipende da alimentazione, hardware, manutenzione e aggiornamenti pianificati; le API dipendono dalla connettività e dalla disponibilità del servizio esterno. Anche il collegamento remoto dei responsabili è una dipendenza a sé: in OverZeus l'app Hermes si collega al server locale tramite una VPN (rete privata virtuale, un collegamento riservato) su connessione 5G cifrata proprietaria, quindi richiede connettività per funzionare — è un accesso remoto privato, distinto sia dall'operatività offline nel CED sia dalle API cloud.
| Aspetto | Server nel CED | API su Azure/AWS in Europa |
|---|---|---|
| Dove avviene l'elaborazione | Su hardware aziendale, in sede. | Nella geografia definita dal tipo di deployment o dal profilo di inferenza scelto, da verificare in configurazione. |
| Funzionamento senza Internet | Previsto per la modalità locale; autonomia reale da dimostrare in prova. | No: richiede connessione verso i servizi remoti. |
| Cosa esce dall'azienda | Da definire: aggiornamenti, assistenza, eventuali canali di supporto. | I dati selezionati per l'analisi; l'elenco va scritto e approvato. |
| Dipendenza principale | Hardware, alimentazione, manutenzione e procedure di aggiornamento concordate. | Connettività e disponibilità del servizio cloud. |
| Evidenza da conservare | Documentazione dell'installazione, delle fonti e delle comunicazioni esterne del sistema. | Tipo di deployment o profilo di inferenza, regione, log che mostrano dove è avvenuta l'elaborazione. |
Esempio illustrativo: la risorsa «in Europa» che non basta
Esempio illustrativo. Lo scenario seguente è inventato per spiegare il metodo; non descrive un cliente né un incidente reale.
Un'azienda manifatturiera vuole usare l'AI per riassumere i rapporti di manutenzione. Il responsabile informatico crea una risorsa su un cloud con regione europea e la presenta alla direzione come «dati in Europa». Durante la verifica congiunta emergono due dettagli: il deployment scelto è di tipo globale — più economico, ma con elaborazione possibile fuori dalla geografia voluta — e nei rapporti di manutenzione compaiono nomi di clienti che la policy interna classifica come riservati.
La decisione documentata: per i rapporti con dati riservati si usa l'installazione nel CED; per i test su documentazione tecnica generica si usa l'API, ma con il deployment corretto, la regione concordata per iscritto e un controllo periodico dei log che indicano dove è avvenuta l'elaborazione. Nessuna delle due opzioni è «giusta» in assoluto: ciascuna è giusta per un perimetro definito.
Come documentare la decisione presa
La terza domanda della scheda è quella che protegge il CIO: come decidere caso per caso con criteri scritti. Un documento di una pagina, per ogni caso d'uso, basta a rendere la scelta difendibile:
- Caso d'uso e dati coinvolti. Quale processo alimenta l'AI e con quali informazioni.
- Perimetro dei dati. Cosa può essere inviato a un servizio esterno e cosa no, secondo la policy interna.
- Architettura scelta e motivazione. CED o API europee, con le ragioni su dati, continuità e dipendenze.
- Verifiche fatte. Tipo di deployment o profilo, regione, impostazioni e log consultati, con data.
- Chi ha deciso e quando si riesamina. Un responsabile e una scadenza di revisione, perché servizi e configurazioni cambiano.
Il NIST AI Risk Management Framework, riferimento volontario del National Institute of Standards and Technology statunitense, propone un lessico per gestire e documentare le decisioni sui sistemi di intelligenza artificiale: può aiutare a strutturare il documento senza introdurre obblighi. Per la descrizione puntuale di dove stanno i dati, rimandiamo all'articolo su come documentare dove si trovano i dati aziendali.
Come OverZeus supporta entrambe le opzioni
OverZeus prevede entrambe le modalità descritte in questo articolo: installazione nel CED con possibilità di operare senza Internet, oppure uso di API su Azure o AWS in una regione europea concordata. Integrazioni, regione di elaborazione e dati condivisi vengono definiti insieme in base alla modalità scelta.
Sulla documentazione delle decisioni lavora Odysseus, l'agente di orchestrazione: collega gli indizi, coinvolge i moduli necessari e riunisce analisi e proposte in un piano comprensibile, così che chi decide veda opzioni e conseguenze prima di autorizzare. Mnemosyne conserva fonti, proposte, autorizzazioni ed esiti, e permette di ricostruire perché una certa architettura è stata scelta per un certo caso. Qualsiasi intervento attivo richiede l'approvazione prevista: il silenzio non autorizza.
In fase di valutazione, la prova in sola osservazione (Oracle, con macchina in comodato per 15–30 giorni senza modifiche alla produzione) è il contesto giusto per misurare sul proprio ambiente ciò che le schede tecniche non possono dire: quali fonti servono davvero, cosa resta attivo senza connessione, quali dati finirebbero verso le API.
Confronta con noi un'installazione nel CED e una configurazione API europea: esaminiamo dati, continuità e dipendenze del tuo caso e documentiamo insieme la scelta.
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.