Vem bär ansvaret när programvaran är produkten

Frågan kommer oftast som en oro hos den som byggt eller köpt något med AI i: gör den nya produktansvarslagen oss ansvariga för vad systemet gör. För den som har köpt ett verktyg och använder det är svaret nej. Ansvaret ligger hos den som tillverkat produkten, och den som bara använder någon annans programvara är inte tillverkare. Och ordet artificiell intelligens står inte i de bestämmelser som bär det ansvaret. De säger programvara.

Det är däremot inte hela bilden, och gränsen ligger inte där de flesta letar efter den. Den går inte mellan intern och extern användning, och inte heller vid om programvaran kallas AI. Den går mellan att använda någon annans produkt och att ha byggt sin egen, och därefter vid två saker: om produkten fortfarande står under tillverkarens kontroll, och om någon har ändrat den väsentligt.

Det är en lagrådsremiss och ännu inte en lag

Regeringen beslutade lagrådsremissen En ny produktansvarslag vid regeringssammanträdet torsdagen den 13 augusti 2026, ärende I:3, diarienummer Ju2025/02091, med Johan Forssell som föredragande statsråd och Justitiedepartementet som ansvarigt departement. Den publicerades på regeringen.se en vecka senare, den 20 augusti, vilket är det datum som oftast citeras. Underlaget är SOU 2025:103 och bakom båda ligger direktiv (EU) 2024/2853.

En lagrådsremiss är ett utkast som skickas till Lagrådet för granskning. Det finns ingen proposition och ingen antagen lag. Lagen föreslås träda i kraft den 9 december 2026, och produktansvarslagen (1992:18) upphöra samma dag. Datumet är inte valt fritt. Direktivets artikel 22.1 ålägger medlemsstaterna att sätta i kraft de bestämmelser som behövs senast den 9 december 2026, och artikel 2.1 säger att direktivet ska tillämpas på produkter som släppts ut på marknaden eller tagits i bruk efter samma dag.

Paragrafnumren nedan är lagrådsremissens. Utredningen hade en annan indelning, så en hänvisning hämtad ur SOU:n pekar på fel bestämmelse i den föreslagna lagen.

Programvaran är produkten

Definitionen står i 1 kap. 3 § och är kort: med produkt avses "en lös sak eller en programvara, även om den är integrerad i eller sammankopplad med lös eller fast egendom", samt en digital fil som innehåller informationen som krävs för att tillverka en produkt automatiserat. Direktivets artikel 4.1 räknar i samma anda upp att "i produkter ingår el, digitala tillverkningsfiler, råvaror och programvara".

Fristående programvara är alltså en produkt. Det behövs ingen maskin omkring den, ingen fysisk leverans och ingen hårdvara. En applikation är en produkt på samma sätt som en borrmaskin.

Ordet artificiell intelligens står inte i de bestämmelser som citeras här. Det som binder AI till regelverket ligger på två andra ställen. Utredningens motivering namnger tillämpningen uttryckligen: utvidgningen omfattar "fristående mjukvara (t.ex. en applikation till en dator eller en smarttelefon och ett program som tillhandahåller artificiell intelligens)". Och lagtexten själv beskriver egenskapen utan att namnge tekniken. Bland det som säkerheten ska bedömas mot står i 2 kap. 2 § punkt 4 "inverkan på produkten av en förmåga hos produkten att fortsätta lära sig eller förvärva nya egenskaper efter att den har släppts ut på marknaden eller tagits i bruk".

Bestämmelserna behöver aldrig säga AI, eftersom de i stället skriver in att produkten fortsätter att lära sig.

Direktivets skäl 13 är rakare än någon av bestämmelserna och bör läsas av den som tror att leveransformen räddar någon. Programvara är en produkt "irrespective of whether the software is stored on a device, accessed through a communication network or cloud technologies, or supplied through a software-as-a-service model", och "a developer or producer of software, including AI system providers within the meaning of Regulation (EU) 2024/1689 of the European Parliament and of the Council, should be treated as a manufacturer". Samma skäl drar också en gräns åt andra hållet: information är inte en produkt, och reglerna träffar därför inte innehållet i digitala filer eller programvarans källkod i sig.

