Para líderes que gerem ou patrocinam a implementação de IA no serviço de apoio ao cliente, e para todos os que estão prestes a aprovar a 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 lacuna entre o piloto e a produção não é um problema de tecnologia, é um problema estrutural. Os pilotos são construídos em torno de condições que não existem em escala: dados curados, âmbito limitado, equipas dedicadas e métricas de sucesso frequentemente definidas apenas após os primeiros resultados já estarem disponíveis. A produção elimina tudo isso. 

Por que enfrentamos esta dificuldade 

A IA no 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 distância entre os líderes e os retardatários está a aumentar rapidamente. A questão já não é se deve implementar IA no apoio ao cliente. É como fazer com que ela funcione de forma sustentável. 

Por que os pilotos vencem por design 

Os pilotos são feitos para ter sucesso. Nenhuma das quatro condições que os fazem parecer bons sobreviverá ao contacto com a produção: 

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

• Dados curados: sem casos extremos, sem inconsistências de sistemas legados, sem as contradições da base de conhecimento que existem no seu sistema real. 

• Um ambiente controlado: uma equipa dedicada com total atenção, enquanto a produção significa recursos partilhados e uma dúzia 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 em relação a uma fasquia que ele próprio ajudou a definir. 

Um piloto existe para o ajudar a aprender, e é a única janela onde ainda tem pessoas dedicadas, 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 em produção, quando a equipa já se dispersou e corrigir as coisas custa muito mais. O desconforto de encontrar problemas cedo é o objetivo principal. Um piloto que não encontra nada de errado foi, quase de certeza, procurar nos locais errados. 

O padrão que qualquer líder reconhece 

O piloto parece robusto. As taxas de automatização melhoram, os níveis de serviço mantêm-se, as partes interessadas estão entusiasmadas e a administração aprova a fase seguinte.  

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

Isto não é azar, é o que acontece por predefinição quando um piloto é desenhado para validar uma decisão que já tomou, em vez de testar se essa decisão se sustenta quando surgem as condições reais. 

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

Temos visto as mesmas seis lacunas aparecerem repetidamente, em implementações de seguros, e-commerce, bens de grande consumo (FMCG), energia e serviços financeiros. O setor não parece importar. 

1. Design do piloto. Os pilotos correm em horários estruturados e com clientes cooperantes, ignorando picos de carga e intensidade emocional. Um piloto de seguros parecia robusto até que a produção trouxe volumes 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 correm com conteúdo curado, enquanto a produção expõe todos os artigos desatualizados e contradições. Um retalhista de e-commerce tinha artigos sobre políticas de devolução que se contradiziam entre si e com a própria lógica do agente, 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 agentes 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 correm frequentemente com sistemas simulados ou desconetados, pelo que 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 corrigir de forma económica.

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

4. Adequação do caso de uso e presunção de portabilidade. 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. Compliance, regulamentação e infraestrutura. Os pilotos correm normalmente abaixo do radar do compliance. Uma implementação bancária provou o conceito com sucesso à escala do piloto, mas bateu numa barreira no momento em que a gestão 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 silenciosamente adiado.  

A solução: envolver o compliance e a infosec desde cedo, mesmo que isso abrande o piloto. 
 

6. Propriedade operacional e manutenção. Os pilotos correm com pessoas seniores e empenhadas de ambos os lados, mas a produção necessita de uma transição estruturada. Sem um proprietário nomeado 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 proprietários nomeados para a otimização, conhecimento e escalonamento. 

Como é uma implementação de nível de produção: um importante fornecedor europeu de bancasseguros

O encaminhamento de chamadas recebidas deste cliente é um caso onde as decisões difíceis, os requisitos de compliance ao abrigo do DORA, a complexidade de integração e as restrições de infraestrutura foram confrontados durante o projeto, e 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 globalmente. A solução substituiu inteiramente 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 design. 

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 na satisfação do cliente e produtividade dos agentes, porque as lacunas que habitualmente surgem em produção já tinham sido resolvidas durante o projeto. 

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

Não tentam automatizar tudo de uma vez para justificar o investimento. É exatamente por isso que a maioria falha. Em vez disso, elas: 

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

• Começam pequeno mas desenham 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 mediar o impacto em 30 dias, escolheu o caso de uso errado. 

• Atribuem responsabilidade operacional, com proprietários nomeados para otimização, conhecimento e escalonamento. Não o fornecedor, e não apenas o departamento de TI. 

• Preparam o terreno ao nível de 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 assinalar. O objetivo não é um relatório final bonito. É uma lista completa de tudo o que precisa de estar assegurado antes da produção, testado e corrigido enquanto a equipa e o orçamento ainda estão disponíveis. 

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

• Sobre o design do piloto: Como desenhamos 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 estiver em produção, e como é que se parece realmente um modelo operacional sustentável? 

• Sobre a priorização de casos de uso: Como equilibramos as metas 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 assegurados desde o início? 

Quer aprofundar o assunto?  

Este artigo baseia-se no briefing da 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.