Como a Anthropic automatizou 95% das análises de negócio com IA?

Com uma stack de 4 camadas: (1) Data Foundations — datasets canônicos com governança via CI; (2) Sources of Truth — camada semântica, grafo de linhagem e knowledge graph de negócio; (3) Skills — arquivos Markdown com conhecimento procedural que ensinam o agente quais fontes consultar e em que ordem; (4) Validation — testes offline, ablação, revisão adversarial e monitoramento online. A camada de Skills sozinha elevou a precisão de 21% para 95%.

Por que analytics com IA falha mesmo quando o modelo sabe escrever SQL?

A Anthropic identificou três modos de falha que não têm a ver com geração de código: (1) ambiguidade conceito-para-entidade — 'usuários ativos' pode significar dezenas de coisas diferentes em tabelas diferentes; (2) estagnação do conhecimento — schemas e definições mudam constantemente e o contexto do agente envelhece; (3) falha de recuperação — a informação correta existe mas o agente não consegue achar num espaço de busca de milhões de campos.

O que são Skills em Markdown e como elas funcionam?

Skills são documentos Markdown que ensinam ao agente conhecimento procedural: quais fontes consultar, em que ordem, com quais ressalvas e quais tabelas evitar para cada tipo de pergunta. Funcionam como um documento de onboarding para um analista novo. Na Anthropic, são versionadas no mesmo repositório dos modelos de transformação de dados, e ~90% dos PRs de data model incluem atualização de skill.

Quanto tempo leva para a precisão de um agente analítico degradar sem manutenção?

No caso da Anthropic, a precisão caiu de ~95% para ~65% em apenas um mês sem manutenção das skills. O modelo e o agente eram os mesmos — o que mudou foi que o contexto procedural ensinado a ele ficou desatualizado em relação ao data warehouse. A lição é que acurácia de IA analítica é dívida técnica: sem monitoramento e manutenção contínua, ela decai rapidamente.

Preciso de um modelo de IA mais potente para ter boa precisão em analytics?

Não. O caso da Anthropic mostra que o salto de 21% para 95% de precisão veio do framework de Skills, não de um upgrade de modelo. O gargalo em analytics com IA raramente é a qualidade do SQL gerado — é a capacidade do agente de mapear perguntas ambíguas de negócio para as entidades corretas no data warehouse. Invista em camada semântica e skills antes de gastar com modelos mais caros.

Como a Anthropic Levou Análise de Dados com IA de 21% para 95% de Precisão — Sem Tocar no Modelo

Toda empresa que adota IA para análise de dados começa pelo mesmo lugar: pergunte qualquer coisa em linguagem natural, o modelo escreve SQL, você recebe a resposta. Depois de 3 perguntas erradas, o time de dados desliga o acesso e volta a escrever query na mão. A Anthropic resolveu esse problema para uso interno e documentou tudo num artigo de 3 de junho de 2026. O número principal — 95% das consultas de negócio automatizadas com ~95% de precisão — é impressionante. Mas o que realmente importa está no caminho até ele: o sistema começou com apenas 21% de precisão, e a virada não veio de um modelo mais forte. Veio de um framework de Skills em Markdown.

O problema real: SQL não é o gargalo — contexto é

A Anthropic identificou três modos de falha que matam qualquer agente analítico. Nenhum deles tem a ver com escrever SQL errado:

(1) Ambiguidade conceito-para-entidade. "Usuários ativos" pode significar dezenas de coisas diferentes dependendo da tabela, do time e do mês. O modelo sabe escrever SELECT COUNT(DISTINCT user_id) — ele não sabe qual das 14 tabelas de usuário usar para a pergunta do CFO.

(2) Estagnação do conhecimento. Schemas mudam, definições de negócio evoluem, colunas são renomeadas. O agente que acertava 90% em janeiro erra 50% em março porque o contexto que ele usa envelheceu. O prompt é o mesmo — o data warehouse não.

