Gå til hovedindholdet
FromNine
Menu

AI & data

AI-agenter og automatisering der holder sig inden for dine grænser.

Vi automatiserer arbejde i flere trin med agenter og workflows. De bruger afgrænsede værktøjer, venter på godkendelse før handlinger med konsekvens og efterlader et spor, som jeres revision kan afspille igen.

For kommuner, styrelser og virksomheder der vil automatisere sagsforløb, uden at afgørelsen forlader sagsbehandleren.

Tal med os om dit projektLæs om borger- og kundeservice
AI-agenter & automatisering: lagene i løsningenFire lag oven på hinanden. Fra øverst til nederst: det workflow der holder styr på tilstanden, agentens trin inde i det, værktøjsgatewayen med sine rettigheder og godkendelsen før en handling når dine systemer.01Workflow og tilstand02Agentens trin03Værktøjsgateway og rettigheder04Godkendelse, så handling
  1. 01Den rette grad af selvstændighed pr. trin, fra fast workflow til agent under opsyn
  2. 02Værktøjer med mindst mulige rettigheder bag en gateway, med grænser pr. handling
  3. 03Hvert trin, hvert værktøjskald og hver godkendelse logges, kan afspilles og eksporteres

01 Problemer

Hvorfor automatiserings­projekter tøver

  1. 01

    Ingen kan sige hvad agenten må

    Den kører under en bred servicekonto. Risikostyring og it-sikkerhed vil ikke godkende den, og de skal heller ikke gætte.

  2. 02

    Automatiseringsgraden ser god ud, men undtagelserne hober sig op

    De enkle sager glider igennem. Resten lander i en fælles postkasse uden kontekst, og teamet der håndterer dem, har nu mere travlt end før.

  3. 03

    Når det går galt, kan ingen genskabe hvorfor

    Der er ingen registrering af hvilke data agenten så, hvilket værktøj den kaldte, eller hvem der godkendte trinnet. Den interne revision spørger, og der er intet svar.

  4. 04

    Robotterne går i stykker hver gang et skærmbillede ændres

    Robotter der læser skærmbilleder, bærer kritisk arbejde. Hver opdatering af en applikation betyder en weekend med reparationer.

02 Leverancer

Det leverer vi

  1. 01 Selvstændighed designet pr. trin

    For hvert trin vælger vi det enkleste der virker: et deterministisk workflow, ét modelkald, en agent med værktøjer eller orkestrering i flere trin. Nogle gange er det rigtige svar at en agent er det forkerte værktøj.

    Det gør vi

    • Gennemgang af processen med dem der udfører arbejdet
    • Beslutning om selvstændighed trin for trin, med risiko pr. trin
    • Tilstandsmaskine eller BPMN-model af forløbet
    • Kriterier for at give et trin mere eller mindre selvstændighed

    Det får du

    • Kort over selvstændighed i processen
    • Workflowmodel under versionsstyring
    • Begrundet beslutning for hvert agenttrin

  2. 02 Værktøjsrettigheder og mindst mulige rettigheder

    Agenter kalder værktøjer, aldrig systemer direkte. En værktøjsgateway håndhæver rettigheder, tilladelseslister og beløbsgrænser, og hvert værktøj kører under sin egen serviceidentitet.

    Det gør vi

    • Værktøjskatalog med læse- og skriveværktøjer adskilt
    • Afgrænsede serviceidentiteter pr. værktøj
    • Beløbs- og frekvensgrænser pr. type handling
    • Isoleret kørsel ved håndtering af kode og filer

    Det får du

    • Værktøjsgateway med politik som konfiguration
    • Rettighedsmatrix godkendt af it-sikkerhed
    • Testsuite for håndhævelse af politikker

  3. 03 Design med mennesket i løkken

    Godkendelsesgrænser, routing efter sikkerhed og firøjneprincip for handlinger med konsekvens. Afgørelser om personer har altid en person med i løkken, i tråd med GDPR artikel 22 og retten til menneskelig prøvelse.

    Det gør vi

    • Klassificering af handlinger efter konsekvens
    • Godkendelsesgrænser og regler for eskalering
    • Brugerflade til godkendere med den kontekst der skal til for at beslutte
    • Sikkerhedsforanstaltninger for afgørelser om enkeltpersoner

    Det får du

    • Godkendelsespolitik pr. type handling
    • Godkendelsesforløb i de værktøjer jeres teams allerede bruger
    • Eskaleringskort med navngivne teams

  4. 04 Sporbarhed og revision

    En fuldstændig registrering af input, hentet kontekst, modeloutput, værktøjskald og godkendelser, så hver kørsel kan afspilles og eksporteres til intern revision eller en tilsynsmyndighed.

    Det gør vi

    • Design af hændelseslog med regler for opbevaring
    • Afspilning af kørsler mod faste input
    • Eksportformater aftalt med intern revision
    • Dashboards for andelen af undtagelser og godkendelser

    Det får du

    • Lager til revisionsspor
    • Værktøjer til afspilning
    • Driftsdashboards

  5. 05 Håndtering af fejl

    Agenter vil fejle. Vi designer så fejl er ufarlige: idempotente handlinger, kompensation og tilbagerulning, timeouts, eskalering til et navngivet team og en nødstop-knap som en bestemt person har ret til at bruge.

    Det gør vi

    • Idempotensnøgler på hver skrivehandling
    • Kompenserende trin for ændringer på tværs af systemer
    • Timeouts og budgetter for genforsøg
    • Nødstop pr. agent og pr. værktøj

    Det får du

    • Analyse af fejltilstande
    • Driftsvejledning med procedure for nødstop
    • Kaostests af de kritiske forløb

  6. 06 Agenter side om side med eksisterende automatisering

    Process mining viser forløbet som det faktisk kører. RPA bliver, hvor der kun findes et gammelt skærmbillede, og flytter til API’er så snart der findes ét. Vi måler andelen af undtagelser, ikke kun automatiseringsgraden.

    Det gør vi

    • Process mining på hændelseslogs
    • Oversigt over eksisterende robotter og deres fejlhistorik
    • API-alternativer til skrøbelig skærmautomatisering
    • Analyse af undtagelser efter årsag

    Det får du

    • Analyse af det nuværende forløb
    • Plan for at flytte fra skærmbilleder til API’er
    • Udgangspunkt og mål for tiden brugt på undtagelser

