Para líderes que gerem ou patrocinam a implementação de IA no serviço de apoio ao cliente, e para qualquer pessoa prestes a dar luz verde à fase seguinte após um piloto promissor. 

A maioria dos pilotos de Conversational AI é bem-sucedida. A maioria das implementações em produção não cumpre o que o piloto prometeu.  

Se isto parece uma contradição, não é.  

Provavelmente já viu isto acontecer; é o padrão mais previsível em IA empresarial hoje em dia, e surgiu repetidamente numa conversa que organizámos com líderes seniores numa mesa-redonda de pequeno-almoço do Directors Club, em Londres. 

A diferença entre o piloto e a produção não é um problema tecnológico, é um problema estrutural. Os pilotos são construídos em torno de condições que não existem à escala: dados selecionados, âmbito limitado, equipas dedicadas e métricas de sucesso frequentemente definidas apenas após os primeiros resultados já terem surgido. A produção elimina tudo isso. 

Por que enfrentamos esta dificuldade 

A IA no serviço de apoio ao cliente já não é uma aposta que está a ponderar. Já está aqui, e os números confirmam-no, de acordo com o Microsoft's 2025 Work Trend Index: 

A diferença entre os líderes e os retardatários está a aumentar rapidamente. A questão já não é se vai implementar IA no serviço de apoio ao cliente. É como a vai consolidar. 

Por que os pilotos vencem por conceção 

Os pilotos são concebidos para vencer. Nenhuma das quatro condições que os fazem parecer bem sobreviverá ao contacto com a produção: 

• Âmbito limitado: testa os cenários ideais, de elevado volume e fluxos bem documentados. As interações confusas, ambíguas e emocionalmente carregadas raramente entram no teste. 

• Dados selecionados: sem casos limite, sem inconsistências de sistemas legados, sem nenhuma das contradições na base de conhecimento que existem no seu sistema real. 

• Um ambiente controlado: uma equipa dedicada com atenção total, enquanto a produção significa recursos partilhados e uma dezena de prioridades concorrentes a desviar as mesmas pessoas. 

• Medição favorável: define as métricas de sucesso após ver os primeiros resultados, pelo que o piloto acaba por ser medido face a uma fasquia que ele próprio ajudou a estabelecer. 

Um piloto existe para o ajudar a aprender, e é a única janela onde ainda tem pessoas dedicadas, a atenção da liderança e orçamento para corrigir o rumo. Cada problema que encontra durante o piloto é um problema que não irá descobrir na produção, quando a equipa já se dispersou e corrigir as coisas custa uma ordem de grandeza superior. O desconforto de encontrar problemas cedo é todo o objetivo. Um piloto que não encontra nada de errado esteve, quase de certeza, a procurar nos sítios errados. 

O padrão que qualquer líder reconhece 

O piloto parece forte. As taxas de automatização melhoram, os níveis de serviço mantêm-se, os stakeholders estão entusiasmados e a administração aprova a fase seguinte.  

Depois a produção chega. As taxas de escalonamento sobem, a complexidade aumenta, as operações lutam para acompanhar o ritmo, os custos voltam a subir e, discretamente, o projeto é arquivado. 

Isto não é falta de sorte, é o que acontece por predefinição quando um piloto é concebido para validar uma decisão que já tomou, em vez de testar se essa decisão se mantém quando as condições reais se impõem. 

Seis coisas que falham entre o piloto e a produção 

Vimos estas mesmas seis lacunas surgirem repetidamente em implementações de seguros, e-commerce, FMCG, energia e serviços financeiros. O setor não parece importar. 

1. Conceção do piloto. Os pilotos funcionam em horários estruturados e com clientes cooperativos, ignorando os picos de carga e a intensidade emocional. Um piloto de seguros parecia forte até que a produção trouxe um volume e uma amplitude emocional para os quais o piloto nunca tinha sido testado.  

A solução: testar as horas de pico e a amplitude emocional real antes do go-live, não depois. 
 

2. Qualidade da base de conhecimento. Os pilotos funcionam com conteúdo selecionado, enquanto a produção expõe cada artigo desatualizado e contradição. Um retalhista de e-commerce tinha artigos sobre políticas de devolução que se contradiziam entre si e à própria lógica do assistente, uma base de conhecimento que simplesmente nunca tinha sido auditada face ao processo real.  

A solução: auditar toda a base de conhecimento face à lógica real dos assistentes antes do go-live e tratá-la como uma manutenção contínua. 

3. Integração de sistemas e preparação de dados. Os pilotos funcionam frequentemente com sistemas simulados ou desligados, por isso nada atrasa a conversa. Uma empresa de FMCG evitou isto integrando-se com a sua sandbox do Salesforce durante o piloto, detetando um estrangulamento nas consultas a tempo de o resolver de forma económica.

