IA no Fluxo de Trabalho do Analista de Negócios: Onde Ajuda, Onde Falha

São 9h14 de uma segunda-feira. Um VP encaminha um print do Slack. O assistente de IA da nova ferramenta de CSM diz que os clientes ativos cresceram 38% no último trimestre. O executivo quer colocar esse número no deck do conselho até a hora do almoço.

Você abre o warehouse. O número real é próximo de 12%. O chatbot contou todas as linhas em customers independentemente do status, ignorou a flag is_test que o engenheiro de dados adicionou em fevereiro, e somou discretamente uma métrica que zera mensalmente como se fosse cumulativa. Você tem quarenta minutos para explicar o que deu errado sem soar como alguém com medo de ser substituído por automação.

Essa é a vida do BA agora. Toda ferramenta de BI lança um recurso de "pergunte em português claro". Todo IDE tem autocomplete que escreve joins. A maior parte do output é SQL errado-mas-confiante: queries que rodam, retornam números e contam errado de formas que não disparam nenhum guardrail. Alguém precisa ser a última linha de defesa. Esse alguém ainda é você, e as ferramentas não tornaram o trabalho mais fácil, apenas deslocaram onde as partes difíceis estão.

Aqui está a visão do BA que trabalha de verdade, escrita para quem já subiu painéis reais e cometeu erros reais.

Onde a IA Genuinamente Ajuda o BA

Há alavancagem real aqui. Recusar isso por princípio tem a mesma energia dos analistas que insistiam em escrever todo join à mão em 2014 porque IDEs eram "para juniores." O trabalho mudou. Cinco lugares onde a IA cumpre o que promete:

Rascunhos de SQL para refatorar. Esqueletos de joins, sintaxe de window functions, regex para aquele campo de log que ninguém documentou. Você dá ao Claude os nomes das colunas e uma descrição de uma linha do que quer, e ele retorna uma query que está 70% correta e 100% melhor do que começar de um arquivo em branco. Então você refatora. O modelo é mais rápido que seus dedos; seus dedos nunca foram o gargalo.

Documentação de schema de painel. Quarenta e três colunas em fact_orders, três delas com nomes como flag_2 e legacy_amt_v3. Cole o schema e o histórico recente de commits em um modelo e peça para ele rascunhar descrições de colunas. Você vai corrigir metade delas. Você também terá escrito documentação que antes não existia, o que supera a versão em que ela nunca é escrita.

Preparação para entrevista de requisitos. Antes de um kickoff com partes interessadas, peça ao modelo que gere as perguntas incômodas que você costuma esquecer, como "o que significa 'churn' aqui, mês calendário ou 30 dias corridos?" ou "como lidamos com contas que fazem downgrade e depois upgrade no mesmo período?" O modelo não conhece o seu negócio. Ele é bom em lembrar você das categorias de perguntas que você precisa fazer de qualquer forma.

Detecção de anomalias em datasets conhecidos. Aponte um modelo para uma série temporal e pergunte "onde uma pessoa cuidadosa olharia primeiro?" Ele vai sinalizar as coisas certas: surtos súbitos de nulos, picos pontuais, dias em que a contagem de linhas cai para um número arredondado que sugere carga parcial. Você ainda precisa investigar. O modelo apenas comprime o escaneamento.

Manutenção do dicionário de dados. Transformar tickets do Jira em entradas de glossário é um trabalho chato. Colocar um ticket fechado em um modelo e pedir uma definição de um parágrafo é o tipo de escrita mecânica que a IA faz de forma adequada e que você nunca teria tempo de fazer de outra forma.

Observe o padrão: a IA é útil quando a entrada é delimitada e você permanece como editor. No momento em que o modelo é o autor final, as coisas começam a escorregar.

Onde a IA Falha Silenciosamente

Esta é a seção que importa. As falhas não são barulhentas. A query roda. O gráfico renderiza. O número está errado de uma forma que leva trinta minutos de arqueologia no warehouse para provar.

Semântica de dados. Sua tabela orders tem uma coluna status com valores como pending, processing, shipped, delivered, returned, void, chargeback e legacy_v2. Quais desses significam "efetivamente uma venda"? Sua equipe de Finanças tem uma opinião. Sua equipe de Operações tem uma opinião diferente. O modelo não conhece nenhuma das duas e escolherá a opção que soa mais plausível, geralmente delivered, que está errada em cerca de 8% dos casos por causa de devoluções lançadas em um lote separado.

