Governança de Dados

Visão geral

Governança de dados (data governance) é o conjunto de funções, políticas, processos e controles técnicos que determinam quem “é dono” dos dados, quem pode acessá-los e quem é responsável por mantê-los ao longo de seu ciclo de vida. Em organizações de IA/AM, a governança de dados é especialmente importante porque os conjuntos de dados de treinamento e avaliação influenciam diretamente o comportamento do modelo, a segurança e a exposição legal.

Uma definição prática alinhada a esta seção do wiki:

  • Propriedade: Responsabilização clara pelo significado, pela correção e pelos usos aprovados de um conjunto de dados.
  • Controle de acesso: Regras aplicadas para definir quem pode ver, consultar, exportar ou modificar dados.
  • Curadoria (stewardship): Cuidado contínuo — documentação, monitoramento de qualidade, retenção e resolução de problemas.

A governança de dados complementa (mas não é a mesma coisa que) práticas adjacentes como Segurança de Dados, Privacidade, Versionamento de Dados e Documentação de Conjuntos de Dados (Datasheets).

Por que a governança de dados importa para IA/AM

Sistemas de IA ampliam as consequências de uma governança deficiente:

  1. O risco do modelo escala com o acesso aos dados

    • Se muitos usuários podem exportar dados sensíveis, a chance de vazamento aumenta.
    • Se dados de treinamento são usados fora do escopo pretendido, os modelos podem violar consentimento ou limites regulatórios.

  2. Dados de treinamento são uma “dependência a montante”

    • Mudanças no esquema de dados, backfills ou atualizações na política de rotulagem podem alterar silenciosamente o comportamento do modelo. A governança cria pontos de controle e responsabilização.

  3. Obrigações regulatórias e contratuais

    • GDPR, HIPAA, PCI DSS, regras setoriais e acordos de compartilhamento de dados frequentemente exigem controles de acesso documentados, limites de retenção e auditabilidade.

  4. Eficiência operacional

    • Sem propriedade clara, conjuntos de dados tornam-se “órfãos”: ninguém corrige problemas de qualidade, e equipes desperdiçam tempo negociando acesso ad hoc.

Exemplo prático: Um modelo de churn treinado com transcrições de suporte ao cliente pode incluir acidentalmente categorias sensíveis (detalhes médicos, dados de pagamento). A governança garante (a) que as transcrições sejam classificadas, (b) que apenas funções aprovadas possam acessar texto bruto e (c) que o treinamento do modelo use uma visão validada e minimizada.

Conceitos centrais

Propriedade do conjunto de dados

Propriedade trata de responsabilização, não necessariamente de propriedade legal. Um padrão comum de governança atribui múltiplas funções:

  • Proprietário de Dados (Data Owner) (accountable): Define casos de uso aprovados, classificação de sensibilidade, regras de compartilhamento e expectativas de qualidade. Frequentemente é um líder de domínio de negócio.
  • Curador de Dados (Data Steward) (responsible): Mantém metadados, documentação e resolve problemas de dados; coordena com produtores/consumidores.
  • Custodiante de Dados (Data Custodian) (técnico): Implementa armazenamento, backups, controles de acesso e confiabilidade operacional (geralmente plataforma ou engenharia de dados).
  • Produtor de Dados (Data Producer): Sistema ou equipe que gera os dados (serviço de app, pipeline de instrumentação).
  • Consumidor de Dados (Data Consumer): Equipes que usam dados para analytics, AM ou relatórios.

Um RACI enxuto para um conjunto de dados de “Interações com Clientes”:

  • Owner: Head de Customer Ops (A)
  • Steward: Líder de analytics (R)
  • Custodian: Time de plataforma de dados (R)
  • Producer: Time de ferramentas de suporte (C)
  • Consumers: Time de AM, time de BI (I/C dependendo da mudança)

A propriedade deve estar visível em um catálogo de dados e vinculada a processos operacionais (aprovações de acesso, revisões de mudança, resposta a incidentes).

Curadoria e gestão do ciclo de vida

Curadoria abrange o trabalho contínuo necessário para manter os dados utilizáveis e seguros:

  • Metadados e documentação

  • Expectativas de qualidade

  • Gestão de mudanças

    • Evolução de esquema, descontinuações, backfills e contratos de dados.

  • Retenção e exclusão

    • Por quanto tempo os dados são mantidos, como solicitações de exclusão são tratadas e a propagação a jusante.

  • Gestão de incidentes

    • Triagem, análise de causa raiz e comunicação aos consumidores impactados (incluindo pipelines de AM).

Controle de acesso (quem pode fazer o quê)

