RPA klikker. AI-agenter fortolker. Det er den korteste sande beskrivelse af forskellen, og den forklarer det meste af, hvad de hver især er gode og dårlige til. RPA — Robotic Process Automation — er software, der efterligner en medarbejders handlinger i et system, mens en AI-agent forstår indhold og træffer en vurdering.
Dansk Industri formulerer det præcist i deres egen gennemgang: en RPA er ikke en kunstig intelligens, men en robot. Den lærer ikke selv, den gør det, du har bedt om, på præcis den måde. Denne guide gennemgår hvornår hver af de to er det rigtige valg for en dansk SMV — og hvorfor svaret i 2026 oftest er, at I skal bruge begge dele til hver sin del af opgaven.
RPA (Robotic Process Automation): Software der betjener andre programmers brugerflade som et menneske ville — åbner, klikker, taster, kopierer. Den er regelbunden og forudsigelig, og den er skrøbelig over for ændringer i det, den betjener.
Hvad er RPA, og hvad er RPA-løsninger gode til?
En RPA-robot er sat op til en fast rutine: åbn det gamle økonomisystem, find posten, kopier beløbet, skift til det andet system, indsæt, gem. Den ser ikke systemet som data — den ser det som en skærm.
Det lyder primitivt, og det er det også. Men det er præcis derfor, RPA stadig løser et reelt problem: den kan betjene systemer, der ikke har noget API. Og mange danske virksomheder kører kritiske processer i systemer, hvor der ikke er nogen anden dør ind.
RPA er stærk på fire punkter:
- Forudsigelighed. Samme input giver samme output. Hver gang.
- Revisionsvenlighed. Man kan læse robottens trin og sige præcis, hvad den gjorde. Det tæller i regulerede brancher.
- Ingen krav til systemet. Leverandøren behøver hverken vide det eller understøtte det.
- Hurtig at bygge til en simpel rutine. Dage, ikke måneder.
Og svag på tre:
- Skrøbelighed. Flytter leverandøren en knap i en opdatering, går robotten i stå. Uvarslet.
- Ingen tolerance for variation. Ser fakturaen anderledes ud end forventet, stopper den.
- Kan ikke læse. En robot kan kopiere et felt, men ikke forstå, hvad der står i et brev.
Hvad AI-agenter gør anderledes
En AI-agent arbejder på indhold i stedet for på skærmbilleder. Den kan læse en mail og udlede, hvad kunden vil have. Den kan se på tyve forskellige fakturalayouts og finde beløbet i dem alle. Den kan sammenfatte en sagsmappe.
Styrken er variation. Svagheden er den samme egenskab set fra den anden side: den kan svare forskelligt på det samme spørgsmål. Det er acceptabelt, når den foreslår et udkast til et menneske, og problematisk, når den bogfører uden opsyn.
Vi har behandlet, hvordan agenter bygges og hvor de fejler, i guiden til AI-agenter i virksomheden. Her er pointen alene, hvordan de står i forhold til RPA.
RPA vs AI-agenter: sammenligningen
| RPA | AI-agent | |
|---|---|---|
| Arbejder på | Skærmbilleder og faste felter | Indhold og betydning |
| Input | Struktureret, ensartet | Ustruktureret, varieret |
| Samme input to gange | Samme svar | Kan give forskelligt svar |
| Går i stykker når | Brugerfladen ændres | Materialet er modstridende |
| Egnet til revision | Ja — trinene kan læses | Sværere — svaret skal begrundes |
| Kan læse et brev | Nej | Ja |
| Kan taste i et gammelt system | Ja | Kun via RPA eller integration |
| Typisk vedligehold | Højt og uforudsigeligt | Moderat, men kræver dataopsyn |
Læg mærke til, at de to kolonner næsten ikke overlapper. Det er ikke tilfældigt, og det er hele grunden til, at spørgsmålet “RPA eller AI?” som regel er stillet forkert.
Derfor er svaret oftest begge dele
De fleste virkelige processer i en dansk SMV har to halvdele: noget skal forstås, og noget skal indtastes.
Tag en typisk leverandørfaktura. Den ankommer som PDF i en mailboks. Beløb, dato, leverandør og kontering skal udledes — det er fortolkning. Derefter skal tallene ind i økonomisystemet — det er indtastning.
Den holdbare opdeling ser sådan ud:
- AI læser dokumentet og afleverer et struktureret resultat: leverandør, beløb, dato, forslag til konto.
- Et menneske godkender undtagelserne — det, AI’en er usikker på.
- RPA eller en integration taster det godkendte ind i systemet.
Hvert led gør det, det er bedst til. Og lige så vigtigt: når noget går galt, er det til at se hvor. Bygger man i stedet én stor AI-agent, der både læser og taster, bliver fejlfinding et gættespil.
Den dyreste automatiseringsfejl vi rydder op efter, er ikke at have valgt det forkerte værktøj. Det er at have brugt ét værktøj til begge halvdele af en opgave, der havde to.
Samme princip ligger bag den tilgang, vi beskriver i guiden til automatiseret fakturahåndtering.
AI-AG’s 3 spørgsmål, der afgør valget
Stil dem i denne rækkefølge:
- Har systemet et API? Hvis ja: brug det. Hverken RPA eller en agent er nødvendig til at flytte data. En integration er billigere og går ikke i stykker af en designopdatering.
- Er inputtet ensartet? Kommer det altid i samme format og felter, er det RPA eller integration. Varierer det — sprog, layout, formulering — skal AI læse det først.
- Hvad koster et forkert svar? Er svaret “vi opdager det og retter det”, kan AI arbejde selvstændigt. Er svaret “vi sender en forkert regning til en kunde”, skal der en godkendelse ind, uanset værktøj.
Spørgsmål 1 er det vigtigste, og det er også det, folk springer over. Vi har flere gange fjernet en RPA-robot, som en virksomhed havde levet med i to år, og erstattet den med en simpel integration — fordi ingen havde spurgt leverandøren, om der var et API.
Er I i tvivl om, hvilken halvdel jeres proces består af, er det som regel en kort samtale at afklare. Book en uforpligtende snak, så kigger vi på processen, før der bygges noget.
Et konkret eksempel fra praksis
En dansk grossistvirksomhed med omkring 45 ansatte havde en RPA-robot, der hver morgen hentede ordrer fra en kundeportal og oprettede dem i deres eget system.
Situationen: Robotten gik i stykker cirka en gang om måneden, typisk efter en opdatering af portalen. Hver gang tog det en halv til en hel arbejdsdag at få den i gang igen, og i mellemtiden blev ordrerne oprettet i hånden. Virksomheden overvejede at erstatte robotten med “noget AI”.
Handlingen: Vi stillede spørgsmål 1 først. Kundeportalen havde faktisk et API — det var bare aldrig blevet efterspurgt, fordi robotten “jo virkede”. Ordreudtrækket blev flyttet til en almindelig integration. Men en del af ordrerne kom desuden ind som fritekst i mails fra mindre kunder, og dem havde robotten aldrig kunnet håndtere. Der blev sat AI-aflæsning på, med godkendelse af alt, hvor beløb eller varenummer var usikkert.
Resultatet: Robotten blev pensioneret. Integrationen har ikke fejlet siden, fordi den ikke afhænger af, hvordan portalen ser ud. Og de fritekst-ordrer, der før blev tastet manuelt, bliver nu forberedt automatisk og godkendt på få minutter.
Bemærk, at den oprindelige idé — at erstatte RPA med AI — var forkert i begge retninger. Halvdelen af problemet skulle løses med en integration, den anden halvdel med AI. Ingen af delene var mere RPA.
Hvornår er RPA stadig det rigtige valg i 2026?
RPA er ikke død, og det er værd at være konkret om, hvornår den vinder:
- Systemet har intet API, og leverandøren vil ikke lave et. Det er den klassiske og stadig gyldige begrundelse.
- Processen er fuldstændig regelbunden, og inputtet varierer ikke.
- Sporbarhed vejer tungt. Man kan læse en RPA-robots trin som en opskrift, hvilket er en fordel i regulerede sammenhænge.
- Volumen er høj nok til at bære vedligeholdet.
Og hvornår den taber:
- Der findes et API — så brug det.
- Inputtet varierer — så skal AI læse først.
- Volumen er lav — så koster vedligeholdet mere end den manuelle proces.
Bruger I Microsoft, er RPA-delen i øvrigt allerede indenfor rækkevidde: Power Automate Desktop er RPA, mens cloud-flows er integrationer. Skelnen mellem de to er den samme som i hele denne artikel, og vi har gennemgået den i guiden til Power Automate.
Sådan griber I valget an
- Kortlæg processen i to spalter: hvad skal forstås, og hvad skal indtastes.
- Spørg efter et API til hvert system, der indgår. Spørg leverandøren direkte.
- Vælg værktøj per halvdel, ikke per proces.
- Sæt godkendelse ind, hvor et forkert svar koster noget.
- Byg den mindste version, der løser én rigtig sag, og kør den i en måned, før I udvider.
Det er den samme rækkefølge, vi anbefaler i al procesautomatisering, og trin 2 er det, der oftest sparer mest.
Opsummering
RPA og AI-agenter er ikke konkurrenter. De løser hver sin halvdel af de opgaver, danske SMV’er faktisk har.
Tre ting at tage med:
- RPA klikker, AI fortolker. Vælg efter hvilken halvdel af opgaven I står med — de fleste processer har begge.
- Spørg altid efter et API først. Både RPA og agenter er omveje udenom en manglende dør. Er døren der, er en integration billigere og mere stabil.
- Vedligehold er den skjulte omkostning ved RPA. Robotten går i stykker, når andre ændrer noget, og det varsles ikke.
Start med at dele én proces i de to spalter. Som regel bliver det tydeligt af sig selv, hvad der skal bruges hvor.
Ofte stillede spørgsmål
Hvad er RPA?
RPA står for Robotic Process Automation og er software, der efterligner en medarbejders handlinger i et IT-system: den åbner programmer, klikker på knapper, kopierer felter og taster videre. Den er ikke kunstig intelligens og lærer ikke selv — den gør præcis det, den er sat op til, hver gang. Netop derfor er den forudsigelig og velegnet til revision, men også skrøbelig over for ændringer i brugerfladen.
Hvad er forskellen på RPA og en AI-agent?
RPA udfører faste handlinger efter regler og giver samme resultat hver gang. En AI-agent fortolker input og træffer en vurdering, hvilket gør den i stand til at håndtere variation — men også til at svare forskelligt på det samme. Kort sagt: RPA er stærk til strukturerede data og faste klik, AI-agenter er stærke til ustruktureret tekst og variation. De løser hver sin halvdel af de fleste virkelige processer.
Er RPA forældet i 2026?
Nej. RPA får mindre opmærksomhed end AI, men den løser stadig et problem, AI ikke løser godt: at betjene gamle systemer uden API, forudsigeligt og revisionsvenligt. Mange danske virksomheder har systemer, hvor RPA er den eneste realistiske vej til automatisering. Det, der er forældet, er at bruge RPA til at læse dokumenter og fortolke tekst — der er AI langt bedre.
Hvad er RPA-løsninger typisk brugt til?
De klassiske anvendelser er dataoverførsel mellem systemer, der ikke taler sammen, oprettelse af poster i flere systemer på én gang, afstemninger mellem lister, og udtræk af faste rapporter. Fællestrækket er, at opgaven er kedelig, gentagen og fuldstændig regelbunden — og at det involverede system ikke har et API, man kunne bruge i stedet.
Kan man kombinere RPA og AI?
Ja, og det er som regel den rigtige løsning. Den typiske opdeling er, at AI læser og fortolker det ustrukturerede — en faktura, en mail, et scannet dokument — og afleverer et struktureret resultat, som RPA derefter taster ind i systemet. AI klarer variationen, RPA klarer klikkene. Hver del gør det, den er bedst til, og fejlene bliver lettere at finde.
Hvad koster en RPA-løsning for en dansk SMV?
Omkostningen deler sig i licens og vedligehold, og folk undervurderer systematisk det sidste. Selve robotten kan ofte bygges på få dage, men den skal repareres, hver gang systemet bag ændrer sig — og det varsles sjældent. Regn med løbende vedligehold som en fast post i budgettet. Er der et API tilgængeligt, er en almindelig integration næsten altid billigere på sigt.
Hvornår skal man vælge RPA frem for en API-integration?
Kun når der ikke er et API, eller når adgangen til det er urimeligt dyr eller langsom at få. En API-integration taler med systemets aftalte grænseflade og går ikke i stykker, fordi en knap flyttes. RPA er en omvej udenom en manglende dør. Er døren der, så brug den — vi har flere gange fjernet en RPA-robot og erstattet den med en simpel integration, der bare virkede.