Di Andrew Tan
L'audit che non trova mai il problema reale
Ecco una scena che si ripete ogni trimestre nei settori regolamentati:
Il team di compliance esegue la sua scansione di governance. Il catalogo dati mostra tag di classificazione su ogni tabella del data warehouse. Il lakehouse ha policy di sicurezza a livello di colonna. Lo strumento BI impone l'accesso a livello di riga. Tutti approvano. Gli auditor se ne vanno soddisfatti.
Nel frattempo, un feed CDC sta replicando PII di clienti da un database transazionale a un cluster di analisi. Nessuno ha classificato lo stream in sé — hanno classificato la tabella di destinazione, il che va bene, tranne per il fatto che lo stream attraversa un topic di staging a cui si sottoscrivono tre diversi servizi. Uno di questi è un job di arricchimento AI che invia frammenti dei dati a un'API LLM esterna. La chiamata API non compare nel catalogo dati perché il catalogo cataloga solo ciò che atterra, non ciò che si muove.
Il programma di governance è impeccabile a riposo. È quasi cieco in movimento.
Non è un fallimento degli strumenti. È un errore di categoria. Abbiamo costruito la governance sull'assunto che i dati vivano in tabelle e file, e che se controlliamo gli endpoint, controlliamo la storia. Ma le pipeline moderne non funzionano così. I dati sono in costante movimento — attraverso broker, trasformazioni, set di addestramento per i modelli, verso API di partner — e la maggior parte dei framework di governance non ha tenuto il passo.
Perché la governance dei dati a riposo non coglie i casi difficili
La governance dell'era batch aveva senso per un'architettura dell'era batch. I dati si muovevano in carichi programmati. Sapevi quando arrivavano. Potevi scansionarli, classificarli e applicare le policy prima che qualcuno li interrogasse. La pipeline era sostanzialmente un camion da trasporto, e la governance avveniva al molo di carico.
Lo streaming e i CDC hanno rotto quel modello. I dati si muovono in modo continuo. Vengono uniti in volo. Vengono arricchiti da servizi esterni. Vengono filtrati, divisi e instradati verso più consumatori prima ancora di toccare una destinazione governata. Quando atterrano, le parti sensibili potrebbero essere già trapelate, copiate o inviate in qualche posto che il catalogo non vede.
Il divario si manifesta in modi specifici e dolorosi:
Classificare dopo l'atterraggio è spesso troppo tardi. Se uno stream CDC trasporta numeri di carta di credito non mascherati attraverso tre topic intermedi prima di raggiungere il data warehouse, la policy a livello di colonna del warehouse è un cerotto su un'emorragia avvenuta a monte.
Gli strumenti di governance batch non capiscono la semantica dello streaming. Un catalogo dati può dirti cosa c'è in una tabella. Non può dirti che uno streaming join sta estraendo PII da un topic e correlandoli con dati comportamentali da un altro, creando un nuovo dataset composito che nessuno ha revisionato.
Il lineage si spezza ai bordi. La maggior parte degli strumenti di lineage traccia le relazioni da tabella a tabella. Non tracciano la chiamata API che arricchisce un record a metà pipeline, né il modello che si addestra su uno snapshot dello stream, né il job reverse ETL che spinge i dati derivati di nuovo in un CRM. La mappa sembra completa finché non segui un record attraverso il suo ciclo di vita reale.
Le policy di retention ignorano le copie create durante il movimento. Imposti una retention di 90 giorni sul data warehouse. Ottimo. Ma il consumatore dello stream che ha materializzato una vista in Elasticsearch? Il bucket S3 in cui la pipeline scrive per il replay? L'API di partner che ha ricevuto una copia? La retention è forte solo quanto la sua replica più debole, e la maggior parte dei programmi di governance non sa dove si trovino le repliche.
Cosa significa davvero la governance in movimento
Spostare la governance nella pipeline non significa sostituire il catalogo dati o il modello di sicurezza del lakehouse. Significa estendere l'applicazione delle policy ai punti in cui i dati si muovono effettivamente.
Ecco le quattro capacità che contano:
Policy al confine
Invece di classificare i dati dopo che sono arrivati, classificali quando entrano nella pipeline. Un feed CDC da un database clienti dovrebbe portare con sé i propri tag di classificazione — PII, dati finanziari, dati sanitari — e quei tag dovrebbero persistere attraverso ogni riformattazione, join e decisione di routing. Se un consumatore a valle cerca di inviare dati taggati a una destinazione non approvata, la pipeline dovrebbe bloccarlo, non registrarlo e andare avanti.
Sembra ovvio, ma la maggior parte delle pipeline non lo fa. I metadati che contano per la governance — classificazione, flag di consenso, requisiti di retention — vengono solitamente eliminati durante la normalizzazione o memorizzati in un catalogo separato che il runtime non consulta.
Gate di approvazione per i flussi ad alto rischio
Alcuni movimenti di dati non dovrebbero avvenire senza una seconda occhiata. Una pipeline che inizia a replicare una nuova tabella in uno strumento di analisi esterno. Uno stream che inizia a includere una colonna appena aggiunta con dati di geolocalizzazione. Un Workflow AI che vuole inviare trascrizioni di clienti a un modello di terze parti.
Non sono malfunzionamenti. Sono operazioni normali. Ma sono anche i momenti in cui il rischio di governance si concentra. Il modello giusto non è bloccare tutto e aspettare un ticket. È lasciare che i flussi a basso rischio procedano automaticamente e segnalare quelli ad alto rischio per l'approvazione — con il gate di approvazione integrato nella pipeline stessa, non in uno strumento di workflow separato che l'ingegnere potrebbe usare o dimenticarsi di usare.
Retention e cancellazione che seguono i dati
Quando un cliente esercita il proprio diritto all'oblio, o quando scade un periodo di retention, la richiesta deve raggiungere ogni copia dei dati — non solo la tabella del data warehouse. Ciò include i replay dello stream, le viste materializzate, gli snapshot di addestramento dei modelli e le cache delle API di partner.
In pratica, ciò significa che il runtime della pipeline deve tracciare dove sono stati inviati i dati e mantenere la mappatura tra l'identità di un record e le sue repliche. La maggior parte delle piattaforme di streaming non lo fa. Trattano ogni messaggio come indipendente, senza memoria di dove provenga o dove sia andato. La governance in movimento richiede un modello diverso: i messaggi portano con sé l'identità e il runtime mantiene la provenance.
Lineage che include le trasformazioni, non solo le tabelle
Il lineage da tabella a tabella è utile per le pipeline batch. Per lo streaming e i CDC è incompleto. È necessario sapere che un particolare passaggio di arricchimento ha aggiunto dati di terze parti, che un join ha correlato due dataset che avrebbero dovuto rimanere separati, o che un filtro ha silenziosamente scartato record che avrebbero dovuto essere conservati per compliance.
Ciò significa che il lineage non può essere una scansione a posteriori dei log delle query. Deve essere integrato nel runtime, catturando ciò che ogni passaggio fa ai dati mentre avviene.
Il percorso di rollout: iniziare dalle interfacce
Nessuno ricostruisce il proprio modello di governance in un unico progetto. I team che hanno successo iniziano in piccolo e si espandono.
Il posto giusto per iniziare è il confine della pipeline — i punti in cui i dati entrano o escono dal tuo sistema. Feed CDC dai database di produzione. Chiamate API a servizi esterni. Job reverse ETL che spingono i dati di nuovo verso strumenti operativi. Queste sono le interfacce ad alto rischio e alta visibilità, ed è lì che i fallimenti di governance emergono per primi.
Scegli un'interfaccia. Aggiungi il tagging di classificazione alla fonte. Aggiungi un controllo delle policy prima che i dati escano. Aggiungi il tracciamento del lineage per quel flusso. Dimostra che funziona. Poi espandi all'interfaccia successiva.
I team che vedo fare bene questo hanno un tratto in comune: trattano la governance come una questione di runtime, non di documentazione. La policy non è scritta in un wiki e lasciata alla speranza. È applicata dalla pipeline, testata in CI e versionata con il codice. Quando la policy cambia, cambia la pipeline. Quando la pipeline cambia, la policy viene rivalidata.
Dove diventa più difficile di quanto sembri
Voglio essere onesto sugli ostacoli, perché "spostare la governance nella pipeline" è facile a dirsi e difficile a farsi.
Gli strumenti esistenti non sono costruiti per questo. La maggior parte dei cataloghi dati, degli scanner di sicurezza e degli strumenti di lineage è stata progettata per data warehouse batch. Si aspettano scansioni programmate, non stream continui. Si aspettano tabelle, non topic. Estenderli per coprire il movimento significa solitamente lavoro di integrazione personalizzato che il fornitore non supporta.
Le performance contano. Aggiungere controlli di classificazione, lookup di policy e logging di lineage a una pipeline di streaming aggiunge latenza. Per flussi ad alto throughput, l'overhead deve essere trascurabile — il che significa che le decisioni sulle policy devono essere messe in cache, valutate in modo asincrono o spinte ai margini della pipeline in modo che non blocchino il percorso critico.
La titolarità organizzativa è poco chiara. La data governance è spesso di proprietà di un team di compliance che non scrive codice di pipeline. L'ingegneria di piattaforma possiede il runtime ma non stabilisce le policy. Far concordare questi team su cosa significhi "governance in movimento", chi la mantiene e chi viene allertato quando si rompe è spesso più difficile dell'implementazione tecnica.
Gli standard si stanno ancora formando. Non esiste un protocollo universale per allegare metadati di governance a record in streaming. Nessuna API standard per l'applicazione delle policy nella pipeline. I vendor stanno costruendo i propri modelli e non interoperano bene. Se scommetti su un approccio specifico, stai in parte scommettendo su quale modello di vendor vincerà.
Dove entra in gioco layline.io
Non fingerò di risolvere ogni parte di questo. In layline.io, ci siamo concentrati sullo strato di runtime: un motore di elaborazione sia batch che streaming in grado di portare i metadati attraverso le trasformazioni, applicare le policy ai confini della pipeline e mantenere il lineage lungo l'intero flusso.
La scommessa è che la governance non dovrebbe essere un sistema separato affiancato alla pipeline, che analizza i log e spera di cogliere tutto. Dovrebbe far parte della pipeline stessa — integrata nello stesso runtime che muove i dati, applicata dagli stessi percorsi di codice che li trasformano, visibile nello stesso livello di osservabilità che ti dice se la pipeline è sana.
Questo conta perché l'alternativa è la frammentazione. Uno strumento per il catalogo, un altro per lo streaming, un altro per il batch, un altro per il lineage, un altro per la gestione delle policy. Ogni punto di integrazione è una giuntura da cui la governance può trapelare. I team con cui parlo sono stanchi delle giunture.
Non siamo gli unici a costruire in questa direzione. Confluent sta spingendo la governance degli stream. Airbyte sta inquadrando la sovranità come un problema architetturale. L'intero mercato si sta muovendo verso la stessa conclusione: i dati in movimento hanno bisogno degli stessi controlli dei dati a riposo. Stiamo costruendo il nostro pezzo di quello stack.
La domanda da porre al tuo team di governance
La prossima volta che il tuo team di compliance approva un audit pulito, chiedigli questo:
"Mi puoi mostrare dove vanno i PII dei clienti tra il database di produzione e il data warehouse? Non gli endpoint — il percorso. Ogni topic, ogni chiamata di arricchimento, ogni replica."
Se la risposta è un diagramma con due riquadri e una freccia, non hai governance. Hai speranza.
La buona notizia è che risolvere il problema non richiede di strappare tutto. Richiede di spostare il punto di controllo dalla destinazione al viaggio. Inizia dai confini. Aggiungi policy alla pipeline. Rendi il lineage parte del runtime. Gli strumenti stanno migliorando, i pattern diventano più chiari e i team che lo capiranno per primi avranno un vero vantaggio operativo — non solo audit più puliti, ma meno incidenti, ripristino più rapido e un'infrastruttura dati di cui possono fidarsi davvero.
Se stai ragionando sulla governance per pipeline di streaming o CDC, mettiti in contatto. Stiamo lavorando con i team esattamente su questo problema — e le soluzioni sono più pratiche di quanto sembrino a prima vista.
Andrew Tan è un imprenditore seriale e fondatore di layline.io, che costruisce infrastrutture di elaborazione dati aziendali in grado di gestire carichi di lavoro sia batch che real-time su larga scala.
