Azure e AWS con regioni europee: cosa verificare prima di firmare

Prima di firmare un contratto per API di intelligenza artificiale su Azure o AWS «con regioni europee», verifica tre cose: dove avviene davvero l'elaborazione (non solo dove sono conservati i dati), chi può accedere a prompt e risposte, e quali evidenze potrai conservare per dimostrare le scelte fatte. La dicitura «Europa» sul preventivo non basta: su entrambe le piattaforme il luogo di elaborazione dipende dalla configurazione scelta, non soltanto dalla regione della risorsa. Questa checklist indica cosa mettere per iscritto, cosa chiedere su sottoprocessori e trasferimenti e cosa archiviare. Non è un parere legale: per la valutazione del contratto coinvolgi il tuo consulente.

Perché «regione europea» non basta

Creare una risorsa in una regione europea non significa automaticamente che ogni elaborazione avvenga lì. La documentazione Microsoft su dati, privacy e sicurezza dei modelli in Azure spiega che è il tipo di deployment a determinare dove vengono elaborati prompt e risposte:

• Deployment regionali (standard): l'elaborazione avviene nella geografia indicata dal cliente, con possibili spostamenti tra regioni della stessa geografia per motivi operativi.
• Deployment «DataZone»: l'elaborazione può avvenire in qualsiasi geografia della zona dati; una risorsa nell'Unione europea può quindi essere elaborata in un altro Stato membro, non necessariamente nel paese della regione scelta.
• Deployment «Global»: l'elaborazione può avvenire in qualsiasi geografia in cui il modello è distribuito, nel mondo. Anche l'elaborazione in batch rientra in questa categoria.

Per i deployment Global e DataZone i dati a riposo restano nella geografia designata: a cambiare è il luogo dell'elaborazione. È una distinzione decisiva, perché le promesse commerciali parlano spesso solo del primo punto.

Su AWS vale una logica simile. La guida sull'inferenza cross-region di Amazon Bedrock descrive due famiglie di profili di inferenza:

• Profilo geografico (per esempio «EU»): la richiesta viene instradata verso una regione AWS dentro quella geografia, ma non necessariamente in una singola regione specifica.
• Profilo globale: la richiesta può essere elaborata in qualsiasi regione commerciale supportata nel mondo; la stessa pagina segnala un costo indicativamente inferiore e raccomanda il profilo geografico a chi ha requisiti di residenza dei dati.

In entrambi i casi, «Europa» è una configurazione da scegliere e verificare, non il comportamento predefinito di qualsiasi chiamata. Se il tema della collocazione ti interessa oltre il piano tecnico, la differenza tra residenza, sovranità e conformità è approfondita nell'articolo sulla residenza dei dati in UE e la sovranità.

Collocazione e regioni: cosa mettere per iscritto

Alla prima domanda — quali impegni contrattuali riguardano collocazione e accessi — risponde bene solo ciò che finisce nero su bianco. Prima di firmare, fai indicare nell'ordine o nel contratto:

• Geografia dei dati a riposo e geografia di elaborazione, come due voci separate. Chiedi esplicitamente quale tipo di deployment (Azure) o quale profilo di inferenza (AWS) userai, e che la scelta sia registrata.
• Le funzioni che creano archivi persistenti. Su Azure, funzioni con memoria di stato (per esempio conversazioni salvate, file caricati, personalizzazioni dei modelli) creano archivi dati nel tuo tenant, nella stessa geografia della risorsa; la documentazione indica cifratura AES-256, opzione con chiave gestita dal cliente e possibilità di eliminazione. Verifica quali di queste funzioni userai davvero: ognuna aggiunge un luogo in cui i dati restano.
• Le condizioni del monitoraggio anti-abuso. Microsoft dichiara che campioni di prompt e risposte possono essere esaminati da sistemi automatici e, se segnalati, da revisori umani (per deployment nello Spazio economico europeo, revisori situati nel SEE). I clienti idonei possono chiedere la modifica di questo monitoraggio e verificarla con un attributo dedicato (ContentLogging=false) nel portale. Chiedi se la tua organizzazione è idonea e fai registrare l'esito.
• Chi può accedere ai dati e da dove. Personale del fornitore, revisori, team di supporto: chiedi per quali motivi possono accedere, con quali autorizzazioni e da quali paesi operano.
• Cosa succede se la configurazione cambia. Nuovi tipi di deployment, nuove regioni, nuove funzioni: chiedi come verrai informato e chi nella tua azienda deve approvare il cambio.

Non basarti sul riassunto di un articolo — questo incluso — per le clausole: leggi i documenti contrattuali aggiornati (condizioni di trattamento dei dati, condizioni del servizio) nella versione vigente alla data della firma.

Sottoprocessori, accessi e trasferimenti

Il servizio che acquisti può appoggiarsi a soggetti ulteriori rispetto al fornitore principale. Alla seconda domanda — cosa chiedere su sottoprocessori e trasferimenti — rispondi con quattro richieste precise:

• L'elenco aggiornato dei sottoprocessori rilevanti per i servizi che userai, con il ruolo di ciascuno e le sedi di trattamento. Chiedi anche come e con quale preavviso sarai avvisato delle modifiche all'elenco.
• Il documento sul trattamento dei dati (in inglese Data Processing Agreement, l'accordo che regola come il fornitore tratta i dati per tuo conto) nella versione corrente, non in una copia scaricata anni prima.
• Come sono gestiti i trasferimenti verso paesi terzi, se previsti: chiedi al tuo consulente legale o al responsabile della protezione dei dati di valutare la documentazione fornita, senza accontentarti della frase «i dati restano in Europa».
• Le vie di accesso operative: supporto tecnico, interventi di manutenzione, strumenti di diagnostica. Ogni canale di accesso va elencato insieme alle sue condizioni.

Tieni presente che residenza dei dati, accessi e giurisdizione sono piani diversi dello stesso problema: la collocazione europea risponde al primo, non assolve gli altri due.

La checklist in sintesi

Usa la tabella in trattativa con qualsiasi fornitore e con qualsiasi integratore, compreso chi propone soluzioni già configurate: la responsabilità di verificare la configurazione resta di chi acquista.

Esempio illustrativo: il profilo che costa meno

Esempio illustrativo. Lo scenario seguente è inventato e serve a mostrare il metodo di verifica; non descrive un caso reale.

Un'azienda di logistica decide di usare un modello linguistico via API su Amazon Bedrock per riassumere i rapporti di viaggio. Per attivare il modello deve scegliere un profilo di inferenza: il profilo geografico «EU» instrada le richieste verso regioni AWS dentro la geografia europea; il profilo globale può farle elaborare in qualsiasi regione supportata nel mondo, e la pagina di AWS lo presenta come indicativamente meno costoso. Il tecnico, sotto pressione sul budget, configura il profilo globale: le chiamate funzionano allo stesso modo e nessuno registra da nessuna parte quale profilo è stato scelto. Sei mesi dopo, un cliente importante chiede in audit dove vengono elaborati i testi inviati al modello. L'azienda scopre che l'evidenza esiste — i registri CloudTrail annotano ogni chiamata con un campo dedicato (inferenceRegion) che indica la regione in cui la richiesta è stata effettivamente elaborata — ma nessuno aveva previsto di conservarli e consultarli, e la scelta del profilo non risulta in nessun documento.

La verifica corretta, prima della firma, avrebbe richiesto tre passaggi: scegliere il profilo di inferenza coerente con i vincoli dichiarati ai clienti, registrare la scelta nei documenti dell'ordine e prevedere la conservazione e il controllo periodico dei log CloudTrail con il campo che mostra la regione di elaborazione. Il costo inferiore del profilo globale non era un errore in sé: lo era firmare senza aver collegato quella scelta ai propri obblighi, e senza conservare l'evidenza che avrebbe permesso di dimostrarla.

Evidenze da raccogliere e conservare

Alla terza domanda — quali evidenze conservare per clienti e controllori — rispondi organizzando tre momenti:

• Prima della firma: le versioni dei documenti contrattuali consultati, con la data; le risposte scritte del fornitore; la motivazione della scelta fatta, incluse le alternative scartate.
• All'attivazione: esportazioni o schermate della configurazione (tipo di deployment, profilo di inferenza, funzioni con memoria di stato, impostazioni del monitoraggio anti-abuso), con data e nome di chi le ha rilevate.
• Nell'esercizio: i log che mostrano dove le richieste sono state elaborate — su Bedrock il campo dedicato nei registri CloudTrail — i cambi di configurazione approvati e le verifiche periodiche concordate.

Questa raccolta serve anche a te, non solo ai controllori: è la stessa disciplina descritta nell'articolo su come documentare dove stanno i dati e in quello sulle verifiche da fare quando si promette che i dati non escono mai.

Se lavori con OverZeus, una parte di questa disciplina trova supporto nel progetto: Mnemosyne, l'agente dedicato ad audit ed evidenze, conserva fonti, timeline, proposte, autorizzazioni ed esiti degli interventi, aiutando a ricostruire il percorso di ogni decisione nel perimetro concordato. Resta alla tua organizzazione l'archivio contrattuale e la raccolta delle configurazioni del fornitore cloud: le evidenze prodotte dagli agenti riguardano ciò che gli agenti osservano e propongono, non sostituiscono la documentazione dell'acquisto.

Per la modalità via API, OverZeus dichiara di collegarsi a servizi su Azure o AWS in una regione europea concordata: «Definiamo insieme i servizi da utilizzare, la regione europea e i dati da inviare per l'analisi». Le verifiche di questa checklist si applicano anche lì, con la stessa cura. In alternativa, il progetto prevede l'installazione nel CED della tua azienda, che riduce i passaggi verso terzi; le differenze tra le due strade sono trattate nell'articolo su AI locale nel CED o API cloud.

Firmare con le verifiche fatte

Le regioni europee di Azure e AWS sono uno strumento utile, non una garanzia automatica. Il luogo di elaborazione dipende da deployment e profili scelti in configurazione; sottoprocessori e accessi vanno elencati e messi per iscritto; le evidenze vanno raccolte prima, durante e dopo la firma. Chi acquista conserva la responsabilità della verifica: fallo con metodo, e fallo per iscritto.

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

Tutti gli articoli OverZeus