A Klarna substituiu 700 pessoas por IA. Depois recontratou todas. Eis o que toda empresa deveria aprender.

Eu estava em uma ligação com um cliente bancário em potencial quando a notícia da Klarna estourou. Meados de 2025. Meu celular vibrou — um colega havia encaminhado o artigo com uma única linha: "É literalmente o que você vem dizendo."

O cliente estava no meio de uma frase, explicando como a equipe dele havia construído um chatbot de atendimento ao cliente em cima do GPT-4, e como ele estava "funcionando muito bem". Perguntei a ele como estavam as notas de CSAT. Longa pausa. "Ainda não acompanhamos isso."

Essa pausa me disse tudo. Porque a Klarna havia acompanhado. E o que encontraram foi devastador o suficiente para reverter uma das implantações de IA mais divulgadas da história das fintechs.

Eis a versão curta: a Klarna, a gigante sueca de buy-now-pay-later avaliada em US$ 14,6 bilhões, substituiu cerca de 700 agentes de atendimento ao cliente por um assistente de IA construído sobre a OpenAI. Anunciaram aquilo como uma volta olímpica — a IA estava atendendo 75% de todos os chats com clientes em 35 idiomas. O custo por transação caiu 40%. Wall Street adorou. Então as notas de satisfação do cliente caíram 22%. A empresa registrou um prejuízo líquido de US$ 99 milhões no primeiro trimestre de 2025. E o CEO Sebastian Siemiatkowski admitiu publicamente que a busca por eficiência havia destruído a qualidade do serviço, produzindo saídas que ele chamou de "genéricas" e incapazes de lidar com qualquer coisa que exigisse julgamento de verdade.

Eles começaram a recontratar. Chegaram a realocar engenheiros de software e profissionais de marketing para atender os telefones.

Venho construindo sistemas de IA neuro-simbólica na Veriprajna há anos, e assisti empresa após empresa cair exatamente na mesma armadilha. Não porque a tecnologia seja ruim — os grandes modelos de linguagem são genuinamente notáveis. Mas porque existe uma confusão fundamental entre parecer certo e estar certo, e em setores regulados essa confusão vai acabar custando tudo a você.

A noite em que percebi que "bom o suficiente" não basta

Antes de entrar na arquitetura, quero contar sobre um momento que mudou a forma como penso nesse problema.

Estávamos rodando um piloto para um sistema de compliance jurídico — não atendimento ao cliente, mas análise de documentos. O tipo de trabalho em que você analisa registros regulatórios e cruza políticas internas com exigências externas. Tínhamos um protótipo que usava uma configuração padrão de retrieval-augmented generation. Busca vetorial, recuperação top-k, GPT gerando o resumo. Era rápido. As saídas eram lindas de ler.

Uma de nossas engenheiras — Priya — ficou até tarde rodando casos extremos. Por volta das 23h ela mandou um print no nosso canal do Slack. O sistema havia gerado um parágrafo perfeitamente fluente citando uma cláusula regulatória específica. A cláusula não existia. Não era uma citação errada, não era uma paráfrase — era uma fabricação completa. E era tão convincente que, se você não fosse especialista naquela regulamentação específica, jamais perceberia.

Lembro de ficar sentado à minha mesa olhando para aquele print e pensando: este é o produto que estamos prestes a lançar. Um sistema que mente com a confiança de um sócio sênior de um escritório de advocacia.

Cancelamos o piloto. Reconstruímos a arquitetura do zero. Perdemos três meses. Foi a melhor decisão que já tomamos.

Quando um sistema de IA fabrica uma citação jurídica com confiança perfeita, o problema não é um bug — é a arquitetura. Não dá para sair de uma base fundamentalmente probabilística à base de engenharia de prompt.

O que é a "armadilha do wrapper" e por que ela continua pegando empresas inteligentes?

Deixe-me explicar o que de fato aconteceu com a Klarna em termos técnicos, porque a imprensa de negócios em geral entendeu errado. Enquadraram o caso como "a IA ainda não está pronta". Não é essa a questão. A questão é qual tipo de IA e como ela foi implantada.

