Seu Agente de Viagens com IA Está Mentindo para Você — E Você Só Vai Descobrir Quando Estiver Ilhado

Uma mulher nos enviou um e-mail no ano passado com uma captura de tela. Ela havia usado um planejador de viagens com IA muito popular para reservar uma viagem em família para a Costa Rica. A IA tinha recomendado um lugar chamado algo como "Tabacon Springs Eco-Lodge" — descrições exuberantes, um preço abaixo de US$ 200 por noite, fotos que pareciam corresponder. Ela reservou voos para quatro pessoas. Alugou um carro. Disse aos filhos que iam ver macacos de uma casa na árvore.

O lodge não existia.

Não que "estivesse fechado" ou "em reforma". Ele literalmente não existia. A IA tinha misturado detalhes de dois ou três resorts costarriquenhos reais — o nome de um, as comodidades de outro, o preço de um albergue logo adiante — e os costurou em uma única propriedade lindamente descrita que nunca havia sido construída. O link de reserva levava a uma página de pagamento genérica que cobrava o cartão dela e não entregava nada.

Quando li aquele e-mail, não senti surpresa. Senti reconhecimento. Porque minha equipe na Veriprajna tinha passado meses encarando exatamente esse modo de falha, dissecando-o, entendendo por que ele acontece no nível arquitetural. E a resposta é ao mesmo tempo simples e profundamente incômoda para qualquer um que esteja construindo produtos de IA em viagens: os sistemas de IA mais populares do setor são otimizados para parecer certos, não para estar certos. Essa distinção é sutil em um gerador de poesia. Na logística de viagens, é a diferença entre umas férias e um desastre.

Por que a Sua IA Inventa Hotéis Que Não Existem?

Eis o que a maioria das pessoas não entende sobre os grandes modelos de linguagem — GPT-4, Claude, Gemini, todos eles. Eles não "sabem" as coisas do jeito que um banco de dados sabe. Um sistema de reservas de hotel sabe que o Quarto 412 no JW Marriott está reservado de 3 a 7 de março. Isso é um fato, armazenado em uma linha, consultável.

Um LLM não funciona assim. Ele prevê a próxima palavra em uma sequência com base em padrões estatísticos dos seus dados de treinamento. Quando você pede um "eco-lodge de luxo na Costa Rica por menos de US$ 200", ele ativa grupos de associações — "Costa Rica" traz "exuberante", "floresta tropical", "eco-lodge". Ele começa a gerar um texto que é estatisticamente provável de seguir aquelas palavras. E quando precisa nomear a propriedade? Ele mistura. Ele pega fragmentos de milhares de avaliações que já viu e os combina em algo que soa plausível.

Na escrita criativa, essa mistura se chama imaginação. Em viagens, se chama alucinação. E o modelo não tem como perceber a diferença.

O modelo está otimizando para coerência, não para correção. Ele foi projetado para produzir uma resposta que parece uma resposta válida, não uma que seja uma resposta válida verificada contra o inventário em tempo real.

O que piora isso é como esses modelos são treinados. Durante o aprendizado por reforço a partir de feedback humano (RLHF), avaliadores humanos consistentemente preferem respostas abrangentes e confiantes a respostas que dizem "não sei". Então o modelo aprende, em um nível profundo, que chutar com confiança é recompensado e admitir ignorância é penalizado. Um agente de viagens humano que chuta a disponibilidade é demitido. Uma IA que chuta a disponibilidade é elogiada pela sua "fluência" — até que o cliente aterrisse em um país estrangeiro sem ter onde dormir.

A Noite em Que Percebi Que a Fluência É o Problema

Há um momento ao qual não paro de voltar. Estávamos testando um protótipo inicial — não um produto que lançamos, mas um experimento interno para entender como os LLMs lidam com consultas de viagem. Pedi que ele encontrasse um hotel perto do Central Park por menos de US$ 250 por noite durante a Semana de Moda em Nova York.

