AI-systemen vinden in hoog tempo hun weg naar bedrijfs­pro­cessen, appli­ca­ties en digi­tale dien­sten. Daarmee ontstaat ook een nieuw bevei­li­gings­vraag­stuk. Want een AI-toepas­sing is zelden alleen een model. Rond dat model zitten data, prompts, data­bases, API’s, externe leve­ran­ciers, gebrui­kers, soft­wa­re­com­po­nenten en soms zelfs systemen waarmee de AI zelf­standig hande­lingen kan uitvoeren. Daarom lanceert EXIN de AI Secu­rity Profes­si­onal-certi­fi­ce­ring

Wie AI wil bevei­ligen, moet verder kijken dan bekende risico’s zoals prompt injec­tion. Dat is een van de belang­rijkste bood­schappen van de OWASP AI Exchange, een uitge­breid inter­na­ti­o­naal kennis­plat­form voor secu­rity en privacy rond kunst­ma­tige intel­li­gentie. De AI Exchange omvat inmid­dels meer dan 300 pagina’s met drei­gingen, bevei­li­gings­maat­re­gelen, test­me­thoden en prak­ti­sche richt­lijnen. Het project is opgezet als een open en voort­du­rend bijge­werkte kennis­bron en wordt onder­houden door een inter­na­ti­o­nale groep van meer dan 170 experts. Boven­dien wordt mate­riaal uit het project gebruikt bij de ontwik­ke­ling van onder andere ISO/IEC-stan­daarden en stan­daarden rond de Euro­pese AI Act.

AI is niet hetzelfde als een taalmodel

Een belang­rijk uitgangs­punt van OWASP is dat orga­ni­sa­ties AI-secu­rity niet moeten redu­ceren tot de bevei­li­ging van gene­ra­tieve AI en large language models. De AI Exchange kijkt nadruk­ke­lijk ook naar analy­ti­sche AI, machi­ne­learning­mo­dellen, clas­si­fi­ca­tie­mo­dellen en zelfs tradi­ti­o­nele rule-based systemen.

Daarmee verschilt het project bijvoor­beeld van de bekende OWASP Top 10 for LLM Appli­ca­tions, die vooral bedoeld is om snel inzicht te geven in belang­rijke risico’s rond gene­ra­tieve AI. De AI Exchange probeert juist het complete bevei­li­gings­vraag­stuk in kaart te brengen.

Daarbij waar­schuwt OWASP ook tegen een andere veel­ge­maakte denk­fout: het model is niet het systeem. Een moderne AI-appli­catie bestaat meestal uit meer­dere onder­delen. Denk aan modellen, data, prompts, retrie­valsys­temen, externe tools en tradi­ti­o­nele IT-infra­struc­tuur. Een orga­ni­satie kan bijvoor­beeld een LLM van een externe leve­ran­cier gebruiken, docu­menten uit een eigen vector­da­ta­base ophalen en het model vervol­gens via API’s opdrachten laten uitvoeren in bedrijfs­ap­pli­ca­ties.

Een bevei­li­gings­test van alleen het model zegt dan rela­tief weinig over de veilig­heid van het totale systeem. Ook wijzi­gingen in een prompt, data­bron, model­versie of confi­gu­ratie kunnen eerder uitge­voerde bevei­li­gings­tests ongeldig maken. OWASP advi­seert daarom om modellen, prompts, data­bronnen, tools en infra­struc­tuur als één samen­han­gend systeem te beoor­delen.

Begin met een inventarisatie

Voor veel orga­ni­sa­ties begint het probleem nog funda­men­teler: ze weten niet precies waar AI wordt gebruikt. Daarom begint OWASP zijn aanpak met gover­nance. Orga­ni­sa­ties moeten eerst inzicht krijgen in welke AI-systemen aanwezig zijn, wie daar­voor verant­woor­de­lijk is en welke leve­ran­ciers en data­bronnen daarbij betrokken zijn. Daarna kan worden bepaald welke risico’s daad­wer­ke­lijk rele­vant zijn.

OWASP vat deze orga­ni­sa­to­ri­sche aanpak samen in het acro­niem GUARD: Govern, Under­stand, Adapt, Reduce en Demon­strate.

