... men jeg kan ikke se hvordan at det offentlige kan have et ansvar for et køretøj, hvor de hverken får hardware diagrammet eller softwaren. Det kan kun være producenten som har ansvaret.

Når EU skriver, at en af parterne i problemstillingen er Accredited security auditors, må det være samme funktion som det der i dag ligger i bilers typegodkendelse - blot altså i en meget mere omfattende funktion. Jag kan godt forestille mig, at myndigheder i fremtiden vil kunne nægte at typegodkende biler, hvis det viser sig at softwaren i dem er for ustabil eller for "amoralsk" til det europæisk marked - på samme måde som visse biler ikke kan godkendes fordi de har for dårlig sikkerhed eller forurener for meget. Så på den måde har myndighederne et vist ansvar. Men det er selvfølgelig ikke ensbetydende med, at den form for ansvar afspejles på bilens ejer eller på fabrikanten, men mon ikke man vil tage aktion hvis den samme bilmodel hele tiden er involveret i den samme type ulykke - trods alt.

At myndigheder kommer til at have et ansvar i forhold til C-ITS er der næppe tvivl om.

En hel del af de spørgsmål som rejses i tråden her, er behandlet i EU kommissionens framework fra 2017: "Security Policy & Governance - Framework for Deployment and Operation of European Cooperative Intelligent Transport Systems (C-ITS)".

Det er dette framework som danner grundlaget for både ETSI's V2x standardisering og for EU's beslutninger i forhold til sikkerhed, ansvar og implementering af C-ITS.

Dykker man ned i afsnit A.4 fremgår det, at man arbejder med "Accredited security auditors" og "Data Protection Authorities", som er myndighedsrepresentation i forhold til sikkerhed. Man er ikke nået så langt i dette arbejde (der er mange gule streger), men billedet er ved at tegne sig. At myndigheder kommer til at have et ansvar i forhold til C-ITS er der næppe tvivl om.

Frameworket ligger her: https://ec.europa.eu/transport/sites/transport/files/c-its_security_policy_release_1.pdf

... og jeg ved ikke om der er kommet revisioner af dokumentet siden 2017.

I 5GAA har man to arbejdsgrupper som beskæftiger sig med disse spørgsmål: WG6: Regulatory and Public Affairs, og WG7: Security and Privacy

Alle andre er ansvarlige for
Alle andre er ansvarlige for hvad vi udvikler og sender på markedet, hvorfor i alverden skal softwareproducenter så ikke være det. Hvis man holdt softwareproducenter ansvarlige for det de laver, kunne det være vi slap for de stimer af softwareopdateringer som ikke er i orden når de lanceres. Som medarbejder i en rådgivende ingeniørvirksomhed har jeg arbejdet med følgende besked "ingen opdaterer til den nyeste CAD version før tidligst når vi har fået revision 2. Så er de hypigste/værste fejl nok væk"</p>
<p>Manglende signaler og blænede kameraer er også softvareproducentens ansvar. Hvis jeg bliver blændet af solen og kører over et barn, er jeg selvfølgelig ansvarlig. Hvis det var AI som fik ødelagt signalet fra et kamera og kører barnet ned, er det softwareproducentens ansvar. Alternativet er at "det er der ikke rigtig nogen som har ansvaret for, det er bare trist for ungen.

Alle andre er ansvarlige for hvad vi udvikler og sender på markedet, hvorfor i alverden skal softwareproducenter så ikke være det. Hvis man holdt softwareproducenter ansvarlige for det de laver, kunne det være vi slap for de stimer af softwareopdateringer som ikke er i orden når de lanceres. Som medarbejder i en rådgivende ingeniørvirksomhed har jeg arbejdet med følgende besked "ingen opdaterer til den nyeste CAD version før tidligst når vi har fået revision 2. Så er de hypigste/værste fejl nok væk"

Manglende signaler og blænede kameraer er også softvareproducentens ansvar.Hvis jeg bliver blændet af solen og kører over et barn, er jeg selvfølgelig ansvarlig. Hvis det var AI som fik ødelagt signalet fra et kamera og kører barnet ned, er det softwareproducentens ansvar. Alternativet er at "det er der ikke rigtig nogen som har ansvaret for, det er bare trist for ungen.

