AI-baseret optimering af arbejdsgange i virksomheder: Fra arkitektur til skalering

Hvad er AI-baseret optimering af arbejdsgange i en tid med AI-agenter?

AI-baseret optimering af arbejdsgange er en grundlæggende omlægning af forretningsprocesser, så de udnytter autonome agenter og maskinlæring. Det rækker langt ud over simpel automatisering af opgaver. Det kræver, at man kortlægger komplekse muligheder, hvor AI skaber voksende værdi over tid.

Det er i det uudnyttede potentiale, de store gevinster ligger.

Lægger du en model oven på en proces, der ikke fungerer, får du bare en proces, der ikke fungerer, lidt hurtigere. Gentænker du derimod processen ud fra det, modellen er god til, får du en helt ny måde at drive forretningen på.

På arkitekturniveau omfatter AI-baseret optimering af arbejdsgange følgende:

• Opdeling af processer: Del hver arbejdsgang op i særskilte, målbare trin, som en agent kan udføre eller vurdere.
• Orkestrering af agenter: Fordel opgaver mellem specialiserede agenter ud fra kontekst, omkostninger og tærskler for sikkerhed i vurderingen.
• Menneskelig kontrol: Fastlæg præcist, hvornår mennesker skal gennemgå, godkende eller gribe ind i agenternes beslutningsforløb.
• Feedbacksløjfer: Registrér menneskelige rettelser, og brug dem til finjustering af modeller eller optimering af prompts.

Diagrammet nedenfor viser, hvordan de tilpassede arbejdsgange fordeler arbejdet mellem agenter og mennesker:

For at omsætte det til drift bør din implementeringstjekliste omfatte:

• [ ] Kortlæg de nuværende arbejdsgange med tidsstempler og omkostning pr. trin
• [ ] Find komplekse trin, hvor agenter klarer sig bedre end regelbaseret logik
• [ ] Fastlæg tærskler for, hvornår agenter kan handle selvstændigt, og hvornår mennesker skal gennemgå arbejdet
• [ ] Sørg for at registrere feedback, hver gang et menneske tilsidesætter en agents beslutning
• [ ] Mål omkostninger, svartid og nøjagtighed for hvert agentkald
• [ ] Gennemgå hvert kvartal, hvilke opgaver agenterne må håndtere

De organisationer, der klarer sig bedst lige nu, er ikke dem med flest modeller.

Det er dem, der har gentænkt deres arbejdsgange mest bevidst.

Trin 1: Gennemgå eksisterende processer for komplekse muligheder med AI

De fleste virksomheder begynder med det forkerte spørgsmål: "Hvor kan vi tilføje AI?" Det rigtige spørgsmål er: "Hvilke processer er mest komplekse og mindst automatiserede i dag, og hvad koster det os?" AI-baseret optimering af arbejdsgange begynder med en kompromisløs, datadrevet gennemgang af alle dine operationelle arbejdsgange.

De øvrige 66% eksperimenterer stadig, og forskellen mellem de to grupper er kvaliteten af deres gennemgang. Du kan ikke optimere noget, du ikke har kortlagt.

Vi bruger en struktureret metode til at gennemgå processer.

Sådan gør vi helt konkret:

1. Udtræk hændelseslogge fra dine ERP-, CRM- og ticketsystemer. Hent alle tidsstempler, aktører og statusændringer fra de seneste 90 dage.
2. Genskab den faktiske arbejdsgang ved hjælp af procesmining. Den dokumenterede proces og den reelle proces er næsten aldrig den samme.
3. Klassificér hvert trin efter kompleksitet (regelbaseret eller vurderingsbaseret) og hyppighed (høj eller lav volumen).
4. Vurdér AI-potentialet ved at gange kompleksitetens vægt med hyppigheden. Komplekse trin, der udføres ofte, er de vigtigste mål.
5. Beregn den nuværende omkostning pr. trin ud fra de samlede personaleomkostninger og omkostningerne ved at rette fejl.

Vi anbefaler tekniske teams at kortlægge arbejdsgange programmatisk.

Her er et enkelt eksempel med Python 3.12 og LangChain v0.2, der klassificerer procestrin efter deres AI-potentiale:

from langchain_core.prompts import ChatPromptTemplate
from langchain_openai import ChatOpenAI
from pydantic import BaseModel, Field
from typing import Literal


