O que sobra de uma análise seis meses depois?

A cena

Em março, uma empresa mudou a política de preço de um canal. A análise foi feita com cuidado, o time discutiu e a decisão saiu.

Em junho, alguém pergunta por que aquela mudança aconteceu. O que existe é uma apresentação com um gráfico e uma conclusão. O caminho até ali ficou na memória do analista e em consultas que ninguém salvou. O analista saiu da empresa em abril.

O exemplo é hipotético, construído para este artigo. O padrão, como veremos adiante, é bem documentado.

O que se perde quando o caminho não existe

Quando só a conclusão sobrevive, três coisas se perdem ao mesmo tempo, e elas não são a mesma coisa.

A verificação. O número pode até estar certo, só que ninguém consegue conferir. Concordar ou discordar passa a depender da confiança na pessoa que fez, e não da evidência que ela usou. Isso funciona enquanto a pessoa está por perto e enquanto ninguém contesta. Quando alguém contesta, a discussão não tem onde acontecer.

O reaproveitamento. Se a margem cair de novo daqui a seis meses, a investigação recomeça do zero. Alguém vai repetir as mesmas consultas, incluindo as que já não tinham levado a lugar nenhum. O custo disso raramente aparece em algum relatório, porque ele se dilui em horas de trabalho que parecem produtivas.

O aprendizado. Se a decisão não funcionou, fica difícil saber onde estava o problema. Pode ter sido o dado, a explicação escolhida entre várias possíveis, ou o julgamento de quem decidiu. São três erros diferentes, com correções diferentes. Sem o caminho, todos viram o mesmo erro genérico, e o que não se entende costuma acontecer de novo.

Isso acontece de verdade, e o caso mais conhecido é público

O exemplo acima é inventado, mas existe um caso real, documentado e com consequência grande, que mostra exatamente o mecanismo.

Em 2010, os economistas Carmen Reinhart e Kenneth Rogoff publicaram um trabalho relacionando dívida pública e crescimento econômico. A conclusão mais citada era que países com dívida acima de 90% do PIB apresentavam crescimento médio negativo. O número virou argumento recorrente em debates públicos sobre corte de gastos em vários países.

Em 2013, o doutorando Thomas Herndon, com os professores Michael Ash e Robert Pollin, tentou reproduzir o resultado e não conseguiu. Só quando obtiveram a planilha original usada nos cálculos é que a explicação apareceu. Havia um erro de seleção de intervalo na média, que deixou cinco países de fora da conta principal, além de decisões de exclusão de dados e de ponderação que os autores não tinham detalhado. Refeita a conta, o crescimento médio no grupo de dívida alta deixava de ser negativo.

Vale ser preciso sobre o que esse caso mostra e o que ele não mostra, porque ele costuma ser mal usado nos dois sentidos. Ele não encerra o debate econômico sobre dívida e crescimento, que seguiu depois com outros métodos e outras conclusões. O que ele mostra, e isso é o que interessa aqui, é que uma conclusão amplamente usada por três anos só pôde ser conferida quando o arquivo de trabalho ficou disponível. Enquanto existia apenas o resultado publicado, discordar dele era uma questão de opinião entre economistas. Com a planilha na mão, virou uma questão de verificação.

É a mesma diferença entre a apresentação de março e o caminho que ninguém guardou.

Não é descuido individual, é padrão

Alguém pode ler o caso acima como um deslize pontual de dois pesquisadores. A evidência disponível sugere o contrário.

Em 2016, a revista Nature consultou 1.576 pesquisadores sobre reprodutibilidade. Mais de 70% relataram já ter tentado e falhado em reproduzir o experimento de outro cientista. Mais da metade relatou ter falhado em reproduzir o próprio experimento.

Ou seja, a falha de reprodução acontece muito e quase nunca volta para quem produziu o resultado original. Se isso ocorre em um ambiente com revisão por pares, metodologia publicada e incentivo explícito à replicação, é razoável supor que ocorra pelo menos tanto dentro de uma empresa, onde nada disso existe. Essa última frase é minha leitura, não um dado da pesquisa.

A régua regulatória está andando nessa direção

Há um terceiro sinal, de outra natureza. O regulamento europeu de inteligência artificial trata registro como requisito, não como boa prática. O Artigo 12 determina que sistemas de IA classificados como alto risco permitam o registro automático de eventos ao longo de toda a vida do sistema, com o objetivo declarado de garantir rastreabilidade adequada à finalidade do sistema, apoiar o monitoramento após a colocação no mercado e permitir identificar situações de risco. As obrigações de alto risco passaram a ser aplicáveis a partir de 2 de agosto de 2026.

