Att komma bort från föreställningen att ”AI är magi”: därför måste kunskap om hur AI-modeller fungerar vara en prioritering för hela företaget

Efter varningar om AI-agenter som löper amok gav en utvecklare nyligen en kodningsagent fria händer på en dator utan fjärrsäkerhetskopiering. Den raderade 48 000 filer på mindre än två minuter.

Händelser som denna påminner med all önskvärd tydlighet om att det innebär risker att införa AI-agenter. Det räcker inte att lägga in en mänsklig granskare någonstans i en komplex process och anta att den är säker. Vissa processer kräver ingen mänsklig inblandning, medan andra behöver betydligt kraftigare kontroller. Att rätta ett stavfel och att radera tusentals filer innebär uppenbart inte samma risknivå, så tillsynen måste anpassas efter vad som faktiskt står på spel.

Organisationer måste bli bättre på att identifiera när mänskligt omdöme verkligen behövs, särskilt när en åtgärd får stora konsekvenser eller är svår att återkalla. Och när agenter gör misstag måste miljön begränsa skadeverkningarna.

AI är inte deterministisk, utan probabilistisk

Framför allt är det avgörande att alla medarbetare som direkt eller indirekt arbetar med programvaruutveckling får grundläggande kunskaper om hur AI-modeller behandlar information. Det är ingen liten uppgift. Den kräver att man satsar på att utbilda teamen och bör så småningom bli ett mål för hela företaget.

När man börjar använda AI känns det som magi. Man skriver en mening och plötsligt för man ett samtal. Grundläggande kunskaper om hur modeller och träning faktiskt fungerar bakom kulisserna är viktiga när företagsövergripande riktlinjer för AI ska utformas med avseende på säkerhet och produktivitet. Det är viktigt att utbilda alla medarbetare i verksamheten om neurala nätverk, tokenisering och den bakomliggande statistiska analysen, samt om hur den leder till resultat.

Stora språkmodeller kommer aldrig att ge deterministiska resultat. Resultaten är probabilistiska. Med vanlig programvara har man vissa förväntningar på vad resultatet kan bli när man matar in något, till exempel A, B eller C. Men med AI kan man få F, ett & eller en beskrivning av en katt med solglasögon.

När något är probabilistiskt går det inte att testa på vanligt sätt. Det behövs en testmetod som gör det möjligt att snabbt justera, resonera, förstå och hämta in sammanhang, så att man kan upptäcka de probabilistiska inslagen och identifiera problemen de kan orsaka. Beroende på omfattningen och risken kan den här typen av testning skötas antingen av AI eller av en människa med relevant sakkunskap. Det är mest användbart att ha en människa med i processen redan från början, så att man kan ringa in problemet som ska lösas och sedan granska resultatet i slutet.

Eftersom utvecklarna har bäst insyn i variablerna och de vanliga arbetssätten som påverkar hur organisationens interna AI tar fram svar utifrån indata, har de goda förutsättningar att bidra till AI-utbildningen inom företaget och se till att alla förstår skillnaden mellan determinism och probabilism inom AI och varför den spelar roll. Målet är att minska föreställningen att AI-användning är som magi och att man blir nöjd med vilket resultat som helst. I stället bör organisationer arbeta för att avmystifiera modellerna som verksamheten använder och tydliggöra hur de används, vilka problem som kan uppstå, hur de kontrolleras och vilka resultat processen ger.

Skyddsräcken hör hemma i infrastrukturen, inte i modellen

När myten om AI:s ”magi” väl har avlivats och ett AI-drivet projekt har kommit i gång är det viktigt att ha tydliga riktlinjer för granskning, så att allt följer den förväntade utvecklingen. Om projektet leder till resultat som är ”dåliga” eller inte håller måttet kan den ansvariga då granska de genomförda stegen och förhindra att problemet uppstår igen. Det är också värdefullt när resultaten blir bättre än väntat, eftersom stegen då kan upprepas och delas med andra projekt eller grupper.

Att systematisera processen är särskilt viktigt i större företag, där varje team kan ha dussintals utvecklare och hundratals utvecklare arbetar med kod under dagens lopp. AI kan göra många saker mycket snabbt, och om något går fel måste det finnas ett system för att fastställa exakt i vilket steg problemet uppstod. Se på OpenAI:s agenter som i somras bröt sig in hos Hugging Face. OpenAI testade hur väl modellerna kunde utnyttja sårbarheter i programvara med hjälp av ett riktmärke kallat ExploitGym. Inför testet lättade man avsiktligt på modellernas vägran att utföra offensiva cyberoperationer. Den enda vägen ut ur sandlådan gick via en paketproxy. Modellerna hittade ett okänt fel i proxyn, tog sig ut och tillbringade mer än två dagar i Hugging Faces produktionssystem med att leta efter testsvaren.

Rubrikerna kallade det en AI på vift. Jag skulle kalla det en deterministisk uppsättning kring ett probabilistiskt system. OpenAI bad modellerna att hacka och förlitade sig sedan på att de skulle hålla sig till den förväntade vägen. Den som skapade riktmärket säger att modeller hade fuskat på testet tidigare, men alltid inne i sandlådan. Den här gången gjorde en av dem inte det. Vanliga skyddsräcken förutsätter ett standardmässigt beteende, men AI behöver inte följa några standarder.

AI-säkerhet handlar därför i grunden om åtkomst och kontroller, som upprätthålls av miljön snarare än av att modellen beter sig väl. Utgå från att agenten kommer att prova varje dörr, och lämna bara de dörrar öppna som den behöver. Agenten som raderade 48 000 filer hade fått instruktioner att arbeta med kopior och låta originalen vara. Ändå raderade den originalen. Instruktioner är inte kontroller.

Att hantera agenters behörigheter är som att introducera en ny juniorutvecklare på jobbet. Du skulle inte ge hen root-åtkomst till produktionsmiljön första dagen. Om du gjorde det och hen raderade din databas skulle du inte skylla på att hen var ett hacker-geni. Vid säkerhetsincidenter av alla omfattningar är det helt nödvändigt att fastställa grundorsaken. Är det modellen? Är det företaget som skapade modellen? Är det företaget som gav modellen åtkomst? Oavsett vilket är det i slutänden en människa som bär ansvaret.

Slutligen är en viktig fråga att ta itu med i dag vad som sker i det fördolda på en utvecklares bärbara dator. Tidigare var arbetsflödet enklare att spåra. Utvecklare skrev kod, granskade den och levererade den, så det fanns en tydlig väg tillbaka till ögonblicket då något gick fel. Nu kan en utvecklare ha gett en agent ett ärende och sagt: ”Fixa det här.” Om arbetet sker utom insyn finns det inget att spåra. Varje steg måste lämna ett fullständigt spår: vilken agent som kördes, vilken modell den använde, vilka promptar den fick, vilka verktyg den anropade och vilka behörigheter den hade vid tillfället. Att köra agenter centralt i stället för på enskilda bärbara datorer är ett sätt att åstadkomma detta. Det viktiga är att spåret finns.

När allt kommer omkring behöver varje företag skydda sig om en incident inträffar. Spåret bör innehålla tillräckligt med information för att genomföra en grundorsaksanalys och hitta det steg och den kod som orsakade problemet.

AI har förändrat världen i grunden, och affärsprocesserna måste följa med. För att fastställa lämpliga skyddsräcken behövs en bättre förståelse för AI-processerna, testningen, granskningscyklerna och revisionscyklerna – både inom utvecklingsteamen och i hela företaget.