Bij Govern draait het om beleid, verant­woor­de­lijk­heden, compli­ance en een inven­ta­ri­satie van AI-toepas­singen. Under­stand bete­kent vervol­gens dat orga­ni­sa­ties onder­zoeken welke drei­gingen bij iedere toepas­sing horen. Daarna moeten bestaande secu­ri­ty­pro­cessen worden aange­past aan AI. Denk aan secure devel­op­ment, supply-chain­ma­na­ge­ment, threat model­ling en secu­ri­ty­tes­ting.

Met Reduce bedoelt OWASP dat orga­ni­sa­ties de poten­tiële schade moeten beperken wanneer een AI-systeem toch verkeerde beslis­singen neemt of wordt gema­ni­pu­leerd. Daarbij spelen onder andere mini­male toegangs­rechten, beper­king van gevoe­lige data, mense­lijke controle en guard­rails een rol.

De laatste stap, Demon­strate, draait om aantoon­baar­heid. Orga­ni­sa­ties moeten via testen, docu­men­tatie en moni­to­ring kunnen laten zien dat bevei­li­gings­maat­re­gelen daad­wer­ke­lijk func­ti­o­neren. Dat wordt onder andere belang­rijk rich­ting klanten, mana­ge­ment en toezicht­hou­ders.

Drie groepen bedreigingen

De AI Exchange verdeelt AI-drei­gingen grofweg in drie cate­go­rieën. De eerste cate­gorie ontstaat tijdens de ontwik­ke­ling van een systeem. Een bekend voor­beeld daarvan is data poiso­ning, waarbij trai­nings­data bewust wordt gema­ni­pu­leerd zodat het model later onge­wenst gedrag vertoont.

Een tweede cate­gorie bestaat uit aanvallen via de invoer van het model. Prompt injec­tion bij taal­mo­dellen valt hier­onder, maar ook zoge­naamde evasion attacks waarbij invoer zo wordt aange­past dat een model verkeerde conclu­sies trekt.

De derde cate­gorie bestaat uit meer tradi­ti­o­nele aanvallen tijdens het gebruik van een AI-systeem. Daarbij kan bijvoor­beeld invoer of andere vertrou­we­lijke infor­matie worden gestolen. Volgens OWASP moeten orga­ni­sa­ties daarbij vooral letten op drie moge­lijke doelen van aanval­lers: infor­matie open­baar maken, het systeem misleiden of de werking ervan verstoren.

Een aanvaller kan bijvoor­beeld proberen trai­nings­data te achter­halen, intel­lec­tueel eigendom uit een model te halen of de inte­gri­teit van het gedrag van een AI-systeem te beïn­vloeden. Dat laatste risico wordt belang­rijker nu AI-systemen steeds vaker zelf­standig hande­lingen kunnen uitvoeren.

Agentic AI vergroot de impact

Bij tradi­ti­o­nele gene­ra­tieve AI blijft de impact van een verkeerde uitvoer vaak beperkt tot foutieve tekst of een onjuist advies. Bij agentic AI kan een model echter opdrachten uitvoeren zonder dat een mens iedere afzon­der­lijke actie goed­keurt. Een agent kan bijvoor­beeld zelf­standig andere modellen aanroepen, berichten versturen, data opvragen of acties uitvoeren in bedrijfs­soft­ware.

Daarmee verschuift het secu­ri­ty­vraag­stuk. Een hallu­ci­ne­rend model is verve­lend. Een hallu­ci­ne­rend model met toegangs­rechten tot bedrijfs­pro­cessen kan aanzien­lijk grotere gevolgen hebben. OWASP advi­seert daarom onder andere om het prin­cipe van least privi­lege ook op AI-modellen toe te passen. Een model of agent moet alleen toegang krijgen tot systemen en gege­vens die nood­za­ke­lijk zijn voor zijn taak. Daar­naast blijven moni­to­ring en mense­lijke controle belang­rijk.

Veel maatregelen zijn verrassend vertrouwd

