Het Europese productaansprakelijkheidsrecht wordt stilzwijgend maar fundamenteel hervormd. Software, AI‑systemen en open‑source‑componenten verschuiven van de periferie naar de juridische kern van wat als “product” wordt aangemerkt, terwijl cyberbeveiliging en levenscyclusbeheer onderdeel worden van de gebrekenanalyse. Voor management en engineeringteams betekent dit dat software‑samenstelling, het gebruik van open source en SBOM niet langer louter technische housekeeping zijn, maar deel uitmaken van het aansprakelijkheidsmodel.
Van analoge producten naar software en AI
De nieuwe Productaansprakelijkheidsrichtlijn (EU) 2024/2853 vervangt het kader uit 1985 en moet uiterlijk op 9 december 2026 in nationaal recht zijn omgezet. De kern van risicoaansprakelijkheid (schuldonafhankelijke aansprakelijkheid) voor gebrekkige producten blijft behouden, maar het begrip “product” en “gebrek” wordt aanzienlijk verbreed om rekening te houden met verbonden, updatebare en lerende digitale technologieën.
Software wordt nu uitdrukkelijk in de productdefinitie opgenomen, ongeacht vorm of leveringsmodel: lokale uitvoerbare bestanden, gedownloade apps, firmware, cloud‑diensten en SaaS‑modellen worden allemaal als producten behandeld. De richtlijn brengt daarnaast “digitale constructiegegevens”, zoals CAD‑bestanden die 3D‑printers aansturen, en functioneel essentiële “verbonden digitale diensten” onder de aansprakelijkheidsregeling door deze als componenten te kwalificeren. Verder schrijft zij voor dat rechters bij de beoordeling van de gebrekkigheid moeten meewegen of een product voldoet aan de toepasselijke veiligheids- en cyberbeveiligingsvereisten van het Unierecht en het nationale recht.
Het Duitse ontwerp‑Productaansprakelijkheidswet volgt deze structuur. Het breidt de reikwijdte van de bestaande ProdHaftG uit naar software, data en digitale componenten, schrapt het eerdere totale aansprakelijkheidsplafond en het eigen risico voor zaakschade en verruimt de kring van aansprakelijke actoren tot importeurs, gemachtigden, fulfilmentdienstverleners, bepaalde platforms en partijen die producten wezenlijk wijzigen. Vanuit engineeringperspectief betekent dit dat “pure” softwareproducten, complexe digitale stacks en gemengde hardware‑software‑systemen alle onder één technologieneutraal aansprakelijkheidskader vallen.
AI‑systemen, verbonden diensten en de rol van controle
AI‑systemen worden behandeld als een specifieke subcategorie van softwareproducten; in de considerans wordt expliciet naar AI‑systemen verwezen om te onderbouwen waarom software door de nieuwe regels moet worden bestreken. De richtlijn probeert AI niet opnieuw te definiëren – dat is de taak van de AI‑verordening – maar koppelt juridische verwachtingen aan kenmerken die software‑engineers onmiddellijk herkennen.
Ten eerste wordt het leervermogen van een product juridisch relevant. Bij de beoordeling of een product gebrekkig is, moeten rechters rekening houden met de effecten van het vermogen van het product om na het in de handel brengen te leren of nieuwe functies te verwerven. Dat is geen ontsnappingsclausule voor “onvoorspelbare” machine‑learning‑systemen; in feite werkt het omgekeerd doordat duidelijk wordt gemaakt dat leerprocessen zó moeten worden ontworpen en gemonitord dat gevaarlijk emergent gedrag wordt voorkomen.
Ten tweede wordt de wisselwerking met andere producten en componenten expliciet onderdeel van de veiligheidsbeoordeling. Gezien de prevalentie van microservices, API’s en gelaagde stacks richt de richtlijn zich op “redelijkerwijs te voorziene” combinaties en interacties in plaats van op een statisch beeld van geïsoleerde apparaten. Dit sluit nauw aan bij de technische realiteit: storingen ontstaan vaak op integratiepunten, niet binnen een enkel, scherp afgebakend component.
Ten derde wordt cyberbeveiliging verheven van achtergrondzorg tot expliciet element van productveiligheid. Indien dwingende cyberbeveiligingsvereisten – bijvoorbeeld onder de CRA of sectorspecifieke regelgeving – niet worden nageleefd, zal het product in de regel als gebrekkig in de zin van het productaansprakelijkheidsrecht worden aangemerkt. Omgekeerd leidt naleving van die vereisten niet automatisch tot uitsluiting van aansprakelijkheid, maar vormt zij een belangrijk referentiepunt voor wat als “stand van de techniek” geldt.
Verbonden digitale diensten illustreren deze ideeën bijzonder goed. De richtlijn behandelt diensten die zodanig in of met een product zijn geïntegreerd dat het product zonder die diensten één of meer functies niet kan vervullen en die onder de “controle” van de fabrikant staan – doordat hij ze integreert of goedkeurt – als componenten. Typische voorbeelden zijn cloud‑gebaseerde navigatiedata, gezondheidsmonitoringdiensten gekoppeld aan wearables of spraakassistenten die apparaten aansturen. Als zo’n dienst foutieve data of gebrekkige logica levert die tot schade leidt, kunnen zowel de dienstverlener als de eindproductfabrikant risicoaansprakelijk zijn, zelfs wanneer het gebrek uitsluitend in de dienst zelf is gelegen. Voor systeemarchitecten formaliseert dit de intuïtieve notie dat verantwoordelijkheid de controle over de architectuur en de keuze van afhankelijkheden volgt.
Open source: beschermde communities, verantwoordelijke integrators
Het nieuwe regime hanteert een genuanceerde benadering van open‑sourcesoftware. Enerzijds sluit de richtlijn “vrije en open‑sourcesoftware die buiten de uitoefening van een commerciële activiteit wordt ontwikkeld of geleverd” van haar werkingssfeer uit. Het Duitse ontwerp neemt deze benadering over en verduidelijkt in de memorie van toelichting dat non‑profit‑stichtingen, academische instellingen en communityprojecten die code beschikbaar stellen zonder commerciële doeleinden na te streven, niet worden geacht producten in de handel te brengen in de zin van de productaansprakelijkheid. Deze carve‑out is bedoeld om afschrikwekkende effecten op vrijwilligersgedreven open‑source‑ecosystemen te vermijden.
Anderzijds is deze bescherming strikt beperkt tot die niet‑commerciële laag. Zodra een onderneming open source in haar eigen product integreert in het kader van een commerciële activiteit – bijvoorbeeld door licenties te verkopen, software met hardware te bundelen, een SaaS‑oplossing te bieden of gebruikersdata te gelde te maken – wordt zij de fabrikant van het totale product en draagt zij risicoaansprakelijkheid voor gebreken, inclusief gebreken die voortkomen uit OSS‑componenten. Er is geen juridische route om risicoaansprakelijkheid door te schuiven naar niet‑commerciële OSS‑auteurs, die per definitie buiten het productaansprakelijkheidsstelsel vallen. Commerciële distributeurs of maintainers van OSS‑pakketten kunnen uiteraard wel contractueel of op grond van nationaal onrechtmatigedaadsrecht aansprakelijk zijn, maar dat is een afzonderlijke vraag.
Voor engineering‑management betekent dit dat open‑source‑componenten als volwaardige, aansprakelijkheidsrelevante onderdelen van de productstack moeten worden behandeld. Selectie, beveiligingsevaluatie, naleving van licenties, integratietests en tijdig patchen zijn niet slechts best practices, maar vormen onderdeel van de zorgvuldigheid die van een fabrikant wordt verwacht. Vanuit ontwikkelaarsperspectief is elke “import” of container‑pull in de build‑pipeline ook een handeling waarbij het bedrijf een risico aanvaardt.
SBOM en de Cyber Resilience Act: bewijs van zorgvuldigheid in plaats van expliciete verplichting
Noch de richtlijn, noch het Duitse ontwerp noemt “SBOM” expliciet; er bestaat geen directe wettelijke verplichting in het productaansprakelijkheidsrecht om een Software Bill of Materials op te stellen. De SBOM verschijnt in het juridische landschap via cyberbeveiligings- en productveiligheidsrecht, vooral via de Cyber Resilience Act en begeleidende technische normen zoals de BSI‑richtlijn TR‑03183.
De CRA verplicht fabrikanten van producten met digitale elementen tot het inrichten van een processen voor kwetsbaarhedenbeheer, het volgen van componenten en bekende kwetsbaarheden gedurende de hele levenscyclus en het verschaffen van passende documentatie. Technisch komt dit neer op wat SBOM‑formaten zoals SPDX of CycloneDX bieden: een machineleesbare inventaris van eigen en derden‑softwarecomponenten, inclusief versies en relaties, die kan worden gebruikt om blootstelling aan CVE’s te beoordelen en patches te coördineren.
De brug naar productaansprakelijkheid wordt geslagen via het gebreksbegrip. De richtlijn schrijft expliciet voor dat rechters moeten nagaan of een product voldoet aan de toepasselijke veiligheids- en cyberbeveiligingsvereisten van het Unierecht bij de beoordeling of het de veiligheid biedt die het publiek redelijkerwijs mag verwachten. Wanneer CRA‑gedreven verplichtingen om een SBOM bij te houden en kwetsbaarheden te beheren worden genegeerd, zal dat zwaar wegen bij de vaststelling van een gebrek. Omgekeerd zal een gedocumenteerd SBOM‑gebaseerd proces aansprakelijkheid niet uitsluiten, maar wel een centraal element vormen bij het aantonen dat de fabrikant in overeenstemming met de stand van de techniek heeft gehandeld.
In de praktijk wordt een SBOM daarmee zowel een operationeel instrument als een stuk juridisch bewijs. Voor ontwikkelteams is het de enige schaalbare manier om binnen redelijke tijd en met voldoende zekerheid te beantwoorden of een nieuw bekendgemaakte kwetsbaarheid bepaalde producten of uitrols treft. Voor juristen maakt het deel uit van het dossier waarmee wordt aangetoond dat het bedrijf voldoende zicht had op zijn softwaresupplychain en adequaat op risico’s heeft gereageerd.
Procedure, bewijs en het belang van documentatie
Het nieuwe regime wijzigt ook de procedurele context waarbinnen productaansprakelijkheidsvorderingen worden uitgeprocedeerd. Om de informatie‑asymmetrie tussen benadeelden en complexe fabrikanten aan te pakken, introduceren de richtlijn en het Duitse ontwerp bevoegdheden voor rechters om openbaarmaking van relevante informatie te gelasten en een reeks weerlegbare vermoedens.
Rechters zullen fabrikanten kunnen bevelen documentatie over het ontwerp, de productie en de veiligheidskenmerken van het product te verstrekken, onder voorbehoud van proportionaliteit en bescherming van bedrijfsgeheimen. Indien een fabrikant zonder rechtvaardiging weigert, kan de rechter veronderstellen dat het product gebrekkig is. Daarnaast voorziet de wet in vermoedens dat een product gebrekkig is als het duidelijk niet voldoet aan verplichte veiligheidsvoorschriften of duidelijke storingen vertoont bij normaal of redelijkerwijs te voorzien gebruik, en in vermoedens omtrent causaliteit wanneer een gebrek en een typisch soort schade zijn aangetoond.
Een bijzonder relevante vernieuwing voor digitale en AI‑intensieve producten is de behandeling van technische en wetenschappelijke complexiteit. Wanneer de complexiteit van een product of dienst het voor een eiser buitensporig moeilijk maakt om een gebrek of causaliteit te bewijzen, en de eiser toch een voldoende hoge waarschijnlijkheid kan aantonen dat het product gebrekkig was of aan de schade heeft bijgedragen, kan de rechter de bewijslast verlichten en een groter deel daarvan bij de fabrikant leggen. Dit is duidelijk gericht op black‑box‑systemen en sterk gelaagde softwarestacks, waarbij externe partijen het interne gedrag niet realistisch kunnen reconstrueren zonder toegang tot documentatie en logs.
Dit alles onderstreept een eenvoudig punt dat zowel engineers als juristen begrijpen, zij het in verschillende terminologie: documentatie is geen bureaucratie, maar onderdeel van het veiligheidsdossier. Architectuurschema’s, componentinventarissen, teststrategieën, beveiligingsconcepten, update‑ en patchbeleid en incident‑response‑plannen zijn niet louter interne housekeeping. Onder het nieuwe recht vormen zij de feitelijke basis voor het betoog dat een product voldeed aan de legitieme veiligheidsexpectaties op het relevante tijdstip.
Juridisch risico in lijn brengen met technische realiteit
Het opkomende Europese kader probeert software‑engineers niet tot juristen te maken en schrijft geen specifieke technologieën voor, zoals concrete SBOM‑formaten of CI/CD‑tools. In plaats daarvan formuleert het een reeks verwachtingen die opvallend goed aansluiten bij degelijk engineering: zicht op de stack, controle over afhankelijkheden, veiligheid en veerkracht gedurende de volledige levenscyclus en een duidelijke toedeling van verantwoordelijkheid in de keten.
Voor het management ligt de strategische taak erin om governance, contracten en verzekeringsarrangementen aan deze realiteit aan te passen en ervoor te zorgen dat productontwikkeling, security en juridische functies met een gedeeld risicomodel werken. Voor ontwikkelaars en architecten is de praktische uitdaging om deze verwachtingen in de dagelijkse workflow te verankeren: SBOM‑generatie als onderdeel van de build behandelen, ontwerpen voor onderhoudbare updatepaden, open‑source‑componenten met dezelfde zorg selecteren en monitoren als interne modules en veiligheidsrelevante beslissingen zó documenteren dat ze jaren later nog begrijpelijk zijn.
Het recht vraagt niet om perfectie. Het vraagt om systemen die niet op voorspelbare wijze gevaarlijk worden, om processen die kunnen worden uitgelegd en verdedigd en om een mate van transparantie die past bij de maatschappelijke afhankelijkheid van software en AI. Wie zijn systemen zó ontwerpt en exploiteert dat hij ze regel voor regel in een kritisch peer‑review zou durven toelichten, staat ook juridisch veel dichter bij de positie die onder het nieuwe productaansprakelijkheidsregime vereist is.
Bereikbaarheid: via e-mail, terugbellen, Threema of Whatsapp. Informatie over onze kosten.
Ons advocatenkantoor is gespecialiseerd in strafrechtelijke verdediging, cybercriminaliteit, economisch strafrecht en fiscaal strafrecht en IT-recht en manager aansprakelijkheid. Wij nemen alleen strafrechtelijke verdedigingen van consumenten aan. Wij zijn gevestigd in de regio Aken en zijn actief in heel Duitsland.
- Europese rechtskader voor productaansprakelijkheid voor software, AI en open source - december 30, 2025
- Sluiting van Cryptomixer.io - december 2, 2025
- Duitse FernUSG en de juridische onduidelijkheden rond online bijscholing - november 22, 2025
