Quais são os casos de uso de IA generativa que funcionam?

Os casos de uso de IA generativa que funcionam têm três coisas em comum: errar custa pouco, conferir é rápido e o volume é alto. Rascunho de texto, rascunho de código, resumo, extração de campo, classificação e triagem cumprem as três. Onde falta uma delas, o piloto costuma parar no piloto, por mais convincente que tenha sido a demonstração.

Isso é uma afirmação sobre a forma da tarefa, não sobre o setor. A mesma empresa tem casos que fecham a conta e casos que não fecham, e a diferença raramente é o modelo escolhido. Vale ler junto a lista de onde LLM não deve ser usado, que é mais curta e mais útil do que parece.

Os dois pontos de partida mais comuns também são os mais bem documentados: atendimento, onde já existe fila e já existe revisão, e conteúdo em escala, onde o ganho é imediato e a armadilha é publicar sem etapa de conferência.

A matriz que decide

Dois eixos explicam a maior parte dos acertos e dos fracassos.

O eixo vertical é o custo de errar. Uma sugestão de título ruim custa uma rolagem. Um parecer jurídico errado custa um processo. Entre os dois extremos há uma faixa larga onde o erro custa alguns minutos de revisão, e é nela que quase tudo que funciona está.

O eixo horizontal é o valor de acertar. Não é o mesmo que volume: um resumo de reunião vale pouco por unidade e muito no agregado, enquanto um parecer vale muito por unidade e sai poucas vezes por mês.

O quadrante superior direito é onde a IA generativa compensa hoje sem discussão: erro barato, valor alto. Rascunho de código, resumo de reunião, triagem de chamado. O quadrante inferior direito é o que gera as manchetes ruins: valor alto e erro caro. Ele não é proibido, mas exige que alguém confira antes de a saída valer, e esse alguém precisa ter tempo alocado, não boa vontade.

Uma armadilha aparece no quadrante inferior esquerdo, que parece inofensivo. Correção de cadastro e classificação fiscal têm erro caro e valor baixo por unidade. É o pior lugar para começar: o esforço de montar e manter não é recuperado e o primeiro erro consome a credibilidade do projeto inteiro.

O que a evidência mostra

Vale separar o que foi medido em experimento do que se repete em apresentação.

Um experimento pré-registrado de 2023 deu tarefas de escrita profissional de nível médio, específicas por ocupação e com incentivo, a 453 profissionais com curso superior, expondo metade deles a um assistente. O tempo médio caiu 40% e a qualidade avaliada subiu 18%. A desigualdade entre trabalhadores diminuiu: quem tinha desempenho mais baixo ganhou mais¹.

Um estudo de campo com 5.172 atendentes de suporte, publicado em 2025, mediu aumento de 15% em chamados resolvidos por hora, com heterogeneidade grande. Quem tinha menos experiência melhorou velocidade e qualidade; quem tinha mais experiência teve ganho pequeno de velocidade e pequena queda de qualidade. O ganho foi maior em problemas moderadamente raros, onde o atendente humano tem menos prática e o sistema ainda tem dados suficientes².

Um experimento controlado com desenvolvedores, também de 2023, pediu a implementação de um servidor HTTP em JavaScript o mais rápido possível. O grupo com assistente terminou 55,8% mais rápido³. É uma tarefa curta e bem definida, e o número não se estende a manutenção de sistema grande.

O trabalho que dimensionou a coisa toda, de 2023, avaliou ocupações americanas por alinhamento com capacidades de LLM. Cerca de 80% da força de trabalho teria ao menos 10% das tarefas afetadas, e cerca de 19% teria ao menos metade. Com acesso apenas ao modelo, cerca de 15% das tarefas poderiam ser feitas significativamente mais rápido com a mesma qualidade; com software construído em cima do modelo, o número sobe para entre 47% e 56%⁴.

Esse último contraste é o achado mais útil aqui. A diferença entre 15% e 50% não está no modelo, está no que foi construído em volta dele.

