Aansprakelijkheid bij falende AI: de impact van de herziene PLD

De aansprakelijkheid voor schade veroorzaakt door software en autonome systemen ondergaat een fundamentele verschuiving. Waar de discussie rond Europese regulering zich lang richtte op markttoegang en voorafgaande conformiteitstoetsen, bepaalt de herziene Productaansprakelijkheidsrichtlijn (Product Liability Directive, afgekort als PLD) wat er gebeurt wanneer een systeem in de praktijk daadwerkelijk faalt en materiële of immateriële schade veroorzaakt. In de uitleg over de EU AI Act staat de tijdlijn van veiligheidseisen en risicocategorieën centraal; de herziene PLD vormt het privaatrechtelijke sluitstuk dat slachtoffers een concreet vorderingsrecht geeft tegen ontwikkelaars, integrators en importeurs.

De klassieke richtlijn uit 1985 ging uit van tastbare, industriële goederen zoals defecte remkabels of exploderende ketels. In de gemoderniseerde richtlijn is software — inclusief zelflerende algoritmes, embedded modellen en cloudgebaseerde AI-diensten — expliciet gelijkgesteld aan een product. Daarmee geldt risicoaansprakelijkheid (aansprakelijkheid zonder schuld) voortaan rechtstreeks voor softwarefouten, trainingsfouten en inadequate modelupdates. In dit artikel analyseren we de juridische mechanismen, de omkering van de bewijslast en de directe gevolgen voor de technische architectuur van AI-toepassingen.

Van fysiek product naar software en autonome systemen

Onder het oorspronkelijke productaansprakelijkheidsrecht stuitten eisers bij softwarematige schade stelselmatig op de definitie van een 'product'. Schade veroorzaakt door pure software werd in veel lidstaten niet behandeld via risicoaansprakelijkheid, maar via het algemene onrechtmatige-daadsrecht. Dat legde de volledige bewijslast van schuld en nalatigheid bij de gedupeerde. De herziene richtlijn trekt hier een definitieve streep door: software, ongeacht of deze is vastgelegd op een fysieke drager, wordt geleverd als broncode, of draait als een API-dienst (Software-as-a-Service), kwalificeert ondubbelzinnig als product.

Deze status geldt ook wanneer de software autonoom beslissingen neemt of na ingebruikname haar werking aanpast via continue trainingslussen. Wanneer een machine learning-model na uitrol in een operationele omgeving ander gedrag gaat vertonen door nieuwe gegevensstromen, blijft de fabrikant of integrator verantwoordelijk voor het waarborgen van de veiligheid. De reikwijdte beperkt zich niet tot zuiver fysiek letsel of zaakschade; ook het vernietigen of onherstelbaar corrumperen van data en ernstige inbreuken op de psychische gezondheid (mits medisch vastgesteld) vallen nu expliciet binnen het vergoedbare schadebegrip.

Voor organisaties betekent dit dat de operationele fase van een model net zo risicodragend is als de initiële release. Een model dat bij oplevering aan alle benchmarks voldeed, maar door concept drift of adversarial manipulation onveilig gedrag ontwikkelt, kan direct leiden tot civielrechtelijke aansprakelijkheid van de partij die controle over het product behield.

Het causale 'black box'-probleem en de omkering van de bewijslast

Het grootste obstakel voor benadeelden bij AI-schade is het asymmetrische kennisvoordeel van de technologieleverancier, gecombineerd met de inherente ondoorzichtigheid van diepe neurale netwerken. Een gedupeerde consument of organisatie kan in de praktijk zelden aantonen welke specifieke gewichten, prompt-injecties of ontbrekende validatielagen hebben geleid tot een onjuiste beslissing. Om te voorkomen dat dit leidt tot een juridisch vacuüm waarin claims bij voorbaat kansloos zijn, introduceert de herziene PLD twee krachtige procesrechtelijke instrumenten: een informatie-openbaarmakingsplicht en een weerlegbaar vermoeden van defect en causaliteit.

Wanneer een eiser aannemelijk maakt dat hij schade heeft geleden en dat het AI-systeem daarbij betrokken was, maar vanwege buitensporige technische complexiteit het exacte gebrek niet kan bewijzen, kan de rechter de gedaagde verplichten om relevante interne documentatie en logs openbaar te maken. Weigert de verweerder deze gegevens te verstrekken, of kan hij niet aantonen dat hij aan de geldende veiligheids- en monitoringseisen voldeed, dan treedt het vermoeden van causaliteit in werking. De rechter neemt dan automatisch aan dat het systeem defect was en dat dit defect de schade heeft veroorzaakt, tenzij de fabrikant het tegendeel bewijst.

