RPA, arbeidsflytautomatisering og KI-agenter: hva hvert begrep betyr

Tre ord som i tilbud brukes som tre prisnivåer for én tjeneste, er tre ulike mekanismer. Hva som skiller dem, hva kjøperen får, og hvorfor skillet nå også er juridisk.

Tre ord dukker ofte opp i ett og samme tilbud som om de var tre prisnivåer for én og samme tjeneste: robotisert prosessautomatisering, arbeidsflytautomatisering og KI-agenter. For kjøperen gir det inntrykk av at man må velge ett av tre produkter, og som regel blir det dyreste valgt, fordi det høres mer moderne ut.

I virkeligheten er det tre ulike mekanismer som løser ulike problemer, og det meste av det reelle arbeidet krever nettopp den som koster minst. Denne artikkelen sammenligner ikke verktøy og anbefaler ingen plattform; den forklarer hva som skiller hver mekanisme teknisk, hva kjøperen får i hvert tilfelle, og hvorfor akkurat dette skillet de siste to årene også er blitt et juridisk spørsmål.

Tre mekanismer som svarer på tre ulike spørsmål

Den enkleste måten å holde dem fra hverandre på, er å spørre hvordan hver av dem vet hva den skal gjøre. Robotisert prosessautomatisering gjentar handlingene et menneske viste den; arbeidsflytautomatisering følger veien noen har tegnet; en KI-agent utleder veien selv ut fra et mål den har fått. Fra denne ene forskjellen følger nesten alt det andre, inkludert pris, skjørhet og det som skjer når situasjonen er uventet. Mekanismen som gjentar, stanser i en uventet situasjon; mekanismen som følger en tegnet vei, tar feilgrenen dersom en slik er forutsett; mekanismen som utleder, kommer opp med noe nytt, og nettopp derfor trenger den overvåking de to andre ikke trenger.

Prøv skillet på én konkret oppgave som ser lik ut i nesten hver bedrift: en faktura som har kommet på e-post, skal inn i regnskapssystemet. Robotisert prosessautomatisering ville løst arbeidet ved å åpne e-postprogrammet, laste ned vedlegget, åpne regnskapsvinduet og fylle ut feltene i nøyaktig den rekkefølgen en medarbeider ville gjort det. En arbeidsflyt ville løst det ved å motta dokumentet gjennom et grensesnitt og kalle grensesnittet til regnskapssystemet med ferdige felt, uten å åpne et eneste vindu. En agent ville løst det ved å motta oppgaven «bokfør denne fakturaen» og selv avgjøre hvilke verktøy den skal kalle, og hva den skal gjøre hvis noe mangler.

Alle tre variantene kan utføre denne oppgaven, og nettopp det villeder. Forskjellen viser seg ikke når alt er i orden, men når leverandøren bytter fakturamal, når det dukker opp et nytt obligatorisk felt i systemet, eller når samme vare er navngitt på to måter, og det er nettopp slike tilfeller som utgjør det meste av det reelle arbeidet.

Robotisert prosessautomatisering gjentar handlinger på skjermen

Robotisert prosessautomatisering, til daglig kalt med den engelske forkortelsen RPA, er en programvarerobot som arbeider i nøyaktig de samme grensesnittene som et menneske: den åpner et vindu, klikker, kopierer et felt, trykker lagre. Systemene den arbeider mot, blir stående helt uendret, og det er både den største fordelen og den største svakheten. Fordelen er at RPA klarer programmer som ikke har noe grensesnitt for datautveksling, og som ingen lenger kommer til å bygge om, så det er ofte den eneste veien inn i gamle regnskaps- eller fagsystemer. Svakheten er at roboten ser skjermen, ikke dataene, så enhver endring på skjermen — en flyttet knapp, et nytt felt, en annen versjon etter en oppdatering — stanser arbeidet, og vedlikeholdet blir en løpende kostnad, ikke en engangskostnad.

