Software wordt een product
Tot voor kort was productaansprakelijkheid iets voor fysieke producten: auto's, speelgoed, machines. De nieuwe EU-productaansprakelijkheidsrichtlijn (Richtlijn (EU) 2024/2853) verandert dat fundamenteel. Software — van mobiele apps tot bedrijfssoftware, van SaaS-platformen tot AI-systemen — is nu expliciet een product. En daarmee valt het onder dezelfde aansprakelijkheidsregels als elk ander product op de Europese markt.
De oude richtlijn stamde uit 1985, lang voordat software alomtegenwoordig was. De herziene versie sluit aan bij een wereld waarin software niet alleen overal aanwezig is, maar ook schade kan veroorzaken: dataverlies, beveiligingslekken, foutieve beslissingen door AI-systemen.
Wat valt eronder?
De richtlijn is breed geformuleerd en technologieneutraal. Het begrip "product met digitale elementen" omvat:
- Standalone software — desktop-applicaties, mobiele apps, firmware
- SaaS en cloud-diensten — expliciet opgenomen, ongeacht of de software lokaal draait of in de cloud
- AI-systemen — apart benoemd, met een directe koppeling aan de EU AI Act
- Maatwerksoftware — als het wordt gebouwd in het kader van een commerciële activiteit
- Software-updates — worden als onderdeel van het product behandeld
Niet-commerciële open-source software valt er buiten, maar zodra open-source componenten deel uitmaken van een commercieel product, is de fabrikant aansprakelijk voor het geheel.
Wat is een gebrek?
Software is gebrekkig als het niet de veiligheid biedt die het publiek redelijkerwijs mag verwachten. Dat klinkt abstract, maar de richtlijn maakt het concreet. Er wordt gekeken naar:
- Hoe het product wordt gepresenteerd en op de markt gebracht
- Het redelijkerwijs te verwachten gebruik
- Geldende technische normen en regelgeving — waaronder de cybersecurity-eisen uit de Cyber Resilience Act
- Of noodzakelijke updates en patches zijn geleverd
Dat laatste punt is cruciaal: het niet leveren van beveiligingsupdates is een gebrek. Als er een kwetsbaarheid wordt ontdekt en de fabrikant levert geen patch, kan dat leiden tot aansprakelijkheid voor alle schade die daaruit voortvloeit.
Niet patchen is niet langer een keuze. Het is een aansprakelijkheidsrisico.
Bewijslast verschuift
Een van de grootste veranderingen zit in de bewijslast. Bij de oude richtlijn moest het slachtoffer bewijzen dat het product gebrekkig was én dat dit gebrek de schade veroorzaakte. Bij software en AI is dat vaak technisch onmogelijk — je kunt niet in de broncode kijken.
De nieuwe richtlijn introduceert twee mechanismen:
Vermoeden van gebrekkigheid
Als de fabrikant weigert bewijs te verstrekken na een rechterlijk bevel — bijvoorbeeld broncode, testresultaten of interne documentatie — mag de rechter aannemen dat het product gebrekkig is. Dit dwingt ontwikkelaars om transparant te zijn over hun ontwikkelproces.
Bewijslastverlichting bij complexe producten
Bij technisch complexe producten zoals software en AI-systemen kan de rechter gebrekkigheid en causaliteit vermoeden als bewijs leveren "buitensporig moeilijk" is voor het slachtoffer. Het slachtoffer hoeft dan alleen aannemelijk te maken dat het waarschijnlijk is — de fabrikant moet het tegendeel bewijzen.
Bredere schadecategorieën
De oude richtlijn beperkte schadevergoeding grotendeels tot lichamelijk letsel en fysieke zaakschade. De nieuwe richtlijn breidt dit uit:
- Dataverlies — vernietiging of corruptie van persoonlijke data is nu compenseerbaar
- Psychisch letsel — mits medisch erkend en gecertificeerd
- Geen maximumlimiet meer — het optionele plafond uit de oude richtlijn is geschrapt
- Geen drempel van €500 meer — in Nederland gold een franchise van €500 voor zaakschade; die wordt afgeschaft
De verjaringstermijn blijft 3 jaar na ontdekking van de schade, maar de absolute vervaltermijn wordt verlengd tot 25 jaar voor sluipende gezondheidsschade (was 10 jaar).
Wie is aansprakelijk bij maatwerk?
Net als bij de Cyber Resilience Act draait het om de vraag: wie brengt het product op de markt?
Als je maatwerksoftware laat bouwen door een extern bureau en het product onder jouw naam aanbiedt aan klanten of gebruikers, ben jij als opdrachtgever de fabrikant. Jij bent dan aansprakelijk voor schade die het product veroorzaakt.
Belangrijk: je kunt deze aansprakelijkheid niet contractueel uitsluiten jegens gedupeerden. Clausules die dat proberen zijn nietig. Wat je wél kunt doen is intern regresafspraken maken met je softwareleverancier — zodat je de schade kunt verhalen als het gebrek bij de bouwer ligt.
Voor softwarebureaus geldt: wie een bestaand product substantieel wijzigt (bijvoorbeeld met een grote update), wordt zelf als fabrikant beschouwd voor die wijziging.
Aansprakelijkheid wegcontracteren kan niet. Intern regres afspreken wel. Zorg dat je contracten daarop zijn ingericht.
Samenhang met CRA en AI Act
De productaansprakelijkheidsrichtlijn staat niet op zichzelf. Samen met de Cyber Resilience Act en de AI Act vormt het een geïntegreerd Europees kader:
- CRA — stelt verplichte cybersecurity-eisen voor digitale producten. Niet voldoen aan de CRA leidt tot een weerlegbaar vermoeden van gebrekkigheid onder de PLD
- AI Act — reguleert AI-systemen op basis van risico. Aanbieders van AI-systemen worden als fabrikant beschouwd onder de PLD
- PLD — biedt het vangnet: als de preventieve regelgeving (CRA, AI Act) niet heeft voorkomen dat er schade ontstaat, biedt de PLD de gedupeerde een route naar schadevergoeding
In de praktijk betekent dit: wie voldoet aan de CRA en AI Act is beter beschermd tegen productaansprakelijkheidsclaims. Maar het is geen garantie — de PLD kijkt naar het resultaat (was er schade?), niet alleen naar het proces.
De tijdlijn
- 18 november 2024 — Publicatie in het EU Publicatieblad
- 27 februari 2026 — Wetsvoorstel naar de Tweede Kamer (Nederland)
- 9 december 2026 — Deadline voor omzetting in nationaal recht door alle EU-lidstaten
De regels gelden alleen voor producten die ná 9 december 2026 op de markt worden gebracht. Software die je vandaag levert, valt nog onder het huidige regime. Maar alles wat je na die datum oplevert — inclusief substantiële updates van bestaande software — valt onder de nieuwe regels.
Nederlandse implementatie
In Nederland wordt de richtlijn omgezet via de Implementatiewet richtlijn herziening productaansprakelijkheid, die Boeken 6 en 7 van het Burgerlijk Wetboek wijzigt. Het wetsvoorstel is op 27 februari 2026 naar de Tweede Kamer gestuurd.
Enkele Nederlandse keuzes: de franchise van €500 voor zaakschade wordt geschrapt, Nederland maakt geen gebruik van de optionele mogelijkheid om een nationaal schadefonds op te richten, en verzekeraars krijgen een gemakkelijkere regresbasis op fabrikanten.
Wat je nu moet doen
- Herzie je contracten — Zorg dat opdrachtovereenkomsten met softwareleveranciers regresclausules bevatten voor productaansprakelijkheid. Wie is verantwoordelijk voor updates na oplevering?
- Documenteer je ontwikkelproces — Bij een claim moet je mogelijk bewijs overleggen. Zorg dat testresultaten, code reviews en security-audits zijn vastgelegd
- Richt een updatebeleid in — Leg contractueel vast wie verantwoordelijk is voor beveiligingsupdates, en voor hoe lang
- Check je verzekering — Dekt je beroeps- of productaansprakelijkheidsverzekering ook software? Veel traditionele polissen doen dat niet
- Ken je componenten — Weet welke open-source en third-party componenten in je software zitten. Jij bent als fabrikant aansprakelijk voor het geheel
Hoe Coding Agency hiermee omgaat
Bij Coding Agency is zorgvuldig bouwen geen optie maar de standaard. Concreet:
- Wij documenteren ons ontwikkelproces: code reviews, testresultaten en security-audits zijn standaard onderdeel van elk project
- Wij hanteren een security-by-design aanpak met dependency scanning en geautomatiseerde beveiligingstests
- Wij adviseren over de contractuele verdeling van verantwoordelijkheden bij oplevering en onderhoud
- Wij bieden onderhoudscontracten die aansluiten op de langetermijnverplichtingen van de nieuwe richtlijn
De nieuwe productaansprakelijkheidsrichtlijn is geen revolutie voor wie al zorgvuldig bouwt. Het is een bevestiging: software die je op de markt brengt, moet veilig zijn. En als er toch iets misgaat, moet je kunnen laten zien dat je er alles aan gedaan hebt.
Conclusie
Vanaf december 2026 is software een product met alle juridische consequenties van dien. De bewijslast verschuift, schadecategorieën worden breder en aansprakelijkheid is niet weg te contracteren. Voor opdrachtgevers betekent dit: kies een leverancier die zijn beveiligingsprocessen op orde heeft en zorg dat je contracten de nieuwe realiteit weerspiegelen. Heb je vragen over wat de richtlijn voor jouw situatie betekent? Neem contact op — we denken graag mee.