Controle de acesso transforma política em aplicação. Normalmente cobre:

  • Autenticação: Quem é você? (SSO, identidades de serviço)
  • Autorização: O que você pode fazer? (permissões e políticas)
  • Auditoria: O que você fez? (logs, alertas, revisões)

Decisões de acesso devem considerar:

  • Sensibilidade do conjunto de dados (PII, segredos comerciais)
  • Tipo de operação (leitura/consulta vs exportação vs escrita)
  • Ambiente (prod vs dev)
  • Contexto (propósito, ticket, acesso com prazo)

Fundamentos de política: o que uma “boa governança” otimiza

Uma governança forte equilibra objetivos concorrentes:

  • Capacitação: Tornar os dados descobríveis e utilizáveis para trabalho legítimo.
  • Redução de risco: Minimizar risco de privacidade, segurança, legal e reputacional.
  • Integridade: Manter definições consistentes e pipelines confiáveis.
  • Responsabilização: Garantir que todo conjunto de dados tenha pessoas responsáveis pelos resultados.
  • Auditabilidade: Ser capaz de reconstruir quem acessou o quê e por quê.

Um modelo mental útil é tratar conjuntos de dados como produtos: têm proprietários, SLAs, roadmaps e consumidores. Isso se alinha naturalmente com AM, em que a qualidade dos dados costuma ser mais impactante do que a arquitetura do modelo.

Modelos operacionais de governança

Governança centralizada

Um grupo central define padrões e aprova acessos.

  • Prós: Consistência, controles fortes, conformidade mais fácil.
  • Contras: Gargalos, iteração lenta, menos contexto de domínio.

Governança federada

Domínios são donos de seus dados; um time central fornece padrões e ferramentas.

  • Prós: Conhecimento de domínio, escalabilidade, decisões mais rápidas.
  • Contras: Risco de inconsistência sem padrões compartilhados fortes.

Governança no estilo data mesh

Equipes são donas de “produtos de dados”, e a governança é aplicada via capacidades padronizadas da plataforma (policy-as-code, catálogos, checagens automatizadas).

  • Prós: Escala com a organização, combina com engenharia distribuída moderna.
  • Contras: Requer plataformas maduras e equipes disciplinadas.

Na prática, muitas organizações adotam um híbrido: padrões centralizados mais propriedade por domínio.

Principais blocos de construção da governança prática de dados

1) Classificação e marcação de dados

Classificação torna políticas aplicáveis. Níveis comuns:

  • Público: Seguro para compartilhar externamente
  • Interno: Apenas da empresa
  • Confidencial: Limitado a funções específicas
  • Restrito: Altamente sensível (PII, regulado, segredos)

Você pode implementar tags em um catálogo ou metastore de lakehouse. Exemplo de uma especificação simples de classificação em YAML:

dataset: customer_support_transcripts
owner: customer-ops@example.com
steward: analytics@example.com
classification: restricted
contains:
  - pii
  - free_text
retention_days: 90
approved_uses:
  - "quality monitoring"
  - "training intent classifier on redacted text"
prohibited_uses:
  - "model training on raw transcripts"

A classificação também deve se estender a colunas/campos, não apenas a tabelas — especialmente para dados multimodais ou aninhados (ver Conjuntos de Dados Multimodais).

2) Padrões de gerenciamento de identidade e acesso

Modelos comuns de autorização:

  • RBAC (Controle de Acesso Baseado em Papéis, Role-Based Access Control): Permissões vinculadas a papéis (por exemplo, “Engenheiro de AM”, “Analista”).

    • Simples, amplamente usado.
    • Pode se tornar frágil com muitas exceções.

  • ABAC (Controle de Acesso Baseado em Atributos, Attribute-Based Access Control): Políticas consideram atributos (atributos do usuário, tags do conjunto de dados, propósito).

    • Mais escalável para orgs complexas.
    • Requer boa higiene de metadados.

  • PBAC (Controle de Acesso Baseado em Políticas, Policy-Based Access Control): Uma categoria mais ampla; frequentemente implementada como policy-as-code (OPA/Rego, políticas de IAM em nuvem).

Ideia prática de política no estilo ABAC:

{
  "allow": true,
  "when": [
    {"user.department": "ml"},
    {"dataset.classification": "confidential"},
    {"request.purpose": "model_training"},
    {"dataset.contains": "pii", "operator": "not_contains"}
  ]
}

Isso codifica uma regra comum: AM pode treinar com dados confidenciais somente se eles não estiverem marcados como contendo PII.

3) Privilégio mínimo e acesso em camadas

