LLMs voor LL.M.s – oftewel: GenAI & de juridische praktijk (leidraad voor juristen)

Mr. dr. Roeland W. de Bruin – van Gogh LL.M. is werkzaam als Universitair Docent bij de Universiteit Utrecht; als advocaat bij Kienhuis Legal NV en als eigenaar van Websession en CEO van Labskai. Dit stuk is geschreven op persoonlijke titel. Dit stuk is bedoeld als een discussiedocument, en daarmee een “groeidocument” en behelst (met name) de persoonlijke opinies van de auteur. Dit is versie 0.2, d.d. 24 maart 2026.

De toepassing van Large Language Models (LLMs) binnen het juridische domein levert nogal eens ongelukken op die even hilarisch als zorgelijk zijn. Of, als ik het bij mijzelf houd, situaties waarin ik mij zelf liever niet zou begeven. Denk aan advocaten die foute LLM-output klakkeloos overnemen in processtukken; studenten die geen idee hebben wat de teksten behelzen die ze bij mij inleveren; cliënten die hun rechtsvraag “al even hebben voorgelegd aan Chat” en waartegen hun raadsman zich vervolgens moet verweren als de waarheid toch weerbarstiger blijkt; vakgenoten die hun cliënten zelfs adviseren om eerst even langs het juridisch LLM-loket te gaan; en/of beweren dat ze hun advies optimaliseren door het daarna door een taalmodel te laten aanvullen, omdat dat tot betere uitkomsten zou leiden (qoud non).

Vaak ontstaan die ongelukken doordat de betreffende collega’s of studenten, met ongetwijfeld goede bedoelingen, maar mede geholpen door een FOMO die is aangewakkerd door een overwegend Amerikaanse industrie die inmiddels “too big to fail” aan het worden is, bang zijn de boot te missen – en onvoldoende beslagen ten ijs blindvaren op wat ChatGPT, Co-pilot, Claude etcetera uitspugen. En daar komen problemen van.

Ik ben zelf ook nieuwsgierig naar de ontwikkelingen omtrent kunstmatige intelligentie in het algemeen, en natuurlijk ook naar GenAI als gemakkelijk toegankelijke verschijningsvorm daarvan. Tegelijkertijd ben ik ook kritisch ten aanzien van de kwaliteit en de implicaties van het ongebreideld toepassen van bijvoorbeeld LLMs, zeker door (startende) Meesters in de Rechten (LL.M.s). Daarom maakte ik (in beginsel voor eigen gebruik) een lijstje met overwegingen die kunnen helpen bij het besluit om een GenAI-toepassing al dan niet te gebruiken. Dit lijstje is niet uitputtend en aan verandering onderhevig, maar toch wil ik het hier delen (opbouwend commentaar is zeker welkom).

De punten tot nu toe: 1) technische werking en toepassings(on)mogelijkheden; 2) kwaliteit van en verantwoordelijkheid voor input/trainingsdata; 3) verantwoordelijkheid voor operationele inzet van LLMs in twee delen: i) privacy en auteursrecht en ii) (algemene) AI-regelgeving en (toezichthouder)beleid; en tot slot een samenvatting én een ecologische overweging nota bene;

1.      LLM techniek en toepassings(on)mogelijkheden

Large Language Models zijn op dit moment de meest gebruikte voorbeelden van generatieve AI. LLMs zijn “next token predictors”.[1] Deze taalmodellen zetten woordelementen om in numerieke waarden (tokens). Elk woorddeel kan, afhankelijk van het gebruikte model, een veelheid aan waarden bevatten, die allemaal een andere lading hebben en iets kunnen zeggen over bijvoorbeeld het type woord, de functie in een zin, de mate van “activiteit” en abstractie etcetera. Naast “tokeniseren” is een taalmodel door middel van deep learning technieken in staat om uit te rekenen hoe bepaalde woordelementen zich tot elkaar verhouden. Dat wordt “embedding” genoemd. Al die “embedded tokens” tezamen kun je weergeven als een gigantische multidimensionale ruimte (“vectorspace”) met meerdere assen (voor elke waarde één), waarin alle woordelementen uit een bepaalde taal zijn opgenomen en in elkaars context geplaatst.

Deep learning vindt doorgaans plaats in meerdere “lagen” van iteraties waarin er door het algoritme zelf (dus “unsupervised”) clusters worden gemaakt van tokens die zich in elkaars nabijheid bevinden. Het deep learning algoritme gaat aan de hand van statistische regels en door het algoritme zélf gedefinieerde variabelen op zoek naar correlaties tussen tokens, waarbij in elke opvolgende laag er een verfijning plaatsvindt. Dit is tot op zekere hoogte een “black box”, waardoor het niet altijd mogelijk is om te reconstrueren hoe de clustering en het correleren heeft plaatsgevonden. Voor de beste resultaten, moet het model getraind zijn met een zo groot mogelijke hoeveelheid voorbeeldteksten: hoe groter de set met “trainingsdata”, des te nauwkeuriger.

