IA no Fluxo de Trabalho do Data Scientist: O Que Automatizar, O Que Nunca Tocar

Na primeira vez que o Copilot alucionou um nome de coluna para mim, o modelo treinou mesmo assim. O pull request fez um join de customer_id contra uma coluna chamada customer_uuid que não existia na tabela do lado direito. O Pandas fez o que o Pandas faz: produziu NaNs silenciosamente para cada linha, não gerou erro algum, e o join "funcionou". O modelo downstream treinou bem. O AUC de validação pareceu normal. Só percebi o problema três dias depois porque uma parte interessada perguntou por que um coorte específico havia sumido do resultado.

Ninguém avisa sobre esse tipo de falha. O marketing de ciência de dados assistida por IA está cheio de demos onde o modelo escreve um pd.merge impecável contra um dataset de brinquedo limpo. O modo de falha real é silencioso. O código roda, os resultados parecem plausíveis, e o bug aparece depois que você já apresentou o gráfico.

Então aqui está o limite que tracei depois de cerca de dezoito meses usando essas ferramentas diariamente, escrito para Data Scientists que estão cansados tanto do hype quanto da rejeição reflexiva. Ambos os extremos estão errados. Existe um meio-termo que entrega mais rápido sem que a qualidade do seu modelo regrida, e este guia tenta descrever isso de forma concreta.

Por que isso importa agora (e por que a maioria do conteúdo sobre "IA em DS" está confusa)

Existem duas coisas completamente diferentes que as pessoas querem dizer quando falam em "IA na ciência de dados", e confundi-las produz conselhos incoerentes.

A primeira é a IA como aceleradora de fluxo de trabalho para o trabalho existente de ciência de dados: código boilerplate, scripts de EDA, docstrings, rascunhos de slides. É o que o Copilot do seu IDE, o Cursor e o Claude fazem. O trabalho continua sendo construir modelos e explicá-los. A IA é uma máquina de escrever mais rápida.

A segunda é construir aplicações baseadas em LLM: sistemas RAG, pipelines de agentes, frameworks de avaliação para outputs generativos. Esse é um trabalho diferente. As habilidades se sobrepõem (você ainda precisa de estatística, ainda precisa pensar em avaliação), mas os modos de falha, a cadeia de ferramentas e o trabalho do dia a dia são diferentes de treinar um modelo XGBoost.

Quando a liderança diz "adicione IA ao seu fluxo de trabalho", geralmente querem dizer o primeiro. Quando dizem "construa uma funcionalidade de IA", geralmente querem dizer o segundo. Se você não separar esses dois casos, vai desperdiçar um trimestre tentando aplicar padrões RAG a um problema de previsão de rotatividade, ou pior, vai publicar um chatbot usando intuição de XGBoost e ficar se perguntando por que suas avaliações não funcionam.

O restante deste guia trata principalmente do primeiro caso. Há uma seção perto do final sobre o segundo.

Onde a IA realmente ajuda (use diariamente)

Esses são os lugares onde deixo a IA escrever os primeiros rascunhos todos os dias, com revisão leve:

Código boilerplate. Reshapes com Pandas que escrevi centenas de vezes: pivot, melt, cadeias de groupby. Scaffolding de Pipeline e ColumnTransformer do sklearn. Grids de subplots do Matplotlib. As partes mecânicas onde a estrutura é fixa e só os nomes das colunas variam. O Cursor ou o Copilot acerta isso em 90% das vezes, e os 10% em que erra são fáceis de identificar porque você já sabe como o output deveria ser.

Scripts de EDA. Gráficos de distribuição na primeira passagem, contagem de nulos, heatmaps de correlação, contagens de valores em cada coluna categórica. A passagem "me mostre o formato deste dataset". A IA é boa nisso porque os padrões são formulaicos e o output é visual, então você vai ver se algo parece estranho. Ainda escrevo a segunda passagem de EDA por conta própria, porque é aí que o pensamento real acontece.

Docstrings e type hints. Quando você já sabe o que a função faz e só precisa documentá-la. Destaque a função, use o prompt "escreva uma docstring no estilo numpy com exemplos" e revise. Economiza vinte minutos por módulo em um codebase real.

Rascunhos de slides e resumos para partes interessadas. Apenas primeiros rascunhos. Escrevo um parágrafo com pontos sobre o que o modelo faz e qual foi o resultado, depois peço ao Claude para transformar isso em três slides para um público não técnico. Em seguida, reescrevo cerca de 60% do conteúdo. O primeiro rascunho é a parte chata: estrutura, transições, repetição para ênfase. A reescrita é onde adiciono as partes que realmente importam.

