Kan ik de leverancier van mijn AI-agent aanpakken wegens door de agent bekend destructief gedrag?

Photo by Jonathan Cooper on Unsplash

Een lezer vroeg me:

Met enige regelmaat lees je over AI agents die destructief handelen, zoals dit verhaal over een AI-agent die op eigen houtje een productiedatabase van een startup verwijdert. Nu vroeg ik me af, kun je die schade verhalen op de leverancier die dat kennelijk zonder kwaliteitscontrole inbouwt? En maakt het daarbij uit dat het AI-model zelf een analyse oplepelt inclusief schuldbekentenis?
Als een menselijke systeembeheerder of programmeur data vernielt, kun je ze als bedrijf op het matje roepen. Maar bij een slecht geprogrammeerd stuk software ligt dat lastiger. Je komt dan al snel uit bij de leverancier, maar die heeft zich in de zakelijke relatie waarschijnlijk ingedekt tegen fouten met een sterke beperking van aansprakelijkheid.

Dat de medewerker schuld bekent, is bij mensen niet heel erg relevant. Fout is fout, en alleen als de bekentenis is “dit deed ik om jullie te beschadigen” dan wordt het juridisch interessant. Want dan spreken we van opzet of bewuste roekeloosheid en dan kun je die beperking van aansprakelijkheid omzeilen.

Alleen: een AI-agent is geen medewerker, en ook daarmee niet te vergelijken. Het is een tool, een stuk software. Weliswaar is de interface “gewoon Nederlands praten” en gebruikt het ding ik en jij in de communicatie, maar juridisch is er geen verschil tussen een shellscript en het meest geavanceerde frontier AI model. Het kan fouten bevatten, en als het de leverancier zijn schuld is dan stuit dat af op de beperking van aansprakelijkheid.

Er is enige discussie of het statistische karakter van deze diensten nog uit moet maken. Een shellscript of ander klassiek stuk software doet wat je zegt, keer op keer. Een AI-agent kan zomaar andere resultaten geven bij dezelfde instructie en dezelfde data. Dat is inherent aan hoe ze zijn gemaakt, en je kunt verdedigen dat dit eerder tot verwijtbaarheid bij de leverancier leidt. Tegelijkertijd: als dit inherent is, is dat ook iets dat jij als koper had moeten weten.

Arnoud

15 reacties

    1. “Bewuste roekeloosheid”, en inderdaad dan geldt je beperking van aansprakelijkheid niet. De HR legt dat uit als “grenzend aan opzet”, oftewel als je niet létterlijk dacht “ik ga ze eens lekker een bak schade bezorgen vandaag” dan toch op zijn minst “ach wat kan mij dat verrotten dat ze hier schade van krijgen”. Gewoon slordig of nalatig zijn haalt dit criterium niet.

        1. Maar als gebruiker ben je wel roekeloos (bewust of onbewust) als je een AI buiten een sandboxed omgeving systeemhandelingen laat verrichten.

          ChatGPT is best handig voor veel zaken, maar het draait of in de browser zonder toegang tot het bestandsysteem, of in een docker container met alleen toegang tot het bestandsysteem dat ik in de container deel.

          Wie is er verantwoordelijk voor het gebruik van een gereedschap wanneer de gebruiker de kennis ontbreekt om het gereedschap veilig te gebruiken.

          Is de gebruiker verantwoordelijk dat hij de kennis heeft? Of heeft de fabrikant een zorgplicht en moet hij dat melden? En als hij dat meld is daarmee zijn verantwoordelijheid weg?

          1. En wat als de fabrikant het specifiek verkoopt als bruikbaar voor systeemhandelingen buiten een sandboxed omgeving? Als dan blijkt dat het niet alleen onbruikbaar is, maar zelfs ronduit gevaarljk, dan is het toch bewust roekeloos om zulke marketing uitspraken te doen ?

            Net zoals het bewust roekeloos zou zijn wanneer een farmaceut claimt dat een bepaald medicijn getest en veilig is, maar er vervolgens mensen aan overlijden. (Ik mag toch hopen dat dat daar onder valt?)

            1. Geen enkele AI is met root/admin rechten op een systeem veilig. Je moet dus altijd zelf maatregelen nemen om et veilig te houden en backups maken voor je begint.

              Dan is de AI nog steeds geschikt en kan je er voor adverteren. Ik zou dan wel verwachten dat je in iedergeval duidelijk op een quickstart wijst waarin je uitlegt hoe je de tool veilig gebruikt.

              Ik gebruik Codex alleen om complexe grote systeeminstellingen te wijzigen, maar ik heb daar een aparte systeem partitie voor die ik na succesvolle updates synchroniseer met de normale systeem partitie.

              Samen met backups en handmatig goedkeuren van elke wijziging is het redelijk risicovrij en kan ik iig altijd een backup terugzetten waar de AI geen toegang tot had.

              Of als ik een nieuw systeem opzet dan draait de ai in een chroot omgeving.

              Maar voor teksten/programmeren heeft de AI of helemaal geen toegang en copy paste ik uit de browser, of draait hij in een sandbox.

              Maar dit is geen nieuw probleem. Al sinds computrs permanent aan het internet hangen hebje te maken met software die verkocht wordt als geschikt voor gebruik, maar de gebruikers hebben de kennis niet om het veilig te gebruiken: Windows zowel als Linux distributies vereisen toch echt kennis die de meeste mensen niet hebben om veilig te gebruiken.

            2. Als het getest en veilig bevonden is, is het natuurlijk niet bewust roekeloos om dat te melden als verkoopargument. Dat het achteraf onveilig blijkt, is heel vervelend maar maakt je niet achteraf roekeloos. Dat is waar testen over gaat. (Liegen dat je getest en veilig bent is opzet.)

              Bij de agents is dus de vraag: wat is er gezegd over de veiligheid, en wat had de klant moeten vermoeden over wat er wel en niet kon. “Wij hebben marktconforme guardrails geimplementeerd en tegen de JoepieDePoepie benchmark getest en daarvoor zijn we geslaagd” zou een aardig tegenargument zijn tegen bewust roekeloos handelen. Aangenomen dat Joepie’s benchmark gedragen wordt door de markt.

        2. Een olifant kan ook niet bewust roekeloos zijn, die heeft gewoon geen benul van de implicaties, maar als ie een porseleinkast aan diggelen trapt, dan wordt er toch wel even heel kritisch gekeken naar de eigenaar van die olifant, en waarom er geen hek om zijn verblijf stond.

            1. Als dat mogelijk is, is het dan niet zo dat je beveiliging al lek is? Want als een agent zichzelf rechten toe kan eigenen, dan kan een gebruiker dat ook.

              En als een AI agent op eigen houtje 0-day exploits toe gaat passen om aan rechten te komen waarmee ie zijn doel kan bereiken, dan hebben we het over een heel andere situatie.

              1. Het probleem is volgens mij meer dat wij gewend zijn bij rechtentoekenning aan menselijk gedrag te denken, in ieder geval voor taken die mensen doen en agents nu gaan doen. Een agent kan dingen aan elkaar knopen, eindeloos proberen en nieuwe inzichten bedenken hoe diensten onderling synergie geven. Dingen waar je als mens niet snel op komt. Zeg maar hacken, in de ouderwetse betekenis. Is de printer een liedje laten spelen door een heel creatief PDF bestand een lekke beveiliging?

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.