Um padrão forte para equipes de IA/AM é fornecer visões em camadas do conjunto de dados:

  • Bruto / Restrito: Fidelidade total (texto livre, identificadores); acesso mínimo.
  • Curado / Confidencial: Limpo, padronizado; acesso mais amplo.
  • Desidentificado / Interno: IDs tokenizados, texto livre removido; seguro para muitos fluxos de trabalho de AM.
  • Agregado / Quase público: Métricas e agregações; seguro para dashboards.

Isso se encaixa com Privacidade e reduz o número de pessoas que sequer tocam dados sensíveis brutos.

4) Segurança em nível de linha e em nível de coluna

Às vezes, você precisa de controles refinados:

  • Analistas podem ver todos os clientes na sua região.
  • Apenas um pequeno grupo pode ver SSNs ou datas de nascimento exatas.
  • Treinamento de AM pode usar uma faixa etária, mas não a data completa de nascimento.

SQL ilustrativo (conceitual; a sintaxe exata varia por data warehouse):

-- Example: hide sensitive column unless user is in privileged role
SELECT
  customer_id,
  CASE
    WHEN current_role() IN ('SECURE_PII_ACCESS') THEN email
    ELSE NULL
  END AS email,
  age_bucket,
  churn_label
FROM curated.customer_churn;

5) Fluxos de solicitação de acesso e aprovações

Governança precisa de um mecanismo repetível para exceções.

Um fluxo típico:

  1. Solicitante especifica conjunto de dados, nível de acesso, propósito e duração.
  2. O sistema verifica a classificação do conjunto de dados e a política base.
  3. Owner/steward aprova ou rejeita.
  4. O acesso é concedido com prazo e registrado.
  5. Revisões periódicas de acesso removem concessões obsoletas.

Pseudo-code para acesso com prazo:

def request_access(user, dataset, purpose, days):
    assert days <= dataset.max_grant_days
    if dataset.classification in ("restricted", "confidential"):
        approval = get_owner_approval(user, dataset, purpose)
        if not approval:
            return "DENIED"
    grant_role(user, dataset.read_role, expires_in_days=days)
    log_access_grant(user, dataset, purpose, days)
    return "APPROVED"

6) Auditabilidade e monitoramento

Logs de auditoria devem responder:

  • Quem acessou qual conjunto de dados?
  • Quais operações foram realizadas (query, export, write)?
  • De onde (rede, dispositivo, serviço)?
  • Sob qual justificativa (ticket/propósito)?

O monitoramento pode sinalizar anomalias:

  • Pico súbito de exportações
  • Acesso a partir de geografia incomum
  • Consultas tocando colunas restritas

Isso está fortemente ligado a Segurança de Dados, mas a governança define o que você deve medir e revisar, não apenas como criptografar.

7) Gestão de mudanças e “contratos de dados”

Sistemas de IA são sensíveis a mudanças a montante. A governança deve exigir:

  • Regras de evolução de esquema (mudanças retrocompatíveis, janelas de descontinuação)
  • Notificações aos consumidores
  • Conjuntos de dados versionados para reprodutibilidade de treinamento (Versionamento de Dados)
  • Contratos de dados entre produtores e consumidores

Um conceito simples de contrato:

  • Garantias do produtor: significados de campos, taxas de nulos permitidas, frequência de atualização
  • Garantias do consumidor: limites de uso e feedback sobre anomalias

Isso se conecta diretamente a Pipelines de Dados (ETL/ELT para AM): pipelines devem aplicar e testar contratos.

Exemplos práticos em contextos de IA/AM

Exemplo 1: Governança de um conjunto de dados de treinamento com PII

Cenário: Você quer treinar um modelo de lead scoring com dados de CRM.

Abordagem de governança:

  • Classificar tabelas de CRM como Restritas devido a PII.
  • Criar uma visão de treinamento que exclui identificadores diretos (email, telefone) e usa chaves substitutas estáveis.
  • Exigir que o treinamento do modelo rode em um ambiente controlado (sem exportações locais).
  • Registrar jobs de treinamento e a versão do conjunto de dados usada.

Resultado:

  • Cientistas de dados podem iterar rapidamente em atributos seguros.
  • O risco de segurança e privacidade é reduzido.
  • Modelos se tornam mais reprodutíveis porque a visão aprovada é estável e versionada.

Exemplo 2: Dados coletados via scraping para ajuste fino de LLM

Cenário: Uma equipe faz scraping de posts de fóruns para ajustar finamente um modelo de linguagem.

Preocupações de governança:

  • Proveniência e termos de uso (ver Dados Web e Scraping)
  • Inclusão potencial de dados pessoais
  • Restrições de licenciamento para redistribuição

