Data Lineage Agent para Data Cloud.
Linaje audit-grade conversacional, de la fuente al ad platform.
Agente custom orientado a Data Architects, Solution Architects, DPO y Compliance Lead. Traza linaje end-to-end (source system → DLO → DMO → CI → segmento → activación → ad platform) y responde queries de auditoría en lenguaje natural. Va más allá del Data Steward OOTB lineage por ser conversacional, audit-grade y por integrar análisis de impacto predicado vs. actual. Ideal para auditorías regulatorias, change management y decisiones de deprecation.
¿Qué hace Data Lineage Agent?
Es un agente custom que construye un graph de linaje end-to-end sobre Data Cloud y responde preguntas conversacionales del tipo "qué activaciones usan email del cliente X en Q4", "qué CIs dependen de transaction.amount", "si elimino un DMO legacy, qué se rompe". Aplica masking de PII en outputs, predice impacto de cambios upstream, exporta audit reports a Confluence o Notion y mantiene memoria de lineage patterns frecuentes para acelerar auditorías recurrentes.
Cómo funciona paso a paso
De la metadata a la respuesta auditable. 5 pasos.
Ingesta de metadata
El agente consume metadata de Data Streams, DMOs, Calculated Insights, Segmentos y Activations vía Metadata APIs. Mantiene snapshot histórico para queries sobre estados pasados.
Construcción del lineage graph
El Lineage Graph Builder arma el graph end-to-end (source → DLO → DMO → CI → segmento → activación → destino). Opcional: persistencia en Neo4j vía Heroku para queries pesadas.
Query del usuario
El usuario pregunta en lenguaje natural. El Query Resolver traduce la pregunta a una query sobre el graph, considera consent y privacy filters y devuelve resultado con masking de PII.
Impact analysis
Cuando el usuario pregunta por impacto de cambios, analyzeImpact estima qué CIs, segmentos y activaciones se rompen y propone una secuencia de cambios segura.
Audit report
generateAuditReport compone un reporte versionado con el lineage path completo y la evidencia. exportToConfluence o exportToNotion publica el documento listo para auditoría.
Ejemplo de interacción real
[DPO durante una auditoría regulatoria]
[El agente responde en 6 segundos]
Arquitectura del agente
Topics, Actions, Hydrators, Effectors, Channels, DMOs, Trust Layer y Memory.
Topics
Dominios de razonamiento
- Lineage Graph Builder
- Query Resolver
- Impact Analyzer
- Change-impact Predictor
- Audit Report Composer
- Lineage Search
Actions
Lo que ejecuta
- buildGraph
- queryLineage
- analyzeImpact
- generateAuditReport
- exportToConfluence / exportToNotion
- traceField / traceSegment
Hydrators y DMOs
Fuentes de contexto
- Data Streams config
- DMO definitions
- CI dependencies
- Segment definitions
- Activation logs
- Prior changes y snapshots
Effectors, Channels, Trust, Memory
Escrituras y guardrails
- Write Lineage Graph
- Push a graph DB (Neo4j optional via Heroku)
- Post audit report
- Channels: Lightning, Slack, Confluence/Notion
- Trust Layer: audit-grade + masking de PII
- Memory: lineage patterns y frequent traces
Implementación en 5 fases
El factor crítico es la disponibilidad de metadata APIs y la consistencia del naming.
Discovery del catálogo y use-cases de auditoría
Mapeamos el catálogo (Data Streams, DMOs, CIs, Segmentos, Activations) e identificamos las preguntas de auditoría más frecuentes.
Acceso a metadata APIs y naming
Validamos accesos a Metadata APIs en cada layer y enforce de naming consistente. Identificamos owners y áreas con gaps.
Configuración del agente y graph
Construimos el Lineage Graph Builder, calibramos masking de PII y opcionalmente persistimos el graph en Neo4j vía Heroku para queries pesadas.
Piloto con auditoría real
Validamos sobre una auditoría concreta (DSAR, change request o impact analysis previo a un cambio upstream). Calibramos response time y reportes.
Go-live y change management
Rollout total con integración a ITSM para impact analysis previo a cambios y a Confluence o Notion para audit reports periódicos.
Perfiles Solu y participantes cliente
Requisitos para arrancar
Lo que conviene tener listo antes del piloto.
Datos
- Metadata APIs accesibles en cada layer
- Naming consistency en DMOs, CIs y segmentos
- Ownership matrix documentada
- Snapshots históricos cuando sea posible
Integraciones
- Mulesoft o conectores zero-copy
- Confluence o Notion via MCP
- Slack vía MCP
- Neo4j vía Heroku como opción avanzada
Organizacional
- Owner de gobernanza de datos
- Política de change tracking
- Integración con ITSM para impact analysis
- Sponsor del CDO o DPO
Qué se busca optimizar
Dimensiones operativas y de calidad, planteadas como marco genérico.
Tiempo de auditoría regulatoria
De semanas a horas en auditorías recurrentes (DSAR, consent audit, change request).
Cobertura de lineage sobre el catálogo
Porcentaje del catálogo (DMOs, CIs, segmentos, activaciones) representado en el lineage graph.
Response time del agente
Llevar el response time a segundos para queries comunes y a minutos para análisis de impacto profundo.
Confidence en cambios upstream
Coincidencia entre impacto predicado y actual luego del rollout: cuánto se rompe sin haber sido anticipado.
Reuso de queries y reports
Cuánto reuso de patrones y traces frecuentes habilita la memoria del agente.
Calidad del audit trail
Trazabilidad completa, masking de PII en outputs y export a herramientas de documentación corporativa.
Qué considerar al implementar
Cinco focos para sostener un lineage audit-grade en el tiempo.
Metadata accesible end-to-end
El graph solo es tan rico como su metadata. Vale la pena auditar accesos en cada layer (Data Streams, DMOs, CIs, segmentos, activaciones) antes del piloto.
Naming consistency
Con naming consistente, el agente correlaciona entidades sin ambigüedad. Sin él, las queries devuelven resultados ruidosos o incompletos.
Ownership matrix
Saber quién es owner de cada DMO o CI permite que el impact analysis derive en acción concreta y no en un report sin destinatario.
Governance de change tracking
El lineage rinde más cuando los cambios upstream se registran formalmente y se conectan con tickets del ITSM.
Masking de PII como guardrail
El audit-grade implica masking de PII automático en cada output. Es preferible asumirlo desde el día uno que reaccionar a un incidente.
Preguntas Frecuentes
El agente complementa catálogos como Data Steward OOTB o herramientas externas (Collibra, Alation) consumiendo su metadata cuando está disponible. No los reemplaza: les agrega capa conversacional, audit-grade y análisis de impacto.
Sí. El agente reconoce Data Streams provenientes de Mulesoft y de sources zero-copy (Snowflake, BigQuery, Databricks). El lineage se traza hasta la fuente externa cuando hay metadata accesible.
Sí, cuando la metadata del layer lo expone. Para CIs, segmentos y DMOs ese detalle suele estar disponible y permite responder preguntas como "qué CIs dependen de transaction.amount".
El agente mantiene snapshots periódicos del lineage graph. Las queries pueden ejecutarse contra estados pasados para responder auditorías sobre Q3 o sobre un release específico, con evidencia versionada.
Vía MCP. Los audit reports se exportan como páginas estructuradas en el espacio elegido por el cliente, con masking de PII y links de retorno al graph para revisión adicional.
Sí. Las queries pueden formularse en español rioplatense, mexicano, portugués brasileño o inglés. La respuesta sigue el idioma de la pregunta y se exporta multi-idioma cuando aplica al destino.
Linaje conversacional audit-grade, listo para regulación y change management.
Conversemos con un Data Architect de Solu. En una sesión de discovery revisamos catálogo, metadata APIs y use-cases de auditoría para proyectar el lineage en tu organización.