class StepClassification(BaseModel): step_name: str = Field(description="The workflow step being classified") complexity: Literal["rules-based", "judgment-based", "hybrid"] = Field( description="Whether the step follows fixed rules or requires human judgment" ) frequency: int = Field(description="Number of occurrences per month") ai_opportunity_score: float = Field( description="Score from 0.0 to 1.0 indicating AI replacement potential" )


llm = ChatOpenAI(model="gpt-6-luna", temperature=0)
structured_llm = llm.with_structured_output(StepClassification)


prompt = ChatPromptTemplate.from_messages([ ("system", "You are a process auditor. Classify workflow steps for AI replacement potential."), ("human", "Step name: {step_name}\nDescription: {description}\nMonthly volume: {volume}"), ])


chain = prompt | structured_llm


result = chain.invoke({ "step_name": "Invoice exception handling", "description": "Review flagged invoices, determine cause, route to correct department or vendor", "volume": 3400 })


print(f"Score: {result.ai_opportunity_score} | Complexity: {result.complexity}")

Gennemgangen skal afdække tre ting: de samlede procesomkostninger, fejlprocenten og gennemløbstiden. Uden alle tre gætter du. Komplekse trin, der udføres tusindvis af gange om måneden, er dér, AI-baseret optimering af arbejdsgange giver et voksende afkast i takt med volumen.

Trin 2: Planlæg, hvad der skal bygges eller købes, og hvordan det skal styres

Alle projekter med AI-baseret optimering af arbejdsgange står over for det samme valg: Skal man bygge en skræddersyet arkitektur med AI-agenter eller købe et færdigt SaaS-værktøj til arbejdsgange?

Svaret afhænger af arbejdsgangens kompleksitet, hvor følsomme dataene er, og hvor meget arbejdsgangen adskiller din virksomhed fra konkurrenterne.

Væksten drives i høj grad af beslutninger om at bygge selv, fordi IT-teams ønsker kontrol over agenternes adfærd og datastrømme. Men det er ikke altid det rigtige valg. Det er hurtigere og billigere at købe, og til standardprocesser er det ofte tilstrækkeligt.

Her er vores beslutningsramme:

Uanset hvilken vej du vælger, er styring ikke til forhandling. Autonome agenter, der træffer forretningsbeslutninger, har brug for klare rammer. Her er den styringsmodel, vi implementerer:

• Registrering af agenter: Hver agent får et unikt ID, en ansvarlig ejer, et beskrevet formål og et sæt godkendte handlinger.
• Lister over tilladte handlinger: Agenter må kun kalde forhåndsgodkendte API'er og værktøjer. De må ikke bruge værktøjer uden afgrænsning.
• Revisionslogning: Alle agentbeslutninger, input, output og menneskelige tilsidesættelser logges med tidsstempler.
• Begrænsning af kald: Sæt en grænse for, hvor ofte agenter må køre, så omkostninger ikke løber løbsk, og fejl ikke breder sig.
• Kriterier for eskalering til mennesker: Fastlæg tærskler for sikkerhed i vurderingen, hvorunder agenter skal overdrage opgaven til et menneske.
• Kvartalsvis adgangsgennemgang: Gennemgå hver agents tilladelser og handlingsmuligheder igen hver 90 dage.

Her er et eksempel på data til registrering af en agent i JSON:

{
 "agent_id": "inv-exception-001",
 "name": "Invoice Exception Handler",
 "owner": "finance-ops@example.com",
 "purpose": "Classify and route invoice exceptions to correct department",
 "approved_actions": ["read_invoice", "classify_exception", "route_to_department"],
 "confidence_threshold": 0.85,
 "max_calls_per_hour": 500,
 "human_escalation": true,
 "review_cycle_days": 90
}

Styring kan forsinke arbejdet, hvis godkendelsesforløbet er dårligt indrettet, men manglende kontrol skaber sine egne forsinkelser og hændelser. Fastlæg krav til tilladelser, logning, eskalering og tilbagerulning i pilotprojektet, og mål derefter, hvordan de påvirker leveringstiden.

Det anderledes synspunkt: Hvorfor AI uden gentænkning af jobfunktioner er dømt til at mislykkes

Den gængse fortælling er, at AI-værktøjer øger produktiviteten, blot fordi medarbejderne får adgang til dem. Dataene viser noget andet. Mere adgang og uændrede jobfunktioner giver kun beskedne gevinster.

