Autonomy’s Hard Part Isn’t the Car. It’s the Service.

Most autonomy conversations start in the same place: sensors, perception, planning, and the magic word “AI”. Then they end there, too, as if better models are the missing ingredient between a controlled pilot and a real service in a capital city.

Copenhagen is about to test that assumption in public. The point is not whether a self-driving stack can keep a lane. The point is whether Denmark is willing to run autonomy as a regulated service, with a control center onshore, with auditable decisions, and with a credible answer to a simple question: who is responsible when nobody is driving?

The Danish debate captured it bluntly in one line: we do not want a random guy with a joystick controlling 40 cars. That is not a punchline. It is the operating model question, stated in plain language.

The autonomy stack is the easy part, because it is legible

“Easy” is relative. Building safe autonomy is hard engineering. But it is legible engineering. You can benchmark it, simulate it, measure disengagements, and ship improvements. You can assign teams, tickets, and budgets. You can draw boundaries around it.

Service delivery in a dense city is different. It is messy, political, and full of edge cases that are not “AI problems” at all:

• How do you handle a passenger who refuses to exit a vehicle that has ended the trip?
• What happens when a police officer gives a hand signal that contradicts road markings?
• Who decides to pause operations during a storm, and what evidence supports that call?
• How do you prove, after the fact, what the system “saw” and why it acted?

This is why the control center matters. Not as a marketing prop, but as the place where responsibility concentrates. The plan to set up a Danish control center is not an implementation detail. It is the real product.

Remote-ops is not one person watching screens, it is a command system

Remote operations is often pictured as tele-driving, a human takes over when the car struggles. That picture is both too simplistic and too risky. In a regulated city service, remote-ops must look more like incident command than like gaming.

Here is the shift: the remote team should not “drive the car”. They should run the system. They make bounded decisions, under rules, with logging, escalation, and handoffs.

A practical way to design it is to separate three capabilities:

• Assistance: the remote team provides context and permission, for example approving a cautious maneuver or routing around a blocked street.
• Recovery: the remote team executes a safe stop, dispatches field support, or coordinates with authorities. This is where minutes matter.
• Containment: the remote team can reduce the operational domain, pause service in a zone, or pull vehicles back to a safe area.

If you do not separate these, you end up with the “random joystick” risk. Not because the person is incompetent, but because the system is asking for heroics instead of providing structure.

What to specify before you add more cars

Before anyone argues about fleet size, specify the remote-ops model in writing. Not as policy theater, as a tool for alignment and audit. If you want a starting checklist:

• Span of control: how many simultaneous interventions can one remote specialist safely support, and what is the evidence?
• Intervention taxonomy: define which events trigger remote involvement, and which ones must stay fully autonomous.
• Escalation paths: what triggers an incident commander, legal notification, or a city liaison?
• Training and certification: what competencies are required, and how are they tested and refreshed?
• Logs and replay: what data is retained, for how long, and who can access it?

Notice what is missing: model architecture. Not because it is irrelevant, but because it is not what fails first in public service.

The safety case is not a PDF, it is a living contract with reality

In regulated environments, “safety case” gets treated as paperwork. In practice, it is the argument that connects assumptions to operations. It states: this is the domain we claim to handle, these are the hazards, these are the controls, and this is how we monitor that the controls still work.

Copenhagen forces the uncomfortable question of what the system is actually claiming. A robot-taxi service is not “autonomous driving”. It is:

• a dispatch system
• a payments and identity system
• a fleet health and maintenance system
• a remote assistance and incident system
• a customer support system
• a compliance and audit system

The vehicle is one component. The safety case must cover the whole service, including how humans interact with it under stress.

I have watched connected products fail in the field not because the embedded code was wrong, but because the handoffs were undefined. A support agent guessed. An engineer improvised. A partial log made everyone argue. The fix was never “better AI”. The fix was clearer boundaries, better instrumentation, and fewer ambiguous decisions in the moment.

If you want autonomy to be boring, you need to make the safety case operational: it must drive training, alerting, and release gates. That is also why I like treating formal specifications as incident tools, not academic proofs, as I wrote in Formal Specs Are Incident Tools, Not Academic Proofs.

Liability is the design constraint nobody wants to own

Every autonomy project eventually collides with liability. Not as a legal footnote, as the core constraint that shapes the entire system.

The question “who is responsible?” shows up in multiple layers:

• Real-time decisions: if remote-ops approves a maneuver, is that “driving” or “supervising”?
• System design: if a safety mechanism is missing, who signed off on that gap?
• Operations: if the service continues during conditions outside the stated domain, who made that call?
• Commercial model: who is the service provider on paper, and what does the customer believe they are buying?

One reason the Copenhagen story matters is that it is explicitly about scrutiny and control, not just novelty. The article makes clear that the planned deployment is a larger step than earlier projects, and that it will be examined and requires a control center in Denmark. That is Denmark inching toward the real question: are we approving a technology demo, or licensing a service with enforceable accountability?

If you are the person accountable for bringing autonomy into a regulated context, treat liability as a product requirement. It will shape your org chart, your vendor contracts, your logging, your insurance, and your customer communication. Ignoring it only pushes it into the first incident.

A Copenhagen-ready autonomy model: the minimum you should demand

Forget grand statements about “being first”. A city should demand a minimum viable operating model that makes failures containable and decisions reviewable. If you are evaluating a vendor, a partner, or your own plan, I would push for five non-negotiables.

1. Onshore incident authority: not just a room with screens, but a named function that can pause operations, contact authorities, and trigger escalation.
2. Bounded remote interventions: a written taxonomy, with technical controls that prevent improvised tele-driving outside allowed cases.
3. End-to-end observability: vehicle telemetry, perception snapshots where appropriate, remote-ops actions, and customer interactions tied together into one timeline.
4. Release discipline tied to safety claims: changes that affect the safety case go through explicit review and staged rollout. Treat it like a release pipeline, not a feature toggle. The same idea shows up in software too, which I covered in Default-On Agentic Coding Is a Release Pipeline Change, Not a Feature Toggle.
5. Clear commercial accountability: the entity collecting money must be the entity that can be held responsible, or you are building a blame maze.

That list is not exhaustive. It is the floor. If you cannot explain these clearly, you do not yet have a service, you have a prototype with passengers.

My opinion: regulate the service, not the magic

Autonomy will arrive in Copenhagen, in some form. The question is whether it arrives as a serious, inspectable public service, or as a fragile arrangement that only looks safe until the first complex incident.

“AI in the vehicle” will keep improving, with or without Danish approval. The differentiator for Copenhagen is whether we can define a robust way to run the whole system: remote-ops with real command, safety cases that change with reality, and liability that is explicit rather than implied.

If you are a founder, owner, or senior leader building anything regulated and safety-adjacent, borrow this lens: the technical core is rarely the bottleneck. The bottleneck is the operating model that makes your claims defensible, your incidents manageable, and your responsibility clear.