De wereld van AI evolueert razendsnel, en met de opkomst van Retrieval-Augmented Generation (RAG) openen zich nieuwe mogelijkheden om data en taalmodellen slim te combineren.

RAG-systemen combineren het generatieve vermogen van LLM’s met het ophalen van relevante, actuele informatie uit databronnen. Dit maakt ze krachtiger, maar ook complexer: ze zijn afhankelijk van de kwaliteit van zowel het model als de gebruikte data, en lopen risico op het verspreiden van verouderde, onjuiste of ongepaste informatie.

In een vorige blogpost bespraken we hoe automatische evaluaties kunnen helpen om de kwaliteit te meten van een RAG-systeem en het interatief te verbeteren. Maar kwaliteit alleen is niet genoeg. Om AI-systemen niet alleen goed te laten functioneren, maar ook veilig en verantwoord, zijn guardrails nodig. Onder guardrails verstaan we de richtlijnen, technische beperkingen en ethische kaders die ervoor zorgen dat AI-systemen binnen aanvaardbare grenzen opereren. Ze voorkomen ongewenste of schadelijke output en zorgen ervoor dat AI-systemen aansluiten bij menselijke waarden en maatschappelijke normen.

Wat zijn die guardrails precies en hoe zet je ze effectief in? Dat verkennen we in deze blogpost.

De nood aan guardrails

LLM-gebaseerde toepassingen brengen verschillende risico’s met zich mee die de nood aan sterke guardrails duidelijk maken. Zonder passende bescherming kunnen de systeeminstructies ontfutseld worden. Die geven inzicht in interne logica en beveiligingsmechanismen, en die zie je dus liever niet onthuld. Ook bestaat het risico op privacy­schendingen wanneer persoonlijke gegevens bij externe modelproviders terechtkomen. Daarnaast kunnen modellen schadelijke antwoorden genereren, variërend van haatspraak tot zelfbeschadigingsadviezen, of incorrecte informatie door hallucinerende output. Off-topic vragen kunnen leiden tot misbruik van de toepassing en de kosten doen oplopen, terwijl ongepaste of niet-conforme antwoorden reputatieschade kunnen veroorzaken.

Om al deze redenen zijn robuuste guardrails essentieel, omdat ze een buffer vormen tegen deze uiteenlopende risico’s en helpen garanderen dat AI-toepassingen veilig, betrouwbaar en conform de verwachtingen van gebruikers en organisaties functioneren.

Methodes en technieken

Guardrails worden doorgaans op twee niveaus ingezet: vlak vóór de input het taalmodel bereikt (inputfilter), of net na het genereren van de output maar vóór die bij de eindgebruiker terechtkomt (outputfilter).

In grote lijnen bestaan er vier technieken om guardrails concreet te implementeren.

• LLM-native guardrails zijn ingebouwde veiligheidsmechanismen die modelproviders zelf voorzien, zoals het vermijden van schadelijke outputs of beperkingen bij het volgen van bepaalde instructies. Ze bieden een eerste verdedigingslinie, maar moeten doorgaans aangevuld worden met één of meerdere van de technieken hieronder.
• Bij prompt-gebaseerde guardrails worden specifieke instructies toegevoegd aan de prompt om het gedrag van het model te beïnvloeden. Een typisch voorbeeld is om het model te verplichten om uitsluitend te antwoorden op basis van aangeleverde contextinformatie (via RAG) zodat het geen ongecontroleerde of ongewenste output genereert. Een ander voorbeeld is het toevoegen van instructies om te vermijden dat het AI-systeem medisch advies geeft. In het voorbeeld hieronder zijn instructies te zien die toegevoegd worden aan de prompt om te vermijden dat de toepassing medisch advies geeft, samen met een voorbeeld van een conversatie waarbij de toepassing het gewenste antwoord geeft.
  
  

  Voorbeeld van prompt hardening: vermijden van medisch advies

