DLP in TuaGate: proteggere i dati sensibili prima che raggiungano l'AI

Quando un dipendente incolla un codice fiscale, un IBAN o una chiave API in una chat, il dato non resta più solo sul suo PC: attraversa il gateway e può finire su un backend cloud. Il layer DLP (Data Loss Prevention) di TuaGate intercetta questi contenuti prima che la richiesta venga inoltrata al modello in modo trasparente per l'utente, configurabile per l'amministratore e tracciabile per la compliance.

Perché serve un DLP dedicato all'AI

I client AI come TuaGPT rendono facile chiedere aiuto su documenti, email, pratiche legali o cartelle cliniche. Il rischio non è l'intenzione malevola, ma l'abitudine: copiare-incollare un testo completo senza pensare a cosa contiene.

Un DLP classico su email o file system non copre il canale conversazionale. TuaGate colma questo vuoto perché si interpone tra il client e i provider di inferenza (locali o cloud), lavorando sul payload OpenAI-compatibile: messaggi, prompt, input strutturati e persino gli argomenti dei tool call.

Il risultato è un controllo centralizzato: l'IT definisce le regole una volta, e ogni richiesta da qualsiasi utente autorizzato, passa dallo stesso filtro.

Dove interviene il DLP nella pipeline

Il DLP è il primo layer della GatewayPipeline, subito dopo autenticazione JWT, risoluzione del router virtuale (tuagate-auto) e controllo ACL sui modelli. Interviene prima del budget token e della compressione contesto (TuaCompress).

Client TuaGPT (OpenAI API)
  → Autenticazione JWT
  → PrepareChatForwardAsync
      1. Router virtuale (tuagate-auto)
      2. ACL modelli
      3. ★ DLP ingresso
      4. Budget token
  → ProxyService → Provider (locale / cloud)

Questa posizione è strategica: i dati sensibili vengono trattati prima che raggiungano OpenAI, OpenRouter, Hugging Face o qualsiasi altro endpoint configurato.

Cosa rileva: 22 pattern built-in + pattern custom

TuaGate scansiona il testo estratto dalla richiesta con espressioni regolari e validatori post-match per ridurre i falsi positivi. I pattern built-in coprono scenari tipici italiani e internazionali.

Attivi di default

• email — indirizzi email
• phone_it — numeri di telefono italiani (fisso e mobile)
• codice_fiscale — con validazione del check digit ufficiale
• iban — con validazione mod 97 ISO 13616
• credit_card — con validazione Luhn

Disponibili, da attivare manualmente

Identità e finanza: partita IVA, SWIFT/BIC, targa veicolo, indirizzo IPv4.

Segreti tecnici: chiavi API (OpenAI, OpenRouter, Hugging Face, AWS, Slack, GitHub), token JWT, chiavi private PEM.

Sanità italiana: NRE/ricetta elettronica, tessera sanitaria/TEAM, codice nosologico, CUP, codice struttura/HSP/STS11.

PA e ambito legale: numero R.G., procedimento, atto/repertorio, protocollo PA, sentenza/decreto/ordinanza.

Oltre ai built-in, l'amministratore può definire fino a 50 pattern custom con regex proprie — ad esempio codici interni, matricole, ID pratica aziendale. Ogni pattern custom ha un identificativo (a-z0-9_), un'etichetta e una regex compilabile (timeout 100 ms, max 512 caratteri).

Le cinque modalità di enforcement

Per ogni richiesta che contiene dati sensibili, TuaGate applica una delle seguenti azioni. La modalità può essere impostata globalmente e sovrascritta per utente o per backend.

Redact vs Tokenize: quale scegliere?

Con Redact, il dato originale è perso in modo irreversibile nella richiesta inoltrata. Il modello risponde su placeholder, non sul valore reale. È la scelta più sicura quando non serve che l'AI manipoli o citi il dato sensibile.

Con Tokenize, il flusso è bidirezionale:

1. In ingresso: "Il CF è RSSMRA80A01H501U" → il backend riceve "Il CF è [[TG:codice_fiscale:AB12CD34]]"
2. Il modello elabora il testo con i token al posto dei valori reali
3. In uscita: TuaGate ripristina i valori originali nella risposta al client

Il mapping token→valore vive solo in memoria per la singola richiesta HTTP (DlpTokenSession) e non viene mai scritto in audit o log di sicurezza. Funziona sia su risposte complete che su streaming SSE, con un buffer dedicato per ricomporre token spezzati tra un chunk e l'altro.

Fail-closed e bypass admin

Se la redazione o la tokenizzazione lascia residui di PII, oppure se la mutazione del payload fallisce, TuaGate applica automaticamente un Block (comportamento fail-closed).

Gli utenti con ruolo Admin bypassano il blocco in modalità Block, ma i PII vengono comunque redatti prima del forward, il dato sensibile non raggiunge il backend cloud nemmeno in caso di override amministrativo.

Configurazione globale

Il DLP è una funzionalità Enterprise / Custom (feature flag governance.dlp). Senza licenza adeguata, l'interfaccia è disabilitata e le API amministrative rispondono 403.

Per configurarlo, aprire il pannello TuaGate e andare in:

Impostazioni → tab Governance → "DLP dati sensibili"

Opzioni disponibili

Abilita DLP globale

Attiva o disattiva il layer per l'intero gateway. Disattivato di default nelle nuove installazioni.

Solo backend cloud

Se attivo, il DLP interviene solo verso endpoint classificati come cloud (OpenAI, OpenRouter, ecc.). I backend locali (Ollama, LM Studio) restano esenti, utile per separare latenza locale da compliance cloud.

Enforcement predefinito

La modalità applicata quando non c'è un override per utente o backend. Default: Redact.

Template redazione

Il placeholder usato in modalità Redact. Deve contenere %type% (sostituito con l'ID del pattern, es. email). Max 64 caratteri. Esempio: REDACTED-%type% oppure [DATO_RIMOSSO:%type%].

Pattern attivi

Checklist con tutti i pattern built-in e custom. Il contatore mostra quanti sono selezionati sul totale.

Pattern custom

Editor per creare, modificare ed eliminare regex personalizzate. Ogni pattern ha ID, etichetta, espressione regolare e flag "abilitato di default".

Prova al volo

Area di test integrata: incolla un testo di esempio e verifica quali pattern lo intercettano. Puoi anche testare una regex in bozza prima di salvarla.

Policy per utente

Non tutti i reparti hanno lo stesso profilo di rischio. TuaGate permette override granulari dalla Gestione utenti:

Tasto destro sull'utente → "Policy DLP…"

• DLP attivo per utente: abilita o disabilita il layer per quell'utente
• Enforcement: con opzione "Eredita impostazione globale" oppure override su Allow / Warn / Redact / Tokenize / Block
• Applica a router virtuale: controlla se la policy vale per richieste via tuagate-auto
• Applica a modelli diretti: controlla se la policy vale quando l'utente seleziona un modello specifico

Questa distinzione è utile, ad esempio, per applicare Block solo ai modelli cloud mentre si lascia più libertà sul router virtuale che instrada verso backend locali.

Override per backend

Ogni endpoint configurato in TuaGate può avere una policy DLP dedicata, accessibile dal form di modifica backend:

• Eredita: segue la policy globale e quella utente
• DLP attivo: forza l'applicazione del DLP su quell'endpoint, ignorando la policy utente. Se l'enforcement globale è Allow, viene usato Redact
• DLP disattivo: salta completamente il layer per quell'endpoint

In combinazione con il flag IsCloudBackend e l'opzione "Solo backend cloud", si costruisce facilmente uno scenario ibrido: Ollama in sede senza DLP, OpenRouter con Redact o Tokenize.

Come si risolve la policy: ordine di priorità

Quando arriva una richiesta, TuaGate valuta le regole in sequenza:

1. Licenza governance.dlp attiva e DLP globale abilitato
2. Se "Solo backend cloud" è attivo e il backend è locale → DLP disattivo
3. Override backend: se DlpEnabled = false → skip; se true → forza enforcement
4. Policy utente: IsEnabled, ambito router virtuale / modelli diretti
5. Enforcement: override utente → globale; backend forzato → non può restare Allow

Questo modello a cascata permette una policy di base restrittiva con eccezioni mirate, senza duplicare configurazioni.

Configurazione via API REST

Per automazione, integrazione con script o control plane multi-nodo, TuaGate espone endpoint amministrativi (richiedono licenza e autenticazione admin):

Audit e monitoraggio

Il DLP non scrive mai il contenuto sensibile nei log. Registra solo conteggi, tipi di pattern e azioni applicate.

Security Event Log

• DlpWarning- modalità Warn, hit rilevati
• DlpRedacted- redazione applicata
• DlpTokenized- tokenizzazione applicata
• DlpBlocked- richiesta bloccata
• DlpAdminBypass- admin ha bypassato il block (con redazione)
• DlpConfigChanged- modifica configurazione globale
• DlpUserPolicyChanged- modifica policy utente

Request Audit Log

Ogni richiesta include DlpAction, DlpHitCount e un outcome tra dlp-allow, dlp-warn, dlp-redact, dlp-tokenize, dlp-blocked.

Header di risposta

I client compatibili (incluso TuaGPT) possono leggere:

• X-TuaGate-Dlp-Action - azione applicata (Warn, Redact, Tokenize, Block, Allow)
• X-TuaGate-Dlp-Hits - numero di occorrenze rilevate

Tre scenari di configurazione

Scenario 1 · Rollout graduale in azienda

Fase 1: Osservazione: abilita DLP globale con enforcement Warn. Attiva solo i 5 pattern di default. Monitora il Security Event Log per una settimana per capire la frequenza reale dei dati sensibili nei prompt.

Fase 2: Protezione: passa a Redact come enforcement globale. Attiva pattern aggiuntivi (partita IVA, chiavi API) se emergono dai log.

Fase 3: Granularità: imposta Block per utenti del reparto Legale/HR tramite policy per utente. Lascia Redact per il resto.

Scenario 2 · Struttura sanitaria

Abilita i pattern sanità: NRE, tessera sanitaria, nosologico, CUP, codice struttura. Imposta enforcement Tokenize per permettere al personale di ricevere risposte con i dati reali, mentre il backend cloud vede solo token anonimi. Attiva Solo backend cloud per non rallentare eventuali modelli locali in reparto.

Scenario 3 · Studio legale con backend misti

Configura Ollama/LM Studio come backend locale con DLP disattivo (dati restano in sede). Configura OpenRouter come backend cloud con DLP forzato e enforcement Block sui pattern R.G., procedimento, protocollo PA e sentenza. Aggiungi pattern custom per i codici pratica interni dello studio.

Personalizzazione avanzata: pattern custom

I pattern built-in coprono i casi più comuni, ma ogni organizzazione ha identificativi propri. Con l'editor integrato puoi definire regex come:

• Matricole dipendenti: \bEMP-\d{6}\b
• Codici commessa: \bCOMM-[A-Z]{2}\d{4}\b
• Numeri ticket interni: \bTKT-\d{8}\b

Regole di validazione: ID univoco (min 2, max 48 caratteri, solo a-z0-9_), non riutilizzabile da pattern built-in, regex compilabile con timeout 100 ms. Usa la sezione Prova al volo per verificare la regex su testi reali (anonimizzati) prima del deploy.

Conclusione

Il DLP di TuaGate trasforma una preoccupazione astratta, "e se qualcuno incolla dati personali nella chat?", in un controllo concreto, configurabile e verificabile. Cinque modalità di enforcement, 22 pattern built-in orientati al contesto italiano, pattern custom, policy per utente e per backend, tokenizzazione invertibile e audit senza leak di contenuto: tutto gestibile da interfaccia o via API, senza che l'utente finale debba cambiare il proprio modo di lavorare.

Per le organizzazioni che adottano TuaGPT come strumento quotidiano, TuaGate è il punto in cui la governance sui dati diventa eseguibilem, non un documento, ma un layer che agisce su ogni richiesta.