(3) Falha de recuperação. A informação correta existe em algum lugar — numa documentação, num schema comment, numa query antiga — mas o agente não consegue achar num espaço de busca de milhões de campos. Isso é o equivalente analítico de "estava na documentação, só ninguém leu".

A stack de 4 camadas que tirou a precisão de 21% para 95%

A solução não foi trocar de modelo. Foi construir 4 camadas de contexto que ensinam o agente a navegar o data warehouse como um analista sênior faria:

Camada 1 — Data Foundations. Datasets canônicos de fonte única de verdade, com governança aplicada via CI. Nada de "cada time tem sua versão da tabela de receita". Sem isso, qualquer agente analítico está morto antes de nascer.

Camada 2 — Sources of Truth. Camada semântica, grafo de linhagem de dados, corpus de queries curadas e um knowledge graph de contexto de negócio. Isso traduz "receita do Q2" para a tabela, coluna e filtro exatos que respondem a pergunta.

Camada 3 — Skills. Aqui está o pulo do gato. Skills são pastas de arquivos Markdown com conhecimento procedural: quais fontes consultar, em que ordem, com quais ressalvas. Pense numa skill como um onboarding document para um analista novo — "quando te perguntarem sobre churn, não use a tabela de cancelamentos direto; passe primeiro pela tabela de assinaturas ativas e filtre por data de expiração". Essa camada sozinha levou a precisão de 21% para 95%.

Camada 4 — Validation. Testes offline, testes de ablação (remover uma skill e medir o impacto), revisão adversarial e monitoramento online. Se uma skill nova não melhora a precisão, ela não mergeia. É engenharia de software aplicada a conhecimento de domínio.

O alerta que vale o artigo inteiro: acurácia decai 30pp em um mês sem manutenção

Esse é o achado mais subestimado do artigo. Quando as skills não eram atualizadas junto com as mudanças no data warehouse, a precisão despencou de ~95% para ~65% em um único mês. Um mês. O agente era o mesmo. O modelo era o mesmo. O que mudou foi que o contexto procedural ensinado a ele ficou velho.

A solução foi colocalizar os arquivos de skill no mesmo repositório dos modelos de transformação. Hoje, ~90% dos PRs de data model na Anthropic incluem uma atualização de skill correspondente. A manutenção do conhecimento do agente virou parte da definição de "done" de qualquer mudança no warehouse. Isso é o que separa um protótipo de analytics com IA de um sistema que sobrevive ao ciclo de vida dos dados.

O que isso significa para times que não são a Anthropic

Na minha leitura, o artigo entrega três princípios que qualquer time de dados pode aplicar a partir de amanhã:

(1) Não comece pelo modelo — comece pela camada semântica. Se o seu agente não sabe qual tabela de "usuários" usar, nenhum upgrade de LLM resolve. Invista em datasets canônicos, glossário de métricas e um corpus de queries validadas antes de gastar um centavo em tokens.

(2) Skills em Markdown são o novo onboarding de analista. Escreva documentos curtos que ensinem o agente o fluxo de raciocínio — não só os comandos, mas a ordem, as ressalvas e os "não use essa tabela para isso". Trate esses documentos como código: versionados, revisados e testados.

(3) Acurácia é dívida técnica como qualquer outra. Se o gráfico de precisão do seu agente não é monitorado, ele já está caindo. O decay de 30pp em um mês que a Anthropic reportou não é exceção — é o estado padrão de qualquer sistema de IA que depende de contexto externo sem manutenção colocalizada.

Conclusão: o modelo é commodity — o contexto é o produto

Esse artigo da Anthropic é um dos raros casos em que o título não entrega a lição real. 95% de automação em analytics é manchete. Mas a lição que fica é outra: a diferença entre 21% e 95% de precisão não foi um modelo melhor — foi contexto procedural organizado, versionado e mantido colocalizado com os dados que ele descreve. O artigo completo está no blog do Claude. Se você está montando um agente analítico, gaste 20% do tempo integrando o modelo e 80% escrevendo as skills que ensinam ele a navegar seu data warehouse. O modelo você troca em uma linha de config. O contexto procedural ninguém vai escrever por você.