Data owner e data steward no cadastro: quem decide o quê por domínio

O data owner é quem decide e responde pelo dado de um domínio: aprova regras, exceções e alterações sensíveis. O data steward cuida dessas regras no dia a dia: define atributos, valores permitidos e trata os problemas de qualidade. A central de cadastro executa, e a TI guarda e opera o sistema, sem ser dona do dado.

Chega um e-mail pedindo para trocar a conta bancária de um fornecedor. A analista da central abre o cadastro, troca banco, agência e conta, e o pagamento da semana sai para a conta nova. Semanas depois o fornecedor liga cobrando. A conta nova não era dele.

Aí começa a reunião. Compras diz que dado bancário é com o financeiro. O financeiro diz que cadastro é com a central. A central diz que só executou o que pediram. A TI mostra o log: o campo foi alterado por um usuário com permissão. Todo mundo fez a sua parte, e ninguém tinha a decisão. É isso que a divisão entre data owner e data steward resolve.

O que é data owner e o que é data steward?

Não existe uma lei que defina esses papéis para empresas privadas. Mas há duas referências públicas que ajudam a separar as coisas.

A primeira é o Decreto nº 10.046/2019, que trata da governança de dados na administração pública federal. Ele vale para órgãos federais, não para empresas. Uso aqui só como referência conceitual, porque ele separa bem quem governa o dado de quem guarda o dado. No art. 2º:

• Gestor de dados (inciso XIII): "órgão ou entidade responsável pela governança de determinado conjunto de dados". É o papel mais próximo do data owner.
• Custodiante de dados (inciso XI): "órgão ou entidade que, total ou parcialmente, zela pelo armazenamento, pela operação, pela administração e pela preservação de dados, coletados pela administração pública federal, que não lhe pertencem, mas que estão sob sua custódia". É o papel mais próximo da TI.
• Governança de dados (inciso XV): "exercício de autoridade e controle que permite o gerenciamento de dados sob as perspectivas do compartilhamento, da arquitetura, da segurança, da qualidade, da operação e de outros aspectos tecnológicos".

Repare na frase do custodiante: os dados "não lhe pertencem". Guardar o dado não faz de ninguém o dono dele.

A segunda referência é o glossário do NIST, instituto de padrões do governo dos Estados Unidos, voltado à segurança da informação. Uma das definições de data steward ali (vinda da norma CNSSI 4009-2022) diz que o steward responde, dentro de uma área de assunto atribuída a ele, por manter nomes de dados, definições de negócio, regras de integridade e valores de domínio, por analisar e melhorar a qualidade dos dados e por identificar e resolver os problemas relacionados.

Traduzindo para o cadastro: o steward é quem sabe por que o campo existe, quais valores ele aceita e o que fazer quando vem errado. Se você ainda mistura governança com gestão de dados, vale ler antes a diferença entre gestão de dados e governança.

Qual a diferença entre owner, steward, central de cadastro e TI?

São quatro papéis. Quando dois deles se misturam, a decisão some.

Papel	O que faz	O que não faz	Quem costuma ser
Data owner	Decide e responde pelo resultado do domínio. Aprova regra, exceção e alteração sensível.	Não digita cadastro nem analisa caso a caso.	Liderança da área que mais sofre quando o dado vem errado.
Data steward	Escreve e mantém as regras, os atributos e os valores permitidos. Analisa problemas de qualidade e propõe correções.	Não aprova sozinho o que mexe com dinheiro, risco ou processo de outra área.	Especialista de negócio do domínio, com tempo reservado para isso.
Central de cadastro e solicitante	O solicitante pede com justificativa. A central confere, cadastra e altera seguindo a regra.	Não cria regra nova no improviso nem aprova o próprio pedido.	Equipe de cadastro e usuários das áreas.
TI ou custodiante	Guarda, opera e protege o sistema. Configura validações, acessos e histórico de alterações.	Não decide qual valor está certo nem quem pode aprovar.	Time de sistemas, ERP e infraestrutura.

Quem decide o quê em materiais, fornecedores e clientes?

As tabelas abaixo são um ponto de partida. A área que assume cada papel muda de empresa para empresa. A lógica de separar decidir, cuidar, executar e operar não muda.

Materiais

O owner costuma sair de quem responde pelo uso do item: engenharia ou planejamento para material produtivo, manutenção para peças e itens de MRO. Duplicidade é a dor típica deste domínio, e ver como identificar materiais duplicados ajuda o steward a escrever a regra.

Tipo de decisão	Data owner	Data steward	Central e solicitante	TI ou custodiante
Definir atributo e regra	Aprova o padrão descritivo e os campos obrigatórios por tipo de material	Escreve o padrão, os valores permitidos e a regra de duplicidade	Avisa quando a regra não cabe no caso real	Configura campos e validações
Criar registro	Não entra caso a caso	Analisa os casos fora do padrão	Solicitante pede com justificativa; central confere duplicidade e cadastra	Mantém sistema e acessos
Aprovar exceção	Aprova item fora do padrão ou cadastro urgente	Analisa e recomenda	Registra a exceção e o motivo	Libera só depois da aprovação
Alteração sensível	Aprova mudança de unidade de medida ou de tipo de material com estoque ou pedido aberto	Avalia o impacto nas áreas	Executa depois de aprovado	Guarda o histórico da alteração
Bloquear ou inativar	Define o critério de bloqueio	Levanta os candidatos e os duplicados	Executa o bloqueio	Roda o bloqueio em massa quando pedido
Acompanhar indicador	Cobra e responde pelo resultado	Mede e explica a causa	Corrige as pendências	Fornece a extração