Vervolgens kan een taalmodel, dus op basis van de ingeleerde onderlinge tokenrelaties, aan de hand van een set inputwoorden (in een prompt), voorspellen wat de meest waarschijnlijke opvolgende woordelementen zijn, en die als output presenteren. Elke keer dat je een prompt invoert, gaat het taalmodel opnieuw (althans gedeeltelijk, er worden binnen bestaande gesprekken meestal ook delen van eerdere zoekopdrachten en de contexten daarvan opgeslagen en hergebruikt) op zoek naar de meest waarschijnlijke onderlinge tokenrelaties. Vaak liggen de uitkomsten erg dichtbij elkaar, en elke keer dat de kansrekening wordt uitgevoerd bestaat de mogelijkheid dat het model een net iets andere route aflegt door de vectorspace. Dat brengt mee dat je steeds andere antwoorden kan zien als resultaat van eenzelfde zoekopdracht.

Hoewel het voorkomt dat er volledig correcte antwoorden worden gegeven, moet je er altijd rekening mee houden dat dat niet altijd zo zal zijn. De output bestaat namelijk uit de meest waarschijnlijke antwoorden – en die kunnen dus ook een beetje juist, of volledig onjuist zijn. Als er geen echt voor de hand liggende antwoorden zijn, krijg je toch minder – soms in het echt geenszins relevante of ronduit onjuiste – uitkomsten te zien: dit wordt wel aangeduid als hallucinatie.

LLM-ontwikkelaars proberen wel zoveel mogelijk hallucinatie te voorkomen – op basis van correcties en het aanbrengen van “eenrichtingsverkeersaanduidingen” in hun modellen, maar geheel uitsluiten van hallucinatie is onmogelijk, dat is nu eenmaal inherent aan de technische functionaliteit.

Dat brengt mee, dat LLM-uitkomsten nooit volledig voor waar kunnen worden aangenomen, en dat nooit geheel kan worden gereconstrueerd hoe een antwoord op een prompt tot stand is gekomen. Wil je als juridisch professional op zoek naar de betekenis van algemene juridische leerstukken kom je waarschijnlijk een heel eind, maar als je een overzicht van alle daarbij behorende jurisprudentie wilt zien, kan je er niet op vertrouwen dat het lijstje a) volledig is en b) klopt. Dat betekent, dat je als LLM-gebruiker dus in staat moet zijn om dat te controleren. Uiteraard gaat dat beter als je kennis van het betreffende leerstuk hebt en de jurisprudentie kunt verifiëren, maar voorzichtigheid blijft geboden.

2.      Input- en trainingsdata: kwaliteit en verantwoording

Hierboven beschreef ik dat LLMs zoveel mogelijk data nodig hebben om de modellen te trainen en (doorlopend) te verfijnen, om zodoende tot zo goed mogelijke resultaten te komen. Dit brengt mee, dat LLM-ontwikkelaars een enorme datahonger hebben. Daarbij wordt niet altijd acht geslagen op de vraag of er mogelijk juridische beletsels zijn die in de weg staan aan het opslokken van informatie, ongeacht waar die op internet te vinden is.

i.                     Persoonsgegevens

Als input- en trainingsdata bijvoorbeeld persoonsgegevens bevatten waarop de Algemene Verordening Gegevensbescherming (AVG) van toepassing is, is het telkens de vraag of die verwerking (invoeren van gegevens en het tokenizen/embedden daarvan zijn afzonderlijke verwerkingen) kan worden gelegitimeerd in de zin van de AVG. Het is een veelgehoorde misvatting dat als je de direct identificerende gegevens weghaalt uit een dataset (zoals NAW-gegevens, email- of IP-adressen), er daarmee geen sprake meer is van persoonsgegevens: ook als informatie indirect herleidbaar is naar een persoon blijft er sprake van persoonsgegevens. Zonder hier op de details in te willen gaan (zie bijvoorbeeld de Opinie 18/2024 van de European Data Protection Board voor een uitvoeriger bespreking),[2] is vaak de eerste horde al lastig te nemen: weinig input- en trainingsverwerkingen kunnen worden gelegitimeerd op basis van een (schijnbaar) eenvoudige grondslag zoals het “gerechtvaardigd belang” en vaak is (geïnformeerde) toestemming van alle betrokken noodzakelijk. Ook is het feit dat persoonsgegevens voor altijd verdwijnen in vaak Amerikaanse of Chinese LLM-databases, zonder dat te achterhalen is (of wordt verantwoord) op welke wijze dat gebeurt, in AVG-perspectief zeer problematisch. Daarnaast zou je als gebruiker de vraag kunnen stellen bij het bepalen van het gebruik of het soort gebruik van een LLM, of het in moreel opzicht wel juist is om van technologie gebruik te maken op de voorgenomen wijze, wetende dat de aanbieders het niet zo nauw nemen met het recht op privacy dat in de Europese Unie als fundamenteel recht wordt beschermd.

Voor de gebruiker die zelf geen persoonsgegevens invoert, maar ze wel als output gepresenteerd krijgt en daar vervolgens iets mee doet (bijvoorbeeld op grond van de prompt “wie is de rijkste persoon van Nederland en waar woont deze”),[3] zal dit meebrengen dat deze gebruiker wordt bestempeld als verwerkingsverantwoordelijke, die om te beginnen niet kan verantwoorden wat de herkomst is van de gegevens. Los van de overige privacyregels waar de verantwoordelijke gebruiker zich aan moet houden voor diens voorgenomen gebruik van de gegevens, levert het feit dat de “output” vaak ook als “input” door de modelaanbieder wordt hergebruikt wellicht nog de grootste compliancehobbels op. Ik ga verder in op de punten waarmee de gebruiker rekening moet houden die wel persoonsgegevens invoert in een LLM in onderdeel 3 hierna.