Om te begrijpen hoe organisaties deze aansprakelijkheidsrisico's operationeel mitigeren, toont de gids over de AI Act in de praktijk welke concrete maatregelen bedrijven moeten treffen om aan de wettelijke documentatieplichten te voldoen. Het ontbreken van robuuste logging vormt onder de herziene richtlijn immers een direct procesrisico.

Aansprakelijkheidsketens: van foundation model tot eindtoepassing

AI-toepassingen worden vrijwel nooit vanaf nul opgebouwd. Een typische stack bestaat uit een onderliggend foundation model, een hostinginfrastructuur, een orchestration-laag (zoals een RAG-pijplijn) en een branchespecifieke gebruikersinterface. De herziene PLD legt vast wie binnen deze keten als aansprakelijke partij geldt wanneer het eindproduct faalt.

De hoofdregel luidt dat de partij die een systeem substantieel wijzigt (bijvoorbeeld door fine-tuning of het koppelen van autonome tools met beslissingsbevoegdheid), juridisch wordt aangemerkt als de fabrikant van het resulterende product. Als een integrator een algemeen taalmodel integreert in een geautomatiseerd medisch triagesysteem of een financieel adviesplatform, kan deze partij zich bij schade niet verschuilen achter de leverancier van het basismodel.

Wanneer niet-Europese leveranciers diensten leveren zonder een vestiging binnen de Europese Unie, verschuift de volledige risicoaansprakelijkheid automatisch naar de Europese importeur of de officiële gemachtigde vertegenwoordiger. Dit dwingt Europese integrators tot rigoureuze due diligence bij de selectie van componenten.

Het ontwikkelingsrisicoverweer onder druk

Traditioneel bevat het productaansprakelijkheidsrecht het zogeheten ontwikkelingsrisicoverweer (development risk defence): een fabrikant is niet aansprakelijk als de stand van de wetenschap en techniek op het moment van in het verkeer brengen het onmogelijk maakte om het gebrek te ontdekken. In de context van probabilistische, niet-deterministische AI-modellen stond dit verweer zwaar ter discussie.

Onder de herziene richtlijn is de toepassing van dit verweer voor AI-systemen aanzienlijk ingeperkt. Een fabrikant kan zich niet langer beroepen op de onvoorspelbaarheid van een neuraal netwerk als excuus voor falende output. Aangezien hallucinaties, bias en kwetsbaarheid voor prompt-manipulatie bekende eigenschappen van deze architectuur zijn, vallen incidenten die hieruit voortvloeien onder het voorzienbare risicoprofiel van het product. Fabrikanten moeten aantonen dat zij de stand der techniek hebben toegepast op het gebied van evaluatie, monitoring en vangnetmechanismen.

Hierbij spelen formele technische kaders een doorslaggevende rol. Zie het dossier over AI-standaarden en ISO-normering voor de normen (zoals ISO/IEC 42001 en CEN/CENELEC-standaarden) die bepalen wat rechters in de praktijk beschouwen als de geldende 'stand van de techniek' bij aansprakelijkheidstoetsingen.

Wisselwerking tussen de AI Act en de Productaansprakelijkheidsrichtlijn

De EU AI Act en de herziene PLD functioneren als een twee-eenheid binnen het Europese digitale recht, maar dienen een fundamenteel ander doel. De AI Act is een publiekrechtelijk instrument gericht op markttoelating, risicobeheersing en toezicht door nationale autoriteiten. Een fabrikant die de AI Act overtreedt, riskeert bestuurlijke boetes en een marktverbod, maar de AI Act regelt zelf geen schadevergoeding voor individuele slachtoffers.

De herziene PLD vormt het privaatrechtelijke complement: het regelt de civielrechtelijke vergoeding van geleden schade. Er bestaat echter een directe bewijsrechtelijke brug tussen beide instrumenten. Wanneer een deployer of integrator kan aantonen dat een AI-systeem niet voldeed aan de fundamentele vereisten van de AI Act (zoals verplichte datakwaliteit, risicobeoordelingen, logging of menselijk toezicht), vormt dit voor de civiele rechter direct een sterk vermoeden dat het product gebrekkig was in de zin van de PLD.

Conformiteit met de AI Act biedt daarentegen geen absolute immuniteit tegen civiele claims. Een systeem kan formeel aan alle markttoelatingseisen voldoen, maar in een specifiek praktijkscenario alsnog een gebrek vertonen dat tot aansprakelijkheid leidt zodra er schade optreedt.

