IA no Fluxo de Trabalho do Data Analyst: Onde Ajuda, Onde Falha

Um VP de Sales envia uma mensagem no Slack às 8h47. A mensagem é de uma linha: "A IA diz que a receita subiu 14%, você pode confirmar?"

Você abre o copilot da ferramenta de BI, cola o mesmo prompt que o VP usou e recebe uma consulta que roda em 1,2 segundo. O número retornado é 14%. A consulta também está errada. Ela faz junção de orders com customers pelo campo email em vez de customer_id, contando em dobro qualquer pessoa que já atualizou o endereço de e-mail. Trata status = 'completed' como receita sem filtrar reembolsos. Os 14% são aritmética real sobre um conjunto de dados equivocado.

O VP não sabe disso. O copilot não sabe disso. Você sabe, porque trabalha nesse data warehouse há nove meses e já se queimou com essas junções antes.

Este é o trabalho de verdade em 2026. Não escrever SQL mais rápido. Verificar SQL que já foi escrito, de forma plausível, por algo que não entende o negócio.

Por que isso importa agora

Todos os fornecedores de BI e todos os IDEs lançaram um recurso de "pergunte em termos simples". A liderança percebeu. O CFO leu um artigo da McKinsey sobre produtividade com IA e agora espera que a área de analytics entregue mais com o mesmo headcount. Recusar-se a usar IA faz você parecer lento. Confiar cegamente nela faz de você o carimbo humano de números alucinados que chegam ao deck do board.

A única posição sustentável é a terceira: usar IA como multiplicador de força nas partes mecânicas do trabalho e se tornar a camada de governança nas partes que não são mecânicas. O analista que consegue explicar com confiança por que uma consulta gerada pela IA está errada, corrigi-la em dois minutos e entregar a resposta certa é mais valioso em 2026, não menos. O analista que cola o output do copilot em um painel de controle e vai embora é um júnior com passos extras.

Onde a IA realmente ajuda

Seja específico. "IA ajuda com produtividade" é o tipo de frase que eu quero deletar deste artigo. Veja onde ela se paga, com nomes.

Rascunhos de SQL para refatorar

Cursor com Claude como modelo é o padrão seguro atual para analistas em atividade. Onde ele brilha é no segundo rascunho, não no primeiro. Você escreveu uma consulta de 200 linhas com cinco CTEs para calcular a retenção por coorte mês a mês. Funciona. Mas também é ilegível. Jogue no Cursor, peça uma refatoração que consolide as CTEs e adicione comentários, e você terá algo mais limpo em 30 segundos. Você lê, rejeita duas mudanças que quebraram a lógica, aceita o restante e economizou uma tarde de limpeza.

O mesmo vale para funções de janela que você escreve duas vezes por ano, self-joins complicados para dados hierárquicos e lógica de pivot. Trate o output como um primeiro rascunho de um júnior inteligente que nunca viu o seu data warehouse. Útil, mas não finalizado.

Documentação do esquema do painel de controle

Passe para o Claude o seu arquivo de modelo dbt, o LookML ou o JSON do painel de controle e peça para ele escrever a entrada do dicionário de dados. Ele vai produzir um texto revisável que está 80% correto. Você edita os 20% em que ele chutou. Tempo total: 10 minutos por painel de controle em vez de duas horas, e o modo de falha é "descrição errada", não "número errado". Muito mais fácil de detectar na revisão.

Este é o uso de IA de maior alavancagem que encontrei. Documentação é a coisa que toda equipe de analytics diz que vai fazer "no próximo trimestre" e nunca faz. A IA remove o atrito inicial.

Preparação para entrevistas de levantamento de requisitos

Antes de se reunir com uma parte interessada sobre um novo painel de controle, cole o histórico do Slack, a troca de e-mails e a solicitação aproximada no Claude. Instrua-o: "Quais são as cinco perguntas que preciso esclarecer antes de escrever SQL para esta solicitação?" Você receberá uma lista. Metade das perguntas será óbvia. Duas vão capturar ambiguidades que você não percebeu. Uma vai ser inútil. Resultado positivo em 90 segundos.

O ponto não é que a IA conhece o seu negócio. É que a IA é um pato de borracha competente que faz perguntas de acompanhamento melhores do que as suas às 9h de uma terça-feira.

