Data Steward Agent para Data Cloud.
Calidad de datos vigilada, anomalías detectadas a tiempo y remediación que llega antes que el incidente.
El agente OOTB de Agentforce que monitorea calidad, completitud, frescura, validez, consistencia y unicidad de los DMOs y DLOs de Data Cloud. Detecta anomalías estructurales, prioriza issues por impacto en activaciones y segmentos críticos, abre tickets en el ITSM existente y propone remediación con audit trail completo. Pensado para CDO, Data Governance Lead, Data Engineering Manager y equipos de Data Stewardship que necesitan mantener un Customer 360 confiable a escala.
¿Qué hace Data Steward Agent?
Es un agente OOTB de Agentforce que vigila el estado de salud de los DMOs y DLOs en Data Cloud. Corre chequeos de calidad sobre seis dimensiones (completitud, frescura, validez, consistencia, unicidad y precisión), detecta anomalías estructurales, calcula el impacto downstream sobre segmentos y activaciones críticas, abre un ticket en Service Cloud, Jira o Linear con la prioridad correcta y sugiere remediación con base en patrones previos. Mantiene catálogo y linaje al día sin pedirle ayuda al equipo data.
Cómo funciona paso a paso
De la señal de cambio al cierre con learning archivado. 6 pasos en cada ciclo.
Señal de cambio detectada
El agente recibe una señal sobre un DMO o DLO: drop de frescura, salto en volumen, distribución que se desvía o nuevo schema. Las señales pueden venir de chequeos programados, de ingestas o de un usuario que reporta un dato sospechoso.
Chequeo de calidad multi-dimensión
Corre las reglas activas sobre el DMO afectado: completitud, frescura, validez de tipos, consistencia con DMOs relacionados, unicidad de claves y precisión semántica frente al business glossary.
Triage por impacto downstream
Hidrata el mapa de consumers: qué segmentos, qué Calculated Insights, qué dashboards y qué activaciones dependen del DMO. Calcula el blast radius y asigna severidad: critical, high, medium o low.
Ticket con owner y contexto
Abre un ticket en Service Cloud Cases, Jira o Linear con el owner del DMO asignado. Adjunta el contexto técnico, la lista de consumers afectados y un link al lineage del campo.
Remediación sugerida
Propone una acción concreta basada en patrones previos: revisar el pipeline upstream, deprecar un campo, ajustar la regla de calidad o reentrenar la regla de match. El owner aprueba o ajusta.
Cierre con learning archivado
Una vez resuelto, archiva el incidente en la memoria del agente: causa raíz, mitigación aplicada, tiempo de resolución. Ese aprendizaje afina el triage y la remediación futura.
Ejemplo de interacción
[El agente detecta drop de frescura]
[Acción automática]
Arquitectura técnica
Topics, Actions, Hydrators, Effectors, Channels, DMOs, Trust Layer y Memory que sostienen al agente.
Topics
Dominios de razonamiento
- Quality Monitor
- Anomaly Detector
- Issue Triager
- Remediation Recommender
- Catalog Maintainer
- Lineage Auditor
Actions y canales
Lo que ejecuta y dónde vive
- runQualityCheck
- openTicket (ITSM)
- suggestRemediation
- updateCatalog
- deprecateField
- Lightning
- Slack vía MCP
- Tableau Pulse
Hydrators y DMOs
Contexto y memoria
- Estadísticas de DMOs
- Logs de frescura
- Downstream consumers map
- Issues previos resueltos
- Business glossary
- Field Lineage
- Memory: incidentes archivados
Effectors y Trust Layer
Escrituras y guardrails
- Definir reglas de calidad
- Abrir Service Cloud Cases / Jira / Linear
- Actualizar descriptions de DMO
- Audit trail completo
- Masking de PII en outputs
- Permisos por rol y por DMO
Cómo se implementa en 5 fases
De discovery a producción con ownership claro y reglas de calidad afinadas al volumen real.
Discovery y catálogo de DMOs
Revisamos el catálogo actual de DMOs, descriptions, ownership por dominio y nivel de glossary. Mapeamos los consumers críticos: segmentos, Calculated Insights, dashboards y activaciones.
Definición de reglas de calidad
Diseñamos las reglas por dimensión y por DMO: thresholds de completitud, ventanas de frescura, formatos válidos. Calibramos al volumen real para evitar falsos positivos.
Configuración del agente y del ITSM
Configuramos los Topics y Actions en Agent Builder, conectamos con el ITSM de la compañía (Service Cloud, Jira o Linear) y definimos la matriz de severidad y enrutamiento.
Piloto controlado por dominio
Activamos el agente sobre un dominio acotado (por ejemplo, Customer 360 o Transactional). Monitoreamos detección, triage y remediación durante 3 a 4 semanas y ajustamos thresholds.
Go-live y mejora continua
Expansión a todos los dominios. Revisión mensual de detecciones, MTTR y precisión del triage. Tuning de la memoria del agente con incidentes resueltos.
Equipo típico de implementación
Requisitos para arrancar
Lo que necesitás listo antes de poner el Data Steward Agent en producción.
Datos
- Data Cloud activo con DMOs en producción
- Descriptions completadas en cada DMO crítico
- Business glossary mínimo viable
- Catálogo con ownership por DMO y por DLO
Integraciones
- ITSM existente: Service Cloud, Jira o Linear
- Slack vía MCP o canal de notificación equivalente
- Mulesoft o conectores Data Cloud para fuentes externas
- Tableau Pulse o dashboard de health
Organizacional
- Owner asignado por cada DMO o dominio
- Política de severidad y SLA acordada
- Sponsor en CDO o Data Governance
- Proceso de revisión mensual de reglas
Trust y compliance
- Trust Layer activo
- Política de masking de PII documentada
- Audit trail habilitado
- Permisos por rol revisados
Qué se busca optimizar
Lo que el agente busca mejorar — los rangos exactos dependen del baseline de cada compañía.
Tiempo de detección de issues
Pasar de detectar problemas de calidad en días u horas (cuando se queja un consumer) a detectarlos en minutos vía chequeos programados.
MTTR de issues críticos
Reducir el tiempo medio de resolución gracias al triage automatizado, owner pre-asignado y remediación sugerida desde el primer ticket.
Cobertura de DMOs monitoreados
Subir el porcentaje de DMOs y DLOs cubiertos por reglas activas. Objetivo realista: arrancar por dominios críticos y expandir en cohortes.
Calidad del alerting
Bajar la tasa de falsos positivos y subir la tasa de alertas accionables, midiendo la proporción de tickets que terminan en remediación real.
Alineación catálogo ↔ realidad
Mantener descriptions, glossary y lineage al día para que segmentos, Calculated Insights y agentes downstream operen sobre metadata confiable.
Tiempo del equipo data
Liberar capacidad del equipo data Steward de tareas reactivas para que se concentre en diseño de reglas, gobierno y nuevos dominios.
Qué considerar al implementar
Decisiones de diseño que vale la pena tomar al principio. Solu acompaña cada una con un patrón probado.
Thresholds adecuados al volumen
Reglas demasiado estrictas generan ruido, demasiado laxas dejan pasar issues reales. Solu calibra los thresholds con el volumen y la varianza histórica del DMO antes de activar la regla.
Triage por impacto, no por severidad genérica
Una anomalía menor en un DMO crítico puede impactar campañas en vivo. Solu modela el blast radius con el mapa de consumers para que la severidad refleje el impacto real, no la severidad técnica.
Ownership claro por DMO
Sin owner identificado, los tickets giran sin resolverse. Solu acompaña la definición de ownership por dominio antes de activar el agente y propone un patrón ligero de revisión trimestral.
Integración con el ITSM existente
Crear un nuevo sistema de tickets duplica el trabajo. Solu integra el agente con el ITSM ya en uso (Service Cloud, Jira o Linear) para que la operación de calidad de datos viva en el mismo flujo del resto del equipo.
Memoria como activo, no como log
Los incidentes resueltos son la mejor fuente de aprendizaje. Solu configura la memoria del agente para que cada caso archivado afine triage y remediación futura, en lugar de quedar en un log inerte.
Preguntas Frecuentes
No. El agente cubre el volumen masivo de chequeos y el triage repetitivo, pero las decisiones de gobierno (qué se considera un issue, qué se deprecia, cómo se versiona un DMO) las sigue tomando el Data Steward humano. El agente le devuelve tiempo para diseño y gobierno, no lo reemplaza.
No completo, pero sí mínimo. Las reglas de validez y consistencia se apoyan en el glossary, así que conviene arrancar con los términos críticos del primer dominio (Customer 360 o Transactional, por ejemplo) y expandir a medida que se activan más DMOs.
Mulesoft alimenta los Data Streams que el agente monitorea aguas abajo. Si una falla de calidad se origina en un flujo de Mulesoft, el ticket incluye un link al flow afectado. Heroku se integra como source de datos para los DMOs y como destino de notificaciones si la compañía tiene allí su tooling interno.
Sí. Cada org tiene su propio agente con sus reglas y permisos. Cuando hay varias orgs federadas, se puede consolidar el dashboard de health en Tableau Pulse o CRMA para una vista de portafolio.
Sí. Las reglas se definen sobre cualquier DMO, estándar o custom. La condición es que el DMO tenga descriptions y ownership asignados. Para DMOs muy custom, conviene ajustar las reglas y revisarlas en la primera revisión mensual.
Con tres palancas: triage por impacto downstream para que solo escalen issues que afectan consumers reales, agrupación de alertas relacionadas en un único ticket y revisión mensual de la tasa de tickets accionables vs. ruido para retirar reglas que no aportan.
El Trust Layer aplica masking automático sobre PII en los outputs. El agente nunca expone valores sensibles en tickets, notificaciones ni dashboards. Los chequeos sobre PII operan a nivel estadístico (completitud, formato), no sobre el valor concreto.
Calidad de datos vigilada con la disciplina que tu Customer 360 necesita.
Hablá con un Solu Architect. Mapeamos tus DMOs, tus consumers críticos y diseñamos el roadmap del Data Steward Agent en tu org.