ii.                   Intellectuele eigendomsrechten

Een groot gedeelte van de door LLMs voor trainingsdoeleinden gebruikte informatie die van het internet werd geschraapt door de modelaanbieders, is beschermd door intellectuele eigendomsrechten, waaronder auteursrecht. Auteursrecht ontstaat “van rechtswege” op het moment dat een menselijke maker een werk tot stand brengt (bijvoorbeeld een tekst, een foto, filmpje, muziek etcetera) dat kan worden aangemerkt als diens “eigen intellectuele schepping” , waarbij bepaalde “vrije creatieve keuzes” zijn gemaakt. De lat ligt laag: zelfs krantenkoppen van 11 woorden kunnen al auteursrechtelijk beschermd zijn. De rechthebbende komt vervolgens het recht toe om te verbieden (of toe te staan) dat anderen het werk verveelvoudigen en/of openbaarmaken – behoudens enkele uitzonderingen. Als een rechthebbende toestemming verleent aan een derde om deze “exploitatiehandelingen” te verrichten, heet dat een licentie.

Als een LLM auteursrechtelijk beschermde werken “oogst” door daar een kopietje van te maken ten behoeve van tokenizen en embedden, is dat een verveelvoudiging. Het tokenizen en embedden gaat vaak gepaard met een nieuwe verveelvoudiging, en op het moment dat (delen van) beschermde werken als output worden weergegeven aan LLM-gebruikers is dat weer een verveelvoudiging, én in veel gevallen ook een openbaarmaking in auteursrechtelijk opzicht. Daarvoor is – behoudens enkele uitzonderingen – toestemming nodig van de rechthebbenden, die in veel gevallen niet toereikend is verkregen door de aanbieders van grote LLMs van bijvoorbeeld Meta, Anthropic, OpenAI en Microsoft. Hierover wordt op dit moment veel geprocedeerd in de Verenigde Staten,[4] maar ook in de EU worden er diverse rechtszaken gevoerd.

Een belangrijke, en mijns inziens ook voor Nederland richtinggevende uitspraak komt van het Landgericht in München in een dispuut tussen de Duitse collectieve rechtenbeheersorganisatie GEMA en OpenAI. Volgens GEMA was toestemming vereist voor 1) het “memoriseren” van Duitse liedteksten in de ChatGPT-modellen en 2) het reproduceren daarvan in de ChatGPT’s output, op basis van “simpel prompten”, en het openbaarmaken daarvan. GEMA kreeg gelijk.[5] Ook kon OpenAI zich niet op de tekst- en datamininguitzondering (TDM-exceptie) beroepen.

De TDM-exceptie komt uit de Europese DSM-richtlijn, (“inzake auteursrechten en naburige rechten in een digitale eengemaakte markt”) en is geïmplementeerd in de Auteurswet. In het kort komt die uitzondering erop neer dat je onder bepaalde omstandigheden, ten behoeve van tekst- en datamining (wat nodig is om LLM-modellen te trainen) reproducties mag maken van auteursrechtelijk beschermde werken. Als degene die dergelijke reproducties wil maken (een TDM’er) een onderzoeks- of erfgoedinstelling is, mag dat, ten behoeve van wetenschappelijk onderzoek, onder de voorwaarde dat de instelling rechtmatige toegang heeft tot de bronnen waaruit wordt geput. Als zo’n wetenschappelijk oogmerk ontbreekt, of is sprake is van een ander type TDM’er (zoals juristen die een praktijk uitoefenen), mag TDM ook maar geldt er een extra voorwaarde. Naast de noodzakelijke rechtmatige toegang tot de bronnen, moet de “gewone” TDM’er namelijk ook rekening houden met eventueel gemaakte voorbehouden die het TDM’en beletten. Als de rechthebbenden “op passende wijze uitdrukkelijke wijze [hebben] voorbehouden, zoals [door middel van] machinaal leesbare middelen in het geval van online ter beschikking gestelde content”,[6] mag er geen gebruik worden gemaakt van de betreffende content. Overigens kan de TDM-exceptie niet worden gebruikt om te rechtvaardigen dat de LLM-output auteursrechtelijk beschermde content bevat, ook al had deze mogen worden “opgezogen en verwerkt” voor trainingsdoeleinden: voor output is meestal toestemming nodig.

OpenAI maakte dus door het tokenizen en embedden van auteursrechtelijk beschermde songteksten reproducties, en kon volgens het Münchener Landgericht geen gebruik maken van de TDM-exceptie. Mijns inziens legt het Landgericht het auteursrecht in dezen goed uit, en is de kans groot dat de Nederlandse rechter tot een soortgelijke conclusie zou komen. Dat betekent, dat wanneer je bijvoorbeeld een dossier met processtukken wilt laten checken op inconsistenties, een contract wilt laten vertalen, een brief wilt analyseren of waar je dan ook een LLM voor zou willen inzetten, je rekening moet houden met het auteursrecht dat daarop kan rusten: het invoeren, tokenizen, embedden en het uitvoeren brengt reproductiehandelingen mee. Gebruik je vervolgens de output in een processtuk, advies, contract of iets degelijks, maak je vervolgens ook de werken openbaar. Daar is dus toestemming voor nodig van de rechthebbenden.