Narrativa de detecção de anomalias

Você identificou o pico. A conversão caiu 23% na região sudeste, semana a semana. Você sabe que é o novo teste de precificação. Agora você precisa escrever a mensagem no Slack com a voz da equipe, com a linguagem de ressalva adequada, os próximos passos corretos e uma menção às partes interessadas afetadas. A IA rascunha essa mensagem em 15 segundos. Você edita o tom, envia e segue em frente.

Observe a ordem. Você fez a análise. A IA fez a redação. Inverta essa ordem e você está de volta ao "a IA diz que a receita subiu 14%".

Manutenção do dicionário de dados

A maioria das equipes não tem descrições de colunas no data warehouse. Nenhuma. Strings vazias. Gerar descrições automaticamente a partir do nome da coluna, mais valores de amostra, mais a tabela pai não é perfeito, mas "descrição imperfeita" supera "sem descrição" sempre. Execute como um processo em lote uma vez por trimestre, edite manualmente as obviamente erradas e publique.

Onde a IA falha

Esses são os modos de falha que enviam números errados para executivos. Memorize-os.

Semântica dos dados

orders.status = 'completed' não significa "receita" no seu data warehouse. Pode excluir pedidos com reembolso, ou não. Pode contar renovações de assinatura como pedidos separados, ou consolidá-los. Pode usar gross_amount, net_amount ou amount_after_tax_and_discount. A IA não sabe qual. A IA vai chutar. O chute será plausível. E com frequência estará errado de uma forma quase impossível de detectar apenas pela consulta. O SQL é sintaticamente perfeito, a junção compila, o número retorna. Você precisa conhecer o data warehouse para detectar o erro.

Tratamento de NULL

COUNT(column) exclui NULLs. COUNT(*) não exclui. SUM sobre uma coluna com NULLs retorna NULL se todos os valores forem NULL, mas um número se qualquer valor for não-NULL. LEFT JOIN em um relacionamento um-para-muitos explode a contagem de linhas se você esquecer de agregar. A IA erra esses casos aproximadamente metade das vezes em esquemas reais, porque metade das vezes os dados de treinamento públicos também têm o bug. Se o seu painel de controle mostrar de repente 4x o número de clientes de ontem, verifique as junções.

Lógica de negócio

"Cliente ativo" significa coisas diferentes em cada empresa. Em uma empresa B2B SaaS pode ser "fez login nos últimos 30 dias". Em um marketplace pode ser "concluiu uma transação nos últimos 90 dias". Em uma fintech pode ser "saldo acima de R$ 0 sem sinalizador de fraude". A IA usa como padrão a definição mais comum nos seus dados de treinamento, que quase certamente não é a sua. O mesmo vale para "MRR", "churn", "engajamento", "retenção". Cada métrica tem cinco definições plausíveis. A sua equipe usa uma delas. A IA não sabe qual.

Governança e linhagem de dados

A IA escreve alegremente uma consulta contra customers_legacy_v2, uma tabela descontinuada que não é atualizada desde novembro. A IA não conhece o SLA de atualização do dbt. Não sabe que a equipe de marketing bifurca a tabela de clientes às terças-feiras para uma exportação de campanha e a bifurcação tem lógica ligeiramente diferente. Não sabe que você migrou o rastreamento de receita para uma nova tabela há seis semanas e a antiga é somente leitura.

Este é o modo de falha que escala pior. À medida que o data warehouse evolui, o modelo mental da IA sobre ele fica cada vez mais defasado, e as consultas que ela gera ficam mais confidentemente erradas com o tempo.

A armadilha do "esta consulta foi gerada pela IA"

Aqui está o limite rígido. Nunca cole uma consulta gerada por IA em um painel de controle, em um relatório para partes interessadas ou em um deck executivo sem fazer todas essas quatro verificações:

1. Execute contra um resultado conhecido. Escolha um recorte que você já validou antes (o número do mês passado que o CFO já aprovou) e confirme que a consulta da IA o reproduz.
2. Observe as contagens de linhas. Se você espera cerca de 10.000 clientes e a consulta retorna 47.000, você tem uma multiplicação de linhas. Se retorna 12, você tem um filtro excessivamente restritivo.
3. Verifique as junções em busca de multiplicação de linhas. Olhe cada JOIN. O lado direito é garantidamente único na chave de junção? Se não, você precisa de DISTINCT ou agregação.
4. Confirme se o filtro de data faz o que afirma. "Mês passado" na ferramenta de BI A pode significar "últimos 30 dias". Na ferramenta B pode significar "mês calendário anterior". No SQL escrito por IA, pode ser qualquer um dos dois, mais um erro de deslocamento de um dia.

