Wat zijn guardrails? Regels en checks die bepalen wat een AI-toepassing wel en niet mag doen of zeggen. Zo ontwerp je ze voor klantcontact en documenten.
Guardrails zijn de regels en controles waarmee je een AI-toepassing begrenst: wat hij wél en nooit mag zeggen, welke acties hij mag uitvoeren en wat gebeurt bij iets raars. Ze bestaan zelden uit één filter. Het zijn lagen: instructies, validatie, rechten en een menselijke controle. Zonder die grenzen werkt een toepassing op goodwill; met ze werkt hij op ontwerp.
Een taalmodel zal vrijwel alles formuleren wat je vraagt. Het kent geen huishoudelijk reglement. Guardrails zijn het reglement van de toepassing eromheen. Concrete voorbeelden uit de praktijk: een assistent noemt nooit prijzen, maar verwijst door naar de juiste collega; hij geeft geen adviezen buiten zijn gebied; hij verstuurt geen persoonsgegevens naar een externe dienst; en hij blijft bij zijn taal en toon, ook als een gebruiker hem probeert uit te lokken.
Belangrijk is dat deze regels niet op één plek zitten. De instructie zegt wat gewenst is, maar instructies zijn beïnvloedbaar. Validatie controleert de uitvoer op vaste regels (geen verboden woorden, wel de verplichte velden) voordat iets verder mag. Rechten op systemen bepalen fysiek wat een toepassing kan: wie alleen-lezen heeft, kan ook niet publiceren. En de menselijke controle vangt wat de vorige lagen laten slippen. Elke laag vangt wat de vorige mist.
Wat guardrails niet zijn: een garantie dat er nooit iets raars uitkomt. Ze vergroten de kans dat het raars gezien wordt vóór het schade doet, en maken het gedrag herleidbaar als het toch gebeurt. Daarom horen er twee dingen bij die vaak worden vergeten: logging van wat de toepassing deed en besloot, en een vast pad voor wat er gebeurt als een regel afgaat. Blokkeren, doorzetten naar een mens, of gewoon netjes weigeren.
De moeite waard zijn ze bij elke toepassing die klantgericht of gegevensgericht is: iets dat met klanten praat, dossiers bijwerkt, documenten produceert of beslissingen voorbereidt. Daar bepalen de regels het verschil tussen nuttige automatisering en reputatierisico. Ook bij interne tooling tellen ze. Juist daar ontstaat de gewoonte om ze 'later' toe te voegen, en later wordt nooit.
Weeg ze wel per toepassing. Strengere regels maken een toepassing ook belemmerender: wie alles blokkeert, levert een tool af die niets meer durft. De kunst is het minimum dat past bij de inzet. Een interne zoekhulp heeft andere grenzen nodig dan een chatassistent die namens het bedrijf schrijft. En een regel die niemand kan uitleggen, wordt vroeg of laat uitgezet; schrijf dus op waarom elke regel bestaat.
We beginnen bij de vraag wat de toepassing nooit mag doen (niet bij wat hij kan) en vertalen dat naar lagen: instructie, validatie, rechten en controlepunt. Vervolgens proberen we de grenzen te doorbreken met lastige invoer, inclusief pogingen tot prompt-injection, en vullen de gaten vóór livegang. Elke afgewende actie wordt gelogd en periodiek bekeken, zodat de regels meegroeien met wat de praktijk leert in plaats van te verstarren in een document.
Er zijn er drie die bijna altijd terugkomen. Hij blijft binnen zijn gebied en verwijst door bij vragen die daarbuiten vallen; hij noemt geen prijzen of contractafspraken maar stuurt die naar een collega; en hij geeft geen persoonsgegevens van klanten door aan externe diensten. Daarnaast krijgt hij een vaste toon en een vast pad voor twijfel: niet gokken, maar doorzetten naar een mens. Specifieke regels per bedrijf voegen we daarbovenop toe, op basis van jullie afspraken.
Proberen doen ze, en soms lukt een eerste poging tegen de instructielaag. Daarom rust het ontwerp niet op woorden alleen. Validatie controleert de uitvoer, rechten beperken wat er technisch mogelijk is, en acties met gevolgen gaan achter een menselijke controle. We testen de grenzen bewust met lastige invoer vóór livegang en vullen de gaten. Het doel is niet een ondoordringbare muur. Die bestaat niet. Maar een opzet waarin een doorbraak gezien en gedempt wordt.
Er staat dan een vast pad klaar, per soort overschrijding anders: een vraag buiten het gebied krijgt een nette weigering met een doorverwijzing; een uitvoer die de controle niet haalt, wordt geblokkeerd en ter beoordeling aan een mens voorgelegd; een poging om het systeem te manipuleren wordt vastgelegd en afgekapt. Wat er in elk geval gebeurt, is dat het wordt vastgelegd in de logs. Zodat je achteraf kunt zien hoe vaak het gebeurt en of de regels kloppen.
Door ze aan te vallen vóór een klant het doet. We verzamelen lastige invoer uit jouw praktijk en bij de toepassing horende randgevallen (vragen buiten het gebied, verzoeken om regels te negeren, teksten die op verboden uitkomsten mikt) en draaien die telkens tegen, ook na elke wijziging. Wat erdoorheen glipt, komt in de volgende versie dicht. Zo is de bescherming geen belofte in een document, maar iets wat met terugwerkende kracht bewezen wordt.
EIGHTY8