Fornecedores

Aqui a dor raramente é duplicidade, porque o CNPJ já amarra o registro. A dor é fornecedor sem homologação, documento vencido, situação cadastral do CNPJ que não confere com a Receita Federal e alteração bancária sem dono. Um caminho comum: compras é owner do relacionamento e da homologação, e o financeiro é owner do grupo de dados bancários e de pagamento. Para o lado de compras, existe um guia de governança de dados mestres em compras.

Tipo de decisão	Data owner	Data steward	Central e solicitante	TI ou custodiante
Definir atributo e regra	Compras aprova os critérios de homologação; financeiro aprova as regras de dados bancários	Define documentos exigidos, validade e campos obrigatórios	Avisa quando um documento não existe para aquele tipo de fornecedor	Configura validações e consultas automáticas
Criar registro	Não entra caso a caso	Analisa os casos com pendência	Comprador solicita; central confere documentos e situação cadastral e cadastra	Mantém sistema e acessos
Aprovar exceção	Compras aprova fornecedor emergencial com documento pendente	Define o prazo e a condição da exceção	Registra a exceção e cobra a regularização	Libera só depois da aprovação
Alteração sensível	Financeiro aprova troca de conta bancária	Define como confirmar a troca com o fornecedor	Executa depois da confirmação; quem pede não aprova	Garante que quem altera não seja quem aprova
Bloquear ou inativar	Compras define critério por documento vencido ou falta de uso	Levanta os casos	Executa o bloqueio	Roda o bloqueio em massa quando pedido
Acompanhar indicador	Cobram e respondem pelo resultado de cada grupo de dados	Mede e explica a causa	Corrige as pendências	Fornece a extração

Clientes

O owner costuma ser comercial para os dados de relacionamento e venda, e crédito ou financeiro para limite, condição de pagamento e bloqueio por inadimplência. Se a empresa usa SAP S/4HANA, vale ler sobre o cadastro de business partner no S/4HANA antes de dividir os papéis entre fornecedor e cliente.

Tipo de decisão	Data owner	Data steward	Central e solicitante	TI ou custodiante
Definir atributo e regra	Comercial aprova campos de venda; crédito aprova regras de limite e condição de pagamento	Define campos obrigatórios por tipo de cliente e valores permitidos	Avisa quando o vendedor não consegue a informação	Configura validações e perfis de acesso
Criar registro	Não entra caso a caso	Analisa os casos fora do padrão	Vendedor solicita; central confere e cadastra	Mantém sistema e acessos
Aprovar exceção	Comercial aprova venda para cliente com cadastro incompleto	Define o que pode faltar e por quanto tempo	Registra a exceção	Libera só depois da aprovação
Alteração sensível	Crédito aprova mudança de limite de crédito	Define a evidência exigida	Executa depois de aprovado; quem pede não aprova	Guarda o histórico da alteração
Bloquear ou inativar	Crédito decide bloqueio por risco; comercial decide inativação por falta de uso	Levanta os casos	Executa o bloqueio	Roda o bloqueio em massa quando pedido
Acompanhar indicador	Cobram e respondem pelo resultado de cada grupo de dados	Mede e explica a causa	Corrige as pendências	Fornece a extração

Se a sua empresa governa um domínio de cada vez ou todos juntos, isso muda quantos owners você precisa. O artigo sobre MDM de um domínio ou multidomínio ajuda nessa decisão.

Como escolher o data owner de cada domínio?

Escolha quem sofre o erro e responde pelo processo. Não escolha quem digita.

• Quem perde quando o dado vem errado? Pagamento na conta errada é perda do financeiro. Peça comprada em duplicidade é perda de suprimentos e manutenção.
• Quem tem autoridade para dizer não? O owner precisa conseguir negar uma exceção pedida por outra área.
• Quem tem tempo para decidir? Owner que demora semanas para aprovar vira gargalo, e a central começa a decidir no lugar dele.
• Quem responde pelo indicador? Se a qualidade do domínio piorar, é essa pessoa que precisa explicar.

Quais sinais mostram que os papéis estão mal definidos?

• Toda exceção sobe por e-mail para várias pessoas e ninguém responde.
• A central de cadastro decide valor de campo porque não tem a quem perguntar.
• Quem pede a alteração também aprova.
• A regra de preenchimento está na cabeça de uma pessoa e não está escrita.
• Depois de um erro, a discussão é sobre quem digitou, e não sobre quem deveria ter decidido.

Quais são os erros mais comuns ao dividir os papéis?