Resumos de revisão bibliográfica. Insiro cinco resumos de artigos e pergunto "quais desses são relevantes para prever rotatividade de clientes a partir de dados de fluxo de eventos, e qual é o método central em cada um?" O output é uma lista de triagem. Depois leio os artigos que realmente preciso ler. Isso é sumarização, não interpretação, e funciona porque é verificável. Se o resumo diz que o artigo 3 usa transformers, posso conferir.

O padrão em todos esses casos: a IA é boa nas partes onde você já sabe como é o "certo", então consegue detectar os erros. É um acelerador de digitação, não um substituto do raciocínio.

Onde a IA quebra (nunca delegue)

Essas são as partes que não deixo a IA tocar, e vou explicar o motivo em cada caso:

Inferência causal. Fatores de confusão, viés de seleção, estratégia de identificação, a questão de se um coeficiente de regressão tem algum significado causal. Os LLMs vão felizmente escrever um modelo de propensity score para uma pergunta que precisa de um desenho de diferença-em-diferenças. Eles não conhecem o seu processo de geração de dados. Não sabem quais variáveis são pós-tratamento. Não sabem que o seu "grupo de controle" foi selecionado pelo outcome. Uma afirmação causal errada dita com confiança é pior do que nenhuma afirmação, e a IA é muito boa em estar errada com confiança sobre isso.

Decisões de modelagem. Qual algoritmo usar, qual função de perda, qual esquema de validação, como lidar com vazamento de dados. Essas são escolhas de julgamento que dependem do contexto de negócio, do formato dos dados e para que o modelo serve. O Copilot vai sugerir random forests para tudo porque random forests aparecem com mais frequência nos dados de treinamento. Ele não sabe que o seu problema tem vazamento temporal que quebra todo esquema de validação cruzada exceto um de encadeamento progressivo. Você precisa tomar essas decisões por conta própria.

Interpretação de atributos. O que um valor SHAP significa neste contexto de negócio. A IA pode gerar o gráfico SHAP. Pode descrever o que são valores SHAP em abstrato. Não consegue te dizer se "tenure tem um alto valor SHAP" significa que tenure é causalmente importante ou apenas que tenure é um proxy para outra coisa que você não está medindo. Isso requer conhecer o negócio.

Enquadramento de negócio. Traduzir "o modelo diz que a probabilidade de rotatividade é 0,73 para este segmento" em "devemos mudar a cadência de renovação para contas acima de $50k". Essa é uma tradução de tomada de decisão, e errar nisso é como a ciência de dados perde credibilidade. O LLM não sabe qual é a tolerância a risco da sua empresa. Não sabe quais partes interessadas são céticas em relação ao trabalho com dados e precisam de evidências extras. Não sabe que da última vez que você propôs uma intervenção similar ela falhou.

Em resumo: a IA está bem para o o quê. Nunca a use para o por quê ou o e daí.

O stack de ferramentas que realmente funciona

Depois de experimentar a maioria delas, este é o stack em que me apoio como Data Scientist em 2026:

Cursor para código. É o VS Code com melhor integração de LLM. O recurso Composer (onde você descreve uma mudança em múltiplos arquivos e deixa ele propor edições) é genuinamente útil para refatorar um pipeline de atributos em três arquivos. Mantenho o autocomplete ativado para boilerplate e desativo quando estou pensando em lógica. Essa troca de modo importa.

Claude (ou equivalente) para revisão de código. Antes de abrir um PR, colo o diff no Claude com um prompt como: "Revise isso para correção, não para estilo. Foco em: referências a colunas, erros off-by-one, vazamento de dados, APIs obsoletas e casos extremos no tratamento de nulos." Ele detecta problemas. Nem sempre, mas com frequência suficiente para eu continuar fazendo isso. É um segundo par de olhos disponível às 23h antes de um prazo.

IA nativa de notebooks (Hex Magic, Deepnote AI) com rédea curta. São ótimos para a passagem de EDA: "mostre-me a distribuição de cada coluna numérica" ou "encontre correlações acima de 0,7". Não deixo que escrevam a análise final. A rédea é a regra de que qualquer coisa que eles gerem precisa ser re-executada em um notebook limpo antes de sair do meu computador, e leio cada linha de SQL gerado. A conveniência é real, a confiança é limitada.

O motivo pelo qual um par de ferramentas supera uma ferramenta única: cada uma tem pontos cegos diferentes. O Cursor é bom em contexto local (o arquivo em que você está) mas ruim para entender como seus dados realmente parecem. O Claude é bom em raciocínio de alto nível ("isso faz sentido?") mas não tem o contexto do seu IDE. Ferramentas de notebook são boas para olhadas rápidas nos dados, mas tendem a escrever código descartável. Você quer ferramentas diferentes para trabalhos diferentes, não uma única ferramenta tentando fazer os três de forma ruim.

