La maggior parte degli strumenti interni eredita la propria giurisdizione per caso. Un team ricorre al SaaS più rapido da reperire, i dati finiscono ovunque quel fornitore operi, e un anno dopo qualcuno nell'ufficio legale chiede dove risiedano realmente i dati dei clienti — ottenendo una risposta scomoda. Per un'azienda in fase di crescita che opera sotto il GDPR, e sempre più sotto il NIS2 e l'EU AI Act, quel caso fortuito è una responsabilità che attende solo un audit.

NordOps procede nel modo opposto. Quando costruisco software operativo su misura, la residenza dei dati nell'UE è fissata prima ancora di progettare una singola tabella. Sia il runtime che il codice sorgente risiedono in Germania, sotto giurisdizione UE, senza alcuna esposizione legale statunitense per costruzione. Non si applica la conformità a posteriori su un sistema progettato altrove — si parte da lì.

La residenza dei dati come requisito di progettazione, non come intervento successivo

C'è una differenza reale tra un software che si trova a funzionare in Europa e un software che è stato progettato per farlo. Il primo tipo può essere spostato, ripuntato o silenziosamente riospitato la prossima volta che un fornitore cambia la propria infrastruttura. Il secondo tipo tratta la posizione dei dati come parte della specifica — qualcosa che l'architettura garantisce, non qualcosa che una pagina di impostazioni promette.

Per strumenti interni su misura conformi al GDPR nell'UE, quella distinzione si manifesta nei dettagli noiosi ma fondamentali:

  • Dove risiedono i dati. Ogni archivio — database, storage dei file, backup, log — viene predisposto all'interno dell'UE fin dall'inizio, non migrato in seguito.
  • Dove avviene l'elaborazione. Job in background, passaggi assistiti dall'AI e integrazioni vengono eseguiti all'interno della regione, in modo che i dati non escano silenziosamente dal blocco UE per essere elaborati altrove.
  • Chi ha giurisdizione. Ospitare in Germania significa che è il diritto UE a governare l'infrastruttura, senza che la giurisdizione statunitense possa estendersi al runtime o al codice sorgente.

Poiché queste sono decisioni prese in fase di progettazione, reggono quando qualcuno finalmente pone la domanda difficile. La residenza dei dati per il software operativo su misura in Europa smette di essere un'affermazione di speranza e diventa una proprietà del sistema a cui si può fare riferimento concretamente.

Codice sorgente e runtime in Germania, nessuna giurisdizione statunitense

Entrambe le metà della build risiedono nell'UE. Il runtime — i server che il team utilizza realmente ogni giorno — funziona in Germania. Il codice sorgente — il repository, la pipeline di build, il registro esatto di ciò che fa il software — è ospitato anch'esso nell'UE. Nessuno dei due è esposto alla giurisdizione statunitense, e nessuno dei due dipende da una piattaforma di proprietà statunitense che si trova silenziosamente nel percorso.

Questo conta perché la residenza vale quanto il suo anello più debole. Non basta che il database si trovi a Francoforte se la pipeline di deployment, i log degli errori o un servizio di terze parti integrato si estendono al di là dell'Atlantico. Il software aziendale su misura ospitato nell'UE deve esserlo fino in fondo — e una build mantenuta abbastanza contenuta da poter essere posseduta è una build abbastanza contenuta da poter verificare che lo sia davvero.

Un penetration test e un report sono inclusi in ogni modulo di sviluppo — così la postura di sicurezza del sistema ospitato nell'UE è documentata, non presunta.

Come si presenta la consegna — la destinazione la sceglie l'azienda

Possedere il software significa possedere anche il luogo in cui risiede. Ogni incarico trasferisce la piena proprietà del codice sorgente, e con essa la libertà di decidere la destinazione. Non c'è alcun vincolo, nessun abbonamento e nessuna dipendenza dal fatto che NordOps continui a ospitare alcunché.

Al momento della consegna è possibile:

  • Mantenerlo dove funziona — lasciare il runtime in Germania e proseguire, con il codice sorgente ora interamente nelle proprie mani.
  • Spostarlo nel proprio tenant UE — distribuire il codice sorgente trasferito sulla propria infrastruttura, sempre all'interno dell'UE, sotto i propri account.
  • Portarlo ovunque si abbia diritto — il codice è di proprietà; la scelta della residenza diventa una decisione da prendere e rivedere man mano che gli obblighi evolvono.

La base di ogni build — il Portale Admin e il Processore, raggruppati come un unico modulo di sviluppo — viene consegnata con le stesse condizioni di proprietà di tutto ciò che viene definito sopra di essa. Non si affitta mai la cosa da cui dipende l'operatività aziendale.

La padronanza normativa è competenza di deployment — non consulenza di conformità

Una precisazione, detta chiaramente: NordOps non è un servizio di consulenza sulla conformità, e questo non è un parere legale. Non svolgo audit del programma GDPR, non scrivo le policy NIS2, né approvo la postura relativa all'EU AI Act. Questo lavoro spetta ai consulenti legali e al responsabile della protezione dei dati dell'azienda.

Ciò che offro è competenza di deployment — la padronanza necessaria per costruire software che si colloca comodamente all'interno di quei regimi normativi, perché la residenza, i flussi di dati e la giurisdizione sono state decisioni di ingegneria fin dall'inizio. La differenza è quella tra consigliare sulle regole e costruire software che le rispetta già. Il mio compito è assicurarmi che lo strumento posseduto sia uno che la funzione di conformità può difendere, non uno che deve giustificare.

Quando il software aziendale su misura ospitato nell'UE è progettato in questo modo — residenza prima di tutto, codice sorgente e runtime in Germania, proprietà trasferita interamente — la residenza dei dati smette di essere una preoccupazione ricorrente e diventa un dato di fatto consolidato su come opera l'azienda.