Nog een herhaalde nota bene: in veel gevallen gaat hetgeen je invoert, ook onderdeel uitmaken van de databases van de modelaanbieders zelf, en heb je zeer waarschijnlijk geen invloed meer op de voortdurende (mogelijk onrechtmatige) reproducties en openbaarmakingen die daar nadien het gevolg zijn. Het zou goed kunnen dat je daarmee zelf auteursrechtinbreuk pleegt (door het in te voeren)/laat plegen (doordat je mogelijk een modelaanbieder toestemming hebt gegeven om het ingevoerde materiaal te hergebruiken), waarvoor je aansprakelijk kunt worden gehouden.

Uiteraard gelden deze uitgangspunten ook bij het laten inrichten van een “eigen” versie van een taalmodel, bijvoorbeeld specifiek ten behoeve van een advocatenkantoor, dat wordt gevoed en getraind met de contracten, procesdossiers en adviezen die onderdeel uitmaken van het kantoordocumentatiesysteem. Of het trainen (tokenizen en embedden) van het model kan worden gebaseerd op de TDM-exceptie is niet uitgesloten. Je moet dan wel kunnen verantwoorden dat er “rechtmatige toegang” was en er geen TDM-voorbehouden zijn gemaakt. Het operationaliseren door dagelijks gebruik te maken van het “eigen” ingeleerde taalmodel kan niet worden gebaseerd op de TDM-exceptie. Voor dat gebruik is dus, als er auteursrechtelijk beschermde content van derden mee gemoeid is, toestemming nodig van de rechthebbenden.

iii.                 Vertrouwelijke informatie

Het voorgaande is, mutatis mutandis, ook van toepassing op het invoeren van vertrouwelijke informatie. Zodra je die invoert, wordt deze getokenized en geëmbed, en maakt deze waarschijnlijk voor altijd onderdeel uit van het taalmodel. Als er gebruik wordt gemaakt van een openbare LLM, bestaat het risico dat elke willekeurige gebruiker deze voorheen vertrouwelijke informatie als output te zien krijgt. Als dat het geval is, zou dat in strijd kunnen zijn met mogelijke geheimhoudingsafspraken, en kan het ook onrechtmatig zijn in de zin van de Wet bescherming bedrijfsgeheimen (Wbb). Een bedrijfsgeheim is (samengevat) geheime informatie die niet algemeen bekend is, of gemakkelijk toegankelijk is binnen een bepaalde sector; bezit handelswaarde omdat het geheim is; en is onderworpen aan redelijke maatregelen om deze geheim te houden. Het zou onrechtmatig kunnen zijn in de zin van artikel 2 lid 2 Wbb om een bedrijfsgeheim dat je van een derde hebt ontvangen in te voeren in een LLM, als je daarvoor geen toestemming had, en er geheimhouding is afgesproken.

Nota bene voor advocaten: afgezien van de Wbb, is er ook nog de Advocatenwet. Die schrijft voor dat die (en dienst medewerkers) geheim moet houden “al hetgeen waarvan hij uit hoofde van zijn beroepsuitoefening als zondanig kennisneemt” – enkele uitzonderingen daargelaten.

Concluderend: met het trainen van LLMs vinden reproductiehandelingen plaats. Die kunnen worden aangemerkt als verwerking van persoonsgegevens als daar informatie inzit die (in)direct herleidbaar is tot een natuurlijke persoon. Anonimisering is lastig en vaak onmogelijk – wat meebrengt dat je rekening moet houden met de regels uit de AVG. Als dergelijke verwerkingen al kunnen worden gelegitimeerd (op basis van het gerechtvaardigd belang of (uitdrukkelijke) toestemming, is het problematisch (en nauwelijks te verantwoorden) als persoonsgegevens voor altijd “verdwijnen” in de vectorspaces van de vaak niet in de EU gevestigde modelaanbieders. Als er bedrijfsgeheimen worden ingevoerd, moet je er rekening mee houden dat het voorgaande meebrengt dat dat invoeren in strijd kan zijn met contractuele en wettelijke verplichtingen, uit hoofde van een geheimhoudingsovereenkomst, de Wet bescherming bedrijfsgeheimen en/of de Advocatenwet (voor zover deze van toepassing is op de jurist in kwestie). Invoeren van auteursrechtelijk beschermde informatie is een reproductiehandeling. Tokenizen en embedden zijn dat ook. Dat geldt evenzeer voor het gebruik van auteursrechtelijk beschermde output (en dat kan aanvullend ook nog een openbaarmakingshandeling betekenen). De TDM-exceptie zal maar in weinig gevallen soelaas bieden (hooguit voor “eigen” training van LLMs, maar niet ten aanzien van reproductie door LLMs van auteursrechtelijk beschermde content als prompt-output), en legitimeert niet het opnemen van deze content door modelaanbieders in hun modellen.

3.      Verantwoordelijkheid voor operationele inzet LLMs

i.                     Privacy en auteursrecht

Privacy

Gebruikers van LLMs die (in)direct herleidbare informatie in een LLM-prompt invoeren worden gezien als “verwerkingsverantwoordelijken” onder de AVG. Ik herhaal nog eens dat anonimiseren erg lastig is, zeker als je bedenkt dat een LLM erg goed in staat is om bepaalde informatie in elkaars context te plaatsen, en zo ook zélf persoonsgegevens kan genereren uit informatie die voorheen niet als persoonsgegeven hoefde te worden aangemerkt. Dat betekent dat invoerende gebruikers zelf verantwoordelijk (en aansprakelijk) zijn voor het al dan niet voldoen aan de AVG-vereisten.

Stel nu bijvoorbeeld dat je in een echtscheidingszaak een processtuk wilt laten opstellen met behulp van een LLM, waarbij er een alimentatieberekening moet worden gemaakt. Daartoe voer je onder meer in: de namen van de gewezen echtelieden en de gegevens over de financiële behoeften en draagkracht. Al deze gegevens zijn persoonsgegevens in de zin van de AVG. Er is om te beginnen een wettelijke grondslag nodig voor 1) het verwerken van deze gegevens op zich; en 2) het (verder) verwerken van deze gegevens met behulp van een LLM. Aannemende dat er een toereikende grondslag is voor die eerste verwerking, is het de vraag of en zo ja hoe het inschakelen van een LLM kan worden gelegitimeerd voor dit doel. Van de zes in de AVG genoemde verwerkingsgrondslagen, komen er twee mogelijk in aanmerking: toestemming van de betrokkenen of het gerechtvaardigde belang van de verwerkingsverantwoordelijke.