• TI como dona do dado. A TI guarda e opera. Não sabe se a conta bancária é do fornecedor nem se o limite de crédito faz sentido.
• Owner sem tempo. O cargo é alto, mas a pessoa nunca aprova nada. As decisões acabam na mão de quem executa.
• Steward sem autoridade. Escreve a regra, mas ninguém é obrigado a seguir.
• Um owner para tudo. Uma pessoa só não domina material, fornecedor e cliente ao mesmo tempo.
• Comitê decidindo tudo. O comitê serve para conflito entre áreas, não para aprovar cada exceção.

Exemplo hipotético: troca de conta bancária com papéis definidos

Exemplo hipotético, para ilustrar. Uma indústria recebe 40 pedidos de alteração bancária de fornecedores por mês. Ela define o gerente de contas a pagar como owner dos dados bancários e um analista sênior de financeiro como steward.

1. O steward escreve a regra: toda troca de conta exige carta do fornecedor e confirmação por telefone em número que já estava no cadastro antes do pedido.
2. O owner aprova a regra e define que alteração bancária nunca é tratada como urgência.
3. A central executa só pedidos com as duas evidências, depois da aprovação de alguém de contas a pagar designado pelo owner, que não pode ser quem solicitou.
4. A TI configura o sistema para que o usuário que altera seja diferente do que aprova e guarda o histórico de cada mudança.
5. Por mês, o steward mostra ao owner quantos pedidos chegaram, quantos foram recusados e por quê.

O número é ilustrativo. O que importa é que, se o e-mail falso da abertura chegasse aqui, teria um dono claro para barrar.

Por onde começar?

1. Escolha um domínio e um tipo de decisão que já causou problema, como alteração bancária de fornecedor ou criação de material.
2. Liste quem hoje decide, quem executa e quem só é avisado. Escreva o que acontece de verdade, não o que deveria acontecer.
3. Nomeie um owner e um steward para esse recorte, com nome e cargo.
4. Escreva a regra em uma página e coloque no sistema o que puder ser validado.
5. Escolha um indicador simples para o owner acompanhar. Há um guia de como medir a qualidade do cadastro.
6. Expanda para o próximo domínio depois que o primeiro estiver rodando.

Se você não sabe por onde está o maior problema, um diagnóstico da base de cadastro mostra onde a sujeira se concentra antes de você desenhar os papéis. Política mínima, comitê e indicadores mensais vêm depois, cada um no seu tempo.

Perguntas frequentes

Uma pessoa pode ser data owner e data steward ao mesmo tempo?

Pode, em empresa pequena ou num domínio com pouco volume. O cuidado é não deixar a mesma pessoa aprovar o que ela mesma propôs em alterações sensíveis. Nesses casos, outra pessoa precisa revisar.

O data owner precisa ser diretor?

Não. Precisa ter autoridade sobre o processo e tempo para decidir. Um gerente que responde pelo resultado do domínio costuma funcionar melhor que um diretor que nunca abre as aprovações.

Quantos data stewards cada domínio precisa?

Depende do volume e da variedade. Um domínio pode ter um steward por grupo de dados, como dados bancários e dados de homologação em fornecedores. O que não pode é um grupo de dados sem steward nenhum.

Key user é a mesma coisa que data steward?

Não necessariamente. O key user domina o uso do sistema e treina as pessoas. O steward responde pela regra do dado. Às vezes é a mesma pessoa, mas são responsabilidades diferentes. O papel do key user está detalhado em key users e software de MDM.

O que muda quando o cliente é pessoa física?

Os dados pessoais pedem cuidado com quem pode ver e alterar. O owner aprova quem tem acesso, o steward define quais campos são realmente necessários e a TI aplica os perfis de acesso.

O que fazer quando o data owner sai da empresa ou muda de área?

Registre o owner pelo cargo, além do nome, e nomeie um substituto antes da saída, para que as aprovações não fiquem paradas.

Como a 4MDG pode ajudar

A troca de conta bancária sem dono costuma aparecer junto com base suja. Limpar de novo não resolve se não existe política, papel definido nem indicador acompanhado. A 4MDG faz um diagnóstico gratuito, sujeito à avaliação de aplicabilidade e disponibilidade, sobre um recorte real da base de materiais, fornecedores e clientes: você envia uma amostra em planilha ou extração, e nada é instalado no seu ambiente. No MDM Engineering, os papéis de data owner e data steward são definidos em matriz RACI, atributo e etapa por etapa, junto com o modelo da Central de Cadastro. Se quiser conversar sobre o seu caso, fale com a gente.

Fontes

Os critérios deste artigo são recomendação de prática, não exigência legal para empresas privadas.

• Presidência da República. Decreto nº 10.046, de 9 de outubro de 2019, art. 2º. https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2019/decreto/d10046.htm. Acesso em 16/10/2026.
• NIST, Computer Security Resource Center. Glossary: data steward (fonte: CNSSI 4009-2022). https://csrc.nist.gov/glossary/term/data_steward. Acesso em 16/10/2026.