Derfor mislykkes de fleste projekter med AI-baseret optimering af arbejdsgange. Du giver medarbejderne et værktøj, men ændrer ikke måden, deres arbejde er tilrettelagt på. Værktøjet bliver en hjælp i hverdagen, ikke en grundlæggende forandring.

Tag et team, der behandler forsikringskrav. Du giver dem en AI-assistent, som udfylder felter i en skadesanmeldelse på forhånd ud fra dokumenter. Hvis jobbet stadig kræver manuel gennemgang af hvert felt, sparer AI måske 10% af deres tid.

Men hvis du ændrer jobbet, så mennesker kun gennemgår anmeldelser, hvor agentens sikkerhed i vurderingen ligger under en bestemt tærskel, reducerer du behandlingstiden med 60% eller mere. Samme værktøj. Anderledes tilrettelagt arbejde.

Seks gange så stor effekt. Det kræver følgende at gentænke jobfunktioner til AI:

• Fjernelse af opgaver: Fjern opgaver, som agenter nu håndterer fuldt ud. Behold dem ikke som menneskeligt "backup-arbejde".
• Nye roller: Flyt menneskers arbejde fra udførelse til tilsyn, håndtering af undtagelser og træning af agenter.
• Nye mål: Hold op med at måle medarbejdere på antallet af udførte opgaver. Mål dem på kvaliteten af deres håndtering af undtagelser og forbedringer i agenternes præstation.
• Kompetenceudvikling: Lær medarbejderne at skrive effektive prompts, vurdere agenternes output kritisk og give struktureret feedback.
• Nye arbejdsgange: Fordel arbejdet på ny, så agenter tager første gennemløb, mens mennesker tager sig af de beslutninger, der kræver en vurdering.

Forskellen i afkast mellem virksomheder, der gentænker jobfunktioner, og dem, der ikke gør, er ikke marginal. Den er strukturel.

I en hypotetisk omlægning af behandlingen af forsikringskrav kunne kun undtagelser med høj risiko sendes til en sagsbehandler i stedet for, at hvert felt skal gennemgås. Test ændringen på historiske sager, fastlæg omkostningerne ved falske positiver og falske negativer, og offentliggør kun resultater fra det faktiske pilotprojekt.

Du kan ikke sætte AI på en jobstruktur fra det 20. århundrede og forvente resultater, der hører det 21. århundrede til.

Trin 3: Flyt AI-arbejdsgange fra eksperimentel PoC til produktion

Overgangen fra sandkasse til produktion er dér, hvor de fleste initiativer til AI-baseret optimering af arbejdsgange går i stå. Det betyder, at næsten to tredjedele stadig sidder fast i pilotfasen.

For at sætte løsningen i produktion skal du træffe tre arkitekturbeslutninger: inferensinfrastruktur, omkostningsstyring og observerbarhed.

Få styr på alle tre, ellers bliver løsningen i sandkassen.

Her er vores tjekliste til overgangen til produktion:

1. Erstat direkte API-kald med batchbaseret inferens, hvor det er muligt, for at reducere omkostningen pr. token med 40%, en betydelig besparelse.
2. Brug vLLM til selvhostet inferens i arbejdsgange med høj volumen, så du helt undgår priser pr. token.
3. Brug Ray til distribueret orkestrering af agenter, så du kan skalere horisontalt uden at omskrive agentlogikken.
4. Indfør circuit breakers for hvert agentkald, så fejl ikke breder sig gennem systemet.
5. Opret omkostningsdashboards i realtid, der viser forbruget pr. arbejdsgang, pr. agent og pr. kald.
6. Fastlæg SLO'er for agenternes svartid og nøjagtighed, og knyt dem til alarmer.

Her er en minimal Ray Serve-konfiguration til at sætte en agentarbejdsgang i drift i stor skala:

# ray_agent_deploy.py
# Requires: ray[serve]>=2.10, vllm>=0.5, fastapi
import ray
from ray import serve
from vllm import LLM, SamplingParams


ray.init()


@serve.deployment(num_replicas=4, ray_actor_options={"num_gpus": 1}) class WorkflowAgent: def __init__(self): self.llm = LLM( model="meta-llama/Llama-3.3-70B-Instruct", tensor_parallel_size=1, gpu_memory_utilization=0.90, max_model_len=8192, ) self.params = SamplingParams(temperature=0.1, max_tokens=512)


 async def __call__(self, request): prompt = await request.json() prompt_text = prompt.get("task", "") outputs = self.llm.generate([prompt_text], self.params) return {"result": outputs.outputs.text}