Tratamento de nulos. O modelo usa verificações WHERE column IS NULL por padrão. Seu warehouse usa strings vazias, datas sentinela como 1900-01-01, a string literal "NULL" e uma coluna onde valores ausentes são codificados como -999. O modelo não vai capturar nenhum desses a menos que você informe. A maioria dos BAs esquece de informar porque internalizou as peculiaridades e não as enxerga mais.

Lógica de negócio. "Cliente ativo" tem pelo menos seis definições em qualquer warehouse com mais de dois anos. Logou neste mês. Tem uma assinatura paga. Tem uma assinatura paga e não está em dunning. Tem uma assinatura paga, não está em dunning e não está marcado como conta de teste. Usou o produto nos últimos 14 dias. Era ativo conforme o snapshot de Finanças no fechamento do mês. O modelo vai escolher uma. Não vai dizer que escolheu. O CRO vai citar o número resultante em uma reunião do conselho.

Governança. Colar linhas de clientes em uma janela de chat é um evento de exfiltração de dados. Colar o schema é discutível. Colar planos de query que incluem PII real é um incidente real. A maioria dos BAs não pensa em "perguntar ao Claude" como movimentação de dados, mas o Jurídico pensa, e o próximo auditor também.

Eu vi cada um desses quebrar uma análise real nos últimos doze meses. Nenhum deles se anuncia. A query roda. Esse é o ponto.

O Loop Cursor + Claude para SQL

Como isso funciona na prática, para mim e para os BAs em quem confio:

Etapa 1: Force as premissas antes do código. O primeiro prompt nunca é "escreva a query." É "antes de escrever SQL, liste todas as premissas que você precisaria assumir para responder esta pergunta com este schema." Cole as definições de tabela relevantes. O modelo retorna uma lista. Você a edita. Cerca de um terço das premissas estará errado, e é melhor argumentar com uma lista do que com uma query pronta.

Um exemplo real. A questão: "contas ativas mensalmente por nível de plano no T1." As premissas do modelo, levemente editadas:

1. "Ativo" significa last_activity_at dentro do mês calendário.
2. O nível do plano é accounts.plan_id unido a plans.tier_name.
3. Contas de teste (is_test = true) são excluídas.
4. Contas em período de avaliação contam como ativas.
5. Contas com múltiplas mudanças de plano em um mês são atribuídas ao plano no fim do mês.
6. O fuso horário é UTC.

Os pontos 4 e 5 estão errados para nosso padrão de relatórios. Contas em avaliação não contam, e nós atribuímos pelo plano do início do mês porque é assim que Finanças faz. Capturar isso aqui evita uma query que reporta a forma certa com os números errados.

Etapa 2: Rascunho no Cursor. Com as premissas corrigidas, peça a query. O editor do Cursor permite ver o schema na barra lateral, o que significa que o modelo tem menos chances de alucinar nomes de colunas. Ele ainda vai alucinar um ou dois. É por isso que você o lê.

Etapa 3: Refatore como um PR de dbt. Trate a query gerada por IA da forma como trataria o PR de um júnior. Comentários no topo observando o propósito, as premissas e "rascunho com assistência de IA, refatorado por [você]." Notas inline em qualquer join não óbvio. Contagens de teste no final (SELECT COUNT(*) FROM final contra uma referência conhecida) antes de enviar o resultado para alguém.

Etapa 4: Rode contra o warehouse, duas vezes. Uma vez em um intervalo de datas pequeno para verificar o formato. Uma vez no intervalo real para obter a resposta. Se ambos os números parecerem implausíveis, são. O modelo tem zero opinião sobre plausibilidade. Você tem.

Esse loop não é mais lento do que escrever SQL do zero para a maioria das queries não triviais. É materialmente mais rápido. Também é materialmente mais seguro do que a versão em que você aceita o primeiro rascunho.

A Armadilha "A IA Gerou Esta Query"

Há uma nova desculpa circulando. Alguém entrega um número errado. O post-mortem acontece. A frase aparece: "a IA gerou esta query."

A frase está fazendo dois trabalhos. O honesto: "eu estava usando uma ferramenta, a ferramenta errou, não percebi." Certo, isso acontece, registre e siga em frente. O desonesto: "a responsabilidade por este número é do modelo, não minha." Isso é o equivalente moderno de citar a Wikipedia em uma petição judicial e dar de ombros quando a citação resulta ser uma edição de brincadeira de 2009.

Se você enviou o número, você é responsável pelo número. Se você rodou a query, você é responsável pela query. O modelo é uma ferramenta de escrita. Você é o analista. As partes interessadas não se importam com a cadeia de custódia além do seu nome no ticket, e não deveriam ter que se importar.

A versão prática desta regra: nunca cole o output de um modelo em um ticket de parte interessada sem antes rodá-lo no warehouse. Não "olhar para ele." Rodá-lo. Com uma contagem de linhas. Contra o schema real, com os filtros reais, no intervalo de datas real. Se você estiver prestes a pular essa etapa porque o prazo é apertado, o prazo sempre foi apertado, e pular é como o número errado acaba citado em um deck do conselho.

Governança e Versionamento

Trate a análise com assistência de IA como qualquer outro código, porque é código. Uma checklist funcional:

• Revisão de PR. Toda query com assistência de IA que vai para um painel ou relatório recorrente passa pela mesma revisão de uma feita à mão. Sem exceções para "é apenas um número rápido."
• Comentários indicando assistência. Uma linha de cabeçalho: -- Rascunho com assistência de IA (Claude, 2026-04-28); refatorado e validado por [seu nome]. Isso é para o próximo analista, não para o modelo.
• Sem PII nos prompts. O schema é permitido. As primeiras três linhas geralmente são permitidas se forem dados de teste. Linhas de clientes reais, endereços de e-mail, detalhes de pagamento, registros de funcionários: nunca. Use amostras sintéticas ou apenas descrições de colunas.
• Logs de prompt para auditoria. Cursor e Claude têm histórico. Não os limpe. Quando algo quebrar daqui a seis meses, você vai querer encontrar o prompt original.
• Lista de datasets com acesso restrito. Algumas tabelas nunca são enviadas para uma API de terceiros. Registros de HR, financeiros de clientes, qualquer coisa sob uma regra de residência de dados regional. Escreva a lista. Fixe-a no canal Slack do BA. Novos contratados a leem antes de receberem acesso ao warehouse.

O trabalho de governança é pouco glamouroso. Também é a diferença entre a IA ser um multiplicador de produtividade e a IA ser a causa nomeada no relatório de incidente de dados do próximo ano.

Opcional: Onde Isso Se Encaixa no ACE Framework

Para equipes que usam o ACE Framework para mapear capacidades de IA em todo o negócio, o trabalho de BA com assistência de IA está claramente em Analyze no nível de Capabilities (nível 2 de 5). Você está usando IA para interpretar dados existentes e produzir decisões, não para ingerir novas fontes (Ingest), prever (Predict), rascunhar documentos (Generate) ou tomar ações downstream (Execute).

Esse enquadramento é útil porque diz o que a IA não está fazendo para o BA: não está construindo pipelines de dados, não está rodando modelos contra dados futuros, não está enviando e-mails automáticos para partes interessadas. Esses estão em outras linhas do ACE e têm seus próprios modos de falha. Manter as faixas limpas mantém as conversas limpas.

O Plano de 30 Dias

Se você leu até aqui e quer uma forma de começar sem reescrever todo o seu fluxo de trabalho, aqui está. Escolha uma tarefa de SQL recorrente e rode o experimento.

O objetivo dos 30 dias não é "adotar IA." É aprender, no seu warehouse específico, onde o modelo mente. Todo warehouse mente de formas diferentes. O conselho genérico sobre IA ignora isso; é por isso que a maior parte dele é inútil.

Após 30 dias você terá uma noção calibrada da alavancagem. Você saberá quais tarefas são 3x mais rápidas com IA e quais são mais lentas porque a verificação consome o ganho. Você terá escrito as coisas que sua equipe vinha carregando na cabeça, o que é um presente separado para o seu eu futuro.

Conclusão

A IA no fluxo de trabalho do BA é um júnior ágil no primeiro dia. Útil, empenhado e confiantemente errado. A alavancagem é real, e o modo de falha também. O trabalho não mudou: entenda a questão, entenda o warehouse, entregue o número certo. As ferramentas mudaram onde as partes difíceis estão.

O BA que sabe onde o modelo mente é mais valioso, não menos. O BA que trata o modelo como autor final é aquele cujo nome aparece no relatório de incidente do próximo ano ao lado de "a IA gerou esta query."

Escolha o primeiro.

Saiba Mais

• Modelo de Descrição de Cargo de Analista de Negócios
• SQL e Design de Painel Que Gera Confiança
• Levantamento de Requisitos Que Não Se Transforma
• Armadilhas Comuns do Analista de Negócios