Duas ressalvas importantes, porque esse ponto é fácil de exagerar. Primeiro, um sistema de BI corporativo normalmente não se enquadra nas categorias de alto risco previstas no anexo do regulamento, então nada disso obriga automaticamente quem está implantando GenBI para análise interna. Segundo, o texto é preciso quanto ao objetivo e econômico quanto ao formato, o que significa que a definição de o que exatamente registrar continua sendo decisão de projeto.

O que me parece relevante, e aqui é opinião, é a direção. Quando um regulador precisa escrever que o sistema deve registrar automaticamente o que fez, é porque a prática comum era não registrar.

O que é registro, tecnicamente

Aqui vale separar registro de log, porque as duas palavras andam juntas e não significam a mesma coisa.

Um log de aplicação responde a perguntas de operação. Qual consulta rodou, quando, quanto tempo levou, se deu erro. Isso é necessário e não é suficiente, porque nenhuma dessas informações diz por que aquela consulta foi feita nem o que ela estava tentando estabelecer.

Um registro analítico precisa amarrar quatro elementos que só fazem sentido juntos:

1. 01

   A pergunta

   Na forma em que foi feita, incluindo a ambiguidade original. "Por que a margem caiu" e "a margem caiu por causa do custo" são pontos de partida diferentes e levam a investigações diferentes.

2. 02

   A consulta executada

   No texto exato, e não a descrição do que ela faz. A diferença importa porque a descrição é interpretação e a consulta é fato.

3. 03

   O resultado obtido

   Ou pelo menos o suficiente para saber o que voltou. Guardar só a consulta obriga a reexecutar para saber o que aconteceu, e reexecutar seis meses depois pode dar outro número, pelo motivo que vem a seguir.

4. 04

   A hipótese em teste naquele momento

   Esse é o elemento que quase ninguém guarda e o que mais falta depois. Consultar dados de custo por curiosidade e consultar dados de custo para verificar se o custo explica a queda produzem o mesmo SQL e significam coisas diferentes. Sem isso, o histórico vira uma pilha de consultas sem enredo.

O problema que aparece quando você tenta refazer

Existe uma armadilha aqui que só fica visível na prática. Guardar a consulta não garante que executá-la de novo devolva o mesmo resultado.

O mesmo SQL, rodado seis meses depois, pode retornar outro número por pelo menos três motivos independentes. A tabela pode ter recebido dados atrasados que se referem ao mesmo período. A estrutura pode ter mudado, com uma coluna redefinida ou um filtro de negócio incorporado à transformação. E a própria definição da métrica pode ter sido alterada, sem que a consulta mude uma vírgula, quando o cálculo vive em uma camada semântica ou em uma tabela intermediária.

Isso significa que um registro útil precisa identificar também o estado dos dados naquele momento. Na prática, isso costuma ser o horário de execução mais alguma marca de corte do dado, a versão da definição da métrica usada e a identificação da versão da transformação que gerou a tabela consultada. Sem isso, você tem um caminho que não é reproduzível, apenas legível.

Vale dizer que isso não é problema novo nem trazido pela IA. É o mesmo problema que a engenharia de dados trata com versionamento e com controle de linhagem. O que muda com GenBI é o volume.

Onde o GenBI entra

Entra dos dois lados, e as duas coisas são verdadeiras ao mesmo tempo.

Do lado do risco. Antes, uma pessoa levava algumas horas e cinco ou seis consultas até chegar a uma conclusão. Um sistema com IA generativa pode fazer quinze em poucos minutos, para várias pessoas ao mesmo tempo. Se nada disso ficar guardado, a empresa acumula muito mais análise que ninguém consegue conferir depois. O problema não é a velocidade, é a velocidade sem rastro. E há um agravante que não existia antes: quando a análise era feita por uma pessoa, havia pelo menos alguém com a memória do caminho. Um sistema sem registro não tem nem isso.

Do lado da oportunidade. Anotar o que foi feito sempre foi a parte chata do trabalho, aquela que todo mundo sabe que deveria fazer e deixa para depois. Historicamente, o registro dependia de disciplina humana, e disciplina humana é justamente o recurso mais escasso no meio de uma investigação urgente. Um sistema que executa as consultas está em posição de registrar sem depender de ninguém, porque ele já tem em mãos exatamente os quatro elementos listados acima. A pergunta chegou nele, a consulta foi ele quem gerou, o resultado passou por ele e a hipótese estava no plano que ele montou.