app = WorkflowAgent.bind()

Og en vLLM-konfiguration til inferens med styr på omkostningerne:

# vllm serve command for production agent inference
python -m vllm. entrypoints. openai. api_server \
 --model meta-llama/Llama-3.3-70B-Instruct \
 --tensor-parallel-size 4 \
 --gpu-memory-utilization 0.90 \
 --max-model-len 8192 \
 --enable-chunked-prefill \
 --max-num-seqs 256 \
 --port 8000

Ved 2 millioner kald om måneden svarer det til $0.006 pr. kald mod $0.015-0.060 pr. kald hos udbydere af hostede API'er. Sammenlignet med en premium-API nås break-even ved cirka 200.000 kald om måneden.

De arkitekturbeslutninger, du træffer i PoC-fasen, afgør, om løsningen kan fungere i produktion.

Hvordan måler du præcist afkastet af at redesigne arbejdsgange med AI?

De fleste organisationer kan ikke måle afkastet af AI-baseret optimering af arbejdsgange præcist, fordi de følger de forkerte tal. De måler, hvor mange der tager værktøjerne i brug, og hvor tilfredse brugerne er. I stedet bør de måle omkostning pr.

inferens, ændringer i kapacitet og reduktion i manuelt arbejde.

En undersøgelse fra Capgemini Research Institute i 2025 viste, at 40% af de organisationer, der målte afkast, forventede et positivt afkast inden for et til tre år. Tallene giver en pejling. Dine egne tal skal være præcise.

Her er den model, vi bruger til at beregne afkast:

1. Omkostning pr. inferens: Samlede inferensomkostninger divideret med det samlede antal agentkørsler. Følg tallet månedligt.
2. Ændring i kapacitet: Antal opgaver løst pr. time før og efter implementeringen af AI-arbejdsgangen.
3. Reduktion i manuelt arbejde: Antal sparede arbejdstimer værdisat til den samlede timeomkostning for arbejdskraft.
4. Ændring i fejlrate: Fejlraten før og efter AI, sammenholdt med omkostningen pr. fejl.
5. Kortere gennemløbstid: Tiden fra en opgave sættes i gang, til den er afsluttet, målt i arbejdstimer.
6. Tid til break-even: Samlet implementeringsomkostning divideret med den månedlige nettobesparelse. Hvis nettobesparelsen er nul eller negativ, nås break-even aldrig.

Følgende tænkte eksempel bygger på en fast månedlig opgavemængde og de angivne omkostninger.

Tag en arbejdsgang til håndtering af afvigelser i fakturaer:

Månedlig volumen: 3.400 afvigelser Manuel omkostning: 3.400 afvigelser × (12 minutter / 60) × $45/time i samlet arbejdskraftomkostning = $30,600/måned Fordeling af automatiserede omkostninger: - Selvhostet inferens med vLLM: 3.400 kald × $0.006 = $20.40/måned - Cloud-GPU-node (delt): $3,000/måned allokeret - Platform til orkestrering af agenter: $1,200/måned - Menneskelig gennemgang (15% eskalering): 510 gennemgange × (8 minutter / 60) × $45/time = $3,060/måned - Samlet automatiseret omkostning: $7,280.40/måned Månedlig besparelse: $30,600 - $7,280.40 = $23,319.60 Implementeringsomkostning: $85,000 (udvikling, test, idriftsættelse) Break-even: $85,000 / $23,319.60 = 3,6 måneder

Det afgørende er, at afkast ikke er ét tal. Det udvikler sig over tid. Den første måned er afkastet negativt.

I måned fire nås break-even. I måned tolv er nettoafkastet efter implementeringsomkostningen omkring 2,3 gange investeringen. Følg udviklingen, ikke kun et øjebliksbillede.

Organisationer, der kun måler ved idriftsættelsen og efter et år, overser vendepunktet og lukker projekter for tidligt.

Konkrete eksempler på optimering af arbejdsgange på tværs af brancher

Forsyningskæder og logistik giver det tydeligste belæg for, at AI-baseret optimering af arbejdsgange skaber målbare resultater.

Hvad betyder det i praksis? En mellemstor logistikvirksomhed med 200 lastbiler på vejene hver dag har tre flaskehalse: ruteoptimering, efterspørgselsprognoser og håndtering af afvigelser. De har hver deres omkostningsprofil og potentiale for AI.