Duas ressalvas honestas sobre esses números. Todos vêm de tarefas relativamente curtas e bem delimitadas, com resultado avaliável no fim; nenhum mede um projeto de seis meses. E os modelos usados são de 2023, ou seja, muito mais fracos que os de 2026, o que empurra os ganhos para cima em qualquer replicação. O que envelhece bem nesses trabalhos não é a magnitude, é a forma: ganho maior para quem tinha menos prática, ganho menor ou negativo para quem já era muito bom na tarefa, e diferença enorme entre o modelo sozinho e o modelo dentro de um sistema.

As cinco famílias

Atendimento é o ponto de partida mais comum porque a fila já existe e alguém já revisa. Chatbot, triagem de chamado e suporte técnico apoiado em recuperação são variações da mesma estrutura: entender o pedido, buscar o que responde, redigir.

Conteúdo é onde o ganho aparece mais rápido e onde a queda de qualidade demora mais a ser notada. Geração em escala, tradução e resumo funcionam bem por item e degradam no agregado quando ninguém lê a saída.

Dados é a família mais subestimada. Extração de campo de documento, classificação e limpeza de base são tarefas com resposta verificável, volume alto e custo de erro contido, o que é exatamente o perfil que fecha a conta. Não rende demonstração bonita e rende resultado.

Um exemplo do formato: extrair emissor, valor, vencimento e centro de custo de notas que chegam em quarenta layouts diferentes. A conferência é estruturada, o valor extraído pode ser somado e comparado com o total do documento, e um campo recusado volta para uma fila humana em vez de virar lançamento. É a tarefa em que a IA generativa resolve o que quinze anos de regras por template não resolveram, e quase ninguém fala dela.

Código tem a evidência experimental mais forte para tarefas curtas e a mais fraca para manutenção. Rascunho, revisão e migração se comportam de formas diferentes, e migração é a que mais depende de teste automatizado existindo antes.

Decisão é a família que exige mais cuidado. Recomendação personalizada e priorização de fila colocam a saída do modelo diretamente na frente do usuário, sem etapa humana. É onde a matriz da figura 1 precisa ser consultada antes de qualquer linha de código.

O padrão dos casos que funcionam

Errar custa pouco. A saída errada é descartada, corrigida ou ignorada sem consequência fora do processo. Um rascunho ruim vira um rascunho reescrito.

Conferir é rápido. Essa é a condição que mais separa piloto de produção, e a mais esquecida. Verificar precisa ser mais barato que produzir do zero, e nem sempre é. Conferir se um resumo de reunião está correto exige ler a ata inteira, o que às vezes custa mais que escrever o resumo. Casos com verificação estruturada, como extração de campo com validação de formato e conferência contra o documento, são muito mais fáceis de operar do que casos de texto livre.

O volume é alto. Se a tarefa acontece dez vezes por mês, o esforço de montar, avaliar e manter não é recuperado. Sistema em produção tem custo contínuo de manutenção, e volume é o que paga esse custo.

As três valem juntas. Volume alto sem verificação rápida produz erro em escala, que é a pior combinação possível. Erro barato e verificação rápida sem volume é um bom experimento e um mau projeto.

Onde não funciona

Resposta única com consequência. Um estudo de 2024 mediu alucinação jurídica fazendo perguntas específicas e verificáveis sobre processos federais americanos sorteados. A taxa de alucinação ficou entre 58% para o modelo mais forte testado e 88% para o mais fraco. Os modelos também falharam com frequência em corrigir uma premissa jurídica errada embutida na pergunta, e nem sempre conseguiam prever quando estavam alucinando⁵. Os números são de 2024 e melhoraram desde então; o formato do risco não mudou.

Regra de domínio que precisa valer sempre. Um benchmark de 2024 colocou agentes com ferramentas e um documento de política conversando com usuários simulados. Os melhores da época resolveram menos de 50% das tarefas, e a taxa de acerto em todas as oito tentativas da mesma tarefa ficou abaixo de 25% no domínio de varejo⁶. Se a sua regra não pode falhar uma vez em oito, ela não pode depender só de leitura.

