Guardrails (AI)

Wat zijn guardrails?

Guardrails zijn de beschermlagen rond een AI-toepassing die bepalen wat erin en eruit mag. Ze controleren wat gebruikers kunnen vragen, wat het model mag antwoorden en welke acties het mag uitvoeren. Het woord betekent letterlijk vangrails: ze houden de wagen op de weg wanneer er iets misgaat.

Een LLM zonder guardrails doet wat de input vraagt, ook als die input misleidend of kwaadaardig is. Wie een chatbot, een RAG-systeem of een AI-agent in productie zet, bouwt daarom lagen rond het model, want je kan nooit exact voorspellen wat het doet met input die je niet voorzien hebt.

Welke soorten guardrails bestaan er?

De meeste productiesystemen combineren een aantal van deze lagen:

• Input-validatie
  Controleer wat binnenkomt voor het het model bereikt: van simpele filters op bekende aanvalspatronen tot een klein taalmodel dat elke vraag eerst classificeert als veilig of verdacht.

• System prompts en instructies
  De vaste instructies die vastleggen welke rol de assistent speelt, welke onderwerpen buiten scope vallen en hoe hij weigert. Dit is de goedkoopste laag en meteen ook de zwakste: een system prompt is een instructie, geen slot.

• Output-filtering
  Controleer het antwoord voor het bij de gebruiker komt: op schadelijke inhoud, gelekte persoonsgegevens of beweringen die niet uit de aangeleverde brondocumenten komen.

• Moderation-API's
  Kant-en-klare diensten die deze checks voor je doen. Azure AI Content Safety scant tekst en beelden op haat, geweld, seksuele inhoud en zelfverwonding, en heeft met Prompt Shields een aparte detectie voor injectie-aanvallen. OpenAI biedt een gratis moderation-endpoint dat tekst en afbeeldingen in dertien categorieën indeelt.

• Menselijke controle
  Voor acties met echte gevolgen, zoals mails versturen of betalingen starten, vraagt het systeem eerst bevestiging aan een mens.

Wanneer volstaat een system prompt?

Voor een interne assistent die alleen tekst genereert, geen tools heeft en enkel door eigen medewerkers gebruikt wordt, kom je een heel eind met een goede system prompt. Het ergste wat er dan gebeurt, is een slecht antwoord.

Zodra het systeem tools krijgt, externe content leest of publieke gebruikers bedient, verandert de rekening: elke input wordt een mogelijke aanval. Prompt injection toont waarom. Een gebruiker of een verstopte instructie in een document kan het model overhalen zijn instructies te negeren. OWASP stelt dat daar geen waterdichte preventie voor bekend is.

Daarom stapel je meerdere lagen, in security-jargon defense in depth. Mist het inputfilter een creatieve aanval, dan vangt de system prompt hem op. Glipt hij daar ook door, dan blokkeert de outputcheck het antwoord of houdt de bevestigingsstap de actie tegen. Geen enkele laag is perfect, maar samen maken ze de kans op een geslaagde aanval een pak kleiner.

Guardrails, evals en human-in-the-loop

Guardrails werken live. Ze blokkeren, herschrijven of escaleren op het moment dat een vraag of antwoord passeert.

Evals meten offline. Je test periodiek hoe je systeem presteert op een vaste set voorbeelden: juiste antwoorden, correcte weigeringen, lastige randgevallen. Evals tonen je waar je guardrails tekortschieten.

Human-in-the-loop zet een mens op de plaatsen waar je geen enkel automatisch systeem het laatste woord wil geven. Het is de laatste guardrail, voor beslissingen met echte impact op klanten, geld of mensen.

Wat guardrails niet oplossen

Guardrails geven geen garantie. Wie een filter bouwt, ziet aanvallers hun formulering aanpassen tot er iets doorglipt. Het is een kat-en-muisspel, en dat blijft het zolang taalmodellen instructies en data in dezelfde stroom verwerken.

Hetzelfde geldt voor hallucinatie. Het model toestaan om 'ik weet het niet' te antwoorden, bronvermelding verplichten en antwoorden verankeren in aangeleverde documenten helpt merkbaar. Volledig verdwijnen doet het probleem niet; Anthropic zegt dat in zijn eigen documentatie letterlijk.

Guardrails vervangen ook geen goed ontwerp. Een agent die geen verzendrechten heeft, kan geen mails lekken, filter of geen filter. De veiligste guardrail is de toegang die je nooit hebt gegeven.

Waar moet je op letten bij het gebruik van guardrails

Overblokkering
Hoe strenger de filters, hoe meer legitieme vragen sneuvelen. Een klantendienst-bot die elke vraag over facturen weigert omdat er een rekeningnummer in staat, jaagt gebruikers weg. Stem de strengheid af op echt gebruik en meet ook hoeveel je onterecht blokkeert.

Schijnveiligheid
Een moderation-API aanzetten en het dossier sluiten, is gevaarlijker dan weten dat je kwetsbaar bent. Filters missen aanvallen, zeker nieuwe. Test regelmatig met opzettelijke aanvalspogingen.

Onderhoud
Aanvalstechnieken evolueren en elke modelupdate kan het gedrag van je toepassing veranderen. Guardrails zijn onderhoudswerk: ze moeten mee met elke wijziging aan je systeem.

Taalondersteuning
Veel moderation-modellen zijn vooral op Engels getraind. Microsoft noemt voor Azure AI Content Safety acht geteste talen en Nederlands staat daar niet bij. Test dus eerst zelf met Nederlandstalige input.

FAQ over guardrails

1. Zijn guardrails hetzelfde als content-moderatie?
Nee. Content-moderatie is één laag: het filteren van schadelijke inhoud. Guardrails is de bredere term en omvat ook input-validatie, instructies, toegangsbeperkingen en menselijke controle.

2. Heeft een interne chatbot ook guardrails nodig?
Lichtere dan een publieke toepassing, maar zelden geen. Zodra de bot aan bedrijfsdata kan of tools mag gebruiken, wil je minstens toegangsbeperkingen en een bevestigingsstap voor acties met gevolgen.

3. Bestaat er een standaard voor guardrails?
Geen verplichte. Het AI Risk Management Framework van NIST (vrijwillig, met sinds 2024 een apart profiel voor generatieve AI) geeft een kader voor risicobeheer, en OWASP publiceert concrete maatregelen tegen aanvallen zoals prompt injection.