En AI-agent er en funktion, hvor en sprogmodel selv vælger skridt og udfører handlinger, for eksempel opdaterer en post, sender en besked eller kalder et andet system. Det ændrer risikoen, for et forkert svar kan læses og ignoreres, mens en forkert handling er sket. Tre beslutninger bærer sikkerheden: hvad agenten må røre, hvordan hver handling logges, og hvilke handlinger der kræver et menneskes godkendelse. Alle tre skal håndhæves i almindelig kode uden for modellen.
Ordet bruges løst. Nogle kalder enhver chat for en agent. Her menes en funktion, der kan ændre noget i verden. Har I kun brug for, at funktionen læser og svarer, er de tekniske valg før I bygger det rette sted at starte. Mange opgaver kan løses med et fast forløb, hvor modellen hjælper i enkelte trin, og det er billigere at teste. Spørg derfor først, om opgaven overhovedet kræver, at modellen selv vælger vejen.
Hvad agenten må røre
Tænk på agenten som en ny medarbejder, der er hurtig, flittig og godtroende. Giv den de rettigheder, opgaven kræver, og ingen andre.
- Handl på vegne af brugeren. Agenten skal have den aktuelle brugers rettigheder, så den aldrig kan gøre mere, end brugeren selv må. En fælles konto med brede rettigheder er den fejl, der gør størst skade.
- Brug smalle værktøjer. Giv den “opret kladde til faktura” frem for adgang til hele fakturasystemet. Et værktøj, der kan alt, kan også det forkerte.
- Del læsning og skrivning. Mange agenter skal kun læse det meste af tiden.
- Sæt grænser i koden. Antal poster pr. handling, beløbsgrænser i aftalen med kunden, tilladte modtagere og tidsrum håndhæves uden for modellen.
- Foretræk handlinger, der kan fortrydes. Sletning og afsendelse ud af huset skal have en ekstra forhindring.
Agenten skal også behandles som mistænkelig, når den læser tekst udefra. En mail eller et dokument kan indeholde skjulte instruktioner, og det er den risiko, der er beskrevet i prompt injection. Sikkerhedsprojektet OWASP har “Excessive Agency”, altså for vide beføjelser, på sin liste over risici ved sprogmodeller.
Hvad der kræver et menneske
Lav en liste over handlinger i tre grupper, og tag den op med produktansvarlig og gerne en kunde:
- Må ske automatisk: finde data, lave udkast, sortere. Handlingerne logges.
- Kræver godkendelse: sende til kunder, ændre stamdata, booke. En bruger bekræfter med overblik over, hvad der sker.
- Må agenten aldrig: slette konti, ændre rettigheder, betale. Værktøjet findes slet ikke for agenten.
Godkendelsen skal være reel. Hvis brugeren får tyve anmodninger om dagen, klikker vedkommende ja uden at læse. Vis derfor præcis, hvad der vil ske, saml små handlinger til én beslutning, og lad agenten bede om godkendelse sjældnere.
Tilliden kan gradvist udvides. Når I har set en type handling gå rigtigt i en længere periode, kan den flyttes en gruppe op. Lad det være en beslutning, der står skrevet ned, og lad kunden have det sidste ord om sit eget miljø.
Sådan logges handlingerne
Et almindeligt system logger, at en bruger ændrede noget. For en agent skal I kunne svare på mere:
- Hvem bad om det, og hvad var teksten?
- Hvilke skridt valgte modellen, og hvilke data så den?
- Hvilket værktøj blev kaldt med hvilke værdier, og hvad var resultatet?
- Hvem godkendte, og hvad blev vist på skærmen?
- Hvilken modelversion og hvilke instruktioner var i brug?
Handlinger skal stå i produktets almindelige ændringslog, så det fremgår, at en agent udførte dem på vegne af en bestemt bruger. Kunder med krav til logning og roller vil spørge efter det. Hvad samtaler må rumme, og hvordan de opbevares, står i kundedata i AI-funktionen.
Brems og nødstop
En agent kan gå i ring. Den prøver igen, fejler, prøver noget andet og bruger imens af jeres forbrug hos udbyderen. Der skal derfor være:
- et loft over antal skridt pr. opgave,
- et loft over forbrug og tid,
- en kontakt, der stopper agenten for én kunde eller for alle uden en ny udgivelse,
- en alarm, når en agent gør noget usædvanligt.
Test agenten mod et prøvemiljø med falske data, og afprøv, hvad der sker, når et værktøj svarer forkert. Bedømmelsen følger metoden i test af AI-funktioner, og den ser på handlinger ud over tekst.
Ansvar
Når en agent laver en fejl hos en kunde, peger kunden på jer. Fordel derfor ansvaret i tre retninger:
- Internt: hvem ejer agentens rettigheder, og hvem godkender nye værktøjer?
- Over for kunden: hvad står der i vilkårene om, hvad agenten må, og hvem der godkender?
- Over for modelleverandøren: hvad er aftalt, og hvad sker der ved et modelskift?
Bygger I funktionen under eget navn, kan I have en rolle efter AI-forordningen, og handlinger, der påvirker fx ansættelse eller kredit, skal vurderes særskilt. Aftalevilkår og ansvar i konkrete sager er et spørgsmål til advokat.
Tre spørgsmål før beslutningen
Stil disse til teamet, før en agent får lov at ændre noget hos en kunde:
- Hvad er det værste, agenten kan gøre med de rettigheder, den har i dag?
- Hvordan ville vi opdage det, og hvor hurtigt?
- Hvad skal der til for at rulle det tilbage?
Kan teamet ikke svare, er rettighederne for brede.
Det skal I lade være med
- At give agenten en servicekonto med brede rettigheder · den arver magt, ingen bruger selv har.
- At skrive grænserne ind i instruktionerne alene · en grænse, modellen kan overtale sig selv fra, er ingen grænse.
- At bede om godkendelse til alt · så klikker brugeren ja uden at læse.
- At starte med de handlinger, der ikke kan fortrydes · begynd med udkast og forslag.
Det skal I kræve af den eksterne
- ☐ En liste over handlinger fordelt på automatisk, godkendelse og aldrig.
- ☐ Krav om, at rettigheder følger brugeren og håndhæves uden for modellen.
- ☐ Et logformat, der kan bruges over for en kunde.
- ☐ Loft over skridt og forbrug samt et nødstop, der er afprøvet.
- ☐ En plan for at udvide tilliden gradvist.
Kilder
- OWASP Top 10 for LLM and Gen AI Applications, 2025-udgaven: LLM06 Excessive Agency.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Demoen virker · AI-funktionen svarer forkert
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