A armadilha do "LLM escreveu a análise"

Esse é o modo de falha que mais vejo em DS júnior e pleno, e cada vez mais em DS sênior que deveriam saber melhor.

O padrão: você termina a modelagem, tem uma tabela de resultados, cola no ChatGPT e pede "resuma as principais descobertas". Ele escreve uma narrativa confiante, articulada e bem estruturada. Você edita levemente, cola no relatório e publica.

O problema é que o LLM está fazendo correspondência de padrões com o que as conclusões de ciência de dados costumam parecer, não com o que seus dados realmente mostram. Ele vai dizer coisas como "o modelo demonstra forte desempenho preditivo, com a importância dos atributos sugerindo que o engajamento do cliente é o principal fator determinante." Essa frase é estruturalmente correta e pode ser completamente falsa. O modelo pode estar tendo bom desempenho apenas por causa de um atributo com vazamento de dados. "Engajamento do cliente" pode ter alta importância apenas porque é quase um duplicado do target.

Isso é o equivalente moderno do p-hacking. O p-hacking era sobre encontrar uma história que se encaixasse nos dados por meio de buscas suficientes. A armadilha da análise com LLM é obter uma história escrita para os dados sem verificar se ela é verdadeira. A história é plausível, a prosa está limpa e a afirmação subjacente está errada.

Como saber se você caiu na armadilha: se não conseguir, linha por linha, apontar o número específico nos resultados que sustenta cada frase do resumo, você está preso nela. A solução é escrever a análise por conta própria e depois pedir ao LLM para editar para maior clareza. Editar um rascunho que você escreveu é fundamentalmente diferente de gerar um rascunho a partir de números, mesmo que a contagem final de palavras seja a mesma.

IA para ML versus construir aplicações LLM

Um esclarecimento rápido porque isso confunde conversas de equipe constantemente.

Um Data Scientist usando o Copilot para construir um modelo de rotatividade está fazendo ML clássico com um IDE assistido por IA. O modelo é XGBoost ou uma rede neural. A avaliação é AUC, calibração, impacto no negócio. A implantação do modelo é um job de pontuação em lote ou uma API em tempo real. Os modos de falha são vazamento de dados, desvio do modelo e descalibração.

Um Data Scientist construindo um sistema RAG ou um agente LLM está fazendo algo diferente. O "modelo" é um modelo fundacional que você não treinou. A avaliação é qualitativa ou baseada em LLM-judge, não em AUC. A implantação do modelo é um serviço com templates de prompt, índices de recuperação e guardrails. Os modos de falha são alucinação, injeção de prompt e custo descontrolado.

Ambos são trabalhos legítimos. Ambos podem estar no prato de um Data Scientist. Mas não são a mesma habilidade, e um DS sênior excelente no primeiro pode ser mediano no segundo até colocar o tempo necessário. Quando a liderança disser "adicione IA ao produto", pergunte qual dos dois eles querem dizer. Se não souberem, essa é a primeira conversa a ter, não uma tarefa de codificação.

Uso opcional do ACE Framework

Se sua equipe usa o ACE Framework (Ingest, Analyze, Predict, Generate, Execute), a maior parte do trabalho clássico de DS fica em Analyze e Predict. Construir aplicações LLM fica em Generate. Isso não é só vocabulário. É uma forma de recuar quando o escopo cresce demais. Quando um PM pede "você pode adicionar uma funcionalidade de IA generativa ao modelo de rotatividade", você pode dizer: "o modelo de rotatividade é uma capacidade Predict; o que você está descrevendo é uma capacidade Generate, que é um sistema diferente com avaliação diferente. Vamos escopo-los separadamente." O framework lhe dá palavras para o limite que você já sabe que existe.

O plano de adoção de 30 dias

Este é o plano que eu seguiria se estivesse começando do zero, ou integrando um DS júnior ao trabalho assistido por IA:

Semana 1: Somente boilerplate e docstrings. Instale o Cursor e configure uma conta no Claude. Use-os apenas para completar código em tarefas mecânicas (reshapes com Pandas, pipelines do sklearn) e para escrever docstrings em funções que você já escreveu. Mantenha uma nota em execução (apenas um arquivo de texto) toda vez que a sugestão estiver errada. Ao final da semana, você deve ter cerca de 20 exemplos de modos de falha específicos do seu codebase. Esses são dados de calibração. Eles dizem quando confiar na ferramenta e quando ignorá-la.