Um "wrapper" é uma fina camada de software que fica em cima de um grande modelo de linguagem de terceiros. Ela cuida da formatação, gerencia as chamadas de API, talvez acrescente algum parsing de saída estruturada. Mas o pensamento de fato — o raciocínio, o julgamento, a tomada de decisão — é inteiramente terceirizado para o LLM. Seu wrapper envia um prompt, o modelo prevê os próximos tokens mais prováveis, e você recebe de volta algo que soa como uma resposta.

Isso funciona lindamente para uma demo. Funciona de forma adequada para tarefas de baixo risco. E fracassa catastroficamente para qualquer coisa que exija certeza.

A arquitetura Transformer que alimenta esses modelos usa um mecanismo de autoatenção para ponderar a relevância dos tokens em uma sequência e prever o que vem em seguida. Isso é correspondência de padrões — correspondência de padrões extraordinariamente sofisticada, mas ainda assim correspondência de padrões. Não existe mecanismo interno para verificar fatos contra uma fonte externa de verdade. O modelo não sabe nada. Ele prevê a aparência que teria uma resposta bem-informada.

A IA da Klarna conseguia redefinir senhas com perfeição. Mas quando um cliente tinha uma disputa complexa envolvendo um reembolso parcial, um desacordo com o lojista e regulamentações de proteção ao consumidor em duas jurisdições? O modelo recorria ao que eu chamo de slop-spinning — gerar respostas de som plausível que davam voltas em círculos, sem nunca resolver nada, frustrando os clientes no que um analista descreveu como um "loop kafkiano".

E aqui está a parte que deveria aterrorizar todo líder empresarial: as métricas de custo pareciam ótimas durante todo o tempo em que a experiência se deteriorava. O custo por transação caiu de US$ 0,32 para US$ 0,19. O tempo de resolução do chat foi de 11 minutos para menos de 2. Se você estivesse olhando apenas o dashboard, acharia que estava vencendo — até o momento exato em que seus clientes começaram a ir embora.

Por que você não pode simplesmente adicionar guardrails melhores a um LLM?

Essa é a pergunta que mais recebo, e ela revela o mal-entendido central. As pessoas acham que a solução são prompts melhores, mais exemplos few-shot, instruções de sistema mais rígidas. "É só dizer ao modelo para não alucinar."

Isso é como dizer a um modelo de previsão do tempo para não errar. A natureza probabilística não é uma falha a ser remendada — é o mecanismo fundamental de como o sistema funciona.

Uma vez, um investidor me disse, sem rodeios: "É só usar GPT e colocar algumas regras em cima." Perguntei se ele confiaria em uma calculadora que acertasse 95% das vezes. Ele riu. Eu disse: "É isso que você está propondo para compliance bancário." Ele parou de rir.

Os modos de falha técnica vão mais fundo do que a alucinação. Wrappers não têm o que eu chamaria de persistência de state-schema. Conforme a conversa avança, a janela de contexto vai enchendo. Informações do início da conversa são comprimidas ou descartadas. O modelo pode se contradizer dentro de uma mesma sessão e não ter nenhuma consciência de que fez isso. No atendimento ao cliente, isso significa que o agente pode verificar sua identidade no turno 3 e depois pedir que você verifique de novo no turno 15 — ou pior, pular a verificação por completo porque o fluxo da conversa o "convenceu" de que a verificação já havia ocorrido.

Essa é a vulnerabilidade que chamo de Falácia da Liberdade Infinita. Como o LLM não tem restrições estruturais rígidas sobre o que pode dizer ou fazer, um usuário suficientemente esperto — ou uma situação suficientemente complexa — consegue empurrá-lo para estados que violam regras de negócio, exigências regulatórias ou a lógica básica. Não dá para resolver isso com prompting. Você precisa de um tipo de arquitetura completamente diferente.

Escrevi sobre esse problema em profundidade na versão interativa da nossa pesquisa, mas a percepção central é simples: você precisa separar a voz do cérebro.

Os 20% que quebram tudo

Há um padrão que já vi em todos os setores em que atuamos, e acho que ele explica por que tantas implantações de IA seguem a trajetória da Klarna.

A IA em 2025 consegue lidar com competência com cerca de 80% das interações rotineiras e de alta frequência. Redefinições de senha, consultas de status de pedido, respostas básicas de FAQ — esses são problemas resolvidos. Os 20% restantes das interações são os que realmente importam. São as disputas complexas, os casos extremos, os momentos em que um cliente está frustrado, confuso ou assustado. E são os principais motores da reputação da marca e do passivo financeiro.