Uma distinção que evita ilusão

Há uma diferença que precisa ficar clara, e ela é fácil de perder.

Um sistema com modelo de linguagem pode gerar uma narrativa explicando o que fez. Essa narrativa é útil para leitura humana e não é registro. Ela é produzida depois, a partir do mesmo mecanismo que produz qualquer outro texto, e pode descrever um raciocínio mais organizado do que o que de fato ocorreu.

Registro é o que foi efetivamente executado, capturado no momento da execução. A narrativa pode acompanhar, desde que fique claro qual é qual. Quando as duas coisas se misturam, você não ganhou rastreabilidade, ganhou uma explicação convincente, que é exatamente o problema que a rastreabilidade deveria resolver.

O que perguntar em um projeto de GenBI

Se você está avaliando uma ferramenta ou construindo uma, estas perguntas separam demonstração de operação:

Depois de uma investigação de dez consultas, existe um objeto recuperável com o caminho completo, ou o histórico existe apenas na rolagem de uma conversa?

A consulta executada fica disponível em texto, e não apenas o gráfico gerado a partir dela?

O registro identifica o estado dos dados no momento da execução, de modo que alguém consiga distinguir entre um número que mudou porque a análise estava errada e um número que mudou porque o dado mudou?

A hipótese que motivou cada passo é um campo do registro ou uma inferência que alguém vai ter que fazer depois?

Existe alguém responsável por revisar esse histórico, e em que situação essa revisão acontece?

Quanto tempo esse registro é mantido, e o que é descartado?

Limites, riscos e o que este artigo não afirma

Registrar não é governar. O registro é pré-requisito. Governança envolve quem aprova a definição de uma métrica, quem pode ver o quê e o que acontece quando duas áreas chegam a números diferentes. Histórico sem responsável costuma virar apenas mais um arquivo que ninguém abre.

O registro não valida a interpretação. Ele mostra o que foi feito, não que foi a coisa certa a fazer. Uma investigação inteiramente registrada pode ter escolhido a hipótese errada desde o primeiro passo, e o registro vai documentar isso com fidelidade.

O histórico é um ativo novo, com custo e com risco. Ele contém perguntas de negócio, resultados e possivelmente dados pessoais ou informação sensível. Guardar tudo indefinidamente cria volume, custo e superfície de exposição. Definir o que registrar, por quanto tempo e com qual controle de acesso faz parte do projeto, e não é detalhe de implementação.

Os casos citados não são de BI corporativo. Reinhart e Rogoff é pesquisa acadêmica em economia. A pesquisa da Nature trata de experimentos científicos. O regulamento europeu trata de sistemas de alto risco, categoria em que um BI interno normalmente não se enquadra. Eu os uso porque documentam o mesmo mecanismo em ambientes onde ele foi estudado, e não como prova de que o mesmo número apareceria em uma empresa brasileira. Essa transposição é minha, e é uma hipótese razoável, não um dado.

Consequências práticas

Para quem lidera negócio, a pergunta ao avaliar uma ferramenta muda. Em vez de pedir uma demonstração de pergunta e resposta, peça uma investigação completa de um desvio real e peça para ver o registro no fim.

Para quem trabalha com dados e engenharia, o registro deixa de ser um extra e entra no desenho. Ele depende de coisas que já existem no repertório da área, como versionamento de transformação, marca de corte de dados e definição estável de métrica.

Para quem trabalha com IA, o desenho relevante não é o prompt. É o que persiste entre um passo e o outro, e como isso é capturado no momento em que acontece, em vez de reconstruído depois.

Para discutir

A última decisão importante que a sua área tomou com base em dados: alguém consegue refazer a análise hoje, do começo ao fim?

Quando um número de seis meses atrás é questionado, o que a sua empresa tem em mãos, além da apresentação?

Se o mesmo SQL fosse executado de novo hoje, você saberia dizer se um resultado diferente significa erro na análise ou mudança no dado?

Convite

Esse problema não é apenas de SQL, nem apenas de negócio. Ele envolve modelagem, semântica, processo de decisão e responsabilidade, e é justamente por isso que raramente é resolvido dentro de uma área só. É esse tipo de discussão, em cima de casos reais trazidos por empresas, que queremos aprofundar na GenBI Community BR.

Conheça a comunidade em genbi.com.br.