Kjøperen får her en lisens til roboten, kjøremiljøet og administrasjonsverktøyet, en prosessbeskrivelse og en logg over utførte handlinger. Bransjen selv anser navnet som mislykket: det RPA automatiserer, er som regel en enkelt oppgave, ikke en hel prosess, og nettopp dette misforholdet mellom navn og innhold skaper en del av kjøpernes forventninger som senere ikke blir innfridd.

Et annet trekk som ofte overrasker i RPA-prosjekter, er at roboten arbeider med det samme tilgangsnivået som mennesket den gjentar handlingene til. Det betyr at roboten trenger sin egen bruker i hvert system, at rettighetene til denne brukeren må gjennomtenkes som for enhver annen, og at robotens handlinger i systemloggen ser ut som et menneskes handlinger hvis den ikke har en egen konto. I bedrifter der dette ikke er tenkt gjennom, er det senere vanskelig å svare på det enkle spørsmålet om hvem som gjorde den konkrete registreringen.

Arbeidsflytautomatisering kobler systemer, ikke skjermer

Arbeidsflytautomatisering arbeider ett lag dypere: den snakker ikke med skjermen, men med systemene selv, gjennom programvaregrensesnittene deres. En arbeidsflyt er en ferdigtegnet graf over steg — en hendelse utløser en kjede, kjeden kaller handlinger i andre systemer, og mellom dem kan det også være et steg der et menneske skal godkjenne noe. Fordi datautvekslingen går gjennom et grensesnitt, ikke gjennom et bilde, påvirker ikke endringer i systemets utseende denne mekanismen, og det er hovedgrunnen til at der grensesnittet er tilgjengelig, er denne løsningen nesten alltid mer robust og billigere å vedlikeholde enn å gjenta skjermen. Mangelen er åpenbar: har systemet ikke noe grensesnitt, eller er det ikke tilgjengelig på lisensnivået ditt, finnes denne veien rett og slett ikke.

Kjøperen får her selve arbeidsflyten, tilgangsdata, kjørelogg og feilgren, og det er nettopp den siste det lønner seg å vurdere et tilbud etter, fordi en arbeidsflyt uten feilhåndtering bare virker så lenge alt er i orden. På norsk har denne mekanismen sitt eget ord: arbeidsflyt er den etablerte termen, så det engelske ordet i parentes er ikke nødvendig her.

Ordet som hører hjemme her, og som det lønner seg å bruke presist, er programvarerobot: det er et program som etterligner menneskelige handlinger i et grensesnitt, og det er ingen fysisk robot. Denne forskjellen er viktigere på norsk enn på engelsk, fordi ordet «robot» i dagligtale betyr en innretning, og nettopp derfra kommer en del av spørsmålene om hva roboten «ser» og hva den «forstår». Den forstår ingenting: den gjentar det den ble vist.

KI-agenten utleder veien selv

Agenten skiller seg fra de to foregående ved at den ikke får en vei, men et mål, og veien velger den selv ved å kalle verktøy den har tilgang til — søk, en database, et systemgrensesnitt, en annen modell. Det er nettopp det å bruke verktøy som er kjennetegnet som skiller en agent fra en chatbot: chatboten svarer, agenten gjør. Derav følger at agenten klarer oppgaver der rekkefølgen av steg ikke er kjent på forhånd, og samtidig er den den eneste av de tre mekanismene hvis resultat ikke er fullt ut forutsigbart. To identiske kjøringer kan velge ulike veier, og det betyr at det trengs både overvåking og tydelig satte grenser for hva agenten får gjøre selv, og hvor den skal stanse og spørre et menneske.

I det praktiske arbeidet betyr det gjerne at agenten er den riktige mekanismen der inndataene er ustrukturerte og varierte, men den gale der oppgaven er strengt bestemt og gjentas hundrevis av ganger om dagen. I det andre tilfellet er arbeidsflyten både billigere og sikrere, og å bruke en agent der er å bruke penger på uforutsigbarhet ingen hadde behov for.

