Waar AI-beveiligingsnormen stoppen — en runtime-bescherming moet beginnen

Met alle gesprekken over de beveiligingsrisico’s van AI, lijkt er één kwestie te worden over het hoofd gezien: het feit dat AI-systemen alleen functioneren door hun meest waardevolle activa — modellen en gegevens — bloot te stellen.

In tegenstelling tot traditionele software, voert AI geen vooraf gedefinieerde logica uit. Het combineert voortdurend propriëtaire modellen met gevoelige invoer om uitvoer te genereren, vaak op infrastructuur die niet is ontworpen om berekening te beschermen.

Op deze manier schiet traditionele beveiliging tekort. Versleuteling is effectief wanneer gegevens worden opgeslagen of via een netwerk worden verzonden, maar niet wanneer gegevens worden verwerkt of bewerkt. Voor AI in het bijzonder ontstaat het gevaar wanneer een model wordt geïmplementeerd. De parameters worden in het geheugen geladen, geïnitialiseerd en op grote schaal uitgevoerd – het punt waarop versleuteling stopt – waardoor deze blootgesteld wordt aan potentieel ongeoorloofde toegang. Tijdens inferentie stromen gevoelige gegevens door dezelfde blootgestelde ruimte. Het resultaat is een zeer kwetsbaar risicovlak: AI-systemen die mogelijk beveiligd lijken – maar in werkelijkheid onbeschermd zijn op de meest kritieke momenten.

Norminstellingen zoals het National Institute of Standards and Technology (NIST), de Europese Unie Agentschap voor Cyberbeveiliging (voorheen bekend als de Europese Netwerk- en Informatiebeveiligingsagentschap, of ENISA), en de Open Web Application Security Project (OWASP) zijn begonnen met het in kaart brengen van dit terrein. Zij beschrijven de risico’s, noemen de kwetsbaarheden en schetsen governance-principes. Maar zij stoppen kort voor het voorschrijven van hoe modellen als intellectueel eigendom en gegevens als vertrouwelijke activa moeten worden beschermd zodra de uitvoering begint. Het sluiten van deze kloof vereist het opnieuw definiëren van AI-beveiliging – niet als een compliance-oefening, maar als een probleem van berekening zelf. Dit is waar versleuteling-in-gebruik, of eind-tot-eindversleuteling, een rol speelt.

De Blinde Vlek in Moderne AI-Beveiliging

De meeste AI-beveiligingsgesprekken draaien nog steeds om vertrouwd terrein: training data governance, toegangscontrole, API-monitoring, en verantwoorde gebruikersbeleid. Deze zijn noodzakelijk. Echter, geen van deze adresseert wat er gebeurt na implementatie, wanneer een model de repository verlaat en een levend systeem wordt.

Eens geïmplementeerd, zijn een modelparameters niet langer abstracte artefacten. Zij zijn levende, in het geheugen aanwezige activa, die voortdurend worden benaderd tijdens inferentie en vaak door meerdere tenants of klanten worden gebruikt via gedeelde AI-diensten. Deze blootstelling treedt op voordat enige inferentieaanvraag wordt gedaan, waardoor het risico wordt verergerd door gevoelige invoer en extern waarneembare gedragingen in te voeren.

Het behandelen van modelbescherming als een pre-implementatiekwestie en inferentiebeveiliging als een runtimekwestie mist het punt. In reële systemen overlappen deze risico’s. Modellen en gegevens worden blootgesteld over initialisatie, uitvoering en uitvoer. Beveiliging die begint en eindigt met opslagcontrole faalt om deze blootstellingen aan te pakken.

Wat NIST Goed Doet — en Waar Het Stopt

Het NIST AI Risk Management Framework is een hoeksteen geworden voor organisaties die proberen AI-risico’s te beheren. De structuur — governance, kaart, meten, beheren — biedt een gedisciplineerde manier om na te denken over verantwoordelijkheid, context, impact en mitigatie over de AI-levenscyclus.

Wat NIST bijzonder goed doet, is AI-risico’s kaderen als systemisch in plaats van toevallig. AI-falen is zelden een enkelvoudig punt; het ontstaat uit interacties tussen modellen, gegevens, mensen en infrastructuur. Die kadering is essentieel.

Waar het kader tekort schiet, is in het niet voorschrijven van hoe hoge-waarde AI-activa worden beschermd zodra systemen live zijn. Modelparameters worden impliciet behandeld als ontwerp-tijd-artefacten in plaats van runtime-activa. Uitvoeringsomgevingen worden verondersteld vertrouwd genoeg te zijn.

In de praktijk zijn modelparameters vaak de meest waardevolle intellectuele eigendom die een organisatie bezit. Zij worden in het geheugen geladen, over knooppunten gekopieerd, in de cache opgeslagen en hergebruikt. Als AI-risicobeheer niet rekent met de vertrouwelijkheid van modellen tijdens implementatie en uitvoering, blijft een kritisch actief buiten de risicogrens, als een zittende eend.

ENISA en de Realiteit van AI-Specifieke Bedreigingen