Voor het kunnen bepalen of er sprake is van een gerechtvaardigd belang, moet je aan drie cumulatieve vereisten voldoen. Ten eerste moet sprake zijn van een daadwerkelijk belang. Dat kan wellicht worden gevonden, in algemene zin, in het zo efficiënt mogelijk bijstaan van een cliënt in een procedure. Ten tweede moet je kunnen aantonen dat het noodzakelijk is om de persoonsgegevens door middel van een LLM te verwerken. Dat is al lastiger: ook zonder een LLM kun je prima een alimentatieberekening maken: het kan “met de hand”, of met technische hulpmiddelen die minder ingrijpen in de persoonlijke levenssfeer van de cliënt en de wederpartij. Ten derde moet er een belangenafweging worden gemaakt, waarbij het privacybelang wordt afgewogen tegen het “efficiency”-belang van de advocaat. Wetende dat LLMs notoir slecht zijn in rekenen (ook hier wordt gehallucineerd door taalmodellen); dat je nauwelijks kunt voorkomen dat input-informatie, en dus ook persoonsgegevens, verdwijnen in de vectorspace en dat betrokkenen (dus ook de wederpartij) er in beginsel niet op bedacht hoeven zijn dat er met een LLM zou worden gewerkt om een alimentatieberekening te maken, lijkt het mij niet voor de hand liggen dat aan deze derde eis kan worden voldaan. Kortom: mij lijkt dat er niet snel sprake zal zijn van een gerechtvaardigd belang dat de advocaat kan inzetten om een LLM te gebruiken voor het maken van dit soort processtukken. Let op: de gerechtvaardigd-belanggrondslag is niet toereikend  als er wordt gewerkt met bijzondere persoonsgegevens,[7] dan is er namelijk ook nog een uitzondering nodig op het standaard verwerkingsverbod van dit soort persoonsgegevens. De enige die daarvoor waarschijnlijk in aanmerking komt, is als sprake is van “uitdrukkelijke toestemming” van betrokkenen. Dat gaat nog verder dan de “gewone” toestemmingsgrondslag die ik hierna zal bespreken.

Terug naar onze casus, waarbij er “gewone” persoonsgegevens worden verwerkt. De tweede mogelijke grondslag is die van de toestemming van betrokkenen. Beide gewezen echtelieden moeten dan van te voren toestemming geven voor het inzetten van een taalmodel. Daarbij moet in duidelijke en begrijpelijke taal worden aangegeven waar precies toestemming voor wordt gevraagd en die toestemming moet in vrijheid kunnen worden gegeven. Dat betekent dat je niet met een vooraf ingevulde verklaring mag werken, of – als je die toestemming elektronisch wilt ophalen – met een vooraf gezet toestemmingsvinkje, en dat ook de mogelijkheid moet worden om geen toestemming te verlenen zonder dat dit consequenties heeft voor de betrokkenen.[8] Ook moet worden geborgd dat de toestemming (op even gemakkelijke wijze) weer kan worden ingetrokken. Dat heeft tot gevolg dat er vanaf het moment van intrekken, er geen grondslag meer is voor (verdere) verwerking van de betreffende gegevens. Waar het nog wel moet lukken om aan cliënten te vermelden dat de toestemming behelst dat de betreffende persoonsgegevens zullen worden ingevoerd in een LLM, zal het lastiger – zo niet onmogelijk – zijn om te voorkomen dat bij het intrekken van de toestemming, de persoonsgegevens die onderdeel zijn gaan uitmaken van de vectorspace niet verder verwerkt zullen worden. Als je dus niet heel zeker weet of je kunt borgen dat de prompt-input niet ook wordt opgenomen in de modellen zelf, kan je dus ook geen gebruik maken van de toestemmingsgrondslag.