I agenttilfellet får kjøperen noe annet enn i de to andre, og i tilbudene er det ofte ikke beskrevet i det hele tatt. Ved siden av selve agenten trengs verktøyene den får kalle, grenser for hva den får gjøre uten godkjenning, en logg over hva den gjorde i hver kjøring, og en måte å stanse den på. Et tilbud som bare inneholder en modell og en prompt, beskriver en demonstrasjon, ikke et arbeidsverktøy.

Det finnes også en kostnadsforskjell som ofte mangler i prosjektplanene. Å kjøre en arbeidsflyt koster nesten ingenting, fordi det er et par kall, og RPA-kostnadene er i hovedsak lisens og vedlikehold. Hver kjøring av en agent koster derimot for selve modellbruken, og denne kostnaden vokser med volumet, så mekanismen som i en prøve virket billig, kan i hundrevis av kjøringer om dagen vise seg å være den dyreste av de tre.

Hvor automatisering slutter og kunstig intelligens begynner

Denne grensen er de siste årene blitt et juridisk spørsmål, fordi KI-forordningen knytter pliktene sine nettopp til definisjonen av et KI-system. Artikkel 3 nr. 1 i forordningen beskriver det som et system som utleder hvordan det fra mottatte inndata skal frembringe et resultat — en prediksjon, innhold, en anbefaling eller en avgjørelse. Like viktig er det som blir stående utenfor. I fortalen er det sagt rett ut at systemer som bare virker etter regler fastsatt av mennesker, for å utføre handlinger automatisk, ikke faller inn under denne definisjonen, og Europakommisjonens retningslinjer gjentar det enda mer konkret, ved å kalle evnen til å trekke slutninger for det uunnværlige kjennetegnet og utførelse av forhåndsbestemte instrukser for noe som ikke hører hjemme i definisjonen.

Den samme grensen følger av definisjonen: automatisering som omfatter robotisert prosessautomatisering og forretningsregelmotorer, og som utfører forhåndsbestemte steg uten læring eller prediksjon, er ikke kunstig intelligens. Fortalen til KI-forordningen, i den uoffisielle norske oversettelsen fra Digitaliserings- og forvaltningsdepartementet, sier det med rene ord: definisjonen bør ikke omfatte systemer som er basert på regler som utelukkende er fastsatt av fysiske personer for å utføre operasjoner automatisk. Det er tolkning av definisjonen, ikke en egen norsk forskrift, men det er den klareste formuleringen av skillet på norsk. Den praktiske betydningen er direkte: en RPA-robot som kopierer data mellom to vinduer, og en arbeidsflyt som kaller et grensesnitt etter en tegnet vei, utløser ikke pliktene i KI-forordningen. En agent som utleder, kan utløse dem, og nettopp derfor er det å blande navnene i et tilbud ikke bare et stilspørsmål.

Hva kjøperen får i hvert tilfelle

Tilbud er lettere å sammenligne hvis du ikke ser på navnet, men på det som etter arbeidet blir igjen i bedriften. Ved robotisert prosessautomatisering blir det igjen en lisens, et kjøremiljø, et administrasjonsverktøy, en prosessbeskrivelse og en logg over utførte handlinger, og av alt dette er prosessbeskrivelsen det viktigste, fordi det er den som sier hva roboten gjør når noe ikke stemmer med det forventede.

Ved en arbeidsflyt blir det igjen selve arbeidsflyten, tilgangsdata til hvert tilknyttede system, kjørelogg og feilgren, og her lønner det seg å merke hvem som eier tilgangsdataene, og hvor arbeidsflyten kjører. Kjører den i leverandørens konto med leverandørens nøkler, betyr et brudd i relasjonen også et brudd i arbeidet, og det er lettere å rydde i det når avtalen inngås enn senere.

Ved en agent blir det i tillegg til alt det foregående også igjen ansvaret for det den gjorde, og nettopp derfor er loggen der ikke en teknisk detalj, men selve kjernen. Kan du ikke si hvorfor agenten i et konkret tilfelle handlet som den gjorde, kan du heller ikke svare kunden som spør hvorfor søknaden hans ble behandlet akkurat slik.

