Como uso IA no trabalho de verdade — meu modelo pessoal
TL;DR
Uso IA no trabalho de verdade há mais de um ano. O que funciona para mim não é "vibe coding" nem delegação de raciocínio — é usar IA como par de pensamento para tarefas específicas, mantendo a propriedade intelectual sobre o que entrego. Os dois erros mais comuns que vejo: ou as pessoas não usam IA onde ela seria útil (por ceticismo) ou delegam exatamente o que não deveria ser delegado (o contexto de negócio e a conclusão). Este post descreve o meu modelo pessoal — com o que funcionou e o que não funcionou junto.
O paradoxo de produtividade da IA
Existe um estudo publicado em 2026 pela Fortune que documenta o que ficou conhecido como o "paradoxo de produtividade da IA": CEOs relatam que adotaram ferramentas de IA em escala, mas os ganhos de produtividade mensuráveis estão muito abaixo do esperado.
Robert Solow ficou famoso nos anos 80 por uma frase sobre computadores: "você pode ver a era dos computadores em todo lugar, exceto nas estatísticas de produtividade." O mesmo padrão parece se repetir com IA generativa.
Por que isso acontece?
Uma das hipóteses mais plausíveis é que a maioria das pessoas usa IA para as tarefas erradas — ou da forma errada. Automatiza o que era rápido, e deixa intocado o que era lento. Ou delega o que exige julgamento, e mantém manual o que é puro trabalho de volume.
Comecei a pensar sobre o meu próprio uso a partir dessa lente: onde eu estou usando IA, e onde eu deveria estar usando mais?
O que não é verdade no meu uso
Antes de descrever o que funciona, vale nomear o que eu não faço.
Não "vibe coders". Não escrevo um prompt descrevendo o que quero, aceito o output, e entrego. Isso funciona para prototipagem rápida — e para trabalho onde o julgamento sobre o output não importa. No trabalho de BA, o julgamento sobre o output é basicamente tudo.
Não delego o contexto de negócio. IA não sabe que aquele dado de receita está duplicado porque o time de engenharia corrigiu um bug em fevereiro. Não sabe que o stakeholder daquela análise vai apresentar para o board na quinta. Não sabe que a hipótese mais simples foi testada e descartada três meses atrás. Esse contexto é o que torna uma análise útil — e não está disponível para o modelo.
Não trato o output como verdade. Verifico SQL gerado. Corrijo argumentos que soam convincentes mas têm premissas erradas. Leio o que foi escrito como se tivesse escrito eu mesmo — porque vou assinar embaixo.
Onde uso de verdade
1. SQL: debug e revisão
Escrevo a query, IA revisa. Ou escrevo a estrutura, IA preenche as partes repetitivas. O que funciona: pedir para o modelo explicar o que a query faz antes de rodar — isso revela premissas que eu tinha implícitas e que estavam erradas.
O que não funciona: pedir a query completa sem entender o que ela deveria fazer. O output às vezes está correto sintaticamente e errado semanticamente — e sem entender a lógica, você não detecta.
2. Estrutura de argumentos
Quando tenho que montar uma análise para uma audiência nova, peço para o modelo tentar contra-argumentar a conclusão que pretendo apresentar. Isso antecipa as perguntas que vão aparecer na reunião.
Não é delegação de raciocínio — é forçar que o meu raciocínio seja exposto a objeções antes de chegar ao stakeholder.
3. Primeiros rascunhos de comunicação
E-mails de alinhamento, resumos de análise, documentação de decisão: uso IA para o draft inicial, depois reescrevo com o tom correto para aquela audiência específica.
O draft gerado raramente está certo de primeira — mas elimina a inércia de começar do zero. O trabalho de reescrita é mais rápido do que o trabalho de criação.
4. Aprender algo novo rapidamente
"Me explica esse conceito de três formas diferentes — uma técnica, uma com analogia, uma como se eu soubesse a metade do contexto necessário." Esse formato funciona bem para absorver tópicos que estou vendo pela primeira vez. Não substitui ler o material original, mas acelera o entendimento inicial.
5. Identificar o que estou assumindo sem saber
Antes de finalizar uma análise, peço: "quais são as premissas implícitas desta conclusão?" A lista que o modelo gera costuma ter pelo menos uma coisa que eu não tinha pensado — e que vale checar antes da reunião.
Onde me decepcionei
Análise exploratória sem briefing claro. Quando a pergunta está mal definida, o output de IA amplifica a ambiguidade. O modelo gera algo plausível, você se apega ao que foi gerado, e acaba respondendo a pergunta errada com muita qualidade.
Raciocínio causal. IA é boa em correlações, ruim em causalidade. Quando peço para o modelo sugerir explicações para um movimento de métrica, as hipóteses geradas costumam ser as mais prováveis estatisticamente, não as mais relevantes para o contexto do negócio. Isso é exatamente o tipo de erro que parece razoável mas está errado por dentro.
Qualquer coisa que precise de contexto organizacional. "Como devo apresentar isso para o meu VP?" — o modelo não conhece o VP, não sabe o histórico, não sabe o que foi prometido anteriormente. O output é genérico. Genérico não funciona para comunicação de alto risco.
O modelo mental que uso
Existe uma distinção que mudou como eu penso sobre IA no trabalho: IA como par vs IA como oracle.
Oracle: você delega a pergunta e aceita a resposta. A IA sabe, você implementa. O output define o que você entrega.
Par: você traz a pergunta e o contexto, o modelo contribui com estrutura, verificação, alternativas. Você ainda decide o que fazer. O output informa — não define.
Na maioria dos casos de uso que funcionam para mim, estou usando IA como par. Nas situações que decepcionaram, estava usando como oracle — esperando que o modelo tivesse o contexto que só eu tenho.
A diferença prática: quando uso como oracle, aceito o output com pouca fricção. Quando uso como par, estou ativamente discordando, verificando, reescrevendo. O trabalho não diminui — muda de natureza.
O que mudou de verdade
Ser honesto sobre isso importa porque o hype infla as expectativas.
O que mudou: algumas tarefas que tomavam 2 horas tomam 40 minutos. Drafts de comunicação ficaram melhores mais rápido. Tenho menos bloqueio para começar quando a tarefa é pesada ou ambígua.
O que não mudou: o trabalho de entender o problema, de identificar a pergunta operacional, de construir confiança com stakeholders. Isso continua sendo trabalho humano — e provavelmente vai continuar sendo por um tempo.
O paradoxo que o estudo da Fortune documenta faz sentido para mim: IA aumenta produtividade onde o trabalho era processo, não onde era julgamento. E nas funções de análise, o trabalho de valor é quase todo julgamento.
Sobre o curso
O tipo de raciocínio que descrevi aqui — saber o que delegar, quando verificar, como estruturar análises que servem decisões — é o que o curso que estou lançando vai cobrir.
Não é um curso sobre como usar ferramentas de IA. É sobre como pensar análises que geram impacto — com ou sem IA.
Lista de espera aberta. Link na bio.
Referências
→ Fortune / AI Productivity Paradox (2026): fortune.com/2026/02/17/ai-productivity-paradox-ceo-study-robert-solow-information-technology-age/
→ Solow, R. (1987). We'd better watch out. New York Times Book Review, p. 36.
