O que a IBM levou 6 anos para aprender sobre IA — e que a maioria das empresas ignora

Toda semana aparece um novo case de IA com números impressionantes. A maioria some da memória em dias.

O AskHR da IBM não some. E o motivo é exatamente o oposto do que você espera.

1. O case que todo mundo cita pelo motivo errado

Quando alguém menciona o AskHR, os números vêm rápidos: 11,5 milhões de interações em 2024. 94% de containment rate. NPS saiu de -35 para +74. 40% de redução nos custos operacionais de RH em quatro anos. Adoção de 99% entre gestores.

São números que param qualquer reunião de liderança. E é exatamente por isso que o case costuma ser mal lido.

A maioria das empresas ouve esses números e pensa: "precisamos de um agente de IA para o RH". Pegam um LLM, conectam na base de conhecimento, botam um chat na intranet e chamam de transformação digital.

Seis meses depois, o agente responde errado, os funcionários param de usar, e a iniciativa morre em silêncio.

O que o case AskHR realmente ensina não está nos números finais. Está no número que quase ninguém menciona: 6 anos.

2. Seis anos não é uma linha do tempo. É uma filosofia

O AskHR não nasceu pronto em 2024. Começou anos antes como um assistente virtual simples de RH, foi iterado continuamente, e só recentemente integrou capacidades mais avançadas com o watsonx Orchestrate.

Isso significa que cada automação, cada fluxo, cada integração passou por ciclos reais de uso, feedback, ajuste e reuso. Não foram construídos em uma sprint de dois meses com pressão para mostrar demo para o board.

Para equipes de produto, isso é a lição mais importante e a mais difícil de vender internamente: IA bem implantada é lenta no começo e acelerada no longo prazo. O inverso do que a maioria das organizações quer ouvir.

3. Os quatro princípios que ninguém coloca no slide

Quando você desmonta o AskHR além dos números, quatro decisões de produto aparecem como responsáveis pelo resultado:

1. Domínio estreito, não plataforma universal

O AskHR não foi construído para "resolver tudo de RH". Foi construído para resolver tarefas específicas e bem definidas: cartas de emprego, solicitações de férias, acesso a folha de pagamento, transferências internas. Hoje são 80 a 90 automações — mas cada uma foi adicionada com critério, não com ambição.

Esse foco é contraintuitivo em um mercado que vende plataformas "end-to-end" de IA. Mas é o que garante qualidade: um agente que faz 10 coisas muito bem é infinitamente mais útil do que um que faz 100 coisas mais ou menos.

2. Integração profunda, não camada por cima

O AskHR não é uma interface bonita em cima de um PDF de políticas de RH. Ele está integrado com Workday, SAP e Concur. Isso significa que quando um funcionário pede informações sobre seu contracheque, o sistema acessa o dado real, não um texto genérico.

Essa profundidade de integração é cara e demorada de construir. É também o que separa um agente útil de um agente frustrante.

3. Modelo híbrido: agente para o rotineiro, humano para o complexo

O 94% de containment rate costuma ser vendido como eficiência máxima. Mas o detalhe mais importante é o 6% restante: esses casos são intencionalmente encaminhados para especialistas humanos.

O AskHR não tentou automatizar 100% das interações. Reconheceu que há situações onde o toque humano não é um custo — é o produto. Projetar esse limite com cuidado é o que manteve o NPS positivo.

4. Iteração longa sem perder o fio

Seis anos de desenvolvimento pressupõem algo que a maioria das empresas não tem: continuidade. O mesmo time, a mesma visão, o mesmo compromisso com o produto ao longo de vários ciclos de liderança, tecnologia e contexto de negócio.

Isso é raro. E é provavelmente o fator mais difícil de replicar.

4. O que o NPS de -35 para +74 realmente significa

Vale parar nesse número um momento.

NPS negativo significa que os usuários estavam ativamente desrecomendando o produto. Alguém perguntava "como você resolve dúvidas de RH?" e a resposta era: "não usa aquele sistema, vai direto falar com alguém".

Chegar a +74 não é uma melhoria incremental. É uma reversão completa de percepção. E ela não aconteceu porque o modelo de linguagem ficou melhor — aconteceu porque o produto ficou melhor. Mais preciso, mais integrado, mais confiável, mais claro sobre o que faz e o que não faz.

Para times de produto, esse é o KPI mais honesto de IA em produção: não quantas interações o agente processa, mas se os usuários o recomendam. Tudo o mais é vaidade de painel.

5. O que isso significa para quem está implantando IA agora

A maioria das empresas brasileiras está na fase de pilotos. Alguns projetos maduros. Poucos em escala real.

O AskHR oferece um modelo mental útil para qualquer organização que quer sair do piloto e construir algo duradouro:

Comece pequeno, mas comprometa-se longo. Escolha um domínio específico onde IA resolve um problema real e com dados suficientes para aprender. Não tente resolver tudo de uma vez. Mas também não trate como experimento descartável — trate como produto que vai crescer.

Integre de verdade ou não integre. Uma camada de IA em cima de dados desatualizados ou sistemas desconectados não gera confiança. Gera frustração. Se a integração profunda não é viável agora, adie o lançamento até que seja.

Desenhe o modelo híbrido desde o início. Decida explicitamente quais situações o agente resolve e quais ele encaminha. Essa fronteira não é fraqueza — é design. E deve ser comunicada claramente para o usuário.

Meça o que importa para o usuário, não para o board. Containment rate impressiona apresentação. NPS diz se o produto tem futuro.

6. O case AskHR não é sobre IA

É sobre o que acontece quando uma organização trata IA como produto — com a mesma disciplina, iteração e compromisso de longo prazo que qualquer produto bem construído exige.

A tecnologia foi necessária. Mas não foi suficiente.

Nunca é.

Este artigo integra uma série sobre IA aplicada em produtos reais. Referências: case público IBM AskHR, IBM watsonx Orchestrate, reportagens de 2024-2025 sobre a evolução do assistente de RH da IBM.