Styrning av AI-agenter innebär att sätta tekniska och organisatoriska ramar för vad en agent får göra: vilka behörigheter den har, hur dess handlingar loggas, när den måste lämna över till en människa och hur den stängs av. Ramarna behövs eftersom en agent, till skillnad från en assistent som föreslår text, utför uppgifter själv: den tar emot ett mål, bryter ner det i steg, hämtar den information som behövs och agerar i andra system, till exempel genom att boka, registrera, skicka eller uppdatera.
Skillnaden låter liten men är principiell. En assistent som formulerar ett dåligt utkast kostar en pinsam genomläsning. En agent som skickar fel mejl till fel kund har redan gjort det när någon upptäcker saken.
Vad kan gå fel, konkret?
OWASP, organisationen bakom de välkända topplistorna över säkerhetsrisker i webbapplikationer, publicerade i december 2025 sin första topplista över risker i agentiska AI-system. Den är framtagen tillsammans med över hundra experter, forskare och praktiker och hänvisar till dokumenterade verkliga incidenter. Där finns mönster som verktygsmissbruk, där agenten använder sina kopplingar på oavsedda sätt, missbruk av identitet och behörigheter, förgiftat minne och sammanhang som styr agentens framtida beteende, och kaskadfel där ett litet fel fortplantar sig genom en kedja av automatiska steg.
Uppräkningen är inget skäl att avstå från agenter, bara från agenter utan ramar.
En AI-agent i drift behöver fyra saker: minsta möjliga behörighet, loggning av varje handling, tydliga gränser för när människor tar över och en avstängning som fungerar direkt.
Princip 1: Minsta möjliga behörighet
En frestande genväg är att låta agenten arbeta med en anställds inloggning. Det fungerar direkt, och det är precis därför det är farligt: agenten ärver allt personen kommer åt, långt mer än uppgiften kräver, och dess handlingar blandas med människans i alla loggar. OWASP beskriver problemet under rubriken missbruk av identitet och behörigheter: utan en egen, styrd identitet går det inte att upprätthålla verklig minsta behörighet för en agent.
Ge agenten ett eget tjänstekonto i stället, med rättigheter enbart till de system uppgiften kräver, läsåtkomst som standard och skrivåtkomst punktvis. Det är samma logik som IT-avdelningen redan tillämpar på integrationer: åtkomsten avgör hur stor en incident kan bli. Hur agenten kopplas till affärssystemen beskrivs i integrera AI i befintliga system.
Princip 2: Logga allt agenten gör
Varje åtgärd agenten vidtar ska lämna spår: vad den gjorde, när, på vilket underlag och med vilket resultat. För en agent som hanterar fakturor eller order är det inget uttryckligt lagkrav, eftersom AI-förordningens loggkrav gäller system med hög risk, men driften kräver det. En agent som inte kan förklaras kan inte felsökas, och en agent som inte kan felsökas förlorar organisationens förtroende vid första konstiga utfall. OWASP skriver samma sak: utan insyn i vad agenter gör, varför de gör det och vilka verktyg de anropar kan små fel växa till fel i hela systemet.
Loggningen är också er försäkring den dag någon frågar varför ett beslut blev som det blev. Frågan kan komma från en kund, en revisor eller en tillsynsmyndighet, och "det vet vi inte" är ett svar som kostar mer än loggarna någonsin gjort.
Princip 3: Bestäm var människan tar över
Varje agent behöver en uttalad gräns mellan det den avgör själv och det den lämnar vidare: belopp över en nivå, ärenden med juridiska inslag, allt som avviker från de fall den prövats på. Gränsen ska sättas av verksamheten, inte av utvecklaren, och den ska vara snäv i början för att vidgas i takt med förtroendet. Någon i verksamheten behöver också äga agenten, följa upp den och flytta gränsen när regler eller sortiment ändras. Var gränserna går för ett visst flöde bestäms lämpligen i förstudien, som är första fasen i varje bygge och beskrivs under AI-förstudie.
En AI-agent bör få sitt körkort stegvis. Först kör agenten med handledare: varje åtgärd granskas av en människa innan den verkställs. Sedan får den köra själv på raksträckorna, alltså de ärendetyper där utfallet visat sig pålitligt, medan korsningarna fortfarande kräver mänskligt beslut. Statistiken från handledarfasen är beslutsunderlaget: när agenten föreslagit rätt åtgärd i, säg, hundra fall av hundra på en ärendetyp finns belägg för att släppa fram den där, och bara där. Samma statistik styr åt andra hållet: faller träffsäkerheten efter en systemuppdatering, en ny produktlinje eller ett ändrat regelverk, snävas gränsen in igen.
Ett tänkt exempel: en agent som matchar leverantörsfakturor mot order och avtal. I handledarfasen föreslår den bara, och en människa godkänner varje faktura. Visar loggarna att agenten matchar rätt på fakturor med fullständig order och avtalat pris, får den hantera just dem själv, medan avvikelser och fakturor utan order alltid går till en människa. Gränsen ses över vid varje genomgång av loggarna. Förtroende för en agent är inget man beslutar om, det är något loggarna får bevisa. Hur ett sådant flöde byggs beskrivs i automatisera processer med AI.
Princip 4: Avstängningen ska vara en knapp, inte ett projekt
Fråga er själva: om agenten börjar bete sig fel klockan sju en fredagskväll, vem stänger av den, och hur lång tid tar det? Om svaret innehåller orden "utvecklaren" eller "på måndag" är styrningen inte klar. Avstängning ska vara omedelbar, dokumenterad och möjlig för fler än en person: i praktiken att tjänstekontots åtkomst dras in på ett ställe. Det är också ett skäl att undvika agentlösningar som är så sammanvävda med era flöden att de inte går att pausa utan att verksamheten stannar. Resten av rutinen, från stopp till anmälan, hör till förvaltningen och beskrivs i AI-förvaltning.
Vad kräver reglerna, och vad är bara klokt?
Sedan 2 augusti 2026 gäller transparenskraven i artikel 50 i EU:s AI-förordning, bland annat att människor som interagerar direkt med ett AI-system ska informeras om det, om det inte är uppenbart. Per oktober 2026 tillämpas de tunga kraven på AI-system med hög risk, däribland loggning enligt artikel 12, från 2 december 2027 för system i bilaga III, som rekrytering och kreditprövning av privatpersoner. Datumet sköts fram av ändringsförordningen 2026/1744. En agent som matchar leverantörsfakturor eller sorterar kundärenden omfattas inte av högriskkraven, medan en agent som sållar bland jobbansökningar kan göra det. Regelöversikten finns i EU AI Act och GDPR.
Den som vill ha en struktur att luta sig mot kan titta på ISO/IEC 42001:2023, standarden för ledningssystem för AI, men en certifiering ersätter inte principerna ovan. Omfattas ert företag av cybersäkerhetslagen (2025:1506), som gäller sedan 15 januari 2026, ska säkerhetsåtgärderna enligt 2 kap. 3 § bland annat omfatta riskanalys, åtkomstkontroll och säkerhet i leveranskedjan, och en agent med åtkomst till era system hör hemma i den analysen. Kravet på leveranskedjan gör också att kunder som omfattas kan ställa motsvarande krav på er som leverantör.
Redo att släppa fram en agent, med ramarna på plats?
Byron Calles bygger agentlösningar med behörigheter, loggning och eskaleringsgränser som en del av bygget och inte som ett tillägg efteråt. Boka ett samtal om ni vill resonera kring ett konkret flöde, eller läs mer om hur en AI-lösning byggs upp.
Vanliga frågor
Hur länge ska en AI-agents loggar sparas?
Det finns inget enhetligt svar, men två regler sätter ramarna. För AI-system med hög risk ska tillhandahållaren, alltså företaget som använder systemet, enligt artikel 26.6 i AI-förordningen spara de automatiskt genererade loggarna i minst sex månader, om inte annan lag säger något annat. För system i bilaga III gäller det från 2 december 2027, per oktober 2026. Innehåller loggarna personuppgifter, vilket de gör så snart agenten hanterar ärenden med namn eller kontaktuppgifter, gäller GDPR:s princip om lagringsminimering: uppgifterna får inte sparas längre än ändamålet kräver. För en agent utan hög risk avgör alltså ändamålen, hur långt bak ni behöver kunna felsöka, följa upp och svara på frågor i efterhand. Bestäm gallringstiden innan agenten går i drift och skriv ner varför.
När är en AI-agent fel lösning?
När stegen är kända i förväg. Ett flöde som alltid går i samma ordning, som att hämta en order, kontrollera den mot lagret och registrera den, byggs billigare och säkrare som en vanlig integration eller ett regelstyrt flöde, där en språkmodell på sin höjd tolkar indata i ett enskilt steg. En agent behövs först när nästa steg beror på innehållet i varje ärende och inte går att skriva ner som regler. OWASP formulerar samma råd i sin topplista för agentiska system: undvik onödig autonomi, eftersom agentbeteende där det inte behövs ökar attackytan utan att tillföra värde. Ett regelstyrt flöde är dessutom lättare att testa, eftersom samma indata ger samma resultat.