A solução: integrar-se com sistemas reais durante o piloto, não depois; os estrangulamentos encontrados cedo são um sucesso. 

4. Adequação do caso de uso e portabilidade assumida. O que funciona num mercado raramente se transfere automaticamente para outro. Um caso de uso de encomendas B2B construído com base na estrutura de compras de um mercado europeu não tinha cabimento no Reino Unido, onde as relações com os compradores funcionam de forma diferente.  

A solução: validar a adequação localmente antes de assumir a portabilidade entre mercados ou unidades de negócio. 

5. Conformidade, regulação e infraestrutura. Os pilotos funcionam normalmente abaixo do radar da conformidade. Uma implementação bancária provou o conceito perfeitamente à escala do piloto, mas bateu numa barreira no momento em que o tratamento de dados à escala de produção e as questões de segurança ativaram todo o mecanismo de infosec do banco, uma conversa que ambas as partes tinham discretamente adiado.  

A solução: envolver a conformidade e a infosec cedo, mesmo quando isso abranda o piloto. 
 

6. Propriedade operacional e manutenção. Os pilotos decorrem com pessoas seniores e empenhadas de ambos os lados, mas a produção necessita de uma transição estruturada. Sem um responsável designado para a otimização, conhecimento e escalonamento, a degradação instala-se rapidamente assim que a equipa do projeto avança para outra tarefa. 

A solução: definir a matriz RACI antes do encerramento do piloto, com responsáveis designados para a otimização, conhecimento e escalonamento. 

Como se parece uma implementação de nível de produção: um fornecedor europeu líder em bancasseguros

O encaminhamento de chamadas recebidas deste cliente é um caso em que as decisões difíceis, os requisitos de conformidade ao abrigo do DORA, a complexidade da integração e as restrições de infraestrutura foram enfrentados durante o projeto, não depois. 

O IVR tradicional forçava os clientes a opções de menu genéricas, aumentando as transferências, o custo e a frustração, enquanto a distribuição manual de chamadas inflacionava os tempos de atendimento de forma geral. A solução substituiu totalmente o IVR por classificação de intenções em tempo real, encaminhando cada chamada para a equipa certa sem menus ou transferências, integrada com Talkdesk CTI e Salesforce CRM para distribuição automatizada de chamadas e criação de casos, e alojada na nuvem privada Microsoft Azure para segurança e governação por conceção. 

O resultado: Mais de 90% de precisão na classificação de intenções no encaminhamento de chamadas, redução das transferências de chamadas, resolução mais rápida de problemas e melhoria da satisfação do cliente e da produtividade dos assistentes, porque as lacunas que habitualmente surgem na produção já tinham sido eliminadas durante o projeto. 

O que as organizações que escalam a IA fazem de diferente 

Não tentam automatizar tudo ao mesmo tempo para justificar o investimento. É exatamente por isso que a maioria das outras falha. Em vez disso, elas: 

• Escolhem o caso de uso de entrada certo: maior volume, âmbito mais claro, impacto mensurável mais rápido. Prove-o antes de o escalar. 

• Começam pequenas, mas projetam a pensar na expansão, documentando para onde vai o roadmap após o primeiro lançamento. 

• Medem o impacto desde o primeiro dia. Se não conseguir medi-lo em 30 dias, escolheu o caso de uso errado. 

• Atribuem propriedade operacional, com responsáveis designados para a otimização, conhecimento e escalonamento. Não o fornecedor, e não a TI de forma isolada. 

• Preparam o terreno nos dados, sistemas e gestão de mudança antes do arranque, em vez de descobrirem o que falta quando já estão em produção. 

Tratam o piloto como uma ferramenta de aprendizagem, não como uma tarefa a cumprir. O objetivo não é um relatório final bonito. É uma lista completa de tudo o que precisa de ser verdade antes da produção, testado e corrigido enquanto a equipa e o orçamento ainda estão presentes. 

Perguntas que vale a pena levar para a sua própria organização 

• Sobre a conceção do piloto: Como concebemos pilotos que prevejam genuinamente o desempenho em produção, e não apenas que provem um conceito? 

• Sobre a propriedade operacional: Quem é o proprietário do serviço de apoio ao cliente baseado em IA quando este entra em produção, e como é realmente um modelo operacional sustentável? 

• Sobre a priorização de casos de uso: Como equilibramos os objetivos de automatização com a experiência do cliente, e como garantimos que os casos de uso certos, e a experiência certa, estão implementados desde o início? 

Quer aprofundar o assunto?  

Este artigo baseia-se no briefing da nossa Mesa-Redonda de Pequeno-Almoço do Directors Club, "Why Conversational AI Wins Pilots and Loses in Production" que realizámos em Londres. Documento completo aqui.