Hvilke frister som allerede er begynt

Fordi kravene i forordningen trer i kraft trinnvis, lønner det seg å vite hva som allerede gjelder, og hva som ennå ikke gjør det. Plikten til å informere et menneske om at det kommuniserer med et KI-system, gjelder i EU fra 2. august 2026, og den treffer en KI-agent eller chatbot kundene ser på nettstedet ditt. I Norge er KI-forordningen ennå ikke innlemmet i EØS-avtalen, så for et rent nasjonalt tilbud kommer plikten med KI-loven; tilbyr du systemet mot kunder i EU, er dette et spørsmål som må løses nå, ikke senere.

Kravene til høyrisiko, som gjelder områder som rekruttering og personalbeslutninger, begynner å gjelde 2. desember 2027, og denne datoen ble nylig flyttet, så i en del artikler står det fortsatt et tidligere år. Forbudt praksis og selve definisjonen av systemet gjelder allerede i EU.

Uavhengig av KI-forordningen gjelder fortsatt også kravet i personvernforordningen om avgjørelser som utelukkende er basert på automatisert behandling og som har rettsvirkning eller på tilsvarende måte i betydelig grad påvirker et menneske. Dette kravet avhenger ikke av om mekanismen er en agent eller en enkel arbeidsflyt: det som teller, er om avgjørelsen om et menneske treffes av maskinen alene.

Det lønner seg også å forstå hvorfor denne grensen er trukket nettopp gjennom evnen til å utlede, ikke gjennom kompleksitet. Et program kan være svært komplisert og likevel ikke være et KI-system, hvis hvert steg i det er fastsatt av et menneske, og omvendt — en ganske liten løsning som bruker en modell for å avgjøre hva den skal gjøre, faller inn under definisjonen. Det betyr at svaret på spørsmålet om plikter verken gis av prosjektbudsjettet eller av antall linjer, men bare av hvordan neste handling blir besluttet.

I praksis treffer disse fristene oftest én konkret ting mange bedrifter allerede har: en chatbot eller en assistent på nettstedet. Er den synlig for kunden og basert på en språkmodell, gjelder plikten til å si at samtalepartneren ikke er et menneske allerede i EU, og praktisk oppfylles den med en tydelig merking i grensesnittet, ikke med et avsnitt i personvernerklæringen. Er det et enkelt regeltre med ferdigskrevne svar, er det ikke et KI-system, og denne plikten oppstår ikke, men skillet lønner det seg å fastsette skriftlig, fordi om et år husker ingen lenger hvordan det var laget.

Hvorfor navnene blandes i markedet

Sammenblandingen har også en helt objektiv grunn, og det er ikke bare markedsføring. Verktøy som tidligere gjorde én ting, gjør nå flere: plattformer som startet som arbeidsflytverktøy, tilbyr nå også et steg for en agent, mens selskaper som solgte robotisert prosessautomatisering, nå beskriver de samme produktene som om de virker av seg selv.

Det betyr at du etter produktnavnet ikke lenger kan fastslå mekanismen, og det eneste sikre spørsmålet til et tilbud er hvordan handlingsveien blir bestemt i den konkrete løsningen: om et menneske skriver den, om den tegnes som en graf, eller om modellen velger den i hver kjøring. Svaret på dette ene spørsmålet sier både pris, skjørhet og om pliktene i forordningen i det hele tatt kan oppstå.

Det finnes også ord det lønner seg å være forsiktig med på norsk. Forkortelsen RPA bør aldri stå alene i teksten uten den fulle formen ved første gangs omtale. RPA er robotisert prosessautomatisering, altså programvare, ikke robotikk i betydningen fysiske roboter.

Det andre stedet navnene blandes, er selve bruken av ordet «automatisering». På norsk betegner det både styring av industrielle prosesser og automatisering av kontorarbeid, og det er to helt ulike markeder med ulike leverandører. Leter du etter et tilbud, lønner det seg å si hvilken av de to som er ment, fordi du ellers får en del tilbud fra en helt annen bransje.