O padrão a internalizar é: A IA escreveu, eu verifiquei, eu assumo a responsabilidade. Não: A IA disse que o número é X. Se você não consegue defender a consulta linha por linha diante do VP de Finanças, não pode enviar a resposta. Se você enviar mesmo assim e estiver errada, "a IA escreveu" não é uma defesa. Você a escreveu, ao aceitá-la.

Governança e controle de versão

Trate o SQL assistido por IA como qualquer outro código. Faça commit no seu repositório dbt ou no GitHub de analytics. Use revisão de pull request, mesmo que o único revisor seja você mesmo 24 horas depois, com olhos frescos. Inclua o modelo e o prompt no comentário do commit se ele moldou materialmente a lógica, para que o você do futuro saiba de onde veio aquela estrutura estranha de CTE.

Monte um pequeno arquivo forbidden_patterns.md no repositório da sua equipe. Dez a vinte entradas, cada uma sendo uma armadilha que você pessoalmente já caiu:

• Junções que parecem corretas mas não são (o exemplo do email vs customer_id acima)
• Colunas que mudaram de significado (status costumava incluir "enviado", agora não inclui)
• Tabelas que não devem ser consultadas diretamente (raw.events é firehose, use analytics.sessions)
• Definições de métricas que diferem do padrão público (a sua definição de "usuário ativo")
• Tabelas com SLA de atualização crítico (esta tem latência de 24 horas, esta é em tempo real)

Passe esse arquivo para o contexto do Cursor em cada sessão de SQL. É a ferramenta de governança mais barata e de maior alavancagem que encontrei. A IA tem muito menos probabilidade de cair em uma armadilha conhecida se você disse a ela onde as armadilhas estão.

O plano de 30 dias para integrar IA sem perder o seu domínio técnico

Não tente incorporar IA em todo o seu fluxo de trabalho no primeiro dia. Avance por etapas.

Semana 1, calibração. Escolha uma ferramenta. Cursor mais Claude é o padrão seguro; se a sua empresa tem Copilot implantado, use-o. Use-o apenas para refatoração de SQL em consultas que você já entende e já validou. Compare cada output com o que você teria escrito. Construa um senso de onde é confiável e onde alucina. O objetivo é calibração, não produtividade.

Semana 2, documentação. Adicione as tarefas de baixo risco e alta alavancagem. Gere automaticamente entradas do dicionário de dados. Produza READMEs de painéis de controle. Escreva rascunhos de runbook para as solicitações recorrentes da sua equipe. O modo de falha aqui é uma frase que você precisa reescrever, não um número errado na mesa do CFO.

Semana 3, preparação de requisitos. Antes de cada reunião com partes interessadas, execute a IA no histórico da conversa primeiro. Peça as cinco perguntas de esclarecimento. Rastreie quais delas realmente evitaram uma reescrita. Após duas semanas, você terá um padrão do que a IA detecta e do que ela perde.

Semana 4, codifique. Escreva o ai-usage.md da sua equipe. Três seções: o que a IA tem permissão de rascunhar de forma autônoma, o que os humanos devem verificar antes do merge e o que está fora dos limites. Um ponto de partida razoável:

• Permitido: rascunhos de documentação, sugestões de refatoração, rascunhos de narrativa de anomalias após análise humana, perguntas de esclarecimento de requisitos.
• Verificar antes do merge: qualquer SQL que afete painéis de controle em produção, qualquer mudança na definição de métricas, qualquer novo modelo dbt.
• Fora dos limites: executar automaticamente SQL gerado por IA contra produção sem LIMIT 100 e revisão humana; colar qualquer coluna com PII em uma ferramenta de IA de terceiros que não tenha um DPA assinado; usar IA para escrever SQL em dialetos que você não lê fluentemente.

Esse último é o que a maioria das pessoas ignora. Se você não consegue ler a sintaxe de funções de janela específicas do Snowflake, não consegue revisar o que o Cursor escreveu. Você está confiando nele por fé. Não faça isso.

