Å overvinne tanken om at «KI er magi»: Derfor må det være en prioritet for hele virksomheten å lære hvordan KI-modeller fungerer

Mens advarslene om KI-agenter som løper løpsk tiltar, ga en utvikler nylig en kodeagent frie tøyler på en maskin uten ekstern sikkerhetskopi. Den slettet 48 000 filer på under to minutter.

Slike hendelser minner oss på en brutal måte om at det innebærer risiko å ta i bruk KI-agenter. Det er ikke nok å sette inn en menneskelig kontrollør et sted i en kompleks prosess og anta at den er sikker. Noen prosesser trenger ingen inngripen, mens andre krever langt strengere kontroller. Å rette en skrivefeil og å slette tusenvis av filer innebærer åpenbart ikke samme risikonivå, så oppfølgingen må stå i forhold til det som faktisk står på spill.

Organisasjoner må bli flinkere til å identifisere når menneskelig skjønn faktisk er viktig, særlig når en handling har store konsekvenser eller er vanskelig å gjøre om. Og når agenter gjør feil, må omgivelsene begrense skadeomfanget.

KI er ikke deterministisk, men probabilistisk

Først og fremst er det avgjørende at alle ansatte som direkte eller indirekte arbeider med programvareutvikling, får en grunnleggende forståelse av hvordan KI-modeller behandler informasjon. Dette er ingen liten oppgave: Det krever en målrettet innsats for å lære opp teamene, og etter hvert bør det bli et mål for hele virksomheten.

Når man begynner å bruke KI, føles det som magi. Man skriver inn en setning, og plutselig fører man en samtale. En grunnleggende forståelse av hvordan modeller og trening faktisk fungerer i bakgrunnen, er viktig når man skal utforme retningslinjer for KI i hele virksomheten, både med hensyn til sikkerhet og produktivitet. Nevrale nettverk, tokenisering og den statistiske analysen som ligger bak, og hvordan dette fører til resultater, gir en viktig læringsmulighet for alle ansatte i virksomheten.

Store språkmodeller kommer aldri til å gi deterministiske resultater. Resultatet er probabilistisk. Med vanlig programvare har man visse forventninger til hva resultatet kan bli når man gir den en inndata, for eksempel A, B eller C. Med KI kan man derimot få F, et & eller en beskrivelse av en katt med solbriller.

Når noe er probabilistisk, kan man ikke teste det på vanlig måte. Man trenger en måte å teste på som gjør det mulig å justere, resonnere, forstå og raskt hente inn kontekst, slik at man kan fange opp de probabilistiske elementene og oppdage problemene de kan føre til. Avhengig av omfanget og risikoen kan denne typen testing håndteres av KI eller av et menneske med relevant kompetanse. Det er mest nyttig å ha et menneske med i prosessen helt fra starten, slik at man kan definere problemet som skal løses, og deretter gjennomgå resultatet til slutt.

Siden utviklerne er nærmest til å observere variablene og den vanlige praksisen for hvordan organisasjonens interne KI utleder svar fra inndata, er de godt egnet til å bidra til opplæring i KI i virksomheten og sørge for at alle forstår forskjellen mellom determinisme og probabilisme i KI, og hvorfor den er viktig. Målet er å redusere forestillingen om at det å bruke KI er som magi, og at man er fornøyd med hvilket som helst resultat man får. I stedet bør organisasjoner arbeide for å avmystifisere modellene virksomheten bruker og forklare hvordan de brukes, hvilke problemer som kan oppstå, hvordan de kontrolleres, og hvilke resultater denne prosessen gir.

Sikkerhetsmekanismene hører hjemme i infrastrukturen, ikke i modellen

Når «magien» ved KI er avmystifisert og et KI-drevet prosjekt er i gang, er det avgjørende å ha en transparent revisjonspolicy på plass for å sikre at alt følger den forventede kursen. Da kan den ansvarlige, hvis prosjektet gir et «dårlig» resultat eller et resultat som ikke holder mål, gå gjennom trinnene som er fulgt, og hindre at problemet oppstår igjen. Dette er også nyttig når resultatene er bedre enn forventet, fordi de samme trinnene da kan gjentas og deles med andre prosjekter eller grupper.

