Valkuilen automatische besluiten: AVG 22 en AI Act 14

Het is 08:00 in Utrecht. De acceptant bij een middelgrote kredietverstrekker heeft de agent open op haar tweede scherm. Naast haar staat de compliance officer met een uitgeprinte checklist van veertien punten. Vrijdag gaat het live. Niets gaat de deur uit voordat elk vinkje groen is.

We zijn een variant van die kamer in gelopen bij elk geautomatiseerd-besluit project dat we voor een Nederlandse verzekeraar of kredietverstrekker hebben gedaan. Het patroon is consistent genoeg om de lijst gepind te houden in het project-channel. Zeven van de veertien sluit je met een UI-aanpassing die de compliance officer direct bij product kan aanvragen. De andere zeven dwingen een backend engineer om een human-in-the-loop write gate toe te voegen voordat de agent het system of record mag aanraken.

Dit is die checklist, in de volgorde waarin we 'm aflopen.

De twee artikelen die het werk afbakenen

AVG artikel 22 zegt dat een betrokkene het recht heeft om niet onderworpen te worden aan een besluit dat uitsluitend gebaseerd is op geautomatiseerde verwerking, inclusief profilering, als dat besluit rechtsgevolgen heeft of de betrokkene aanmerkelijk treft. Een lening weigeren of een premie bepalen telt mee. Een claim als fraude markeren ook.

AI Act artikel 14 ligt daar bovenop. Hoogrisico AI-systemen moeten effectief menselijk toezicht hebben: een natuurlijke persoon die kan ingrijpen, overrulen of het systeem stoppen. Credit scoring en premiebepaling staan expliciet op de hoogrisico-lijst in Bijlage III.

Samen gelezen zijn de regels niet subtiel. Als de agent een afwijzing wegschrijft naar het system of record zonder akkoord van een menselijke reviewer, zit het bedrijf aan de verkeerde kant van beide. Het interessante werk zit in de gelaagde verdediging die voorkomt dat het zover komt.

De officiële teksten zijn kort genoeg om in een tab open te houden: AVG en de AI Act. De Autoriteit Persoonsgegevens publiceert haar eigen interpretatie; eens per kwartaal doorscrollen is verstandig als je in deze markt levert.

Groep A: valkuilen die de compliance officer sluit met een UI-aanpassing

Deze zeven gaan over beleid, teksten of de flow van een formulier. Geen backend engineer nodig. Wel iemand in product die voor het einde van de dag een banner, link of alinea kan opleveren.

1. De privacyverklaring beschrijft de logica niet

Artikel 22(3) en overweging 71 verwachten 'zinvolle informatie over de onderliggende logica'. Een zin als 'we gebruiken geautomatiseerde systemen' is dat niet. De fix is één alinea die de kenmerken benoemt die het besluit drijven (inkomen, betalingsverleden, openstaande schuld, georisico) en het mechanisme op hoofdlijnen (statistisch model, drempelregels). De gewichten hoef je niet te publiceren.

2. Geen 'vraag een mens' optie op de afwijzingsbrief

Het recht op menselijke tussenkomst moet uitoefenbaar zijn. Een voetnoot die naar info@ verwijst, is dat niet. De fix is één CTA op de afwijzingsbrief en in het klantportaal: 'Vraag beoordeling door een medewerker aan.' Koppel 'm aan een ticketqueue met een SLA van 5 werkdagen.

3. De cookiebanner gooit analytics en besluitvorming op één hoop

We zien dit voortdurend. De banner zegt 'we gebruiken cookies om je ervaring te verbeteren en aanbiedingen te personaliseren'. Die zin doet twee dingen en eentje daarvan valt onder artikel 22. Splits de banner. Analytics op de ene toggle, geautomatiseerde profilering op de andere, en maak die tweede opt-in.

4. Het klantenservice-script heeft geen escalatiepad

