Inkoopteams bij gereguleerde organisaties zijn al jaren goed in het beoordelen van cloudleveranciers. Ze weten hoe ze een SOC 2-rapport moeten lezen. Ze weten waar ze op moeten letten in een verwerkersovereenkomst. Een vaag sub-processorsbeding herkennen ze op afstand.

Niets van dat alles bereidt ze voor op het moment dat het product een AI-systeem is dat draait op een large language model.

Het aanvalsoppervlak van een LLM-applicatie verschilt fundamenteel van een conventioneel SaaS-platform. Het model zelf introduceert kwetsbaarheden die geen equivalent hebben in traditionele software. Geen enkele ISO-certificering is ontworpen om ze te vangen. Geen enkele pentest had ze in scope. De standaard beoordelingsmethodiek faalt niet omdat hij slecht is. Hij faalt omdat hij gebouwd is voor een ander type product.

Er bestaat wel een raamwerk dat specifiek is ontworpen voor de modellaag. De OWASP Top 10 voor LLM-applicaties benoemt de risico’s die traditionele security-checklists volledig onbehandeld laten, en de meeste inkoopteams in Europa zijn er nog nooit mee in aanraking gekomen.

Een beveiligingsraamwerk voor de modellaag

OWASP, het Open Worldwide Application Security Project, publiceert al meer dan twintig jaar zijn Top 10-lijst van kwetsbaarheden in webapplicaties. Als je in IT-security of softwareontwikkeling werkt, ben je hem vrijwel zeker tegengekomen. De webversie is een de facto industriestandaard, gerefereerd in auditframeworks en compliancevereisten wereldwijd.

In 2023 publiceerde OWASP een aanvullende lijst specifiek voor applicaties gebouwd op large language models. De redenering was eenvoudig: LLM-applicaties introduceren kwetsbaarheidscategorieën die in traditionele software niet bestaan, en de originele OWASP Top 10 zou ze nooit gaan dekken. De LLM-lijst werd eind 2024 bijgewerkt naar de 2025-editie. Dat zegt iets over hoe snel dit domein beweegt.

De tien entries beslaan prompt injection (een model manipuleren zodat het zijn instructies negeert), gevoelige informatielekken (het model onthult data waar het geen toegang toe zou moeten hebben), supply chain-risico’s (niet-geauditeerde componenten van derden in de AI-stack), excessive agency (het model neemt acties die buiten zijn beoogde scope vallen), system prompt leakage, vector- en embeddingzwakheden, datavergiftiging, en meer.

Wat de lijst bijzonder bruikbaar maakt voor een inkooppubliek is dat OWASP een non-profit, community driven project is. Geen leverancier heeft deze lijst geschreven. Geen adviesbureau licentieert hem. Hij is vrij beschikbaar, goed gedocumenteerd, en onderhouden door practitioners zonder commercieel belang bij hoe jouw evaluatie uitpakt. Die onafhankelijkheid telt wanneer je een standaard nodig hebt die de leverancier niet zelf heeft opgesteld.

Wat je huidige leveranciersbeoordeling niet dekt

SOC 2 Type II beoordeelt of de interne beheersmaatregelen van een leverancier op het gebied van beveiliging, beschikbaarheid en vertrouwelijkheid effectief functioneren over tijd. ISO 27001 certificeert dat een leverancier een managementsysteem voor informatiebeveiliging heeft geïmplementeerd. Beide zijn waardevol. Geen van beide is ontworpen om de vraag te beantwoorden: kan dit model gemanipuleerd worden om persoonsgegevens te lekken via een slim geformuleerde prompt?

Dat is een vraag over scope, niet over kwaliteit. SOC 2 en ISO 27001 beoordelen infrastructuur- en procescontroles. Ze dekken hoe data wordt opgeslagen, wie toegang heeft, hoe incidenten worden afgehandeld. Wat ze niet dekken is het gedrag van een probabilistisch systeem dat natuurlijke taal verwerkt, onvoorspelbare output genereert, en mogelijk toegang heeft gekregen tot gevoelige data of downstream tools.

Het praktische gevolg is dat een leverancier elke relevante certificering kan hebben, elke audit kan doorstaan, en alsnog een LLM-applicatie kan uitrollen met serieuze kwetsbaarheden op de modellaag. Als je ooit een leveranciersbeoordeling hebt meegemaakt waarbij de security-sectie volledig bestond uit certificeringslogo’s op een slide, dan weet je hoe dit gaat. Het gebouw komt door de inspectie. Niemand controleert wat de huurder binnen doet.

Vijf risico’s waar inkoopteams om zouden moeten geven

Niet alle tien entries op de OWASP LLM-lijst wegen even zwaar voor iemand die een RFP schrijft of een leveranciersvoorstel beoordeelt. Sommige zijn vooral relevant voor het ontwikkelteam dat de applicatie bouwt. Andere belanden direct op het bureau van degene die beslist of dit systeem de organisatie binnenkomt. Dit zijn de vijf met de meest directe gevolgen voor inkoop.