Naast allerhande overige AVG-compliance-eisen (van registerplichten via verwerkersovereenkomsten tot adequate beschermingsmaatregelen, dataminimalisatie, data-export buiten de EER etcetera, etcetera) wil ik in dit verband nog wijzen op de rechten van betrokkenen. Niet alleen moeten betrokkenen van tevoren worden geïnformeerd over alle aspecten van de verwerking (met inbegrip van de derde partijen die betrokken zijn), ook moeten ze onder meer in staat worden gesteld om hun persoonsgegevens in te zien, te corrigeren en (als het doel van de verwerking is bereikt, bijvoorbeeld doordat het processtuk is ingediend en de rechter uitspraak heeft gedaan) te wissen. Nu dat doorgaans wel zou moeten kunnen als de gegevens zich “on premise” van de advocaat bevinden, of op de systemen van diens hostingpartij, zal dat een stuk ingewikkelder zijn als die gegevens zich in de Amerikaanse cloud of – erger nog – in de vectorspace bevinden.

Als gebruikers persoonsgegevens invoeren in een openbare variant van een GenAI-model zal dat vrijwel nooit in lijn kunnen geschieden met de AVG, omdat in de meeste gevallen niet te voorkomen of controleren is of/in hoeverre de ingevoerde gegevens onderdeel gaan uitmaken van de dataset van de LLM-aanbieder. Ook als er betaalde varianten worden gebruikt en er een “lokale” distributie wordt gebruikt van een taalmodel, blijft dit een risico.[9] 

Samenvattend: het lijkt mij in de meeste gevallen lastig om LLMs te voeden met persoonsgegevens op een wijze die in overeenstemming is met de AVG. Handelen in strijd met de AVG leidt (naast reputationele schade) tot mogelijke handhavingsmaatregelen (de Autoriteit Persoonsgegevens kan boetes opleggen tot € 20 miljoen per overtreding) en civiele aansprakelijkheid.

Auteursrecht

Zoals besproken bevatten de vectorspaces van de grote taalmodellen waarschijnlijk grote hoeveelheden auteursrechtelijk beschermd materiaal, die er zonder toereikende toestemming in terecht is gekomen. Op het eerste gezicht is dat vooral “het probleem” van de modelaanbieder, maar de juridische implicaties kunnen verstrekkender zijn.

Als “gewone” LLM-gebruiker, moet je er dus rekening mee houden dat de output van een taalmodel eveneens reproducties kan bevatten van auteursrechtelijk beschermd materiaal, dat dus in strijd met het auteursrecht daarin terecht is gekomen. Dat materiaal kan in de output terechtkomen zonder dat de gebruiker dat weet (bijvoorbeeld omdat er geen of ontoereikende bronvermelding plaatsvindt). Als je vervolgens zo’n beschermd werk opnieuw gebruikt, bijvoorbeeld door het op te nemen in een processtuk, een advies of een ander type uiting, kan je daarmee zelf dus ook in strijd handelen met de rechten van de makers.

Overigens is volledig door een LLM gegenereerde output waarin geen auteursrechten van derden zitten vervat zelf niet het voorwerp van auteursrechtelijke bescherming. Het is immers noodzakelijk dat er een menselijke maker aan het scheppingsproces te pas komt. Als er geen menselijke maker betrokken was bij het tot stand komen van bepaalde output, is er niet voldaan aan het “antropocentrisch vereiste”, en ontstaat er geen auteursrecht.

Kortom: naast het in onderdeel 2 geschetste probleem van het voeden en trainen van taalmodellen met auteursrechtelijk beschermde content, kan ook het gebruiken van output zonder goed te (kunnen) controleren of die auteursrechtelijk beschermd is, leiden tot aansprakelijkheid vanwege auteursrechtinbreuk.

ii.                   Algemene AI-regelgeving

De AI-verordening stelt generieke regels voor het ontwikkelen en toepassen van AI-modellen voor algemene doeleinden, en AI-systemen voor specifieke doeleinden.

Als een jurist in de uitoefening van zijn praktijk een LLM (een AI-model voor algemene doeleinden in de zin van de AI-verordening) gebruikt, is hij in de meeste gevallen gebruiksverantwoordelijke, en de modelaanbieder aanbieder in de zin van de AI-verordening. Mocht het kantoor nu een specifieke implementatie van een LLM laten maken (in die zin dat het kantoor een LLM hetzij zelf ontwikkelt/laat ontwikkelen, of het model “van een ander” onder eigen naam of merk gaat gebruiken of verhandelen),[10] en/of het taalmodel onder het kantoorlabel voeren, dan verwordt het kantoor (ook) tot aanbieder.[11]

Eén van de meest wezenlijke verplichtingen die gelden voor aanbieders en gebruiksverantwoordelijken staat in artikel 4, dat geldt voor alle organisaties waarin AI wordt ingezet, en ziet op AI-bewustzijn van de medewerkers. Daarin staat het volgende:

Aanbieders en gebruiksverantwoordelijken van AI-systemen nemen maatregelen om, zoveel als mogelijk, te zorgen voor een toereikend niveau van AI-geletterdheid bij hun personeel en andere personen die namens hen AI-systemen exploiteren en gebruiken, en houden daarbij rekening met hun technische kennis, ervaring, onderwijs en opleiding en de context waarin de AI-systemen zullen worden gebruikt, evenals met de personen of groepen personen ten aanzien van wie de AI-systemen zullen worden gebruikt.

