La IA en apps de movilidad resuelve tres problemas: casar oferta y demanda, ajustar el precio en tiempo real y frenar el fraude. Los tres parten del dato que la app ya recoge: posición, tiempo y comportamiento del usuario. La ganancia viene de empezar por un caso, con regla simple, y cambiar a modelo cuando el volumen lo justifique.
Por qué la movilidad es terreno fértil para la IA
Una app de movilidad genera datos cada segundo: posición, hora, tiempo de espera, cancelación, pago, valoración. Es un dato abundante, estructurado y ligado a decisiones que se repiten miles de veces al día. Es lo contrario de muchos proyectos de IA corporativa, donde el dato es escaso y la decisión es rara.
Al mismo tiempo, la decisión tiene que ser rápida y barata. El usuario no espera. Un modelo que tarda en responder es peor que una regla simple que responde al instante.
Matching: ¿quién atiende qué pedido?
El matching es la decisión de qué recurso atiende qué pedido. En transporte por aplicación, qué conductor recoge a qué pasajero. En reparto, qué repartidor lleva qué pedido. En bicicletas compartidas, qué bicicleta ve el usuario como disponible y a qué distancia.
La señal básica es posición y estado en tiempo real. Sin eso no existe matching, con o sin IA. La primera versión suele ser una heurística: el recurso disponible más cercano. La segunda tiene en cuenta el tiempo estimado de llegada, el historial de cancelaciones y lo que ocurre con el resto de la flota después de la asignación.
La predicción de llegada es el ejemplo más estudiado. En el artículo sobre DeepETA, publicado en febrero de 2022, Uber describe un modelo que no sustituye al motor de rutas: predice el residuo, es decir, la diferencia entre la estimación del mapa y lo que ocurrió en la calle. Las entradas son origen, destino, hora del pedido, tráfico en tiempo real y tipo de pedido. El modelo tiene cientos de millones de parámetros, pero alrededor del 0,25% de ellos se usan en cada predicción, y la respuesta tiene que salir en pocos milisegundos. Ese diseño, regla física más corrección aprendida, es una buena referencia para quien empieza: el modelo mejora lo que ya existe en lugar de partir de cero.
Un ejemplo de nuestro portafolio muestra la base sin la cual nada de esto funciona. En la app de MOB, un sistema de bicicletas compartidas en Portugal, el usuario encuentra una bicicleta, paga y la desbloquea desde el móvil. Cada bicicleta reporta posición y estado vía IoT, y el operador ve toda la flota en tiempo real en el panel. La posición fiable de cada activo, en tiempo real, es el prerrequisito de cualquier modelo futuro.
Precios dinámicos: ¿cuándo debe cambiar el precio?
El precio dinámico es ajustar el valor del viaje, del reparto o del alquiler según la relación entre oferta y demanda en una zona y en una franja horaria. El objetivo es atraer oferta hacia donde falta y reducir el tiempo de espera, no maximizar ingresos en cada pedido.
La señal es demanda por celda geográfica y franja horaria, oferta disponible en la misma celda, tiempo de espera actual, clima y eventos. El modelo empieza como predicción de demanda a corto plazo, con una regla de ajuste por encima. La optimización de precios solo tiene sentido después, cuando hay volumen para probar variaciones con seguridad.
El riesgo a controlar es de percepción y de regulación. Un multiplicador sin tope en un día de lluvia o de emergencia se convierte en noticia. Tres controles simples: suelo y tope por zona, explicación visible al usuario antes de confirmar, y prueba controlada en una ciudad antes de expandir.
Detección de fraude: ¿por dónde se escapa el dinero?
El fraude en movilidad tiene formas conocidas: cuentas creadas para abusar de cupones, viajes pactados entre conductor y pasajero para cobrar incentivos, GPS falsificado para simular desplazamiento, contracargos después del servicio prestado y, en bicicletas compartidas, uso sin pago o bicicletas que no vuelven.
La señal está en el comportamiento y en el dispositivo: velocidad de creación de cuentas, patrón de GPS incompatible con un desplazamiento real, el mismo dispositivo en varias cuentas, secuencias de eventos fuera de lo normal, historial de pago. El modelo empieza con reglas y detección de anomalías. Un clasificador supervisado llega después, cuando hay etiquetas, como contracargos confirmados y cuentas bloqueadas tras revisión.
El riesgo a controlar es el falso positivo. Bloquear a un usuario legítimo cuesta más que dejar pasar un fraude pequeño, porque ese usuario no vuelve. Por eso, las decisiones de bloqueo piden revisión humana en una franja de incertidumbre. Escribimos sobre ese diseño, con el modelo señalando y la persona decidiendo, en agentic AI en empresas híbridas.
| Funcionalidad | Señal o dato | Tipo de modelo | Riesgo a controlar | Por dónde empezar |
|---|---|---|---|---|
| Matching | Posición y estado en tiempo real, tiempo estimado de llegada, historial de cancelaciones | Heurística de distancia, después optimización con predicción de ETA | Espera larga en zonas de poca oferta | Regla del más cercano; PoC de 3 semanas para probar la ganancia de un modelo de ETA |
| Predicción de llegada | Origen, destino, hora, tráfico, tipo de pedido | Motor de rutas más un modelo que corrige el residuo (en el DeepETA de Uber, alrededor del 0,25% de los parámetros por predicción, respuesta en pocos milisegundos) | Latencia por encima de lo que la app tolera | Medir el error del motor de rutas actual antes de entrenar cualquier modelo |
| Precios dinámicos | Demanda y oferta por celda y franja horaria, tiempo de espera, clima | Predicción de demanda a corto plazo más regla de ajuste | Percepción de abuso y regulación | Suelo y tope por zona; PoC de 4 a 6 semanas con datos reales de una ciudad |
| Detección de fraude | Dispositivo, patrón de GPS, velocidad de eventos, historial de pago | Reglas y anomalías, después clasificador supervisado con etiquetas de contracargo | Falso positivo que bloquea a un usuario legítimo | Reglas sobre los tres patrones más caros, con revisión humana en la franja de duda |
Coaching y recomendación: el mismo dato, otra pregunta
No toda la IA en una app de movilidad trata de la operación. A veces trata del usuario. Wooshy es una app de inteligencia deportiva que reúne datos del reloj, de Strava, del sueño y de la frecuencia cardíaca, los cruza con la percepción que el propio atleta registra y responde por chat con un coach de IA. Atiende ciclismo, running, tenis y bienestar, está publicada en App Store y Google Play, y la ficha de Google Play informa de que ningún dato del usuario se comparte con terceros.
La lección vale para cualquier app que maneja ubicación y cuerpo: el modelo de lenguaje solo es útil sobre datos estructurados e integrados, y la regla de privacidad tiene que estar declarada antes del lanzamiento, no después. Para el mercado brasileño, el punto de partida está en LGPD e IA generativa.
¿Por dónde empezar cuando la app todavía es pequeña?
Con una regla, no con un modelo. Una app con unos pocos miles de viajes al mes no tiene datos para entrenar un modelo de precios, pero sí tiene datos para medir el tiempo de espera por zona y para atrapar los tres patrones de fraude más caros con reglas simples. Eso ya resuelve buena parte del problema y genera las etiquetas que el modelo necesitará después.
El orden que suele funcionar:
- Garantice posición y estado fiables en tiempo real. Sin eso, nada de lo demás avanza.
- Mida el problema antes de resolverlo: espera media, tasa de cancelación, pérdida por fraude.
- Ponga una regla simple y registre cada decisión que toma.
- Cuando el volumen lo justifique, pruebe un modelo contra la regla en un ciclo corto, con el mismo indicador.
Es la lógica de validar antes de construir que aparece en las startups no fracasan por falta de ideas: lo que falta rara vez es un modelo, es el encaje entre lo que la app hace y lo que el usuario paga por tener.
Siguiente paso
Si su app ya recoge posición y pago, el siguiente paso es medir dónde la espera, el precio o el fraude cuestan más hoy. La página de apps muestra cómo Cortex IQ construye este tipo de producto, y la página de movilidad y apps reúne los proyectos ya entregados en el sector.