Den punkten gör något ovanligt. Produktansvar har alltid utgått från att produkten är densamma efter leverans som vid den, och att en brist därför fanns eller inte fanns vid ett bestämt tillfälle. Punkt 4 accepterar i stället att produkten förändrar sig själv, och lägger den förändringen bland det som bedömningen ska ta hänsyn till.

Tillverkare är också den som bygger för eget bruk

Ansvaret är knutet till roller, och rollerna räknas upp i 3 kap. 1 §. Först i listan står tillverkaren av den skadegörande produkten. Vem det är definieras i 1 kap. 4 §: tillverkare är den som "tillverkar, framställer eller utvecklar en produkt", den som låter tillverka eller utforma en produkt, eller den som genom att sätta sitt namn, varumärke eller annat kännetecken på produkten utger sig för att vara den som tillverkat den.

Ordet utvecklar bär mer än det ser ut att göra. Det finns inget krav i definitionen på att produkten säljs, licensieras eller ens lämnar organisationen. Den som bygger en programvara har utvecklat en produkt.

Nästa led stänger dörren som annars hade stått öppen. Enligt 3 kap. 5 § första stycket 1 går en tillverkare eller importör fri som visar att denne "inte har släppt ut produkten på marknaden eller tagit den i bruk". Ibruktagande definieras i 1 kap. 4 § som "den första användningen av en produkt inom EES som ett led i en näringsverksamhet, om produkten dessförinnan inte har släppts ut på marknaden". Att sätta sin egenutvecklade programvara i drift i verksamheten är alltså ett ibruktagande, och ansvarsfriheten i punkt 1 gäller då inte.

Listan i 3 kap. 1 § slutar inte vid tillverkaren. Punkt 2 gör tillverkaren av en komponent ansvarig, när komponenten integrerats i eller sammankopplats med produkten inom komponenttillverkarens kontroll och säkerhetsbristen i produkten beror på en brist i komponenten. Den som säljer en modell, ett bibliotek eller ett gränssnitt som byggs in i någon annans produkt står i den positionen, och den är varken användarens eller den färdiga produktens tillverkares. Punkterna 3 och 4 lägger ansvar på importören, på tillverkarens representant och i sista hand på en leverantör av distributionstjänster, när tillverkaren är etablerad utanför EES.

Skillnaden mellan att köpa och att bygga är därför större än skillnaden mellan att använda internt och att sälja. Ett bolag som köper en modell och kör den i egen drift använder någon annans produkt. Ett bolag som utvecklar samma funktion självt och sätter den i drift är tillverkare av sin egen.

Vem som kan kräva, och för vad

Rollen är en sak och exponeringen en annan, och den andra är snävare än den första. Lagens tillämpningsområde står i 1 kap. 1 §: den gäller "ansvar för skador som en fysisk person har orsakats på grund av en säkerhetsbrist i en produkt". Den skadelidande är alltså en människa, och ett bolag får ingen ersättning för sin egen skada. Det betyder inte att motparten alltid är en enskild. Direktivets artikel 5.2 låter anspråket föras även av "a person that succeeded, or was subrogated, to the right of the injured person", vilket är den väg ett försäkringsbolag normalt kommer in.

Vad som ersätts står i 2 kap. 1 § och är tre poster. Personskada, utan förbehåll. Sakskada, men bara "på egendom som inte användes uteslutande för yrkesmässiga ändamål". Och ren förmögenhetsskada "på grund av förlust eller förvanskning av data som användes uteslutande för personliga ändamål".

Det ger tillverkarrollen en bestämd form för den som byggt något för eget bruk. Ett internt system vars fel bara förstör bolagets egen yrkesmässiga utrustning och bolagets egna yrkesmässiga data bär ingen skadeståndsskyldighet enligt lagen alls, hur illa det än går. Det system vars fel kan skada en människa gör det. Och människor finns i fler system än man först tänker sig: den som arbetar vid maskinen, patienten, resenären, besökaren.