Det er særlig viktig å systematisere denne prosessen i større selskaper, der hvert team kan ha dusinvis av utviklere, og hundrevis av utviklere kan være innom kode i løpet av dagen. KI kan gjøre mange ting svært raskt, og hvis noe går galt, må det finnes et system for å fastslå nøyaktig på hvilket trinn problemet oppsto. Se på OpenAIs agenter som i sommer trengte inn i Hugging Face. OpenAI testet hvor godt modellene kunne utnytte sårbarheter i programvare, ved hjelp av en referansetest kalt ExploitGym. I testen lempet selskapet bevisst på modellenes avvisninger av offensive cyberaktiviteter. Den eneste veien ut av sandkassen gikk gjennom en pakkemellomtjener. Modellene fant en ukjent feil i denne mellomtjeneren, kom seg ut og tilbrakte mer enn to dager i Hugging Faces produksjonssystemer på jakt etter testsvarene.

Overskriftene kalte det KI på avveie. Jeg vil heller kalle det et deterministisk oppsett rundt et probabilistisk system. OpenAI ba modellene om å hacke, og stolte deretter på at de holdt seg til den forventede kursen. Skaperen av referansetesten sier at modeller hadde jukset på testen før, men alltid innenfor sandkassen. Denne gangen gjorde én av dem ikke det. Vanlige sikkerhetsmekanismer forutsetter vanlig atferd, men KI trenger ikke å følge normene.

Derfor handler KI-sikkerhet om tilgang og kontrollmekanismer som håndheves av miljøet, ikke om at modellen oppfører seg slik den skal. Gå ut fra at agenten vil prøve alle dører, og la bare dørene den trenger, stå åpne. Agenten som slettet 48 000 filer, hadde fått beskjed om å arbeide på kopier og la originalene være i fred. Likevel slettet den originalene. Instruksjoner er ikke kontrollmekanismer.

Å administrere agenters tilgangsrettigheter er som å ta imot en ny juniorutvikler. Du ville ikke gitt vedkommende root-tilgang til produksjonsmiljøet den første dagen. Hvis du gjorde det, og vedkommende slettet databasen din, ville du ikke forklart det med at hen var en genial hacker. Ved sikkerhetshendelser av ethvert omfang er det avgjørende å finne grunnårsaken. Er det modellen? Er det selskapet som laget modellen? Er det selskapet som ga modellen tilgang? Uansett hva årsaken er, er et menneske til syvende og sist ansvarlig.

Til slutt er et viktig spørsmål vi må ta tak i nå, hva som skjer i det skjulte på en utviklers bærbare datamaskin. Tidligere var det enklere å spore arbeidsflyten. Utviklerne skrev kode, gjennomgikk den og satte den i produksjon, så det var en tydelig vei tilbake til tidspunktet da noe gikk galt. Nå kan en utvikler ha gitt en agent oppgavebeskrivelsen og sagt: «Fiks dette.» Hvis arbeidet foregår uten innsyn, finnes det ingenting å spore. Hvert trinn må dokumenteres fullstendig: hvilken agent som kjørte, hvilken modell den brukte, hvilke ledetekster den fikk, hvilke verktøy den brukte, og hvilke tillatelser den hadde på det tidspunktet. Å kjøre agenter sentralt i stedet for på hver enkelt utviklers bærbare datamaskin er én måte å få til dette på. Det viktigste er at sporet finnes.

Når alt kommer til alt, må alle selskaper beskytte seg selv hvis det skjer en hendelse. Sporet bør inneholde nok informasjon til å gjennomføre en rotårsaksanalyse og finne fram til trinnet og koden som forårsaket problemet.

KI har endret verden enormt, og forretningsprosessene må følge med. For å fastsette passende sikkerhetsrammer må man ha bedre forståelse av KI-prosessene, testingen, gjennomgangssyklusene og revisjonssyklusene – både i utviklingsteamene og i hele selskapet.