När ingen sitter bakom ratten – AI och ansvarsutmaningar i en digitaliserad framtid

I mars 2018 blev en kvinna i Tempe i den amerikanska delstaten Arizona påkörd av en Volvo XC90 som tillhörde Ubers initiativ för självkörande bilar. Olyckan fick tragiskt nog dödlig utgång, och händelsen kommer gå till historien som det första dödsfallet orsakad av en självkörande bil (nivå 3 eller högre på på Society of Automotive Engineers (”SAE”) 5 graders automationsskala). Tidigare bilolyckor med dödlig utgång har alltid involverat bilar som befunnit sig på de lägre nivåerna (0-2) av SAEs automationsskala för bilar.

Vad vi ser i och med denna tragedi är en olycklig milstolpe i ett paradigmskifte där vi kommer gå mer och mer mot automation. Visionen för många av bolagen engagerade i automation av bilar är dock att kraftigt reducera olyckorna, då tekniska problem eller yttre omständigheter endast står för ca 6% av alla bilolyckor medan den stora boven är den mänskliga faktorn på 94%.

Men vad hände egentligen med Uber i detta fall? Vem ansågs vara ansvarig för kvinnans död? Var det Volvo vars bil träffade kvinnan? Nvidia vars hårdvara användes som ”hjärna” i bilen? Eller Uber själva, som stod för mjukvaran som processade sensordata och styrde bilen?

Uber träffade en förlikning med kvinnans familj redan samma månad som olyckan skedde. Vilken kompensation kvinnans familj fick har hållits hemligt. Däremot fortsatte den straffrättsliga utredningen mot företaget i drygt ett år innan den lades ner av åklagaren i Yavapai County. Åklagaren bedömde att det inte fanns grund för att hålla Uber straffrättsligt ansvariga i fallet, då bolaget haft en designerad förare i bilen vars uppdrag var att se till så att bilen undvek just den typen av situation som hade uppstått. Vidare ansågs offret ha bidragit till olyckan genom att hon korsade vägen, som hade en hastighetsbegränsning på 45 MPH (72 km/h), i mörkret (vilket dock inte borde påverka bilens förmåga att identifiera henne) långt ifrån närmaste övergångsställe. ”Föraren” av bilen har dock inte sluppit undan, och en utredning pågår fortfarande mot denne.

Men vad kommer hända när vi oundvikligen når nivå 4 och 5 på SAE:s skala? Det må verka avlägset, men de flesta större biltillverkare räknar med att leverera nivå 4 bilar någon gång mellan 2021 och 2030, beroende på miljö och region. Detta motsvarar en nivå på autonomin hos bilarna som är så hög att föraren inte överhuvudtaget ska behöva intervenera i bilens körning. I dessa fall vore det inte heller rimligt att klandra en s.k. ”förare” vid en eventuell olycka. Vem bär då ansvaret? Vidare, är det rimligt att hålla en utvecklare av bilens AI, eller en producent av dess hårdvara ansvarig för något som en autonom robot begått p.g.a. något som roboten lärt sig helt själv, avskilt från dess skapare? Detta sista exempel är för närvarande något avlägset, men för varje dag som går närmar vi oss just den situationen. En situation där den autonoma roboten kommer ta beslut på grunder som inte direkt avsetts, eller kunnat förutses, av dess skapare.

I EU:s organ diskuteras frågan om reglering av autonoma robotar och AI sedan några år tillbaka, och parlamentet har bland annat lämnat förslag till kommissionen angående hur och vad framtida reglering bör reglera. Parlamentet belyser problematiken som tagits upp ovan, d.v.s. att robotar i framtiden kommer vara autonoma i den mening att de kommer fatta beslut på grunder som inte rimligen kunnat förutses. Parlamentet lyfter även problematiken med att hålla en autonom robots skapare ansvarig vid olyckor där varken vårdslöshet, uppsåt eller ens ett produktionsfel nödvändigtvis var orsak till händelsen. Dessa frågor känns direkt främmande för en jurist uppvuxen och utbildad i en värld utan den här typen av teknik. Lösningen torde kanske istället vara att ge någon form av rättskapacitet och status som subjekt till maskinen. Detta är i min mening inte så onaturligt som det först kan verka, då vi går in i en era där vi så småningom kommer kunna skapa maskiner som har all intellektuell kapacitet nödvändig, och mer därtill, för att bli behandlade just som detta, rättssubjekt.

