Uw organisatie heeft een AI-platform, en binnenkort gebruikt iedereen het elke dag. Ze plakken er contracten in, stellen er vragen over klanten aan, en vroeg of laat vraagt iemand wat een collega verdient. Hoe slim het model is, bepaalt niet of dit goed afloopt. Wat dat wel bepaalt, is wat het model tegenhoudt voordat het iets doet waar uw organisatie spijt van krijgt.

Daar zijn AI-guardrails voor. Elke leverancier zegt ze te hebben. Weinigen kunnen vertellen waar ze draaien of wie ze beheert. Dit stuk is voor de mensen die straks verantwoording afleggen over de uitrol: IT, security, juridische zaken, privacy en de afdelingshoofden wier teams ermee gaan werken.

Wat een AI-guardrail is, en wat niet

Een guardrail is een technische maatregel die beperkt wat een AI-systeem mag ontvangen, doen of teruggeven. Hij zit om het model heen: hij filtert invoer, beperkt welke tools en data het model kan bereiken, controleert de uitvoer en logt wat er is gebeurd. Het systeem dwingt hem af. Het model wordt niet gevraagd zich eraan te houden.

Dat verschil doet ertoe. Een regel in een systeemprompt met "geef nooit vertrouwelijke informatie prijs" is een beleefd verzoek aan een probabilistisch systeem, meer niet. En uw medewerkers zijn niet de enigen die de grenzen gaan opzoeken. Nieuwsgierige collega's doen dat, vermoeide collega's ook. Uiteindelijk ook iemand met kwade bedoelingen.

Het onderzoek laat zien waarom. Wei et al. (2023) tonen in Jailbroken: How Does LLM Safety Training Fail? dat veiligheidstraining op twee voorspelbare manieren faalt: wanneer de doelen van een model met elkaar botsen, en wanneer een prompt buiten het bereik van de training valt. Zou et al. (2023) lieten zien dat automatisch gegenereerde adversarial suffixes gealigneerde modellen tot schadelijke uitvoer konden brengen, en dat die aanvallen overdraagbaar waren tussen modellen. Veiligheid die alleen in het model zit, kan worden weggepraat. Dat is precies de reden om de controle erbuiten te leggen.

Interne AI-risico's: wat er binnen uw eigen muren mis kan gaan

De meeste interne risico's zijn alledaags. Juist daarom zijn ze gevaarlijk: ze groeien mee met elke nieuwe gebruiker.

Begin bij toegang. Koppel een AI aan uw documentopslag met ruimere rechten dan de vragensteller zelf heeft, en het systeem antwoordt zonder blikken of blozen uit bestanden die die persoon nooit had mogen zien. De OWASP Top 10 for LLM Applications (editie 2025) schaart dit onder excessive agency: het systeem kan meer bereiken dan de taak vereist.

Dan is er content met verborgen instructies. Greshake et al. (2023) beschreven indirect prompt injection: instructies verstopt in een webpagina, een e-mail of een gedeeld document, die de AI later leest en opvolgt zonder dat de medewerker ze ooit ziet. Een pdf van een leverancier wordt zo een opdracht aan uw assistent.

En er zijn stellige foute antwoorden, waar helemaal geen aanvaller voor nodig is. Collega's handelen naar wat het systeem zegt, zeker als het overtuigend klinkt.

Een guardrail die alleen het chatvenster scant, mist het grootste deel hiervan. Echte guardrails zitten op elke grens: wat erin gaat, wat het model mag ophalen, wat het mag doen en wat eruit komt.

Wie is aansprakelijk als een AI-chatbot de fout in gaat? Vraag het Air Canada

Wie denkt dat een AI-fout het probleem van het model is, kan het Air Canada vragen. In Moffatt v. Air Canada (2024 BCCRT 149) kreeg een klant van de chatbot op de website verkeerde informatie over een rouwtarief. De luchtvaartmaatschappij betoogde in feite dat de chatbot een eigen entiteit was en dat het bedrijf niet verantwoordelijk was voor wat die zei. Het tribunaal veegde dat van tafel:

"Het maakt geen verschil of de informatie van een statische pagina of van een chatbot komt."

Die zaak ging over een chatbot voor klanten, maar het principe geldt net zo goed binnen de organisatie. Als een medewerker een door AI opgesteld antwoord naar een klant stuurt, of handelt op basis van een AI-samenvatting, dan is het resultaat van de organisatie. Die verantwoordelijkheid gaat niet over op het model, en ook niet op de leverancier.

Verplichtingen voor gebruiksverantwoordelijken onder de AI-verordening: artikel 4, 14 en 15

De AI-verordening (Verordening (EU) 2024/1689) richt zich niet alleen tot de bedrijven die AI bouwen. Ze legt ook verplichtingen op aan de organisaties die AI gebruiken, de gebruiksverantwoordelijken. Artikel 4 vraagt om maatregelen die zorgen voor "een toereikend niveau van AI-geletterdheid" bij personeel en anderen die namens de organisatie AI-systemen bedienen en gebruiken. Uw mensen moeten weten hoe ze er veilig mee werken, en het platform hoort dat makkelijker te maken, niet moeilijker.

Voor systemen met een hoog risico gaat artikel 14, lid 1 verder en eist dat zij:

"zodanig ontworpen en ontwikkeld [worden], met inbegrip van passende mens-machine-interface-instrumenten, dat hierop tijdens de periode dat zij worden gebruikt, op doeltreffende wijze toezicht kan worden uitgeoefend door natuurlijke personen."

Artikel 15, lid 1 voegt daaraan toe dat zulke systemen "een passend niveau van nauwkeurigheid, robuustheid en cyberbeveiliging" moeten bieden, "alsook consistente prestaties gedurende de levenscyclus op deze gebieden".

Niet elke interne toepassing is een hoogrisicosysteem, maar de richting is duidelijk. Op doeltreffende wijze toezicht. Gedurende de levenscyclus. Dat beschrijft maatregelen die elke dag werken en die iemand in uw organisatie kan controleren. Een belofte die eenmalig bij de aanbesteding is gedaan, haalt die lat niet.

Het NIST AI Risk Management Framework (AI RMF 1.0) komt op hetzelfde punt uit. Het omschrijft betrouwbare AI als valide en betrouwbaar, veilig, beveiligd en weerbaar, verantwoord en transparant, verklaarbaar en interpreteerbaar, privacybeschermend, en eerlijk met beheerste schadelijke bias. Het grootste deel van die lijst gaat over het systeem om het model heen, en dat is precies het deel dat u koopt.

Waarom AI-guardrails en datasoevereiniteit bij elkaar horen

Als uw guardrails draaien in de omgeving van een ander, onder de jurisdictie van een ander, met regels die een ander van de ene op de andere dag kan wijzigen, dan is uw veiligheidslaag gewoon de zoveelste afhankelijkheid. Het risico is verhuisd. Het is niet verdwenen.

Zeggenschap over waar uw data staat en zeggenschap over hoe uw AI zich gedraagt, zijn dezelfde vraag twee keer gesteld: wie beslist? Voor uw organisatie hoort het antwoord te zijn: u.

Hoe AI-guardrails voor organisaties eruit moeten zien

Een platform waar uw medewerkers op kunnen bouwen, moet een korte reeks toetsen doorstaan. De maatregelen worden buiten het model afgedwongen, waar een slimme prompt er niet zomaar omheen praat. Ze dekken elke grens, inclusief wat het model ophaalt en welke tools het aanroept, en niet alleen het chatvenster. Toegang volgt uw organisatie, zodat de AI alleen bij data komt die een medewerker toch al mocht zien. De regels zijn van u: uw beheerders stellen het beleid in voor uw sector, uw dataclassificatie en uw risicobereidheid. Elke blokkade en elke overrule wordt gelogd op een plek waar uw eigen team meekijkt. Red teaming staat in de agenda, en blijft daar ook na de livegang staan. En er blijft een mens in de lus overal waar de gevolgen dat rechtvaardigen.

Vragen die u een AI-leverancier stelt over guardrails

Vraag elke AI-leverancier waar de guardrails draaien en wat ze precies afdwingen. Vraag wie in uw organisatie de regels kan aanpassen, en wie bij de leverancier dat kan. Vraag hoe het platform voorkomt dat een medewerker bij data komt waar hij geen recht op heeft. En vraag hoe de guardrails worden getest, en of uw eigen securityteam ze ook mag testen.

Krijgt u concrete antwoorden, dan spreekt u met iemand die een controle heeft gebouwd. Blijven ze vaag, dan heeft u beleid en een verkooppraatje in handen.

Kan uw organisatie de AI niet controleren, dan moet u uw medewerkers niet vragen erop te vertrouwen. Guardrails zijn iets wat u moet kunnen zien en testen. Geloof is geen controle.

GLBNXT bouwt in de EU gehoste, ISO 27001:2022-gecertificeerde AI-infrastructuur voor organisaties in gereguleerde sectoren, met guardrails die door de eigen beheerders van de klant worden ingesteld en beheerd. www.glbnxt.com

Bronnen

• Wei, A., Haghtalab, N., Steinhardt, J. (2023). Jailbroken: How Does LLM Safety Training Fail? https://arxiv.org/abs/2307.02483

• Zou, A., Wang, Z., Kolter, J. Z., Fredrikson, M. (2023). Universal and Transferable Adversarial Attacks on Aligned Language Models. https://arxiv.org/abs/2307.15043

• Greshake, K. et al. (2023). Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. https://arxiv.org/abs/2302.12173

• OWASP, Top 10 for Large Language Model Applications (2025): https://owasp.org/projects/top-10-for-large-language-model-applications

• Moffatt v. Air Canada, 2024 BCCRT 149 (British Columbia Civil Resolution Tribunal): https://www.canlii.org/en/bc/bccrt/doc/2024/2024bccrt149/2024bccrt149.html

• Verordening (EU) 2024/1689 (AI-verordening), artikel 4: https://artificialintelligenceact.eu/article/4/

• Verordening (EU) 2024/1689 (AI-verordening), artikel 14: https://artificialintelligenceact.eu/article/14/

• Verordening (EU) 2024/1689 (AI-verordening), artikel 15: https://artificialintelligenceact.eu/article/15/

• NIST (2023), Artificial Intelligence Risk Management Framework (AI RMF 1.0): https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf