Agentes de IA já conseguem interpretar “quero um carro que aceite meu cachorro” e transformar isso em uma solicitação de corrida. O desafio é outro: fazer o usuário sair do app que já conhece, delegar acesso a endereço e pagamento a um agente externo e confiar que a reserva será concluída corretamente. Segundo o Tecnoblog.net, a DiDi — dona da 99 no Brasil — classificou como “insignificante” o número de corridas solicitadas por agentes de IA externos. Para mim, esse dado diz menos sobre a capacidade dos modelos e mais sobre integração, confiança e conveniência.
Por que agentes de IA ainda geram poucas corridas
Um agente de IA não é apenas um chatbot que recomenda um destino. Para pedir um carro, ele precisa transformar uma intenção em ações: identificar origem e destino, escolher uma categoria, consultar preço e disponibilidade, lidar com autenticação e, por fim, confirmar a corrida. Cada etapa depende de dados atuais e de uma integração confiável com a plataforma.
Na reportagem, o vice-presidente sênior da DiDi, Stephen Zhu, questionou qual valor adicional o agente oferece diante de um aplicativo que os clientes já sabem usar. É uma pergunta de produto importante. Se abrir o app da 99 e tocar em “confirmar” resolve o problema com menos dúvidas, adicionar um intermediário pode ser só uma camada extra de falha.
A Uber também informou, em seus resultados do terceiro trimestre, que recebeu apenas quatro solicitações de viagens feitas dessa forma. Esse número chama atenção, mas não deve ser comparado diretamente com o volume total de corridas: a reportagem não fornece o mesmo período, a mesma definição de solicitação nem um denominador específico para essas tentativas. A DiDi informou 55 milhões de transações por dia no segundo trimestre de 2026, somando todos os serviços da plataforma — não apenas corridas.
Agente externo não é a mesma coisa que IA dentro do aplicativo
A distinção mais importante da notícia é entre um agente externo, como um assistente conectado ao ChatGPT ou ao Claude, e uma IA integrada ao próprio app da DiDi. A empresa tem a Xiao Di, assistente que aceita texto ou voz e pode escolher entre cerca de 90 opções de serviço. O usuário pode, por exemplo, pedir um carro adequado para transportar um cachorro.
Isso é uma experiência com IA, mas não significa necessariamente que um agente externo controlou a plataforma. Quando a empresa domina o aplicativo, os dados de serviço, as regras de negócio e o fluxo de pagamento, consegue oferecer uma interface conversacional sem abrir essas operações para terceiros. A Xiao Di também pode consultar opções que um agente de fora talvez nem consiga descobrir.
Essa diferença importa para quem desenvolve. Um modelo pode entender perfeitamente “preciso de um carro maior para levar meu cachorro”, mas não consegue inventar uma categoria de veículo, disponibilidade ou regra de transporte. A resposta depende de ferramentas conectadas a dados reais e de uma API que exponha essas opções de forma segura.
O que uma integração de corridas com IA precisa resolver
Intenção, dados e confirmação
O agente precisa separar o que o usuário realmente informou do que está presumindo. “Me busca em casa” só funciona se o sistema tiver um endereço residencial confiável e autorização para usá-lo. “Leva meu cachorro” pode exigir uma categoria específica, que varia por cidade e disponibilidade.
Antes de reservar, a interface deve mostrar os dados que afetam a decisão: origem, destino, tipo de veículo, preço estimado e condições relevantes. Uma confirmação explícita evita que uma interpretação errada do modelo vire uma cobrança ou uma corrida para o lugar errado. Para ações com custo financeiro, tratar a confirmação como detalhe opcional é um erro de produto e de segurança.
Autenticação, pagamento e permissões
Um agente não deveria receber a senha do usuário nem reutilizar um token amplo que dê acesso a toda a conta. Em uma integração real, o fluxo precisa limitar permissões, permitir revogação e proteger informações sensíveis. OAuth com escopos específicos é uma alternativa mais adequada do que compartilhar credenciais ou automatizar o login no aplicativo.
Também há uma diferença entre autorizar uma consulta e autorizar uma compra. Consultar uma estimativa de preço pode ser uma permissão; solicitar a corrida é outra. A arquitetura deve deixar essa fronteira clara, inclusive quando o usuário conversa por voz ou quando o agente tenta completar várias etapas em sequência.
APIs oficiais, links profundos e automação de tela
Há três caminhos comuns para conectar um assistente a um serviço. Uma API oficial oferece mais controle sobre autenticação, validação e resposta, mas exige que a empresa construa e mantenha a integração. Um link profundo pode abrir o app com parte da solicitação preenchida e deixar a confirmação com o usuário; costuma ser mais simples, mas não permite ao agente completar todo o fluxo.
Automatizar a interface visual é a opção mais frágil. Mudanças no layout, janelas de permissão ou testes A/B podem quebrar o fluxo. Além disso, simular cliques pode contrariar regras do serviço e não resolve, por si só, autenticação segura, prevenção de duplicidade ou confirmação de pagamento. Protocolos de ferramentas, como MCP, podem padronizar a comunicação entre clientes e ferramentas, mas não substituem uma API oficial nem resolvem as regras de negócio.
Na Prática: desenhando uma reserva segura
Quando penso em um fluxo de reserva conectado a um agente, separo a operação em consulta e execução. Primeiro, o sistema cria uma estimativa associada a um identificador. Depois que o usuário revisa os detalhes, uma segunda chamada confirma a reserva. O exemplo abaixo é executável em Python e simula essa separação em memória; não se conecta à 99 ou à DiDi.
from dataclasses import dataclass
from secrets import token_urlsafe
@dataclass
class Quote:
quote_id: str
origin: str
destination: str
vehicle: str
estimated_price: float
quotes = {}
bookings = {}
def quote_ride(origin: str, destination: str, vehicle: str = "standard") -> dict:
origin = origin.strip()
destination = destination.strip()
if not origin or not destination:
raise ValueError("Origem e destino são obrigatórios.")
if vehicle not in {"standard", "pet", "xl"}:
raise ValueError("Categoria de veículo inválida.")
quote = Quote(
quote_id=token_urlsafe(8),
origin=origin,
destination=destination,
vehicle=vehicle,
estimated_price=18.50,
)
quotes[quote.quote_id] = quote
return {
"quote_id": quote.quote_id,
"origin": quote.origin,
"destination": quote.destination,
"vehicle": quote.vehicle,
"estimated_price": quote.estimated_price,
"requires_confirmation": True,
}
def book_ride(quote_id: str, confirmed: bool, idempotency_key: str) -> dict:
if not confirmed:
raise PermissionError("A reserva exige confirmação explícita.")
if not idempotency_key:
raise ValueError("A chave de idempotência é obrigatória.")
if idempotency_key in bookings:
return bookings[idempotency_key]
quote = quotes.get(quote_id)
if quote is None:
raise ValueError("Estimativa inexistente ou expirada.")
booking = {
"booking_id": token_urlsafe(8),
"quote_id": quote.quote_id,
"status": "requested",
}
bookings[idempotency_key] = booking
return booking
estimate = quote_ride("Av. Paulista, 100", "Aeroporto de Congonhas", "xl")
print(estimate)
# A aplicação deve mostrar os detalhes e pedir confirmação ao usuário.
O exemplo usa um preço fixo e armazenamento em memória para deixar a lógica visível. Em produção, eu substituiria isso por uma API que consulte preço e disponibilidade em tempo real, persistência durável, expiração de estimativas e uma chave de idempotência armazenada no servidor. A chave evita que uma repetição causada por timeout ou tentativa automática crie duas reservas.
Também não deixaria o modelo decidir sozinho que uma resposta ambígua equivale a consentimento. O agente pode preparar a solicitação; a aplicação deve validar os campos, mostrar o resumo e exigir uma confirmação inequívoca antes de chamar a operação que gera custo.
Erros comuns ao desenvolver agentes que executam ações
- Confundir conversa com integração: um modelo que descreve como pedir um carro não fez uma reserva. A ação só existe quando uma ferramenta autorizada executa a operação e retorna um resultado verificável.
- Deixar o agente preencher dados críticos por suposição: endereço, categoria e pagamento precisam vir de dados autorizados ou de uma pergunta ao usuário, não de uma inferência silenciosa.
- Repetir chamadas sem idempotência: redes instáveis e timeouts são normais. Sem proteção contra repetição, uma nova tentativa pode duplicar a solicitação.
- Expor ferramentas com permissões amplas: se a integração permite alterar conta, pagamento e corridas sem separação de escopos, um erro ou abuso tem impacto maior do que o necessário.
- Ignorar respostas parciais e falhas: “solicitação enviada” não é o mesmo que “motorista confirmado”. O sistema deve representar estados distintos e informar claramente o que aconteceu.
- Medir apenas chamadas ao agente: vale acompanhar quantos usuários iniciam o fluxo, quantas estimativas são concluídas, quantas reservas falham e quantas pessoas abandonam para abrir o app. Isso ajuda a descobrir se a IA reduz atrito ou só adiciona etapas.
O que esse número significa para quem desenvolve
Eu não interpretaria o volume “insignificante” como prova de que agentes de IA não têm utilidade. A própria fala de Zhu aponta uma questão que aparece em qualquer produto: a tecnologia precisa melhorar uma tarefa concreta. Se a interface conversacional facilita uma solicitação complexa, como combinar tipo de veículo, passageiro e animal, existe um ganho potencial. Se apenas reproduz os mesmos botões do app, o usuário tem pouco motivo para mudar de hábito.
Para desenvolvedores, a oportunidade está menos em colocar um modelo na frente de qualquer API e mais em desenhar ferramentas confiáveis. Isso significa contratos claros, dados atuais, limites de permissão, confirmação antes de ações irreversíveis, respostas estruturadas e observabilidade. A qualidade da experiência depende tanto dessas decisões de engenharia quanto da capacidade do modelo de entender linguagem natural.
Também é preciso separar descoberta de execução. Um agente pode ajudar o usuário a decidir qual serviço atende melhor à necessidade, mas ainda direcioná-lo ao app oficial para concluir a compra. Esse fluxo híbrido pode ser mais útil e seguro do que tentar fazer toda a transação dentro de uma conversa desde o primeiro dia.
Perguntas frequentes sobre agentes de IA e corridas
O que é uma corrida solicitada por um agente de IA?
É uma solicitação iniciada por um assistente externo que interpreta o pedido do usuário e aciona uma ferramenta ou integração para pedir o serviço. Isso é diferente de usar uma IA que já está dentro do aplicativo da empresa.
A Xiao Di é um agente externo como ChatGPT ou Claude?
Não. Segundo a reportagem, a Xiao Di é a assistente de viagens própria da DiDi, integrada ao app da empresa. Ela pode ajudar a selecionar opções de serviço, mas isso não equivale a uma solicitação feita por um agente externo.
Por que uma integração oficial é melhor do que automatizar cliques?
Uma API oficial permite definir permissões, validar dados e tratar estados da reserva de forma estruturada. A automação de tela depende do layout, é mais vulnerável a mudanças e não resolve sozinha segurança nem duplicidade de operações.
Um agente de IA pode reservar uma corrida sem confirmação?
Tecnicamente, isso depende da integração e das permissões concedidas. Para uma ação que envolve custo, considero mais seguro mostrar origem, destino, categoria e preço estimado e exigir confirmação explícita antes de enviar a solicitação.
O baixo volume prova que agentes de IA falharam?
Não. O número isolado não informa quantas pessoas tentaram usar o recurso, em qual período ou por que desistiram. Ele mostra que, naquele momento, as solicitações externas ainda eram pequenas — não que toda aplicação de agentes tenha fracassado.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.