Hvor AI-sikkerhedsstandarder stopper — og runtime-beskyttelse må begynde

Med al den snak om sikkerhedsrisici ved AI, synes et problem at være overset: det faktum, at AI-systemer kun fungerer ved at eksponere deres mest værdifulde aktiver — modeller og data.

I modsætning til traditionel software, udfører AI ikke bare foruddefineret logik. Det blander kontinuerligt proprietære modeller med følsomme indgange for at generere udgang, ofte på infrastruktur, der ikke er designet til at beskytte beregning.

På denne måde mangler traditionel sikkerhed. Kryptering er effektiv, når data er gemt eller overført over et netværk, men ikke, når data bearbejdes eller opereres på. For AI specifikt opstår farerne, når en model er deployet. Dens parametre indlæses i hukommelse, initialiseres og udføres i stor skala – det punkt, hvor kryptering stopper – og eksponerer det for potentiel uautoriseret adgang. Under inferens flyder følsomme data gennem det samme eksponerede rum. Resultatet er en høj eksponeringsflade: AI-systemer, der kan synes sikre – men i virkeligheden er ubeskyttede i de kritiske øjeblikke.

Standardiseringsorganisationer som National Institute of Standards and Technology (NIST), Den Europæiske Agentur for Cybersikkerhed (tidligere kendt som Den Europæiske Netværk- og Informationssikkerhedsagentur, eller ENISA) og Open Web Application Security Project (OWASP) har begyndt at kortlægge dette territorium. De beskriver risici, navngiver sårbarheder og fastlægger regler for governance. Men de stopper kort før at foreskrive, hvordan man beskytter modeller som immaterielle aktiver og data som fortrolige aktiver, når udførelse begynder. At lukke denne åbning kræver en omdefinering af AI-sikkerhed – ikke som en compliance-øvelse, men som et problem omkring beregning selv. Her spiller kryptering-i-brug, eller end-to-end-kryptering, en rol.

Den blinde plet i moderne AI-sikkerhed

De fleste AI-sikkerhedsdiskussioner kredser stadig om velkendt jord: styre af træningsdata, adgangskontrol, API-overvågning og ansvarlige brugerpolitikker. Disse er nødvendige. Men ingen af dem beskæftiger sig med, hvad der sker efter deployment, når en model forlader repository og bliver et levende system.

Når en model er deployet, er dens parametre ikke længere abstrakte artefakter. De er levende, hukommelses-resident aktiver, der kontinuerligt adgangs during inferens og ofte bruges af multiple lejere eller kunder gennem delte AI-tjenester. Denne eksponering sker før nogen inferens-anmodning er gjort, og dermed forøger risikoen ved at introducere følsomme indgange og eksternt observerbar adfærd.

At behandle modelbeskyttelse som en pre-deployment-bekymring og inferens-sikkerhed som en runtime-bekymring gør ikke sagen retfærdighed. I virkelige systemer overlapper disse risici. Modeller og data er eksponeret på tværs af initialisering, udførelse og output. Sikkerhed, der begynder og slutter med lagringskontrol, fejler at adressere disse eksponeringer.

Hvad NIST gør rigtigt — og hvor det stopper

NIST’s AI-risikostyringsramme er blevet en hjørnesten for organisationer, der forsøger at styre AI-risiko. Dens struktur — styre, kortlæg, mål, styre — tilbyder en disciplineret måde at tænke om ansvar, kontekst, impact og afhjælpning på tværs af AI-livscyklussen.

Hvad NIST især gør godt, er at definere AI-risiko som systemisk snarere end tilfældigt. AI-fejl er sjældent enkeltstående begivenheder; de opstår fra interaktioner mellem modeller, data, mennesker og infrastruktur. Denne definition er essentiel.

Hvor rammen mangler, er i ikke at diktere, hvordan højværdi-AI-aktiver beskyttes, når systemer er live. Modelparametre behandles implicit som design-tids-artefakter snarere end runtime-aktiver. Udførelse-miljøer antages at være tillidsværdige nok.

I praksis er modelparametre ofte den mest værdifulde immaterielle ejendom, en organisation ejer. De indlæses i hukommelse, kopieres over noder, cachelagres og genbruges. Hvis AI-risikostyring ikke tager højde for fortroligheden af modeller under deployment og udførelse, forbliver en kritisk aktiv uden for risikogrænsen, som en siddende and.

ENISA og virkeligheden af AI-specifikke trusler

