Det svære ved autonomi er ikke bilen. Det er servicen.

De fleste samtaler om autonomi starter samme sted: sensorer, perception, planlægning og trylleordet “AI”. Og så stopper de ofte der – som om bedre modeller er den manglende ingrediens mellem en kontrolleret pilot og en reel service i en hovedstad.

København er ved at teste den antagelse offentligt. Pointen er ikke, om en self-driving stack kan holde sin vognbane. Pointen er, om Danmark vil drive autonomi som en reguleret service: med et control center i landet, med beslutninger der kan auditeres, og med et troværdigt svar på et enkelt spørgsmål: Hvem har ansvaret, når ingen kører?

Den danske debat ramte det kontant i én sætning: vi skal ikke have en tilfældig gut med joystick til at styre 40 biler. Det er ikke en punchline. Det er operating model-spørgsmålet, formuleret i helt almindeligt sprog.

Autonomy-stacken er den “lette” del, fordi den er læsbar

“Let” er relativt. At bygge sikker autonomi er hård engineering. Men det er læsbar engineering. Du kan benchmarke, simulere, måle disengagements og shippe forbedringer. Du kan fordele teams, tickets og budgetter. Du kan tegne klare grænser omkring det.

Service delivery i en tæt by er noget andet. Det er rodet, politisk og fyldt med edge cases, som slet ikke er “AI-problemer”:

• Hvordan håndterer du en passager, der nægter at forlade bilen, efter turen er afsluttet?
• Hvad sker der, når en politibetjent giver håndtegn, der strider mod afmærkningen?
• Hvem beslutter at pause driften under en storm – og hvilket grundlag dokumenterer beslutningen?
• Hvordan beviser du bagefter, hvad systemet “så”, og hvorfor det handlede, som det gjorde?

Derfor betyder control center’et noget. Ikke som marketingrekvisit, men som stedet hvor ansvaret samler sig. Planen om at etablere et dansk control center er ikke en implementeringsdetalje. Det er det egentlige produkt.

Remote-ops er ikke én person, der ser på skærme. Det er et command system.

Remote operations bliver ofte forestillet som tele-driving: et menneske tager over, når bilen får problemer. Det billede er både for simpelt og for risikabelt. I en reguleret byservice skal remote-ops ligne incident command mere end gaming.

Skiftet er dette: Det remote team skal ikke “køre bilen”. De skal drive systemet. De træffer afgrænsede beslutninger efter regler – med logging, eskalation og handoffs.

En praktisk måde at designe det på er at adskille tre kapabiliteter:

• Assistance: det remote team leverer kontekst og tilladelse, fx ved at godkende en forsigtig manøvre eller rute uden om en blokeret gade.
• Recovery: det remote team iværksætter et sikkert stop, sender field support eller koordinerer med myndigheder. Her tæller minutter.
• Containment: det remote team kan reducere det operationelle domæne, pause service i en zone eller kalde biler tilbage til et sikkert område.

Hvis du ikke skiller de tre ting ad, ender du med risikoen ved “tilfældig joystick”. Ikke fordi personen er inkompetent, men fordi systemet beder om heltegerninger i stedet for at give struktur.

Hvad der skal specificeres, før du tilføjer flere biler

Før nogen diskuterer flådestørrelse, så få remote-ops-modellen ned på skrift. Ikke som policy-teater, men som et værktøj til alignment og audit. Hvis du vil have en start-checkliste:

• Span of control: hvor mange samtidige interventioner kan én remote specialist håndtere sikkert – og hvad er evidensen?
• Intervention taxonomy: definér hvilke hændelser der udløser remote involvering, og hvilke der skal forblive fuldt autonome.
• Escalation paths: hvad udløser en incident commander, juridisk notifikation eller en city liaison?
• Training and certification: hvilke kompetencer kræves, og hvordan testes og vedligeholdes de?
• Logs and replay: hvilke data gemmes, hvor længe, og hvem har adgang?

Bemærk, hvad der mangler: modelarkitektur. Ikke fordi det er irrelevant, men fordi det sjældent er det, der fejler først i offentlig service delivery.

Safety case er ikke en PDF. Det er en levende kontrakt med virkeligheden.

I regulerede miljøer bliver “safety case” ofte behandlet som papirarbejde. I praksis er det argumentet, der forbinder antagelser med drift. Det siger: dette er domænet, vi påstår at kunne håndtere; dette er farerne; dette er kontrollerne; og sådan overvåger vi, at kontrollerne stadig virker.

København tvinger det ubehagelige spørgsmål frem: Hvad er det egentlig, systemet påstår? En robot-taxa-service er ikke “autonomous driving”. Det er:

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

