Det spørgsmål, de fleste ikke har stillet sig selv.
Hvilke opgaver er vi holdt op med at automatisere, fordi det aldrig betalte sig? Og er den beregning stadig rigtig?
Anders Kloster Nannerup
Senior Manager
I mange organisationer er der en kategori af manuelle driftsopgaver, der aldrig er blevet automatiseret – ikke fordi de er svære, men fordi klassiske integrationsprojekter var for dyre og for skrøbelige til at det kunne betale sig. Opgaverne bliver i stedet håndteret manuelt. De gentager sig. De binder tid. De skaber afhængighed af nøglepersoner. Og de er for sjældent synlige nok til, at nogen prioriterer at løse dem.
Det er den kalkule, som AI-agenter er ved at ændre.
En agent er interessant, når den ikke kun kan svare på spørgsmål, men også udføre konkrete handlinger i virksomhedens systemer. Det kan være at oprette en bruger, ændre en rettighed, lukke en sag, starte en synkronisering eller hente en status på tværs af platforme. Her er Model Context Protocol – MCP – en vigtig brik. MCP gør det muligt at udstille de handlinger, agenten må bruge, på en sikker og kontrolleret måde.
MCP er en åben standard, der gør det muligt for AI-agenter og chatbots at udføre afgrænsede handlinger i virksomhedens systemer. I stedet for at bygge fulde integrationer udstiller man et sæt klart definerede handlinger – find en bruger, opdater en rettighed, hent en status. Agenten har kun adgang til det, der eksplicit er tilladt, og alle handlinger kan logges og kontrolleres.
Et gennemgående mønster i drift- og platformteams er håndtering af brugere og rettigheder. Når en medarbejder skifter rolle, projekt eller team, skal adgange justeres på tværs af systemer – CMS, PIM, e-commerce platforme, supportværktøjer og interne administrationssystemer.
Opgaven er sjældent kompleks. Men den kræver en teknisk medarbejder, og den gentager sig.
En onboarding-proces der involverer tre systemer tager typisk en teknisk medarbejder 20–30 minutter. I en organisation med 50 onboardinger om måneden er det 25–37 timers teknisk tid. Hertil kommer fejl ved manuelle indtastninger, forsinkelser ved nøglepersonsfravær og den grundlæggende risiko ved rettigheder, der ikke er sat korrekt.
Det er ikke en enkelt stor omkostning – det er en vedvarende friktion, der sjældent optræder på et dashboard, men er der hele tiden.
Med MCP kan denne type opgave håndteres af en agent – fx via Microsoft Teams – med adgang til et begrænset sæt veldefinerede handlinger: find bruger, opdater rettighed, fjern adgang, log ændringen. Den samme proces klares på under to minutter. Agenten udfører kun de handlinger, den eksplicit er givet lov til, og intet andet – og rapporterer tilbage, når det er udført.
Den samme tilgang gælder for selvbetjeningsscenarier: agenter der i dag kun kan svare på generelle spørgsmål, kan med MCP slå konkrete data op og udføre afgrænsede ændringer – uden at der skal bygges en ny integration for hver funktion.
Mange MCP-løsninger fungerer i en prototype og fejler i drift. Tre principper adskiller de løsninger, der holder.
Handlinger bør svare til det, en erfaren medarbejder ville gøre.
Handlinger, der direkte afspejler tekniske API-kald, tvinger agenten til at navigere i detaljer og rækkefølger, der er irrelevante for opgaven. Det øger fejlraten og gør løsningen dyr at vedligeholde. Handlingerne bør repræsentere klare forretningsbeslutninger med validering indbygget.
Få og klart adskilte handlinger giver mere forudsigelig adfærd.
Overlappende handlinger er den klassiske kilde til ustabilitet. Hvis det ikke er åbenlyst, hvilken handling der gælder i en given situation, opfører agenten sig uforudsigeligt og bliver sværere at styre. Et begrænset, entydigt handlingssæt er lettere at teste og vedligeholde.
Agenter arbejder bedre med præcis information end med store mængder.
En agent, der præsenteres for for meget eller forkert kontekst, leverer over tid dårligere resultater – på samme måde som et menneske, der skal gennemgå hundredevis af elementer manuelt. Målrettede opslag fungerer langt bedre end brede forespørgsler.
Governance stiller de samme krav til agenter som til menneskelige brugere: tydelig adgangsstyring, konsekvent logging og audit trail, og sikre stopmekanismer. Mangler disse mekanismer, er konsekvensen sjældent et dramatisk sammenbrud – men en gradvis erosion af sporbarhed og kontrol, der gør løsningen for usikker til produktion.
MCP er ikke universelt. Det løser et specifikt problem – veldefinerede handlinger udført af AI – og det kræver, at opgaverne faktisk er veldefinerede.
MCP er typisk det forkerte valg, når:
Opgaven kræver kompleks forretningslogik og situationsvurdering. Hvis en erfaren medarbejder ville bruge tid på at vurdere konteksten, er MCP ikke det rigtige lag at løse det på.
Systemerne ikke er stabile og veldokumenterede. MCP-handlinger er afhængige af, at de underliggende systemer opfører sig forudsigeligt. Ustabile API'er eller systemer under aktiv udvikling giver en skrøbelig løsning.
Datakvaliteten er lav. Agenter er afhængige af strukturerede, pålidelige data. Inkonsistente eller mangelfulde data fører til fejl, der er svære at opdage og rette.
Der ikke er klar ejerskab til at definere og vedligeholde handlingssættet. MCP-løsninger kræver løbende vedligeholdelse, efterhånden som systemer og processer ændrer sig.
Det er ikke argumenter for at undgå MCP – det er kriterier for at vurdere, hvornår en investering reelt giver mening.
MCP skaber hurtigst værdi på opgaver, der involverer manuelle trin på tværs af to eller flere systemer, udføres af tekniske medarbejdere selvom de ikke kræver teknisk vurdering, og sker med høj frekvens og lav forretningsmæssig risiko.
Brugeradministration, rettighedsjusteringer og statusopslag er klassiske eksempler.
En typisk vej frem starter med at kortlægge de opgaver, organisationen holdt op med at automatisere – og vurdere, om kalkulen er ændret. Dernæst identificeres et afgrænset område med høj frekvens og lav risiko. Herefter defineres handlingssættet, den nødvendige governance sættes op, og løsningen sættes i drift.
Det er præcis det, Immeo hjælper med – fra den indledende vurdering af hvilke processer der giver mening at automatisere (Advisory), til design og implementering af MCP-setup (Build), til drift og videreudvikling (Run). Ikke som en isoleret teknisk leverance, men som en del af en bredere indsats for at reducere den friktion, der kendetegner travl drift.
