Ik ben architect, geen jurist. Zie dit daarom vooral als een ontwerpvisie en niet als juridisch advies. Wat ik wel heb geleerd, is dat compliance veel goedkoper is wanneer je die vanaf het ontwerp meeneemt dan wanneer je haar na livegang moet repareren.
Twee wetten, twee verschillende vragen
De GDPR stelt vragen over data: van wie is die data, waar gaat die naartoe, met welk doel en hoe lang bewaar je die?
De AI Act stelt vragen over het gebruik: waarvoor wordt het systeem ingezet en hoeveel schade kan het veroorzaken? De AI Act classificeert op basis van het doel, niet op basis van de techniek. Dezelfde documentassistent is minimaal risicovol wanneer hij vragen beantwoordt op basis van je IT-documentatie, maar kan onder de high-risk categorie vallen wanneer hij beslissingen over bijvoorbeeld werving, kredietverlening of toegang tot essentiële diensten ondersteunt.
De planning is deze zomer verschoven. Met de Digital Omnibus on AI, die eind juni 2026 is aangenomen, gaan de verplichtingen voor zelfstandige high-risk AI-systemen in op 2 december 2027 in plaats van augustus 2026. Dat is uitstel, geen vrijstelling. Systemen die vandaag worden ontworpen, draaien in december 2027 nog steeds. De transparantieverplichtingen, zoals mensen informeren dat ze met een AI-systeem te maken hebben, vallen niet onder dat uitstel.
Wat je ook bouwt, van één enkele modelaanroep tot een autonome agent, het ontwerp bepaalt het antwoord op vier vragen. Beantwoord je die bewust, dan wordt het grootste deel van het compliancegesprek een kwestie van aantonen hoe je het hebt ingericht.
1. Waar gaat de data naartoe?
Persoonsgegevens in een prompt verlaten je eigen omgeving. Daarmee wordt de modelleverancier een verwerker, met alles wat daarbij hoort: een overeenkomst, een bekende verwerkingslocatie en een bewaartermijn voor prompts. De ontwerpvraag is eenvoudig en wordt toch vaak overgeslagen: welke velden moeten daadwerkelijk in de prompt terechtkomen? Voor een samenvatting van een klacht heb je zelden het adres van de klant nodig.
Ook kopieën tellen mee. Een zoekindex die je voor het model bouwt, is een kopie van je data en vaak ook van persoonsgegevens. Een verzoek om gegevens te wissen moet die index en eventuele caches bereiken, niet alleen het bronsysteem. En pas op voor de batchjob die begint met: "Nu we het kunnen, laten we het hele archief erdoorheen halen." Dat archief is ooit voor een bepaald doel verzameld, en dat doel dekt deze verwerking misschien helemaal niet. Verwerking op die schaal is een typische aanleiding voor een Data Protection Impact Assessment.
Nog een belangrijk onderscheid: de locatie van een datacenter en de jurisdictie waarin de exploitant van dat datacenter valt, zijn twee verschillende vragen. Vraag dus naar beide.
2. Wie mag wat zien en doen?
Een model heeft zelf geen rechten. Het zou precies dezelfde rechten moeten hebben als de persoon namens wie het op dat moment werkt, en niets meer. Wanneer het documenten ophaalt, moet de toegangscontrole plaatsvinden op het moment van ophalen. Anders kan het model zonder moeite HR-documenten citeren aan iemand van Sales. Wanneer het functies in je systemen aanroept, doet het dat met de rechten van die gebruiker, via credentials die beperkt zijn en maar kort geldig blijven.
Vertrouw hiervoor niet op instructies in de prompt. Een system prompt is adviserend, en modellen die koste wat kost een taak willen afronden, blijken die instructies soms te negeren. Beperkingen horen thuis in de infrastructuur: rechten, een gateway die weigert wat niet is toegestaan en een bevestiging voordat iets onomkeerbaars gebeurt.
3. Wie neemt de beslissing?
Artikel 22 van de GDPR beperkt beslissingen die uitsluitend gebaseerd zijn op geautomatiseerde verwerking en die mensen significant raken. In de SCHUFA-zaak uit 2023 oordeelde het Europees Hof van Justitie dat een automatisch berekende kredietscore op zichzelf zo'n beslissing kan zijn wanneer de partij die de score gebruikt er zwaar op leunt. Voor high-risk systemen voegt de AI Act daar expliciete eisen voor menselijk toezicht aan toe.
Een reviewer die iedere suggestie bevestigt zonder die daadwerkelijk kritisch te beoordelen, verandert daar niets aan. Als je wilt dat de mens daadwerkelijk een rol speelt, moet je het systeem daar ook op ontwerpen. Laat het bewijs zien, niet alleen het antwoord. Geef reviewers de tijd en de bevoegdheid om het oneens te zijn en meet hoe vaak ze dat doen. Laat duidelijke gevallen automatisch doorstromen en stuur onzekere gevallen naar iemand die de tijd heeft om ze te beoordelen. Stel de drempel daarbij niet alleen vast op basis van het vertrouwen van het model, maar ook op basis van de kwaliteit van de data.
Eén regel pas ik overal toe: wat het model leest, mag een beslissing informeren, maar nooit autoriseren. Als in een beleidsdocument staat dat refunds tot een bepaald bedrag zijn toegestaan, wordt die regel uit het document gehaald, gecontroleerd en in code afgedwongen. Het model mag het beleid niet lezen en vervolgens zelf bepalen wat wel en niet mag. Anders kan iedereen die het document kan aanpassen, veranderen wat je systeem mag doen.
4. Kun je achteraf bewijzen wat er is gebeurd?
Vroeg of laat vraagt iemand waarom een bepaalde uitkomst tot stand is gekomen. Een klant, een auditor of een toezichthouder. Voor high-risk systemen vereist de AI Act dat gebeurtenissen gedurende de levensduur van het systeem automatisch worden gelogd. Maar eigenlijk wil je voor ieder systeem maanden later één specifieke uitkomst kunnen reconstrueren: welke gebruiker, welke data, welke modelversie, welke prompt en welke actie. Prompts en modelversies zijn configuratie en verdienen dezelfde versiecontrole als code.
Security is óók een compliancevraag
Er is één combinatie die een behulpzame assistent in een datalek kan veranderen. Simon Willison noemde dit de lethal trifecta: toegang tot private data, blootstelling aan onbetrouwbare content en de mogelijkheid om extern te communiceren. Een assistent die inkomende e-mails kan lezen, in je CRM kan kijken en berichten kan versturen, kan door één slim geschreven e-mail worden aangezet om klantdata naar buiten te sturen.
Haal één van die drie mogelijkheden weg en die aanval kan niet meer plaatsvinden. En onder de GDPR is een datalek via een AI-assistent nog steeds gewoon een datalek.
Wat hoort in ieder ontwerp?
Welke use case je ook hebt, ik wil drie dingen geregeld hebben:
- een datamap per prompt: welke velden verlaten je omgeving, naar welke provider, in welke regio en hoe lang worden ze bewaard;
- logging waarmee je maanden later één specifieke uitkomst kunt reconstrueren;
- een schakelaar per AI-feature, zodat je die kunt uitschakelen zonder de applicatie uit de lucht te halen.
Als je dit vanaf het begin inbouwt, is geen van deze drie dingen duur. Als je ze pas na een incident of een auditvraag moet toevoegen, zijn ze dat allemaal wel.
De AI Act classificeert waarvoor je AI gebruikt. Je architectuur bepaalt of je dat ook kunt bewijzen.
Voordat het contract wordt getekend
Sta je op het punt een taalmodel toe te voegen aan een proces waarin klant- of personeelsgegevens worden verwerkt? Betrek je functionaris voor gegevensbescherming dan vroegtijdig en betrek de architectuur daarbij tegelijkertijd. De meeste vragen die zij zullen stellen, hebben antwoorden die in het ontwerp zitten.
Wij helpen je graag om die antwoorden te vinden zolang ze nog goedkoop te veranderen zijn.