03 Arkitektur

En illustrativ referencearkitektur

Orkestratoren ejer tilstanden i arbejdet. Agentens trin ligger inde i den og kan kun nå dine systemer gennem værktøjsgatewayen, der kontrollerer rettigheder og grænser ved hvert kald. Læseværktøjer går igennem. Skriveværktøjer stopper ved en godkendelse, når handlingen har konsekvens.

Alt efterlader et spor i revisionssporet. Nødstop og timeouts sidder på orkestratoren, og undtagelser går til et navngivet team med hele kørslens kontekst.

Lagene i tegningen

Modtagelse
En ny sag, besked eller hændelse starter en kørsel med et korrelations-id.
Orkestrering
Workflowets tilstand, agentens trin, kompensation og nødstop.
Rettighedsgrænse
Værktøjsgateway, læseværktøjer, godkendelse og skriveværktøjer.
Systemer
CRM, ERP og sagssystemer, som kun kan nås gennem værktøjer.
Spor
Revisionssporet og det team der håndterer eskaleringer.
Eksempel

  1. Modtagelse

    • Udløser: sag, besked, hændelse

  2. Orkestrering

    • Orkestrator og tilstand
    • Agenttrin
    • Nødstop og timeouts
    • Kompensation og tilbagerulning

  3. Rettighedsgrænse

    • Værktøjs­gateway
    • Læseværktøjer
    • Godkendelse
    • Skriveværktøjer

  4. Systemer

    • CRM, ERP, sagssystem

  5. Spor

    • Revisionsspor: hvert trin, kald og godkendelse, med afspilning og eksport
    • Navngivet team for undtagelser
En agent inden for en rettighedsgrænse

Illustrativ arkitektur, ikke en kundes system.

Læs diagrammet som tekst

Hovedruten går fra en udløser gennem orkestratoren og et agenttrin til værktøjsgatewayen, derefter gennem en godkendelse hvor en person beslutter, så til et skriveværktøj og til sidst til forretningssystemerne.

Gatewayen tillader også læseværktøjer der henter direkte fra forretningssystemerne. Et nødstop styrer orkestratoren, kompenserende trin kan fortryde agentens handlinger, og orkestratoren eskalerer til et navngivet team.

