En AI-agent til e-mails opsættes ved at koble en mailkonto til en model, definere konkrete handlinger og lægge menneskelig kontrol ind før risikable afsendelser. Den bør først sortere, opsummere og klargøre udkast, før den får lov til at sende eller ændre mails automatisk.
En AI-agent til e-mails bør starte med afgrænsede handlinger, sikre mailadgange og udkast, som et menneske godkender før afsendelse. Det centrale er at styre, hvilke data agenten må læse, hvilke handlinger den må udføre, og hvordan fejl, logning og stopregler håndteres.
Hvad er en AI-agent til e-mails?
En AI-agent til e-mails er et system, der kan læse udvalgte mails, forstå en opgave, vælge en handling og eventuelt udføre handlingen via en mailplatform. Den kan for eksempel prioritere indbakken, foreslå svar, oprette udkast, sætte labels, finde manglende oplysninger eller sende en besked efter godkendelse.
Det afgørende er, at agenten ikke kun genererer tekst. Den har et handlingslag omkring modellen. Det handlingslag kan være Gmail API, Microsoft Graph, et CRM-system, en kalender, et ticketsystem eller en intern database. Derfor skal opsætningen behandle både sprogforståelse, rettigheder, dataafgrænsning og kontrolpunkter.
Hvis du vil skelne begrebet fra en almindelig chatbot, er forskellen forklaret nærmere i hvad en AI-agent er, og hvordan den adskiller sig fra en chatbot. I e-mailkontekst bliver forskellen tydelig, fordi agenten kan forberede eller udføre konkrete handlinger i indbakken.
Hvilken opgave skal agenten løse først?
Opsætningen bør begynde med én afgrænset opgave. En e-mailagent kan teknisk set få mange roller, men en bred start gør den svær at teste. Vælg derfor først mellem sortering, opsummering, udkast, opfølgning, intern routing eller afsendelse. Hver kategori har forskellig risiko og kræver forskellige kontroller.
Lavrisikoopgaver er typisk læsende eller forberedende. Agenten kan markere en mail som “kræver svar”, foreslå en kategori eller udarbejde et udkast uden at sende det. Højrisikoopgaver er handlinger, som ændrer relationen til en ekstern modtager: afsendelse, videresendelse, sletning, arkivering af juridisk relevante mails eller løfter om priser, levering, ansættelse eller support.
En god første version er derfor ofte en udkast-agent. Den læser en mail, finder intentionen, foreslår et svar og gemmer udkastet, mens et menneske sender. Det giver reel tidsbesparelse uden at give systemet fri adgang til at kommunikere på vegne af brugeren.
Hvilke mailadgange skal forbindes?
Mailadgangen afhænger af platformen. Gmail API kan bruges til autoriseret adgang til Gmail-mailbokse, herunder læsning, organisering, filtrering og programmatisk afsendelse. Microsoft Graph giver tilsvarende autoriseret adgang til Outlook- og Microsoft 365-maildata med ressourcer til beskeder, mapper, sendte elementer, regler og notifikationer.
Agenten bør kun have de tilladelser, der matcher den valgte opgave. Hvis den kun skal foreslå svar, er fuld adgang til at sende mails ofte unødvendig. Hvis den skal sende, skal tilladelsen være eksplicit, logget og knyttet til en klar godkendelsesmodel. Gmail dokumenterer send-scopes for beskedafsendelse, og Microsoft Graph dokumenterer Mail.Send for sendMail-handlingen.
For organisationer er det også relevant, om agenten kører med brugerens delegerede adgang eller som en applikation med bredere adgang. Delegeret adgang følger ofte brugerens kontekst, mens applikationsadgang kan være mere kraftfuld og derfor kræver strammere governance. Den forskel bør afklares, før agenten forbindes til rigtige mailbokse.
Hvordan bør agentens handlinger afgrænses?
Agentens handlinger bør beskrives som små, navngivne funktioner i applikationslaget. Det kan være “opret udkast”, “sæt label”, “find seneste ordre”, “foreslå prioritet” eller “send godkendt svar”. Modellen bør ikke få fri tekstadgang til hele mail-API’et. Den bør kun kunne vælge mellem de handlinger, som udvikleren har gjort tilgængelige.
OpenAI beskriver function calling som en metode, hvor modellen kan kobles til eksterne systemer gennem definerede værktøjer, mens applikationen udfører den faktiske kode. Den model passer godt til e-mailagenter, fordi du kan lægge regler ind i værktøjerne: hvilke felter må udfyldes, hvornår kræves godkendelse, og hvilke handlinger er aldrig tilladt.
En smal værktøjsliste gør agenten mere forudsigelig. Hvis opgaven er at lave svarudkast, behøver agenten ikke værktøjer til at slette mails eller ændre videresendelsesregler. Hvis opgaven er intern routing, behøver den ikke adgang til ekstern afsendelse. Afgrænsningen er et teknisk designvalg, ikke kun en sproglig instruktion.
Hvordan ser en robust arbejdsgang ud?
En robust e-mailagent arbejder i trin. Først henter den en afgrænset mængde maildata. Derefter klassificerer den opgaven, henter eventuel relevant kontekst, laver et forslag og gemmer status. Til sidst sendes handlingen til menneskelig godkendelse eller udføres automatisk, hvis handlingen er lav risiko og eksplicit tilladt.
Et praktisk flow kan se sådan ud: nye mails mærkes efter type, agenten foreslår prioritet, den opretter udkast til bestemte typer henvendelser, og brugeren godkender udkastet i mailklienten. Først når denne proces fungerer stabilt, kan enkelte lavrisikohandlinger automatiseres, for eksempel intern labeling eller arkivering af nyhedsbreve efter faste regler.
Det er nyttigt at tænke i tilstande. En mail kan være “ny”, “analyseret”, “udkast oprettet”, “afventer godkendelse”, “sendt”, “afvist” eller “kræver manuel behandling”. Med tydelige tilstande undgår du, at agenten behandler samme besked flere gange eller sender et svar efter, at en bruger allerede har håndteret sagen.
Hvorfor er udkast bedre end automatisk afsendelse i starten?
Udkast reducerer risikoen, fordi agenten kan levere værdi uden at tage den sidste eksterne handling. Gmail API har en draft-ressource til uafsendte beskeder, og Microsoft Graph kan både oprette og sende meddelelser. Den tekniske forskel bør udnyttes i designet: først udkast, derefter godkendelse, derefter eventuelt afsendelse.
Automatisk afsendelse kan give mening i snævre scenarier, for eksempel standardiserede interne kvitteringer eller beskeder, hvor indholdet ikke kræver vurdering. Den bør ikke være første trin for kundesvar, HR-sager, klager, økonomiske aftaler eller følsomme emner. Her er det mere sikkert, at agenten formulerer et forslag og gør begrundelsen synlig.
Udkast giver også en god læringssløjfe. Brugeren kan rette tonen, markere fejl og afvise forslag. De mønstre kan bruges til at forbedre regler, eksempler og datagrundlag, uden at fejl allerede er sendt ud af organisationen.
| Niveau | Agentens rolle | Typisk kontrol |
|---|---|---|
| Assistent | Opsummerer og prioriterer mails | Ingen afsendelse, kun forslag |
| Udkast-agent | Opretter svar, labels og opfølgningsforslag | Menneskelig godkendelse før eksterne handlinger |
| Handlende agent | Udfører udvalgte handlinger automatisk | Stramme regler, logging og mulighed for stop |
Hvilke data må agenten læse?
Agenten bør kun læse de mailfelter, den skal bruge. Til prioritering kan afsender, emne, dato og et kort uddrag være nok. Til svarudkast kan den også bruge den relevante tråd, kundetype eller ordrestatus. Det er sjældent nødvendigt at give adgang til hele mailboksen, gamle vedhæftninger og alle mapper fra første dag.
Dataafgrænsning er særlig vigtig, fordi e-mails ofte indeholder persondata, fortrolige forretningsoplysninger, adgangslinks, kontraktvilkår, helbredsoplysninger eller interne konflikter. Agenten bør have regler for, hvilke mapper den må se, hvilke vedhæftninger den må analysere, og hvilke emner der altid skal sendes til manuel behandling.
Du kan gøre grænsen praktisk ved at oprette en særskilt label, mappe eller kø, som agenten må arbejde med. Brugeren eller et regelsæt flytter relevante mails dertil. Det giver en klarere start end fuld indbakkeadgang og gør det lettere at stoppe agenten uden at afbryde hele mailkontoen.
Hvordan kobles agenten til viden uden at læse for meget?
En e-mailagent bliver bedre, hvis den kan hente relevant viden: produktvilkår, standardsvar, leveringsregler, åbningstider, CRM-data eller interne procedurer. Men kontekst bør hentes målrettet. Hvis agenten får alle dokumenter hver gang, øges risikoen for langsomme svar, irrelevante forslag og unødig datadeling.
En praktisk model er at lade agenten identificere mailtypen og derefter hente et lille sæt relevante kilder. En supportmail om faktura bør ikke give adgang til hele produktmanualen. En HR-mail bør ikke blandes med salgsdata. Det samme princip gælder forskellen mellem AI-agenter og AI-workflows: agenten kan vælge, men workflowet bør stadig sætte grænser.
Hvis svarene kræver præcise oplysninger, bør agenten skelne mellem fundet viden og egen formulering. Den kan for eksempel skrive “grundlag: ordrestatus hentet fra systemet” i en intern note, mens selve mailudkastet holdes kort og venligt. Så bliver det lettere for brugeren at kontrollere, hvor svaret kommer fra.
Hvordan håndteres fejl, misbrug og uønskede handlinger?
Fejl i e-mailagenter kan være mere synlige end fejl i interne analyseværktøjer, fordi de rammer modtagere direkte. Derfor bør opsætningen have stopregler. Agenten bør ikke sende svar, hvis mailen handler om klager, betaling, kontrakter, opsigelser, ansættelse, helbred, sikkerhed, adgangskoder eller juridiske vurderinger, medmindre der findes en særskilt godkendt proces.
Misbrug kan også komme udefra. En mail kan forsøge at få agenten til at ignorere regler, videresende fortrolige oplysninger eller udføre en handling, der ikke passer til afsenderens rettigheder. Derfor bør agenten behandle mailindhold som upålideligt input og aldrig lade en ekstern afsender ændre agentens egne regler.
Logning er en enkel, men central kontrol. Gem besked-ID, tidspunkt, handling, modelrespons, anvendt værktøj, godkendende bruger og endelig status. Loggen gør det muligt at fejlfinde, dokumentere beslutninger og stoppe mønstre, hvor agenten gentager samme fejl.
Hvornår er en almindelig automatisering nok?
En AI-agent er ikke altid nødvendig. Hvis opgaven kan beskrives med faste regler, er et almindeligt filter, en mailregel eller et workflow ofte mere stabilt. Eksempler er videresendelse fra bestemte afsendere, arkivering af nyhedsbreve, standardlabels eller påmindelser efter en fast dato. Her giver en agent ofte ekstra kompleksitet uden tilsvarende nytte.
En agent giver mere mening, når opgaven kræver fortolkning. Det kan være at skelne mellem en kunde, der klager, en kunde, der spørger neutralt, og en kunde, der beder om noget, som kræver intern godkendelse. Det kan også være at samle flere oplysninger og foreslå et svar, hvor tonen skal tilpasses situationen.
Hvis du er i tvivl, kan du starte med et workflow og kun lade agenten håndtere undtagelser. Den tilgang minder om den praktiske skelnen i hvordan en AI-agent fungerer trin for trin: agenten bør have en opgave, en beslutningslogik og et kontrolleret handlingsrum.
Hvordan tester du agenten før drift?
Test bør ske på kopier, syntetiske mails eller en begrænset mappe, før agenten får adgang til rigtige arbejdsgange. Lav et testsæt med normale mails, uklare mails, svære mails og mails, som agenten skal afvise. Mål ikke kun, om teksten lyder god, men om agenten vælger den rigtige handling.
En nyttig testmatrix kan indeholde mailtype, ønsket handling, data der må læses, forventet output, krav om godkendelse og stopregel. Hvis agenten fejler på en højrisikomail, bør løsningen ikke gå i drift, før grænsen er rettet. Det gælder også, hvis agenten sender for lange svar, misforstår afsenderens hensigt eller bruger oplysninger fra forkert kunde.
NIST’s AI Risk Management Framework kan bruges som overordnet ramme for at tænke i risiko, troværdighed og evaluering. Det er ikke en specifik e-mailmanual, men principperne passer til agentdesign, fordi systemet kan påvirke både organisation, modtagere og enkeltpersoner.
Hvordan kan agenten forbedres efter første version?
Efter første version bør forbedringer bygge på konkrete observationer. Se på afviste udkast, manuelle rettelser, fejltyper, svartid og de situationer, hvor brugeren alligevel overtager. Det er mere brugbart end at udvide agentens adgang, bare fordi teknologien kan mere.
Du kan forbedre agenten ved at indføre bedre mailkategorier, kortere standardsvar, tydeligere værktøjsgrænser, bedre kontekstvalg og mere præcise stopregler. Hvis agenten bruges til kommercielle mails, bør den holdes adskilt fra bredere AI til optimering af e-mail-marketing, fordi support-, salgs- og marketingmails har forskellige risici.
En moden agent er ikke den, der gør mest automatisk. Det er den, der løser en veldefineret opgave med kendte grænser, tydelige logs og en menneskelig rolle der, hvor konsekvensen er høj. Først når den disciplin er på plads, giver det mening at udvide fra udkast til mere selvstændige handlinger.
Hvilke kilder ligger til grund?
Den tekniske del bygger på Gmail API overview, Googles dokumentation for Gmail drafts, Microsofts dokumentation for sendMail i Microsoft Graph og OpenAI’s vejledning om function calling. Risikovurderingen bygger desuden på NIST AI Risk Management Framework.