Ele voltou com três opções. Descrições detalhadas. Preços. Comodidades. Uma delas até mencionava um bar na cobertura com vista para o parque. A linguagem era tão polida, tão específica, que meu primeiro instinto foi clicar em "reservar".

Então um dos meus engenheiros — sujeito mais quieto, muito metódico — rodou a mesma consulta na API Amadeus Hotel Search. Dois dos três hotéis existiam, mas não tinham disponibilidade durante a Semana de Moda. O nome do terceiro hotel era parecido com o de uma propriedade real, mas não correspondia a nenhum ID de hotel no sistema. O bar na cobertura? Pertencia a um hotel completamente diferente a seis quarteirões dali.

Foi naquela noite que entendi que o perigo não é a IA que falha de forma óbvia. Um chatbot que diz "não entendi sua pergunta" é frustrante, mas inofensivo. O perigo é a IA que entende sua pergunta perfeitamente e responde com informações eloquentes, persuasivas e factualmente erradas. Começamos a chamar isso de "Vale da Estranheza" da confiabilidade — a inteligência verbal do sistema é tão alta que os usuários baixam a guarda na verificação factual.

O caso do chatbot da Air Canada tornou isso concreto em termos jurídicos. Um chatbot alucinou uma política de reembolso. O tribunal decidiu que a companhia aérea era responsável — não o fornecedor da IA, não o chatbot como uma "ferramenta beta". A empresa que implantou o agente era responsável pelas afirmações do agente. Se a sua IA promete uma suíte com vista para o mar por US$ 200 e o GDS só tem um quarto padrão por US$ 400, você pode ficar responsável pela diferença. Ou pior, pela viagem arruinada.

O Que Acontece Quando Você Trata o LLM Como o Cérebro em Vez da Boca?

Depois daquela noite de testes, minha equipe teve uma longa discussão. Do tipo em que as pessoas desenham em quadros brancos e falam por cima umas das outras. A pergunta era simples: tentamos tornar o LLM mais preciso ou mudamos a arquitetura por completo?

Um lado queria prompts melhores, mais guardrails, geração aumentada por recuperação. Ajustar o modelo com dados de viagem. O outro lado — aquele em que acabei ficando — argumentava que o problema não era o conhecimento do modelo. O problema era o papel do modelo. Estávamos pedindo a um gerador de texto que fizesse o trabalho de um gerente de inventário. Isso é como pedir a um romancista que administre uma companhia aérea. Ele pode descrever a experiência de voar lindamente, mas não pode dizer se há um assento no voo das 8h para Heathrow.

Então tomamos uma decisão que mudou tudo o que construímos depois: o LLM nunca seria a fonte das informações de viagem. Ele seria o roteador da intenção.

O usuário diz "Encontre um hotel perto do Central Park". O trabalho do LLM é entender essa intenção, decompô-la em parâmetros estruturados — localização, intervalo de datas, orçamento, preferências — e entregar esses parâmetros a uma ferramenta que consulta o inventário real. A ferramenta retorna com dados reais. O segundo trabalho do LLM é apresentar esses dados em linguagem natural. Mas ele nunca gera os dados. Ele os traduz.

Paramos de construir IA que fala sobre viagens. Começamos a construir IA que faz viagens — consulta sistemas reais, interpreta códigos de status reais e só confirma o que pode verificar.

Essa é a mudança daquilo que o setor chama de "Wrapper de LLM" para um sistema de IA Agêntica. E a diferença não é incremental. É uma mudança de espécie. Escrevi sobre essa arquitetura em profundidade na versão interativa da nossa pesquisa.

O Padrão Orquestrador-Trabalhador: Por Que Um Único Agente Não Basta

No começo, tentamos rodar tudo por meio de um único agente. Um prompt lidando com voos, hotéis, aluguéis de carro, restrições alimentares, políticas de viagem corporativa. Ele desmoronou sob o próprio peso. A janela de contexto lotava. As instruções entravam em conflito. O agente reservava um hotel antes de confirmar as datas do voo e depois tinha que desfazer tudo.

