A reunião começou com a pergunta errada.
“Onde podemos usar IA?” — perguntou o diretor, e a sala passou a hora seguinte gerando respostas. Chatbot no atendimento. Assistente para o jurídico. Resumo automático de reuniões. Um piloto aqui, outro ali. Ao final, seis iniciativas aprovadas, nenhuma delas amarrada a um problema que alguém tivesse, de fato, tentado resolver antes e falhado.
Um ano depois, três dos seis pilotos tinham morrido silenciosamente. Os outros três produziam demonstrações impressionantes em reuniões de comitê e nenhum resultado que aparecesse no resultado operacional. A empresa tinha “adotado IA”. Não tinha resolvido nada que não conseguisse resolver antes.
O erro não estava na tecnologia escolhida. Estava na pergunta.
O que vou apresentar neste artigo
A pergunta “onde podemos usar IA?” é estruturalmente a pergunta errada — ela parte da ferramenta, não do problema, e produz pilotos sem dono e sem critério de sucesso.
Christensen (Jobs to Be Done): ninguém compra uma ferramenta. Contrata algo para fazer progresso numa situação específica. IA só importa quando acelera esse progresso de forma confiável.
Quatro sistemas que foram construídos internamente na Qeevo — não estudos de caso de terceiros — mostram o padrão invertido: problema primeiro, IA como resposta, não como ponto de partida.
Um princípio opera nos quatro: não automatize desperdício. Se o processo é ruim, IA acelera o problema, não o resolve.
Um segundo princípio, que abre o próximo artigo desta série: nem tudo que pode ser automatizado deve ser automatizado — a fronteira certa não é departamento, é reversibilidade da decisão.
“Demo bonita” e “MVP confiável” são coisas diferentes. A pergunta que separa os dois não é “pode funcionar?” — é “quando falha?”
A pergunta que a maioria das organizações está fazendo — e por que ela garante desperdício
Praticamente toda iniciativa de IA malsucedida que diagnostiquei nos últimos dois anos começou com a mesma pergunta: onde podemos usar IA? A pergunta parece neutra. Não é. Ela parte da ferramenta e procura um lugar para encaixá-la — o que inverte a ordem que qualquer transformação organizacional bem-sucedida sempre seguiu.
Peter Drucker definiu eficácia como fazer a coisa certa — não apenas fazer a mesma coisa mais rápido. A pergunta “onde usar IA” otimiza para a segunda definição e ignora a primeira. Ela pressupõe que os processos atuais são os processos certos e que só faltava velocidade. Na maioria das organizações que diagnostico, essa suposição está errada: o processo já era ineficiente antes de qualquer modelo de linguagem existir, e a pergunta certa nunca foi feita.
A pergunta certa não é técnica — é estratégica
Pergunta errada: “Onde podemos usar IA?”
Pergunta correta: “Que problema crítico ainda não conseguimos resolver bem — e o que mudou que torna isso possível agora?”
A diferença não é sutil. A primeira pergunta gera uma lista de ferramentas candidatas. A segunda exige um diagnóstico honesto do que está quebrado antes de cogitar qualquer tecnologia — e, com frequência, revela que o problema real nunca foi falta de IA.
Jobs to Be Done: ninguém compra ferramenta de IA; compramos soluções para problemas
Clayton Christensen argumentou que o cliente não contrata um produto — contrata algo para fazer progresso numa situação específica. Aprovar uma compra. Publicar uma matéria. Fechar o financeiro do mês. Cumprir um prazo processual sem perder o processo. A IA só tem valor quando acelera esse progresso de forma confiável; caso contrário é apenas mais uma ferramenta competindo por atenção num ambiente já saturado de ferramentas.
Essa distinção parece óbvia quando enunciada — e é sistematicamente ignorada na prática. A prova mais clara não vem de um estudo de terceiros. Vem de quatro sistemas que construí e opero, todos nascidos da mesma disciplina: identificar o trabalho que precisava ser feito antes de perguntar qual tecnologia fazia isso.
Agora vejamos como isso funciona na prática com os casos reais que desenvolvemos na Qeevo Holding (Quero Educação, Melhor Escola, Allevo, e mais).
Caso Real - Qeevo OS
Qeevo OS não nasceu para ser uma simples ferramenta de compras. Nasceu porque o processo estava fragmentado — existia um monte de exceção. Solicitação, nota fiscal e classificação nasciam espalhadas entre Slack, e-mail, WhatsApp e o ERP. Três pessoas seguravam isso na mão.
O fechamento contábil só saía no dia 20 do mês seguinte — porque virava garimpo, reconstruir informação que deveria ter nascido estruturada.
Hoje: dia 5, com 1 pessoa em vez de 3. E uma pergunta que antes levava mais de um dia pra responder — “quanto já está comprometido?” — agora leva minutos.
A parte que mais gosto de contar não é o resultado, é onde a IA entrou — em duas frentes diferentes. Construímos o sistema inteiro com duas pessoas (um PM e um dev), porque o Claude Code viabilizou isso no prazo que tínhamos. E, dentro do processo, a IA lê e confere nota fiscal contra o pedido. Não aprova, não classifica — isso continua sendo decisão humana.
O aprendizado: quando a IA acelera tanto a construção, o gargalo vira outra coisa — fechar a regra de negócio antes de sair codando. Tempo de PM valeu mais que tempo de dev, neste projeto.
Próximo passo: sair de vez do ERP legado. Projeção de mais de 80% de redução de custo, porque o que sobra é só o núcleo contábil.
Figura 1 · Qeevo OS — o “sistema operacional” da nossa empresa
Caso Real - Jur OS
JUR.OS não é chatbot fazendo petição. Conecta com a API do Procon, analisa processo, propõe prazo e parecer com contexto. Cuida também da parte societária inteira do grupo — holding, empresas, rodas de investimento, sócios — mais contratos e trabalhista.
O gargalo nunca foi “inteligência jurídica”. Foi volume: informação não estruturada chegando todo dia, em formato diferente, numa escala que planilha não acompanha.
Em algum momento testamos deixar o sistema confirmar prazo sozinho, sem passar por revisão humana. Funcionou tecnicamente — zero erro nas duas semanas de teste.
Desligamos assim mesmo.
Não porque errasse. Porque prazo perdido não tem volta, e a pergunta certa nunca foi “funciona?” — é “quando errar, dá pra reverter?”. Hoje: 893 prazos monitorados, zero vencido. A IA lê e propõe; quem confirma, assume a responsabilidade e decide a estratégia continua sendo humano.
Essa disciplina, sem atalho, é o que sustenta os números mostrados na Figura 2: exposição de risco caindo 88,7%.
Figura 2 · JUR.OS — IA propõe, humano decide
Caso Real - Foqa News
FOQA News não é “site de notícia gerado por IA”. Isso já existe aos montes por aí. O que nós criamos foi uma verdadeira curadoria com um agente por trás — a Feme — que lê, cruza fonte, escreve e organiza a matéria. E outro agente — o Ale — que conversa com quem está lendo, dentro da própria notícia, tirando dúvida e dando contexto.
A régua que usamos pra decidir onde a IA entra: ela fica onde há ambiguidade — gerar, resumir, interpretar contexto. Código fica onde há certeza — categorizar, publicar, indexar. Humano fica onde há responsabilidade — aprovar, editar, decidir linha editorial.
Nos primeiros 15 dias do MVP: 2.357 matérias publicadas. Hoje, em regime: cerca de 1.200 artigos novos por mês, otimizados pra buscador e pra IA que os lê depois — com 1 desenvolvedor, tendo IA como parceiro de arquitetura.
O que sustenta o volume não é velocidade. É a régua acima, aplicada com disciplina — notícia errada publicada rápido é o tipo de erro mais caro de reverter.
Figura 3 · Foqa News — IA no produto, não só no processo interno
Caso Real - Content OS
Mais um exemplo é o Content.OS. Começou pequeno: gerar carrossel pra rede social, porque a produção manual — briefing solto em documento avulso, arte no Canva, sem padrão de marca — tomava tempo demais.
Hoje ele estrutura o briefing, gera o roteiro com as diretrizes de marca, aplica os templates e publica no calendário. E está deixando de ser ferramenta interna pra virar produto vendido pra fora.
Diferença importante em relação aos outros três casos que venho postando: os números abaixo são projeção de MVP, não resultado de produção madura. Trato como hipótese em teste, não fato consolidado — é exatamente esse tipo de otimismo prematuro que o resto desta série vem criticando.
Hoje, temos as seguintes métricas, por carrossel: de 1-3 horas pra 5-15 minutos, em 4 etapas com IA integrada — nenhuma sem revisão humana.
Se em alguns meses esse número não se confirmar em produção real, volto aqui e conto isso também. Tratam-se de experimentos. E, por falar em experimentos, esse será o tema do meu próximo artigo na semana que vem, explicando como identificar e selecionar experimentos, como e quando transformar em projetos, bem como um novo framework mais flexível para gerenciar projetos de IA nas empresas.
Figura 4 · Content.OS — de ferramenta interna a produto (resultados projetados)
Nenhum desses quatro sistemas acima começou com a pergunta “onde posso usar IA”. Todos começaram com um processo que eu já conhecia por dentro, que já sabia que estava quebrado, e que eu já tentava resolver antes de qualquer modelo de linguagem estar disponível para resolver do jeito que resolve hoje. A IA foi a resposta que ficou disponível depois. Não foi o ponto de partida.
Agora vamos analisar um caso mundial, para contraste — Klarna
Em fevereiro de 2024, o assistente de IA da Klarna processou 2,3 milhões de conversas em 30 dias — equivalente ao trabalho de 700 atendentes — automatizando 67% do atendimento, com projeção de US$40 milhões em ganho. Um ano depois, a empresa recontratou humanos e reduziu a automação: o próprio CEO reconheceu publicamente que “custo foi fator predominante” na decisão original, e isso gerou “menor qualidade”.
Klarna não errou a tecnologia. Errou a pergunta — otimizou para custo, não para o job to be done do cliente. O mesmo erro estrutural deste artigo, só que em escala de bilhões e com imprensa mundial assistindo.
Princípio 1 — não automatize desperdício
IA pode tornar processos ruins mais rápidos. Isso não é transformação — é desperdício acelerado. A sequência importa, e ela não começa com automação.
Figura 5 - A ordem correta para transformar processos com IA.
Sequência correta antes de automatizar qualquer processo:
Eliminar → Simplificar → Padronizar → Automatizar → Aumentar
Eliminar o desnecessário. Simplificar o que sobra, reduzindo etapas e complexidade. Padronizar num processo único. Só então automatizar, com tecnologia usada com critério. Aumentar — IA como copiloto — vem por último, não primeiro.
Na prática, isso significa que a pergunta “que processo automatizamos primeiro” está, na maioria das organizações, mal-colocada. A pergunta anterior — “esse processo já está limpo o suficiente para merecer velocidade?” — raramente é feita, e é exatamente a que separa transformação real de desperdício acelerado.
Princípio 2 — nem tudo que pode ser automatizado deve ser
Daniel Kahneman documentou que vieses cognitivos humanos são reais — mas confiança excessiva em sistemas automatizados cria riscos sistêmicos de outra natureza. O design correto não escolhe entre humano e máquina. Calibra autonomia pelo risco e pela reversibilidade da decisão em jogo.
Figura 6 - Orientações para seleção e priorização das iniciativas de IA relacionadas a processos internos.
Este é o princípio que o próximo artigo desta série desenvolve por completo: a fronteira certa entre o que a IA decide e o que ela apenas propõe não é definida por departamento, nem por tipo de tarefa. É definida por uma única pergunta — essa decisão, se errada, é fácil de reverter?
Procure verbos, não ferramentas
Se a pergunta “onde usar IA” não funciona, qual pergunta funciona? Uma alternativa prática: mapear os verbos do processo, não as ferramentas do mercado.
Figura 7 - Procure pelos verbos onde IA pode gerar oportunidades
Oportunidades aparecem onde informação vira julgamento, julgamento vira decisão, e decisão vira ação. Mapeie os verbos do seu processo — o gargalo aparece sozinho, sem precisar de consultoria para achá-lo.
Demo bonita não é MVP confiável
Uma demonstração convincente responde a uma pergunta fácil: pode funcionar? Um MVP sério de IA precisa responder a uma pergunta mais dura: quando falha? Sem baseline de desempenho, casos difíceis, limite aceitável de erro, custo operacional real e mecanismo de supervisão humana, o que existe é experimento — não produto.
Conexão · Hélice da Execução · Trentim (2026)
Um MVP de IA que só responde “pode funcionar?” está testando Capacidade de Entrega — a pá que mede se a organização consegue entregar o que promete. Mas sem responder “quando falha?”, a organização não sabe se está entregando algo que sustenta Governança Enxuta — a quantidade certa de controle no nível certo. As duas pás precisam ser avaliadas juntas antes de qualquer piloto de IA sair da fase de demonstração.
As três perguntas que separam demo de produto: Valor — o que muda, de fato, para quem usa? Verdade — onde exatamente o sistema erra, e com que frequência? Controle — quem monitora e quem decide quando o erro aparece?
Governança não é burocracia — é design de confiança
Frameworks como o NIST AI Risk Management Framework e a norma ISO 42001 convergem num ponto: risco deve ser mapeado antes da implantação, responsabilidade deve ser explícita e rastreável, supervisão humana deve ser proporcional ao impacto. O Double Diamond de design aplica-se diretamente aqui — descobrir e definir o risco antes de desenvolver e implantar qualquer sistema de IA com impacto organizacional significativo.
Isso não é obstáculo à velocidade. É a condição que permite velocidade sustentável. Organizações que investem em tecnologia sem investir na mesma medida em processo, segurança e governança constroem soluções frágeis — mesmo quando os resultados de curto prazo parecem bons.
O que sobe de valor quando inteligência fica abundante
A abundância de IA não desvaloriza as pessoas. Desvaloriza a execução mecânica. O que sobe de valor é contexto, responsabilidade, ética, critério estratégico e a capacidade de fazer a pergunta certa antes de qualquer ferramenta entrar na sala. Quanto mais inteligência artificial disponível, mais valioso se torna o julgamento humano sobre onde aplicá-la — e sobre onde não aplicar.
A pergunta para levar à próxima reunião sobre IA
Que problema se tornou resolvível agora que inteligência ficou abundante?
Não volte para sua empresa procurando ferramenta. Abra um processo que todo mundo odeia. Ali começa a transformação real — o maior erro sobre IA ainda é começar pela IA.
→ Próximo artigo desta série (semana que vem): “A IA não decide. Ela propõe.” — o princípio 2 deste artigo, desenvolvido por completo: por que a fronteira certa da automação não é departamento, é reversibilidade — e o que isso muda na forma como PMOs, comitês e lideranças decidem o que delegar a um agente.
Mario H. Trentim é conselheiro de administração, doutorando em Engenharia no ITA (2024–2029), e autor de 13 livros em gestão estratégica e execução. Construiu e opera os quatro sistemas de IA descritos neste artigo. Escreve semanalmente sobre estratégia, execução e governança em organizações complexas.
Esta newsletter não tem patrocinadores nem anúncios. Se o conteúdo tem valor, a melhor forma de amplificá-lo é encaminhar para quem está prestes a aprovar o próximo piloto de IA sem ter feito a pergunta certa antes.
📩 Estratégia em Ação · Newsletter semanal sobre execução, governança e organizações que aprendem mais rápido do que o mercado muda · substack.com/@mariotrentim
Referências e fontes
Christensen, C.M., Hall, T., Dillon, K. & Duncan, D.S. (2016). Know your customers’ “jobs to be done”. Harvard Business Review, September 2016.
Drucker, P.F. (1967). The Effective Executive. Harper & Row. [eficácia vs. eficiência]
Kahneman, D. (2011). Thinking, Fast and Slow. Farrar, Straus and Giroux. [viés cognitivo vs. confiança automatizada]
DeepMind / Google (2016-2018). Machine learning application for data center cooling — redução documentada de ~40% no consumo de energia de refrigeração.
National Institute of Standards and Technology (NIST). AI Risk Management Framework (AI RMF 1.0, 2023) e adendo para IA generativa.
International Organization for Standardization. ISO/IEC 42001:2023 — Sistema de gestão de IA.
Trentim, M.H. (2026). Hélice da Execução: Framework diagnóstico de capacidade organizacional. [W25, W38-W40 desta newsletter]
Trentim, M.H. (2026). Qeevo OS, JUR.OS, FOQA News — sistemas proprietários em operação, dados internos verificados. Content.OS — sistema em transição de ferramenta interna para produto, dados de MVP projetados.
Klarna AB (2024-2025). Assistente de IA de atendimento — lançamento, resultados iniciais e recuo parcial amplamente noticiados na imprensa de tecnologia e negócios.