De afgelopen jaren heeft de Europese wetgever een reeks digitale regelgeving vastgesteld die rechtstreeks van invloed is op aanbieders van SaaS-oplossingen (zoals online platformen). De AVG, de Dataverordening en de Europese AI Act zijn inmiddels bekende namen. Minder bekend, maar zeker zo relevant, is de herziene productaansprakelijkheidsrichtlijn, die in 2026 in het Nederlandse recht wordt geïmplementeerd.
Waar productaansprakelijkheid traditioneel werd geassocieerd met fysieke producten als machines of medische hulpmiddelen, trekt de nieuwe richtlijn software uitdrukkelijk in de werkingssfeer. Dat roept voor SaaS-aanbieders een praktische vraag op: valt mijn SaaS-oplossing hieronder, en wat betekent dat precies voor mijn aansprakelijkheidsrisico?
Waarom SaaS nu onder de productaansprakelijkheidsrichtlijn valt
De oorspronkelijke productaansprakelijkheidsrichtlijn uit 1985 was geschreven voor een wereld van fysieke goederen. Software viel er strikt genomen buiten. De nieuwe richtlijn beoogt daar een einde aan te maken door software uitdrukkelijk als product te definiëren. In overweging 13 van de richtlijn lezen we bovendien dat de leveringsvorm er niet toe doet. Of software nu lokaal draait of via de cloud als SaaS wordt aangeboden, in beide gevallen valt zij in beginsel onder de reikwijdte van de richtlijn. Dat betekent dat wanneer die software schade veroorzaakt, de producent in principe aansprakelijk kan zijn, zonder dat de benadeelde partij schuld hoeft te bewijzen.
De wetgever erkent daarmee dat software vergelijkbare schade kan veroorzaken als een gebrekkig fysiek product. Medische software die een verkeerde diagnose ondersteunt of een beveiligingslek dat tot een datalek leidt, valt dus ook onder de reikwijdte van de richtlijn.
Wat betekent dit concreet voor jouw SaaS-product?
Het meest voor de hand liggende risico zit in de software zelf: een bug die leidt tot letsel of zaakschade kan worden aangemerkt als een productdefect. Maar de reikwijdte van de richtlijn is breder dan programmeerfouten alleen. Ook het uitblijven van noodzakelijke beveiligingsupdates kan bijvoorbeeld meewegen in de beoordeling of een product gebrekkig is. Wie een kwetsbaarheid kent en die niet tijdig verhelpt, loopt het risico dat schade die via dat lek ontstaat, wordt toegerekend.
Daar komt natuurlijk bij dat SaaS zelden een “eenmalige levering” is. Als aanbieder blijf je doorgaans betrokken via updates en doorlopend beheer. Die voortdurende betrokkenheid weegt juridisch mee en de verantwoordelijkheid stopt dus niet zonder meer bij de eerste beschikbaarstelling.
Ook samenhangende diensten spelen een rol. Denk aan hosting of dataopslag die nodig zijn om de software te laten functioneren; die kunnen worden meegewogen in de beoordeling van het product als geheel. De scheidslijn tussen software en dienst wordt daarmee minder scherp.
Data als schadepost
Nieuw is bovendien dat vernietiging of corruptie van data in bepaalde gevallen kan worden meegenomen als schadepost onder de productaansprakelijkheidsrichtlijn. Niet in alle gevallen van dataverlies, want gegevensbescherming blijft primair onder de AVG vallen, maar wel wanneer sprake is van materiële schade als gevolg van een productdefect. Als jouw software door een bug bijvoorbeeld klantdata vernietigt, kan dat onder omstandigheden leiden tot een schadevergoedingsplicht op grond van de richtlijn.
Cybersecurity en de link met de productaansprakelijkheidsrichtlijn
De richtlijn staat niet op zichzelf. Ze vormt een samenhangend geheel met onder andere de Cyber Resilience Act en NIS2. Niet-naleving van cybersecurityverplichtingen kan worden meegewogen bij de beoordeling of sprake is van een productdefect in de zin van de richtlijn. Als bijvoorbeeld niet wordt voldaan aan eisen rond security-by-design, kan dat bijdragen aan het oordeel dat een product niet voldoet aan de veiligheidsverwachtingen die daaraan mogen worden gesteld.
Bewijslast verschuift naar de aanbieder
De nieuwe richtlijn versterkt de positie van de eiser in bewijszaken. Als aannemelijk is dat een softwareproduct gebrekkig was, kan de rechter defect of causaal verband aannemen wanneer sprake is van voldoende complexe technische omstandigheden, zonder dat de eiser hoeft te laten zien hoe het systeem intern precies werkt.
Daarnaast kan de rechter je verplichten om bewijsstukken over te leggen. Doe je dat niet, dan kan hij daaruit gevolgen trekken bij de beoordeling van het geschil. Testresultaten, incident response-logs en technische documentatie kunnen daarbij allemaal relevant zijn in een procedure. Zorgvuldige vastlegging daarvan is dus niet alleen verstandig vanuit operationeel oogpunt, maar ook juridisch van belang.
Contractuele uitsluitingen werken niet
Probeer aansprakelijkheid niet contractueel uit te sluiten. De richtlijn bepaalt namelijk expliciet dat bepalingen die aansprakelijkheid onder de PLD beogen te beperken of uitsluiten, geen effect hebben. SaaS-contracten bieden hier dus geen bescherming.
Wie is er aansprakelijk in de keten?
De richtlijn is erop gericht dat er altijd een aansprakelijke partij in de EU is. Ben je zelf in de EU gevestigd, dan ben jij als fabrikant primair aansprakelijk. Zit je buiten de EU, dan verschuift aansprakelijkheid naar je EU-importeur of gemachtigde vertegenwoordiger.
Voor SaaS-aanbieders is dit vooral relevant wanneer je componenten van derden integreert. Gebruik je bijvoorbeeld een AI-module van een niet-EU-leverancier, dan kan de aansprakelijkheid in bepaalde gevallen bij jou terechtkomen als degene die het product op de markt brengt.
Hetzelfde geldt wanneer je software van een derde partij wezenlijk aanpast voordat je die aan klanten beschikbaar stelt: in dat geval kun je zelf als fabrikant worden aangemerkt. Distributeurs die niet binnen een redelijke termijn kunnen aangeven wie de verantwoordelijke EU-partij is, kunnen bovendien zelf aansprakelijk worden gehouden. Het is daarom essentieel om in de keten steeds duidelijk te kunnen aantonen wie waarvoor verantwoordelijk is.
Wat betekent dit voor open source componenten
Open source software die buiten een commerciële context wordt ontwikkeld en gedeeld, valt in beginsel buiten de richtlijn. Zodra je open source integreert in een commercieel product verandert dat beeld. De verantwoordelijkheid ligt dan bij de partij die het product op de markt brengt. Een defect in een open source library die je gebruikt, kan dus alsnog tot aansprakelijkheid leiden, afhankelijk van je rol in de keten en de wijze waarop het product op de markt is gebracht.
Dat vraagt om zorgvuldig beheer van je softwarecomponenten. Ken je dependencies, monitor kwetsbaarheden en zorg dat je tijdig kunt patchen. Dat de fout in een externe library zit, vormt op zichzelf geen vrijwaring.
AI-systemen die blijven leren
De richtlijn houdt expliciet rekening met AI-systemen die na marktintroductie blijven leren. Als software door machine learning nieuwe eigenschappen ontwikkelt, maakt dat adaptieve gedrag onderdeel uit van de veiligheidsbeoordeling. Het uitgangspunt is dat dat gedrag binnen zekere grenzen voorspelbaar en beheersbaar blijft. Leidt het leerproces tot gevaarlijke uitkomsten die bij een zorgvuldig ontwerp hadden kunnen worden voorkomen, dan kan dat bijdragen aan de kwalificatie als defect.
Dit sluit aan bij de verplichtingen uit de AI Act. Documentatie over intended use, risicobeoordeling en de ingebouwde waarborgen voor lerende systemen is niet alleen een compliancevereiste, maar kan ook worden ingezet als bewijs in aansprakelijkheidskwesties. De overlap tussen AI-governance en productaansprakelijkheid is daarmee aanzienlijk.
Productaansprakelijkheid SaaS: juridische ondersteuning nodig?
Wil je meer weten over de impact van de nieuwe productaansprakelijkheidsregels op jouw SaaS-product, of welke stappen je nu al kunt zetten om je organisatie daarop voor te bereiden? We denken graag met je mee over wat dit concreet betekent in jouw situatie.
