Sådan overvinder man tanken om, at »AI er magi«: Derfor skal det være en fælles prioritet i hele virksomheden at lære, hvordan AI-modeller fungerer

Midt i advarslerne om AI-agenter, der går amok, gav en udvikler for nylig en kodningsagent frie hænder på en maskine uden fjernbackup. Den slettede 48.000 filer på under to minutter.

Hændelser som denne er en tydelig påmindelse om, at det indebærer risici at implementere AI-agenter. Det er ikke nok at sætte et menneske til at kontrollere arbejdet et sted i en kompleks proces og antage, at det er sikkert. Nogle processer kræver ingen indgriben, mens andre kræver langt grundigere kontrol. Det er tydeligvis ikke lige risikabelt at rette en slåfejl og at slette tusindvis af filer, så tilsynet skal afspejle, hvad der reelt står på spil.

Organisationer skal blive bedre til at identificere de situationer, hvor menneskelig dømmekraft virkelig er vigtig, især når en handling har stor betydning eller er vanskelig at omgøre. Og når agenter begår fejl, skal omgivelserne begrænse skadeomfanget.

AI er ikke deterministisk, men probabilistisk

Først og fremmest er det afgørende, at alle medarbejdere, der direkte eller indirekte arbejder med softwareudvikling, får en grundlæggende forståelse af, hvordan AI-modeller behandler information. Det er en omfattende opgave, som kræver, at man prioriterer at uddanne teams, og på sigt bør det blive et mål for hele virksomheden.

Når man begynder at interagere med AI, føles det som magi. Man skriver en sætning, og pludselig er man i gang med en samtale. En grundlæggende forståelse af, hvordan modeller og træning faktisk fungerer bag kulisserne, er vigtig, når virksomheden skal fastlægge en fælles AI-politik for sikkerhed og produktivitet. Det neurale netværk, tokeniseringen og den statistiske analyse, der foregår bag kulisserne, samt hvordan den fører til output, er et vigtigt læringsemne for alle medarbejdere i virksomheden.

Store sprogmodeller vil aldrig give deterministiske resultater. Outputtet er probabilistisk. Når man bruger almindelig software, har man nogle forventninger til, hvad resultatet kan være, for eksempel A, B eller C. Men med AI kan man få F, et & eller en beskrivelse af en kat med solbriller på.

Når noget er probabilistisk, kan man ikke teste det på sædvanlig vis. Man har brug for en testmetode, der gør det muligt hurtigt at justere, ræsonnere, forstå og hente kontekst, så man kan fange de probabilistiske elementer og opdage de problemer, de kan skabe. Afhængigt af omfanget og risikoen kan denne type test enten håndteres af AI eller af et menneske med relevant ekspertise. Det er mest nyttigt at inddrage et menneske helt fra begyndelsen, så man kan fastlægge den problemstilling, der skal løses, og derefter gennemgå resultatet til sidst.

Da udviklerne er bedst placeret til at observere de variable og gængse arbejdsgange, der præger, hvordan organisationens interne AI udleder svar af input, kan de være med til at forme AI-undervisningen i deres virksomheder og sikre, at alle forstår forskellen mellem determinisme og probabilisme i AI, og hvorfor den er vigtig. Målet er at mindske forestillingen om, at det at bruge AI er som magi, hvor man bare er tilfreds med det output, man får. I stedet bør organisationer arbejde på at afmystificere og synliggøre de modeller, virksomheden bruger, hvordan de bruges, hvilke problemer der kan opstå, hvordan de kontrolleres, og hvilke resultater denne proces giver.

Sikkerhedsforanstaltninger hører hjemme i infrastrukturen, ikke i modellen

Når man først har aflivet myten om AI’s »magi«, og et AI-drevet projekt er sat i gang, er det afgørende at have en gennemsigtig politik for revision på plads, så man sikrer, at alt følger det forventede forløb. På den måde kan den ansvarlige, hvis projektet resulterer i et »dårligt« eller utilstrækkeligt output, gennemgå de udførte trin og forhindre, at problemet opstår igen. Det er også en fordel, hvis resultaterne er bedre end forventet, fordi trinnene så kan gentages og deles med andre projekter eller grupper.

