Svært at placere ansvaret, når AI slår ihjel

Plus16. december 2020 kl. 11:0020
Arkivfoto - selvkørende bil stopper for fodgængere
Illustration: Sangoiri / Bigstock.
Hvem har ansvaret, når kunstig intelligens laver ulykker? Brugeren, producenten... eller staten?
Artiklen er ældre end 30 dage

Husker du ulykken i Arizona i 2018, hvor en selvkørende Volvo fra Uber kørte en kvinde ihjel? Bilens software identificerede ved en fejl ikke kvinden, der gik over vejen med sin cykel, som en kollisionsfare.

Gratis adgang i 30 dage

Tegn et gratis prøveabonnement og få adgang til alt PLUS-indhold på Ing.dk, Version2 og Radar, helt uden binding eller betalingsoplysninger.

Alternativt kan du købe et abonnement
remove_circle
Har du allerede et PLUS-abonnement eller klip?
close

Velkommen til PLUS

Da du er ved at tilmelde dig en gratis prøve beder vi dig hjælpe os med at gøre vores indhold mere relevant for dig, ved at vælge et eller flere emner der interesserer dig.

Vælg mindst et emne *
Du skal vælge en adgangskode til når du fremover skal logge ind på din brugerkonto.
visibility
Dit medlemskab giver adgang
Som medlem af IDA har du gratis adgang til PLUS-indhold, som en del af dit medlemskab. Fortsæt med MitIDA for at aktivere din adgang til indholdet.
Oplever du problemer med login, så skriv til os på websupport@ing.dk
Abonnementsfordele
vpn_key
Fuld adgang til Ing.dk, Version2 og Radar
Fuld digital adgang til PLUS-indhold på Ing.dk, Version2 og Radar, tilgængeligt på din computer, tablet og mobil.
drafts
Kuraterede nyhedsbreve
Det seneste nye fra branchen, leveret til din indbakke.
Adgang til andre medier
Hver måned får du 6 klip, som kan bruges til permanent at låse op for indhold på vores andre medier.
thumb_up
Adgang til debatten
Deltag i debatten med andre kloge læsere.
20 kommentarer.  Hop til debatten
Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
20
17. december 2020 kl. 17:13

... 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.

Ja, der er mange udfordringer gemt i den teknologi.

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.

19
17. december 2020 kl. 14:28

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

I forbindelse med services som drives af det offentlige, f.eks. trafiklys, og i fremtiden trådløse services, så er det naturligt, at det offentlige må have et ansvar - 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. Myndighederne kan måske have et ansvar for, at lave en lovgivning, og at lovgivningen sikrer, at man er i stand til at kunne ansvarsplacere fejl. En god løsning er krav til en sort boks i alle køretøjer, der indeholder elektronik, så det er muligt at undersøge om teknikken har fejlet op til en ulykke. Uden en sort boks, er det umuligt. Elektronikken kan måske have redundans, backups, og masser af former for sikkerhed, men der er aldrig noget, som kan erstatte en sort boks, når der er sket en fejl, og den skal analyseres. Teknikken kan ikke analyseres uden inputs, og myndighedernes skal blandt andet at sætte krav til den sorte boks's indhold, så det sikres at det er muligt at undersøge, om det er en fejl på produktet. En god regel er, at det altid skal være muligt at reproducere hændelsen, ud fra den sorte boks indhold, og at det også skal være muligt at reproducere de signaler, som den sorte boks har optaget.

18
17. december 2020 kl. 13:44

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

17
17. december 2020 kl. 12:22

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.

Det er lidt forkert at skyde det hele på software - men du har helt ret i, at det er producentens ansvar. Fejlen kan både ligge i software og hardware - i begge tilfælde, er det naturligvis altid producentens ansvar. Når du sælger software som et produkt, gælder samme ansvarsforpligtelser som for andre produkter - vi kan tage softwaren i et komfur, eller en vaskemaskine som eksempel. Der er ingen evige opgraderinger, fejlretninger og den slags - dette er noget vi kun kender fra PC verden. Producenterne vil naturligvis gerne have det ind under andre ting, såsom køleskabe osv. så de aldrig behøver at færdigudvikle produktet, men kan sende opdateringer jævnligt, og når så endeligt at køleskabet køler til den rette temperatur, så er det forældet.

16
17. december 2020 kl. 12:11

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.

14
17. december 2020 kl. 11:11

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

13
17. december 2020 kl. 02:04

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).

Uforudsigelighed findes ikke - vi kan, og skal altid logge enhver tilfældig beslutning, som softwaren tager, da det skal være muligt at simulere produktets opførsel på ulykkestidspunktet. Et softwareprodukt må ikke tage tilfældige beslutninger, som ikke logges i den sorte boks.

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.

12
17. december 2020 kl. 00:55

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.

11
17. december 2020 kl. 00:29

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.

10
16. december 2020 kl. 23:51

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.

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). Men ligesom med alt andet software - specielt hvis det kommunikerer over et netværk - er kompleksiteten af problemet nu yderligere forøget ved at tilføje problematikken omkring IT sikkerhed, idet der også skal indregnes muligheden for at softwaren kan være blevet kompromitteret. Omvendt kan det at sandsynliggøre at et system er blevet hacket, i sig selv kan være noget af en udfordring og for at gøre det hele endnu værre er det ikke givet at der er en direkte sammenhæng mellem kompromitteret software og et fejlende system.

9
16. december 2020 kl. 19:52

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

6
16. december 2020 kl. 14:01

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.

5
16. december 2020 kl. 13:38

Hvilken producent?

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

4
16. december 2020 kl. 13:32

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.

3
16. december 2020 kl. 13:25

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.

2
16. december 2020 kl. 13:17

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

Ja, det er lige præcis der skoen trykker. For at man kan forudse noget kræver det indsigt. Nogen har mere indsigt end andre. Og hvis indsigt også kærver at man læser det med småt på side 345 i manualen, så er vi for alvor i problemer.

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.

1
16. december 2020 kl. 12:41

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.