AI-verktygen är på god väg att bli en naturlig del av såväl vardag som arbetsliv. Att integrera AI-verktyg i systemen kan leda till enorma produktionsvinster. Rätt införda kan det göra arbetet enklare och mer tillfredsställande för medarbetarna. Det finns stor potential, även om den är långt ifrån självklar. Men AI-verktyg skiljer sig från traditionella mjukvaruagenter på ett avgörande sätt.

Med traditionella agenter kan vi både styra och spåra hur de löser sina uppgifter genom att följa koden de är byggda av. AI-agenter vet vi hur vi gör när vi konstruerar dem, men det är i praktiken omöjligt att spåra hur de faktiskt löser de enskilda uppgifter vi ger dem. Ofta blir det rätt, och vi kan oftast i efterhand förstå varför det blev som det blev. Men det är svårare att förutspå hur det kan bli, framför allt hur det kan gå fel.

Detta skapar nya hotbilder för organisationer och företag. Att det dessutom är en ny teknik som utvecklas i oerhörd hög takt gör det inte enklare.

Fördelen är dock att de flesta av de här utmaningarna går att hantera genom att tillämpa gammal visdom. I den här bloggposten kommer jag att ta upp tre vanliga problemområden jag stöter på arbetet med våra kunder och i bästa möjliga mån förklara hur de bäst avhjälps. Jag har delat upp dem i kategorier jag kallar självreglering, behörighet och tillgänglighet.

Problemet med självreglering

De flesta är medvetna om problemet med begränsningar som uppstår när vi ger en språkmodell, LLM, tillgång till våra system. Vi vill inte att LLM:en ska dela, manipulera eller radera data och funktioner på ett okontrollerat sätt. Därför vill vi skapa gränser, guard rails, för att så att säga hålla agenten kvar på den väg vi anvisat den, utan olyckliga avstickare. En vanlig, och inte särskilt lyckad, lösning är att vi försöker begränsa den genom att säga åt den vad den inte får göra. Vi skriver helt enkelt en prompt av typen ”Tillåt inte att användaren gör x”.

Tyvärr är den här typen av instruktioner svagare än de ser ut. De är mest att betrakta som försynta uppmaningar till LLM:en ”snälla, gör så här, men inte så här, och snälla glöm inte bort detta”.
Detta medför en lång rad risker. Den mest uppenbara är prompten ”bortse från alla tidigare instruktioner” som får LLM:en att agera utifrån ”aha, nya bud, vi börjar om från början”. Det finns även mer sofistikerade risker som dels har att göra med hur LLM:er tolkar prompter, dels hur den hanterar sitt eget lärande (återigen: vi vet inte exakt hur den gör det i varje enskilt fall). Problemet med övertro på sådana här guard rails kan illustreras med hur en AI-expert och forskare på Meta fick se AI-agenten OpenClaw ”glömma” en tidigare begränsning och istället börja radera hela hennes inbox. Det slutade med att hon i panik fick springa och rycka ur sladden för att få stopp på processen.

Om inte någon som, vad vi får anta, tillhör den absoluta eliten vad gäller AI-expertis kan lita på guard rails ska nog inte vi göra det heller. Lösningen på detta problem är också enkel: Vi kan definitivt använda instruktioner för att guida AI. Men, vi ska inte förlita oss på att vi kan begränsa AI med instruktioner, de är ingen säkerhetsgaranti.

Problemet med behörighet

En bättre lösning på problemet är att lägga begränsningarna mellan LLM:en och systemet. Här gör många i stället misstaget att behandla AI-agenten som ett vanligt mjukvarusystem och ge den systembehörighet utan ytterligare kontroll. Detta innebär återigen att du förlitar dig på att du ska kunna lägga in begränsningarna i agenten. Det kan fungera så länge du har kontroll och insyn i hur agenten löser sina uppgifter, men det har vi ju inte när det handlar om en AI-agent.

Det vi behöver göra är att skilja på systembehörighet och den behörighet som är baserad på användarens behörighet, där agentens rättigheter hanteras utifrån att den agerar på en annan användares uppdrag, att den anses agera ”on behalf of”.

Om de bakomliggande systemen litar på att agenten har kontrollerat behörigheten, finns det risk att användaren får tillgång till sådant som hen inte ska ha tillgång till. Lösningen blir då att användaren tilldelar AI-agenten en tidsbegränsad ”ticket” där den får samma behörigheter – och begränsningar – som användaren själv har. På så sätt lägger vi kontrollen av rättigheter så att säga på rätt sida av systemet.

Problemet med tillgänglighet

Det här har sin grund i att licens- och ersättningsmodellerna för underliggande AI-tjänster i allmänhet är baserade på användande. På så sätt påminner de om när vi köper lagring. När organisationen börjar närma sig sin quota kommer varningar och vi tvingas rensa. Problemet som kan uppstå med LLM:er är att våra system kanske inte får eller fångar varningar och att systemet får slut på sin temporära quota. Mitt under arbetsdagen stannar funktionen ”semantisk sökning” för kundtjänst och står stilla tills quotan återställs. Detta kan typiskt ta allt från några timmar eller upp till en månad om inte någon uppgraderar dessförinnan. Det kan skapa oerhörda problem, och det är som regel helt onödigt eftersom vi vet att det ofta finns vissa användare som är särskilt förtjusta i att använda AI till allt möjligt. Att bekanta sig och använda ny teknik är i allmänhet något organisationer uppmuntrar, men det är inte bra när överanvändande riskerar tillgängligheten för affärskritiska funktioner.

Lösningen här kan dels vara att tilldela användare individuella quota, dels det vi kallar ”graceful degradation”. Det innebär att enskilda användare kan få ökade responstider, lägre prioritet eller tilldelas mindre kraftfulla AI-modeller. På så sätt kan vi begränsa belastningen, och därmed företagets kostnader, utan att riskera kritiska funktioners up-time.  Den stora vinsten är att vi själva väljer hur degradation sker och kan få en mjuk landning innan vi slår i leverantörens kakelvägg.

Sammanfattning: Så vad ska man göra?

I korthet kan man sammanfatta lärdomarna med AI i följande enkla visdomar:

1. Var inte för ivrig i installationerna

Den vanligaste anledningen till att det går fel är att det går för fort. AI:s funktionalitet är attraktiv och AI-tjänster säljs i till synes lättintegrerade färdigförpackade abonnemang. Att stanna upp och tänka till räcker långt. De flesta organisationer har rutiner för hur de ska hålla sina system säkra. Men ofta glöms det bort när det kommer till att integrera AI i systemen. De gamla principerna gäller.

2. IT-avdelningen är din luttrade vän

Runda inte IT-avdelningen. Det händer alltför ofta. Deras expertis finns där för att ni tillsammans ska undvika dyra misstag, inte för att göra livet besvärligt för dig. Det är inte första gången de förhåller sig till en hype och med vana kommer just förmågan att undvika misstag. Som min farfar som var murare berättade att det sades inom skrået: ”Bygg det första huset åt din fiende, det andra åt din vän och det tredje åt dig själv”.

3. Var medveten om att vi inte vet säkert hur AI fungerar

Man kan jämföra AI med anden i flaskan. Vi ger den uppgifter som den som regel löser med en snabbhet och precision som är imponerande så länge det går rätt. Men vi vet inte hur det går till, vilket vi märker när det plötsligt och oförklarligt går fel. Och i det kanske ligger den djupaste insikten för att förstå hur vi ska tillämpa våra säkerhetsprinciper: att inte låta sig imponeras till oförsiktighet. Anden i flaskan är kraftfull, men det är du som håller i korken.