ENISA’s arbejde med AI-cybersikkerhed skyder diskussionen videre. Dens multilag-framwork skelner mellem traditionel infrastruktursikkerhed og AI-specifikke risici, og anerkender, at AI-systemer opfører sig anderledes — og fejler anderledes — end konventionel software.

Hvorfor er dette vigtigt? AI introducerer trusler, der ikke passer nøje ind i eksisterende kontroller: model-ekstraktion, parameter-lækage, co-tenancy-eksponering og manipulation under udførelse. Disse risici kræver ikke eksotiske angribere. De opstår naturligt, når højværdi-modeller kører i delte eller eksternt styrede miljøer.

ENISA’s ramme anerkender implicit, at sikring af AI betyder sikring af adfærd, ikke kun kode. Men som de fleste standarder fokuserer den på, hvad der skal overvejes, ikke hvordan beskyttelse teknisk gennemføres, når modeller kører.

OWASP og omkostningerne ved observerbar intelligens

OWASP’s Top 10 for Large Language Model-applikationer tilbyder en mere konkrete syn på, hvordan AI-systemer bryder sammen i den virkelige verden. Prompt-injektion, følsom informations-afsløring, embedding-lækage, excessiv output-transparens — disse er ikke teoretiske bekymringer. De er biprodukter af at deploye kraftfulde modeller uden at begrænse, hvad de afslører.

Selvom disse problemer ofte beskrevet som applikationslag-problemer, er deres konsekvenser dybere. Gentagen eksponering af modeladfærd kan føre til effektiv kloning; dårligt isolerede embeddings kan afsløre struktur; og inferens-misbrug bliver en vej til model-replikation.

OWASP’s taksonomi gør én ting klart: beskyttelse af AI handler ikke kun om at stoppe dårlige indgange. Det handler om at begrænse, hvad modeller afslører — internt og eksternt — når de er operative.

En fælles konklusion, en uafsluttet opgave

På tværs af NIST, ENISA og OWASP er der bred enighed om grundlæggende principper:

• AI-risiko omfatter livscyklussen
• AI-systemer introducerer nye trusskategorier
• Modeller og data er højværdi-aktiver
• Runtime-eksponering er uundgåelig

Hvad disse rammer mangler, er dog en mekanisme for at gennemtvinge fortrolighed, når modeller er deployet og beregning begynder. Denne udeladelse er ikke en fejl, da standarder definerer intention og omfang. Implementering overlades normalt til system-designeren.

Men de efterlader en kritisk åbning — en, der vokser bredere, efterhånden som AI-systemer skalerer.

Kryptering-i-brug ændrer ligningen

Kryptering-i-brug skifter sikkerhedsmodellen. I stedet for at antage, at data og modeller må være eksponeret for at være nyttige, behandler det beregning som noget, der kan beskyttes.

I praksis betyder dette:

• Modeller forbliver krypterede under deployment, initialisering og udførelse
• Indgange er aldrig synlige i klartekst for udførelse-miljøet
• Mellemtilstande kan ikke inspiceres eller ændres
• Infrastruktur behøver ikke længere at være implicit tillidsværdig

Dette erstatter ikke governance-rammer eller applikationslag-kontroller — det operationaliserer dem. Det omdanner risiko-principper til gennemtvingelige garantier lige, når AI-systemer er mest sårbare.

Med andre ord er kryptering-i-brug den manglende lag mellem AI-politik og AI-virkelighed.

Når governance slutter og udførelse begynder: Beskyttelse af AI-beregning

AI-sikkerhed bryder sammen på runtime. Når AI-modeller og følsomme data må være eksponeret i hukommelse for at fungere, opstår en eksponeringsflade, som traditionelle kontroller — kryptering i hvile, kryptering under overførsel og governance-rammer — ikke var designet til at beskytte.

Standardiseringsorganisationer som NIST, ENISA og OWASP har gjort kritisk fremgang i at definere AI-risiko, ansvar og misbrug. Men deres vejledning behandler modeller som design-tids-artefakter og antager, at udførelse-miljøer kan tillides. I praksis er modelparametre og følsomme indgange kontinuerligt adgangs, genbruges og ofte bearbejdes i delte eller eksternt styrede miljøer.

At lukke denne åbning kræver en omdefinering af AI-sikkerhed ikke som en compliance-øvelse, men som et problem omkring beskyttelse af beregning selv — når modeller er live, data er i brug, og eksponering er uundgåelig. Kryptering-i-brug tilbyder en viable måde at holde AI-modeller og følsomme indgange sikre på tværs af alle stadier af AI-livscyklussen.