Waarom een model-audit niet genoeg is: systeemintegratie-audits voor AI

De meeste AI-audits kijken naar het model. Dat is simpelweg niet genoeg.

Nederlandse overheden draaien AI zelden als een geïsoleerd model. Het is een systeem. Denk aan een RAG-pijplijn met een foundation model, een vector database, een embedding service, een API-gateway, een UI-laag en een data-pijplijn die continu nieuwe documenten indexeert. Een audit die alleen het foundation model test, mist de risico's die ontstaan in de integraties tussen deze componenten.

Een nieuw paper uit de arXiv-serie, System Integration Audits in AI: A Scoping Review[^1], levert precies het framework dat we nodig hebben om AI-audits uit te breiden naar systeemniveau. Het is direct relevant voor AI Act-conformiteitsbeoordelingen en voor elke organisatie die AI in productie heeft.

Wat het paper doet

De auteurs hebben een systematische review uitgevoerd van bestaande auditmethoden voor AI-systemen. Hun conclusie: de meeste audits richten zich op het model zelf, bias, robuustheid, transparantie, maar negeren de systeemcontext. Ze stellen een raamwerk voor dat auditoren dwingt om de hele keten te doorlopen. Van data-inname tot output-validatie.

Het paper identificeert vier lagen die in een systeemaudit aan bod moeten komen:

1. Data-laag: herkomst, kwaliteit, versiebeheer, privacy-by-design.
2. Model-laag: het foundation model, fine-tuning, embeddings.
3. Integratie-laag: API's, middleware, caching, rate limiting, logging.
4. Interface-laag: UI, output filtering, gebruikersterugkoppeling.

Voor elke laag definiëren ze specifieke auditcriteria. Dat is precies wat ontbreekt in de huidige praktijk.

Waarom dit ertoe doet voor de Nederlandse overheid

De AI Act verplicht aanbieders en gebruikers van hoog-risico AI-systemen tot conformiteitsbeoordelingen. Die beoordelingen moeten aantonen dat het systeem voldoet aan eisen rond transparantie, menselijk toezicht, nauwkeurigheid en cyberweerbaarheid.

Maar de AI Act definieert een AI-systeem als "een software die is ontwikkeld met technieken zoals machine learning, en die output genereert die invloed heeft op de omgeving". Die definitie omvat het hele systeem, niet alleen het model. Toch zien we in de praktijk dat audits zich beperken tot modelkaarten en bias-rapporten.

Neem een typisch RAG-systeem bij een gemeente. Het foundation model is getraind op algemene data. De vector database bevat gemeentelijke documenten. De retrieval-module haalt de top-5 chunks op. De prompt template voegt die chunks samen met de gebruikersvraag. Het model genereert een antwoord. De UI toont dat antwoord.

Een model-audit checkt alleen het foundation model. Maar de risico's zitten elders:

• Retrieval bias: de vector database kan systematisch bepaalde documenten prefereren boven andere, bijvoorbeeld oudere beleidsstukken boven nieuwe.
• Prompt injection: een kwaadwillende gebruiker kan via de UI een prompt sturen die de retrieval omzeilt.
• Data leakage: de API-gateway logt mogelijk gevoelige informatie uit de prompts.
• Output validatie: de UI toont hallucinaties zonder dat er een filter tussen zit.

Het paper geeft auditoren een checklist om al deze punten te adresseren.

Concrete voorbeelden uit de praktijk

Ik werk dagelijks met overheden die AI inzetten voor burgerondersteuning, vergunningverlening en interne kennismanagement. Wat ik steeds terugzie: men laat het model auditen door een externe partij, maar de rest van de pijplijn is niet getoetst.

Een voorbeeld: een RAG-pijplijn met LangChain, een OpenAI-model en een Qdrant vector database. De model-audit gaf groen licht. Maar bij een integratietest bleek dat de embedding-service geen rate limiting had. Een DDoS-aanval op de API kon de hele dienst platleggen. Dat is een NIS2-risico en ook een BIO2-vereiste voor beveiliging van netwerk- en informatiesystemen.

Een ander voorbeeld: een UI die de output van het model direct toont zonder validatie. Gebruikers kregen antwoorden die juridisch incorrect waren, omdat de retrieval verouderde documenten ophaalde.