Prompt injection staat bovenaan de lijst. Het beschrijft de categorie aanvallen waarbij een gebruiker of kwaadwillende input formuleert die het model ertoe brengt zijn oorspronkelijke instructies te negeren. De directe variant kan een klantgerichte chatbot ertoe verleiden zijn systeeminstructies of interne data prijs te geven. De indirecte variant is subtieler: kwaadaardige instructies verborgen in een document dat het model ophaalt als onderdeel van een zoek- of samenvattingstaak. De leverancier zou in staat moeten zijn om zijn gelaagde verdedigingsstrategie hiervoor uit te leggen. Als ze ongemakkelijk kijken wanneer je ernaar vraagt, zegt dat genoeg.

Gevoelige informatielekken is het punt waar de lijst het meest direct raakt aan de AVG. Als een model persoonsgegevens kan tonen in zijn output, of dat nu komt uit de trainingsdata, de retrieval-context, of de gespreksgeschiedenis, dan heeft de verwerkingsverantwoordelijke een probleem. Onder de AVG is de verwerkingsverantwoordelijke aansprakelijk, ongeacht of de onthulling opzettelijk was. De leverancier moet uitleggen hoe persoonsgegevens het model binnenkomen en verlaten bij zowel training als inferentie, en welke dataminimalisatiemaatregelen er daadwerkelijk zijn getroffen. “Wij nemen privacy serieus” is geen antwoord op deze vraag.

Supply chain-kwetsbaarheden verdienen meer aandacht dan ze doorgaans krijgen. Vrijwel geen enkele enterprise AI-implementatie is volledig zelf gebouwd. De applicatie van de leverancier hangt waarschijnlijk af van een basismodel van de ene partij, een embeddingmodel van een andere, een vectordatabase, retrieval-plugins, fine-tuningdatasets van externe bronnen, en evaluatietools van weer een andere partij. Het inkoopteam beoordeelt de leverancier. Maar wie beoordeelt de leveranciers van de leverancier? Een RFP zou openbaarmaking van de AI supply chain moeten vereisen. Als de leverancier die niet kan leveren, koop je een systeem waarvan je de fundamenten niet kunt inspecteren.

Excessive agency wordt relevant zodra een AI-systeem meer kan dan vragen beantwoorden. Als het model e-mails kan versturen, records kan wijzigen, workflows kan triggeren of code kan uitvoeren, gaat het niet meer alleen om wat het model zegt. Het gaat om wat het model doet. OWASP identificeert drie grondoorzaken: het model heeft toegang tot tools die het niet nodig heeft, het opereert met hogere rechten dan vereist, of het neemt impactvolle acties zonder menselijke goedkeuring. Inkoopteams zouden moeten vragen om een helder overzicht van wat het systeem kan doen, welke rechten het heeft, en waar een mens moet tekenen voordat er iets onomkeerbaars gebeurt.

System prompt leakage is een nieuwere toevoeging aan de 2025-lijst en een risico dat veel organisaties onderschatten. System prompts bevatten vaak operationele logica, interne regels, toegangsconfiguraties, en in sommige gevallen zelfs API-sleutels. Omdat LLM’s probabilistisch zijn, bestaat er geen betrouwbare manier om te garanderen dat een system prompt vertrouwelijk blijft zodra het onderdeel is van de context van het model. OWASP is hier duidelijk over: system prompts zijn geen beveiligingscontroles. Als er een geheim in de prompt staat, behandel het dan als blootgesteld. Vraag de leverancier of er credentials, interne logica of toegangsregels in de system prompt zitten. Het juiste antwoord is nee.

Van risicolijst naar beoordelingsinstrument

De waarde van de OWASP LLM Top 10 voor inkoop is dat het inkoopmedewerkers een gestructureerde set vragen geeft waar security, juridische zaken en compliance allemaal mee uit de voeten kunnen. Niemand hoeft security-engineer te worden om het te gebruiken. Het raamwerk doet het vertaalwerk.

In de praktijk betekent dit dat je elke relevante OWASP-entry vertaalt naar een RFP-vraag die de leverancier moet beantwoorden, een beoordelingscriterium dat het evaluatieteam kan scoren, of een contractclausule die een afdwingbare verplichting creëert na tekening. Voor prompt injection zou de RFP-vraag de leverancier kunnen vragen om zijn gelaagde verdedigingsstrategie te beschrijven, inclusief inputfiltering, outputvalidatie, privilegescheiding en monitoring. Voor gevoelige informatielekken zou het kunnen vragen om een datastroomdiagram dat laat zien hoe persoonsgegevens door het systeem bewegen bij training en inferentie.

Sommige organisaties beginnen met het opstellen van wat je een LLM Security Schedule zou kunnen noemen als bijlage bij hun verwerkersovereenkomsten. Het is een apart onderdeel dat modellaagrisico’s adresseert los van de infrastructuurrisico’s die de standaard verwerkersovereenkomst al dekt. Dit is nog ongebruikelijk, maar de organisaties die het doen melden dat het onduidelijkheid aan beide kanten vermindert en het aanzienlijk makkelijker maakt om de leverancier verantwoordelijk te houden als er iets misgaat.

