Veljko Radan

Språk: SVEnglish

← Alla artiklar

AI-agenter i drift

Jag bygger verktyg med AI-agenter varje vecka. Kompetensen ligger inte i att låta dem skriva, utan i att kravställa, begränsa och verifiera.

Veljko Radan · · 7 min läsning

Jag skriver inte kod för hand. Ändå har jag de senaste åren byggt verktyg som används i skarpt arbete: rapportkedjor, kapacitetsrapporter, automatisering av dokumentation och den här webbplatsen. Det har jag gjort med AI-kodagenter, som arbetar direkt i en terminal, läser filer, kör kommandon och skriver kod.

Det är lätt att tro att kompetensen då ligger hos AI:n. Det gör den inte. En agent skriver snabbt och självsäkert, och den har fel tillräckligt ofta för att det spelar roll. Kompetensen ligger i att veta vad som ska byggas, begränsa vad agenten får göra och kontrollera allt som kommer ut. Det är samma disciplin som i drift.

Kravställ som om det vore en leverantör

Den som har beställt något av en leverantör vet att ett vagt krav ger ett vagt resultat. Med en agent är det likadant, bara snabbare. Jag skriver vad som ska göras, vad som inte ska göras, vilka fakta som gäller och hur resultatet ska kontrolleras. Ju tydligare kravet är, desto mindre behöver jag rätta i efterhand.

Verifiering är en grind, inte ett förslag

Inget levereras utan kontroll. I praktiken betyder det:

  • Automatiska kontroller före leverans. En validator som går igenom resultatet och stoppar bygget vid fel, i stället för att lita på att det ser rätt ut.
  • Varje siffra spårbar till sin källa. En rapport byggs från data via ett mellanled med fasta nycklar. En felstavad nyckel stoppar bygget, i stället för att ge en tom ruta i en presentation för ledningen.
  • Jag läser det som kommer ut. Det låter självklart, men det är där felen hittas. En siffra som är rätt i analysen men fel i texten. En formulering som säger mer än underlaget.

Ett minne som överlever sessionen

En AI-agent glömmer allt när sessionen tar slut. Därför ligger projektkunskapen i versionshanterade filer som agenten läser i början av varje session: vad projektet är, vad som är beslutat, vad som är öppet och hur vi arbetar. Ett beslut skrivs in där det hör hemma direkt, och det som motsägs ändras i stället för att kompletteras. Det är samma sak som god driftdokumentation, och det gör att arbetet går att ta upp igen efter en vecka utan att börja om.

Prompt injection är ett säkerhetsproblem, inte en kuriositet

En agent som läser webbsidor, dokument och utdata från kommandon kan luras av text som ser ut som instruktioner. Det kallas prompt injection, och det är ett verkligt hot när agenten har tillgång till ett skal och kan skicka data vidare. Jag behandlar det som vilken annan säkerhetsrisk som helst:

  • Minsta behörighet. Agenten får inte läsa hemligheter, och den har inte tillgång till nycklar som den inte behöver.
  • Uttryckliga regler i konfigurationen, inte bara i instruktionerna: vissa kommandon är förbjudna, andra kräver att jag godkänner dem.
  • Granskningslogg över vad agenten har kört.
  • Extern text är data, aldrig instruktioner. Om något i en fil eller på en webbsida försöker styra agenten ska det citeras och lyftas till mig, inte utföras.

Det är samma tänkande som i OT: anta att något kommer att försöka ta sig in, och bygg så att skadan blir begränsad när det händer.

Beroendet är verkligt – och hanteras

Ett verktyg som är byggt med AI kan vara svårt att felsöka utan AI. Det ska man vara ärlig med. Jag motverkar det med dokumentation och körbara instruktioner, så att verktygen går att förvalta av någon annan än mig. Ett verktyg som bara en person förstår är en risk, oavsett hur det är byggt.

Kort sagt

  • Kravställ tydligt: vad, vad inte, vilka fakta, hur det ska kontrolleras.
  • Gör verifiering till en grind som stoppar leveransen.
  • Lägg projektets minne i filer, inte i en chatt.
  • Behandla prompt injection som en säkerhetsrisk med tekniska skydd.
  • Dokumentera så att någon annan kan ta över.