Ruteoptimering: Før AI tilpasser disponenter ruter manuelt efter trafik, vejr og leveringsvinduer. Når agenten er sat i drift, optimerer en ruteagent løbende ruterne for alle 200 lastbiler. Transportomkostningerne falder 25%, fordi der køres færre kilometer uden last, og brændstoffet udnyttes bedre.

Efterspørgselsprognoser: Traditionelle prognoser bygger på historiske gennemsnit justeret for sæsonudsving. AI-baserede prognosemodeller inddrager signaler i realtid: vejr, lokale begivenheder, økonomiske indikatorer og konkurrenters priser. Forbedringen i nøjagtighed på 85% betyder, at lageromkostningerne falder markant, fordi du lagerfører det, du har brug for, frem for det, du gætter på.

Håndtering af afvigelser: Når en forsendelse bliver forsinket, sætter den gamle arbejdsgang en telefonkæde i gang. I den optimerede arbejdsgang omdirigerer en agent automatisk forsendelsen, giver kunderne besked og opdaterer de forventede ankomsttider. Driftsomkostningerne falder 23%, fordi andelen af afvigelser, der kræver menneskelig indgriben, falder fra 100% til cirka 15%.

Mønstret er det samme i alle eksemplerne. AI-baseret optimering af arbejdsgange forbedrer ikke kun ét nøgletal. Gevinsterne forstærker hinanden på tværs af hele forsyningskæden.

Ruteoptimering leverer data til efterspørgselsprognoserne. Mere præcise prognoser giver færre afvigelser. Færre afvigelser kræver mindre menneskelig indgriben, og hver forbedring gør den næste billigere.

Det er ikke teoretiske fremskrivninger. Data fra Capgemini i 2026 bekræfter disse omkostningsreduktioner i AI-systemer, der er sat i drift i forsyningskæder. Virksomhederne bag resultaterne har redesignet arbejdsgangene, ikke kun deres dashboards.

Fremtidens arbejde: Bliv klar til systemer med flere agenter

Skiftet fra arbejdsgange med én agent til systemer med flere agenter går hurtigere, end de fleste virksomheder er klar til.

Systemer med flere agenter ændrer regnestykket for AI-baseret optimering af arbejdsgange. I stedet for at én agent håndterer hele arbejdsgangen, arbejder specialiserede agenter sammen. En researchagent indsamler data.

En analyseagent vurderer mulighederne. En beslutningsagent anbefaler handlinger. Et menneske gennemgår anbefalingen.

Hver agent er mindre, billigere og mere pålidelig end én stor agent, der forsøger at klare det hele.

Infrastrukturen skal udvikles, så den kan understøtte det.

Her er, hvad driftsansvarlige bør bygge nu:

• Protokoller for kommunikation mellem agenter: Definér, hvordan agenter deler kontekst, overdrager opgaver og eskalerer til hinanden.
• Systemer med fælles hukommelse: Giv agenterne adgang til fælles tilstand, så de ikke udfører det samme arbejde eller modsiger hinanden.
• Orkestreringslag: Sæt en routingagent eller orkestrator i drift til at fordele opgaver og løse konflikter.
• Omkostninger fordelt på den enkelte agent: Følg forbruget pr. agent, ikke kun pr. arbejdsgang.
• Forebyggelse af kaskadefejl: Hvis én agent fejler, skal systemet fortsætte med begrænset funktionalitet i stedet for at bryde sammen.

Den kulturelle omstilling er lige så vigtig. Medarbejderne skal forstå, at deres rolle skifter fra selv at udføre arbejdet til at styre de agenter, der udfører det. Det er ikke en lille justering. Det ændrer grundlæggende menneskers forhold til de operationelle processer.

Microsoft og andre platformudbydere bygger muligheder for orkestrering af agenter direkte ind i deres løsninger til virksomheder, og det vil sætte fart på udbredelsen. Men de organisationer, der klarer sig bedst, bliver dem, der forbereder deres arbejdsgange, styring og medarbejdere på systemer med flere agenter, før værktøjerne kommer, ikke bagefter.

Udviklingen er tydelig. Arbejdsgange med én agent er nutidens optimering. Systemer med flere agenter bliver morgendagens udgangspunkt. Afstanden mellem dem, der er længst fremme, og dem, der halter efter, vil vokse markant i løbet af de næste 18 måneder.