Machine Learning for Smart Mobility: Notes from Lisbon

Arriving in Lisbon

Later in 2017 I flew to Lisbon to speak at a Smart Mobility Summit. If you have been, you know the particular pleasure of that city — the yellow trams grinding up impossibly steep hills, the tiled facades, the smell of grilled sardines drifting up from the Alfama. The summit itself was held in one of those bright, glass-fronted riverside venues near the Tagus, the kind of room where the afternoon sun comes in sideways and everyone drifts toward the water-cooler view. The audience was a mix I liked: transport authority people, logistics operators, a few automotive engineers, city planners, and the inevitable contingent of startup founders convinced they were about to reinvent the parking meter.

I had been asked to talk about machine learning and mobility. And mobility, it turned out, was one of the richest and most honest applications of the machine learning of that moment — because movement generates data relentlessly, and because the consequences of a bad prediction are physical and immediate. You cannot fake your way through a traffic model. Either the bus comes when you said it would, or it does not.

The argument: movement is a sensor-data problem

The through-line of my talk was this: smart mobility is not really about vehicles, it is about learning from streams of movement and sensor data. Every GPS ping, every loop detector buried in the tarmac, every fare-card tap, every accelerometer in a delivery van — each is a low-level observation of how a city actually behaves, as opposed to how the planners assumed it would. The opportunity in 2017 was that we finally had both the data volume and the modeling techniques to turn those streams into decisions.

I broke the opportunity into three modeling shapes, because they demanded different tools.

Prediction over time. Where will demand be in twenty minutes? How long will this trip take at 5:40pm on a rainy Thursday? These were sequence problems, and recurrent neural networks were doing real work on them — learning the daily and weekly rhythms of a city far better than the static timetables they replaced.

Perception. For the automotive engineers, deep convolutional networks reading camera and lidar frames were the headline. But I cautioned that perception in a demo and perception in the rain, at dusk, with a cyclist half-occluded by a parked van, are very different animals.

Sequential decision-making. Signal timing, fleet dispatch, dynamic routing — these were control problems, and reinforcement learning was the natural, if still immature, fit. An agent that learns a policy for holding a green light a few seconds longer when it sees a platoon of buses approaching.

Why it mattered to enterprises in 2017

The people who ran transport networks and logistics fleets did not need to be sold on the romance of it. They needed to know it would survive contact with their operations. So I spent the middle of the talk on the same operational realities I was preaching everywhere that year, translated into their world.

The data is filthy and never stops. GPS bounces off buildings in a dense old city like Lisbon and reports you a block away or inside the river. Sensors fail silently and keep reporting their last value forever. A model that has not been built to expect garbage will confidently make decisions on garbage. Data cleaning was not a preprocessing footnote here; it was half the system.

Streams demand online learning. A logistics network's patterns shift with the season, with a new distribution center, with a holiday, with a marathon closing half the city. A model frozen at training time drifts almost immediately. This was my strongest pitch for online and incremental learning in mobility — models that update continuously from the stream, because the stream is the whole point.

Explainability is a safety and accountability requirement, not a nicety. When a routing model reroutes an entire fleet, or a signal-control policy changes how an intersection behaves, someone in a control room has to understand why before they will let it run unsupervised. And when something goes wrong on a public road, "the model decided" is not an answer a transport authority can give to a regulator or a journalist. Interpretability was, for this audience, closer to a legal prerequisite than a feature.

It has to run as real infrastructure. A predictive model that needs a data scientist to nurse it through rush hour is not operational. The MLOps discipline — monitoring, versioning, automatic retraining, graceful fallback when a data feed dies — was what separated a pilot that made a nice conference slide from a system a city would actually depend on.

A concrete example

The example I used was a delivery and logistics fleet — a case the logistics people in the room felt in their bones.

Start with the ambition: predict, per stop, how long a delivery will actually take, and use those predictions to sequence a driver's route so they finish on time with less fuel. The raw materials were all there — years of historical stop times, GPS traces, timestamps, package attributes. A supervised model could learn that a delivery to a tower-block business district at lunchtime takes four times as long as a suburban doorstep drop, a pattern no hand-written rule set had ever captured well.

Then the operational reality, the part that made it interesting. The GPS traces were noisy — you had to infer real stop events from messy position data before you could even build labels. The patterns drifted constantly: a new depot, a seasonal surge, a street closed for construction, and last month's model was quietly wrong. So the retraining had to be continuous, an online loop rather than a once-a-year event. And crucially, the dispatchers would not accept a route they could not question — if the system reordered a driver's day, it had to show its reasoning, or the humans would simply override it back to the old way and the whole investment would evaporate. The winning system was not the one with the cleverest network. It was the one that cleaned its data honestly, kept learning from the stream, and explained itself well enough that the people in the loop trusted it.

What I asked the room to take home

I ended the Lisbon talk the way I ended most of them that year: the model is the easy part. In mobility, the hard and decisive parts are cleaning relentless, imperfect sensor data; learning continuously because the city never holds still; and explaining every decision well enough that a control room, a dispatcher, or a regulator will let the system run. Get those three right and machine learning genuinely reshapes transport and logistics. Skip them and you have a beautiful pilot that never leaves the conference hall.

The bridge to today

The techniques we had in 2017 were narrower than what we work with now, and I would not pretend otherwise. But the disciplines from that riverside room in Lisbon — models that keep learning from live data, decisions people can trust and audit, and the operational rigor to run it all as dependable infrastructure — are exactly what StudioX now operationalizes as the Enterprise AI Platform. What has changed is that those disciplines can finally be embodied as autonomous AI workers carrying out full Missions, rather than a single prediction feeding a dashboard.

Related on StudioX: Enterprise AI Platform · AI Workers · AI Missions