Sikkerhetsrammer for KI i virksomheter kan være viktigere enn KI-fronten

Glem KI-fronten. Kundene krever at virksomheter innfører flere sikkerhetsmekanismer for KI som allerede er i bruk, og erfaringene med PCI DSS gir en nyttig modell.

KI-ens regulatoriske friperiode er over. Nylige avsløringer har ført til diskusjoner om å bremse utviklingen av de mest avanserte KI-modellene og innføre påbudte kontroller. Et av de få punktene det er enighet om, er at kontrollene bør ligge utenfor modellene og verifiseres uavhengig.

Det diskuteres hva som skjer videre, men tilsynsmyndighetene er allerede i gang. EUs KI-forordning innfører gradvis sikkerhetsforpliktelser, blant annet kjøperansvar. I USA tas NIST-rammeverket for risikohåndtering av KI i bruk som en standard for forsvarlig aktsomhet. Globalt har OWASP Top 10 for LLM-applikasjoner blitt en vanlig referanse i sikkerhetsgjennomganger, og ISO/IEC 42001-sertifisering dukker opp i anskaffelsesdokumenter.

Det betyr at modellutviklerne ikke er de eneste som kan holdes ansvarlige. Sikkerhetsforpliktelser og -risikoer gjelder også virksomheter som bruker modeller som allerede er lansert, særlig i høyrisikotilfeller. Feil svar i et sikkerhetsskjema fra en kunde eller i et tilbudssvar kan sette en B2B-avtale på vent.

PCI DSS viser vei

Heldigvis har vi sett denne filmen før. For tjue år siden var sikkerheten i webapplikasjoner stort sett basert på periodiske kodegjennomganger, statiske skanninger og utviklernes disiplin. Deretter krevde PCI DSS-krav 6.6, som ble innført i 2006 og håndhevet fra 2008, at organisasjoner som håndterte kortinnehaveropplysninger, enten gjennomgikk all applikasjonskode for å finne sårbarheter eller installerte automatiserte tekniske kontroller. Senere ble muligheten til å velge kodegjennomgang fjernet, og tekniske kontroller ble påkrevd.

PCI DSS startet imidlertid ikke som lovgivning. Det begynte som en kontraktsbasert standard som omformet markedet, sannsynligvis raskere enn lovgivning ville ha gjort, fordi kontrakter utvikles raskere enn offentlige lover.

På samme måte opplever organisasjoner nå press om å innføre sikkerhetsmekanismer for KI som er tatt i bruk, ikke fra tilsynsmyndigheter, men fra kunder og partnere – gjennom sikkerhetsskjemaer, krav i tilbudsforespørsler og krav i forsikringsvilkår.

Løs det operative problemet, så følger etterlevelsen

Det kan være vanskelig å håndtere dette presset, fordi KI-styring ikke bare handler om retningslinjer. Det handler også om løpende tekniske bevis.

Mange av virksomhetene jeg snakker med, kjører et halvt dusin eller flere modeller i produksjon. Ofte kobler de modellene sammen i kjeder eller orkestrerer dem, slik at resultatet fra én modell blir inndata til en annen. Tenk deg å skulle påvise at én bestemt regel håndheves på tvers av hele systemet – for eksempel at modellens utdata ikke inneholder personidentifiserende opplysninger (PII) – under slike forhold. Manuell gjennomgang av flere modeller med individuelle konfigurasjoner ville tatt mye av utviklernes tid. I tillegg sliter de fleste organisasjoner med uautorisert og høyrisiko KI-bruk, for eksempel når ansatte limer inn sensitive data i KI-verktøy for forbrukere, eller SaaS-leverandører i det stille aktiverer nye KI-funksjoner. Likevel ligger ansvaret fullt og helt hos virksomheten.

I slike krevende situasjoner kan kravene kokes ned til én enkel oppgave: Vis at dere kan begrense inndataene til og utdataene fra modeller kontinuerlig, samtidig som aktiviteten loggføres for verifisering. Når applikasjoner kaller modeller, agenter bruker verktøy, og modeller utfører handlinger eller utløser arbeidsflyter, er det handlingen som må kontrolleres – verktøykallet, API-forespørselen eller utløseren av arbeidsflyten.

Flytt sikkerheten til inferensbanen

Denne handlingen er håndhevingspunktet som eksperter på applikasjonssikkerhet har brukt 20 år på å bygge opp for applikasjonstrafikk. Særlig når inferensforespørsler går gjennom delt infrastruktur, blir inferensbanen det ideelle kontrollpunktet på tvers av modeller og også for uautorisert KI-bruk. KI-inferenstrafikk må leveres, inspiseres, autentiseres og styres på samme måte som annen viktig samhandling med applikasjoner, ut fra hvor trafikken kommer fra og hva den forsøker å gjøre. I motsetning til manuelle gjennomganger kan styring av inferenstrafikk skaleres.

Slik kommer du i gang

Med tanke på den regulatoriske utviklingen må organisasjoner begynne med tre ting nå:

1. Kartlegg ansvarsområdet deres, fra SaaS-API-er og driftede endepunkter til skygge-KI.
2. Skill sikkerhetspolicy og håndheving fra modellene, og legg dem inn i inferensbanen.
3. Sørg for at revisjonsspor genereres utenfor modellene og agentenes kontroll. Det er vist at de kan forsøke å endre logger over sine egne handlinger.

Hva som regnes som tilstrekkelig overvåking og håndheving, er fortsatt under avklaring. Men drifts- og sikkerhetsteamene i virksomheten vet hva som faktisk kan håndheves, hvor mye en kontroll koster i form av forsinkelse og kompleksitet, og hvor en velment regel kan gi feil resultat. Involver dem nå. Sikkerhetsrisikoene og forpliktelsene knyttet til bruk av KI er reelle, og kundene og lederne deres bryr seg utvilsomt mer om risikoene og forpliktelsene de står overfor i dag enn om truslene fra framtidens frontmodeller.