AI in mobility apps solves three problems: matching supply and demand, adjusting price in real time and stopping fraud. All three start from the same data the app already collects: position, time and user behavior. The gain comes from starting with one case, with a simple rule, and switching to a model when volume justifies it.
Why mobility is fertile ground for AI
A mobility app generates data every second: position, time, waiting time, cancellation, payment, rating. It is abundant, structured data tied to decisions that repeat thousands of times a day. That is the opposite of many corporate AI projects, where data is scarce and the decision is rare.
At the same time, the decision has to be fast and cheap. The user does not wait. A model that takes time to answer is worse than a simple rule that answers immediately.
Matching: who serves which request?
Matching is the decision of which resource serves which request. In ride-hailing, which driver picks up which passenger. In delivery, which courier takes which order. In bike sharing, which bike the user sees as available and at what distance.
The basic signal is position and status in real time. Without it there is no matching, with or without AI. The first version is usually a heuristic: the nearest available resource. The second takes into account estimated time of arrival, cancellation history and what happens to the rest of the fleet after the assignment.
Arrival prediction is the most studied example. In the article on DeepETA, published in February 2022, Uber describes a model that does not replace the routing engine: it predicts the residual, that is, the difference between the map's estimate and what happened on the street. The inputs are origin, destination, request time, real-time traffic and the type of request. The model has hundreds of millions of parameters, but roughly 0.25% of them are used in each prediction, and the answer has to come back within a few milliseconds. That design, physical rule plus learned correction, is a good reference for anyone starting out: the model improves what already exists instead of starting from scratch.
An example from our portfolio shows the foundation without which none of this works. In the MOB app, a bike sharing system in Portugal, the user finds a bike, pays and unlocks it from the phone. Each bike reports position and status via IoT, and the operator sees the whole fleet in real time on the dashboard. The reliable, real-time position of every asset is the prerequisite for any future model.
Dynamic pricing: when should the price change?
Dynamic pricing is adjusting the value of the ride, the delivery or the rental according to the relationship between supply and demand in a region and at a time of day. The goal is to attract supply to where it is missing and reduce waiting time, not to maximize revenue on every request.
The signal is demand per geographic cell and time slot, available supply in the same cell, current waiting time, weather and events. The model starts as short-term demand forecasting with an adjustment rule on top. Price optimization only makes sense later, when there is enough volume to test variations safely.
The risk to control is perception and regulation. A multiplier with no cap on a rainy day or during an emergency becomes news. Three simple controls: floor and cap per region, a visible explanation to the user before confirming, and a controlled test in one city before expanding.
Fraud detection: where does the money leak?
Fraud in mobility has known forms: accounts created to abuse coupons, rides arranged between driver and passenger to collect incentives, spoofed GPS to simulate movement, chargebacks after the service was provided and, in bike sharing, use without payment or bikes that never come back.
The signal is in behavior and device: speed of account creation, GPS patterns incompatible with real movement, the same device across several accounts, sequences of events out of the ordinary, payment history. The model starts with rules and anomaly detection. A supervised classifier comes later, when there are labels, such as confirmed chargebacks and accounts blocked after review.
The risk to control is the false positive. Blocking a legitimate user costs more than letting a small fraud through, because that user does not come back. That is why blocking decisions call for human review in a band of uncertainty. We wrote about that design, with the model flagging and the person deciding, in agentic AI in hybrid companies.
| Feature | Signal or data | Model type | Risk to control | Where to start |
|---|---|---|---|---|
| Matching | Real-time position and status, estimated time of arrival, cancellation history | Distance heuristic, then optimization with ETA prediction | Long waits in low-supply regions | Nearest-available rule; a 3-week PoC to test the gain of an ETA model |
| Arrival prediction | Origin, destination, time, traffic, request type | Routing engine plus a model that corrects the residual (in Uber's DeepETA, roughly 0.25% of parameters per prediction, answer within a few milliseconds) | Latency above what the app tolerates | Measure the current routing engine's error before training any model |
| Dynamic pricing | Demand and supply per cell and time slot, waiting time, weather | Short-term demand forecast plus adjustment rule | Perception of abuse and regulation | Floor and cap per region; a 4 to 6-week PoC with real data from one city |
| Fraud detection | Device, GPS pattern, event velocity, payment history | Rules and anomaly detection, then supervised classifier with chargeback labels | False positive blocking a legitimate user | Rules on the three most expensive patterns, with human review in the doubtful band |
Coaching and recommendation: the same data, a different question
Not all AI in a mobility app is about the operation. Sometimes it is about the user. Wooshy is a sports intelligence app that gathers data from the watch, Strava, sleep and heart rate, crosses it with the perception the athlete records, and answers by chat with an AI coach. It serves cycling, running, tennis and wellness, is published on the App Store and Google Play, and the Google Play listing states that no user data is shared with third parties.
The lesson applies to any app that handles location and the body: the language model is only useful on top of structured, integrated data, and the privacy rule has to be declared before launch, not after. For the Brazilian market, the starting point is in LGPD and generative AI.
Where to start when the app is still small?
With a rule, not a model. An app with a few thousand trips a month does not have the data to train a pricing model, but it has the data to measure waiting time per region and to catch the three most expensive fraud patterns with simple rules. That already solves a good part of the problem and generates the labels the model will need later.
The order that usually works:
- Make sure position and status are reliable in real time. Without that, nothing else moves.
- Measure the problem before solving it: average wait, cancellation rate, loss to fraud.
- Put a simple rule in place and log every decision it makes.
- When volume justifies it, test a model against the rule in a short cycle, with the same indicator.
That is the validate-before-building logic in startups don't fail for lack of ideas: what is missing is rarely a model, it is the fit between what the app does and what the user pays to have.
Next step
If your app already collects position and payment, the next step is to measure where waiting, price or fraud cost the most today. The apps page shows how Cortex IQ builds this kind of product, and the mobility and apps page gathers the projects already delivered in the sector.