Carreira Governança de Dados: Nível 1 Etapa 2

Por

2ª Etapa: Ciclo de vida dos dados aplicado ao caso SwiftBank

Discutir no fórum

Agora você precisa mostrar, na prática, como um dado nasce, evolui e é descartado dentro do SwiftBank. O caso escolhido é o do conceito “Cliente Ativo”, que hoje é definido de formas diferentes em Marketing, Crédito e Financeiro. Você produzirá um fluxograma do ciclo de vida cobrindo coleta → armazenamento → recuperação → uso → descarte, com responsáveis e perguntas-chave em cada etapa, mais um documento de apoio.

Pergunta-chave: “Quais decisões de governança precisam acontecer em cada etapa do ciclo de vida do dado de ‘Cliente Ativo’ para que ele possa ser usado de forma segura, consistente e em conformidade com a LGPD?”

🎯 Sua missão

🔹 Missão 1 Draw.io / PlantUML

No Draw.io, crie um fluxograma horizontal com as cinco etapas do ciclo de vida (coleta, armazenamento, recuperação, uso, descarte). Em cada etapa, inclua:

  • (a) os atores envolvidos (ex.: Engenharia de Dados, Data Owner, Segurança);
  • (b) duas a três perguntas-chave (ex.: “temos direito de coletar?”, “qual a finalidade declarada?”, “quando descartar?”);
  • (c) um exemplo concreto aplicado ao SwiftBank usando o dataset clientes_swiftbank.csv (ex.: na coleta, como entra o campo consentimento_marketing).

Código PlantText do Fluxograma abaixo:

 

Fluxograma do ciclo de vida (clique para ampliar em nova aba):


Ciclo de vida do dado Cliente Ativo – SwiftBank

 

🔹 Missão 2 Excel – 02_ciclo_de_vida_cliente_ativo.xlsx

Crie a pasta de trabalho com as abas Etapas, Camadas e Definicao_Cliente_Ativo.

📋 Aba Etapas

etapa acao atores perguntas_chave riscos_LGPD evidencia_no_dataset
Coleta Coletar dados cadastrais e de consentimento do cliente. Engenharia de Dados, Time de Cadastro, DPO Temos base legal? A finalidade está declarada? O dado é necessário (minimização)? Coleta sem consentimento; finalidade genérica; excesso de dados. Campos consentimento_marketing (sim/não), data_cadastro, nome, cidade, data_nascimento.
Armazenamento Persistir em camadas bronze, silver e gold com controles de acesso. Engenharia de Dados, Data Owner, Segurança Onde armazenar? Por quanto tempo reter? Quem pode acessar? Armazenamento inseguro; retenção além do necessário; acesso não autorizado. Tabelas bz_clientes, sl_clientes, gd_clientes_ativos (derivadas do CSV).
Recuperação Localizar, solicitar acesso e extrair os dados autorizados. Analista de Dados, Data Owner, Segurança Quem solicita? Qual a finalidade? O acesso é auditado? Acesso indevido; extração sem justificativa; dados desatualizados. Consultas à gd_clientes_ativos para campanhas ou análise de crédito.
Uso Utilizar o dado padronizado para decisões de negócio. Marketing, Crédito, Financeiro, Compliance O uso está alinhado à finalidade? Há viés? Os resultados são auditáveis? Uso discriminatório; desvio de finalidade; falta de transparência. Regra cliente_ativo aplicada sobre status_conta e data_ultima_transacao.
Descarte Eliminar dados pessoais após o prazo legal ou revogação do consentimento. Engenharia de Dados, DPO, Segurança, Jurídico Quando descartar? Como garantir eliminação segura? Há arquivamento legal? Retenção indefinida; descarte inadequado; perda de evidências legais. Exclusão de registros do clientes_swiftbank.csv após 5 anos sem transação e sem consentimento.

📋 Aba Camadas

camada tabela o que muda exemplo de transformação
Bronze bz_clientes Dados brutos, sem tratamento, exatamente como vêm da origem (CSV). clientes_swiftbank.csv é carregado sem alterações; campos como nome, cidade, data_nascimento, consentimento_marketing.
Silver sl_clientes Dados limpos, padronizados, com tipagem correta e remoção de duplicatas. Datas convertidas para o padrão ISO; status_conta normalizado (ex.: “Ativa”, “Inativa”); consentimento_marketing como booleano.
Gold gd_clientes_ativos Dados enriquecidos e prontos para o negócio, com a regra de “Cliente Ativo” aplicada. Filtro: status_conta = 'Ativa' E data_ultima_transacao >= CURRENT_DATE - 90 dias. Resultado: apenas clientes ativos para Marketing, Crédito e Financeiro.

📋 Aba Definicao_Cliente_Ativo

Regra padronizada: “Cliente PF ou PJ com status_conta = 'Ativa' e ao menos uma transação efetivada nos últimos 90 dias.”

Justificativa: Essa regra elimina divergências porque estabelece um critério único, objetivo e auditável para todas as áreas. Marketing, Crédito e Financeiro passam a usar a mesma base (gd_clientes_ativos), evitando que cada setor crie sua própria definição (ex.: “cliente que logou no app”, “cliente com saldo positivo”, “cliente com compra no mês”).

Três decisões erradas sem a padronização:

  1. Marketing envia campanhas para clientes inativos (sem transação há mais de 90 dias), gerando custo elevado e baixa conversão.
  2. Crédito nega ou aprova limites com base em uma definição diferente, aumentando o risco de inadimplência ou perda de bons clientes.
  3. Financeiro projeta receita com clientes que não transacionam, causando distorções no fluxo de caixa e metas irreais.

🔹 Missão 3 Documento de apoio

O documento de apoio é composto pelas abas do Excel descritas acima, que detalham cada etapa, camadas e a definição padronizada. Além disso, o fluxograma PlantUML serve como representação visual do ciclo de vida.

🧰 Ferramentas

  • Draw.io (para o fluxograma visual – o PlantUML pode ser importado ou usado como referência);
  • Excel (para as abas Etapas, Camadas e Definição_Cliente_Ativo).

💡 Dicas de troubleshooting

  • Armazenamento vs. recuperação: armazenar é guardar; recuperar é localizar, pedir acesso e extrair. Quem aprova é o Data Owner.
  • Descarte vs. arquivamento: pela LGPD, manter dado pessoal além da finalidade é problema; descarte exige procedimento, não basta apagar de uma planilha.
  • Dado pessoal sensível: combinações de nome + cidade + data de nascimento já configuram identificação indireta (consulte o clientes_swiftbank.csv).

Solução completa para a 2ª etapa – Ciclo de vida dos dados aplicado ao SwiftBank.

Deixe um comentário

Facebook
LinkedIn
Share
Instagram