Hvad nu hvis AI systemerne har færre dødsulykker?

Hvad nu hvis AI systemerne har færre dødsulykker?

Jeg kan da lige tilføje et vigtigt element her: IT sikkerhed Alt hvad der her er nævnt af udfordringer bygger på den præmis, at der er tale om uforudsigelighed eller deciderede fejl ( brugerfejl eller fejl i hardware og software forståes, hvilket et stykke ud i fremtiden nok stadig er uundgåeligt).

Jeg mener AI kan være et problem, fordi der måske tages mange tilfældige beslutninger, og kan være mange interne tilstande. Dette er generalt et problem, fordi det ødelægger brugerens følelse med produktet. Vi risikerer, at vi ikke kan forudsige hvordan produktet fungerer, fordi at dets opførsel er uoverskuelig, eller uforudsigelig, og ikke gjorde det samme sidst. Dette er et problem.

Men, vi skal altid kunne reproducere data fra loggen med andre af producentens tilsvarende enheder, og kunne genskabe situationen. Tager vi identiske enheder, skal de altid give eksakt samme resultat. Er det forskel, så er det altid hardwarefejl (manglende redundans), eller fejl i producentens software. Det er vigtigt, at altid analyserer data i den sorte boks, for at undersøge om det er hardwarefejl, designfejl, eller brugerfejl. Hvis det er brugerfejl, kan årsagen være produktets uforudsigelighed, og at man troede der skete noget andet, og det syntes jeg generalt er et problem når teknologien fungerer ud fra uoverskuelige algoritmer. Teknisk, er det dog ikke et problem at reproducere og undersøge en fejl, da det altid er et krav, at alle tilfældige valg logges. Normalt, vil vi helst undgå tilfældige valg, og i stedet altid vælge et optimalt valg.

Forslag til regler:

Alt udstyr skal indeholde en sort boks. Indholdet i den sorte boks, skal udover at indikere alle inputs og outputs på begge sider af ulykkes tidspunktet, altid indeholde så mange oplysninger, at det er muligt at reproducere teknikkens opførsel på uheldstidspunktet. Ellers, er det altid leverandørens hovedpine.

Der hvor det er vigtigt for sikkerheden, skal der være flere følere og inputs, så der kan ses om der kan være fejl i følere.

Ud fra ovenstående, skal vi gerne kunne reproducere ulykken, og verificere at teknikken har fungeret overens med de andre tilsvarende produkteter.

Herefter må vi afgøre, om det er en designfejl, eller om det er en brugerfejl. Hvis det er en brugerfejl, skal vi se på, om der kan gøres noget for at undgå den, f.eks. om manualen er i orden, om undervisning i produktet er i orden, og om brugeren har tilstrækkelig træning i produktet, og om den pågældende træning indeholder den pågældende typer af situationer.

Mekanik kan også uden AI være skyld i ulykker - som eksempel, kan et flyuheld måske skyldes produktionsfejl på flyet. Ofte opdages det først, når flere ensartede uheld, rammer samme type.

Det er vigtigt at vi sætter krav til teknologien - det kan f.eks. være en sort kasse, der logger alt som sker før og efter uheld, og som kan anvendes til at analysere uheldet.

Det er også vigtigt, at man gør noget aktivt for at finde ud af hvad det er sket - og ikke bare giver føren ansvaret. Ofte ser vi at en forsikring bare betaler, uden at teknologien undersøges, fordi at det er den nemme løsning, og det er almindeligt accepteret, at der opstår uheld. Resultatet er, at samme uheld måske opstår igen.

I mange sammenhænge, er også en fordel at sætte krav til determinisme - det kan man ikke så nemt ved AI. Men, det er dog ikke utænkeligt, at der kan logges så mange data, at det er muligt at genskabe uheldet med simulation.

Udover at en sort boks kan afsløre om teknologien fejler, så kan den også afsløre hvad at brugeren har gjort, og en analyse kan afsløre om brugeren har gjort noget forkert.

Det er vigtigt, at man ved uheld analyserer dem grundigt, fordi at den viden man får herfra, kan være med til at forebygge uheld fremover. Er det f.eks. brugeren der laver fejl, så kan det ske at det reelt mangler informationer i manualen, eller i undervisningen af brugen har manglet, været dårlig, eller endog fejlbehæftet.