Det er særligt vigtigt at systematisere denne proces i større virksomheder, hvor hvert team kan have snesevis af udviklere, og hundredvis af udviklere arbejder med kode i løbet af dagen. AI kan gøre mange ting meget hurtigt, og hvis noget går galt, skal der være et system til at fastslå præcis, på hvilket trin problemet opstod. Se blot OpenAI’s agenter, der trængte ind hos Hugging Face i sommer. OpenAI testede, hvor godt modellerne kunne udnytte softwaresårbarheder, ved hjælp af et benchmark kaldet ExploitGym. Til testen lempede OpenAI bevidst på modellernes afvisninger af offensivt cyberarbejde. Den eneste vej ud af sandkassen gik gennem en pakkeproxy. Modellerne fandt en ukendt fejl i denne proxy, slap ud og tilbragte mere end to dage i Hugging Faces produktionssystemer på at lede efter testens svar.

Overskrifterne kaldte det en AI, der var gået amok. Jeg vil kalde det en deterministisk opsætning omkring et probabilistisk system. OpenAI bad modellerne om at hacke og stolede derefter på, at de ville holde sig på den forventede kurs. Benchmarkets skaber siger, at modeller tidligere havde snydt i testen, men altid inde i sandkassen. Denne gang blev én af dem ikke dér. Almindelige sikkerhedsforanstaltninger forudsætter almindelig adfærd, men AI behøver ikke følge almindelige normer.

Derfor handler AI-sikkerhed om adgang og kontroller, som håndhæves af omgivelserne i stedet for at afhænge af, at modellen opfører sig ordentligt. Gå ud fra, at agenten vil prøve alle døre, og lad kun dem stå åbne, som den har brug for. Agenten, der slettede 48.000 filer, havde fået besked på at arbejde med kopier og lade originalerne være. Alligevel slettede den originalerne. Instruktioner er ikke kontroller.

At administrere en agents tilladelser svarer til at tage imod en ny juniorudvikler. Du ville ikke give vedkommende root-adgang til produktionsmiljøet på dag ét. Hvis du gjorde det, og vedkommende slettede din database, ville du ikke forklare det med, at personen var en genial hacker. Ved sikkerhedshændelser af enhver størrelse er det afgørende at finde frem til grundårsagen. Er det modellen? Er det virksomheden, der skabte modellen? Er det virksomheden, der gav modellen adgang? Uanset hvad årsagen er, er et menneske i sidste ende ansvarligt.

Endelig er et centralt problem, der skal tackles i dag, det, der foregår i det skjulte på en udviklers bærbare computer. Tidligere var det lettere at spore arbejdsgangen. Udviklerne skrev kode, gennemgik den og sendte den ud, så der var en tydelig vej tilbage til det tidspunkt, hvor noget gik galt. Nu kan en udvikler have givet en agent opgaven og sagt: »Ret det her.« Hvis arbejdet foregår uden for syne, er der intet at spore. Hvert trin skal kunne følges fuldt ud: hvilken agent der blev kørt, hvilken model den brugte, hvilke prompts den fik, hvilke værktøjer den kaldte på, og hvilke tilladelser den havde på det tidspunkt. En måde at opnå det på er at køre agenter centralt i stedet for på individuelle bærbare computere. Det afgørende er, at der findes et fuldstændigt spor.

Når alt kommer til alt, skal enhver virksomhed beskytte sig selv, hvis der sker en hændelse. Sporet skal indeholde nok oplysninger til at analysere grundårsagen og finde det trin og den kode, der forårsagede problemet.

AI har ændret verden markant, og forretningsprocesserne skal følge med. For at finde frem til de rette sikkerhedsforanstaltninger er det nødvendigt at få en bedre forståelse af AI-processerne, testningen, gennemgangscyklusserne og revisionscyklusserne – både i udviklingsteams og på tværs af hele virksomheden.