IA em apps de mobilidade resolve três problemas: casar oferta e demanda, ajustar o preço em tempo real e barrar fraude. Os três partem do mesmo dado que o app já coleta: posição, tempo e comportamento do usuário. O ganho vem de começar por um caso, com regra simples, e trocar por modelo quando o volume justificar.
Por que mobilidade é um terreno fértil para IA
Um app de mobilidade gera dado a cada segundo: posição, horário, tempo de espera, cancelamento, pagamento, avaliação. É dado abundante, estruturado e ligado a decisões que se repetem milhares de vezes por dia. Isso é o oposto de muitos projetos de IA corporativa, em que o dado é escasso e a decisão é rara.
Ao mesmo tempo, a decisão precisa ser rápida e barata. O usuário não espera. Um modelo que demora para responder é pior do que uma regra simples que responde na hora.
Matching: quem atende qual pedido?
Matching é a decisão de qual recurso atende qual pedido. Em transporte por aplicativo, é qual motorista pega qual passageiro. Em entregas, qual entregador leva qual pedido. Em bicicletas compartilhadas, qual bicicleta o usuário vê como disponível e a que distância.
O sinal básico é posição e status em tempo real. Sem isso, não existe matching, com ou sem IA. A primeira versão costuma ser uma heurística: o recurso disponível mais próximo. A segunda leva em conta o tempo estimado de chegada, o histórico de cancelamento e o que acontece com o restante da frota depois da atribuição.
A previsão de chegada é o exemplo mais estudado. No artigo sobre o DeepETA, publicado em fevereiro de 2022, a Uber descreve um modelo que não substitui o motor de rotas: ele prevê o resíduo, ou seja, a diferença entre a estimativa do mapa e o que aconteceu na rua. As entradas são origem, destino, horário do pedido, trânsito em tempo real e o tipo de pedido. O modelo tem centenas de milhões de parâmetros, mas cerca de 0,25% deles são usados em cada previsão, e a resposta precisa sair em poucos milissegundos. Esse desenho, regra física mais correção aprendida, é uma boa referência para quem está começando: o modelo melhora o que já existe em vez de partir do zero.
Um exemplo do nosso portfólio mostra a base sem a qual nada disso funciona. No app da MOB, sistema de bicicletas compartilhadas em Portugal, o usuário encontra uma bicicleta, paga e destrava pelo celular. Cada bicicleta reporta posição e status via IoT, e o operador vê a frota inteira em tempo real no painel. A posição confiável de cada ativo, em tempo real, é o pré-requisito de qualquer modelo futuro.
Precificação dinâmica: quando o preço deve mudar?
Preço dinâmico é ajustar o valor da corrida, da entrega ou do aluguel conforme a relação entre oferta e demanda em uma região e em um horário. O objetivo é atrair oferta para onde falta e reduzir o tempo de espera, não maximizar receita em cada pedido.
O sinal é demanda por célula geográfica e faixa de horário, oferta disponível na mesma célula, tempo de espera atual, clima e eventos. O modelo começa como previsão de demanda de curto prazo, com uma regra de ajuste por cima. Otimização de preço só faz sentido depois, quando há volume para testar variações com segurança.
O risco a controlar é de percepção e de regulação. Um multiplicador sem teto em dia de chuva ou de emergência vira notícia. Três controles simples: piso e teto por região, explicação visível ao usuário antes de confirmar, e teste controlado em uma cidade antes de expandir.
Detecção de fraude: onde o dinheiro vaza?
Fraude em mobilidade tem formas conhecidas: contas criadas para abusar de cupom, corridas combinadas entre motorista e passageiro para receber incentivo, GPS falsificado para simular deslocamento, chargeback depois do serviço prestado e, em bicicletas compartilhadas, uso sem pagamento ou bicicleta que não volta.
O sinal está no comportamento e no dispositivo: velocidade de criação de contas, padrão de GPS incompatível com deslocamento real, mesmo dispositivo em várias contas, sequência de eventos fora do normal, histórico de pagamento. O modelo começa com regras e detecção de anomalia. Um classificador supervisionado vem depois, quando há rótulos, como chargebacks confirmados e contas bloqueadas com revisão.
O risco a controlar é o falso positivo. Bloquear um usuário legítimo custa mais do que deixar passar uma fraude pequena, porque ele não volta. Por isso, decisões de bloqueio pedem revisão humana em uma faixa de incerteza. Escrevemos sobre esse desenho, com o modelo sinalizando e a pessoa decidindo, em agentic AI em empresas híbridas.
| Funcionalidade | Sinal ou dado | Tipo de modelo | Risco a controlar | Por onde começar |
|---|---|---|---|---|
| Matching | Posição e status em tempo real, tempo estimado de chegada, histórico de cancelamento | Heurística de distância, depois otimização com previsão de ETA | Espera longa em regiões de baixa oferta | Regra do mais próximo; PoC de 3 semanas para testar o ganho de um modelo de ETA |
| Previsão de chegada | Origem, destino, horário, trânsito, tipo de pedido | Motor de rotas mais modelo que corrige o resíduo (no DeepETA da Uber, cerca de 0,25% dos parâmetros por previsão, resposta em poucos milissegundos) | Latência acima do que o app tolera | Medir o erro do motor de rotas atual antes de treinar qualquer modelo |
| Precificação dinâmica | Demanda e oferta por célula e horário, tempo de espera, clima | Previsão de demanda de curto prazo mais regra de ajuste | Percepção de abuso e regulação | Piso e teto por região; PoC de 4 a 6 semanas com dados reais de uma cidade |
| Detecção de fraude | Dispositivo, padrão de GPS, velocidade de eventos, histórico de pagamento | Regras e anomalia, depois classificador supervisionado com rótulos de chargeback | Falso positivo bloqueando usuário legítimo | Regras sobre os três padrões mais caros, com revisão humana na faixa de dúvida |
Coaching e recomendação: o mesmo dado, outra pergunta
Nem toda IA em app de mobilidade é sobre a operação. Às vezes é sobre o usuário. O Wooshy é um app de inteligência esportiva que reúne dados do relógio, do Strava, do sono e da frequência cardíaca, cruza com a percepção que o próprio atleta registra e responde por chat com um coach de IA. Atende ciclismo, corrida, tênis e bem-estar, está publicado na App Store e no Google Play, e a listagem no Google Play informa que nenhum dado do usuário é compartilhado com terceiros.
A lição vale para qualquer app que lida com localização e corpo: o modelo de linguagem só é útil sobre dado estruturado e integrado, e a regra de privacidade precisa estar declarada antes do lançamento, não depois. Para o mercado brasileiro, o ponto de partida está em LGPD e IA generativa.
Por onde começar quando o app ainda é pequeno?
Com regra, não com modelo. Um app com poucos milhares de viagens por mês não tem dado para treinar um modelo de precificação, mas tem dado para medir tempo de espera por região e para pegar os três padrões de fraude mais caros com regras simples. Isso já resolve boa parte do problema e gera os rótulos que o modelo vai precisar depois.
A ordem que costuma funcionar:
- Garanta posição e status confiáveis em tempo real. Sem isso, nada do resto anda.
- Meça o problema antes de resolvê-lo: espera média, taxa de cancelamento, perda por fraude.
- Coloque uma regra simples e registre cada decisão que ela toma.
- Quando o volume justificar, teste um modelo contra a regra em um ciclo curto, com o mesmo indicador.
Essa é a lógica de validar antes de construir que aparece em startups não falham por falta de ideia: o que falta raramente é modelo, é encaixe entre o que o app faz e o que o usuário paga para ter.
Próximo passo
Se o seu app já coleta posição e pagamento, o próximo passo é medir onde a espera, o preço ou a fraude custam mais hoje. A página de apps mostra como a Cortex IQ constrói esse tipo de produto, e a página de mobilidade e apps reúne os projetos já entregues no setor.