Enunciado
A equipe de Governança do Bytebank compilou três artefatos que representam o estado atual das práticas fundamentais: uma entrada do catálogo de dados, um trecho do glossário corporativo e uma matriz de papéis e responsabilidades. A diretoria quer saber se esses artefatos estão em condições de sustentar as iniciativas planejadas para o próximo ano (qualidade de dados, produtos de dados e expansão de IA).
Artefato 1 — Entrada do catálogo de dados: tabela clientes_v3_final
| Campo | Valor |
|---|---|
| Nome do ativo | clientes_v3_final |
| Descrição | Tabela de clientes |
| Sistema de origem | — |
| Data Owner | Área de Negócios |
| Data Steward | (não preenchido) |
| Classificação de sensibilidade | (não preenchido) |
| Metadados de negócio | (não preenchido) |
| Metadados técnicos | Banco: Azure SQL. Colunas: id_cli, nm, dt_nasc, cpf, email, seg, score_cred, dt_ult_trans, flag_pep |
| Linhagem | (não preenchido) |
| Consumidores conhecidos | Área de Crédito |
| Última atualização do registro | 14/01/2026 |
Escala de classificação vigente no Bytebank: Pública, Interna, Confidencial e Restrita.
Artefato 2 — Trecho do glossário corporativo
| Termo | Definição | Responsável | Data de revisão |
|---|---|---|---|
| Cliente ativo | Pessoa que possui conta aberta no Bytebank | Área Comercial | 10/03/2025 |
| Cliente ativo | Pessoa que realizou ao menos uma transação nos últimos 12 meses | Área de Dados | 15/06/2025 |
| Score de crédito | Pontuação que indica a probabilidade de inadimplência | (não preenchido) | (não preenchido) |
| PEP | Pessoa politicamente exposta | Compliance | 02/02/2026 |
| Receita líquida | Receita total menos impostos e devoluções | Finanças | 01/08/2025 |
Política do glossário: cada termo deve ser revisado ao menos uma vez por ano.
Artefato 3 — Matriz de papéis e responsabilidades (governança de dados)
| Papel | Pessoa/Área designada | Responsabilidades documentadas |
|---|---|---|
| Data Owner — Clientes | “Área de Negócios” | Aprovar acessos; garantir qualidade |
| Data Owner — Transações | Gerência de Operações | Aprovar acessos |
| Data Steward — Clientes | (vago) | — |
| Data Steward — Transações | Ana Luísa (Engenharia de Dados) | Manter metadados; criar regras de qualidade |
| Technical Data Steward — Clientes | Carlos (DBA) | Backup e performance |
| CDO (Chief Data Officer) | Reporta à VP de Tecnologia | Responder em última instância perante reguladores |
| Comitê de Dados | Reunião trimestral | Aprovar políticas |
| Pessoa consumidora de dados | (não mapeado) | — |
Pergunta-chave: “Os artefatos fundamentais de governança do Bytebank estão em condições de sustentar iniciativas de qualidade de dados, produtos de dados e expansão de IA no próximo ano?”
Sua missão:
- Leia cada artefato com atenção e registre, por escrito, sua própria avaliação: quais elementos estão adequados, quais apresentam fragilidades e qual a gravidade de cada fragilidade para as iniciativas planejadas. Priorize — nem tudo tem o mesmo peso.
- Para cada problema priorizado, justifique por que ele é um problema, referenciando um conceito ou princípio estudado nos cursos deste nível.
- Depois de concluir seu diagnóstico, submeta os três artefatos a um assistente de IA generativa com um prompt estruturado (por exemplo: “Analise estes artefatos de governança de dados de um banco digital e aponte fragilidades à luz do DAMA-DMBOK e de boas práticas de catálogo, glossário e ownership”). Compare a leitura da IA com a sua: o que a IA identificou que você não havia notado? Onde a IA foi genérica ou imprecisa? Registre o que você manteve, o que incorporou e o que descartou da análise da IA, explicando o porquê. Os artefatos deste case são fictícios; numa organização real, verifique a política de uso de IA da empresa antes de submeter documentos internos a um assistente externo.
Entregáveis sugeridos: Parecer escrito com os problemas priorizados e justificados; versão corrigida da entrada de catálogo e do glossário (escritas dentro do próprio documento de análise); registro da comparação com a leitura da IA.
O que caracteriza uma boa análise:
- O parecer avalia, para cada papel da matriz e para cada ativo, se a atribuição permite saber quem decide, quem executa e a quem recorrer, e se as responsabilidades descritas correspondem ao papel?
- A análise verifica, termo a termo, se a definição do glossário é única, precisa o bastante para ser calculada, tem responsável e está vigente?
- O parecer avalia se os metadados são suficientes para que alguém que não conhece a tabela consiga localizá-la, compreendê-la e confiar nela?
- A análise avalia se a classificação dos dados está presente e coerente com a natureza de cada coluna, distinguindo dados pessoais de dados pessoais sensíveis e justificando o enquadramento?
- Cada problema priorizado tem gravidade declarada com critério explícito (impacto em clientes, exposição regulatória, iniciativa bloqueada), e a ordem de prioridade é defensável?
Ferramentas: Assistente de IA generativa, Editor de documentos ou planilhas.
Dicas para a análise da 1ª etapa:
- Releia os conceitos de metadados de negócio versus metadados técnicos e pergunte-se: se uma pessoa analista de outra área encontrasse essa entrada no catálogo, conseguiria entender o que a tabela contém e para que serve?
- Para cada termo do glossário, pergunte-se: duas pessoas de áreas diferentes, usando só este glossário, chegariam ao mesmo número num indicador? A definição é precisa, tem responsável e está vigente?
- Para cada papel da matriz, imagine um incidente concreto (um acesso indevido, um dado errado num relatório regulatório): a matriz permite saber quem é acionado e quem decide?
1. Parecer de Avaliação
A pergunta-chave é: os artefatos fundamentais de governança do Bytebank estão em condições de sustentar iniciativas de qualidade de dados, produtos de dados e expansão de IA no próximo ano?
Resposta curta: não. Os três artefatos apresentam fragilidades estruturais que bloqueiam as três iniciativas planejadas. Não são problemas cosméticos de preenchimento — são falhas que impedem a responsabilização, o cálculo consistente de indicadores e a conformidade regulatória.
Abaixo, a avaliação por artefato, com priorização e justificativa conceitual.
2. Avaliação do Artefato 1 — Entrada do Catálogo (clientes_v3_final)
2.1. Elementos adequados
- O ativo existe e está nomeado (
clientes_v3_final) — há um mínimo de inventário. - Há metadados técnicos (banco, colunas), o que permite localização técnica básica.
- Há consumidor conhecido (Área de Crédito) e data de atualização do registro.
2.2. Fragilidades identificadas e gravidade
| # | Fragilidade | Gravidade | Justificativa |
|---|---|---|---|
| 1 | Data Owner = “Área de Negócios” (genérico, não uma pessoa/papel nomeado) | Crítica | Sem owner nomeado, não há accountability. A trilha é explícita: “Data Owner é um profissional de negócio que toma decisões sobre os dados”. “Área de Negócios” não decide, não aprova acesso, não responde a reguladores. Bloqueia qualidade, produtos de dados e IA. |
| 2 | Classificação de sensibilidade ausente | Crítica | A tabela contém cpf, email, dt_nasc e flag_pep. São dados pessoais (CPF, e-mail, data de nascimento) e flag_pep é dado pessoal sensível por implicação (PEP relaciona-se a exposição política). Sem classificação, não há base para controle de acesso, LGPD ou uso em IA. Exposição regulatória direta. |
| 3 | Metadados de negócio ausentes | Alta | A descrição “Tabela de clientes” não explica o que a tabela contém, para que serve, quais regras de negócio se aplicam. A trilha alerta: “sem metadados, o catálogo vira uma lista de tabelas”. Uma pessoa de outra área não consegue usar a tabela com confiança. Bloqueia produtos de dados e IA. |
| 4 | Linhagem ausente | Alta | Não se sabe de onde vêm os dados, como foram transformados. A auditoria externa já apontou fragilidade de rastreabilidade. Sem linhagem, não se responde a incidentes nem à LGPD. Bloqueia conformidade e IA. |
| 5 | Sistema de origem ausente | Média/Alta | Sem origem, não se investiga causa raiz de problemas de qualidade. |
| 6 | Data Steward não preenchido | Alta | Sem steward, não há quem mantenha metadados, crie regras de qualidade e esclareça dúvidas. |
| 7 | Nome do ativo clientes_v3_final |
Média | Nome técnico, não business-friendly. A trilha recomenda nomes amigáveis ao negócio. “v3_final” indica versionamento informal e falta de padrão. |
2.3. Versão corrigida da entrada de catálogo (proposta)
| Campo | Valor corrigido |
|---|---|
| Nome do ativo | Clientes (Cadastro de Clientes) |
| Descrição | Tabela mestre com o cadastro de clientes pessoa física do Bytebank, contendo dados cadastrais, segmentação e indicadores de crédito. |
| Sistema de origem | [a levantar com Engenharia de Dados — provável CRM ou sistema de cadastro] |
| Data Owner | [a levantar com Diretoria de Crédito/Negócios — pessoa nomeada, com autoridade] |
| Data Steward | [a levantar com área de negócio — pessoa com conhecimento de domínio] |
| Technical Data Steward | Carlos (DBA) — já designado |
| Classificação de sensibilidade | Confidencial (dados pessoais: CPF, e-mail, data de nascimento) com coluna flag_pep classificada como Restrita (dado pessoal sensível por implicação). |
| Metadados de negócio | Definição de “cliente” (ver glossário); regra de “cliente ativo”; significado de seg (segmento); score_cred (ver glossário); flag_pep (ver glossário). |
| Metadados técnicos | Banco: Azure SQL. Colunas: id_cli (PK), nm, dt_nasc, cpf, email, seg, score_cred, dt_ult_trans, flag_pep. |
| Linhagem | [a levantar com Engenharia de Dados — pipeline de origem] |
| Consumidores conhecidos | Área de Crédito; [a levantar com Governança — mapear demais consumidores] |
| Última atualização do registro | 14/01/2026 |
3. Avaliação do Artefato 2 — Glossário Corporativo
3.1. Elementos adequados
- Existe um glossário com termos e responsáveis (embora incompletos).
- Há política de revisão anual declarada.
3.2. Fragilidades identificadas e gravidade
| # | Fragilidade | Gravidade | Justificativa |
|---|---|---|---|
| 1 | “Cliente ativo” com DUAS definições conflitantes | Crítica | Uma definição (Comercial, 10/03/2025) diz “conta aberta”; outra (Dados, 15/06/2025) diz “transação nos últimos 12 meses”. Duas pessoas de áreas diferentes, usando o glossário, chegam a números diferentes. Isso viola o princípio de definição única. Bloqueia qualidade, produtos de dados e IA (indicadores inconsistentes). |
| 2 | “Score de crédito” sem responsável e sem data de revisão | Alta | Termo central para crédito e IA, sem dono nem vigência. Não se sabe quem decide sobre a definição. Bloqueia IA de crédito. |
| 3 | Definições imprecisas para cálculo | Alta | “Cliente ativo: pessoa que possui conta aberta” — conta aberta há quanto tempo? Conta encerrada conta? “Pessoa que realizou ao menos uma transação nos últimos 12 meses” — que tipo de transação? Inclui transferência interna? A definição precisa ser calculável. |
| 4 | Política de revisão anual não é cumprida | Média/Alta | “Cliente ativo” (Comercial) foi revisado em 10/03/2025 — dentro do prazo. Mas há termos sem data (Score de crédito). A política existe, mas não é aplicada. |
3.3. Versão corrigida do glossário (proposta)
| Termo | Definição | Responsável | Data de revisão |
|---|---|---|---|
| Cliente ativo | Pessoa que realizou ao menos uma transação financeira (excluindo consultas e transferências entre contas próprias) nos últimos 90 dias. Definição única corporativa. | [a levantar com Comitê de Dados — decisão mediada entre Comercial e Dados] | [data da aprovação] |
| Cliente engajado (app) | Pessoa que acessou o aplicativo nos últimos 30 dias. Termo distinto, para uso de Marketing. | Área Comercial | 10/03/2025 |
| Cliente com pedido em trânsito | Pessoa com ao menos um pedido de entrega em andamento. Termo distinto, para uso de Logística. | [a levantar com Logística] | [data] |
| Score de crédito | Pontuação que indica a probabilidade de inadimplência, calculada pelo modelo [nome do modelo]. | [a levantar com Ciência de Dados/Crédito] | [data] |
| PEP | Pessoa politicamente exposta, conforme definição do Compliance. | Compliance | 02/02/2026 |
| Receita líquida | Receita total menos impostos e devoluções. | Finanças | 01/08/2025 |
Nota conceitual: a solução não é “escolher uma definição e descartar a outra”, mas distinguir conceitos: “cliente ativo” (corporativo, único) e termos específicos para usos legítimos diferentes (“cliente engajado no app”, “cliente com pedido em trânsito”). Isso resolve o conflito sem perder a necessidade de cada área.
4. Avaliação do Artefato 3 — Matriz de Papéis e Responsabilidades
4.1. Elementos adequados
- Há uma matriz formalizada com papéis e algumas responsabilidades.
- Há CDO e Comitê de Dados previstos.
4.2. Fragilidades identificadas e gravidade
| # | Fragilidade | Gravidade | Justificativa |
|---|---|---|---|
| 1 | Data Owner — Clientes = “Área de Negócios” (genérico) | Crítica | Mesmo problema do catálogo. Sem pessoa nomeada, não há quem aprove acesso, garanta qualidade ou responda a reguladores. Bloqueia tudo. |
| 2 | Data Steward — Clientes = “(vago)” | Crítica | Sem steward, não há quem mantenha metadados, crie regras de qualidade ou esclareça dúvidas. A trilha: “sem steward, as capacidades de governança são comprometidas”. |
| 3 | Pessoa consumidora de dados = “(não mapeado)” | Alta | O consumidor é quem identifica problemas e fornece feedback. Sem mapeamento, a governança perde seu principal aliado e a qualidade não melhora. |
| 4 | Data Owner — Transações com responsabilidade incompleta | Alta | “Aprovar acessos” apenas — não inclui “garantir qualidade”, que é responsabilidade do Owner. |
| 5 | Data Steward — Transações = Ana Luísa (Engenharia de Dados) | Média/Alta | Steward de negócio deveria ser da área de negócio, não de Engenharia. Ana Luísa pode ser Technical Data Steward, não Business Data Steward. A trilha distingue claramente os dois papéis. |
| 6 | CDO reporta à VP de Tecnologia | Alta | A trilha alerta que o CDO precisa de autonomia e independência para reportar a reguladores. Reportar à Tecnologia compromete a independência e a autoridade sobre as áreas de negócio. |
| 7 | Comitê de Dados = “Reunião trimestral” | Média | A matriz descreve a periodicidade, não a composição nem o poder decisório. Quem participa? Quem decide? Sem isso, o comitê é frágil. |
4.3. Versão corrigida da matriz (proposta)
| Papel | Pessoa/Área designada | Responsabilidades documentadas |
|---|---|---|
| Data Owner — Clientes | [a levantar com Diretoria de Negócios — pessoa nomeada, com autoridade] | Aprovar acessos; garantir qualidade; responder por conformidade; decidir sobre uso em IA. |
| Data Owner — Transações | Gerência de Operações (nomear pessoa) | Aprovar acessos; garantir qualidade; responder por conformidade. |
| Business Data Steward — Clientes | [a levantar com área de negócio — pessoa com conhecimento de domínio] | Manter metadados de negócio; criar regras de qualidade; esclarecer dúvidas. |
| Technical Data Steward — Clientes | Carlos (DBA) | Backup, performance, implementação técnica de regras. |
| Business Data Steward — Transações | [a levantar com Operações] | Manter metadados de negócio; criar regras de qualidade. |
| Technical Data Steward — Transações | Ana Luísa (Engenharia de Dados) | Implementar regras técnicas; manter metadados técnicos. |
| CDO | Reporta à Diretoria Executiva (não à Tecnologia) | Responder em última instância perante reguladores; garantir autonomia da governança. |
| Comitê de Dados | Reunião trimestral; composição: CDO + Owners + representantes de Negócio, Tecnologia, Jurídico, Compliance | Aprovar políticas; decidir sobre casos de maior risco; mediar conflitos de definição. |
| Pessoa consumidora de dados | [a levantar — mapear por domínio] | Reportar problemas de qualidade; fornecer feedback; usar dados conforme políticas. |
5. Priorização dos Problemas (Matriz Gravidade × Iniciativa Bloqueada)
| Prioridade | Problema | Gravidade | Iniciativas bloqueadas | Justificativa conceitual |
|---|---|---|---|---|
| 1º | Data Owner genérico (“Área de Negócios”) e Data Steward vago (Artefatos 1 e 3) | Crítica | Qualidade, Produtos de Dados, IA | Sem owner nomeado e steward, não há accountability, não se aprova acesso, não se criam regras de qualidade, não se responde a reguladores. É a base de toda a governança (DAMA: ownership é iniciativa fundamental e perene). |
| 2º | “Cliente ativo” com duas definições conflitantes (Artefato 2) | Crítica | Qualidade, Produtos de Dados, IA | Indicadores inconsistentes; duas áreas chegam a números diferentes. Viola a definição única do glossário. Bloqueia qualquer produto de dados ou modelo de IA que dependa de “cliente ativo”. |
| 3º | Classificação de sensibilidade ausente em tabela com CPF, e-mail, data de nascimento e flag_pep (Artefato 1) |
Crítica | IA, conformidade LGPD | Dados pessoais e sensíveis sem classificação = exposição regulatória direta. Impede uso seguro em IA e controle de acesso. |
| 4º | Metadados de negócio e linhagem ausentes (Artefato 1) | Alta | Produtos de Dados, IA | Sem contexto, ninguém usa a tabela com confiança; sem linhagem, não se responde à auditoria. |
| 5º | CDO reporta à VP de Tecnologia (Artefato 3) | Alta | Governança como um todo | Compromete a autonomia e a independência exigidas para responder a reguladores. |
| 6º | Pessoa consumidora não mapeada (Artefato 3) | Alta | Qualidade | Sem consumidor mapeado, perde-se o principal aliado na identificação de problemas. |
| 7º | “Score de crédito” sem responsável nem vigência (Artefato 2) | Alta | IA de crédito | Termo central sem dono; não se sabe quem decide a definição. |
| 8º | Ana Luísa (Engenharia) como Data Steward de negócio (Artefato 3) | Média/Alta | Qualidade | Confusão entre Business e Technical Steward; o steward de negócio deve ser da área de negócio. |
| 9º | Nome clientes_v3_final e definições imprecisas no glossário |
Média | Produtos de Dados | Nome técnico e definições não calculáveis dificultam uso e automação. |
Critério de gravidade explícito:
- Crítica: bloqueia iniciativa planejada E/OU gera exposição regulatória direta E/OU impede accountability.
- Alta: compromete seriamente a qualidade ou a confiança nos dados, mas há contorno parcial.
- Média: degrada a experiência ou a eficiência, sem bloquear a iniciativa.
6. Comparação com a Leitura da IA Generativa
6.1. Prompt estruturado utilizado
“Analise estes três artefatos de governança de dados de um banco digital (entrada de catálogo, trecho de glossário e matriz de papéis) e aponte fragilidades à luz do DAMA-DMBOK e de boas práticas de catálogo, glossário e ownership. Priorize por gravidade e indique correções.”
6.2. O que a IA identificou que eu não havia notado
- A IA destacou que
flag_pepé um dado pessoal sensível por implicação (exposição política), o que eu havia mencionado, mas a IA detalhou melhor o enquadramento regulatório (LGPD, art. 5º, II). Incorporei o detalhamento. - A IA apontou que a data de revisão do glossário “Cliente ativo” (Comercial) está dentro do prazo anual, mas a de “Dados” também — e ambas coexistem, o que reforça que o problema não é vigência, é conflito de definição. Incorporei.
- A IA sugeriu que o nome
clientes_v3_finalindica versionamento informal, o que eu havia notado, mas a IA relacionou à falta de padrão de nomenclatura. Incorporei.
6.3. Onde a IA foi genérica ou imprecisa
- A IA sugeriu “escolher a definição da Área de Dados como oficial” sem considerar que a Comercial tem necessidade legítima de outra definição. Descartei — a solução correta é distinguir conceitos (cliente ativo vs. cliente engajado), não descartar uma área.
- A IA não questionou o CDO reportar à VP de Tecnologia com a devida ênfase na autonomia. Mantive minha análise e reforcei o ponto.
- A IA tratou “Área de Negócios” como owner aceitável, sem destacar que precisa ser pessoa nomeada. Descartei — a trilha exige pessoa com autoridade e conhecimento.
- A IA não mencionou a distinção Business vs. Technical Data Steward para o caso da Ana Luísa. Mantive minha análise.
6.4. O que mantive, incorporei e descartei
| Item | Decisão | Justificativa |
|---|---|---|
flag_pep como dado sensível |
Incorporei | Detalhamento regulatório da IA é correto e útil. |
| Conflito de definição de “cliente ativo” | Mantive e reforcei | A IA identificou, mas não propôs a solução de distinguir conceitos. |
| Escolher definição da Área de Dados | Descartei | Desconsidera a necessidade legítima da Comercial. |
| CDO reportando à Tecnologia | Mantive | A IA não deu ênfase à autonomia. |
| “Área de Negócios” como owner | Descartei a aceitação da IA | Precisa ser pessoa nomeada. |
| Distinção Business vs. Technical Steward | Mantive | A IA não abordou. |
7. Conclusão do Parecer
Os artefatos NÃO estão em condições de sustentar as iniciativas planejadas. As fragilidades críticas são:
- Ownership genérico e steward vago → sem accountability, nenhuma iniciativa avança.
- Definição conflitante de “cliente ativo” → indicadores inconsistentes, produtos de dados e IA comprometidos.
- Classificação de sensibilidade ausente em tabela com dados pessoais e sensíveis → exposição regulatória direta.
Correções prioritárias:
- Nomear Data Owners e Data Stewards (pessoas, não áreas).
- Resolver o conflito de “cliente ativo” com definição única corporativa + termos distintos para usos legítimos.
- Classificar a tabela
clientescomo Confidencial, comflag_pepcomo Restrita. - Preencher metadados de negócio e linhagem.
- Reposicionar o CDO para reportar à Diretoria Executiva.
- Mapear consumidores de dados.
Sem essas correções, as iniciativas de qualidade, produtos de dados e IA do próximo ano estão bloqueadas na base. A governança precisa agir sobre os artefatos antes de avançar.
8. Fluxo PlantUML — Diagnóstico e Priorização
O código abaixo está pronto para colar no PlantText.
