Af Greg Nowak. Senest opdateret 2026-09-18.
Kundeindbakken er ofte virksomhedens mindst strukturerede arbejdsfordeler. Tilbudsanmodninger, reklamationer, spørgsmål til fakturaer og almindelige servicehenvendelser lander side om side. Derefter bruger medarbejderne tid på at læse, vurdere og sende hver mail videre.
Kunne jeres virksomhed bruge det her? nowa.dk sætter AI-automatisering op for danske virksomheder.
AI kan overtage en stor del af sorteringen. Grænsen skal bare være tydelig: Systemet må forstå mailen, men ikke adlyde den. En kunde kan godt skrive, at sagen haster. Kunden skal ikke kunne få AI’en til at tilsidesætte regler, hente uvedkommende data eller aktivere et værktøj – hverken med en direkte besked eller en skjult instruktion.
Et sikkert mailflow består derfor af en kontrolleret kæde: Modtag hændelsen, klassificér indholdet, kontrollér resultatet, udarbejd et forslag og send det til menneskelig godkendelse. Det er langt mere anvendeligt end at give en autonom AI-medarbejder adgang til hele værktøjskassen.
Reagér på nye mails frem for at overvåge indbakken
Et moderne mailflow behøver ikke spørge indbakken hvert minut, om der er kommet noget nyt. Gmail API understøtter push-notifikationer via Google Cloud Pub/Sub. En backend kan dermed få besked, når en overvåget postkasse ændrer sig, og starte behandlingen kort efter, at mailen er modtaget.
Notifikationen indeholder dog ikke hele mailen. Gmail sender blandt andet en ny historikmarkør, som integrationen bruger til at hente ændringer siden den senest registrerede markør. Systemet skal derfor gemme sin position, kvittere for beskeder og kunne håndtere, at samme hændelse leveres igen. Hvis en notifikation ikke bliver kvitteret, kan Pub/Sub forsøge på ny.
Google oplyser også, at notifikationer i sjældne tilfælde kan blive forsinket eller gå tabt. En periodisk kontrol bør derfor samle eventuelle manglende ændringer op. Selve overvågningen kræver vedligeholdelse: Gmail kræver et nyt watch-kald mindst hver syvende dag og anbefaler, at det fornyes dagligt.
Microsoft Graph tilbyder tilsvarende ændringsnotifikationer for Outlook-mails. Her kan et abonnement afgrænses til bestemte ændringstyper, mapper og betingelser. Det kan for eksempel reagere på nye beskeder uden at starte et flow ved enhver mindre ændring i postkassen. Abonnementerne udløber og skal forlænges, mens lifecycle-notifikationer kan hjælpe med at opdage fjernede abonnementer eller mistede hændelser.
En notifikation sætter processen i gang
Når integrationen modtager en mailhændelse, bør den kun hente de oplysninger, som den konkrete opgave kræver. Microsoft Graph dokumenterer både notifikationer med krypterede ressourcedata og notifikationer uden mailindhold, hvor beskeden hentes bagefter. Selektion og filtrering kan holde datamængden nede.
Det samme princip bør gælde for rettighederne. Hvis opgaven er at kategorisere nye henvendelser og oprette kladder, behøver AI-delen næppe adgang til at slette mails, ændre kontakter eller sende svar på egen hånd. Adgangen skal passe til den godkendte arbejdsgang, ikke til alt det, platformens API teknisk set kan udføre.
| Trin | Automatikken må | Grænsen går ved | Praktisk kontrol |
|---|---|---|---|
| Modtagelse | Registrere en mailhændelse og hente nødvendige felter | At hente hele postkassen uden et konkret behov | Afgræns mapper, felter og rettigheder |
| Klassifikation | Foreslå type, prioritet og ansvarligt team | At behandle afsenderens tekst som en systeminstruktion | Test med indirekte promptinjektion |
| Arbejdsgang | Oprette en intern ticket eller svarkladde | At ændre kritiske data eller godkende økonomiske handlinger | Brug faste tilladelseslister og validerede felter |
| Svar | Foreslå et svar ud fra godkendt kontekst | At sende noget eksternt uden menneskelig kontrol | Kræv eksplicit godkendelse |
| Drift | Logge beslutninger og samle mistede hændelser op | At skjule fejl eller fortsætte fra en usikker tilstand | Overvåg abonnementer, køer og afvigelser |
Behandl mailen som data med lav tillid
En mail kommer fra en ekstern part. Den kan rumme almindelig tekst, links, signaturer, videresendte beskeder og vedhæftede dokumenter. Alt dette kan være relevant for sagen, men intet af det bør fungere som en betroet instruktionskanal.
I vejledningen om Prompt Shields beskriver Microsoft dokumentangreb som instruktioner, der ligger indlejret i tredjepartsindhold, herunder e-mails. Formålet kan være at lokke modellen til utilsigtede handlinger, uautoriseret adgang, dataudtræk eller svindel. Det kaldes ofte indirekte promptinjektion, fordi instruktionen følger med det materiale, AI’en bliver bedt om at behandle.
Et filter er et nyttigt forsvarslag. Prompt Shields kan registrere mistænkeligt input og enten annotere eller blokere det. Detektionslaget kan dog både overse angreb og markere uskyldigt indhold. Den mest robuste beskyttelse ligger derfor i systemets rammer: Modellen skal kun have den adgang og handlekraft, som opgaven kræver.
Design efter, at modellen en dag tager fejl
OWASP’s sikkerhedsopdatering for 2026 følger udviklingen fra modeller, der producerer indhold, til agenter, der også kan handle. Dermed handler sikkerheden ikke længere kun om, hvad modellen formulerer. Den afhænger også af, hvilke data og værktøjer det samlede system kan nå, og hvilke handlinger det må udføre. OWASP fremhæver blandt andet identitet, governance, test og kontrol under drift.
For kundeindbakken betyder det, at en god systemprompt ikke kan bære sikkerheden alene. Arkitekturen bør tage højde for, at modellen før eller siden misforstår noget eller bliver påvirket af en manipuleret mail. Konsekvensen kan begrænses ved at dele flowet op: Én komponent læser og klassificerer, en anden validerer det strukturerede resultat, og et godkendt workflow udfører kun på forhånd definerede handlinger.
Et svarforslag kan eksempelvis afleveres som en kladde sammen med foreslået emne, kategori og kø. En medarbejder kontrollerer indhold, modtager og eventuelle vedhæftninger, før svaret bliver sendt. Er klassifikationen usikker, skal sagen gå til manuel behandling i stedet for at blive presset igennem på et spinkelt gæt.
Begynd med arbejdsgangen
Første opgave er at kortlægge de henvendelser, der faktisk kommer ind. Hvilke typer fylder mest? Hvilke kræver hurtig reaktion? Hvilke kan trygt ende som en kladde, og hvilke må aldrig automatiseres videre? Svarene danner grundlag for kategorier, eskalationsregler, godkendelser og den information, medarbejderen skal have foran sig.
Et afgrænset første flow kan samle fire opgaver: registrering af nye mails, klassifikation efter kendte henvendelsestyper, prioritering efter aftalte regler og oprettelse af en ticket eller svarkladde. Effekten bør vurderes på forhold, der betyder noget i driften: fejlsorteringer, usikre resultater, manglende hændelser og tiden fra modtagelse til første interne behandling.
Testmaterialet skal rumme mere end pæne standardmails. Brug også tvetydige formuleringer og bevidste forsøg på promptinjektion. Prøv derefter de kedelige, men afgørende driftsfejl: dobbelte notifikationer, udløbne abonnementer, tidsudløb og hændelser i forkert rækkefølge. Her viser det sig, om løsningen kan fungere som en stabil forretningsproces og ikke kun som en overbevisende demonstration.
Hurtigere service inden for en klar sikkerhedsgrænse
Greg kan gennem nowa.dk, en AI-automatiseringsservice for danske virksomheder, kortlægge henvendelsestyper og svartider og forbinde Gmail eller Microsoft 365 med de mindst nødvendige rettigheder. Leverancen kan omfatte klassifikation, prioritering, kladder eller tickets, logning, håndtering af usikre resultater og test mod promptinjektion.
Opgaven er at fjerne det hurtige, gentagne analysearbejde uden at gøre AI’en til selvstændig kundeservicechef. Indbakken må gerne sortere sig selv. Den må bare aldrig få lov til at bestemme, hvad virksomhedens AI kan gøre.
Relateret på GrN.dk
- Montørens talenote skal blive til en arbejdsordre – ikke rå lyd
- Samme kunde, tre kundekort: AI-oprydning med styr på historikken
Brug for hjælp til den slags opgaver?
Få kortlagt jeres sikre mailflow Kontakt Greg her.