A Klarna otimizou para os 80% e ignorou os 20%. A conta parecia óbvia: automatize o que é fácil, economize milhões. Mas os 20% são onde a confiança é construída ou destruída. Um cliente que redefine a senha sem atrito não conta para ninguém. Um cliente que passa 45 minutos preso em um loop de IA tentando resolver um erro de cobrança conta para todo mundo.

Os 80% das interações que a IA resolve bem são invisíveis para a sua marca. Os 20% que ela resolve mal são os únicos de que alguém se lembra.

A ironia é que os US$ 10 milhões iniciais de economia da Klarna com a redução de quadro foram quase certamente superados de longe pelo valor do tempo de vida do cliente que eles destruíram por meio de experiências degradadas. Quando você é uma empresa de US$ 14,6 bilhões se preparando para um IPO, uma queda de 22% na satisfação do cliente não é um problema de métrica — é um problema existencial.

O que "IA determinística" realmente significa?

Então, se os wrappers são o problema, qual é a solução? É aqui que preciso ficar um pouco técnico, mas prometo manter os pés no chão.

Na Veriprajna, construímos o que se chama de IA neuro-simbólica. O nome soa acadêmico, mas o conceito é intuitivo: você pega a fluência linguística de uma rede neural e a restringe dentro da lógica rígida de um motor de raciocínio simbólico. A rede neural cuida do trabalho "leve" — entender linguagem natural, gerar respostas legíveis por humanos, interpretar consultas ambíguas. O motor simbólico cuida do trabalho "duro" — impor regras, validar a lógica, garantir que toda saída seja rastreável até uma fonte verificada.

Chamamos isso de Sanduíche Neuro-Simbólico. Antes de uma consulta chegar ao LLM, uma camada de validação de intenção a confronta com as restrições de política e faz a triagem de entradas adversariais. Depois que o LLM gera uma resposta, um motor de validação — tipicamente uma Máquina de Estados Finitos ou um solucionador lógico — valida cada afirmação no knowledge graph e cada ação contra as regras de negócio. Se a resposta violar qualquer restrição, ela não passa. Ponto final.

Existe uma técnica que usamos chamada decodificação restrita — também conhecida como token masking — que acho particularmente elegante. Em vez de deixar o modelo gerar livremente e depois checar a saída, nós impedimos fisicamente que certos tokens sejam gerados já de saída. Se o modelo está produzindo um relatório de compliance tributário, a camada simbólica garante que cada número corresponda a um cálculo verificado. O modelo literalmente não pode alucinar um número, porque os tokens alucinados são mascarados da distribuição de probabilidade antes que a geração ocorra.

Isso não é "adicionar guardrails". Isso é uma arquitetura fundamentalmente diferente, em que o LLM é a voz e o motor simbólico é o cérebro, e a voz nunca tem permissão para falar sem a aprovação do cérebro.

Quando o knowledge graph nos salvou de um erro de US$ 2 milhões

O RAG padrão — retrieval-augmented generation — tem um problema do qual a maioria das pessoas não fala. Ele depende de similaridade vetorial para encontrar documentos relevantes. Mas a similaridade vetorial não entende direcionalidade. "A Empresa A processou a Empresa B" e "A Empresa B processou a Empresa A" podem ter embeddings vetoriais quase idênticos, mas descrevem situações jurídicas completamente opostas.

Descobrimos isso da maneira difícil durante um piloto jurídico. Nosso sistema estava analisando o histórico de litígios de um cliente corporativo, e a configuração padrão de RAG vivia confundindo os papéis de autor e réu. As saídas eram fluentes, bem estruturadas e perigosamente erradas.

Foi aí que migramos para o que chamamos de GraphRAG com Citação Imposta. Em vez de despejar documentos em um vector store, nós os analisamos e os transformamos em um knowledge graph — entidades conectadas por relações tipadas e direcionais. Quando o sistema faz uma afirmação, ele precisa rastrear essa afirmação de volta até nós e arestas específicos do grafo. Se o grafo não sustenta a afirmação, o sistema não a faz.