Então construímos o que chamamos de padrão Orquestrador-Trabalhador. Pense nisso como um consultor de viagens sênior que nunca toca em um teclado, gerenciando uma equipe de especialistas que fazem, cada um, uma coisa extremamente bem.

O Orquestrador é um modelo de alto raciocínio — GPT-4o ou Claude 3.5 Sonnet — que conversa com o usuário, mantém o histórico da conversa e decide o que precisa acontecer. Ele não toca no GDS diretamente. Abaixo dele ficam Trabalhadores especializados: um Trabalhador de Voos que fala as APIs Amadeus Air e entende os códigos IATA, um Trabalhador de Hotéis que fala o Sabre Content Services for Lodging e sabe a diferença entre um depósito e uma garantia, um Trabalhador de Políticas que verifica as regras de viagem corporativa antes que qualquer coisa seja apresentada.

Quando um usuário diz "Reserve um voo para NYC na próxima terça e um hotel perto do Central Park", o Orquestrador decompõe isso em duas tarefas, identifica que a busca de hotel depende do horário de chegada do voo, aciona primeiro o Trabalhador de Voos e depois o Trabalhador de Hotéis com as datas certas. Se o Trabalhador de Hotéis falhar, o Orquestrador ainda apresenta as opções de voo e pergunta se o usuário quer tentar novamente com critérios de hotel diferentes. Nada trava. Nada alucina.

O insight fundamental foi separar o pensar do fazer. O Orquestrador pensa. Os Trabalhadores fazem. E nenhum deles finge ser o outro.

Por Que o "200 OK" Quase Nos Enganou

Eis uma história que ainda me faz estremecer. Estávamos no auge dos testes de integração com as APIs de reserva do Sabre. Nosso Trabalhador de Hotéis enviava uma solicitação de reserva, recebia de volta uma resposta HTTP 200 — que em desenvolvimento web significa "sucesso" — e a repassava ao Orquestrador. O Orquestrador dizia ao usuário: "Você está reservado!"

Só que não estavam. Nem sempre.

Levamos um tempo constrangedoramente longo para perceber isso. A resposta HTTP era 200 porque a mensagem tinha sido entregue com sucesso. Mas dentro do corpo da resposta, o código de status do segmento do GDS era UC — Unable to Confirm (Impossível Confirmar). O hotel havia rejeitado a solicitação, geralmente porque a disponibilidade em cache estava desatualizada. O quarto havia sido vendido nos milissegundos entre a busca e a tentativa de reserva.

A desconexão entre a camada de transporte e a camada de aplicação é uma armadilha clássica, e caímos direto nela. Um 200 OK no nível HTTP dizia "sua mensagem chegou". Um UC no nível do GDS dizia "sua reserva falhou". Nosso sistema estava lendo o envelope e ignorando a carta lá dentro.

Foi então que implementamos o que hoje considero a peça mais importante da nossa arquitetura: o Loop de Verificação. Toda resposta de reserva passa por uma etapa de verificação separada — seja uma verificação de código determinística ou um prompt especializado que age como auditor de qualidade — antes que qualquer confirmação chegue ao usuário. A regra é absoluta:

Um agente de IA nunca tem permissão para emitir uma mensagem de confirmação a menos que tenha analisado o código de status específico do segmento do GDS e o tenha validado como HK — Holding Confirmed (Retenção Confirmada). Tudo o mais é uma falha, não importa o que diga o cabeçalho HTTP.

HK significa que o inventário está garantido. UC significa que o hotel te rejeitou. NN significa que a solicitação está pendente — não prometa nada ainda. NO significa que nenhuma ação foi tomada. Esses códigos são a diferença entre um quarto reservado e um viajante ilhado, e a maioria dos sistemas de viagem com IA nem sequer os analisa.

Para o detalhamento técnico completo do nosso tratamento de códigos de status e da arquitetura de verificação, veja nosso artigo de pesquisa.

Como Um Agente de IA Lida Com "O Quarto Acabou de Ser Vendido"?

