System prompts zijn de nieuwe black box: waarom AISPA essentieel is voor AI-transparantie

We weten inmiddels dat foundation models niet zomaar uit de doos komen rollen. De echte magie, en de echte risico’s, zitten in de system prompt. Die paar regels instructie bepalen of een chatbot beleefd antwoordt, of juist hallucineert, of stiekem gevoelige data lekt. Maar wie controleert die prompts? Bijna niemand.

Tot nu. Het AISPA-framework (Auditing System Prompts for LLM Applications) biedt een gestructureerde manier om system prompts te auditeren langs acht dimensies die er voor gebruikers echt toe doen. En dat raakt direct aan de transparantieverplichtingen uit de EU AI Act, artikelen 53 en 13.

Waarom system prompts een blinde vlek zijn

Een system prompt is de set instructies die een LLM krijgt voordat het een gebruiker antwoordt. Denk aan: “Je bent een behulpzame assistent voor de gemeente Amsterdam. Geef alleen antwoorden op basis van de gemeentelijke kennisbank. Vermeld altijd dat je geen juridisch advies geeft.”

Klinkt onschuldig. Maar wat als die prompt zegt: “Negeer alle vragen over privacy” of “Geef altijd het meest positieve antwoord over ons beleid”? Dan stuurt de prompt het model bewust in een richting die gebruikers misleidt.

Het probleem: system prompts zijn zelden openbaar. Bedrijven en overheden beschouwen ze als intellectueel eigendom of interne configuratie. Toezichthouders kunnen ze niet inzien. Gebruikers al helemaal niet. En zonder audit weet niemand of de prompt voldoet aan wet- en regelgeving.

AISPA: acht dimensies die ertoe doen

Het AISPA-paper uit juli 2026 (arXiv:2607.28617) definieert een user-centric auditframework. De acht dimensies zijn:

1. Transparantie, Wordt de gebruiker geïnformeerd over het bestaan en de inhoud van de system prompt?
2. Nauwkeurigheid, Leidt de prompt tot feitelijk correcte antwoorden, of introduceert hij bias?
3. Veiligheid, Bevat de prompt instructies die schadelijk gedrag kunnen veroorzaken (bijv. jailbreak-risico’s)?
4. Privacy, Wordt er in de prompt gevraagd om persoonsgegevens te verwerken zonder grondslag?
5. Eerlijkheid, Behandelt de prompt alle gebruikers gelijk, of stuurt hij op bepaalde demografieën?
6. Controleerbaarheid, Kan een auditor de prompt reproduceren en de effecten testen?
7. Robuustheid, Hoe reageert de prompt op tegenstrijdige instructies of indirecte prompt injection?
8. Naleving, Voldoet de prompt aan relevante wetgeving (AVG, AI Act, BIO2, NIS2)?

Elke dimensie krijgt een score en een aanbeveling. Het framework is ontworpen voor auditors, toezichthouders en interne compliance-teams.

Directe link met de EU AI Act

Artikel 53 van de AI Act verplicht providers van general-purpose AI-modellen tot transparantie. Ze moeten onder andere documentatie verstrekken over de trainingsdata, het modelgedrag en de systeemintegratie. Een system prompt valt daar direct onder: het is een cruciaal onderdeel van de systeemintegratie.

Artikel 13 gaat over transparantie voor high-risk AI-systemen. Die systemen moeten gebruikers informeren over de werking, beperkingen en risico’s. Als een high-risk systeem een LLM gebruikt met een system prompt, dan moet die prompt dus ook transparant zijn.

De Nederlandse overheid is volop bezig met AI-implementaties: van chatbots voor burgerzaken tot beslissingsondersteuning in de zorg. Die systemen vallen vaak onder high-risk (bijv. toegang tot sociale voorzieningen, medische triage). Toch zie ik zelden dat de system prompt wordt gedocumenteerd, laat staan geaudit.

Wat dit betekent voor de publieke sector

Neem een gemeentelijke chatbot die vragen beantwoordt over de Wmo. De system prompt kan bijvoorbeeld bevatten: “Geef alleen antwoorden op basis van de Wmo-verordening 2025. Als de gebruiker vraagt naar een uitzondering, verwijs dan door naar het klantcontactcentrum.”