Opcional: o ângulo do ACE Framework

Se a sua empresa está implementando um Modelo Operacional de IA baseado no ACE Framework, o fluxo de trabalho do analista se encaixa perfeitamente nele. A IA cuida do Generate (rascunhando SQL, docs e atualizações no Slack) e auxilia no Analyze (resumos de anomalias, sugestões de refatoração). Os humanos são responsáveis pelo Ingest (semântica dos dados, o que cada coluna realmente significa neste negócio), pelo Predict (interpretação causal do por que uma métrica se moveu) e pelo Execute (entregando a resposta à parte interessada com confiança e uma trilha lógica defensável).

Essa é a versão em um parágrafo. O ponto é que as partes do trabalho que exigem alto nível de confiança e contexto de negócio permanecem com humanos por muito tempo. As partes mecânicas vão para a IA. A sua carreira é construída na primeira metade.

Erros comuns

Algumas armadilhas em que vejo analistas caírem, em ordem aproximada de frequência:

• Deixar partes interessadas usarem o copilot de BI de forma autônoma e tratar a revisão do analista como opcional. O copilot envia números errados; o analista leva a culpa de qualquer forma.
• Colar esquema de produção com PII em uma ferramenta de IA de terceiros que não tem um DPA. Isso é demissão imediata na maioria das empresas. Verifique antes de colar.
• Usar IA para escrever SQL em dialetos que você não lê fluentemente. O ARRAY_AGG do BigQuery não é o do Postgres; o QUALIFY do Snowflake não é o do Redshift. Você não pode revisar o que não consegue ler.
• Pular a etapa "comparar com um resultado conhecido" porque a consulta "parece certa". É assim que crescimento de receita de 14% é publicado quando o crescimento real é de 3%.
• Tratar a confiança do copilot de BI como evidência de correção. Ele vai dizer "a receita subiu 14%" com o mesmo tom, quer a consulta esteja correta ou catastroficamente errada.

Modelos e ferramentas

Três artefatos para construir nos seus primeiros 30 dias. Mantenha-os no repositório de analytics da equipe.

1. forbidden_patterns.md: comece com dez entradas do seu data warehouse. Junções reais que já queimaram alguém. Adicione uma por mês conforme você as encontrar.
2. Checklist de revisão de SQL: oito itens para executar em qualquer consulta gerada por IA antes do merge: verificação de resultado conhecido, sanidade da contagem de linhas, verificação de multiplicação de linhas, verificação de filtro de data, verificação de tratamento de NULL, verificação de lógica de negócio (o "ativo" significa o que entendemos?), verificação de governança (esta tabela está atualizada?) e verificação de legibilidade.
3. Prompt de preparação para entrevista com partes interessadas: um prompt salvo no Claude no qual você cola um histórico do Slack e recebe cinco perguntas de esclarecimento. Refine-o mensalmente.
4. ai-usage.md: a política da sua equipe. Documento vivo. Revise trimestralmente.

Medindo o sucesso

Você saberá que está funcionando quando três coisas forem verdadeiras. Você entrega mais rápido no lado de documentação e refatoração, e consegue apontar entregas específicas que não existiam antes. As partes interessadas confiam mais nos seus números, não menos, porque você está rotineiramente detectando os erros do copilot de BI antes que cheguem ao Slack. E você consegue articular, em uma frase por consulta, por que o primeiro rascunho da IA estava errado.

Essa última frase é a que faz de você um profissional mais sênior em 2026, não mais substituível. "Ele fez a junção por e-mail em vez de customer_id." "Estava faltando o filtro de reembolso." "Usou a tabela de receita descontinuada." Cada frase é um pedaço de julgamento específico do data warehouse que a IA não tem e não pode ter sem você. Esse é o diferencial. Construa-o.

O trabalho não é mais digitar a consulta. O trabalho é ser responsável pela resposta. A IA escreveu, você verificou, você assume a responsabilidade. Essa é a linha. Esse é o artigo inteiro.

Saiba Mais

• Um Dia na Vida de um Data Analyst
• Seus Primeiros 30/60/90 Dias como Novo Data Analyst
• Modelo de Descrição de Cargo para Data Analyst
• ACE Framework