Service Robots Are Learning to Drive: Lessons from Autonomous Vehicles

A robotaxi changes lanes to avoid a double-parked truck while a passenger asks it to play 80s hip-hop and wants to know when the Giants game starts. That scene opens Jochen Wirtz’s article on generative AI robots in Harvard Business Review, which I read in HBR Türkiye’s June 2026 issue. Wirtz, a long-time researcher on service robots, argues that generative AI will finally make robots useful in hotels, hospitals, restaurants and shops: places where service has always depended on people.

I have spent years teaching cameras to understand the world around a car, so the Waymo opening caught my attention for a different reason. Autonomous driving is the one field where robots already move among the public at scale, and it has spent fifteen years learning, often the hard way, what it takes to make that safe. Service robots are about to go through the same lessons. This post summarises Wirtz’s article and then looks at it through that lens.

What generative AI changes

Wirtz bases his article on visits to 14 companies in Europe, Asia and North America over 18 months. His diagnosis of the past is honest: service robots have advanced much more slowly than enthusiasts predicted. Many pilots stalled. He cites a McKinsey survey in which 71% of companies named high upfront costs and 61% a lack of automation experience as the main barriers. Most deployed robots are little more than advanced automatons that follow fixed routes, read barcodes and answer FAQs.

What changes now, in his view, is a combination of three technologies:

  • Large language models give robots real conversation. A hospital robot used to fail at a child’s question like “Will it hurt?”; an LLM-based robot can answer it in plain language. Robin, a robot used in around 30 paediatric units and care homes in the US, visits children, answers their questions and plays voice games with them.
  • Agentic AI adds memory, planning and the ability to hand a task to a person. A robot can recognise a returning guest, weigh an early check-in against room readiness and act on high-level instructions such as “restock the IV supplies”.
  • Large behaviour models are trained on large sets of physical behaviour. A robot watches a few demonstrations of how to carry a wine glass, practises millions of variations in simulation and a digital twin, and transfers the skill to carrying medical tubes in a clinic.

On top of that come no-code training and fleet learning: a front-line employee can show a robot a better way to do a task, and the new behaviour is shared across the whole fleet within days instead of months.

His advice to leaders comes in four steps: start with use cases where labour is scarce and tasks are repeatable; design interactions that make adoption easy; position robots as service enhancers rather than replacements; and keep responsible-use guidelines up to date, from privacy and manipulation to physical safety measures such as hazard analysis, geofencing and emergency stops.

Two stories the article tells only halfway

Henn na Hotel. Wirtz mentions the robot receptionists at this Japanese hotel chain and notes that they struggle with accents, background noise and unexpected requests, and sometimes add to staff workload. The full story is more striking. In January 2019, the Wall Street Journal reported that the hotel had retired more than half of its 243 robots. The in-room assistant could not answer basic questions and sometimes woke up when guests snored; luggage robots struggled to reach rooms; check-in robots kept calling staff for help. The hotel said the robots created more problems than they solved. The one robot that clearly worked was a large arm that moved luggage into storage: the most narrowly defined task in the building.

BMW and Figure. The article presents the humanoid Figure 02 at BMW’s Spartanburg plant as a turning point: it reasons about objects, asks questions and contributed to about 30,000 cars in an 11-month deployment. That number comes from Figure. The picture has been more nuanced. In April 2025, while Figure’s CEO was describing “a fleet of robots performing end-to-end operations”, a BMW spokesperson told Fortune that a single robot was doing a single task: picking sheet-metal parts from a container and placing them on a fixture. When Figure retired the F.02 in November 2025, its own report confirmed that task and added useful detail: 1,250 hours of runtime, more than 90,000 parts loaded with a 5 mm tolerance, and a forearm that was the “top hardware failure point”. That is real progress, and an honest engineering report. But it is one well-defined task, not a general-purpose worker.

Both stories point to the same conclusion, and it is the one autonomous driving reached years ago.

Lesson 1: Define the operational design domain

In automated driving, every system has an operational design domain (ODD), a term defined in SAE J3016: the specific conditions under which it is designed to work, such as road types, speeds, weather, time of day and geography. Waymo did not launch everywhere at once. It expanded city by city, and each new area was a new ODD to validate.

Wirtz’s first step, starting with narrow, repeatable use cases, is the same idea in business language. I would make it explicit. Before a robot enters a lobby or a ward, write down its ODD: which spaces, which tasks, which people it interacts with, what noise levels and crowd densities it can handle, and what it does when it leaves that domain. Henn na Hotel’s luggage arm worked because its domain was tiny and well defined. The in-room assistant failed because its domain was “anything a guest might say at any time of night”.

Lesson 2: A good conversation is not a safety case

