Tankeledere

Hvor AI-sikkerhetsstandarder stopper — og runtime-beskyttelse må begynne

mm
Legg til Unite.AI blant dine foretrukne kilder på Google

Med all samtalen om sikkerhetsrisikoene med AI, ser ett problem ut til å bli oversett: det faktum at AI-systemer bare fungerer ved å eksponere sine mest verdifulle aktiva — modeller og data.

I motsetning til tradisjonell programvare, utfører AI ikke bare forhåndsdefinert logikk. Den blander kontinuerlig proprietære modeller med sensitive inndata for å generere utdata, ofte på infrastruktur som ikke er designet for å beskytte beregninger.

På denne måten, kommer tradisjonell sikkerhet til kort. Kryptering er effektiv når data lagres eller overføres over et nettverk, men ikke når data bearbeides eller opereres på. For AI spesifikt, oppstår faren når en modell er deployet. Parametrene lastes inn i minne, initialiseres og utføres i stor skala – punktet hvor kryptering stopper – og eksponerer det for potensiell uautorisert tilgang. Under inferens, flyter sensitive data gjennom samme eksponerte rom. Resultatet er en høyt sårbær risikoflate: AI-systemer som kan se ut til å være sikre – men i virkeligheten er ubeskyttet i de kritiske øyeblikkene.

Standardiseringsorganer som National Institute of Standards and Technology (NIST), Den europeiske unionens byrå for cybersikkerhet (tidligere kjent som Den europeiske nettverk- og informasjonssikkerhetsbyrå, eller ENISA), og Open Web Application Security Project (OWASP) har begynt å kartlegge dette territoriet. De beskriver risikoene, navngir sårbarhetene og fastsetter styringsprinsipper. Men de stopper kort av å preskribere hvordan man skal beskytte modeller som immaterielle eiendommer og data som konfidensielle aktiva når utføringen begynner. Å lukke denne gapet krever å omdefinere AI-sikkerhet – ikke som en compliance-øvelse, men som et problem med beregning selv. Dette er hvor kryptering-i-bruk, eller end-to-end-kryptering, spiller en rol.

Den blinde flekk i moderne AI-sikkerhet

De fleste samtaler om AI-sikkerhet befinner seg fortsatt på bekjent grunn: styring av treningsdata, tilgangskontroll, API-overvåking, og ansvarlige brukerpolitikker. Disse er nødvendige. Men ingen av dem addresserer hva som skjer etter deployering, når en modell forlater repositoriet og blir et levende system.

Når en modell er deployet, er parametrene ikke lenger abstrakte artefakter. De er levende, minne-resident aktiva, kontinuerlig aksessert under inferens og ofte brukt av flere leietakere eller kunder gjennom delte AI-tjenester. Denne eksponeringen skjer før noen inferensforespørsel gjøres, og øker dermed risikoen ved å introdusere sensitive inndata og eksternt observerbar atferd.

Å behandle modellbeskyttelse som en pre-deployeringsbekymring og inferenssikkerhet som en runtime-bekymring, går glipp av poenget. I virkelige systemer, overlapper disse risikoene. Modeller og data er eksponert over initialisering, utføring og utdata. Sikkerhet som begynner og slutter med lagringskontroller, feiler i å addresere disse eksponeringene.

Hva NIST gjør riktig — og hvor det stopper

NISTs AI-risikostyringsrammeverk har blitt en hjørnestein for organisasjoner som prøver å håndtere AI-risiko. Dets struktur — styre, kartlegge, måle, håndtere — tilbyr en disiplinert måte å tenke om ansvar, kontekst, påvirkning og mitigasjon over hele AI-livssyklusen.

Hva NIST gjør spesielt bra, er å ramme inn AI-risiko som systemisk snarere enn tilfeldig. AI-feil er sjelden enkeltstående hendelser; de oppstår fra interaksjoner mellom modeller, data, mennesker og infrastruktur. Denne rammen er essensiell.

Hvor rammeverket kommer til kort, er i å ikke diktere hvordan høyverdi AI-aktiva beskyttes når systemer er live. Modellparametre behandles implisitt som design-tid artefakter snarere enn runtime-aktiva. Utføringsemiljøer antas å være tillitsverdige nok.

I praksis er modellparametre ofte det mest verdifulle immaterielle eiendom en organisasjon eier. De lastes inn i minne, kopieres over noder, cachas og gjenbrukes. Hvis AI-risikostyring ikke tar hensyn til konfidensialiteten av modeller under deployering og utføring, forblir en kritisk aktiv utenfor risikogrensen, som en sittende and.

ENISA og virkeligheten av AI-spesifikke trusler

ENISAs arbeid med AI-sikkerhet skyver samtalen videre. Dets flerskiktsrammeverk skille mellom tradisjonell infrastruktursikkerhet og AI-spesifikke risikoer, og anerkjenner at AI-systemer oppfører seg annerledes — og feiler annerledes — enn konvensjonell programvare.

