Kernepåstand: Den 9. december 2026 begynder EU’s reviderede produktansvarsdirektiv at gælde for software, der bringes i omsætning — og fordi direktivet belønner producenter, der kan dokumentere, hvordan produktet blev bygget, er parathed ikke en papirøvelse, man kan klare i den sidste uge af november: den historik, man får brug for, er den, man begynder at føre nu.

Hvad der faktisk sker den 9. december

Direktiv (EU) 2024/2853 gør software — selvstændig, indlejret eller leveret som SaaS — til et “produkt” i EU’s produktansvarsret. Medlemsstaterne skal gennemføre direktivet senest 9. december 2026, og det gælder for produkter, der bringes i omsætning eller tages i brug fra den dato; produkter, der allerede er på markedet, forbliver under den gamle ordning fra 1985. I Danmark er gennemførelsen i gang: Justitsministeriet sendte et lovudkast til ny produktansvarslov i høring i januar 2026, og lovforslaget ligger nu i Folketingets Retsudvalg.

Én afgrænsning først, for den afgør, hvordan direktivet når jer. PLD kompenserer fysiske personer: død, personskade, skade på ejendom, der anvendes privat, og ødelæggelse eller korruption af data, der ikke udelukkende bruges erhvervsmæssigt. Det er ikke en generel B2B-erstatningsordning — en erhvervskunde får ikke et nyt PLD-krav mod sin softwareleverandør. For B2B-softwarehuse kommer direktivet indirekte, men konkret: gennem produkter, der møder forbrugerkrav, med regres tilbage op gennem leverandørkæden til komponent- og softwareleverandørerne — og gennem den bevisstandard, det sætter for, hvordan en dokumenteret udviklingsproces ser ud, når en domstol først begynder at spørge.

To egenskaber ved den nye ordning betyder noget for alle, der leverer software. For det første er ansvaret objektivt — der skal ikke påvises uagtsomhed, når et defekt produkt forvolder skade inden for dette anvendelsesområde, og “skade” omfatter nu også ødelæggelse eller korruption af (ikke-erhvervsmæssige) data. For det andet er bevismekanikken ændret: en domstol kan pålægge producenten at fremlægge “nødvendig og forholdsmæssig” dokumentation om produktet, og efterkommer producenten ikke pålægget, formodes produktet at være defekt. Kort sagt: fra december argumenterer det hold, der ikke kan vise sit arbejde, fra den tabende position.

Tjeklisten

Halvfems dage er nok til at blive klar — hvis tiden bruges på at skabe evidens frem for at formatere dokumenter. Listen her er en teknisk parathedsliste, ikke juridisk rådgivning; vurderingen af jeres konkrete eksponering hører hjemme hos advokaten.

  1. Lav inventar over, hvad I bringer i omsætning. Alle produkter med software i, inklusive SaaS og software leveret som opdateringer. Skæringsdatoen 9. december løber produkt for produkt, ikke firma for firma.
  2. Kend jeres AI-andel. Hvilke komponenter, features og ændringer er skrevet eller medskrevet af AI-værktøjer — og under hvis review? “Det ved vi ikke” er det svagest mulige svar på et fremlæggelsespålæg — og det ærlige svar i de fleste kodebaser i dag.
  3. Start en samtidig udviklingshistorik. Hvem ændrede hvad, hvilket review passerede det, hvilke tests kørte det imod — registreret på ændringstidspunktet, append-only, verificerbart af tredjepart. Dette er det ene punkt på listen, der ikke kan laves bagudrettet.
  4. Gør review-processen reel og synlig. Et review, der fandt sted, men ikke efterlod sig spor, opfører sig i en fremlæggelsessituation som et review, der ikke fandt sted.
  5. Bind test-evidens til releases. For hver version, der bringes i omsætning, skal I kunne sige, hvilke tests der kørte, hvornår og med hvilket resultat — ikke som et CI-dashboard, der udløber, men som en historik, der overlever værktøjerne.
  6. Før teknisk dokumentation pr. release. Cyber Resilience Acts indberetningspligter begynder 11. september 2026, og dens dokumentationskrav peger samme vej som PLD: en SBOM, en beskrevet og dokumenteret udviklingsproces og et sårbarhedsspor.
  7. Tjek jeres komponent-oprindelse. Tredjeparts- og open source-komponenter har deres egen ansvarshistorie under direktivet; fri og open source-software leveret uden for kommerciel aktivitet ligger uden for direktivets anvendelsesområde — men i det øjeblik den indgår i jeres produkt, er dens oprindelse jeres problem.
  8. Øv fremlæggelsesspørgsmålet. Giv en udvikler én time og spørgsmålet “vis mig, hvordan release X blev bygget, reviewet og testet.” Er svaret et skuldertræk, en wiki-side fra 2024 og tre Slack-tråde, har I fundet jeres hul, mens det stadig er billigt.

Derfor slår september november

Punkterne ovenfor deler sig skarpt i to. Formateringsøvelser — inventaret, dokumentationsstrukturen — kan komprimeres; dem kan man tage i en sprint, når det passer. Evidens kan ikke komprimeres. En udviklingshistorik startet i september beviser tre måneders reel historie ved skæringsdatoen; én startet ugen før beviser en uge — og en historik rekonstrueret bagefter beviser ingenting, for oprindelse er det ene i software, man ikke kan reparere med tilbagevirkende kraft. Direktivets egne indsigelsesmuligheder peger samme vej: udviklings- risiko-indsigelsen afhænger af, hvad man vidste og kontrollerede på tidspunktet — præcis det, kun en samtidig historik kan fastslå.

Halvfems dage før skæringsdatoen er spørgsmålet ikke, om I kan nå at skrive dokumenterne. Det er, om jeres kodebase den 9. december har en historik — eller bare en historie.

Kilder