In alle AI-implementaties die ik in verschillende sectoren heb beoordeeld, valt één patroon op: organisaties zoeken het risico op de verkeerde plek. Hun focus ligt meestal op het model zelf, inclusief de trainingsdata, beveiligingsmaatregelen en het gedrag. In de praktijk is dat echter zelden waar het misgaat.
Veel van de meest impactvolle kwetsbaarheden ontstaan in het omliggende systeem — in de manier waarop prompts worden opgebouwd, hoe externe data wordt verkregen en vertrouwd, waar het model toegang toe heeft en onder welke identiteiten het opereert. Hier zijn AI-systemen het vaakst blootgesteld: in de verbindingen tussen componenten, waar governance meestal het zwakst is.
Het diepere probleem is de kloof tussen verwachting en realiteit. Organisaties verwachten een bepaald type falen, maar productiesystemen falen op totaal andere manieren. Het risico ontstaat in die mismatch — in aannames die geen stand houden bij schaal, autonomie of integratie.
Dezelfde misvattingen over het beveiligen van AI komen steeds weer terug. Het is de moeite waard om de vijf belangrijkste te bekijken.
Misvatting #1: Als het model veilig is, is het systeem veilig
Dit is de meest voorkomende fout die ik zie, en hij is gemakkelijk te maken. Het model voelt nieuw, dus teams richten zich op guardrails en testen en gaan er vervolgens van uit dat het werk klaar is.
Maar zo falen deze systemen niet. Het model is slechts één component van een veel grotere infrastructuur, en de meeste fouten ontstaan waar het verbonden is met data, tools en andere systemen. Alleen focussen op het model is als het installeren van een hoogbeveiligde deur in een gebouw zonder muren.
Hoe dit op te lossen: om een AI-systeem te beveiligen, moet je de volledige omgeving zien als het aanvalsvlak. Breng de volledige datastroom in kaart — van input tot retrieval en geheugen, en van tools tot output — en beheer prompts, agents, vectorstores, identiteiten en connectors als beheerde assets, met duidelijke controlepunten, verantwoordelijkheid en beleid, zoals bij elk ander kritisch systeem.
Misvatting #2: Prompt injection is gewoon een invoerprobleem
Beveiligingsteams met een webachtergrond grijpen vaak naar bekende tools wanneer ze een nieuw probleem tegenkomen. Bij het beveiligen van AI kan dat instinct hen echter de verkeerde kant op sturen.
Prompt injection lijkt op SQL-injection — waarbij systemen kwaadaardige input als een commando behandelen — maar gedraagt zich heel anders. Traditionele software kan een duidelijke scheiding afdwingen tussen instructies en data. Grote taalmodellen kunnen dat niet betrouwbaar doen. Ze verwerken instructies en data als één stroom tekst en maken probabilistische inschattingen over wat wat is.
Het Britse National Cyber Security Centre (NCSC) is hier duidelijk over: prompt injection is structureel anders dan SQL-injection en vereist een andere aanpak.
Hoe dit op te lossen: filters en detectiemechanismen helpen, maar lossen het probleem niet op zichzelf op. De meest effectieve maatregelen zijn architectonisch van aard. Beperk de toegang tot tools, pas het least-privilegeprincipe toe, isoleer niet-vertrouwde content en valideer toolaanroepen en parameters deterministisch. Vereis expliciete goedkeuring voor gevoelige acties, gebruik sandboxing en monitor streng. Deze maatregelen verminderen zowel de kans als de impact van een compromis, maar elimineren het risico niet. Als het restrisico onaanvaardbaar blijft, is de use case niet geschikt voor een large language model.
Misvatting #3: AI-output is gewoon tekst — het creëert geen echt risico
Vroege AI-implementaties beloonden autonomie. Die benadering is meegenomen naar productieomgevingen waar ze niet thuishoort.
AI-output kan eruitzien als onschuldige tekst, maar blijft dat zelden. Zodra deze aan een ander systeem wordt doorgegeven, kan dit leiden tot echte acties — e-mails verzenden, databases bevragen, code uitvoeren of een record verwijderen. In die context erft een succesvolle prompt injection alle mogelijkheden van het systeem.
Daar wordt het risico reëel: de mogelijkheden van het systeem worden de mogelijkheden van de aanvaller.
Het Open Web Application Security Project identificeert overmatige autonomie als een van de ernstigste risico’s in agentische AI, terwijl het NCSC aangeeft dat dit precies het punt is waarop prompt injection ophoudt een hinder te zijn en een beveiligingsincident wordt.
Hoe dit op te lossen: het is eenvoudig: beperk wat het systeem kan doen, pas het least-privilegeprincipe toe en behandel modeloutput als onbetrouwbaar totdat deze deterministisch is gevalideerd bij de uitvoeringsgrens. Dit maakt een gecompromitteerde agent niet onschadelijk, maar verkleint wel aanzienlijk de impact.
Misvatting #4: Het gebruik van externe data maakt AI betrouwbaarder en veiliger
Retrieval-augmented generation (RAG), waarbij modellen externe data gebruiken, verbetert de nauwkeurigheid maar maakt systemen niet veiliger. Onderzoek gepubliceerd door USENIX toont aan dat het manipuleren van een klein aantal kennisbankitems voldoende is om RAG-output op schaal betrouwbaar te beïnvloeden.
Elke databron die je koppelt, wordt een potentiële toegangspoort. Als die data onbetrouwbaar, verouderd of gemanipuleerd is, kan dit de output van het model op moeilijk detecteerbare manieren beïnvloeden.
Hoe dit op te lossen: dit is zowel een modelprobleem als een data- en supplychainprobleem. Behandel externe bronnen als afhankelijkheden die governance vereisen. Pas controles toe voor herkomst, validatie, schrijfrechten, ingestiescans, versiebeheer, scheiding van bronnen en changemanagement.
Misvatting #5: Managed AI betekent dat de leverancier de beveiliging regelt
Mensen verwarren managed services vaak met uitbestede beveiliging. In werkelijkheid is de verantwoordelijkheid gedeeld, maar blijven de beveiligingsverantwoordelijkheden van de klant aanzienlijk.
De leverancier beveiligt de dienst zelf. Jij bent verantwoordelijk voor alles eromheen: welke data wordt ingevoerd, wie toegang heeft, wat het model mag doen en hoe de output wordt gebruikt.
Hoe dit op te lossen: wees expliciet over wat jouw verantwoordelijkheid is, breng de gedeelde verantwoordelijkheid duidelijk in kaart en ga er niet van uit dat iets veilig is alleen omdat het managed is. Beoordeel de controles van de leverancier en dicht vervolgens zelf de gaten op het gebied van identiteit, databeheer, configuratie, monitoring en integratiebeveiliging.
Wat elke implementatie zou moeten bevatten
De meeste organisaties die ik beoordeel, kunnen de AI-systemen opsommen die ze hebben ingezet. Veel minder kunnen me vertellen wie ervoor verantwoordelijk is, welke data ze gebruiken, wat ze kunnen doen of wat er gebeurt als ze falen. Dat wijst op een governanceprobleem.
De basis is niet bijzonder ingewikkeld; ze wordt alleen ongelijk toegepast.
Minimaal zou je het volgende moeten hebben:
- Een duidelijke, door het management goedgekeurde AI-beveiligingsstrategie en een gedefinieerde risicobereidheid, afgestemd op specifieke use cases en datatypen
- Een volledige inventaris van je AI-assets (modellen, prompts, agents, datasets, vectorstores, connectors, serviceaccounts en plugins), met benoemde eigenaren
- Threat models die vertrouwensgrenzen definiëren en beleid afdwingen op voorspelbare controlepunten
- Sterke integriteitscontroles in je supplychain en datapipeline, inclusief herkomst, ondertekening, scanning, traceerbaarheid, versiebeheer en waar nodig beheerde registers
- Toegang tot tools voor agents volgens het least-privilegeprincipe, met human-in-the-loop toezicht voor acties met grote impact
- Validatielagen op output voordat iets wordt uitgevoerd, opgeslagen of aan gebruikers wordt blootgesteld
- Continue evaluatie en monitoring als onderdeel van changemanagement
- Incidentrunbooks die in de praktijk zijn getest, inclusief scenario’s voor containment, veilige uitschakeling en rollback
Door deze elementen te implementeren, pas je dezelfde engineeringdiscipline toe die van elk kritisch systeem wordt verwacht.
De kern van AI-beveiliging
AI-beveiliging gaat verder dan alleen het beveiligen van systemen of modellen. Wie dat vroeg inziet, loopt voor op degenen die het pas leren nadat er iets misgaat.
Dit is geen eenmalige oefening. AI-systemen blijven zich ontwikkelen en beveiliging moet meegroeien. Dat betekent doorlopende tests, inclusief red teaming — het doelbewust proberen te breken van het systeem om de zwakke punten te begrijpen.
En als je je blootstelling over modellen, integraties, datapipelines en agents niet duidelijk kunt verantwoorden, dan vormt die onzekerheid zelf al een deel van het risico.