Tre påstander som er feil i tilbudene

Den første er at robotisert prosessautomatisering skulle være kunstig intelligens. Det er ikke bare et terminologispørsmål, fordi det utløser plikter: et system som utfører steg et menneske har skrevet, faller ikke inn under definisjonen av et KI-system, og et tilbud som kaller roboten kunstig intelligens, enten tar for mye betalt, eller skaper bekymringer som ikke er begrunnet. Den andre er at en agent skulle være rett og slett en smartere chatbot. Forskjellen ligger ikke i hvor smart den er, men i handlingen: chatboten genererer et svar, agenten kaller verktøy og endrer tilstand i andre systemer, og nettopp derfor trenger agenten grenser en chatbot ikke trenger. En bedrift som ikke skiller der, gir gjerne agenten tilgang ingen har tenkt gjennom.

Den tredje er at valget mellom disse tre skulle være et valg mellom tre leverandører. I virkeligheten kan ett og samme verktøy ofte gjøre alle tre: plattformer som startet som arbeidsflytverktøy, tilbyr nå også et steg for en agent, og det betyr at spørsmålet ikke er hva du skal kjøpe, men hvordan handlingsveien blir bestemt i den konkrete løsningen.

Hvordan du velger mekanisme for et konkret arbeid

Valget er i praksis kort hvis spørsmålene stilles i riktig rekkefølge. Finn først ut om de involverte systemene har et programvaregrensesnitt, fordi hvis de har det, vil en arbeidsflyt nesten alltid være mer robust og billigere å vedlikeholde enn å gjenta skjermen, og videre er spørsmålet ikke lenger om mekanisme, men om omfang. Har systemet ikke grensesnitt, og kan det ikke byttes, er robotisert prosessautomatisering det rette verktøyet, men med åpne øyne: i budsjettet må det være vedlikehold, og i prosjektet må det være en ansvarlig som retter roboten når skjermen endrer seg. Er inndataene ustrukturerte, hvert tilfelle annerledes og rekkefølgen av steg umulig å skrive på forhånd, først da lønner det seg å se mot en agent, og også da må du vite hvor den stanser, og hvem som overvåker den.

Den vanligste praktiske løsningen er blandet: arbeidsflyten styrer kjeden og utfører alle forutsette steg, men på ett konkret sted kaller den en modell for å behandle ustrukturert inndata, og resultatet går tilbake inn i kjeden. Det forener forutsigbarhet med fleksibilitet akkurat der den trengs, og det er også det billigste av variantene som i det hele tatt virker.

Det finnes ennå et praktisk hensyn som ofte avgjør valget mer enn teknikken. Hver av de tre mekanismene krever en ulik vedlikeholder: en arbeidsflyt kan vedlikeholdes av et menneske som forstår systemenes grensesnitt, roboten trenger noen som kjenner nettopp det verktøyet og de skjermene den arbeider med, mens agenten i tillegg trenger noen som jevnlig ser på hva den faktisk gjør. Finnes det ikke et slikt menneske i bedriften, og er det ikke planlagt å kjøpe vedlikehold, må valget mellom mekanismene begynne med hvilken av dem det reelt vil være mulig å vedlikeholde.

Det lønner seg også å navngi den feilen som i dette valget koster dyrest, og det er ikke valg av mekanisme, men rekkefølgen. Bedrifter pleier først å velge verktøy, deretter lete etter hva de skal automatisere med det, og først da skjønne at prosessen de ville automatisere, ennå ikke er beskrevet. Riktig rekkefølge er den motsatte: først beskrives arbeidet med unntakene sine, deretter avklares om systemene har grensesnitt, og først da velges mekanismen, fordi valget på det tidspunktet som regel er innlysende og tar fem minutter. Like ofte finnes den motsatte ytterligheten, der bedriften venter til alt er ryddet, og ikke starter med noe. Her er det nyttig å huske at en arbeidsflyt kan bygges også for ett lite ledd og utvides senere, og at det nettopp er det første ferdige leddet som som regel viser hvor flaskehalsen faktisk ligger, langt mer presist enn enhver forhåndsvurdering.

