Data owner y data steward en datos maestros: quién decide qué
Diferencia entre data owner y data steward en datos maestros, con una matriz de decisiones para materiales, proveedores y clientes y pasos para empezar.
El data owner es quien decide y responde por los datos de un dominio: aprueba reglas, excepciones y cambios sensibles. El data steward cuida esas reglas en el día a día: define atributos y valores permitidos y atiende los problemas de calidad. El equipo de datos maestros ejecuta, y TI resguarda y opera el sistema, sin ser dueña del dato.
Llega un correo que pide cambiar la cuenta bancaria de un proveedor. La analista del equipo de datos maestros abre el registro, cambia banco, sucursal y número de cuenta, y el pago de esa semana sale hacia la cuenta nueva. Unas semanas después el proveedor llama reclamando el pago. La cuenta nueva nunca fue suya.
Entonces empieza la reunión. Compras dice que los datos bancarios son de finanzas. Finanzas dice que los registros son del equipo de datos maestros. El equipo dice que solo ejecutó lo que le pidieron. TI muestra el log: el campo lo cambió un usuario con permiso. Cada uno hizo su parte, y nadie tenía la decisión. Eso es lo que resuelve una división clara entre data owner y data steward.
¿Qué es un data owner y qué es un data steward?
No existe una ley que defina estos roles para empresas privadas. Pero hay dos referencias públicas que ayudan a separarlos.
La primera es el Decreto nº 10.046/2019, una norma de Brasil sobre gobierno de datos en la administración pública federal brasileña. Aplica a los organismos federales de ese país, no a las empresas. La usamos aquí solo como referencia conceptual, porque separa con claridad a quien gobierna el dato de quien lo resguarda. Su artículo 2 define (traducción nuestra):
- Gestor de datos (inciso XIII): "órgano o entidad responsable del gobierno de un determinado conjunto de datos". Es el rol más cercano al data owner.
- Custodio de datos (inciso XI): "órgano o entidad que, total o parcialmente, vela por el almacenamiento, la operación, la administración y la preservación de datos recolectados por la administración pública federal, que no le pertenecen, pero que están bajo su custodia". Es el rol más cercano a TI.
- Gobierno de datos (inciso XV): "ejercicio de autoridad y control que permite la gestión de datos desde las perspectivas del intercambio, la arquitectura, la seguridad, la calidad, la operación y otros aspectos tecnológicos".
Fíjese en la frase del custodio: los datos "no le pertenecen". Resguardar el dato no convierte a nadie en su dueño.
La segunda referencia es el glosario del NIST, el instituto de estándares del gobierno de Estados Unidos, enfocado en seguridad de la información. Una de sus definiciones de data steward (tomada de la norma CNSSI 4009-2022) indica que el steward responde, dentro de un área temática asignada, por mantener nombres de datos, definiciones de negocio, reglas de integridad y valores de dominio, por analizar y mejorar la calidad de los datos y por identificar y resolver los problemas relacionados.
Llevado a los datos maestros: el steward es quien sabe por qué existe el campo, qué valores acepta y qué hacer cuando llega mal. Si todavía confunde gobierno con gestión de datos, conviene leer antes la diferencia entre gestión de datos y gobierno de datos.
¿En qué se diferencian owner, steward, equipo de datos maestros y TI?
Son cuatro roles. Cuando dos de ellos se mezclan, la decisión desaparece.
| Rol | Qué hace | Qué no hace | Quién suele ocuparlo |
|---|---|---|---|
| Data owner | Decide y responde por el resultado del dominio. Aprueba reglas, excepciones y cambios sensibles. | No captura registros ni revisa caso por caso. | Un líder del área que más sufre cuando el dato llega mal. |
| Data steward | Escribe y mantiene reglas, atributos y valores permitidos. Analiza problemas de calidad y propone correcciones. | No aprueba solo lo que afecta dinero, riesgo o procesos de otra área. | Un especialista de negocio del dominio, con tiempo asignado para ello. |
| Equipo de datos maestros y solicitante | El solicitante pide con justificación. El equipo revisa, crea y modifica registros siguiendo la regla. | No inventa reglas sobre la marcha ni aprueba sus propias solicitudes. | El equipo de datos maestros y usuarios de cada área. |
| TI o custodio | Resguarda, opera y protege el sistema. Configura validaciones, accesos e historial de cambios. | No decide qué valor es correcto ni quién puede aprobar. | Equipos de sistemas, ERP e infraestructura. |
¿Quién decide qué en materiales, proveedores y clientes?
Las tablas siguientes son un punto de partida. El área que asume cada rol cambia de una empresa a otra. La lógica de separar decidir, cuidar, ejecutar y operar no cambia.
Materiales
El owner suele venir de quien responde por el uso del artículo: ingeniería o planeación para materiales productivos, mantenimiento para repuestos y artículos MRO. Los duplicados son el dolor típico de este dominio, y saber cómo identificar materiales duplicados ayuda al steward a escribir la regla.
| Tipo de decisión | Data owner | Data steward | Equipo de datos maestros y solicitante | TI o custodio |
|---|---|---|---|---|
| Definir atributo y regla | Aprueba el estándar descriptivo y los campos obligatorios por tipo de material | Escribe el estándar, los valores permitidos y la regla de duplicados | Avisa cuando la regla no encaja en un caso real | Configura campos y validaciones |
| Crear registro | No interviene caso por caso | Revisa los casos fuera del estándar | El solicitante pide con justificación; el equipo revisa duplicados y crea | Mantiene sistema y accesos |
| Aprobar excepción | Aprueba un artículo fuera del estándar o una creación urgente | Analiza y recomienda | Registra la excepción y el motivo | Libera solo después de la aprobación |
| Cambio sensible | Aprueba un cambio de unidad de medida o de tipo de material con inventario o pedidos abiertos | Evalúa el impacto en las áreas | Ejecuta después de la aprobación | Guarda el historial del cambio |
| Bloquear o inactivar | Define el criterio de bloqueo | Identifica candidatos y duplicados | Ejecuta el bloqueo | Ejecuta bloqueos masivos cuando se solicitan |
| Seguir indicador | Da seguimiento y responde por el resultado | Mide y explica la causa | Corrige los pendientes | Entrega la extracción de datos |
Proveedores
Aquí el dolor rara vez son los duplicados, porque la identificación fiscal suele amarrar el registro. El dolor es el proveedor sin homologar, el documento vencido, la situación registral que no coincide con el registro fiscal oficial y el cambio bancario sin dueño. Un esquema frecuente: compras es owner de la relación y de la homologación, y finanzas es owner del grupo de datos bancarios y de pago.
| Tipo de decisión | Data owner | Data steward | Equipo de datos maestros y solicitante | TI o custodio |
|---|---|---|---|---|
| Definir atributo y regla | Compras aprueba los criterios de homologación; finanzas aprueba las reglas de datos bancarios | Define documentos exigidos, vigencia y campos obligatorios | Avisa cuando un documento no existe para ese tipo de proveedor | Configura validaciones y consultas automáticas |
| Crear registro | No interviene caso por caso | Revisa los casos con pendientes | El comprador solicita; el equipo revisa documentos y situación registral y crea | Mantiene sistema y accesos |
| Aprobar excepción | Compras aprueba un proveedor de emergencia con documento pendiente | Define el plazo y las condiciones de la excepción | Registra la excepción y da seguimiento | Libera solo después de la aprobación |
| Cambio sensible | Finanzas aprueba el cambio de cuenta bancaria | Define cómo confirmar el cambio con el proveedor | Ejecuta después de la confirmación; quien solicita no aprueba | Asegura que quien modifica no sea quien aprueba |
| Bloquear o inactivar | Compras define el criterio por documento vencido o falta de uso | Identifica los casos | Ejecuta el bloqueo | Ejecuta bloqueos masivos cuando se solicitan |
| Seguir indicador | Cada owner da seguimiento y responde por su grupo de datos | Mide y explica la causa | Corrige los pendientes | Entrega la extracción de datos |
Clientes
El owner suele ser el área comercial para los datos de relación y venta, y crédito o finanzas para límite de crédito, condiciones de pago y bloqueo por morosidad. Si su empresa usa SAP S/4HANA, conviene leer sobre los datos maestros de business partner en S/4HANA antes de dividir los roles entre proveedores y clientes.
| Tipo de decisión | Data owner | Data steward | Equipo de datos maestros y solicitante | TI o custodio |
|---|---|---|---|---|
| Definir atributo y regla | Comercial aprueba los campos de venta; crédito aprueba las reglas de límite y condiciones de pago | Define campos obligatorios por tipo de cliente y valores permitidos | Avisa cuando el vendedor no logra obtener la información | Configura validaciones y perfiles de acceso |
| Crear registro | No interviene caso por caso | Revisa los casos fuera del estándar | El vendedor solicita; el equipo revisa y crea | Mantiene sistema y accesos |
| Aprobar excepción | Comercial aprueba vender a un cliente con registro incompleto | Define qué puede faltar y por cuánto tiempo | Registra la excepción | Libera solo después de la aprobación |
| Cambio sensible | Crédito aprueba el cambio de límite de crédito | Define la evidencia exigida | Ejecuta después de la aprobación; quien solicita no aprueba | Guarda el historial del cambio |
| Bloquear o inactivar | Crédito decide el bloqueo por riesgo; comercial decide la inactivación por falta de uso | Identifica los casos | Ejecuta el bloqueo | Ejecuta bloqueos masivos cuando se solicitan |
| Seguir indicador | Cada owner da seguimiento y responde por su grupo de datos | Mide y explica la causa | Corrige los pendientes | Entrega la extracción de datos |
Gobernar un dominio a la vez o todos juntos cambia cuántos owners necesita. El artículo sobre MDM de un dominio o multidominio ayuda en esa decisión.
¿Cómo elegir el data owner de cada dominio?
Elija a quien sufre el error y responde por el proceso. No elija a quien captura.
- ¿Quién pierde cuando el dato llega mal? Un pago a la cuenta equivocada es una pérdida de finanzas. Una pieza comprada dos veces es una pérdida de compras y mantenimiento.
- ¿Quién tiene autoridad para decir que no? El owner debe poder rechazar una excepción que pide otra área.
- ¿Quién tiene tiempo para decidir? Un owner que tarda semanas en aprobar se vuelve un cuello de botella, y el equipo de datos maestros empieza a decidir en su lugar.
- ¿Quién responde por el indicador? Si la calidad del dominio empeora, es esa persona quien tiene que explicarlo.
¿Qué señales muestran que los roles están mal definidos?
- Cada excepción sale por correo a varias personas y nadie responde.
- El equipo de datos maestros decide valores de campo porque no tiene a quién preguntar.
- Quien pide el cambio también lo aprueba.
- La regla de llenado está en la cabeza de una persona y no está escrita.
- Después de un error, la discusión es sobre quién capturó, y no sobre quién debió decidir.
¿Cuáles son los errores más comunes al dividir los roles?
- TI como dueña del dato. TI resguarda y opera. No sabe si la cuenta bancaria es del proveedor ni si el límite de crédito tiene sentido.
- Owner sin tiempo. El cargo es alto, pero la persona nunca aprueba nada. Las decisiones terminan en manos de quien ejecuta.
- Steward sin autoridad. Escribe la regla, pero nadie está obligado a seguirla.
- Un owner para todo. Una sola persona no domina materiales, proveedores y clientes a la vez.
- Un comité que decide todo. El comité sirve para conflictos entre áreas, no para aprobar cada excepción.
Ejemplo hipotético: cambio de cuenta bancaria con roles definidos
Ejemplo hipotético, solo para ilustrar. Una empresa industrial recibe 40 solicitudes de cambio bancario de proveedores al mes. Nombra al gerente de cuentas por pagar como owner de los datos bancarios y a un analista sénior de finanzas como steward.
- El steward escribe la regla: todo cambio de cuenta exige una carta del proveedor y una confirmación telefónica a un número que ya estaba en el registro antes de la solicitud.
- El owner aprueba la regla y establece que un cambio bancario nunca se trata como urgente.
- El equipo de datos maestros solo ejecuta solicitudes con las dos evidencias, después de la aprobación de alguien de cuentas por pagar designado por el owner, que no puede ser quien solicitó.
- TI configura el sistema para que el usuario que modifica sea distinto del que aprueba y guarda el historial de cada cambio.
- Cada mes, el steward muestra al owner cuántas solicitudes llegaron, cuántas se rechazaron y por qué.
La cifra es ilustrativa. Lo importante es que, si el correo falso del inicio llegara aquí, habría un dueño claro para detenerlo.
¿Por dónde empezar?
- Elija un dominio y un tipo de decisión que ya haya causado problemas, como el cambio bancario de proveedores o la creación de materiales.
- Liste quién decide hoy, quién ejecuta y quién solo recibe aviso. Escriba lo que pasa de verdad, no lo que debería pasar.
- Nombre un owner y un steward para ese recorte, con nombre y cargo.
- Escriba la regla en una página y lleve al sistema todo lo que pueda validarse.
- Elija un indicador simple para que el owner le dé seguimiento. Hay una guía sobre cómo medir la calidad de los datos maestros.
- Pase al siguiente dominio cuando el primero ya esté funcionando.
Si no sabe dónde está el mayor problema, un diagnóstico de la base de datos maestros muestra dónde se concentra antes de diseñar los roles. Una política mínima, un comité e indicadores mensuales vienen después, cada uno a su tiempo.
Preguntas frecuentes
¿Una persona puede ser data owner y data steward al mismo tiempo?
Sí, en una empresa pequeña o en un dominio con poco volumen. El cuidado es no permitir que la misma persona apruebe lo que ella misma propuso en cambios sensibles. En esos casos, otra persona debe revisar.
¿El data owner tiene que ser director?
No. Necesita autoridad sobre el proceso y tiempo para decidir. Un gerente que responde por el resultado del dominio suele funcionar mejor que un director que nunca abre las aprobaciones.
¿Cuántos data stewards necesita cada dominio?
Depende del volumen y la variedad. Un dominio puede tener un steward por grupo de datos, como datos bancarios y datos de homologación en proveedores. Lo que no puede haber es un grupo de datos sin ningún steward.
¿Un key user es lo mismo que un data steward?
No necesariamente. El key user domina el uso del sistema y capacita a las personas. El steward responde por la regla del dato. A veces es la misma persona, pero las responsabilidades son distintas.
¿Qué cambia cuando el cliente es una persona física?
Los datos personales exigen cuidado sobre quién puede verlos y modificarlos. El owner aprueba quién tiene acceso, el steward define qué campos son realmente necesarios y TI aplica los perfiles de acceso.
¿Qué hacer cuando el data owner deja la empresa o cambia de área?
Registre al owner por cargo, además del nombre, y nombre un sustituto antes de la salida, para que las aprobaciones no se detengan.
Cómo 4MDG puede ayudar
Un cambio bancario sin dueño suele aparecer junto con una base desordenada. Limpiar de nuevo no resuelve si no hay política, roles definidos ni indicadores con seguimiento. 4MDG ofrece un diagnóstico gratuito, sujeto a evaluación de aplicabilidad y disponibilidad, sobre un recorte real de su base de materiales, proveedores y clientes: usted envía una muestra en hoja de cálculo o extracción, y no se instala nada en su entorno. En MDM Engineering, los roles de data owner y data steward se definen en una matriz RACI, atributo por atributo y etapa por etapa, junto con el modelo operativo del equipo de datos maestros. Si quiere conversar sobre su caso, contáctenos.
Fuentes
Los criterios de este artículo son recomendaciones de práctica, no exigencias legales para empresas privadas.
- Presidencia de la República de Brasil. Decreto nº 10.046, del 9 de octubre de 2019, artículo 2. https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2019/decreto/d10046.htm. Consultado el 16/10/2026.
- NIST, Computer Security Resource Center. Glossary: data steward (fuente: CNSSI 4009-2022). https://csrc.nist.gov/glossary/term/data_steward. Consultado el 16/10/2026.