• Regelgebaseerde guardrails werken deterministisch met filters op basis van exacte woorden of reguliere expressies. Op die manier kan gescreend worden op bepaalde woorden of onderwerpen, en kunnen eenvoudige vormen van vertrouwelijke informatie gefilterd worden, zoals ID’s, telefoonnummers of e-mailadressen.
• LLM/ML-gebaseerde guardrails maken gebruik van machine learning modellen of zogenaamde LLM-judges die veel beter overweg kunnen met nuance, intentie en context. Ze kunnen zowel input als output beoordelen en kunnen deze classificeren, bijvoorbeeld om schadelijke inhoud of prompt injections te detecteren (dit zijn pogingen van gebruikers om het gedrag van de toepassing te manipuleren via de prompt). Daarnaast kunnen ze gevoelige informatie filteren en fact-checking uitvoeren door na te gaan of alle uitspraken in de output effectief worden ondersteund door de aangeleverde context, zoals bij RAG.

Elke techniek heeft een eigen nut, complexiteit en kost. Het is daarom aangeraden om eerst de specifieke risico’s voor een bepaalde usecase te evalueren en daarna te bepalen welke guardrails echt nodig zijn. Begin met de eenvoudigste methodes (prompt-gebaseerd en regelgebaseerd) en schakel pas over op complexere technieken (LLM/ML gebaseerd) wanneer dat noodzakelijk is. Deze laatste brengen namelijk extra latency en kosten met zich mee.

Guardrail tools

Er bestaan heel wat tools die deze technieken ondersteunen en het eenvoudiger maken om guardrails in een toepassing te integreren. Frameworks bieden een volledige omgeving om guardrails te definiëren, combineren en orkestreren. Ze laten je regels, workflows en validatiestappen configureren zonder alles zelf te moeten bouwen. Voorbeelden zijn Guardrails AI, LLM Guard en NVIDIA NeMo Guardrails.

Daarnaast zijn er API’s en services die specifieke functionaliteiten aanbieden, zoals het detecteren van schadelijke inhoud, het filteren van gevoelige gegevens of het opsporen van jailbreaks. Deze kun je rechtstreeks vanuit je toepassing aanroepen. Denk hierbij aan Azure AI Content Safety of OpenAI Moderation API.

Onder de motorkap maken deze tools gebruik van een mix van ML-modellen, LLM-judges en regelgebaseerde technieken. Voorbeelden van ML-modellen zijn Llama Guard en Prompt Guard.

Uit onze eigen ervaringen blijkt dat bepaalde guardrailtools merkbaar minder nauwkeurig presteren in het Nederlands en Frans ten opzichte van het Engels. We zien daarbij soms ook false positives, bijvoorbeeld wanneer selfharm-detectie onschadelijke zinnen foutief als risicovol markeert. Voor eenvoudige toepassingen met een laag risicoprofiel en uitsluitend publieke data lijkt de meerwaarde van extra guardrailtools beperkt. In zulke gevallen volstaan doorgaans de ingebouwde veiligheidsmechanismen van de LLM in combinatie met een goed ontworpen RAG-prompt.

Conclusie

Samengevat is het belangrijk om guardrails steeds risicogestuurd en gelaagd in te zetten. Begin met het identificeren van de risico’s binnen de specifieke usecase en kies vervolgens de passende technieken, waarbij eenvoudige methodes de voorkeur krijgen en complexere oplossingen pas worden toegevoegd wanneer dat echt nodig is. Hoewel een combinatie van LLM-native, prompt-gebaseerde, regelgebaseerde en ML/LLM-gebaseerde guardrails een robuustere bescherming biedt, blijft het essentieel om te beseffen dat geen enkel systeem volledige veiligheid garandeert. Input- en outputfilters kunnen zowel false positives als false negatives opleveren. ML/LLM-gebaseerde guardrails brengen bovendien extra kosten en latency met zich mee. Een continue monitoring van de AI-toepassing is aangeraden om nieuwe kwetsbaarheden tijdig op te sporen en aan te pakken.