Google Apps Script e Data Regions: guida per aziende

Google Apps Script entra nei controlli Data Regions di Google Workspace. Dal 16 settembre 2026 le organizzazioni idonee possono applicare alle automazioni la regione già assegnata a unità organizzative e gruppi, sia per i dati archiviati sia per l’esecuzione. È un passo importante per imprese regolamentate e pubbliche amministrazioni, ma non equivale a una garanzia automatica che ogni integrazione resti nella stessa area geografica.

Che cosa cambia con le Data Regions per Apps Script

Una policy Data Regions applicata in Google Workspace ora governa anche parti rilevanti di Google Apps Script. Secondo l’annuncio ufficiale, i progetti e le esecuzioni seguono la regione assegnata dall’amministratore senza che l’utente debba attivare una preferenza separata.

Dati archiviati nella regione scelta

Rientrano nella regionalizzazione i file di progetto, il codice, i manifest, i metadati dei trigger e gli archivi chiave-valore usati da servizi come Properties Service e Cache Service. Per chi usa Apps Script per approvazioni, report o sincronizzazioni, significa che anche componenti spesso trascurati nell’inventario applicativo entrano nel perimetro della policy.

Esecuzioni e automazioni container-bound

Google dichiara che esecuzioni, automazioni legate a documenti e operazioni di runtime associate vengono elaborate nella regione selezionata. La novità riguarda quindi non soltanto il luogo in cui risiede il codice, ma anche il trattamento necessario per farlo funzionare.

Quali edizioni sono supportate

La disponibilità non è uguale per tutti i piani. Enterprise Plus e Frontline Plus includono archiviazione ed elaborazione nella regione; Education Standard ed Education Plus includono invece l’archiviazione regionale. Prima di aggiornare policy o documentazione di conformità conviene verificare l’edizione effettiva del tenant e gli eventuali componenti aggiuntivi.

Edizione	Archiviazione regionale	Elaborazione regionale
Enterprise Plus	Sì	Sì
Frontline Plus	Sì	Sì
Education Standard / Plus	Sì	Non indicata nell’annuncio

Il rollout è indicato come disponibile da subito sia per i domini Rapid Release sia per quelli Scheduled Release. La configurazione si trova nella Console di amministrazione, nel percorso Dati > Conformità > Regioni dati.

Il punto critico: servizi non regionalizzati

La regionalizzazione di Apps Script non comprende automaticamente qualunque servizio richiamato dal codice. Google avverte che, per le organizzazioni che disattivano le funzioni capaci di elaborare dati in più regioni nelle impostazioni avanzate di Drive e Documenti, i servizi Apps Script non regionalizzati vengono disabilitati a partire da settembre 2026.

La documentazione elenca, tra gli esempi, classi come FormApp, GroupsApp, Jdbc e Maps, oltre a servizi avanzati quali BigQuery, Chat, Classroom, YouTube e varie API amministrative. Se uno script usa un componente non regionalizzato, l’esecuzione può fallire con un errore che segnala il servizio non disponibile. Non è quindi sufficiente accendere il controllo: serve un collaudo delle automazioni reali.

Attenzione ai servizi esterni

Webhook, API di terze parti, database esterni e progetti Google Cloud collegati possono avere una propria collocazione geografica e condizioni contrattuali differenti. La policy Workspace non estende automaticamente il proprio perimetro a questi sistemi. Lo stesso vale per logging personalizzato, trasferimenti tramite HTTP e dati inviati a piattaforme esterne.

Perché interessa anche le PMI

Apps Script viene spesso adottato in modo incrementale: una macro in Sheets diventa un flusso di approvazione, poi un’integrazione con il gestionale. La nuova copertura aiuta a rendere più coerente la governance, ma porta alla luce script senza proprietario, trigger dimenticati e credenziali eccessive.

Per le aziende che stanno già introducendo automazioni con Google Workspace Studio, questa è anche l’occasione per separare i flussi no-code dalle personalizzazioni Apps Script e attribuire a ciascuno un responsabile. Le nuove regole DLP e di condivisione di Google Drive proteggono un altro livello: non sostituiscono il controllo sulla regione di esecuzione né l’analisi del codice.

Checklist prima di applicare policy più restrittive

Inventariare progetti e trigger: includere script autonomi, container-bound, componenti aggiuntivi e account tecnici.
Mappare dati e destinazioni: identificare fogli, documenti, caselle, API, database e webhook coinvolti.
Controllare l’edizione: verificare se il piano offre archiviazione soltanto o anche elaborazione nella regione.
Individuare servizi non regionalizzati: confrontare classi e servizi avanzati usati dal codice con l’elenco ufficiale aggiornato.
Creare un gruppo pilota: applicare la policy a una OU o a un gruppo ristretto e registrare gli errori di esecuzione.
Testare i trigger: provare trigger temporali, on-edit, on-form-submit e automazioni legate ai documenti.
Verificare logging e Cloud Project: controllare regione, retention e accessi dei progetti Google Cloud collegati.
Aggiornare runbook e DPIA: documentare ambito, eccezioni, servizi esterni e procedura di rollback.

Come impostare un progetto pilota

Il test dovrebbe partire da processi non critici ma rappresentativi: un report pianificato, un’approvazione su Sheets e uno script che chiama un servizio esterno. Per ciascuno vanno misurati esito, tempo di esecuzione, log disponibili e comportamento in caso di errore.

Conviene poi creare due elenchi: automazioni compatibili con il perimetro regionale e automazioni che richiedono una modifica architetturale. Nel secondo gruppo possono rientrare script da riscrivere, integrazioni da spostare su servizi regionali o flussi da mantenere esclusi con una motivazione approvata.

L’approccio è simile a quello utile per i connettori di Gemini verso applicazioni esterne: sapere che una funzione è disponibile non basta; servono inventario, autorizzazioni minime, responsabilità e verifica dei confini dei dati.

Domande frequenti

Le Data Regions per Apps Script sono disponibili per tutti?

No. L’annuncio indica Enterprise Plus e Frontline Plus per archiviazione ed elaborazione regionali; Education Standard ed Education Plus per l’archiviazione regionale. Occorre verificare piano e componenti aggiuntivi del tenant.

Gli utenti devono modificare qualche impostazione?

No. Progetti ed esecuzioni seguono automaticamente la policy assegnata dall’amministratore all’unità organizzativa o al gruppo.

Tutte le chiamate di uno script restano nella regione?

No. Servizi non regionalizzati e sistemi esterni possono elaborare dati altrove o diventare indisponibili quando vengono applicate impostazioni avanzate restrittive.

Uno script incompatibile continua a funzionare?

Non necessariamente. La documentazione Google avverte che l’uso di classi o servizi avanzati non regionalizzati può causare errori di esecuzione quando tali funzioni vengono disattivate.

La regionalizzazione sostituisce DLP e controllo accessi?

No. Data Regions governa la collocazione geografica dei dati coperti e della loro elaborazione; DLP, condivisione, identità, autorizzazioni OAuth e logging restano controlli separati.

Conclusione

La disponibilità generale delle Data Regions per Apps Script riduce una lacuna importante nella governance di Google Workspace. Il valore concreto dipende però dalla qualità dell’inventario e dai test: una policy più rigorosa può rafforzare la conformità, ma anche interrompere automazioni che usano servizi non regionalizzati.

EP Consulting può aiutare a censire gli script, verificare dipendenze e autorizzazioni e progettare un pilota prima dell’estensione della policy all’intera organizzazione.

Google Apps Script entra nelle Data Regions: cosa verificare