Godkendelser og skrivehandlinger registreres i et revisionsspor, der kan afspilles og eksporteres. Gatewayen, læseværktøjerne, godkendelsen og skriveværktøjerne udgør tilsammen rettighedsgrænsen.

04 Hensyn og begrænsninger

Tekniske hensyn og begrænsninger

  • Selvstændighed gives trin for trin

    Sådan håndterer vi det

    Trin starter under opsyn. Vi giver kun mere selvstændighed, når logs viser at trinnet holder sig inden for de aftalte grænser over et tilstrækkeligt antal sager.

    Begrænsninger og afhængigheder

    Nogle trin skal aldrig være selvstændige, uanset hvad tallene viser. Det er en forretningsbeslutning, og vi beder dig træffe den udtrykkeligt.

  • En agent er kun så sikker som sine værktøjer

    Sådan håndterer vi det

    Skriveværktøjer er snævre og har faste parametre: »opret en kreditnota op til en grænse«, aldrig »kald ERP-systemet«.

    Begrænsninger og afhængigheder

    Hvor et system ikke har en finmasket rettighedsmodel, kompenserer vi i gatewayen. Det giver mere arbejde, og nogle systemer kan ikke gøres sikre nok til skriveadgang.

    AI-output kan være forkert. Derfor stopper handlinger med konsekvens hos en person, og usikre sager sendes videre i stedet for at blive gættet.

  • Prompt injection er en driftsrisiko

    Sådan håndterer vi det

    Indhold fra e-mails, dokumenter og websider behandles som ikke-betroet. Det kan ikke ændre agentens instruktioner eller udvide dens rettigheder, og red teaming-tests kontrollerer at det ikke sker.

    Begrænsninger og afhængigheder

    Ingen foranstaltning fjerner risikoen helt. Designet går ud fra at et forsøg en dag lykkes, og begrænser hvad det kan nå.

  • Undtagelser er en del af produktet

    Sådan håndterer vi det

    Hver undtagelse kommer med kørslens kontekst, en årsag og et forslag til næste skridt, i køen hos et team der ejer den.

    Begrænsninger og afhængigheder

    Automatisering flytter arbejde i stedet for at fjerne det, hvis ingen ejer undtagelseskøen. Vi går ikke i drift uden en navngivet ejer.

05 Sådan arbejder vi

Sådan arbejder vi

Vi tager udgangspunkt i processen som den kører, ikke som den er tegnet, og giver selvstændighed trin for trin.

  1. 01

    Se det rigtige forløb

    Process mining og observation viser mængder, varianter og hvor tiden går tabt.

    ResultatAnalyse af det nuværende forløb

  2. 02

    Fastlæg selvstændighed pr. trin

    Workflow, modelkald eller agent, med konsekvensen af en forkert handling skrevet ned for hvert trin.

    ResultatKort over selvstændighed og rettighedsmatrix

  3. 03

    Kør i skyggedrift

    Systemet foreslår, mennesker handler. Vi sammenligner forslagene med medarbejdernes beslutninger på rigtige sager.

    ResultatRapport fra skyggedrift

  4. 04

    Gå i drift med godkendelser

    Handlinger med konsekvens venter på godkendelse. Grænserne justeres ud fra data, ikke mavefornemmelse.

    ResultatGodkendelsespolitik og dashboards

06 Menneskelig kontrol

Hvor mennesker har kontrollen

Agenter handler inden for de rettigheder du fastlægger, beder om godkendelse før handlinger med konsekvens og logger hvert trin.

  • Godkendelse før konsekvens

    Betalinger, afgørelser om enkeltpersoner og ændringer i stamdata venter på en person, med den kontekst der skal til for at beslutte hurtigt.

  • Firøjneprincip hvor det betyder noget

    Over aftalte grænser godkender to personer. Grænsen er en indstilling som jeres risikoejer styrer, ikke kode.

  • Et nødstop som nogen må bruge

    Hver agent og hvert værktøj kan stoppes af en navngivet rolle uden en ny udrulning, og proceduren bliver øvet.

  • Menneskelig prøvelse af afgørelser om personer

    Hvor et resultat berører en enkeltperson, gennemgår en person det, og den berørte kan bede om den gennemgang.

  • Eskalering til et navngivet team

    Usikre eller fejlede kørsler går til et team der ejer dem, aldrig til en postkasse som ingen holder øje med.