A melhoria de acurácia foi dramática — 30-35% superior ao RAG padrão em tarefas complexas de raciocínio multi-hop. Mas, mais importante, isso nos deu algo que nenhuma quantidade de engenharia de prompt poderia dar: uma trilha de auditoria. Toda saída pode ser rastreada de volta pelo caminho exato de raciocínio, de entidade em entidade, de relação em relação. Um responsável por compliance consegue ver por que o sistema chegou a uma conclusão, não apenas o que ele concluiu.

Para o detalhamento técnico completo de como essa arquitetura funciona em diferentes domínios — bancário, jurídico, manufatura — veja nosso aprofundamento técnico.

A discussão que quase dividiu meu time

Quero ser honesto sobre uma coisa. Construir dessa forma é mais difícil. Significativamente mais difícil. E houve um momento, talvez dezoito meses atrás, em que meu time teve uma discussão genuína sobre se estávamos superengenheirando.

Estávamos em uma sala de reunião — quadros brancos cobertos de diagramas de arquitetura — e um dos nossos engenheiros seniores defendeu que deveríamos lançar um MVP baseado em wrapper para um cliente da manufatura. "Fature primeiro, prove o conceito, reforce a arquitetura depois." Era um argumento razoável. O cliente estava ansioso. O prazo estava apertado. E todo concorrente do nosso espaço estava lançando produtos-wrapper e fechando negócios.

Lembro do silêncio depois que ele terminou. Então Priya — a mesma engenheira que havia pegado a citação fantasma — abriu um slide que estava guardando. Ele mostrava três casos reais do trimestre anterior em que sistemas de IA baseados em wrapper haviam gerado saídas que, se tivessem sido seguidas, teriam violado exigências regulatórias. Não violações hipotéticas. Violações reais, pegas apenas porque, por acaso, havia humanos no loop.

Tomei a decisão de manter o rumo. Perdemos aquele negócio para um concorrente que entregou mais rápido. Seis meses depois, o sistema do concorrente produziu uma violação de compliance que custou ao cliente dele uma remediação de sete dígitos. O cliente veio para nós.

Velocidade sem correção não é vantagem competitiva. É um passivo com pavio retardado.

Não estou contando essa história para parecer clarividente. Estou contando porque a pressão para lançar rápido e iterar depois é enorme e, na maioria dos contextos de software, é o instinto certo. Mas em setores regulados — bancário, saúde, jurídico, manufatura — "iterar depois" significa "consertar depois da violação". E violações nesses domínios não vêm com período de carência.

Por que 2026 é o ano em que a conta chega

Eis o cenário macro. A McKinsey descobriu que, embora 88% das organizações estejam usando IA, apenas 39% conseguem apontar um impacto positivo nos lucros no nível corporativo. Essa lacuna está prestes a se tornar insustentável.

A fase de "investir e aprender" da adoção de IA acabou. Os CFOs não estão mais perguntando "Estamos usando IA?". Estão perguntando "Qual é o impacto no EBIT?". E, para a maioria das organizações, a resposta honesta é: "Economizamos algum tempo em tarefas administrativas."

Isso não basta. Economizar tempo em e-mails e apresentações é "IA de Produtividade" — útil, mas incremental. O que as empresas de fato precisam é de "IA Operacional" — sistemas que eliminam atrito de dinheiro real na economia física. Evitar rupturas de estoque. Pegar violações de compliance antes que aconteçam. Reduzir o custo anual de US$ 890 bilhões das devoluções no varejo oferecendo provador virtual preciso em vez de imagens de fantasia geradas por IA que ficam lindas, mas não refletem como o tecido de fato cai sobre um corpo humano.

A história da Klarna é instrutiva aqui porque as métricas deles pareciam ROI. Custo por transação 40% menor! Mas eles estavam medindo a coisa errada. Mediram tempo economizado e quadro reduzido. Não mediram confiança corroída e clientes perdidos. Quando você considera os custos de recontratação, o dano à marca e o prejuízo de US$ 99 milhões do primeiro trimestre, a "economia" evapora.

As empresas que vão vencer em 2026 são as que medem perdas operacionais evitadas, não horas economizadas. As que implantam IA capaz de simular 10.000 cenários de disrupção na cadeia de suprimentos da noite para o dia e construir manuais de recuperação de crise que nenhum time humano produziria em uma década. Aquelas cujos sistemas de IA conseguem provar seu raciocínio a um regulador, não apenas produzir um parágrafo convincente.