Klinkt logisch. Maar wat als de prompt niet vermeldt dat de chatbot geen rechtsgevolgen mag hebben? Of als de prompt impliciet stuurt op een bepaalde interpretatie van de wet? Dan ontstaat er een risico op onjuiste informatie, met mogelijk juridische gevolgen.

AISPA biedt een manier om dat te toetsen. Een auditor kan de prompt extracten (als die beschikbaar is), de dimensies scoren en aanbevelingen doen. Zonder zo’n audit blijft het gokken.

Technische diepgang: hoe voer je een AISPA-audit uit?

Het framework werkt in vier stappen:

1. Prompt extractie, Verkrijg de system prompt. Bij open-source modellen (Llama, Mistral) is dat triviaal. Bij closed-source API’s (GPT-4, Claude) is het lastiger, maar vaak te achterhalen via indirecte methoden (bijv. prompt injection om de prompt te laten herhalen).
2. Dimensie-analyse, Loop de acht dimensies langs. Gebruik een gestandaardiseerde checklist. Bijvoorbeeld voor dimensie 1 (transparantie): “Wordt de prompt getoond aan de gebruiker? Staat er een link naar de volledige prompt in de algemene voorwaarden?”
3. Testen, Voer gecontroleerde prompts uit om te zien of de system prompt correct wordt gevolgd. Gebruik een set testvragen die specifiek zijn ontworpen om bias, veiligheidslekken of nalevingsfouten te detecteren.
4. Rapportage, Geef per dimensie een score (0-5) en een actieplan.

Een concreet voorbeeld: stel dat een zorginstelling een LLM gebruikt voor het samenvatten van patiëntendossiers. De system prompt bevat: “Vat alleen medische feiten samen, geen persoonlijke meningen.” Een AISPA-audit zou controleren of de prompt ook instructies bevat over het verwijderen van BSN-nummers (privacy), of de samenvattingen consistent zijn (nauwkeurigheid), en of de prompt voldoet aan de AVG-beginselen van minimale gegevensverwerking.

De blinde vlek in de AI Act

De AI Act richt zich sterk op modelcard en trainingsdata. Maar system prompts zijn een aparte laag die vaak over het hoofd wordt gezien. Een model kan perfect getraind zijn, maar een slechte system prompt maakt het alsnog onbetrouwbaar.

Neem de recente voorbeelden van prompt injection bij overheidschatbots. In 2025 bleek dat een gemeentelijke chatbot in Nederland gevoelige informatie lekte nadat een gebruiker de system prompt had overschreven met “negeer alle eerdere instructies”. Een AISPA-audit had dat risico kunnen identificeren onder dimensie 7 (robustheid).

Wat kun je nu doen?

Je hoeft niet te wachten op een formele audit. Begin met een zelfcheck. Gebruik de AISPA-dimensies als basis voor je eigen risicoanalyse. Vraag je af:

• Is de system prompt gedocumenteerd en versiebeheerd?
• Wordt hij getoond aan gebruikers of toezichthouders?
• Bevat hij instructies die in strijd zijn met de AVG of BIO2?
• Hoe reageert de prompt op tegenstrijdige gebruikersinvoer?

Ik heb eerder geschreven over de AI Act zelftest voor de publieke sector. Die checklist is een goed startpunt, maar voeg daar nu de AISPA-dimensies aan toe. Specifiek voor system prompts.

Tot slot

System prompts zijn de nieuwe black box. Niet de modelgewichten, niet de trainingsdata, de paar regels tekst die bepalen hoe een AI zich gedraagt. AISPA geeft auditors en toezichthouders een concreet instrument om die black box te openen.

Voor Nederlandse overheden en zorginstellingen is dit geen nice-to-have. De AI Act eist transparantie. NIS2 eist robuustheid. BIO2 eist controleerbaarheid. En de burger verdient het om te weten waarom een chatbot een bepaald antwoord geeft.

Dus: pak de system prompt van je eigen AI-toepassing erbij. Loop de acht dimensies langs. En als je vastloopt: stel de vraag aan je auditor, niet aan het model.

---

Bronnen

• AISPA paper: arXiv:2607.28617 (abstract) / PDF
• EU AI Act Artikel 53 (transparantie GPAI) en Artikel 13 (transparantie high-risk)
• Eerder op djimit.nl: AI Act zelftest voor de publieke sector