Proveniência e Rastreabilidade de Dados

Seu sistema de IA tomou uma decisão. Você consegue rastrear os dados por trás dela?

A proveniência de dados é a infraestrutura que torna respondíveis as perguntas sobre dados de IA — não um painel ou entrada de catálogo, mas um sistema que captura onde os dados de treinamento se originaram, quais transformações sofreram, quais modelos os consumiram e se essa cadeia pode ser verificada criptograficamente (veja nossa pesquisa sobre a arquitetura de IA verificável para a empresa pós-confiança).

Um tribunal acaba de ordenar que a OpenAI apresente 78 milhões de logs de saída do ChatGPT porque os autores da ação precisavam rastrear como dados de treinamento protegidos por direitos autorais influenciaram o comportamento do modelo. Esse é um exemplo extremo. A versão cotidiana é mais discreta, mas igualmente consequente:

• Um regulador perguntando quais dados treinaram seu modelo de concessão de crédito.
• Uma solicitação de exclusão do GDPR que chegou às suas tabelas de origem, mas não aos seis modelos downstream que consumiram os registros excluídos.
• Um incidente de envenenamento de dados em que você não consegue identificar quais lotes de treinamento foram comprometidos porque nada em seu pipeline registrou a resposta.

Nossa abordagem consiste em construir essa camada de proveniência nas ferramentas de pipeline que as empresas já executam: Spark, dbt, Airflow, Dagster e ETL personalizado.

Por que a linhagem de catálogo não é o mesmo que a proveniência de dados de treinamento

A maioria das empresas já possui um catálogo de metadados. Collibra, Alation, Atlan ou DataHub cobre a linhagem em nível de tabela, útil para análise de impacto de mudanças de esquema. Isso não responde às perguntas que reguladores, auditores e litigantes fazem sobre sistemas de IA. A lacuna se manifesta em três pontos:

Nossa abordagem funciona com qualquer catálogo que você já possua. A camada de proveniência foi projetada para atuar sob ele, instrumentando a execução real do pipeline para capturar os detalhes em nível de registro e de transformação que os catálogos não foram projetados para fornecer.

O que instrumentamos e como

O desafio central é capturar a proveniência na granularidade exigida pelos reguladores sem inviabilizar o throughput do pipeline. O hashing SHA-256 por registro em um job do Spark processando 500 milhões de linhas adiciona 15–40% de sobrecarga — o que raramente é aceitável para produção. Nossa abordagem calibra a granularidade da proveniência ao perfil de risco real.

Instrumentação de pipelines com OpenLineage

A instrumentação utiliza o OpenLineage como padrão de emissão onde existem integrações (Spark, Airflow, dbt e Dagster têm diferentes níveis de suporte), com facetas personalizadas que capturam metadados específicos de ML: parâmetros de engenharia de features, configurações de aumento de dados, estratégias de amostragem e critérios de divisão entre treino/validação/teste. Onde a integração do OpenLineage é incompleta ou descarta eventos — o listener do Spark é conhecido por perder silenciosamente facetas personalizadas sob altas contagens de partições —, a abordagem adiciona instrumentação suplementar projetada para capturar o que a integração padrão perde, detalhado em nosso whitepaper técnico sobre como proteger a cadeia de suprimentos de ML em todo o ciclo de vida.

Proveniência para dados não estruturados

Para dados de treinamento não estruturados — documentos, imagens, áudio e vídeo usados em fine-tuning ou pipelines de RAG —, a abordagem aplica fingerprinting de conteúdo com hashing perceptual (pHash para imagens, chromaprint para áudio) junto a hashes criptográficos, permitindo o rastreamento de proveniência mesmo quando o conteúdo sofre transformações com perdas — veja uma demonstração prática do rastreamento de proveniência de áudio.

O problema da exclusão no GDPR que ninguém resolveu de forma limpa

No GDPR, o Artigo 17 concede o direito à eliminação. Para bancos de dados tradicionais, basta excluir e confirmar. Para sistemas de IA, trata-se de um problema não resolvido disfarçado de item de conformidade. Grandes modelos de linguagem não armazenam dados como registros discretos — eles armazenam padrões estatísticos derivados dos dados de treinamento, distribuídos por bilhões de parâmetros. Excluir os dados de uma pessoa da tabela de origem não remove sua influência dos pesos do modelo, e o GDPR não oferece uma estrutura para interpretar o que "eliminação" significa uma vez que os dados tenham sido absorvidos pela arquitetura de tomada de decisão do modelo.

A pesquisa sobre desaprendizado de máquina (machine unlearning) está avançando. Em setembro de 2025, pesquisadores da UC Riverside demonstraram o "source-free unlearning", um método certificado que funciona sem os dados de treinamento originais, usando conjuntos de dados substitutos e ajuste de parâmetros baseado em atualizações de Newton. No entanto, nenhum método de desaprendizado está pronto para produção em escala corporativa. As abordagens práticas atuais combinam três camadas:

• Prevenção — manter PII fora dos dados de treinamento por meio de gates de pré-processamento.
• Remediação rápida — excluir de índices de recuperação, caches e logs.
• Documentação defensável — registros de proveniência que comprovam quais dados entraram em quais modelos, embasando decisões de retreinamento quando o desaprendizado for insuficiente.

A infraestrutura de proveniência foi projetada para criar o pré-requisito para qualquer estratégia de eliminação: um mapa consultável a partir do identificador do titular dos dados para cada modelo, pipeline e artefato que consumiu seus dados. Com ela, você responde "quais modelos precisam de retreinamento?" em questão de minutos após uma solicitação de exclusão, em vez de descobrir meses depois que uma execução esquecida de fine-tuning utilizou os dados afetados.

Artigo 10 do EU AI Act: De Documentos de Políticas a Evidências de Pipeline

O Artigo 10 do EU AI Act exige que os dados de treinamento, validação e teste estejam sujeitos a "práticas de governança e gestão de dados apropriadas para a finalidade pretendida". A aplicação começa em 2 de agosto de 2026. O requisito prático não é um documento de política de governança. É uma evidência verificável e com carimbo de data/hora de que a governança foi aplicada no momento em que os dados entraram no pipeline.

A lacuna é real: apenas 3% das instituições financeiras implantaram IA em produção com eficácia (Relatório de Confiança de Dados da Ataccama 2025). As políticas de governança existem, mas a comprovação de adesão em nível de pipeline não.

Nossa abordagem entrega conformidade com o Artigo 10 como uma capacidade do pipeline. Cada execução é projetada para produzir um registro de proveniência capturando: fontes de dados com metadados de origem, resultados de validação de qualidade, parâmetros de transformação, metodologia de amostragem, propriedades estatísticas do conjunto de dados (representatividade, completude, taxas de erro) e políticas ativas de governança. Esse é o artefato que um auditor examina — gerado automaticamente, não montado retroativamente.

Para organizações também sujeitas ao Artigo 30 do GDPR (registros de atividades de tratamento), o sistema de proveniência foi projetado para produzir ambos os artefatos de conformidade a partir de uma única camada de instrumentação. Os requisitos se sobrepõem, mas não são idênticos: o Artigo 30 foca nas finalidades de tratamento e nas bases legais, enquanto o Artigo 10 foca na qualidade e representatividade dos dados. Um sistema unificado evita a duplicação que afeta organizações que executam trilhas de conformidade separadas.

Atribuição de Dados de Treinamento e Detecção de Envenenamento

Os órgãos reguladores estão começando a questionar quais exemplos de treinamento influenciaram uma previsão específica. As funções de influência, o framework matemático para isso, historicamente têm sido caras demais para a produção. Avanços recentes — a projeção de gradiente LoGra e o algoritmo ASTRA — trazem a computação de influência para uma escala prática. Nossa abordagem implementa a atribuição como um recurso forense: pontuações de influência pré-computadas para comportamentos críticos do modelo, armazenadas em cache para recuperação quando um auditor ou litigante precisar da conexão entre uma saída específica e os dados subjacentes.

A proveniência também atua como a principal defesa contra o envenenamento de dados de treinamento (nossa pesquisa sobre proteção de modelos corporativos contra envenenamento). Pesquisas confirmaram em 2025 que o envenenamento exige apenas um número constante de amostras, independentemente do tamanho do modelo, e até 0,001% de dados adversariais pode degradar a acurácia em 30%. Quando cada elemento de dados possui uma cadeia de custódia verificada, padrões anômalos de proveniência tornam-se detectáveis:

• Dados de fontes não verificadas.
• Registros com cadeias de hash corrompidas.
• Exemplos contornando o pipeline padrão de ingestão.

Sobre o grafo de proveniência, a abordagem adiciona camadas de detecção projetadas para sinalizar esses padrões antes que os dados contaminados alcancem o treinamento do modelo.

Quando este é o investimento certo

Você precisa de infraestrutura de proveniência quando seus sistemas de IA consomem dados com risco jurídico, regulatório ou de segurança:

• Empresas de serviços financeiros sujeitas ao Artigo 10 do EU AI Act.
• Setor de saúde sujeito ao FDA 21 CFR Part 11.
• Empresas com exposição ao GDPR que realizam treinamento com dados de usuários.
• Organizações cuja obtenção de dados de treinamento está sob escrutínio legal.

Você não precisa disso se sua IA consome apenas dados primários e não regulamentados com um pipeline simples. Se o grafo de linhagem do dbt somado a uma instância do DataHub atender às suas necessidades, utilize-os — diremos isso já na primeira conversa.