Semana 2: Adicione assistência de EDA. Escolha um projeto concluído onde você já sabe o que a EDA deveria ter mostrado. Re-execute a passagem de EDA com assistência de IA e compare com o seu trabalho original. Anote especificamente o que a IA perdeu (geralmente perde o material contextual, como "esta variável parece normal mas é na verdade um vazamento do futuro") e o que ela detectou mais rápido do que você teria. Ao final da semana, você deve ter uma regra escrita sobre quando a EDA com IA é útil e quando não é.

Semana 3: Loop de revisão de código. Para cada PR que você abrir, cole o diff no Claude primeiro com um prompt de revisão de código. Registre: quantos PRs receberam comentários úteis do Claude? Quantos bugs o Claude detectou que os revisores da sua equipe teriam perdido? Quantos falsos positivos? Depois de uma semana, você terá uma noção de se esse loop vale a pena manter. Para mim, valeu, mas a calibração é por equipe.

Semana 4: Escreva o documento "onde usamos IA / onde não usamos" da sua equipe. Uma página. Liste as tarefas onde a IA é a ferramenta padrão. Liste as tarefas onde a IA é proibida. Liste as tarefas onde a IA é permitida, mas todo output passa por revisão humana antes de ser integrado. Obtenha aprovação do seu gestor. O ponto de escrever isso é que força a conversa, que traz à tona discordâncias que você não sabia que existiam.

Erros comuns

Uma lista curta, ordenada pela frequência com que os vi explodir em produção:

Confiar em nomes de colunas alucinados. Sempre verifique se as colunas referenciadas no código gerado por IA existem no dataframe. df.columns.tolist() é seu amigo.
Aceitar uma recomendação de modelo sem uma segunda opinião. Se o Copilot diz "use um random forest aqui", pergunte-se por quê, e pergunte ao Claude separadamente para criticar essa escolha. Discordância é informação.
Deixar a IA escrever o resumo executivo. Já foi abordado. Não faça isso.
Usar LLMs para afirmações causais. Eles vão te dar uma resposta confiante. A resposta não tem correlação com a verdade.
Esquecer que as janelas de contexto dos prompts truncam o seu dataframe. Se você colar uma amostra de 50 linhas e perguntar "há um padrão de outlier", o LLM só vê 50 linhas. Não vai saber sobre a cauda longa. O conselho que ele der estará errado para os dados completos.
Usar o mesmo prompt em projetos sem reajustá-lo. O seu codebase tem convenções. Prompts genéricos de revisão de código não detectam os padrões específicos da sua equipe.

Templates e ferramentas

Um kit inicial funcional:

Arquivo de regras do Cursor para trabalho em DS. Informa ao Cursor sobre as convenções da sua equipe: qual versão do sklearn você usa, que você usa Polars em vez de Pandas (ou vice-versa), que todos os atributos precisam de um comentário sobre vazamento de dados.
Template de prompt de revisão de código para Claude. "Revise este diff para: correção de referências a colunas, vazamento de dados, APIs obsoletas, casos extremos em nulos, e consistência com o restante do codebase. Não comente sobre estilo."
Documento de política de uso de IA de uma página. Um documento Google de uma página que sua equipe assina. Três colunas: tarefa, IA permitida?, revisão obrigatória? Poste no canal da sua equipe.
Checklist de verificação de EDA. Quando a IA gera uma EDA, passe por: ela contou nulos corretamente? Detectou a coluna categórica com 10.000 valores únicos? Notou a coluna de data com problemas de fuso horário? Se ela perdeu algum desses, o restante do output é suspeito.

Medindo se isso está funcionando

Três sinais, em ordem de importância:

O tempo para o primeiro modelo em um novo dataset cai de forma mensurável. Se um DS júnior costumava levar três dias para chegar a um modelo de referência e agora leva um, esse é o ganho que você está buscando. Se o tempo não caiu, você não está usando IA nas partes onde ela ajuda.
Comentários de revisão de PR sobre "coluna errada" ou "API obsoleta" chegam a zero. Esses são os bugs fáceis. Se ainda estão aparecendo, o loop de revisão de código da Semana 3 não está detectando-os.
A equipe tem uma política escrita e a referencia. Não apenas um documento que existe, mas um documento que é citado em PRs e revisões de design. "Não usamos IA para isso por causa da seção 3 da política" é o indicador de que o limite é real.

O sinal negativo que importa mais do que todos esses: ninguém na equipe publicou uma análise escrita por LLM como trabalho próprio. Se isso acontecer, e vai acontecer em algum momento, você não tem um problema de política de IA, você tem um problema de credibilidade, e a solução é uma conversa, não uma mudança de ferramenta.

A linha entre "a IA me ajuda a entregar mais rápido" e "a IA publicou uma análise errada com meu nome" é mais tênue do que o marketing sugere. Trace-a explicitamente, escreva-a, e revisite-a a cada trimestre conforme as ferramentas mudam.

Playbooks para Data Scientists