Det må ta ett tag innan vi börjar behandla maskiner som rättssubjekt men den nuvarande tekniska nivån ger oss ändå maskiner, mer specifikt bilar i vårt exempel, som inom endast några år är tillräckligt autonoma för att klara sig utan översyn av en mänsklig operatör. Dock förefaller läget så vara att tekniken, likt så många gånger tidigare, utvecklas snabbare än lagstiftningen och olyckor så som den i Tempe, får behandlas med sin grund i lagstiftning som inte riktigt är ämnad för den typ av situation som nu kan uppstå. De mest relevanta civilrättsliga regleringarna, här i EU, är de lagar som härstammar från 1984 års produktansvarsdirektiv, i Sverige har detta direktiv lett till produktansvarslagen (PAL).

Oavsett hur rättsutveckling bör eller kommer utvecklas på området är det intressant att utreda frågan utifrån gällande rättsläge för att etablera vad olika aktörer inblandade i branschen kan göra för att främja affärer och innovation. Därav återvänder vi till ansvarsfrågan från perspektivet av biltillverkaren, utvecklaren av datorplattformen, men främst mjukvareutvecklaren.

Biltillverkaren kan bli strikt skadeståndsskyldig för den skadegörande produkten enligt PAL och skulle då vara skyldig att betala skadestånd i den mån skadan orsakats av en säkerhetsbrist i produkten. Dessa typer av situationer behandlas generellt sett kontraktuellt mellan biltillverkaren och dess leverantörer, och ansvaret brukar skjutas över till leverantören i det fall en komponent väsentligen avviker från vad som kunnat förväntas från den eller i den mån den avviker från relevant standard. Jag väljer dock att fokusera på de situationer där skadegörelsen orsakats av bilens artificiella intelligens, som närmast kan anses kopplat till chipplattformen samt mjukvaran därpå. Därav kommer jag även fokusera på de aktörer som är närmast sammanblandade med detta, särskilt det sistnämnda, mjukvaran.

För att en produkt ska täckas av PAL måste den skadegörande produkten vara av fysisk art. Därav täcks inte eventuell programvara som en tillverkare har använt på sin plattform då programvaran snarare räknas som ett intellektuellt alster. Datorplattformstillverkaren kan därför bli strikt ansvarig för en skadelidandes skada i den mån t.ex. bilen orsakat en olycka på grund av att chipet som ”körde” bilen varit felaktigt. Ifall tillverkaren av datorplattformen därutöver levererat sin plattform med ytterligare mjukvara, så som Nvidia med deras produkt NVIDIA DRIVE, täcks däremot inte fel i själva mjukvaran av PAL. Men det vore inte sann juridik utan undantag. Viss mjukvara s.k. firmware är oåtskiljbar från själva hårdvaran. Firmware är mjukvara på den absolut lägsta nivån, ”närmast” chipet, som är integrerad i själva hårdvaran och möjliggör dess styrning. Utan firmware skulle hårdvaran inte fungera överhuvudtaget och räknas därför som en del av hårdvaran. Därav kan skada som orsakats på grund av fel i mjukvara i form av firmware föranleda skadeståndsskyldighet enligt PAL.

En konsument riktar dock troligen sitt anspråk mot biltillverkaren och eventuella regressanspråk mot plattformstillverkaren får istället ske genom avtalad ansvarsfördelning, alternativt köplagens bestämmelser i den mån bestämmelser saknas i kontraktet sinsemellan, mer om detta nedan.