Als een afgewezen aanvrager belt, heeft de medewerker aan de telefoon een gedocumenteerde route naar een menselijke beoordelaar nodig. We hebben scripts gezien die zeggen 'het systeem heeft besloten, beroep is niet mogelijk'. Met die zin verlies je een zaak. Pas het script aan. Train het team.

5. Geen uitlegverzoek-formulier in het portaal

Naast tussenkomst kan een betrokkene om uitleg vragen over een specifiek besluit. Het portaal heeft een formulier nodig dat de besluit-ID, de identiteit van de aanvrager en een vrij in te vullen vraag vastlegt. Het antwoord wordt opgesteld door de reviewer die de zaak heeft behandeld, niet door het model.

6. Gevolgen van geautomatiseerde verwerking weggestopt in de voorwaarden

De toelichting op de gevolgen moet vindbaar zijn. We halen 'm uit paragraaf 14 van de voorwaarden en zetten 'm op een eigen pagina, gelinkt vanaf het aanvraagformulier. Eén scherm, helder Nederlands, geen nesting.

7. De cookiewall blokkeert de opt-out

Een profileringsopt-out die alleen verschijnt als de gebruiker cookies accepteert, is geen opt-out. De fix is om de privacy-instellingen te tonen zonder toestemming, en de rest van de pagina te koppelen aan welke cookiestrategie je ook wilt.

Die zeven sluit je in dagen, niet weken. Daarmee staat de compliance officer op oranje. Nu het engineeringwerk.

Groep B: valkuilen die een backend write gate nodig hebben

Deze zeven zijn de valkuilen die livegangs vertragen. Het gaat niet om slechte tekst. Het gaat om beslissingen over wie wat wegschrijft naar het system of record, wanneer, en met welk spoor.

8. De agent schrijft een definitief besluit voordat een mens tekent

Dit is de oerzonde. Het model scoort, de agent zet de aanvraagstatus op 'afgewezen' in het kernsysteem, en de brief gaat de deur uit. De volgende ochtend kijkt een mens ernaar. Tegen die tijd is artikel 22 al overtreden. De fix is om de scorestap los te trekken van de schrijfstap. De agent schrijft een voorstel naar een queue. Een reviewer schrijft het besluit.

Het patroon dat we gebruiken, gestript:

async function propose(application) {
  const result = await model.score(application);

  const proposal = {
    application_id: application.id,
    model_version: model.version,
    score: result.score,
    top_features: result.shap_top_5,
    proposed_outcome: result.proposed_outcome,
    confidence: result.confidence,
    status: 'awaiting_review',
    created_at: new Date().toISOString(),
  };

  await db.proposals.insert(proposal);
  await queue.enqueue('review', proposal.id);

  // No customer-facing change. No status update in the core system.
  return { proposal_id: proposal.id };
}

async function commitDecision(proposalId, reviewerId, outcome, reason) {
  const proposal = await db.proposals.findById(proposalId);
  if (proposal.status !== 'awaiting_review') {
    throw new Error('proposal already resolved');
  }
  await db.transaction(async (tx) => {
    await tx.proposals.update(proposalId, {
      status: 'reviewed',
      reviewer_id: reviewerId,
      reviewer_outcome: outcome,
      reviewer_reason: reason,
      reviewed_at: new Date().toISOString(),
    });
    await tx.applications.update(proposal.application_id, {
      status: outcome,
    });
    await tx.audit.insert({
      type: 'decision_committed',
      proposal_id: proposalId,
      reviewer_id: reviewerId,
      model_version: proposal.model_version,
    });
  });
}

De reviewer mag het voorstel van het model letterlijk overnemen. Dat is prima. Het gaat erom dat aan elke write een menselijk user-ID hangt, elke keer.

9. Reviewer-dashboard toont een score maar geen feature-bijdragen

Artikel 14 eist effectief toezicht. Een reviewer die naar een risicoscore van 0,83 staart zonder context oefent geen toezicht uit, die zet een stempel. Het dashboard heeft de belangrijkste features nodig die de score hebben gedreven, met richting en grootte. SHAP-waarden, partial dependencies, wat het model ook ondersteunt. Zonder dat is het audit trail betekenisloos.