É aqui que os sistemas agênticos justificam seu valor. A discrepância "Look-to-Book" é endêmica em viagens — você pesquisa, vê a disponibilidade, clica em reservar e o quarto sumiu. Acontece o tempo todo nas altas temporadas. Uma IA baseada em wrapper não tem vocabulário para essa situação. Ela ou diz "Reservei!" (errado) ou "Falhou" (inútil). Ela não consegue dizer "Estava aí há um segundo, mas outra pessoa pegou — aqui está a sua próxima melhor opção".

Nossos agentes conseguem. Quando uma reserva retorna UC, o sistema aciona automaticamente uma nova busca de disponibilidade para o mesmo hotel. Se um quarto ou tarifa diferente estiver disponível, ele apresenta a opção: "A tarifa anterior esgotou, mas encontrei um quarto semelhante por US$ 10 a mais". Se nada estiver disponível, ele puxa o próximo melhor hotel dos resultados de busca originais e oferece isso em vez. Isso exige que o agente mantenha estado — uma memória do que já pesquisou, do que o usuário já rejeitou, de quais eram as alternativas. Wrappers não têm estado. Eles não conseguem fazer isso. Eles começam do zero toda vez, ou alucinam continuidade.

O Problema da Normalização de Que Ninguém Fala

Uma coisa que me surpreendeu — genuinamente me surpreendeu — foi o quão diferentes são as estruturas de dados entre a Amadeus e a Sabre. A Amadeus retorna os preços divididos em base, total e impostos em um JSON aninhado rígido. A Sabre às vezes inclui o imposto, às vezes não, dependendo do plano tarifário. Os nomes dos campos diferem. amount em um sistema é totalPrice em outro.

Se você alimentar as duas respostas brutas em um LLM e pedir que ele compare os hotéis, ele vai se confundir. Ele pode citar o preço antes dos impostos da Amadeus e o preço depois dos impostos da Sabre, fazendo o hotel da Amadeus parecer US$ 50 mais barato quando na verdade está US$ 20 mais caro. Vimos isso acontecer nos testes, e é o tipo de erro quase impossível de o usuário perceber.

Então construímos um Trabalhador de Normalização — uma camada de código determinística que pega os JSONs díspares de ambos os sistemas e os converte em um único esquema padronizado. O Orquestrador nunca vê dados brutos do GDS. Ele vê campos limpos e consistentes: nome, preço total incluindo impostos, classificação por estrelas, distância do ponto de interesse do usuário. O LLM apresenta esses dados normalizados. Ele não interpreta respostas brutas de API. Ele traduz fatos curados.

"É Só Usar GPT" — E Outras Coisas Que Investidores Dizem

As pessoas me perguntam constantemente por que não usamos simplesmente geração aumentada por recuperação — puxar dados de hotéis para um banco de dados vetorial e deixar o LLM pesquisar. Ou ajustar um modelo com dados de viagem. Ou só adicionar um prompt de sistema melhor.

Um investidor me disse, sem rodeios: "É só usar GPT com um bom prompt. O modelo é inteligente o suficiente". Respeito o instinto — é a solução mais simples, e soluções simples geralmente estão certas. Mas não aqui. Não quando o modo de falha é uma família dormindo em um aeroporto.

O RAG ajuda com o conhecimento estático — "Qual é a política de vistos para a Tailândia?" — mas não pode dizer se o Voo AA123 tem assentos disponíveis agora mesmo. O ajuste fino ajuda com o tom e o vocabulário do domínio, mas não conecta o modelo ao inventário ao vivo. Um prompt de sistema melhor ajuda com a formatação, mas não impede o modelo de gerar um nome de hotel que não existe em nenhum GDS.

A única coisa que evita a alucinação em viagens é fundamentar a saída da IA em dados verificados e em tempo real do sistema de registro. Esse sistema é o GDS. Todo o resto é decoração.

Criatividade sem restrição é caos. Em viagens, a restrição é a realidade — o assento de avião que existe ou não, o quarto de hotel que está disponível ou não. Não há meio-termo, e a IA precisa parar de fingir que há.

