Você quer implementar IA em seu datacenter? excelente!
Agora, responda: Você tem dados de qualidade?
Se a resposta é "acho que temos", pare aqui.
Porquê a verdade brutal é: IA é só tão boa quanto seus dados.
Dados ruins = modelos ruins = decisões ruins= prejuízo real.
Governança de dados não é tarefa d TI. É estratégia corporativa.
O Problema Real: Dados Sujos
Exemplo 1: Idade de Clientes
Cliente A registrado em 1950 (118 anos)
Cliente B registrado em 2050 (nascimento futuro)
Cliente C sem data de nascimento registrada
Cliente D data registrada como "31/02/2023" (não existe)
Modelo de ML treinado com isso:
"Hm, dados dizem que pessoas nascem em 1950, 2050, ou data inváliad"
Output: Modelo completamente quebrado
Exemplo 2: Localização de Servidor
Servidor registado em:
- "New York"
- "NY"
- "Nueva York" (espanhol
- "Unidade 1, Prédio B, NY" (muito específico)
- "Default" (não foi preenchido)
- "" (vazio)
Consolidado: 6 entradas diferentes, mas é 1 servidor
Modelo teta correlacionar por localização?
Resultados: inconsistentes
Exemplo 3: Provisionamento de Memória
10 servidores, configuração de memória:
- "8G"
- "8gb"
- "8 GB"
- "8"
- "8 (gigabytes)"
- "8000MB
- "0008"
Sistema que calcula total de memória:
Trata "8" como 8 bytes? 8MB? Falha de parsing.
Resultado estimativas de capacidade completamente erradas
Pilares da Governança de Dados
1. Qualidade de Dados
Métricas:
| Dimensão Descrição | Target |
|----------|-----------|-------|
| Completude | % de campos preenchidos | > 95% |
| Acurácia | % de valores corretos vs real | > 98% || Consistência | Mesmo dado é igual em todas as tabelas | > 99% |
| Atualidade | Dados refletem realidade atual | < 24h de lag |
| Unicidade | Sem registros duplicados | > 99% |
2. Catalogação e Metadata
Você tem 10.000 tabelas de dados em seu datacenter. Qual é qual?
Sem catálogo, é folha em floresta.
O qe catalogar:
Tabela: sales_transactions
├── Oner: revenue-team
├── Location: warehouse/analytics/ales
├── Last updated: 2025-04-05
├── Row count: 50M
├── Clumns:
│ ├── transaction_id (PII)
│ ├── customerid (PII)
│ ├── amount (sensitive)
│ ├── timestam
│ └── status
├── Lineage:
│ ├── Source: order_sstem (daily, 8pm UTC)
│ ├── Transform: aggregation, deduplication
│ ── Consumers: revenue_reporting, ml_models/churn_preiction
├── Data quality score: 0.96
├── Refresh SLA:daily, < 2h lag
└── Retention: 7 years (regulatory rquirement)
3. Privacidade by Design
Antes de coletar dados, pergunte: "Preciso disso? Posso coletar legalmente?"
LGPD (Lei Geral de Proteção de Dados - Brasil)
Se você coleta dados de brasileiro, é regulado por LGPD.
Regras básicas:
- Consentimento: usuário tem que consentir ou ter "interesse legítimo"
- Direito ao esquecimento: se pede para deletar, você deleta
- Transparência: explicar para quê usa dados
- Segurança: proteger dados contra roubo
- Data minimization: coleta só o necessário
GDPR (Europa)
Mais rigoroso que LGPD. Se algum cliente europeu? Está sob GDPR.
Multas: até 4% da receita global se violar
Implementação Prática:
Antes de usar dados em IA:
☐ Tenho consentimento?
☐ Dados são PII (Personally Identifiable Information)?
☐ Se sim, estão criptografados?
☐ Posso deletar dados se pedirem?
☐ Registro de quem acessou?
☐ Documentação de consentimento arquivada?
4. Master Data Management (MDM)
Single source of truth. Quando há conflito de dados, qual é a versão correta?
Exemplo:
Sistema A: Cliente João Silva, data de nascimento 15/03/1980
Sistema B: Cliente João Silva, data de nascimento 15/03/1981
Qual é correto? Sem MDM, ninguém sabe.
Com MDM:
1. Designar sistema A como "master"
2. Sistema B sincroniza com A
3. Se diferença, flag para revisão manual
4. Resultado: dados únicos e confiáveis
5. Data Retention e Arquivamento
Manter dados para sempre é:
- Caro (armazenamento)
- Arriscado (mais dados = mais superfície de ataque)
- Problemático (LGPD obriga deletar se não precisa mais)
Política de retenção:
Transações de vendas:
├── Hot data: últimos 90 dias (em memória/SSD rápido)
├── Warm data: 91 dias a 2 anos (storage padrão)
├── Cold data: 2-7 anos (arquivo, acesso lento)
└── Deletion: após 7 anos (regulatory requirement)
Logs de acesso:
├── Hot: últimos 30 dias
├── Archive: 30-90 dias
└── Delete: após 90 dias
6. Data Sharing e Governança de Acesso
Nem toda pessoa acessa todo dado.
RBAC (Role-Based Access Control):
Analista de vendas:
├── Acesso: sales_transactions (últimos 2 anos)
├── Restrições: não vê salário de funcionário
├── Audit: todos os acessos logados
└── Revogação: quando sai da empresa
DBA:
├── Acesso: tudo (precisa para manutenção)
├── Restrições: acessos logados, supervisão
└── Revogação: imediata se demitido
Roadmap: 12 Meses
Mês 1-2: Assessment
- Auditar: que dados você tem?
- Qual a qualidade?
- Quem usa? Quando?
- Quais estão "sujos"?
Output: Documento de estado atual
Mês 3-4: Governance Framework
- Definir política de qualidade
- Estabelecer MDM
- Criar catálogo de dados
- Documentar lineage (origem dos dados)
Output: Framework aprovado por Legal/Compliance/CIO
Mês 5-6: Implementação Técnica
- Deploy de ferramentas (Collibra/Atlas)
- Integração com data warehouse
- Automação de quality checks
- Testes com dataset piloto
Mês 7-9: Rollout Controlado
- Validar com business teams
- Identificar dados críticos vs não-críticos
- Implementar controles de acesso
- Treinamento de usuários
Mês 10-12: Escala + Automação
- Expandir para novos datasources
- ML para detecção automática de anomalia de qualidade
- Retenção automática de dados
- Compliance audits mensais
Custo-Benefício
Investimento (Year 1)
| Item | Custo |
|---|---|
| Ferramenta (Collibra) | R$ 100.000 |
| Infraestrutura (storage, compute) | R$ 80.000 |
| Recursos (Data Gov Officer + team) | R$ 200.000 |
| Treinamento + consultoria | R$ 50.000 |
| Total | R$ 430.000 |
Benefício (Year 1)
| Item | Valor |
|---|---|
| Redução de erro de dados | R$ 150.000 |
| Compliance penalties evitadas | R$ 200.000+ |
| Eficiência (menos tempo em limpeza) | R$ 120.000 |
| IA que funciona melhor | R$ 300.000 |
| Total | R$ 770.000+ |
ROI: ~80% no Year 1
Governança + IA: Por Que Importa
Sem governança:
Dados sujos → Modelo treinado em lixo → Output lixo → Decisão errada → Prejuízo
Com governança:
Dados limpos → Modelo robusto → Output confiável → Decisão certa → Valor real
Quando você implementa IA (observabilidade preditiva, RPA cognitiva, etc), ela só funciona bem se dados são bons.
Governança de dados é pré-requisito, não extra.
Conclusão
Ninguém fica famoso por "ter boa governança de dados".
Mas todo projeto de IA fracassa por "dados foram ruins".
Você quer ser conhecido como:
a) "Aquele que implementou IA revolucionária" (que quebrou porque dados eram ruins)
b) "Aquele que construiu fundação sólida de dados" (que permite IA escalar)
Escolha (b). Seu futuro eu agradece.
Comece agora. Dados não limpam a si mesmos.