Dit brengt mee, dat als juristen met AI (moeten/mogen) gaan werken, dat ze bewust moeten zijn van de kansen en risico’s van de in te zetten technieken, dat ze ook het reguleringskader kennen, en degenen die ze gaan bedienen met gebruikmaking van de AI-systemen of -modellen ook daaromtrent informeren.[12]

Aanbieders moeten er tevens voor zorgen dat ze transparant zijn over het feit dat er gebruik wordt gemaakt van LLMs, en dat de LLM-output als zodanig herkenbaar en detecteerbaar is. Als aanbieders gebruikers rechtstreeks laten communiceren met een AI-model (een advocatenkantoor met een eigen chatbot bijvoorbeeld), moeten zij duidelijk maken dat er wordt gecommuniceerd met een AI-model.

Als het gebruikte AI-model systeemrisico’s met zich brengt (die kwalificatie is niet eenvoudig, maar als vuistregel kan worden gehanteerd dat de meeste grote modellen uit de VS en China wel als zodanig kunnen worden geoormerkt) gelden er aanvullende eisen, onder meer met betrekking tot technische documentatie, en beleid met betrekking tot het waarborgen van IE-rechten en bedrijfsgeheimen. Ook moeten ze onder meer het model doorlopend evalueren om risico’s op te sporen en te mitigeren; incidenten rapporteren; fouten corrigeren; en zorgen voor de juiste beveiligingsmaatregelen.[13]

Gebruiksverantwoordelijken moeten transparant zijn over het gebruik van generatieve AI, met name wanneer de output een (audiovisuele) deepfake behelst, of als er teksten worden gegenereerd die bedoeld zijn om het publiek te informeren over zaken van algemeen belang.

Daarnaast moet erop worden gelet dat, als een AI-model naast voor algemene ook voor specifieke doeleinden wordt ingezet, dat dit een andere set regels kan activeren. Zo zijn er bepaalde AI-systemen categorisch verboden. Denk aan “social credit scoring”-systemen, systemen voor emotieherkenning op de werkvloer of in het onderwijs, systemen die misbruik maken van kwetsbaarheden van personen et cetera.[14]

Sommige systemen waarbij de ontwikkeling en uitrol risico’s meebrengen voor burgers met betrekking tot hun grondrechten, veiligheid en gezondheid, worden aangemerkt als  “hoog-risico” AI-systemen. Daarbij kan gedacht worden aan systemen die in arbeidsrelaties of HR-processen worden ingezet (CV’s filteren, banen matchen, werknemersprestaties beoordelen e.d.), systemen voor emotieherkenning (voor zover die niet verboden zijn); AI-systemen die in de rechterlijke macht worden ingezet – et cetera. De verplichtingen voor aanbieders en gebruiksverantwoordelijken zijn verstrekkend – maar die zal ik hier niet en detail bespreken.[15]

Wel wil ik in dit verband wijzen op de “Aanbevelingen AI in de Advocatuur” van de Nederlandse Orde van Advocaten (NOVA),[16] die van toepassing zijn wanneer beroepsbeoefenaren AI willen inzetten ten behoeve van hun clientèle:

iii.                 NOVA-regels

De NOVA heeft onlangs een set aanbevelingen gepubliceerd voor het gebruik van AI in de advocatuur, die aansluiten bij de kernwaarden deskundigheid, vertrouwelijkheid, onafhankelijkheid, integriteit en partijdigheid. Samengevat komen die op het volgende neer.

In verband met kernwaarde deskundigheid schrijft de NOVA voor dat voordat AI mag worden ingezet, de advocaat dient te investeren in kennis over (generatieve) AI, in lijn met de door de AI-verordening voorgeschreven AI-geletterdheidsverplichtingen. Meer specifiek stelt de NOVA dat iedere advocaat kennis dient te vergaren en die steeds bij te houden omtrent “(generatieve) AI, LLM-principes, prompt-engineering, bias-mitigatie, hallucinaties, foutdetectie, juridisch relevante regelgeving en cybersecurity”. Daarnaast wordt gewezen op de noodzaak om LLM-output altijd te verifiëren, en om met leveranciers waarborgen omtrent kwaliteit af te spreken.

Met betrekking tot de kernwaarde vertrouwelijkheid stelt de NOVA dat er nooit vertrouwelijke gegevens of clientdata zouden mogen worden verwerkt wanneer gebruik wordt gemaakt van gratis tools of publieke taalmodellen. Men wijst erop dat er vaak wordt betaald “met data”. Overigens geldt ook ten aanzien van betaalde tools dat je altijd goed moet opletten wat er met de input gebeurt, zoals ik hierboven al beschreef. Daarnaast stelt de NOVA dat je consequent privacy-by-design moet toepassen, door alleen strikt noodzakelijke informatie te delen. Ook wordt gesteld dat je een Data Privacy Impact Assessment zou moeten uitvoeren (mijns inziens kun je daarmee niet volstaan overigens) voorafgaand aan het verwerken van persoonsgegevens met LLMs, en dat je altijd toestemming zou moeten vragen aan een cliënt voor het gebruiken van AI (in algemene zin) in een dossier. Daarnaast wordt gewezen op het belang van het kennen van de datastromen en welke partijen daarbij betrokken zijn – en welke voorwaarden die stellen (ook ten aanzien van IE, zeggenschap over data, aansprakelijkheid en “exit”), en het belang gebruik van de tools binnen de kantooromgeving, en bewustzijn van welke data al dan niet impliciet in het model terechtkomen. 