Volume baixo com montagem cara. O caso em que a demonstração encanta e a conta não fecha. Quinze ocorrências por mês não sustentam um sistema com avaliação, monitoramento e alguém de plantão.

Tarefas onde a linha de base humana já é quase perfeita. Se a operação atual erra 0,5%, um sistema que erra 4% é uma piora, ainda que 96% pareça um bom número isolado.

Casos em que ninguém definiu o que é uma saída boa. É a falha mais comum e a menos técnica. Sem um critério escrito antes, a avaliação vira discussão de gosto e o projeto não termina.

Quando a conta fecha

Ordem de grandeza, com as premissas à vista. Uma tarefa de extração sobre um documento de 4 páginas custa perto de 6 mil tokens de entrada e 500 de saída. Em mil documentos por mês, isso é um custo de infraestrutura pequeno perto do salário de uma pessoa fazendo o mesmo trabalho, e a conta parece fechada.

O que costuma não estar na conta é o resto. A construção leva de duas a oito semanas de alguém. O conjunto de avaliação precisa existir e ser mantido. A revisão humana continua consumindo tempo, menor mas não zero. E cada mudança de modelo ou de formato de documento exige rodar a avaliação de novo.

A regra prática que sobrevive: some o custo de inferência, o custo de revisão que permanece e um sexto de uma pessoa por mês de manutenção. Se ainda assim o número for confortavelmente menor que a linha de base, o caso fecha. Se ficar perto, ele não fecha, porque a estimativa vai errar para cima.

Como escolher o primeiro caso

1. Procure uma fila que já existe. Onde há fila há volume, há linha de base medida e há alguém que já revisa. As três condições ficam mais fáceis de satisfazer de uma vez.
2. Escreva o critério de saída boa antes de escrever o prompt. Em uma página, com exemplos de saída aceita e de saída recusada.
3. Meça a linha de base humana primeiro. Tempo por item, taxa de retrabalho, taxa de erro. Sem esses três números, não existe comparação depois.
4. Comece pelo caminho mais simples. Um prompt bem escrito resolve mais casos do que parece, e engenharia de prompts é a etapa que mais rende antes de qualquer arquitetura.
5. Coloque a verificação no desenho, não no discurso. Quem confere, quanto tempo tem, o que faz quando recusa.
6. Rode em paralelo com o processo atual por algumas semanas. Sem substituir nada, comparando saída com saída. É a única forma barata de descobrir o que a demonstração escondeu.

O passo 3 é o que quase ninguém faz e é o que determina se você vai conseguir defender o resultado seis meses depois.

Footnotes

1. Noy e Zhang (2023) mediram, em experimento pré-registrado com 453 profissionais, queda de 40% no tempo médio e alta de 18% na qualidade avaliada em tarefas de escrita profissional, com redução da desigualdade entre participantes. ↩

2. Brynjolfsson, Li e Raymond (2025) acompanharam 5.172 atendentes e mediram 15% a mais de chamados resolvidos por hora, com ganho concentrado nos menos experientes e pequena queda de qualidade entre os mais experientes. ↩

3. Peng et al. (2023) conduziram um experimento controlado em que o grupo com assistente completou a implementação de um servidor HTTP 55,8% mais rápido que o grupo de controle. ↩

4. Eloundou et al. (2023) estimaram que cerca de 80% da força de trabalho americana teria ao menos 10% das tarefas afetadas por LLMs e cerca de 19% ao menos metade, com o salto de 15% para 47–56% de tarefas aceleradas quando se considera software construído sobre o modelo. ↩

5. Dahl et al. (2024) mediram taxas de alucinação jurídica entre 58% e 88% em perguntas verificáveis sobre processos federais sorteados, e encontraram que os modelos frequentemente não corrigem premissas erradas do usuário. ↩

6. Yao et al. (2024) mediram menos de 50% de sucesso e menos de 25% de acerto em todas as oito tentativas da mesma tarefa no domínio de varejo, com agentes seguindo políticas de domínio escritas. ↩