ENISA’s werk over AI-cyberbeveiliging duwt het gesprek verder. De multilaagse structuur onderscheidt tussen traditionele infrastructuurbeveiliging en AI-specifieke risico’s, erkennend dat AI-systemen zich anders gedragen — en anders falen — dan conventionele software.

Waarom is dit belangrijk? AI introduceert bedreigingen die niet netjes in bestaande controles passen: model-extractie, parameter-lekkage, co-tenancy-blootstelling en manipulatie tijdens uitvoering. Deze risico’s vereisen geen exotische aanvallers. Zij ontstaan natuurlijk wanneer hoge-waarde modellen worden uitgevoerd in gedeelde of extern beheerde omgevingen.

ENISA’s structuur erkent impliciet dat het beveiligen van AI het beveiligen van gedrag betekent, niet alleen code. Maar net als de meeste normen, richt het zich op wat moet worden overwogen, niet op hoe beschermingen technisch worden afgedwongen zodra modellen worden uitgevoerd.

OWASP en de Kosten van Observable Intelligentie

OWASP’s Top 10 voor Large Language Model-toepassingen biedt een meer concrete kijk op hoe AI-systemen in de praktijk falen. Prompt-injectie, gevoelige informatie-onthulling, embedding-lekkage, overmatige uitvoertransparantie — deze zijn geen theoretische zorgen. Zij zijn de bijproducten van het implementeren van krachtige modellen zonder te beperken wat zij onthullen.

Hoewel deze problemen vaak worden geframed als application-laagproblemen, zijn de gevolgen dieper. Herhaalde blootstelling van modelgedrag kan leiden tot effectieve kloning; slecht geïsoleerde embeddings kunnen structuur onthullen; en inferentie-misbruik wordt een pad naar model-replicatie.

OWASP’s taxonomie maakt één ding duidelijk: het beveiligen van AI is niet alleen een kwestie van het stoppen van slechte invoer. Het is een kwestie van het beperken van wat modellen onthullen — intern en extern — zodra zij operationeel zijn.

Een Gedeelde Conclusie, een Onvoltooide Taak

Over NIST, ENISA en OWASP heen is er brede overeenstemming over de fundamenten:

• AI-risico overspant de levenscyclus
• AI-systemen introduceren nieuwe bedreigingscategorieën
• Modellen en gegevens zijn hoge-waarde activa
• Runtime-blootstelling is onvermijdelijk

Wat deze kaders ontbreken, is een mechanisme voor het afdwingen van vertrouwelijkheid zodra modellen zijn geïmplementeerd en berekening begint. Deze omissie is geen fout, aangezien normen intentie en scope definiëren. Implementatie wordt meestal overgelaten aan de systeemontwerper.

Maar zij laten een kritische kloof achter — een die breder wordt naarmate AI-systemen schalen.

Versleuteling-in-Gebruik Verandert de Vergelijking

Versleuteling-in-gebruik verandert het beveiligingsmodel. In plaats van aan te nemen dat gegevens en modellen blootgesteld moeten worden om nuttig te zijn, behandelt het berekening als iets dat beschermd kan worden.

In praktische termen betekent dit:

• Modellen blijven versleuteld tijdens implementatie, initialisatie en uitvoering
• Invoer is nooit zichtbaar in plaintext voor de uitvoeringsomgeving
• Tussenliggende staten kunnen niet worden geïnspecteerd of gewijzigd
• Infrastructuur hoeft niet langer impliciet te worden vertrouwd

Dit vervangt geen governance-kaders of application-laagcontroles — het operationaliseert ze. Het verandert risicoprincipes in afdwingbare garanties recht op het moment dat AI-systemen het meest kwetsbaar zijn.

Met andere woorden, versleuteling-in-gebruik is de ontbrekende laag tussen AI-beleid en AI-reality.

Wanneer Governance Eindigt en Uitvoering Begint: Het Beveiligen van AI-Berekening

AI-beveiliging breekt af tijdens runtime. Eens geïmplementeerd, moeten AI-modellen en gevoelige gegevens blootgesteld worden in het geheugen om te functioneren, waardoor een risicovlak ontstaat dat traditionele controles — versleuteling bij rust, versleuteling in transit, en governance-kaders — nooit zijn ontworpen om te beschermen.

Norminstellingen zoals NIST, ENISA en OWASP hebben kritische vooruitgang geboekt in het definiëren van AI-risico, verantwoordelijkheid en misbruik. Maar hun richtlijnen behandelen modellen meestal als ontwerp-tijd-artefacten en veronderstellen dat uitvoeringsomgevingen te vertrouwen zijn. In de praktijk worden modelparameters en gevoelige invoer voortdurend benaderd, hergebruikt en vaak verwerkt in gedeelde of extern beheerde omgevingen.

Het sluiten van deze kloof vereist het opnieuw definiëren van AI-beveiliging niet als een compliance-oefening, maar als een probleem van het beschermen van berekening zelf — wanneer modellen live zijn, gegevens in gebruik zijn en blootstelling onvermijdelijk is. Versleuteling-in-gebruik biedt een haalbare manier om AI-modellen en gevoelige invoer te beveiligen over elke fase van de AI-levenscyclus.