Då programvaran inte är av fysisk art utan ses snarare som ett intellektuellt alster, omfattas inte fel i mjukvaran av PAL, och en konsument kan därför inte direkt rikta anspråk mot den som utvecklat mjukvaran. Detta betyder dock inte att mjukvareutvecklaren automatiskt undgår ansvar, utan snarare att biltillverkaren får kräva regress genom allmänna skadeståndsrättsliga principer, grundat i avtal, eller utifrån köplagen.

Detta gör att ansvarsklausulerna i avtalen mellan mjukvareutvecklare och biltillverkare måste både vara genomtänkta och spegla de intressen de är menade att reglera. Det är inte sällan så att den här typen av avtalsförhållanden kan vara präglade av en obalans gällande förhandlingssituation och makt, då biltillverkarna ofta är stora multinationella bolag, medan mjukvareutvecklare finns i alla dess former. Med detta i baktanke uppkommer frågan gällande hur en mjukvareutvecklare ska hantera risken rörande eventuella stora regressanspråk från en stark kund eller samarbetspartner i form av en biltillverkare?

Det finns ett antal olika tillvägagångssätt som mjukvareutvecklaren kan, och bör, använda sig av för att kontrollera och arbeta med risk i koppling till denna typ av affärsrelation. Först och främst bör mjukvareutvecklaren reglera sin risk genom att i avtal behandla de frågor som är av vikt för denne. Detta kan ta sig form genom klausuler som begränsar ansvar på olika sätt, bl.a. ”hold harmless”- eller skadelösklausuler, genomtänkta och noggranna specificeringar av vad utvecklaren garanterar, klausuler som etablerar begränsningar i skadeståndsskyldigheten, eller dylikt.

Om man dock tar den, inte sällan, skeva maktbalansen i dessa affärsrelationer i beaktning, så kan det möjligen vara lättare sagt än gjort att få in dessa klausuler med en leverantörsvänlig twist i avtalen. I dessa fall är det oerhört viktigt att åtminstone begränsa eventuella inomkontraktuella skadestånd till det tak som stadgas i sin ansvarsförsäkring. I den mån man inte gör detta riskerar man att en före detta affärspartner som nu transformerats till en motpart kommer rikta skadeståndsanspråk på bokstavligt talat varenda tillgång man besitter som har någon form av värde. Lika viktigt är därför också att man tecknar en försäkring som passar bolagets verksamhet och riskprofil.

En annan självklar, men ack så viktig, aktivitet för ett bolag som jobbar med mjukvaruutveckling av AI- produkter eller -tjänster är den, i kontexten, näst intill omöjliga uppgiften att kvalitetssäkra sin mjukvara. Uppgiften kan verka omöjlig då det ligger i mjukvarans själva natur att processa och lära sig av data som den inte nödvändigtvis direkt känner igen baserat på tidigare liknande eller icke-liknande data och mönster. Därav är det viktigt att balansera fördelarna med att få ut en produkt i sin tilltänkta miljö för att eskalera inlärningen och således dess kvalitet med att kvalitetssäkra sin produkt tillräckligt mycket i en säker miljö för att minska risken för oönskade konsekvenser så som olyckor eller annat skadligt beteende.

Alternativa affärsmodeller bör också noggrant analyseras och övervägas för att utreda ifall det finns vägar man som utvecklare kan ta för att ta del av värdeskapandet och samtidigt hålla nere sin risk. Ett exempel skulle kunna vara att utveckla mjukvara integrerad i en större plattformslösning där plattformsskaparen tar merparten av risken. Dock är detta givetvis något som inte kommer fungera i alla former av fall och för all typ av mjukvara.

I det stora hela handlar det om riskavvägning. Detta gäller avtalsskrivningarna likväl som försäkringen och valet av affärsmodell. Juridiken är ett mäktigt verktyg för att arbeta med risk, men bör samtidigt kompletteras med sunda affärsbeslut och affärsmodeller, försäkringar och ständig riskuppföljning.