La domanda giusta non è quale sia più sicuro. È quale perimetro siete in grado di governare e dimostrare.
La formulazione conta. “Più sicuro” suggerisce una gerarchia assoluta che non esiste: un’infrastruttura interna gestita senza competenze dedicate è meno sicura di un servizio gestito da un operatore specializzato, e un servizio eccellente collocato fuori dai vincoli normativi applicabili non è utilizzabile a prescindere dalla sua qualità tecnica.
La scelta è di governo, non di preferenza tecnologica.
Le tre configurazioni possibili
Cloud pubblico. Il modello è erogato come servizio da un fornitore, i dati transitano verso la sua infrastruttura. È la configurazione più rapida da attivare, con l’accesso più immediato ai modelli più recenti e con costi legati al consumo effettivo.
I punti da verificare sono la localizzazione del trattamento, le condizioni contrattuali sull’uso dei dati, i tempi di conservazione dei log lato fornitore e la disciplina applicabile in caso di richieste di accesso da parte di autorità estere.
Cloud dedicato o sovrano. Il servizio è erogato su infrastruttura riservata, con localizzazione dei dati garantita contrattualmente e isolamento dagli altri clienti. Il costo è superiore, la flessibilità inferiore, il perimetro molto più definibile.
È la configurazione che nella nostra esperienza risolve la maggior parte dei casi in ambito bancario, assicurativo e pubblico, quando il vincolo riguarda la residenza del dato più che il controllo fisico dell’hardware.
On-premise. I modelli vengono eseguiti su infrastruttura dell’organizzazione. Il dato non lascia il perimetro.
È la configurazione con il massimo controllo e il massimo onere. Richiede hardware specializzato, competenze di gestione, un piano di aggiornamento dei modelli e una capacità di dimensionamento che va prevista in anticipo. Con i modelli open weight disponibili oggi, la qualità raggiungibile è adeguata a molti casi d’uso documentali, pur restando in genere inferiore a quella dei modelli proprietari di frontiera sui compiti più complessi.
I criteri reali di scelta
Quattro criteri, nell’ordine in cui conviene applicarli.
La natura del dato. Non del progetto: del dato. Un sistema che lavora su manualistica tecnica pubblicabile ha vincoli diversi da uno che tratta dati sanitari o istruttorie di credito. La prima attività è classificare i dati che il sistema toccherà, incluse le informazioni che compaiono incidentalmente negli allegati.
I vincoli normativi e contrattuali. Requisiti settoriali, disposizioni sulla localizzazione, obblighi verso l’autorità di vigilanza, clausole già assunte verso i propri clienti. È un accertamento che va fatto insieme alla funzione legale prima della valutazione tecnica, perché in alcuni casi esclude direttamente una o due configurazioni.
Le competenze interne. Un’architettura on-premise richiede un presidio stabile. Se quel presidio non esiste e non è previsto assumerlo, la configurazione più controllata sulla carta diventa la meno sicura nei fatti: sistemi non aggiornati, log non monitorati, dipendenza da un singolo fornitore esterno.
Il costo del ciclo di vita. Non il costo iniziale. Hardware, energia, aggiornamenti dei modelli, personale, evoluzione dei carichi. Su un orizzonte di tre anni il confronto tra le configurazioni cambia spesso di segno rispetto alla valutazione del primo anno, in entrambe le direzioni a seconda dei volumi.
Le architetture ibride
Nella maggior parte dei progetti reali la scelta non è binaria, e questo è il punto più utile della discussione.
Un’architettura ibrida separa i componenti in base alla sensibilità dei dati che trattano. I documenti riservati restano nel perimetro interno, insieme all’indicizzazione e alla ricerca. Il modello che genera la risposta finale può essere interno o esterno a seconda del caso d’uso.
Una variante frequente prevede la classificazione automatica della richiesta: le domande che coinvolgono dati sensibili vengono instradate al modello interno, le altre al servizio esterno. Richiede una logica di instradamento affidabile e verificabile, e va progettata con attenzione, perché un errore di classificazione ha conseguenze immediate.
Un’altra soluzione consiste nel mantenere all’interno i dati identificativi e inviare all’esterno solo contenuti pseudonimizzati. Funziona su alcuni casi d’uso e non su altri: la pseudonimizzazione va verificata, non assunta, perché il contesto residuo può essere sufficiente a reidentificare.
Il criterio generale è che il deployment segue i vincoli dell’organizzazione, non il contrario. Quando la residenza dei dati non è negoziabile, l’architettura resta interna o ibrida, e le scelte a valle si adattano.
Le domande da porre al fornitore
Sei domande, da porre prima di decidere e da mettere per iscritto.
Dove risiedono fisicamente i dati durante l’elaborazione e dopo, e per quanto tempo vengono conservati.
I dati vengono utilizzati per addestrare o migliorare modelli, propri o di terzi, e con quale base contrattuale.
Che cosa viene registrato nei log del fornitore, chi può accedervi e con quale procedura.
Come si ottiene la cancellazione effettiva di un dato, in quali tempi e con quale evidenza.
Che cosa accade se il servizio viene interrotto o il modello dismesso: quale preavviso è garantito e quale percorso di migrazione.
Quale disciplina si applica in caso di richieste di accesso da parte di autorità di paesi terzi.
Se una risposta è generica, la domanda va riformulata per iscritto. In fase contrattuale la differenza tra “i dati non vengono usati per l’addestramento” e “i dati non vengono usati per l’addestramento salvo diversa configurazione del servizio” è sostanziale.
Che cosa la scelta dell’infrastruttura non risolve
Nessuna configurazione protegge da una gestione dei permessi mal progettata. Un sistema interno che mostra a un utente documenti che non sarebbe autorizzato a leggere costituisce un incidente, indipendentemente da dove sia collocato il server.
Nessuna configurazione protegge dalle vulnerabilità applicative. La difesa da prompt injection, il trattamento dei contenuti recuperati come input non fidato, il controllo delle azioni eseguibili: sono temi di architettura applicativa, non di infrastruttura.
E nessuna configurazione sostituisce l’audit trail. Sapere che il dato è rimasto interno non dice chi ha consultato che cosa.
In chiusura
La decisione andrebbe presa dopo aver classificato i dati e verificato i vincoli applicabili, non prima. Nella nostra esperienza, quando questo ordine viene rispettato, la configurazione adeguata emerge con poca ambiguità.
Se state valutando un progetto con dati sensibili, siamo disponibili a un confronto su requisiti di sicurezza e perimetro: quali dati sono coinvolti, quali vincoli si applicano e quale architettura sarebbe difendibile in sede di verifica.