Checkbox compliance versus structurele verificatie

Er is een wezenlijk verschil tussen een leverancier die zegt dat hij prompt injection adresseert en een leverancier die laat zien hoe. Zelfverklaring is waar de meeste leverancierssecurity-beoordelingen beginnen, en te vaak ook waar ze stoppen. De leverancier vult een vragenlijst in, voegt een beleidsdocument bij, en inkoop plaatst het vinkje.

Voor traditionele IT-risico’s heeft die aanpak bekende zwaktes maar werkt hij in grote lijnen. Een firewallregel bestaat of bestaat niet. Een encryptiestandaard is geïmplementeerd of niet. De controls zijn deterministisch en auditeerbaar. LLM-risico’s zijn anders. Een leverancier kan inputfiltering voor prompt injection implementeren en alsnog kwetsbaar zijn voor technieken die die filters omzeilen, omdat het gedrag van het model niet volledig te voorspellen is.

Daarom zou inkoop moeten aandringen op architectureel bewijs. Datastroomdiagrammen die laten zien hoe informatie daadwerkelijk door het systeem beweegt. Documentatie van modeltoegangsbeheer en inferentie-isolatie. Bewijs dat de leverancier red team-tests heeft uitgevoerd tegen OWASP LLM-categorieën. Jurisdictiedocumentatie voor zowel het model als de data die het verwerkt. Niets hiervan maakt het inkoopproces vijandig. Het maakt het specifiek.

Waar infrastructuurarchitectuur het aanvalsoppervlak verkleint

Verschillende risico’s op de OWASP LLM-lijst worden erger afhankelijk van hoe de onderliggende infrastructuur is ingericht. Multi-tenant inferentie-omgevingen, waar meerdere klanten dezelfde modelinfrastructuur delen, vergroten het oppervlak voor gevoelige informatielekken. Grensoverschrijdende dataroutering creëert onzekerheid over welk privacyregime van toepassing is op een gegeven interactie. Ondoorzichtige modelafhankelijkheden van derden maken supply chain-risico’s lastiger te beoordelen omdat de leverancier zelf mogelijk geen volledig zicht heeft op waar hij van afhankelijk is.

In de EU gehoste, single-tenant infrastructuur neemt een deel van deze risico’s weg op architectuurniveau. Wanneer inferentie draait in een geïsoleerde omgeving binnen één jurisdictie, verdwijnen bepaalde categorieën kruisbesmetting en jurisdictionele blootstelling by design. Dat laat prompt injection, excessive agency of system prompt leakage niet verdwijnen. Dat zijn applicatielaagproblemen die applicatielaagcontroles nodig hebben, ongeacht waar de infrastructuur staat. Maar het betekent wel dat de infrastructuur ze niet erger maakt.

Inkoop als laatste verdedigingslinie

Inkoop is niet langer alleen software kopen. Wanneer een organisatie een AI-systeem aanschaft, beslist ze welke modelarchitecturen, welke datastromen en welke risicoprofielen binnen haar perimeter gaan opereren. Die beslissing heeft gevolgen onder de AVG als er data lekt. Het heeft operationele gevolgen als het systeem zich gedraagt op manieren die niemand had voorzien. En het heeft reputatiegevolgen die geen beleidsdocument of verzekeringspolis volledig zal opvangen.

De OWASP Top 10 voor LLM-applicaties laat die risico’s niet verdwijnen. Wat het wel doet is inkoop een gedeelde taal geven met het security-team, het juridische team en de FG. Het biedt een raamwerk om de juiste vragen te stellen vóór het contract wordt getekend, niet nadat het incidentrapport op iemands bureau belandt. Traditionele certificeringen blijven belangrijk en horen onderdeel te zijn van elke evaluatie. Maar ze hebben een aanvulling nodig die de modellaag dekt. OWASP levert die. De organisaties die het nu integreren zullen minder tijd en geld kwijt zijn aan het opruimen van problemen die ze bij de voordeur hadden kunnen tegenhouden.

Bronnen

OWASP Top 10 voor LLM-toepassingen 2025 genai.owasp.org/llm-top-10/

Volledige PDF - OWASP Top 10 voor LLM's v2025 owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf

OWASP GenAI Security Project owasp.org/www-project-top-10-for-large-language-model-applications/

OWASP Top 10 voor Agentische AI-toepassingen genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/

GitHub-repository github.com/OWASP/www-project-top-10-for-large-language-model-applications

Over GLBNXT

GLBNXT levert soevereine AI-oplossingen die zijn gebouwd voor gereguleerde sectoren. Ons platform wordt 100% in de EU gehost, is van ontwerp uit AVG-conform en is gebouwd zonder training op klantdata. We werken met juridische dienstverleners, adviesbureaus voor de overheid en ondernemingen die AI nodig hebben waarop ze kunnen vertrouwen. Lees meer of plan een demonstratie op www.glbnxt.com.