Direktivets artikel 6 drar gränserna på samma ställen men inte med samma ord. Sakskadan undantar där "egendom som uteslutande används för yrkesmässiga ändamål", och dataposten täcker "förstörelse eller förvanskling av data som inte används för yrkesmässiga ändamål". Den svenska lydelsen kräver i stället att datan användes uteslutande för personliga ändamål. Det är två olika sätt att avgränsa samma post.

Kontrollen upphör inte vid leveransen

Nästa bestämmelse avgör när klockan stannar. Uttrycket tillverkarens kontroll definieras i 1 kap. 4 § som den kontroll tillverkaren anses ha genom att integrera, sammankoppla eller tillhandahålla en komponent, genomföra ändringar eller samtycka till att någon annan gör det, eller genom att "ha möjlighet att själv eller genom någon annan tillhandahålla uppdateringar eller uppgraderingar av en programvara".

Möjligheten räcker. Inte att uppdateringar faktiskt skickas, utan att de kan skickas. En molntjänst som kan patchas i morgon står under tillverkarens kontroll i dag, och en produkt som fortfarande står under kontroll har inte passerat den tidpunkt som annars begränsar ansvaret.

Det syns tydligast i undantagen. Enligt 3 kap. 5 § första stycket 3 går en tillverkare eller importör fri som gör sannolikt att säkerhetsbristen "inte fanns när produkten släpptes ut på marknaden eller togs i bruk". Men andra stycket tar tillbaka det undantaget om bristen beror på "produktens programvara eller en tillhörande tjänst och produkten var inom tillverkarens kontroll när säkerhetsbristen uppstod", eller på en väsentlig ändring som gjordes inom tillverkarens kontroll.

Här skiljer sig de två texterna i lydelse. Direktivets artikel 11.2 har fyra punkter: en tillhörande tjänst, programvara inbegripet uppdateringar, "avsaknad av uppdateringar eller uppgraderingar av programvara som är nödvändiga för att upprätthålla säkerheten", och en väsentlig ändring. Den svenska bestämmelsen har två. Avsaknaden av uppdateringar står inte som en egen punkt där. Att den fångas ändå, genom att kontrollen enligt 1 kap. 4 § består så länge möjligheten att tillhandahålla uppdateringar finns, är en läsning och inte något lydelsen själv slår fast. Skillnaden är i uppställning, och den som bygger sitt resonemang på direktivets fyra punkter bör veta att den svenska lydelsen räknar annorlunda.

Den som ändrar byter plats med tillverkaren

Den bestämmelse som flyttar ansvaret mellan företag är 3 kap. 4 §. Den lyder att om en produkt efter att den släppts ut på marknaden eller tagits i bruk "väsentligen har ändrats utanför tillverkarens kontroll och därefter tillhandahållits på marknaden eller tagits i bruk, är den som har gjort ändringen skadeståndsansvarig enligt 1 § 1". Direktivets artikel 8.2 säger samma sak med ett annat verb: den som gör det "ska betraktas som tillverkare".

Två villkor måste vara uppfyllda samtidigt, och det andra glöms lätt. Ändringen ska vara gjord utanför tillverkarens kontroll, och produkten ska därefter ha tillhandahållits på marknaden eller tagits i bruk. Båda de uttrycken är definierade. Ibruktagande förutsätter enligt 1 kap. 4 § att produkten dessförinnan inte har släppts ut på marknaden, så en ändring av något ni har köpt och som stannar inne i huset träffar inte det ledet. En programvara ni har utvecklat själva och först sätter i drift gör det.

Vad som är väsentligt avgörs i två steg. Följer det av lag eller andra föreskrifter om produktsäkerhet är saken klar. Saknas sådana föreskrifter för produkten krävs i stället två saker på en gång: att ändringen "förändrar produktens prestanda, ändamål eller typ på ett sätt som inte kunnat förutses vid den riskbedömning som gjordes vid tillverkningen av den ursprungliga produkten", och att den "medför att riskens art förändras, att en ny risk uppstår eller att risknivån höjs".

Den som ändrar väsentligt och sedan lämnar produkten vidare står som tillverkare.

Det andra ledet i prövningen hänger alltså på en riskbedömning som någon annan gjorde vid tillverkningen. Är den bedömningen vid, och dokumenterad, ryms mycket inom det förutsedda. Är den smal eller obefintlig blir tröskeln lägre för alla som rör produkten efteråt. Det finns en lättnad för den som hamnat i rollen: enligt 3 kap. 5 § första stycket 8 går den ansvarige fri om säkerhetsbristen avser en del av produkten som inte påverkas av ändringen. Den lättnaden är inte svensk utan kommer ur direktivets artikel 11.1 g, så den finns i varje medlemsstat.

Invändningen som väger

Det finns ett motsatt förhållande som talar för att göra ingenting alls, och det ska sägas rakt ut.

Förslaget är en lagrådsremiss. Lagrådet ska yttra sig, en proposition ska skrivas, och riksdagen ska besluta. Och övergångsbestämmelsen är generös: "Den upphävda lagen gäller dock fortfarande för produkter som har släppts ut på marknaden eller tagits i bruk före ikraftträdandet." Allt som redan är levererat ligger alltså kvar under 1992 års lag. En läsare med en befintlig portfölj kan med fog fråga vad som brådskar, och svaret för den som varken planerar att släppa ut eller ta i bruk något nytt är att ingenting brådskar.

Tre saker talar ändå emot att skjuta upp frågan. Det bärande datumet står i direktivet och inte i den svenska processen, så det flyttas inte av att riksdagens kalender blir trång. Prövningen av väsentlig ändring vilar på den ursprungliga riskbedömningens vidd, vilket betyder att kvaliteten på en bedömning som görs i dag avgör hur stort utrymme ni och era kunder har att ändra produkten sedan. Och den fråga som avgör allt det andra, alltså vilken av er programvara ni har byggt själva och vilken ni har köpt, är en inventeringsfråga och inte en juridisk fråga.

De två frågorna som avgör om det här är er fråga

Innan de två frågorna ligger en som avgör om någon av dem spelar roll: kan det här systemets fel skada en människa, eller bara er egen yrkesmässiga utrustning och era egna yrkesmässiga data. Är svaret det senare finns ingen skadeståndsskyldighet enligt den här lagen att bära.

Den första frågan är om ni har byggt programvaran eller köpt den. Använder ni någon annans produkt är ni inte tillverkare av den, och ansvaret följer den som är det. Har ni utvecklat den själva är ni tillverkare även om den aldrig säljs, och den första driftssättningen i verksamheten är det ibruktagande som stänger ansvarsfriheten i 3 kap. 5 § första stycket 1. Bygger ni vidare på någon annans programvara och lämnar resultatet vidare är det 3 kap. 4 § som gäller, och inte er egen uppfattning om hur stor ändringen var.

Den andra frågan är hur brett den ursprungliga riskbedömningen var skriven. Den avgör tröskeln i båda riktningarna. Är ni tillverkare skyddar en vid och dokumenterad bedömning er mot att kundens anpassningar räknas som oförutsedda. Är ni den som anpassar avgör samma dokument om er ändring ryms i det förutsedda eller lyfter er in i tillverkarens roll. Två företag som gör exakt samma tekniska ingrepp kan därför få olika svar, beroende på vad leverantören skrev ned innan produkten lämnade huset.

Det finns en tredje fråga som inte handlar om lagen utan om er egen lista: vilka av era system ni har byggt, vilka ni har köpt, vilka ni har ändrat i och hur mycket. Utan den listan går ingen av de två första frågorna att besvara. Hur den byggs och vem som äger den efteråt står under AI governance och regelefterlevnad. Vem som fattar besluten om systemen när de väl är listade behandlas i vår analys om vem som ansvarar för AI-besluten, och kalendern för AI-förordningen, som är ett annat och redan antaget regelverk, står på vår sida om AI-förordningen.