I nogen tilfælde skal man passe på med AI - problemet er at kompleksiteten gør, at det er meget svært at få et godt forhold til. Mennesker er dygtige til at blive fortrolige med teknik, hvis antallet af tilstande er minimale, men er det kompliceret med et stort antal tilstande som vi ikke kender, så mister vi overblikket. Og, i dette tilfælde, så må man sige, at ansvaret helt og aldeles kun kan lægges på AI. Altså, hos virksomheden der producerer det. Vi kan ikke lægge ansvaret hos en bruger, hvis det ikke er muligt for brugeren, at vurdere hvordan produktet fungerer.

I mange tilfælde, er det en stor fordel, at sætte krav til at et produkt er deterministisk, og veldefineret. Det betyder, at vi helt præcist har en entydig specifikation af, hvordan at produktet fungerer, som vi kan forholde os til. Udfører udstyret en fejl i forhold til specifikationen, så er det en implementeringsfejl. Er der fejl i specifikationen, så er det en designfejl. Det er således nemt at finde ud af fejltypen, hvis vi har logdata. Vi kan undgå fejl på mange måder. Typisk undgås specifikationsfejl ved, at flere gennemlæser og analyserer specifikationen, for at sikre sig, at de er enige om der ikke er fejl. At specifikationen er entydig, kan undersøges ved at lade flere hold løse den samme opgave, og tjekke at deres implementeringer virker helt identisk, indenfor de rammer som specifikationen foreskriver omkring usikkerhed.

Indenfor software, er meget almindeligt at sætte krav i specifikationen til eksakt timing - på denne måde, så sikres, at data svarer eksakt samtidigt, og det er enkelt at sammenligne flere uafhængige implementeringer, for at se de giver identiske svar. Denne metode umuliggør eksmpelvis at et hold af programmører laver fejl, fordi at så vil de andre uafhængige implementeringer være forskellige. Ellers, er de ikke uafhængige. At de er uafhængige har man metoder til at sikre, blandt andet må de ikke anvende ens software eller rutiner, med mindre at disse er 100% matematisk beviste, og således er udenfor det som skal dokumenteres. Implementeringsfejl, er således nemt at undgå, og fejl hos programmører, og i hardware kan vi udelukke, hvis det er enentydigt specificeret. Derimod fejl i specifikationen, kan vi kun undgå, ved at have flere til at læse korrektur på den. Typisk vil alle uafhængige hold der koder, også læse korrektur.

Derudover bør vi altid sætte krav til en sort boks, der kan afsløre om fejlen skyldes teknologien. Det skal ud fra data i den sorte boks altid være muligt at reproducere teknikkens opførsel - ellers er det altid producentens hovedpine. Herefter kan man så undersøge, om den påvældende opførsel er korrekt, eller om der er en designfejl. Er der en alvorlig designfejl, vil alle produkter skulle tilbagekaldes, og opdateres. Da den gamle godkendelse vil blive trukken tilbage, er også nødvendigt at få produktet tjekket og godkendt på ny.

Og hvad nu hvis ulykken skyldes at:</p>
<p>5G forbindelsen til bilen fejlede i et kort øjeblik
En refleks i et vindue blændede on-board cameraet
En anden bil sendet fejlagtig information om sin placering eller hastighed
To biler bliver uenige om hvordan der skal undviges
.... fortsæt selv listen.

Vi taler faktisk om tre typer ansvar når vi arbejder med produkter:

• Strafferet (Sikkerhedsstyrelsen)
• Erstatning (Produktansvarforsikring så en skadet person kan få en erstatning)
• Købelov (Sikkerhedsstyrelsen vurderer at produktet ikke overholder gældende krav og kræver tilbagekaldelse: Fabrikanten der har CE-mærket produktet har omkostningen til udbedring eller til at købe produktet tilbage: Fabrikanten vælger)

Hans Morten Henriksen Maskinsikkerhd ApS

og det må vel også være situationen og ulykke statistikker som er bestemmende for om producenten skal straffes.

Men når der tales ansvar, så være lige skarp på om der menes økonomisk ansvar, eller strafferetsligt ansvar.

Mange tager udgangspunkt i regler og filosofi i USA