Det lønner seg også å si at et bytte av mekanisme senere ikke er en katastrofe, hvis selve prosessen er beskrevet. Bedrifter pleier å frykte et feil valg som om det var irreversibelt, men i praksis er den største verdien i prosjektet nettopp prosessbeskrivelsen med unntakene sine, og den blir stående gyldig uavhengig av om den utføres av en robot, en arbeidsflyt eller en agent. Å bytte utfører når beskrivelsen allerede er på plass, er langt billigere enn å skrive beskrivelsen på nytt.

Hva du bør spørre leverandøren om

Ligger tilbudet allerede på bordet, holder fire spørsmål som regel for å skjønne hva som faktisk tilbys, uavhengig av hvilke ord som står i overskriften. Det første gjelder hvem som avgjør neste steg: et ferdigskrevet skript, en tegnet graf, eller en modell i det øyeblikket det kjøres. Nettopp dette svaret navngir mekanismen mer presist enn ethvert produktnavn i overskriften.

Det andre er hva som skjer når noe ikke stemmer med det forventede, og her lønner det seg å kreve et konkret eksempel, ikke en allmenn påstand om pålitelighet. Det tredje er hvem som eier tilgangsdataene, og hvor løsningen kjører, fordi det avgjør om arbeidet fortsetter hvis relasjonen med leverandøren tar slutt. Det fjerde er hva vedlikeholdet koster i året, og hva som konkret mottas for det, fordi det nettopp er vedlikeholdet som er den kostnaden tilbudene oftest ikke oppgir i det hele tatt.

Er svaret på ett av disse spørsmålene uklart, betyr det ennå ikke at tilbudet er dårlig, men at denne delen ennå ikke er tenkt gjennom, og å bli enige om den er langt billigere før avtalen enn etter det første stoppet.

Den motsatte listen er også nyttig, nemlig spørsmål som ikke avgjør noe, selv om de stilles ofte. Hvor store bedrifter leverandøren har betjent, hvor mange år den har vært i markedet, og hvor mange prosesser den har automatisert, sier noe om erfaring, men ingenting om hvorvidt den konkrete mekanismen passer til den konkrete oppgaven. Like lite nyttig er spørsmålet om hvilken plattform leverandøren bruker, fordi én og samme plattform i dag kan virke i alle tre mekanismene, og svaret på dette spørsmålet sier deg ingenting om løsningens skjørhet eller vedlikeholdskostnad.

Til slutt lønner det seg å be leverandøren vise ett allerede virkende eksempel og fortelle hva som har gått i stykker siden innføringen, og hvorfor. Svaret på dette spørsmålet sier mer om leverandørens arbeidskvalitet enn enhver referanseliste, fordi alt som har virket lenge nok, har gått i stykker, og det som teller, er hvor raskt det ble oppdaget og reparert.

Det er også ærlig å si vår egen posisjon, fordi den forklarer hvorfor denne artikkelen er skrevet akkurat slik. Vi selger ikke lisenser til robotisert prosessautomatisering og er ikke partner med noen slik plattform, så vi har ingen interesse av at du skal velge den dyreste mekanismen.

Vårt arbeid er automatisering av forretningsprosesser med arbeidsflyter og grensesnitt mellom systemer du allerede har, inkludert den blandede varianten der kjeden styres av en arbeidsflyt og modellen bare kalles i ett ustrukturert steg, og separat KI-løsninger der oppgaven virkelig krever at det trekkes slutninger. Har du nå et tilbud der disse ordene er blandet, eller er det rett og slett uklart hvilken mekanisme som passer til oppgaven din, send oss en beskrivelse: svaret er ofte at det holder med én kobling, og det er det billigste svaret du kan få.