Hvorfor er dette viktig? AI introduserer trusler som ikke passer inn i eksisterende kontroller: modell-ekstraksjon, parameter-lekkasje, co-tenancy-eksponering og manipulering under utføring. Disse risikoene krever ikke eksotiske angripere. De oppstår naturlig når høyverdi-modeller kjører i delte eller eksternt ledede miljøer.

ENISAs rammeverk anerkjenner implisitt at å sikre AI betyr å sikre atferd, ikke bare kode. Men som de fleste standarder, fokuserer det på hva som bør vurdernes, ikke hvordan beskyttelser teknisk gjennomføres når modeller kjører.

OWASP og kostnaden av observerbar intelligens

OWASPs topp 10 for store språkmodell-applikasjoner tilbyr en mer konkrete visning av hvordan AI-systemer bryter sammen i den virkelige verden. Prompt-injeksjon, sensitive informasjonsavsløring, innlegg-lekkasje, eksessiv utgangstransparens — disse er ikke teoretiske bekymringer. De er biprodukter av å deploye kraftfulle modeller uten å begrense hva de avslører.

Selv om disse problemene ofte rammes inn som applikasjonslagsproblemer, er konsekvensene dypere. Gjentakende eksponering av modellatferd kan føre til effektiv kloning; dårlig isolerte innlegg kan avsløre struktur; og inferensmisbruk blir en vei til modell-replikasjon.

OWASPs taksonomi gjør ett punkt klart: å beskytte AI er ikke bare å stoppe dårlige inndata. Det handler om å begrense hva modeller avslører — internt og eksternt — når de er operative.

En felles konklusjon, en ufullstendig jobb

Over NIST, ENISA og OWASP, er det en bred enighet om grunnleggende punkter:

  • AI-risiko omfatter hele livssyklusen
  • AI-systemer introduserer nye truslekategorier
  • Modeller og data er høyverdi-aktiva
  • Runtime-eksponering er uunngåelig

Hva disse rammeverkene mangler, er imidlertid en mekanisme for å håndheve konfidensialitet når modeller er deployet og beregning begynner. Denne utelatenheten er ikke en feil, da standarder definerer intensjon og omfang. Implementering er vanligvis overlatt til systemdesigneren.

Men de etterlater en kritisk gap — ett som vokser bredere når AI-systemer skalerer.

Kryptering-i-bruk endrer ligningen

Kryptering-i-bruk skifter sikkerhetsmodellen. I stedet for å anta at data og modeller må eksponeres for å være nyttige, behandler det beregning som noe som kan beskyttes.

I praktiske termer betyr dette:

  • Modeller forblir kryptert under deployering, initialisering og utføring
  • Inndata er aldri synlige i klartekst for utføringsemiljøet
  • Mellomliggende tilstander kan ikke inspiseres eller modifiseres
  • Infrastruktur trenger ikke lenger å være implisitt tillitsverdig

Dette erstatter ikke styringsrammeverk eller applikasjonslagskontroller — det operasjonelle dem. Det omgjør risikoprinsipper til håndhevelige garantier rett når AI-systemer er mest sårbare.

Med andre ord, er kryptering-i-bruk det manglende laget mellom AI-politikk og AI-reality.

Når styring slutter og utføring begynner: Sikring av AI-beregning

AI-sikkerhet bryter sammen på runtime. Når en modell er deployet, må AI-modeller og sensitive data eksponeres i minne for å fungere, og skaper en risikoflate som tradisjonelle kontroller — kryptering ved ro, kryptering under overføring og styringsrammeverk — aldri var designet for å beskytte.

Standardiseringsorganer som NIST, ENISA og OWASP har gjort kritisk fremgang i å definere AI-risiko, ansvar og misbruk. Men deres veiledning behandler hovedsakelig modeller som design-tid artefakter og antar at utføringsemiljøer kan tillites. I praksis er modellparametre og sensitive inndata kontinuerlig aksessert, gjenbrukt og ofte prosessert i delte eller eksternt ledede miljøer.

Å lukke denne gapet krever å omdefinere AI-sikkerhet ikke som en compliance-øvelse, men som et problem med å beskytte beregning selv — når modeller er live, data er i bruk og eksponering er uunngåelig. Kryptering-i-bruk tilbyr en viable måte å holde AI-modeller og sensitive inndata sikre over hele AI-livssyklusen.

Luigi Caramico, en veteran i bransjen for datavern, har vært i forkant av innovasjon innen cybersikkerhet i over to tiår. Som medgründer og teknisk direktør i DataKrypto, er Caramico en pionér innen en ny æra av datasikkerhet med fullt homomorf kryptering (FHE) som lover å revolusjonere hvordan organisasjoner beskytter sine mest sensitive opplysninger i en tid med kunstig intelligens.

Med en karriere som spenner over flere vellykkede prosjekter innen dataanalyse og -beskyttelse, har Caramicos reise fra etisk hacker til krypteringsinnovator vært drevet av en enkelt visjon: å skape en verden hvor data forblir sikker fra opprettelse til bruk, også under beregning.