E Quanto à Parte Lenta?

Não vou fingir que os sistemas agênticos são rápidos. Uma única solicitação de usuário pode acionar quatro chamadas de ferramenta — busca, verificação de preço, verificação de política, síntese da resposta. Isso pode levar de 10 a 15 segundos. No e-commerce, isso é uma eternidade.

Lidamos com isso de três maneiras. Primeiro, transmitimos o raciocínio do agente ao usuário: "Buscando voos na Amadeus…" "Verificando a política de viagem corporativa…" Mostrar o trabalho reduz drasticamente a latência percebida. Segundo, rodamos os Trabalhadores em paralelo — o Trabalhador de Voos e o Trabalhador de Hotéis buscam simultaneamente em vez de sequencialmente, cortando o tempo total de espera pela metade, mais ou menos. Terceiro, armazenamos os resultados de disponibilidade em cache por 15 minutos no Redis. Se o usuário diz "Mostre-me aquele segundo hotel de novo", não acessamos o GDS de novo. Puxamos do cache.

É tão rápido quanto um wrapper que inventa uma resposta em dois segundos? Não. É tão rápido quanto precisa ser para um usuário que quer uma resposta de verdade? Sim.

A Parte em Que Admito o Que Ainda Não Conseguimos Fazer

Nenhum sistema de IA lida com todos os casos. Itinerários complexos com múltiplos trechos e dependências de visto, alianças aéreas obscuras, reservas de grupo que exigem tarifas negociadas — essas coisas ainda quebram tudo. Sabemos disso porque construímos a detecção para isso. Quando o agente entra em loop sem resolver, ou quando a análise de sentimento sinaliza frustração do usuário, o sistema faz um downgrade para o que chamamos de "modo Copiloto". Ele alerta um agente de viagens humano, passa o contexto estruturado completo da conversa, e o humano conclui a reserva usando as ferramentas que o agente preparou.

As pessoas me perguntam se isso é um fracasso. Acho que é o oposto. A IA mais perigosa é aquela que não sabe quando parar. Conhecer seus limites e fazer o repasse com elegância é um recurso, não um defeito. O agente que diz "Deixe-me conectá-lo a um especialista" é mais confiável do que aquele que continua chutando com confiança.

Para Onde Isso Vai Em Seguida

O que estamos construindo hoje é a fundação, não o teto. Estamos no que eu chamaria de autonomia de Nível 3 — o agente executa tarefas específicas, mas o usuário confirma antes de o dinheiro se mover. O caminho à frente inclui agentes de negociação que não apenas reservam os preços listados, mas consultam as APIs dos hotéis por descontos por volume, motores de empacotamento dinâmico que agrupam voos e hotéis em produtos personalizados com margens gerenciadas, e a gestão proativa de interrupções — agentes que monitoram o status dos voos 24 horas por dia e, quando ocorre um cancelamento, já reservam um assento na próxima melhor opção antes mesmo de o viajante saber que algo deu errado.

Nada disso é possível em um wrapper. Nada disso funciona se o sistema alucina. Cada uma dessas capacidades exige a arquitetura com estado, verificada e fundamentada em ferramentas que temos construído.

O setor de viagens está em um ponto de inflexão. A primeira onda de adoção de IA — os wrappers, os chatbots, os experimentos de "é só adicionar GPT" — criou algo sedutor e perigoso: sistemas que soam como o melhor agente de viagens que você já conheceu, mas que não conseguem de fato reservar um quarto. A próxima onda será definida por uma pergunta mais difícil e menos glamorosa: não "A IA consegue escrever um itinerário lindo?", mas "A IA consegue confirmar que cada item desse itinerário realmente existe, agora mesmo, pelo preço que cotou?"

Aquela família na Costa Rica merecia mais do que uma ficção lindamente escrita. Todo viajante merece. A era da IA que chuta acabou. O que vem a seguir é a IA que verifica — e só fala quando sabe.