10. Geen audit-regel die het besluit aan de reviewer koppelt

Elk gecommit besluit heeft een regel in een onveranderlijk log nodig met reviewer-ID, modelversie, hash van de input-snapshot en timestamp. We hebben audit-tabellen gezien die alleen de output van het model loggen. Als de toezichthouder vraagt wie drie maanden geleden die afwijzing heeft goedgekeurd, kan het antwoord niet 'het systeem' zijn.

11. Input-features worden niet vastgelegd

Als het model leest uit een feature store die de waarden van gisteren overschrijft, kun je de uitleg voor een besluit van vorige dinsdag niet meer reconstrueren. De fix is om de feature-vector op het moment van het besluit te snapshotten en op te slaan bij het voorstel. Goedkoop. Saai. Redt je als het uitlegverzoek in maand negen binnenkomt.

12. Geen threshold-routing voor randgevallen

De agent moet in autonome modus überhaupt geen grensgevallen behandelen. Stel een confidence-drempel in (wij beginnen meestal op 0,90 en tunen vanaf daar). Daarboven: fast-lane review waarbij de reviewer standaard goedkeurt. Daaronder: volledige review waarbij de reviewer vanaf nul beslist. Onder een lagere drempel (zeg 0,60): alleen mens, zonder modeladvies in beeld.

13. Geen kill switch

Een reviewer of het hoofd acceptatie heeft een manier nodig om de agent in productie binnen seconden uit te zetten. Geen deploy. Een vlag in een config-tabel, gechecked bij elke call. We zijn bij één partij binnengelopen waar het stoppen van de agent betekende dat je de leverancier moest mailen. Dat is geen effectief toezicht onder artikel 14.

14. De retraining-loop neemt overrides over zonder flag

Als een reviewer het model overrulet, is die override een trainingssignaal. Als je 'm ongeflagd in de volgende training meeneemt, leer je het model dat mensen gelijk hadden omdat mensen gelijk hadden, en het model convergeert naar wat de reviewers al doen. Tag overrides. Houd ze buiten de volgende training. Laat het data science-team bewust beslissen hoe ze worden meegenomen.

De checklist in de praktijk

Op een kickoff-call sturen we de lijst tegelijk naar de compliance officer en de engineering lead. Groep A gaat naar product. Groep B gaat naar backend. De twee sporen lopen twee weken parallel. We beschouwen een pipeline pas als live-klaar als beide kolommen groen zijn, en we richten de livegang zo in dat de autonome modus een flag is die we met één configwijziging terug kunnen zetten.

Eén detail dat aandacht verdient: de richtlijnen van het EDPB over geautomatiseerde besluitvorming (WP251rev.01, nog steeds de werkende referentie) beschouwen 'menselijke beoordeling' alleen als substantieel wanneer de reviewer bevoegd en competent is om de uitkomst te veranderen. Een reviewer die alleen een stempel kan zetten op een modeluitkomst, is in regulatoire zin geen reviewer. Daarom telt valkuil 9 net zo zwaar als valkuil 8.

Toen we vorig kwartaal de acceptatie-agent bouwden voor een Nederlandse consumentenkredietverstrekker, was de valkuil waar we tegenaan liepen nummer 11: de upstream feature store overschreef dagelijks, en het eerste uitlegverzoek van een afgewezen aanvrager kwam een maand nadat de snapshot al weg was. We hebben het opgelost door een bevroren feature-vector in de proposals-tabel weg te schrijven op het moment van het besluit. Saaie fix, belangrijke fix. Het grootste deel van ons AI-agent werk voor gereguleerde klanten gaat sindsdien vanaf dag één live met die snapshot.

Sta je deze week op het punt om een geautomatiseerd-besluit pipeline live te zetten, doe dan vandaag één ding: open het codepad dat de aanvraagstatus wegschrijft en check wie het aanroept. Als het model dat kan aanroepen zonder dat er een reviewer-ID aan de write hangt, heb je je eerste ticket.