In verband met de kernwaarde onafhankelijkheid benadrukt de Orde dat AI (op zijn best) een ondersteunende, en nooit een leidende factor mag zijn bij het adviseren van cliënten – en dat een advocaat te allen tijde zelf verantwoordelijk blijft. Dat geldt ook voor het gebruik van AI door medewerkers en leveranciers voor wie de advocaat verantwoordelijk is. Verder wordt gewezen op het gevaar van het bevestigen van (ook onjuiste) aannames door chatbots.

Ter zake van de kernwaarde integriteit schrijft de NOVA voor dat een kantoor een AI-beleid dient te hebben en dat de cliënten daarover dienen te worden geïnformeerd. Ook moet men intern transparant zijn over het gebruik van AI op kantoor. Op deze plek wijst men er nogmaals op dat input-data ook kunnen worden opgenomen in de vectorspace, en dat dat problemen kan geven: de NOVA noemt “datalekken” als expliciet voorbeeld. Ook herhaalt de Orde dat AI-output nooit ongecontroleerd mag worden overgenomen.

Ten aanzien van de kernwaarde partijdigheid leken de argumenten een beetje “op”, en herhaalt de NOVA nog maar eens dat AI nooit leidend mag zijn, en dat de advocaat altijd zelf verantwoordelijk blijft voor een partijdige maar rechtmatige belangenbehartiging.

Ook in Europees verband is er beleid: de Council of Bars and Law Societies of Europe (CCBE) heeft een uitgebreide en goed leesbare gids geschreven op dit terrein.[17] De Koninklijke Notariële Beroepsorganisatie heeft eveneens een beleidskader vastgesteld voor notarissen dat nog in ontwikkeling is, en nog vrij algemeen van aard.[18]

4.      Samenvatting en nog een ecologische overweging nota bene

Bezint eer gij begint is het devies. Wees je bewust van het feit dat LLMs niets meer of minder zijn dan “next token predictors” met een onbedwingbare “will to please”: géén resultaat bestaat niet, je krijgt altijd de meest waarschijnlijke output te verwerken. Hallucinatie ligt steeds op de loer. Stel je dus telkens de vraag of je écht wel een LLM nodig hebt bij jouw juridische werk, en als je vindt dat zo is:

-          Zorg voor AI-geletterdheid bij alle mensen in de organisatie die met AI in aanraking kunnen komen;

-          Check de input: voer geen bedrijfsgeheimen, cliëntgegevens, dossier-informatie, persoonsgegevens of door een auteursrecht (of ander IE-recht) beschermd werk in;

-          Omdat vrijwel niet te voorkomen is dat je persoonsgegevens verwerkt met LLMs:

o   Zorg voor AVG-compliance (als dat al mogelijk is) – en let daarbij ook op het beleid van de toezichthouders AP en EDPB

-          Verifieer de output:

o   Zijn er niet per ongeluk persoonsgegevens uitgerold?

o   Maakt de output inbreuk op een IE-recht van een derde?

o   Klopt het überhaupt wel wat er staat? Check de inhoud én de bronverwijzingen;

-         Voorkom dat de output verdwijnt in de vectorspace, zeker als er onverhoopt toch persoonsgegevens, IE, bedrijfsgeheimen etcetera zouden kunnen worden ingevoerd op een onbewaakt ogenblik;

-         Voor advocaten: wees je bewust van de gedragsregels en de uitleg daarvan in verband met AI door de NOVA (die gaan vrij ver, en schrijven o.a. voor dat je toestemming vraagt aan cliënten).

Een laatste overweging, die als deze al wordt meegewogen in bijvoorbeeld AI-beleid, hooguit als sluitpost fungeert, maar die ik van wezenlijk belang vind, betreft ecologie en duurzaamheid. Onderzoek wijst uit dat de ecologische footprint van LLMs enorm is.[19] Het United Nations Environment Programme meldt het volgende. Er zijn veel (vaak zeldzame) grondstoffen nodig om de hardware te vervaardigen, waarvoor geldt dat de productie vaak ten koste gaat van de leefomgeving; er is een “e-waste” afvalprobleem, want lood en kwik zijn lastig te verwerken reststoffen; er is heel veel water nodig om de computers mee te koelen; en gemiddeld genomen kost het uitvoeren van een ChatGPT-prompt 10x zoveel energie als een vergelijkbare Google-search. Naar schatting consumeren AI-datacenters in Ierland (waar veel datacenters staan van AI-giganten) 35% van alle energie aldaar.

Al met al kom ik vaak tot de conclusie dat ik beter geen LLM kan gebruiken voor mijn juridische werkzaamheden – en doe dat dan ook vrijwel nooit. Als ik LLMs gebruik, dan hooguit als geavanceerde zoekmachine om richting te geven aan een verdere zoektocht naar informatie.