Het begint onschuldig.
Een medewerker gebruikt een AI-tool om een aanvraag te beoordelen. De uitkomst voelt logisch. Het systeem geeft een duidelijke score. Afwijzen. Volgende dossier.
Niemand staat erbij stil dat dit geen advies meer is, maar een besluit. En niemand vraagt zich af waar die score vandaan komt.
Tot een klant bezwaar maakt.
Het moment waarop AI zichtbaar wordt
Een bezwaar klinkt administratief. In werkelijkheid is het een stresstest voor je hele keten.
De klant vraagt geen technische uitleg. Die vraagt iets simpels: waarom ben ik afgewezen?
En daar stokt het gesprek.
Niet omdat niemand wil uitleggen wat er gebeurde. Maar omdat niemand het kan.
Er is geen beslisboom. Geen vastgelegde afweging. Geen log die laat zien welke input is gebruikt, welk model draaide en welke parameters doorslaggevend waren. Alleen een uitkomst. “Het systeem gaf dit aan.”
Dat is het moment waarop AI ophoudt een intern hulpmiddel te zijn en verandert in een extern probleem. Niet technisch. Bestuurlijk.
AI wordt ingezet zonder probleemdefinitie
In eerdere artikelen schreef ik al dat veel organisaties worstelen met de vraag waarom ze AI inzetten, niet hoe.
In AI Act in de praktijk. Waarom verzekeraars hun datastructuur opnieuw moeten ontwerpen liet ik zien dat AI vaak wordt gebouwd op datafundamenten die nooit bedoeld zijn voor beslislogica.
Dit artikel raakt een ander, maar direct verbonden probleem.
AI verschijnt niet als antwoord op een scherp gedefinieerd vraagstuk, maar als feature. Iets nieuws. Iets handigs. Iets dat je “even meeneemt”.
Er is geen expliciete afbakening:
- welk probleem lossen we op
- waar mag AI adviseren
- waar stopt het advies
- wie neemt het besluit
Zonder die afbakening vervaagt de grens. Medewerkers gaan vertrouwen op output. Niet uit gemakzucht, maar omdat het systeem autoriteit uitstraalt.
De architectuur verraadt de organisatie
Niet door wat er staat, maar door wat ontbreekt.
Er is geen logging die vastlegt:
- welke input werd gebruikt
- welke modelversie actief was
- welke regels of wegingen meespeelden
- welke medewerker de uitkomst heeft overgenomen
Er is geen herleidbaarheid. Geen reconstructie. Geen antwoord op de simpele vraag: waarom?
En belangrijker nog: er is geen expliciet eigenaarschap in de keten.
De leverancier levert de AI. De business gebruikt het. IT beheert de omgeving. Legal kijkt mee vanaf de zijlijn. Maar niemand is eigenaar van het besluitgedrag.
In AI bij verzekeraars. Hoe je innovatief blijft zonder je auditteam te laten hyperventileren beschreef ik al dat innovatie zonder expliciete governance leidt tot interne frictie.
Dit is waar die frictie extern zichtbaar wordt.
Contractueel klopt het. Bestuurlijk niet
In veel contracten staat keurig dat de leverancier niet aansprakelijk is voor de uitkomsten van AI. Dat de klant verantwoordelijk is voor het gebruik. Dat resultaten indicatief zijn.
Juridisch valt daar iets voor te zeggen.
Maar zodra een klant bezwaar maakt tegen een automatische afwijzing, verschuift de discussie. Dan gaat het niet meer over aansprakelijkheid, maar over zorgvuldigheid. Over uitlegbaarheid. Over vertrouwen.
En precies daar faalt het contract. Want nergens is vastgelegd:
- hoe besluiten tot stand komen
- hoe toezicht plaatsvindt
- wie corrigeert bij twijfel
- wie eigenaar is van het gedrag van het systeem
De AI Act verandert dit niet automatisch
De AI Act benoemt risico’s, classificaties en verplichtingen. Dat helpt. Maar zonder vertaling naar architectuur en contracten blijft het abstract.
De wet regelt jouw logging niet.
De wet wijst geen eigenaar aan in jouw keten.
De wet definieert jouw probleem niet.
Dat moet je zelf doen. Vooraf.
Wat dit vraagt van architectuur
Dit is geen AI-vraag. Dit is een governancevraag.
Als architect moet je afdwingen dat:
- AI expliciet als component wordt gemodelleerd
- advies en besluit gescheiden blijven
- logging en herleidbaarheid standaard onderdeel zijn
- eigenaarschap expliciet wordt belegd
- contracten deze verantwoordelijkheden ondersteunen
Zonder die keuzes ontwerp je geen innovatie, maar risico.
De echte schade zit niet in de fout
De echte schade zit in het antwoord op de vraag: waarom is dit gebeurd?
Als dat antwoord ontbreekt, maakt het niet uit of de afwijzing inhoudelijk terecht was. Het vertrouwen is weg. Bij de klant. Bij interne stakeholders. En uiteindelijk bij toezicht en media.
En dat begint niet bij een toezichthouder.
Dat begint bij één klant.
Met één bezwaar.
Waar niemand grip op heeft.
Conclusie
AI faalt zelden spectaculair. Het faalt stil. Tot iemand het doorziet.
Wie AI inzet zonder probleemdefinitie, zonder logging en zonder expliciet eigenaarschap, bouwt reputatierisico in. Contractueel afgedekt. Bestuurlijk onhoudbaar.
De AI Act verandert daar niets aan.
Architectuur wel.
Hi Martin,
Ik heb de reeks gelezen — DORA, de AI Act-datastructuur, de auditteam-frictie en het contracten-stuk. Ze bouwen mooi op elkaar voort.
Wat me opvalt: in alle vier de stukken ligt de oplossing bij de architect zelf — eigenaarschap beleggen, lineage automatiseren, logging inbouwen. Volledig terecht. Maar ik loop zelf tegen een ander punt aan vanuit mijn achtergrond (audit, later ML/AI-systemen gebouwd in een bank): zodra dat allemaal intern goed staat, moet iemand het nog één keer van buitenaf kunnen doorlopen en vastleggen — niet als getekende verklaring, maar als het bewijsdossier waar een toezichthouder of auditor mee aan de slag kan.
Zie je dat in de praktijk als een apart traject, of verwacht je dat verzekeraars dat straks gewoon zelf, intern, meenemen in hun architectuurwerk?
Groet,
Enes.
Hi Enes,
Goede vraag. Ik denk dat het de taak van de architect is om ervoor te zorgen dat de basis goed is. Vanuit een Compliance oogpunt is het denk ik goed om te (laten) beoordelen of hetgeen de architect heeft verzonnen ook op een juist manier is geïmplementeerd door de DEVOPS organisatie èn of dat voor een externe toezichthouder / auditor werkbaar is.
Groeten,
Martin