Een softwarefout verwijdert gegevens. Een AI-systeem keurt ten onrechte een aanvraag goed. Een update veroorzaakt schade bij een gebruiker.
Wie is dan verantwoordelijk?
“Het algoritme deed het” klinkt misschien als een verklaring. Het is geen verdedigingsstrategie.
Software wordt steeds minder ongrijpbaar
De Nederlandse regels rond productaansprakelijkheid worden naar verwachting uitgebreid. Daardoor kunnen ook software en AI nadrukkelijker als product onder aansprakelijkheidsregels vallen. De beoogde ingangsdatum is 9 december 2026, maar op het moment van schrijven is die datum nog niet definitief: het wetsvoorstel moet eerst het parlementaire proces doorlopen.
Dit artikel is geen juridisch advies. Het interessante voor Byte Me zit ergens anders: wetgeving maakt zichtbaar wat technisch eigenlijk al normaal zou moeten zijn. Als software echte beslissingen beïnvloedt en echte schade kan veroorzaken, moet je kunnen uitleggen hoe zij is gebouwd, bijgewerkt en gecontroleerd.
Hoe groter de impact van software, hoe minder ruimte er is voor “we weten niet precies wat er gebeurde”.
De fout die niemand kon reconstrueren
Stel dat een platform automatisch beoordeelt of een bestelling direct kan worden vrijgegeven. Op een dinsdag wordt een risicovolle order toch goedgekeurd. Pas later ontdekt de organisatie dat belangrijke klantinformatie tijdens de controle niet beschikbaar was.
Om te begrijpen wat misging, zijn simpele vragen nodig:
- Welke softwareversie draaide op dat moment?
- Welke gegevens zijn gebruikt?
- Welke regels golden?
- Was een externe AI-dienst betrokken?
- Heeft iemand een waarschuwing gezien of genegeerd?
- Kon de order handmatig worden tegengehouden?
Als de software die antwoorden niet kan geven, blijft alleen giswerk over. Dat is niet alleen lastig voor aansprakelijkheid. Het maakt verbeteren vrijwel onmogelijk.
Logging is geen digitale stofzuigerzak
“We loggen alles” klinkt veilig, maar enorme hoeveelheden ongerichte technische data helpen zelden. Goede logging legt vast wat nodig is om een belangrijke actie te begrijpen, zonder onnodig persoonsgegevens of vertrouwelijke inhoud te verzamelen.
Bij een bedrijfskritische beslissing wil je bijvoorbeeld weten welke gebruiker of dienst de actie startte, welke regel werd toegepast, welke versie actief was en wat de uitkomst werd. Bij AI kan het ook nodig zijn vast te leggen welk model of welke configuratie is gebruikt en of een mens de uitkomst heeft goedgekeurd.
Dat vraagt ontwerp. Niet achteraf een extra vinkje.
Updates zijn onderdeel van het product
Software wordt nooit één keer gebouwd en daarna bevroren. Besturingssystemen veranderen, bibliotheken krijgen beveiligingsupdates, externe diensten passen koppelingen aan en nieuwe kwetsbaarheden worden ontdekt.
Wie software levert, moet daarom vooraf nadenken over onderhoud:
- hoe lang worden beveiligingsupdates geleverd?
- hoe worden ernstige problemen gemeld?
- wie bepaalt wanneer een update noodzakelijk is?
- hoe testen we of een wijziging bestaande processen raakt?
- kan een slechte release veilig worden teruggedraaid?
Een lage bouwprijs kan duur worden wanneer niemand verantwoordelijk is voor wat er na livegang gebeurt.
AI vraagt niet om minder controle, maar om andere controle
Traditionele software volgt expliciete regels. AI-systemen kunnen probabilistische uitkomsten geven: dezelfde soort invoer levert niet altijd exact hetzelfde gedrag op. Dat maakt testen niet onmogelijk, maar wel anders.
Je test dan niet alleen één verwacht antwoord. Je werkt met representatieve voorbeelden, grensgevallen, verboden uitkomsten en continue monitoring. Bij beslissingen met grote gevolgen voeg je menselijke beoordeling, beperkte rechten en een duidelijke terugvalroute toe.
Niet omdat AI per definitie onveilig is. Omdat autonomie zonder begrenzing ook bij menselijke medewerkers een slecht idee zou zijn.
Opdrachtgever en bouwer hebben allebei werk te doen
Een softwarebureau kan veilige techniek, logging, tests en onderhoud organiseren. Het kan niet zelfstandig bepalen welk bedrijfsrisico acceptabel is of welke beslissing altijd menselijke goedkeuring nodig heeft.
De opdrachtgever kent het proces en de impact. De bouwer kent de technische mogelijkheden en beperkingen. Verantwoordelijkheid begint daarom bij scherpe gesprekken vóór de bouw.
Bij Byte Me stellen we liever een ongemakkelijke vraag te veel dan achteraf vaststellen dat niemand eigenaar was van een risico. Wat mag automatisch? Wat moet aantoonbaar zijn? Welke fout mag nooit stil blijven? Wie grijpt in?
Geen paniek, wel volwassen software
Nieuwe aansprakelijkheidsregels betekenen niet dat ieder softwareproject plotseling juridisch onbegaanbaar wordt. Ze onderstrepen vooral dat digitale producten serieus genomen moeten worden.
Dat past bij hoe wij willen bouwen: met duidelijke keuzes, beveiliging die in het proces zit, onderhoud na livegang en genoeg bewijs om problemen te kunnen begrijpen.
Software mag fouten hebben. Ieder serieus product heeft grenzen en uitzonderingen. Het verschil zit in de voorbereiding: ontdek je de fout, beperk je de schade, kun je reconstrueren wat er gebeurde en herstel je verantwoord?
Want zodra software onderdeel wordt van je bedrijfsvoering, is een fout nooit meer alleen “iets technisch”.