One technical point in the article needs correcting. Wirtz attributes Waymo’s ability to drive around double-parked trucks to large behaviour models, in the same breath as its voice assistant. In a production autonomous vehicle, these are very different systems. The driving stack combines perception, prediction and planning, and is validated with billions of simulated miles, closed-course testing and staged public deployment. The friendly in-car conversation is a separate layer. It does not decide whether the car brakes.

That separation matters for service robots too. A robot that answers “Will it hurt?” warmly may make people trust it more than its physical behaviour deserves. Fluency is not evidence of safety. The automotive industry uses formal arguments for that evidence: ISO 26262 for functional safety, ISO 21448 (SOTIF) for hazards caused by the limits of sensors and machine learning, and UL 4600, a standard for the safety case of autonomous products that is explicitly not limited to cars.

And even a mature safety process does not make a system perfect. In late 2025, Austin’s school district documented 19 cases of Waymo vehicles illegally passing stopped school buses. NHTSA opened an investigation, and Waymo issued a software recall covering 3,067 vehicles. Its chief safety officer said that “holding the highest safety standards means recognizing when our behavior should be better.” Wirtz writes that “mistakes will happen”. The automotive answer is to plan for them: monitor the fleet, report incidents and have a recall process before you need one.

Lesson 3: Fleet learning is a software release

The feature Wirtz is most enthusiastic about is the one that worries me most. If a front-line employee can teach a robot a new behaviour without code, and that behaviour spreads to the whole fleet, then every employee is shipping software to production. Wirtz sees part of the risk: he notes that a mistaken or malicious change could spread quickly across a fleet, and mentions robots that picked up inappropriate language or were sabotaged by visitors.

In cars, over-the-air updates are regulated. UNECE Regulation No. 156 requires a software update management system, and Regulation No. 155 a cybersecurity management system, before vehicles can be type-approved in the markets that apply them. Service robots will need the equivalent: staged rollouts, validation before release, the ability to roll back, and a clear record of who taught the fleet what. Otherwise fleet learning becomes a supply chain attack path, much like the compromised build script in the Codecov breach I described in my post on cloud and API security. And a robot that takes instructions in natural language inherits every prompt-injection risk I discussed in Agentic AI: Faster Startups, Fragile Systems, except that this agent has arms and wheels.

Lesson 4: Regulation is arriving

The article does not mention a single standard or regulation, but the framework is taking shape, at least in Europe:

  • EU Machinery Regulation (EU) 2023/1230 applies from 20 January 2027 and replaces the Machinery Directive. It addresses machines whose behaviour evolves through machine learning, requires protection of control systems against tampering, and makes third-party conformity assessment mandatory for certain high-risk machinery, including safety components with self-evolving behaviour.
  • ISO 13482 sets safety requirements for personal care robots: mobile servant robots, physical assistant robots and person carriers. The current edition dates from 2014 and is being revised, which says something about how fast the technology has moved.
  • The EU AI Act treats AI systems used as safety components of products covered by EU product legislation, such as machinery, as high-risk.

For a hotel or hospital buying robots, this means the questions to ask a vendor are no longer only about features and price. Which standards does the robot meet? How are its learned behaviours validated? Who is responsible when an update changes how it moves?

Lesson 5: Design the handover to a human

This is where Wirtz is strongest, and where autonomous driving agrees with him. Robotaxi operators do not pretend their vehicles never need help: they use remote assistance teams that can guide a vehicle through situations it does not understand. Wirtz recommends the same thing for service settings: tell customers clearly what the robot does and how to reach a person, keep humans for emotionally demanding or ambiguous situations, and give front-line staff a central role as “citizen developers” who improve the robot.

His advice to communicate with numbers rather than promises is also good engineering practice: “waiting time dropped from six minutes to 90 seconds” or “our nurses walk 3,000 fewer steps per shift” are claims you can verify. That is also the standard to apply to vendors’ claims, including the ones in the article.

What I take away

Wirtz is right that generative AI makes service robots far more capable and far easier to adapt than the scripted machines of the last decade. He is also right that safe and responsible design has to come first. What the autonomous driving industry adds is a set of concrete tools for doing that:

  • Write down the operational design domain before deployment, and expand it step by step.
  • Separate conversation from control. The language layer should never be the thing that decides whether the robot moves.
  • Build a safety case, not just a demo, and plan for incidents and recalls.
  • Treat every learned behaviour as a software release: validated, staged, reversible and logged.
  • Design the human handover as carefully as the robot itself.

Self-driving cars took much longer to arrive than their early promoters said, but where they have arrived, they arrived because of this discipline. Service robots can take the shortcut and learn from it, instead of repeating it.

Sources

Leave a Reply

Your email address will not be published. Required fields are marked *