AI og maskinsikkerhed er diskuteret i arbejdsgruppen ISO TC 199 wg 5 Risikovurdering (og hackersikring af maskiner, brugsanvisinger mv). Vi var hurtigt enige: Det er maskinfabrikantens ansvar: Han må give robotten alt det AI han vil, bare hans risikovurdering viser at det er sikkert. Og den ansvarlige fabrikant skriver jo under på maskinens EF-/EU-Overensstemmelseserklæring og CE-mærker sin maskine. Og dermed er ansvaret entydeigt placeret. Arbejdsgiveren skal så anvende maskinen efter beskrivelsen i brugsanvisningen. Går arbejdsgiveren uden for brugsanvisningen, fx ved en ny programmering i robottens AI, er arbejdsgiveren fabrikant af den ændring, og skal dokumentere i en ny risikovurdering at maskinen fortsat er sikker. Sådan er produktsikkerhed reguleret i EU/EØS. Men i USA arbejder man ikke med fabrikantansvar på samme vis: Her er det brugeren (arbejdsgiveren) der har ansvaret, og han må så kontraktligt forpligte sin leverandør. Så pas på når du læser om AI: Mange tager udgangspunkt i regler og filosofi i USA. EU har klare regler på området, men er på vej med en uddybning vedr AI i den kommende Maskinforordning, der forventes at gælde fra en gang 2024. Det draft der ligger har også AI med, men det afsnit må vi forvente bliver ændret.

Hans Morten Henriksen, hmh@maskinsikkerhed.dkMaskinsikkerhed ApS Specialist i maskinsikkerhed og CE-mærkning, Formand for S-250 og dansk repræsentant i ISO TC 199 wg 5.

Hvilken producent?

Det har aldrig været et problem at identificere hvem som har ansvaret for et produkt, og det er det stadig ikke.

og det må vel også være situationen og ulykke statistikker som er bestemmende for om producenten skal straffes

Hvilken producent?

• Bilproducenten

• Netværksleverandøren

• Softwareudviklerne

• Standardiseringsenheden

• Vejdirektoratet (som måske forsyner bilerne med køreinformation)

Det vil i mange tilfælde være helt umuligt at afgøre hvilken producent som har ansvaret, og så er det letteste jo at tøre den af på kunden og hans forsikringsselskab.

Det er vel som alt der produceres producentens ansvar. Hvorfor skulle det pludseligt være anderledes fordi der er en AI involveret? Men det være sagt så "shit happens" og det må vel også være situationen og ulykke statistikker som er bestemmende for om producenten skal straffes.

Gråzonen er selvfølgelig, hvis de burde kunne forudse det,

Og hvad nu hvis ulykken skyldes at:

• 5G forbindelsen til bilen fejlede i et kort øjeblik

• En refleks i et vindue blændede on-board cameraet

• En anden bil sendet fejlagtig information om sin placering eller hastighed

• To biler bliver uenige om hvordan der skal undviges

• .... fortsæt selv listen.

En række af disse problemstillinger arbejder man intensivt på allerede, ikke mindst i ETSIs standardiseringsarbejder på V2X. Det kan man bl.a. læse meget mere om her: https://www.etsi.org/newsroom/news/1763-2020-05-second-etsi-c-v2x-interoperability-test-event-to-connect-vehicles-in-europe-and-in-the-rest-of-the-world

Det er helt ekstremt spændende at følge hvordan man standardiserer på området, og lidt mærkeligt at der slet ikke er dansk deltagelse i 5GAA - som i slet ikke, ikke et eneste dansk firma.

Det kan godt være at Danmark havde en intension om at være førende 5G nation, men det forudsætter jo at man er med hvor tingene udvikles. Jeg tror desværre, at danske politikere misforstår, og tror at man bliver førende ved at bruge (andres) 5G teknologi.

Biler skal have en ansvarsforsikring for at køre på vejene. Det samme bør gælde for robotter.

Så må forsikringsselskaberne og producenterne slås om hvordan den skal skæres. Hvis en producent ikke vil tage ansvar, så vil forsikringen på deres produkt blive dyr.

Strafferetsligt er der ikke så meget at komme efter. Ingen kan straffes for noget de ikke kunne forudse. Gråzonen er selvfølgelig, hvis de burde kunne forudse det, eller endnu værre, vidste det men ikke gjorde noget.