Controles de governança:

  • Exigir documentação do conjunto de dados (domínios de origem, datas de coleta, observações sobre robots/ToS).
  • Restringir acesso ao texto bruto; fornecer texto filtrado com remoção de PII.
  • Rastrear onde o conjunto de dados é usado (quais fine-tunes, quais releases).

Exemplo 3: Rotulagem e curadoria para conjuntos de dados anotados por humanos

Cenário: Você constrói um classificador de toxicidade com rótulos humanos.

Medidas de governança:

  • Definir taxonomia e diretrizes de rótulos; versioná-las.
  • Garantir que o acesso do rotulador seja restrito (por exemplo, não pode ver IDs de usuário).
  • Armazenar a proveniência das anotações (quem rotulou o quê, quando) para auditabilidade.
  • Documentar limitações e uso pretendido (Coleta e Rotulagem de Dados).

Isso evita que “drift de rótulos” altere silenciosamente os alvos do modelo e dá suporte a investigações posteriores.

Ferramentas e padrões de implementação

A governança de dados é implementada por meio de uma combinação de:

  • Catálogo de dados + linhagem

    • Captura propriedade, tags, uso e dependências.
    • Ajuda a responder “se mudarmos esta tabela, quais modelos quebram?”

  • Motor central de políticas

    • Integração com IAM, permissões da plataforma de dados, policy-as-code.
    • Aplica regras consistentes em data warehouses, data lakes e feature stores.

  • Pipelines orientados por metadados

    • Pipelines leem tags do conjunto de dados e aplicam controles automaticamente:
      • Mascaramento de colunas sensíveis
      • Bloqueio de exportações
      • Aplicação de regras de retenção

  • Feature stores e plataformas de AM

    • A governança deve se estender a atributos:
      • Quais atributos são derivados de fontes restritas?
      • Atributos são permitidos para um determinado modelo/propósito?
    • Isso se conecta a práticas mais amplas de MLOps (se o seu wiki incluir) e a Versionamento de Dados.

Ecossistemas de fornecedores e de código aberto evoluem rapidamente, mas o padrão central é estável: políticas de governança são mais eficazes quando são aplicáveis por máquina e anexadas a metadados.

Armadilhas comuns

  • “Governança = aprovações” apenas

    • Se governança for principalmente reuniões e tickets, as equipes contornam o processo. Automatize a aplicação e facilite caminhos de acesso seguros.

  • Nenhum responsável único e claramente accountable

    • Conjuntos de dados órfãos levam à degradação de qualidade e reutilização arriscada.

  • Restringir demais por padrão

    • Controles excessivamente rígidos empurram as pessoas a copiar dados para planilhas ou buckets pessoais — pior para segurança e conformidade.

  • Ignorar dados derivados

    • Atributos e agregações ainda podem vazar informações sensíveis. A governança deve cobrir transformações e artefatos a jusante.

  • Documentação fraca e intenção pouco clara

    • Sem uso pretendido e limitações, conjuntos de dados são reutilizados para tarefas para as quais nunca foram projetados, aumentando viés e risco de falhas.

Um programa “inicial” pragmático de governança

Para organizações que constroem sistemas de IA, uma base de alto impacto se parece com:

  1. Inventário e catálogo

    • Identificar os principais conjuntos de dados usados por AM e analytics; atribuir owners/stewards.

  2. Classificação e marcação

    • Definir 3–5 níveis de sensibilidade; marcar conjuntos de dados e campos sensíveis.

  3. Papéis padrão de acesso

    • Criar papéis padrão por classificação; implementar privilégio mínimo.

  4. Visões seguras de treinamento

    • Fornecer visões desidentificadas e curadas para casos de uso comuns de AM.

  5. Logs e revisões

    • Ativar logs de auditoria; realizar revisões trimestrais de acesso para conjuntos de dados restritos.

  6. Documentação + versionamento

    • Exigir datasheets para conjuntos de dados de treinamento e versionamento para entradas de treinamento.

  7. Gestão de mudanças

    • Estabelecer uma política de mudança de esquema e um mecanismo de notificação.

Essa base normalmente entrega a maior parte da redução de risco e da clareza operacional sem exigir uma grande burocracia de governança.

Relação com tópicos adjacentes de dados

A governança de dados é o guarda-chuva que coordena diversas práticas especializadas:

Resumo

A governança de dados define e aplica propriedade, controle de acesso e curadoria para conjuntos de dados organizacionais. Para IA/AM, é uma camada crítica de segurança operacional: reduz riscos de privacidade e segurança, melhora a confiabilidade e a reprodutibilidade do modelo e esclarece responsabilidades quando algo dá errado. Governança eficaz não é apenas documentos de política — é metadados, automação e funções claras integradas aos fluxos de trabalho diários de dados e AM.