Por Andrew Tan
La auditoría que nunca encuentra el problema real
Esta es una escena que se repite en las industrias reguladas cada trimestre:
El equipo de cumplimiento ejecuta su escaneo de gobernanza. El catálogo de datos muestra etiquetas de clasificación en cada tabla del almacén de datos. El lakehouse tiene políticas de seguridad a nivel de columna. La herramienta de BI aplica el acceso a nivel de fila. Todo el mundo firma. Los auditores se van contentos.
Mientras tanto, un feed de CDC está replicando PII de clientes desde una base de datos transaccional a un clúster de análisis. Nadie clasificó el stream en sí: clasificaron la tabla de destino, lo cual está bien, excepto que el stream pasa por un topic de staging al que se suscriben tres servicios distintos. Uno de ellos es un trabajo de enriquecimiento con IA que envía fragmentos de los datos a una API externa de LLM. La llamada a la API no aparece en el catálogo de datos porque el catálogo solo cataloga lo que aterriza, no lo que se mueve.
El programa de gobernanza es impecable en reposo. Es casi ciego en movimiento.
Esto no es un fallo de herramientas. Es un error de categoría. Hemos construido la gobernanza partiendo del supuesto de que los datos residen en tablas y archivos, y de que si controlamos los extremos, controlamos la historia. Pero los pipelines modernos no funcionan así. Los datos están en constante movimiento — a través de brokers, pasando por transformaciones, hacia conjuntos de entrenamiento de modelos, hacia APIs de socios — y la mayoría de los marcos de gobernanza no se han puesto al día.
Por qué la gobernanza en reposo no detecta los casos difíciles
La gobernanza de la era por lotes tenía sentido para la arquitectura de la era por lotes. Los datos se movían en cargas programadas. Sabías cuándo llegaban. Podías escanearlos, clasificarlos y aplicar políticas antes de que nadie los consultara. El pipeline era básicamente un camión de reparto, y la gobernanza ocurría en el muelle de carga.
El streaming y CDC rompieron ese modelo. Los datos se mueven de forma continua. Se unen en vuelo. Se enriquecen con servicios externos. Se filtran, dividen y enrutan a múltiples consumidores antes de llegar a un destino gobernado. Para cuando aterrizan, las partes sensibles ya pueden haberse filtrado, copiado o enviado a algún lugar que el catálogo no puede ver.
La brecha se manifiesta de formas específicas y dolorosas:
La clasificación después del aterrizaje suele ser demasiado tarde. Si un stream de CDC transporta números de tarjetas de crédito sin enmascarar a través de tres topics intermedios antes de llegar al almacén de datos, la política a nivel de columna del almacén es un parche sobre una hemorragia que ocurrió aguas arriba.
Las herramientas de gobernanza por lotes no entienden la semántica del streaming. Un catálogo de datos puede decirte qué hay en una tabla. No puede decirte que un join en streaming está extrayendo PII de un topic y correlacionándolo con datos de comportamiento de otro, creando un nuevo conjunto de datos compuesto que nadie revisó.
El linaje se rompe en las costuras. La mayoría de las herramientas de linaje trazan relaciones de tabla a tabla. No rastrean la llamada a la API que enriquece un registro a mitad del pipeline, ni el modelo que se entrena con una instantánea del stream, ni el trabajo de Reverse ETL que devuelve datos derivados a un CRM. El mapa parece completo hasta que sigues un registro a lo largo de su ciclo de vida real.
Las políticas de retención ignoran las copias creadas mientras los datos se mueven. Estableces una retención de 90 días en el almacén de datos. Genial. ¿Pero el consumidor del stream que materializó una vista en Elasticsearch? ¿El bucket de S3 al que el pipeline escribe para reproducción? ¿La API del socio que recibió una copia? La retención es tan fuerte como su réplica más débil, y la mayoría de los programas de gobernanza no saben dónde están las réplicas.
Lo que realmente significa la gobernanza en movimiento
Trasladar la gobernanza al pipeline no significa reemplazar el catálogo de datos ni el modelo de seguridad del lakehouse. Significa extender la aplicación de políticas a los lugares donde los datos realmente se están moviendo.
Estas son las cuatro capacidades que importan:
Políticas en el límite
En lugar de clasificar los datos después de que lleguen, clasifícalos cuando entren al pipeline. Un feed de CDC desde una base de datos de clientes debería llevar sus etiquetas de clasificación consigo — PII, datos financieros, historiales médicos — y esas etiquetas deberían persistir a través de cada cambio de forma, join y decisión de enrutamiento. Si un consumidor aguas abajo intenta enviar datos etiquetados a un destino no aprobado, el pipeline debería bloquearlos, no solo registrarlos y seguir adelante.
Suena obvio, pero la mayoría de los pipelines no lo hacen. Los metadatos que importan para la gobernanza — clasificación, indicadores de consentimiento, requisitos de retención — suelen eliminarse durante la normalización o almacenarse en un catálogo separado que el runtime no consulta.
Puertas de aprobación para flujos de alto riesgo
Algunos movimientos de datos no deberían ocurrir sin una segunda revisión. Un pipeline que comienza a replicar una tabla nueva a una herramienta de análisis externa. Un stream que empieza a incluir una columna recién añadida con datos de geolocalización. Un Workflow de IA que quiere enviar transcripciones de clientes a un modelo de terceros.
No son fallos. Son operaciones normales. Pero también son los momentos en los que se concentra el riesgo de gobernanza. El modelo correcto no es bloquear todo y esperar un ticket. Es dejar que los flujos de bajo riesgo avancen automáticamente y marcar los de alto riesgo para aprobación — con la puerta de aprobación integrada en el pipeline mismo, no en una herramienta de workflow separada que el ingeniero puede o no recordar usar.
Retención y eliminación que siguen a los datos
Cuando un cliente ejerce su derecho al olvido, o cuando expira un periodo de retención, la solicitud debe llegar a cada copia de los datos — no solo a la tabla del almacén. Eso incluye reproducciones de streams, vistas materializadas, instantáneas de entrenamiento de modelos y cachés de APIs de socios.
En la práctica, esto significa que el runtime del pipeline necesita rastrear dónde se enviaron los datos y mantener el mapeo entre la identidad de un registro y sus réplicas. La mayoría de las plataformas de streaming no hacen esto. Tratan cada mensaje como independiente, sin memoria de dónde vino ni a dónde fue. La gobernanza en movimiento requiere un modelo diferente: los mensajes portan identidad, y el runtime mantiene la procedencia.
Linaje que incluye transformaciones, no solo tablas
El linaje de tabla a tabla es útil para pipelines por lotes. Para streaming y CDC, es incompleto. Necesitas saber que un paso de enriquecimiento en particular añadió datos de terceros, que un join correlacionó dos conjuntos de datos que debían mantenerse separados, o que un filtro descartó silenciosamente registros que deberían haberse retenido por cumplimiento.
Esto significa que el linaje no puede ser un escaneo a posteriori de logs de consultas. Tiene que estar integrado en el runtime, capturando lo que cada paso le hizo a los datos a medida que ocurre.
La ruta de implementación: empezar por las interfaces
Nadie reconstruye su modelo de gobernanza en un solo proyecto. Los equipos que tienen éxito empiezan pequeño y expanden.
El lugar correcto para empezar es el límite del pipeline: los puntos donde los datos entran o salen de tu sistema. Feeds de CDC desde bases de datos de producción. Llamadas a APIs hacia servicios externos. Trabajos de Reverse ETL que devuelven datos a herramientas operativas. Estas son las interfaces de mayor riesgo y mayor visibilidad, y son donde aparecen primero los fallos de gobernanza.
Elige una interfaz. Añade etiquetado de clasificación en el origen. Añade una verificación de política antes de que los datos salgan. Añade seguimiento de linaje para ese flujo. Demuestra que funciona. Luego expande a la siguiente interfaz.
Los equipos que veo hacer esto bien comparten un rasgo: tratan la gobernanza como una preocupación del runtime, no de la documentación. La política no se escribe en una wiki y se espera lo mejor. Se aplica mediante el pipeline, se prueba en CI y se versiona junto con el código. Cuando la política cambia, el pipeline cambia. Cuando el pipeline cambia, la política se revalida.
Donde esto es más difícil de lo que parece
Quiero ser honesto sobre los obstáculos, porque «solo traslada la gobernanza al pipeline» es fácil de decir y difícil de hacer.
Las herramientas existentes no están construidas para esto. La mayoría de los catálogos de datos, escáneres de seguridad y herramientas de linaje fueron diseñados para almacenes de datos por lotes. Esperan escaneos programados, no streams continuos. Esperan tablas, no topics. Extenderlos para cubrir el movimiento suele significar trabajo de integración personalizada que el proveedor no admite.
El rendimiento importa. Añadir comprobaciones de clasificación, consultas de políticas y registro de linaje a un pipeline de streaming añade latencia. Para flujos de alto throughput, la sobrecarga debe ser insignificante — lo que significa que las decisiones de política deben almacenarse en caché, evaluarse de forma asíncrona o empujarse al borde del pipeline donde no bloqueen la ruta crítica.
La propiedad organizativa es confusa. La gobernanza de datos suele ser responsabilidad de un equipo de cumplimiento que no escribe código de pipeline. La ingeniería de plataforma es dueña del runtime pero no establece políticas. Lograr que estos equipos se pongan de acuerdo sobre qué significa la «gobernanza en movimiento», quién la mantiene y quién recibe la alerta cuando falla suele ser más difícil que la implementación técnica.
Los estándares aún se están formando. No hay un protocolo universal para adjuntar metadatos de gobernanza a registros de streaming. No hay una API estándar para la aplicación de políticas en pipelines. Los proveedores están construyendo sus propios modelos y no interoperan bien. Si apuestas por un enfoque específico, en parte estás apostando a qué modelo de proveedor gana.
Dónde encaja layline.io
No voy a fingir que resolvemos cada parte de esto. En layline.io, nos hemos centrado en la capa de runtime: un motor de procesamiento tanto por lotes como de streaming que puede transportar metadatos a través de transformaciones, aplicar políticas en los límites del pipeline y mantener el linaje a lo largo de todo el flujo.
La apuesta es que la gobernanza no debería ser un sistema separado sentado junto al pipeline, analizando logs y esperando atraparlo todo. Debería ser parte del pipeline mismo — integrada en el mismo runtime que mueve los datos, aplicada por las mismas rutas de código que lo transforman, visible en la misma capa de observabilidad que te dice si el pipeline está sano.
Esto importa porque la alternativa es la fragmentación. Una herramienta para catalogar, otra para streaming, otra para lotes, otra para linaje, otra para gestión de políticas. Cada punto de integración es una costura por donde la gobernanza puede filtrarse. Los equipos con los que hablo están cansados de las costuras.
No somos los únicos construyendo en esta dirección. Confluent está impulsando la gobernanza de streams. Airbyte está planteando la soberanía como un problema arquitectónico. Todo el mercado se mueve hacia la misma conclusión: los datos en movimiento necesitan los mismos controles que los datos en reposo. Estamos construyendo nuestra pieza de esa pila.
La pregunta que debes hacerle a tu equipo de gobernanza
La próxima vez que tu equipo de cumplimiento apruebe una auditoría limpia, hazles esta pregunta:
«¿Pueden mostrarme a dónde va el PII de los clientes entre la base de datos de producción y el almacén de datos? No los extremos: el camino. Cada topic, cada llamada de enriquecimiento, cada réplica.»
Si la respuesta es un diagrama con dos cuadros y una flecha, no tienes gobernanza. Tienes esperanza.
La buena noticia es que arreglarlo no requiere arrancar todo. Requiere mover el punto de control del destino al recorrido. Empieza en los límites. Añade políticas al pipeline. Haz que el linaje forme parte del runtime. Las herramientas están mejorando, los patrones se están aclarando, y los equipos que descifren esto primero tendrán una ventaja operativa real: no solo auditorías más limpias, sino menos incidentes, recuperación más rápida e infraestructura de datos en la que realmente puedan confiar.
Si estás pensando en la gobernanza para pipelines de streaming o CDC, ponte en contacto. Estamos trabajando con equipos exactamente en este problema — y las soluciones son más prácticas de lo que parecen a primera vista.
Andrew Tan es un emprendedor en serie y fundador de layline.io, construyendo infraestructura de procesamiento de datos empresariales que maneja cargas de trabajo tanto por lotes como en tiempo real a escala.