Opval­lend is dat OWASP AI-secu­rity niet presen­teert als een compleet nieuwe tak van cyber­se­cu­rity. Een belang­rijk deel van de maat­re­gelen bestaat uit bestaande secu­ri­ty­prin­cipes die moeten worden uitge­breid naar nieuwe AI-compo­nenten. Denk aan toegangs­con­trole, bescher­ming van gevoe­lige gege­vens, beper­king van resources, secure devel­op­ment, logging, supply-chain­ma­na­ge­ment en moni­to­ring.

Daar komen enkele speci­fieke AI-maat­re­gelen bij. Orga­ni­sa­ties kunnen bijvoor­beeld invoer en uitvoer contro­leren op afwij­kingen, prompt injec­tions proberen te detec­teren, trai­nings­data vali­deren en voort­du­rend contro­leren of modellen nog steeds het verwachte gedrag vertonen. OWASP groe­peert deze maat­re­gelen in vier hoofd­ca­te­go­rieën: beheren, modellen weer­baarder maken, systemen moni­toren en de moge­lijke impact van AI beperken. In totaal beschrijft de Exchange meer dan vijftig afzon­der­lijke controls.

De leverancier neemt het risico niet over

Een andere belang­rijke bood­schap is rele­vant voor vrijwel iedere orga­ni­satie die dien­sten als ChatGPT, Claude, Gemini of andere externe modellen gebruikt. Uitbe­steden bete­kent niet dat de verant­woor­de­lijk­heid voor secu­rity verdwijnt. Bij een extern gehost model verzorgt de leve­ran­cier welis­waar het model en de onder­lig­gende infra­struc­tuur, maar de klant blijft volgens OWASP verant­woor­de­lijk voor onder andere zijn appli­catie, prompts, data, iden­ti­teit en toegangs­rechten, output­ver­wer­king en moni­to­ring.

Wanneer een orga­ni­satie een extern ontwik­keld model zelf host, komen daar nog verant­woor­de­lijk­heden bij, zoals bescher­ming van de model­be­standen, patch­ma­na­ge­ment en bevei­li­ging van de infra­struc­tuur. Wie zelf modellen traint of fine-tunet, wordt daar­naast verant­woor­de­lijk voor trai­nings­data, data­pi­pe­lines, evalu­a­ties en de uitein­de­lijke model­ver­sies.

In de prak­tijk kunnen die vormen boven­dien door elkaar lopen. Een appli­catie kan tege­lij­ker­tijd gebruik­maken van een extern LLM, een intern clas­si­fi­ca­tie­model en een gespe­ci­a­li­seerd embed­ding­model. OWASP advi­seert daarom verant­woor­de­lijk­heden per compo­nent vast te leggen in plaats van één secu­ri­ty­label op een complete AI-oplos­sing te plakken.

AI-security wordt onderdeel van gewone security

Misschien is dat uitein­de­lijk de belang­rijkste bood­schap van de AI Exchange. AI-secu­rity moet geen los project worden naast bestaande cyber­se­cu­ri­ty­pro­cessen. Orga­ni­sa­ties moeten hun bestaande secu­ri­ty­pro­gramma uitbreiden zodat ook AI-speci­fieke compo­nenten, data en drei­gingen worden meege­nomen.

Dat bete­kent dat secu­ri­ty­teams moeten samen­werken met ontwik­ke­laars, data scien­tists, AI-engi­neers, priva­cy­pro­fes­si­o­nals en leve­ran­ciers. Threat model­ling moet worden uitge­breid, supply chains moeten ook modellen en data­sets omvatten en secu­ri­ty­tests moeten reke­ning houden met het soms minder voor­spel­bare gedrag van AI.

Tege­lij­ker­tijd advi­seert OWASP orga­ni­sa­ties om niet auto­ma­tisch iedere denk­bare AI-drei­ging met een omvang­rijke check­list te bestrijden. Begin met het systeem, breng data, modellen, prompts, tools en verant­woor­de­lijk­heden in kaart en bepaal vervol­gens welke risico’s daad­wer­ke­lijk rele­vant zijn.

Juist nu AI steeds dieper in bedrijfs­pro­cessen wordt geïn­te­greerd, lijkt dat een belang­rijk uitgangs­punt. De vraag is niet langer alleen of het gebruikte model veilig is. Orga­ni­sa­ties zullen moeten aantonen dat het complete systeem erom­heen beheers­baar blijft.