Køretøjet er én komponent. Safety case skal dække hele servicen – inklusive hvordan mennesker interagerer med den under pres.

Jeg har set connected products fejle i felten, ikke fordi embedded-koden var forkert, men fordi handoffs var udefinerede. En support agent gættede. En ingeniør improviserede. Et delvist log-udtræk gjorde, at alle diskuterede. Løsningen var aldrig “bedre AI”. Løsningen var skarpere grænser, bedre instrumentation og færre tvetydige beslutninger i øjeblikket.

Hvis du vil have autonomi til at være kedeligt, skal safety case gøres operationel: den skal styre træning, alarmering og release gates. Det er også derfor, jeg kan lide at se formelle specifikationer som incident tools snarere end akademiske beviser, som jeg skrev i Formal Specs Are Incident Tools, Not Academic Proofs.

Ansvar er design-constrainten, ingen rigtig vil eje

Alle autonomi-projekter rammer før eller siden spørgsmålet om liability. Ikke som en juridisk fodnote, men som den centrale constraint, der former hele systemet.

Spørgsmålet “hvem er ansvarlig?” dukker op i flere lag:

• Beslutninger i realtid: hvis remote-ops godkender en manøvre, er det så “kørsel” eller “supervision”?
• Systemdesign: hvis en safety-mekanisme mangler, hvem har signeret den mangel?
• Drift: hvis servicen fortsætter under forhold uden for det deklarerede domæne, hvem traf den beslutning?
• Commercial model: hvem er service provider på papiret – og hvad tror kunden, de køber?

En af grundene til, at historien om København betyder noget, er, at den eksplicit handler om kontrol og granskning – ikke bare nyhedsværdi. Artiklen gør det klart, at den planlagte udrulning er et større skridt end tidligere projekter, og at den skal granskes og kræver et control center i Danmark. Det er Danmark på vej mod det egentlige spørgsmål: Godkender vi en teknologidemo, eller licenserer vi en service med håndhæveligt ansvar?

Hvis du er den, der står på mål for at bringe autonomi ind i en reguleret kontekst, så behandl liability som et produktkrav. Det vil forme dit org chart, dine vendor contracts, din logging, din forsikring og din kundekommunikation. Hvis du ignorerer det, flytter du det bare ind i den første incident.

En København-klar autonomi-model: minimumskravet

Glem store erklæringer om at “være først”. En by bør kræve en minimum viable operating model, der gør fejl håndterbare og beslutninger efterprøvelige. Hvis du evaluerer en vendor, en partner eller din egen plan, ville jeg insistere på fem non-negotiables.

1. Onshore incident authority: ikke bare et rum med skærme, men en navngiven funktion, der kan pause driften, kontakte myndigheder og trigge eskalation.
2. Bounded remote interventions: en skriftlig taxonomy – med tekniske kontroller, der forhindrer improviseret tele-driving uden for tilladte cases.
3. End-to-end observability: vehicle telemetry, relevante perception snapshots, remote-ops handlinger og kundeinteraktioner bundet sammen i én timeline.
4. Release discipline koblet til safety claims: ændringer der påvirker safety case, går gennem eksplicit review og staged rollout. Behandl det som en release pipeline – ikke som en feature toggle. Samme pointe findes i software også, som jeg skrev om i Default-On Agentic Coding Is a Release Pipeline Change, Not a Feature Toggle.
5. Klar kommerciel ansvarlighed: den enhed, der tager imod betalingen, skal også være den enhed, der kan holdes ansvarlig – ellers bygger du en blame maze.

Listen er ikke udtømmende. Den er gulvet. Hvis du ikke kan forklare de fem punkter klart, har du endnu ikke en service – du har en prototype med passagerer.

Min holdning: regulér servicen, ikke magien

Autonomi kommer til København i en eller anden form. Spørgsmålet er, om det kommer som en seriøs, inspicerbar public service – eller som en skrøbelig konstruktion, der ser sikker ud, indtil den første komplekse incident.

“AI i køretøjet” bliver ved med at forbedre sig, med eller uden dansk godkendelse. Differentieringen for København er, om vi kan definere en robust måde at drive hele systemet på: remote-ops med reelt command, safety cases der ændrer sig med virkeligheden, og liability der er eksplicit frem for underforstået.

Hvis du er founder, ejer eller seniorleder og bygger noget reguleret og safety-adjacent, så lån denne linse: den tekniske kerne er sjældent bottleneck’en. Bottleneck’en er operating model’en, der gør dine påstande forsvarlige, dine incidents håndterbare og dit ansvar tydeligt.