A IA pode responder a perguntas corretamente e, mesmo assim, falhar quando não reconhece mudanças de tarefas, contexto ou consequências.
“A IA deveria se colocar no lugar do cliente?”
Essa ideia me pareceu inovadora na primeira vez que a ouvi. Mas quanto mais eu refletia sobre ela, menos parecia significar — se significar apenas apresentar resultados por meio de linguagem e interfaces com as quais os usuários já estão familiarizados, o retorno é fraco.
Olhando para trás, para os projetos de IA dos quais participei, cheguei a uma conclusão diferente: um modelo pode responder a uma pergunta corretamente e ainda não ter ideia de qual tarefa a pessoa está realmente tentando concluir — se o passo correto agora é continuar respondendo, fazer uma pergunta de acompanhamento, parar ou transferir para um humano. Para que a IA assuma um trabalho real, e não apenas responda a perguntas, as empresas precisam traduzir o que os profissionais experientes sabem sobre contexto, risco, tempo e consequência em algo que um sistema possa realmente reconhecer: sinais, estados de tarefas, protocolos de resposta e critérios de validação.
Este artigo começa a partir de um cenário que conheço bem — o teste de modelos — e percorre como essa tradução acontece, e por que ela forma dois limites decisivos entre a IA e a implantação real. As empresas de IA que entendem e superam esses limites estão melhor posicionadas para construir capacidades duradouras dentro de um domínio vertical, transformando o que aprendem em uma única implantação em capacidades de entrega repetíveis, verificáveis e escaláveis.
Além do teste de modelo: a IA ainda precisa entender a tarefa
Na maioria dos projetos de IA, as equipes técnicas criam uma bateria de prompts de teste e executam o modelo contra eles repetidamente. Ele identificou a intenção corretamente? Ele recuperou e aplicou o conhecimento correto? A resposta foi estável e livre de alucinações, violações de políticas ou erros lógicos? Essa é a maior parte dos testes e da depuração.
Eu vi isso acontecer nos projetos da minha própria empresa muitas vezes. Em um campo como a venda de seguros, no entanto, a equipe de testes geralmente também inclui especialistas no domínio experientes sentados ao lado dos engenheiros. Eles leem as mesmas conversas e sinalizam os mesmos tipos de problemas — mas estão olhando por uma lente inteiramente diferente.
A equipe técnica pergunta primeiro se o modelo acertou a resposta. O especialista no domínio pergunta outra coisa: essa resposta se adapta ao momento atual da conversa? Para onde ela leva o cliente? E o que deve acontecer a seguir — continuar respondendo, investigar mais a fundo, recuar ou trazer um humano?
Essa lacuna entre as duas lentes é exatamente o que a maioria dos projetos de IA enfrenta no momento em que passam do teste de modelo para um ambiente de negócios real.
O primeiro limite: reconhecer quando a tarefa mudou
Digamos que uma apólice de doenças graves inclua um período de carência de 90 dias — uma cláusula sob a qual a cobertura para doenças especificadas começa apenas após um período determinado, sujeito aos termos da apólice. Um cliente, no meio de uma conversa com um assistente de vendas, pergunta: “Qual é o período de carência desta apólice de doenças graves?”
A IA verifica a apólice e responde: “O período de carência é de 90 dias. Uma doença coberta diagnosticada pela primeira vez após esse ponto é elegível para um sinistro sob os termos da apólice.”
Julgando puramente com base no conhecimento do produto e na redação, não há nada de errado aqui. O modelo entendeu a pergunta, citou a cláusula correta e não fez nenhuma promessa além do que a apólice cobre. Pelos padrões comuns de garantia de qualidade (QA), isso conta como uma resposta limpa e bem-sucedida.
Mas um corretor de seguros experiente pode notar algo que uma análise convencional de QA perderia: por que esse cliente está perguntando sobre o período de carência exatamente agora?
Talvez ele esteja simplesmente comparando produtos. Ou talvez tenha acabado de fazer um exame, notado um sintoma ou esteja silenciosamente preocupado com um problema de saúde que ainda não foi diagnosticado. A mesma pergunta, feita em um contexto diferente, pode levar o restante da conversa em uma direção inteiramente diferente.
O que esse limite realmente testa é se a IA pode registrar que a própria tarefa mudou. O sistema precisa primeiro perceber o que está acontecendo: esta ainda é uma consulta rotineira de produto ou a tarefa já mudou para esclarecer riscos de saúde, obrigações de declaração e expectativas de cobertura?
Se o cliente estiver simplesmente comparando produtos, declarar o período de carência é suficiente. Mas se ele já mencionou algo como um resultado de exame anormal ou uma preocupação de saúde, essa mesma consulta de produto provavelmente mudou para um território diferente.
Se a IA, ainda otimizando para conversão, incentivar o cliente a comprar agora para que o período de carência comece a contar mais cedo — cada linha individual nessa troca ainda pode parecer defensável por si só, e os números de conversão de curto prazo podem até parecer bons. Mas, medido em relação ao trabalho real — uma venda sólida e em conformidade —, a direção já tomou o caminho errado. Esse desvio é difícil de capturar precisamente porque cada saída individual se sustenta bem sob sua própria análise; o problema só aparece quando você olha para onde as peças estão se direcionando juntas.
Do ponto de vista da interação humano-IA, o cliente começou com uma pergunta sobre o produto, mas a tarefa que realmente precisava ser tratada pode ter se transformado silenciosamente em outra coisa no meio da conversa. O modelo respondeu corretamente. Ele apenas nunca percebeu que a natureza do trabalho havia mudado.
O segundo limite: entender para que a tarefa realmente serve
Reconhecer que uma tarefa mudou responde apenas a “o que está acontecendo agora”. A IA ainda precisa entender o que a tarefa deve realizar e o que o próximo passo pode desencadear.
Esse tipo de falha é difícil de capturar apenas por verificações de precisão. Às vezes, o problema é a falta de uma investigação suficiente antes da resposta. Às vezes, é uma ação inadequada tomada após responder.
Um cliente que pergunta a um representante de atendimento sobre a política de reembolso pode já ter passado por várias tentativas fracassadas e realmente precisar de um encaminhamento, e não de uma repetição das regras. Um gerente de vendas que pede à IA para explicar uma queda nas receitas pode estar caminhando para uma decisão sobre quais segmentos de clientes cortar, qual processo da linha de frente alterar ou como realocar recursos. Um cliente que pergunta sobre uma cláusula de apólice específica pode simplesmente ter uma preferência — ou pode estar ponderando silenciosamente um risco que não disse em voz alta.
A linguagem e o conhecimento permitem que a IA produza uma resposta melhor. Mas assumir o trabalho real exige entender a tarefa em questão: seu estado atual, seu objetivo pretendido e as consequências da próxima ação.
Este limite testa se a IA entende o contexto e o objetivo por trás da tarefa — não apenas que a tarefa mudou, mas para onde ela se moveu, quais informações ainda estão faltando e o que deve acontecer a seguir.
Apenas com isso definido é que “a IA se colocar no lugar do cliente” significa algo concreto. Um tom natural, uma interface limpa, um painel flexível — tudo isso melhora como as informações são vistas e usadas. Entender a própria tarefa é uma questão totalmente diferente: alcança o tempo certo, os limites, a ação e quem é responsável pelo quê.
Como o julgamento profissional se torna uma capacidade do sistema
A lacuna entre os engenheiros e os especialistas no domínio não é realmente sobre quem conhece a tecnologia e quem conhece o negócio. A verdadeira diferença está na unidade básica que cada lado usa para julgar se uma saída é boa. Por “unidade”, quero dizer: quando você está decidindo se uma saída é aceitável, qual é a primeira coisa que você olha? A equipe técnica verifica o modelo em relação a um conjunto de dimensões de avaliação — reconhecimento de intenção, precisão de recuperação, qualidade da resposta, restrições de segurança, estabilidade de saída. O especialista no domínio coloca essa mesma resposta de volta em seu contexto completo: quando ela apareceu, onde o cliente está no processo e ao que ela pode levar?
Portanto, o primeiro passo do engenheiro é verificar a própria resposta. O especialista no domínio se importa mais com o lugar onde essa resposta se encaixa em todo o trabalho: ela se adapta ao momento, pode ser mal interpretada e como afeta a confiança, a conformidade e o resultado final do negócio? Essa diferença na unidade de julgamento tem consequências reais para o quão bem o humano e a IA trabalham juntos. Um modelo pode parecer ótimo em um relatório de teste e ainda assim continuar produzindo a resposta errada quando estiver em execução — e o problema muitas vezes não é o conteúdo da resposta. É que o sistema nunca percebeu que a tarefa já havia mudado.
Um bom especialista no domínio pode, com frequência, sinalizar um problema instantaneamente: “Isso não é algo que se diga aqui.” Para uma equipe de IA, essa frase é apenas um ponto de partida. Ela levanta questões que ainda precisam de respostas: qual sinal o especialista percebeu? Qual resultado o deixava preocupado? Quais situações são adequadas para continuar e quais precisam de uma pergunta de acompanhamento ou de uma transferência? E a quem pertence esse conhecimento — ao prompt do sistema, ao contexto, a uma regra, a um fluxo de trabalho ou a um limite rígido de permissão no próprio sistema?
Não importa o quão afiado seja o julgamento profissional de alguém, se ele permanecer trancado dentro de sua própria intuição, nunca poderá se tornar uma capacidade do sistema que escala. Portanto, a verdadeira questão — aquela que determina se uma equipe supera ambos os limites — é como transformar o instinto do especialista em estruturas que o sistema possa reconhecer, executar e validar.
Trazer a expertise do domínio para um sistema de IA tende a seguir um caminho bastante consistente:
Começa com a identificação de casos reais em que o modelo respondeu corretamente, mas a tarefa ainda saiu do rumo. A partir daí, a equipe desdobra exatamente qual sinal o especialista captou e usa isso para definir o estado da tarefa apontado por esse sinal. Só então a equipe formula uma hipótese concreta sobre qual intervenção pode ajudar — e só depois disso qualquer parte disso é escrita no sistema, testada contra resultados reais e refinada de acordo com os resultados.
Esse processo tem que começar a partir de um caso concreto. Pergunte a um especialista em abstrato o que observar durante uma venda e você obterá principalmente princípios. Coloque uma conversa real — ou simulada — na frente dele e pergunte onde o problema começou, e os instintos que ele acumulou ao longo dos anos, aqueles que nunca colocou em palavras, finalmente têm algo a que se apegar.
Tome o caso do período de carência. Um cliente mencionando um exame recente, um sintoma físico, perguntando “é muito tarde para comprar agora” ou tratando o período de carência como algum tipo de garantia de um pagamento futuro — todos esses são sinais que valem a pena sinalizar. Mas um sinal é apenas uma observação. Muitas pessoas que perguntam sobre um período de carência não têm nenhum problema de saúde, e o modelo não deve tirar conclusões precipitadas de uma única palavra. A equipe ainda precisa descobrir em quais condições um determinado sinal indica que a tarefa mudou.
Uma vez definida essa mudança — uma consulta rotineira de produto mudando para uma conversa sobre risco de saúde e declaração de informações —, o sistema pode mudar como responde: em vez de seguir em frente, ele esclarece o risco e transfere para um humano, se necessário.
Por meio desse processo, o instinto de um especialista gradualmente se transforma em sinais e estados de tarefa que o sistema pode reconhecer. Uma vez definido o estado da tarefa, a equipe ainda precisa responder a algo mais fundamental:
Para um cliente que mostra uma possível preocupação de saúde, uma pergunta adicional de esclarecimento — em vez de responder diretamente e empurrar a venda para a frente — melhora a integridade da declaração de saúde e reduz disputas futuras?
Essa pergunta ainda vive no nível de uma hipótese de negócio e do design de uma intervenção — ainda não se tornou um prompt ou uma regra de sistema. Ela define a quem se aplica, qual ação testar, com o que compará-la e qual resultado visa melhorar. Nesse ponto, a equipe passou de “o que a IA deve dizer” para “mudar o que a IA faz realmente altera o resultado do negócio?”
A partir daí, a equipe técnica precisa projetar a própria hipótese. Primeiro: quais sinais devem disparar o caminho de esclarecimento de risco. Depois: o que o sistema deve fazer uma vez disparado. Por exemplo — quando um cliente pergunta sobre o período de carência e também menciona um exame recente, um sintoma ou a temporalidade da compra, a IA deve primeiro entender por que ele está perguntando, sinalizar a importância de uma declaração honesta e da análise de subscrição, evitar implicar que um sinistro é garantido e encaminhar para um humano quando necessário.
Parte disso pertence ao prompt do sistema. Outras partes exigem contexto, anotação, regras, gerenciamento de estado e suporte ao fluxo de trabalho para funcionarem juntas. Onde linhas de conformidade, autoridade de compromisso ou decisões de alto risco estão envolvidas, barreiras de proteção mais rígidas no nível do sistema também costumam ser necessárias.
Trazer o julgamento especializado para um sistema, em outras palavras, não pode ser feito com um único bloco de texto de prompt. A equipe precisa determinar, peça por peça, a qual camada pertence cada parte do conhecimento, experiência e restrição — é isso que limita com segurança o comportamento do modelo e melhora a consistência tanto das saídas quanto das ações.
Uma vez que o design do sistema muda, o padrão de teste deve mudar com ele. Em uma comparação de produtos de rotina, a IA pode simplesmente declarar o período de carência. Quando um cliente menciona um resultado de exame anormal e pergunta se é tarde demais para comprar, o sistema precisa reconhecer um estado de tarefa diferente e ajustar seu tratamento de acordo. Se o cliente então pedir à IA para ajudar a ocultar um problema de saúde, ela deve parar, explicar a exigência de declaração e direcionar a conversa para um humano qualificado.
E, no final, tudo volta aos resultados reais. A pergunta adicional melhorou a integridade da declaração e reduziu as disputas? Criou atrito, interrompendo uma grande parcela de consultas de rotina que nunca precisaram disso? A transferência humana realmente melhorou a compreensão do cliente e a qualidade da subscrição?
Essas perguntas só são respondidas com base em dados reais ao longo do tempo. É somente quando o julgamento especializado entra nesse ciclo — testar, implantar, medir, refinar — que ele tem a chance de se estabilizar em algo sólido e repetível.
Conclusão: a colaboração entre humanos e IA começa com uma compreensão compartilhada da tarefa
O que um determinado projeto precisa entregar molda como a colaboração entre humanos e IA acaba parecendo. Se um parceiro se importa principalmente com o resultado final de vendas, a interface do usuário (UI/UX) pode não ser o foco principal da entrega. Mas onde a aquisição de clientes, a análise operacional ou a tomada de decisão direta pela própria equipe do cliente estão envolvidas, um painel capaz de alternar flexivelmente entre segmentos, ajustar fluxos de trabalho e destacar resultados costuma importar bastante.
Este artigo começou a partir de uma versão da mesma pergunta: a IA deve apresentar sua saída na linguagem e nos formatos que o cliente já conhece bem? Essa pergunta merece um peso real — informações que ninguém pode usar, por mais precisas que sejam, nunca entram no trabalho real. Mas avance um pouco mais e uma imagem diferente surge. A interface e a apresentação moldam como as pessoas entendem e usam o que a IA produz. O problema mais profundo na colaboração entre humanos e IA é se a IA entende de qual tarefa ela realmente faz parte.
A mesma pergunta pode ser de rotina ou pode marcar uma virada na tarefa. A mesma resposta, entregue em um momento diferente ou em um contexto diferente, pode levar a consequências totalmente diferentes. A IA precisa reconhecer quando o estado da tarefa mudou, entender o objetivo que está servindo atualmente e saber como agir sobre o que vem a seguir.
Esse tipo de compreensão — de um domínio vertical e seus contextos operacionais específicos — não surge do modelo por si só. Vem de equipes técnicas e especialistas no domínio desconstruindo repetidamente casos reais juntos, transformando os sinais, contexto, respostas e riscos espalhados pela experiência profissional em algo que um sistema possa reconhecer, agir e verificar.
Neste momento, a maioria dos projetos de IA pede a especialistas do domínio para verificar se as respostas estão corretas — se uma linha específica deveria ter sido dita ou se um número está preciso. Isso subestima o valor que eles trazem. O que eles realmente contribuem é a compreensão da tarefa e o julgamento profissional: como uma tarefa muda, quando a intervenção é necessária, qual forma essa intervenção deve tomar e quais resultados não podem ser avaliados apenas por métricas de curto prazo. A equipe técnica deve então decompor essa expertise e codificá-la nas camadas apropriadas do sistema — o prompt do sistema, contexto, regras, fluxos de trabalho, limites de permissão e os mecanismos mais amplos que regem a interação entre humanos e IA.
A colaboração entre humanos e IA é, portanto, uma parceria centrada na tarefa. As pessoas definem os objetivos, restrições e responsabilidades e, em última análise, são donas do resultado; a IA participa da análise, investigação, julgamento e ação. As organizações então refinam tanto a divisão do trabalho quanto o design do sistema em resposta aos resultados do mundo real.
Para uma empresa de IA, esse também é o verdadeiro obstáculo para se aprofundar em qualquer setor vertical. Modelos de uso geral e ferramentas técnicas estão se tornando amplamente disponíveis, mas a expertise de domínio construída em uma única implantação não se transforma em capacidade escalável por si só. Essa experiência se torna escalável apenas quando uma empresa de IA pode traduzir continuamente a expertise de domínio em estados de tarefas, mecanismos de sistema e um ciclo de validação funcional. Só então um único sucesso pode ser reproduzido com segurança em mais clientes e mais cenários.
Acertar a resposta apenas prova que o modelo entendeu a pergunta à sua frente. Capturar uma mudança na tarefa no momento em que ela acontece, entender o que vem a seguir e saber quando responder, perguntar, parar ou devolver a tarefa a uma pessoa — é aí que a IA começa a fazer o trabalho.
David Lien, sócio da Lingxi (Beijing) Technology e autor de “Decoding New Insurance” (2020).
