---

Wetgeving in het ontwerp, niet erachteraan

De meeste AI-projecten doen de juridische toets aan het eind. Dan staat er een werkende oplossing, en dan blijkt hij hoog risico te zijn, persoonsgegevens te verwerken die er niet in hoorden, of data naar een leverancier te sturen die daar niet naartoe mocht. Dan heb je voor niets gebouwd. Daarom zit de toets bij ons in stap 4, bij het ontwerp, naast de zeven criteria.

Vier vragen die het ontwerp bepalen

We lopen bij elk ontwerp vier gebieden na. Niet als checklist die je afvinkt, maar als vragen waarvan het antwoord verandert wat we bouwen.

De AI-verordening. Welke risicoklasse geldt voor deze toepassing? Een agent die vergunningsaanvragen beoordeelt, raakt aan besluiten over burgers en zit daarmee in een andere categorie dan een zoekfunctie over interne handleidingen. Die klasse bepaalt de eisen: documentatie, menselijk toezicht, logging, en of het überhaupt mag. Twee dingen worden vaak vergeten. Weten gebruikers dat ze met AI werken? En zijn je mensen voldoende AI-geletterd om ermee te werken? Dat laatste is een plicht uit de verordening, geen goed idee.

De AVG. Grondslag en doelbinding: mag je deze gegevens hiervoor gebruiken? Dataminimalisatie: ziet het model niet meer dan nodig? Vaak kunnen we een proces laten werken met een fractie van de gegevens die er in het oorspronkelijke idee in zaten. Een DPIA als de verwerking daarom vraagt. En de regel die het ontwerp het meest bepaalt: geen besluiten over mensen zonder menselijke tussenkomst. Dat is waarom de mens in de loop bij ons geen keuze is maar een ontwerpvraag: waar zit hij, en is zijn controle echt.

Regels uit je sector. NIS2, DORA, BIO, medische of financiële toezichtregels. Wat voor je organisatie geldt, geldt ook voor de AI die je inzet. Een gemeente onder de BIO heeft andere eisen aan waar data staat dan een opleider, en een verzekeraar onder DORA moet kunnen aantonen dat een uitbestede dienst beheersbaar is. Dit is meestal de plek waar de vraag naar soevereiniteit wordt beslist: niet uit principe, maar omdat de regels het vragen.

Eigendom en bedrijfsgeheim. Wat mag er naar een leverancier toe, en wordt het daar gebruikt om modellen te trainen? Van wie is wat eruit komt? Een contract dat zegt dat je data niet wordt gebruikt voor training, helpt niet als de instelling in het platform anders staat. Contract en instellingen moeten hetzelfde zeggen, en we controleren beide.

Wat de toets doet met het ontwerp

De uitkomst van deze vier vragen is geen memo maar een aantal ontwerpkeuzes. Een paar voorbeelden van hoe dat in de praktijk uitpakt:

• Een toepassing die hoog risico blijkt, krijgt de mens niet achteraf als steekproef maar vooraf als goedkeurder, per geval.
• Als de sectorregels dataverblijf in Nederland of de EU vragen, valt een deel van de modelkeuze weg voordat we een regel code schrijven. Dan kijken we naar Scaleway of een eigen omgeving, en accepteren we dat het model soms iets minder sterk is.
• Als dataminimalisatie mogelijk is, wordt het ontwerp vaak simpeler: minder gegevens betekent minder koppelingen, minder rechten, minder audittrail.
• Als er onduidelijkheid is over eigendom van de uitkomst, kiezen we een leverancier of instelling waar dat wél helder is, ook als die duurder is.

Waarom dit bij stap 4 hoort en niet bij stap 6

Het argument om de toets uit te stellen klinkt redelijk: eerst kijken of het werkt, dan pas de juridische discussie. Maar een proof of concept die met echte data werkt, is zelf al een verwerking. En een ontwerp dat na de PoC alsnog moet worden omgebouwd voor toezicht, logging of dataverblijf, is meestal een herbouw. De toets bij het ontwerp kost een gesprek van een uur. Achteraf kost hij weken.