07 Eksempel

Et illustrativt eksempel

Eksempel

Fakturaafvigelser hos en grossist

01Udgangspunkt
En grossist med selskaber i Danmark og Sverige modtager tusindvis af leverandørfakturaer om måneden. Fakturaer der ikke passer med en indkøbsordre, ligger i en kø i dagevis, mens bogholderiet jagter indkøberne på e-mail.
02Det ville vi bygge
En agent samler ordre, varemodtagelse og aftalevilkår, skriver et udkast til en løsning og en besked til indkøberen og foreslår posteringen gennem afgrænsede værktøjer i ERP-systemet.
03Her beslutter mennesker
Posteringer over et beløb der er fastsat pr. selskab, kræver to godkendelser. Alt der berører en leverandørs bankoplysninger, bliver aldrig automatiseret.
04Det ville vi måle
Antal dage en afvigelse er åben, andelen af forslag der godkendes uden ændringer, og tiden brugt pr. afvigelse.

08 Brancher

I din branche

  • Finansiel sektor

    Skader, kundeoprettelse og betalingsundtagelser håndteret af agenter med beløbsgrænser, firøjneprincip og revisionseksport i et format aftalt med jeres revision.

  • Offentlig sektor

    Forberedelse af sager hvor agenten samler og skriver udkast, og sagsbehandleren træffer afgørelsen, med hvert trin registreret til brug ved klager og genoptagelse.

  • Industri & produktion

    Ordreændringer, opfølgning hos leverandører og serviceanmodninger på tværs af ERP og e-mail, med godkendelse dér hvor der bindes penge eller kapacitet.

Danmark

Automatisering hvor sagsbehandleren afgør

AI-forordningen og GDPR’s regler om automatiske afgørelser gælder i hele EU. I Danmark supplerer lov nr. 467 af 14. maj 2025 forordningen med Digitaliseringsstyrelsen, Datatilsynet og Domstolsstyrelsen som nationale kompetente myndigheder (status november 2026). I en kommune eller en styrelse betyder det i praksis at agenten forbereder sagen, og en sagsbehandler træffer afgørelsen.

Vi bygger én orkestrering og ét revisionsspor, og gør godkendelsesgrænser, sprog og eskaleringsveje konfigurerbare pr. organisation eller enhed. Den ansvarlige for risiko ser og godkender de indstillinger der gælder for borgere, kunder og medarbejdere.

Spørgsmål om AI-agenter og automatisering

Hvordan vælger I mellem en agent og et almindeligt workflow?

Hvis trinnene er kendte og input er struktureret, er et workflow billigere, hurtigere og lettere at revidere. En agent giver mening, hvor input varierer, vejen afhænger af hvad der bliver fundet, og en person kan kontrollere resultatet. De fleste systemer i drift kombinerer begge dele.

Hvad forhindrer en agent i at gøre noget den ikke må?

Den kan kun handle gennem værktøjer, hvert værktøj kører under sin egen afgrænsede identitet, og gatewayen håndhæver grænser ved hvert kald. Skrivehandlinger med konsekvens venter på godkendelse. Ikke-betroet indhold kan ikke ændre de regler.

Vi bruger allerede RPA. Skal vi smide det ud?

Nej. Robotter på gamle skærmbilleder fortsætter, hvor der ikke findes et API. Vi tilføjer agenter til de trin der kræver vurdering, bruger process mining til at finde de skrøbelige robotter og erstatter dem med API-integrationer, når de underliggende systemer tillader det.

Hvordan måler I succes?

På gennemløbstid, andelen af undtagelser, omarbejde og den tid medarbejderne bruger på undtagelser, målt mod et udgangspunkt fra før idriftsættelse. Automatiseringsgraden alene skjuler for meget.

Kan intern revision eller en tilsynsmyndighed se hvad der skete?

Ja. Hver kørsel kan afspilles fra loggen: input, hentet kontekst, modeloutput, værktøjskald og godkendelser. Eksportformaterne aftales med jeres revision før idriftsættelse.

Kom med den proces der giver dit team mest arbejde

Vi kortlægger hvor en agent hjælper, hvor et workflow er nok, og hvor en person skal beslutte, før noget bliver bygget.

Tal med os om dit projektLæs om borger- og kundeservice