Laatst bijgewerkt op 1 oktober 2026
Auteur: Gerben Nerinckx, Commercial Lawyer & Fractional General Counsel
Het zou maar eens kunnen gebeuren: je bouwt de perfecte point solution, lanceert een app of biedt software als een SaaS-product aan, al dan niet met een AI-model onder de motorkap, en op een dag loopt het mis. Je tool geeft een verkeerd advies, maakt een foute berekening of laat een reeks gegevens verdwijnen, en bij de klant of iemand verderop in de keten ontstaat schade. Moet je daar als ontwikkelaar van wakker van liggen? Het zou je sieren, maar overdrijf toch maar niet. Het Belgische aansprakelijkheids- en contractenrecht bevat voor het slachtoffer toch wat drempels vooraleer die op jouw deur kan komen kloppen… al worden die drempels binnenkort wat minder hoog…
Software kan je niet dagvaarden, jou wel…
Software, een SaaS-instance of een AI-model hebben geen rechtspersoonlijkheid. Er wordt wel over nagedacht om dat te veranderen, maar vandaag kan die software op zich geen fout maken waarvoor het zélf aansprakelijk zou zijn en zélf door ‘top-advocaten’ bij de spreekwoordelijke bits (i.p.v. haren) voor de rechter kan ‘gesleept’ worden. Wie schade lijdt door het gebruik van jouw software, moet dus bij jou aankloppen, als “fabrikant” van de software. En dan begint voor die persoon het echte werk.
Drie horden, en de eiser raakt er maar moeilijk overheen…
Het pad naar de schadevergoeding ligt bezaaid met drie hindernissen, nl. het aantonen van een fout, van schade en van een verband tussen die twee. Is de schadelijder jouw contractspartij, dan bestaat jouw fout als fabrikant meestal uit het niet-naleven van een verbintenis die in jouw contract is opgenomen (denk aan een garantie omtrent specs die niet gehaald wordt, een belofte uit je privacy- of security policy die toch wat losjes was geformuleerd, of een overenthousiaste marketingclaim die jouw klant de hemel beloofde en deel is gaan uitmaken van jouw contract), dan wel uit het niet-naleven van wettelijke vereisten (denk aan het schenden van bepaalde verplichtingen uit de AI Act i.v.m. de training van je AI-systeem). Staat de schadelijder verder in de keten, dan vindt hij/zij jouw fout meestal in dezelfde overtreding van de wet, of wordt jou als fabrikant verweten dat je niet handelde zoals een zorgvuldige ontwikkelaar van software zou handelen.
Over de fout hebben we dus al een idee, en van het bestaan van schade gaan we voor de goede orde even uit. Maar nu moet de schadelijder niet alleen de fout en de schade beweren, maar ook echt bewijzen, en daarnaast moet hij/zij ook het verband aantonen (ook weer niet zuiver beweren) tussen die fout en de geleden schade. En dit is in de softwarewereld niet zo eenvoudig als het lijkt.
De reden daarvoor is wat, in lawyer-geek-taal, de “informatieasymmetrie” wordt genoemd. Jij als fabrikant van de software weet, of hebt ten minste een idee, HOE jouw software is gebouwd, werd getraind, welke QA-procedures werden gehanteerd etc., en als het een beetje meezit (wellicht niet zozeer bij jouw AI-systeem), ook hoe/waarom jouw software ‘besliste’ om de mist in te gaan. Het slachtoffer heeft daarentegen geen inzage in die informatie, en kan vaak alleen maar veronderstellen of beweren… en aannames vormen geen bewijs. En dan ga jij als ‘fabrikant’ van de software vrijuit.
Het oorzakelijk verband tussen een fout en schade is vaak nog moeilijker aan te tonen. Met AI-systemen kom je al snel uit bij het zogenaamde black-box-probleem: zelfs de fabrikant kan vaak niet (meer) uitleggen hoe het model van die ene prompt tot dat ene foute antwoord kwam. Als jij het als fabrikant al niet (meer) kan, hoe moet een buitenstaander het dan aantonen?
Neem het volgende voorbeeld. Stel, je ontwikkelt software om labels op verpakkingen na te kijken in het licht van de correcte vermelding van ingrediënten. De software ‘bekijkt’ een label, geeft groen licht, en een week later belanden een aantal consumenten in een ziekenhuisbed omdat de software het zijne dacht over glutenintolerantie. Of je commercialiseert een SaaS-tool gericht op netwerkbeveiliging, en, ondanks het gebruik van die tool, wordt alle data van de lokale amateur-voetbalclub gewist door een hacker die vlotjes door de mazen van jouw beveiligingsnet surfte. Ik wens het slachtoffer veel geluk bij zijn/haar taak om te bewijzen (en niet louter te beweren) dat jij als fabrikant een fout hebt gemaakt in de ontwikkeling van de software WAARDOOR de schade ontstond.
9 december 2026: de drempels worden lager…
Tegen die datum moet België de nieuwe Europese richtlijn productaansprakelijkheid (Richtlijn 2024/2853) in wetgeving omgezet hebben.
Tot nu toe valt software buiten de regelgeving i.v.m. productaansprakelijkheid, vermits het niet als “product” werd beschouwd. Vanaf die datum draait het plaatje om en wordt software, AI-systemen inbegrepen, ongeacht de wijze van distributie (licentie of SaaS), een “product”, en daarbij geldt dat iedere natuurlijke persoon die schade lijdt ten gevolge van een gebrekkig “product” (jouw software) recht heeft op een schadevergoeding.
Daarnaast komen vanaf dan meer soorten schade in aanmerking voor vergoeding: niet alleen lichamelijk letsel, maar ook psychische schade, schade aan zaken en het verlies of de corruptie van gegevens.
Maar de grootste verandering zit in de aansprakelijkheid zelf. De schadelijder moet, in principe, nog steeds bewijzen dat het product gebrekkig is (lees: niet voldoet aan de veiligheid die een persoon ervan mag verwachten), dat er schade is, én dat er een oorzakelijk verband is tussen dat gebrek en die schade, maar… hij wordt daarbij vanaf nu een handje geholpen: maakt de eiser zijn claim aannemelijk (wat een veel lagere drempel is dan te bewijzen dat…), dan kan de rechter jou als fabrikant verplichten om je documentatie, logs, testresultaten, QA-procedures etc. op tafel te leggen (om de schadelijder te helpen bewijs te leveren). Doe je dat niet (of kan je dat niet omdat je al te slordig was in het bijhouden van die documentatie), dan wordt je product vermoed gebrekkig te zijn. En is het technisch te complex om het oorzakelijk verband tussen gebrek en schade sluitend te bewijzen, dan mag de rechter bovendien genoegen nemen met “waarschijnlijk”. Het is vanaf dan immers voldoende dat het slachtoffer aantoont dat het “waarschijnlijk” is dat het product gebrekkig is en/of dat er een oorzakelijk verband bestaat tussen de gebrekkigheid van het product en de schade.
Vooral in het licht van AI-systemen wordt dit interessant: zou het kunnen ‘waarschijnlijk’ zijn dat AI hallucineert, de foute output genereert en er een verband is met de door het slachtoffer opgelopen schade? Nooit van gehoord? De black box die je vandaag beschermt, werkt niet meer in je voordeel…
En jij dacht dat een grote disclaimer: ‘mijn software kan hallucineren en gekke dingen doen,…, controleer het dus maar best allemaal zelf’ jou kan redden? Wat dacht je hiervan: “(de) samen met een product verstrekte waarschuwingen of andere informatie kunnen echter niet als voldoende worden beschouwd om een gebrekkig product veilig te maken, aangezien de gebrekkigheid moeten worden bepaald aan de hand van de veiligheid die het grote publiek mag verwachten.” Kan je, onze voorbeelden indachtig, niet verwachten dat software die labels controleert, veilig genoeg is om foutieve labels tegen te houden waar het voedselintolerantie betreft, of dat software bedoeld voor netwerkbeveiliging precies verhindert dat hackers al te vlotjes in het systeem van jouw klanten geraken? Wie zal het zeggen? Het zal de komende jaren wel door de rechtbanken uitgemaakt worden.
Tijd voor een grote kuis in je contracten en je polis
Ik schreef al eerder over het belang van indemnities in jouw contracten met AI-leveranciers (I indemnify, You indemnify, He/She indemnifies…and why Your AI vendor should as well). Nu komt daar een dimensie bij: als fabrikant van software kan je jouw aansprakelijkheid in het licht van de richtlijn productaansprakelijkheid t.o.v. de schadelijder niet beperken, maar de leverancier van het AI-model dat in jouw software ingebakken zit kan dit t.o.v. jou wél. En… poef… bij wijze van een goocheltruc (ik schrijf bewust niet Google-truc) ben jij aansprakelijk t.o.v. jouw klanten maar jouw leverancier niet t.o.v. jou.
Let daar dus maar een beetje op vóór je je contracten met je leverancier ondertekent. En probeer het nalezen van jouw contracten misschien niet al te vlotjes uit te besteden aan jouw AI-buddy. Je riskeert immers tussen twee stoelen te vallen, aansprakelijk tegenover je klant, en zonder verhaal bij wie het onderliggende model leverde. Komt je verzekeraar daarvoor tussen? Check misschien ook maar even vlug jouw polis, terwijl je toch bezig bent…
Algemene informatie over Richtlijn (EU) 2024/2853 inzake aansprakelijkheid voor gebrekkige producten, geen juridisch advies voor jouw specifieke situatie.