Contractuele doorwerking en vrijwaringen in de praktijk

Omdat de risicoaansprakelijkheid onder de PLD dwingend recht is ten gunste van consumenten en benadeelde partijen, kunnen leveranciers deze aansprakelijkheid naar de buitenwereld toe niet contractueel uitsluiten. Dit heeft geleid tot een radicale herstructurering van zakelijke contracten (B2B) binnen de technologiesector.

Integrators en softwarebedrijven verleggen het financiële risico van potentiële claims via strikte vrijwaringsclausules, geplafonneerde aansprakelijkheden en specifieke Service Level Agreements (SLA's) naar toeleveranciers en modelaanbieders. Om te beoordelen hoe organisaties deze risicoverdeling waterdicht vastleggen, biedt de analyse over vendorcontracten voor AI concrete handvatten voor het formuleren van aansprakelijkheidslimieten en garanties bij het inkopen van externe modelcapaciteit.

In de praktijk zien we dat gevestigde modelleveranciers expliciet uitsluiten dat zij garanties geven op de feitelijke juistheid van gegenereerde output. Daardoor komt het aansprakelijkheidsrisico van een falend systeem vrijwel volledig te rusten op de partij die het model implementeert in een operationele workflow zonder afdoende validatiestappen.

Technische maatregelen voor auditeerbaarheid en logbeheer

Om te voorkomen dat een organisatie bij een aansprakelijkheidsclaim wordt geconfronteerd met het gerechtelijke vermoeden van causaliteit, is het opzetten van een robuuste logging- en traceerbaarheidsarchitectuur noodzakelijk. Het achteraf reconstrueren van de exacte staat van een model, de meegegeven context en de ontvangen input is de enige effectieve verdediging tegen claims.

Een compliant logging-architectuur moet minimaal de volgende onderdelen onveranderlijk vastleggen:

• De exacte versie en modelparameters (waaronder temperature, top-p en system prompts) die tijdens de inferentie actief waren.
• De volledige context payload, inclusief de specifieke documentfragmenten die via retrieval-augmented generation (RAG) zijn geïnjecteerd.
• De resultaten van geautomatiseerde validatiefilters (guardrails) vóór en na de modelaanroep.
• De eventuele tussenkomst of goedkeuring door een menselijke toezichthouder (human-in-the-loop).

Onderstaande configuratie toont een functioneel schema voor een audit-log event payload die voldoet aan de eisen voor traceerbaarheid onder de herziene richtlijn:

{
  "event_id": "evt_20260819_9481a",
  "timestamp": "2026-08-19T17:22:04.118Z",
  "system_identifier": "triagesysteem-medisch-v2.4",
  "model_provider": "local-hosted-inference",
  "model_version_hash": "sha256:d8b74c83e29f01a3",
  "inference_parameters": {
    "temperature": 0.0,
    "seed": 42
  },
  "retrieval_context": {
    "source_dataset_id": "protocol-nl-2026-v3",
    "chunk_references": ["doc_883_p12", "doc_902_p4"]
  },
  "guardrail_evaluations": {
    "input_safety_passed": true,
    "output_toxicity_score": 0.002,
    "factual_consistency_score": 0.984
  },
  "human_override": {
    "reviewed_by_user_id": "usr_dr_8829",
    "override_action": "none"
  }
}

Vooruitblik op handhaving en rechtspraak

De implementatie van de herziene Productaansprakelijkheidsrichtlijn markeert het einde van het vrijblijvende experimentstadium voor AI-toepassingen in productieomgevingen. Waar softwareontwikkelaars historisch gewend waren aan verregaande contractuele disclaimers ("as is"-levering zonder aansprakelijkheid voor gevolgschade), dwingt het Europese risicoaansprakelijkheidsregime tot dezelfde kwaliteitsborging en productveiligheid die geldt voor de medische en automotive-industrie.

Voor organisaties die AI-systemen ontwerpen, integreren of inzetten, verschuift het zwaartepunt van risicomanagement van puur administratieve compliance naar meetbare, technische robuustheid. Wie niet kan aantonen welke data het model heeft gevoed, hoe guardrails hebben gefunctioneerd en welke controles zijn uitgevoerd, draagt bij schade automatisch de zware last van het wettelijke defectvermoeden. De komende jaren zal de rechterlijke toetsing via proefprocessen en civiele schadeclaims exact bepalen waar de grenzen liggen van wat van een redelijk handelend AI-ontwikkelaar mag worden verwacht.