E quanto aos humanos?

As pessoas sempre contestam esse enquadramento. "Se a IA ficar tão boa assim, o que acontece com as pessoas?"

Acho que a resposta é o oposto do que a maioria das pessoas espera. As organizações que implantam IA profunda e arquiteturalmente sólida não precisam de menos humanos — precisam de humanos diferentes. A pirâmide tradicional da consultoria, com sua base enorme de analistas juniores fazendo síntese de dados e montagem de apresentações, está desmoronando. A IA faz esse trabalho mais rápido e melhor. Mas a necessidade de julgamento sênior, pensamento estratégico, supervisão ética e empatia humana genuína não está apenas sobrevivendo — está se intensificando.

O que está surgindo é algo que o setor chama de modelo "Obelisk": times mais enxutos e com mais especialistas, em que profissionais em início de carreira são "facilitadores de IA" que desenham e gerenciam fluxos de trabalho de IA, profissionais de meio de carreira são "arquitetos de engajamento" que definem quais problemas vale a pena resolver, e líderes seniores se concentram no trabalho profundamente humano de construir confiança e navegar a ambiguidade.

O assistente de IA interno da McKinsey, o "Lilli", é usado por 72% da força de trabalho da firma e cortou o tempo de pesquisa em 30%. O "Deckster", da BCG, automatiza a criação de apresentações. Mas nenhuma das duas consultorias está encolhendo. Elas estão se reestruturando — trocando volume por precisão, trocando horas faturadas por resultados entregues.

O erro da Klarna não foi usar IA. Foi usar IA como substituto dos humanos em vez de amplificador da capacidade humana. Essa distinção parece sutil. Não é. É a diferença entre uma economia de US$ 10 milhões e um prejuízo de US$ 99 milhões.

A arquitetura da confiança

Quero encerrar com algo que está na minha cabeça desde aquela madrugada em que Priya encontrou a citação fantasma.

Estamos vivendo um momento em que sistemas de IA conseguem produzir saídas indistinguíveis do trabalho de especialistas humanos — e ainda assim completamente, confiantemente erradas. Isso não é uma limitação temporária que será resolvida pelo GPT-6 ou GPT-7. É uma propriedade inerente ao funcionamento dos modelos de linguagem probabilísticos. Eles otimizam para plausibilidade, não para verdade. E em domínios onde a verdade importa — onde uma resposta errada significa uma violação de compliance, um diagnóstico errado, um precedente jurídico fabricado — a plausibilidade é a coisa mais perigosa do mundo.

A solução não é abandonar a IA. A solução é construir sistemas de IA em que a verdade seja imposta arquiteturalmente, não esperada probabilisticamente. Em que toda afirmação seja rastreável até uma fonte verificada. Em que o sistema literalmente não consiga gerar uma saída que viole as regras do domínio em que opera. Em que a trilha de auditoria não seja um recurso — seja o alicerce.

É isso que construímos na Veriprajna. Não porque a IA determinística seja mais fácil — ela é consideravelmente mais difícil. Não porque ela fique melhor em demo — wrappers ficam lindos em demo. Mas porque, em setores que não podem se dar ao luxo de adivinhar, a única arquitetura sustentável é aquela que torna o adivinhar impossível.

A Klarna aprendeu essa lição ao custo de 700 empregos, uma queda de 22% no CSAT e um prejuízo trimestral de US$ 99 milhões. A pergunta para todo líder empresarial que lê isto é simples: você quer aprendê-la pela história deles ou pela sua própria?

O futuro da IA corporativa não tem a ver com tornar os modelos de linguagem mais inteligentes. Tem a ver com torná-los responsabilizáveis — arquiteturalmente, comprovadamente, imutavelmente responsabilizáveis.

A era do wrapper acabou. O que vem a seguir será mais difícil de construir, mais lento de lançar e valerá cada mês extra de engenharia. Porque, no fim das contas, o único sistema de IA que vale a pena implantar é aquele em que você apostaria sua empresa. E você nunca deveria apostar sua empresa em um sistema que não consegue mostrar seu trabalho.