RPA, arbetsflödesautomation och AI-agenter: vad varje term betyder

Tre ord som i offerter används som tre prisnivåer för samma tjänst är tre skilda mekanismer. Vad som skiljer dem, vad du som köpare får och varför skillnaden nu också är juridisk.

Tre ord brukar dyka upp i en och samma offert som om de vore tre prisnivåer för en och samma tjänst: robotiserad processautomation, arbetsflödesautomation och AI-agenter. Köparen får intrycket att det gäller att välja en av tre produkter, och oftast blir det den dyraste, för den låter modernast.

I själva verket är det tre skilda mekanismer som löser skilda problem, och merparten av de verkliga uppgifterna kräver just den som kostar minst. Den här artikeln jämför inte verktyg och rekommenderar ingen plattform; den förklarar vad som tekniskt skiljer varje mekanism, vad du som köpare får i varje fall och varför just den skillnaden de senaste två åren också har blivit en juridisk fråga.

Tre mekanismer som svarar på tre olika frågor

Det enklaste sättet att hålla dem isär är att fråga hur var och en vet vad den ska göra: robotiserad processautomation upprepar de åtgärder en människa visade den; arbetsflödesautomation följer en väg någon har ritat; en AI-agent drar själv slutsatser om vägen utifrån ett mål den har fått. Nästan allt annat följer av den enda skillnaden, inklusive pris, skörhet och vad som händer när situationen är oväntad, så mekanismen som upprepar stannar i en oväntad situation; mekanismen som följer en utritad väg tar felgrenen, om en sådan är förutsedd; mekanismen som drar slutsatser hittar på något nytt, och just därför behöver den en tillsyn som de andra två inte behöver.

Det är värt att pröva det på en konkret uppgift som ser likadan ut i nästan varje företag: en faktura som kommit med e-post ska in i bokföringssystemet. Robotiserad processautomation skulle lösa arbetet genom att öppna e-postprogrammet, ladda ner bilagan, öppna bokföringsfönstret och fylla i fälten i exakt den ordning en medarbetare skulle ha gjort det. Ett arbetsflöde skulle lösa det genom att ta emot dokumentet via ett gränssnitt och anropa bokföringssystemets gränssnitt med färdiga fält, utan att öppna ett enda fönster. En agent skulle lösa det genom att ta emot uppgiften ”bokför den här fakturan” och själv avgöra vilka verktyg den ska anropa och vad den ska göra om något saknas.

Alla tre varianterna kan utföra uppgiften, och just det vilseleder: skillnaden visar sig inte när allt är i sin ordning, utan när leverantören byter fakturaformulär, när ett nytt obligatoriskt fält dyker upp i systemet eller när en och samma vara har två namn, och just de fallen utgör merparten av det verkliga arbetet.

Robotiserad processautomation upprepar åtgärder på skärmen

Robotiserad processautomation, i vardagen kallad med den engelska förkortningen RPA, är en mjukvarurobot som arbetar i precis samma gränssnitt som en människa: den öppnar ett fönster, klickar, kopierar in ett fält, trycker på spara. Systemen den arbetar mot förblir helt oförändrade, och just det är både den främsta fördelen och den främsta svagheten: fördelen är att RPA klarar program som saknar varje gränssnitt för datautbyte och som ingen längre kommer att bygga om, så det är ofta den enda vägen in i gamla bokförings- eller branschsystem, medan svagheten är att roboten ser skärmen, inte data, så varje ändring på skärmen — en flyttad knapp, ett nytt fält, en annan uppdateringsversion — stoppar arbetet, och förvaltningen blir en löpande kostnad, inte en engångskostnad.

Du som köpare får här en robotlicens, dess körningsmiljö och hanteringsverktyg, en processbeskrivning och en logg över de utförda åtgärderna. Det är värt att veta att branschen själv räknar namnet som misslyckat: det RPA automatiserar är vanligtvis en enskild uppgift, inte en hel process, och just glappet mellan namn och innehåll skapar en del av de köparförväntningar som sedan inte infrias.

Ett annat kännetecken som brukar överraska i RPA-projekt är att roboten arbetar med samma åtkomstnivå som människan vars åtgärder den upprepar. Det betyder att roboten behöver en egen användare i varje system, att den användarens rättigheter måste tänkas igenom som för vilken annan som helst, och att robotens åtgärder i systemloggen ser ut som en människas om den inte har ett separat konto. I företag där det inte har tänkts igenom är det efteråt svårt att svara på den enkla frågan vem som gjorde den konkreta posten.

Arbetsflödesautomation kopplar system, inte skärmar

Arbetsflödesautomation arbetar ett lager djupare: den talar inte med skärmen, utan med själva systemen, via deras programmeringsgränssnitt. Ett arbetsflöde är en i förväg ritad graf av steg — en händelse sätter igång en kedja, kedjan anropar åtgärder i andra system, och däremellan kan det också finnas ett steg där en människa godkänner något. Eftersom datautbytet går via gränssnittet, inte via en bild, påverkar ändringar i systemets utseende inte den här mekanismen, och det är det främsta skälet till att den, där ett gränssnitt finns, nästan alltid är det tåligare och billigare valet att förvalta jämfört med att upprepa skärmen. Nackdelen är uppenbar: om systemet saknar gränssnitt, eller om det inte ingår i din licensnivå, finns den här vägen helt enkelt inte.

Du som köpare får här själva arbetsflödet, åtkomstuppgifter, en körningslogg och en felgren, och just den sista är det du ska bedöma en offert efter, för ett arbetsflöde utan felhantering fungerar bara så länge allt är i sin ordning. På svenska har mekanismen ett eget ord: arbetsflöde är den etablerade termen för engelskans workflow, och den här webbplatsens egen tjänstetext använder den redan, så det engelska ordet behövs inte inom parentes här.

Ett ord som behövs här och som är värt att använda precist är mjukvarurobot: det är ett program som härmar en människas åtgärder i ett gränssnitt, och det är ingen fysisk robot. Den skillnaden är viktigare på svenska än på engelska, för ordet ”robot” betyder i vardagen en apparat, och just från det missförståndet kommer en del av frågorna om vad roboten ”ser” och vad den ”förstår” — den förstår ingenting, utan upprepar det den visades.

AI-agenten drar själv slutsatser om vägen

Agenten skiljer sig från de båda föregående genom att den inte får en väg, utan ett mål, och vägen väljer den själv genom att anropa verktyg den har tillgång till — sökning, databas, systemets gränssnitt, en annan modell. Just att den arbetar med verktyg är det kännetecken som skiljer agenten från en chattbot — chattboten svarar, agenten gör — och därav följer att agenten klarar uppgifter där stegens ordning inte är känd i förväg, och samtidigt är den den enda av de tre mekanismerna vars resultat inte är fullt förutsägbart. Två identiska körningar kan välja olika vägar, och det betyder att det behövs både tillsyn och tydligt satta gränser för vad agenten får göra själv och var den ska stanna och fråga en människa.

I det praktiska arbetet brukar det betyda att agenten är rätt mekanism där indata är ostrukturerade och skiftande, men fel där uppgiften är strikt bestämd och upprepas hundratals gånger om dagen. I det andra fallet är arbetsflödet både billigare och säkrare, och att använda en agent där är att betala för oförutsägbarhet som ingen behövde.

I agentfallet får du som köpare något annat än i de två övriga fallen, och i offerterna är det ofta inte beskrivet alls. Utöver själva agenten behövs verktyg den får anropa, gränser för vad den får göra utan godkännande, en logg över vad den gjorde i varje körning, och ett sätt att stoppa den, så en offert som bara innehåller en modell och en prompt beskriver en demonstration, inte ett arbetsverktyg.

Det finns också en kostnadsskillnad som brukar saknas i projektplanerna: att köra ett arbetsflöde kostar nästan ingenting, för det är ett par anrop, och RPA-kostnaden är främst licens och förvaltning, medan varje körning av en agent kostar för användningen av modellen, och den kostnaden växer med volymen, så mekanismen som i ett försök verkade billig kan vid hundratals körningar om dagen visa sig vara den dyraste av de tre.

Där automatiseringen slutar och den artificiella intelligensen börjar

Den här gränsen har de senaste åren blivit en juridisk fråga, för EU:s förordning om artificiell intelligens knyter sina skyldigheter just till definitionen av ett AI-system. Artikel 3.1 beskriver det som ett system som drar slutsatser om hur det av den indata det tar emot ska skapa utdata — en förutsägelse, innehåll, en rekommendation eller ett beslut. Lika viktigt är det som hamnar utanför: i förordningens skäl sägs rakt ut att system som bara arbetar efter regler som människor har fastställt, för att automatiskt utföra åtgärder, inte omfattas av definitionen, och Europeiska kommissionens riktlinjer upprepar det ännu mer konkret genom att kalla slutsatsförmågan den oersättliga egenskapen och utförandet av i förväg bestämda instruktioner för något som inte ingår i definitionen.

Samma gräns står i förordningens eget svenska skäl 12: definitionen omfattar inte system som bygger på de regler som fastställs endast av fysiska personer för att automatiskt utföra operationer, och slutsatsförmågan är den egenskap som skiljer ut ett AI-system, så robotiserad processautomation och affärsregelmotorer som utför i förväg bestämda steg, utan inlärning eller förutsägelse, är därför inte artificiell intelligens. Den praktiska innebörden är rak: en RPA-robot som kopierar data mellan två fönster, och ett arbetsflöde som anropar ett gränssnitt längs en utritad väg, ger inte upphov till skyldigheter enligt förordningen, medan en AI-agent som drar slutsatser kan göra det, och just därför är det inte bara en stilfråga att blanda namnen i en offert.

Vad du som köpare får i varje fall

Offerter är lättare att jämföra om du inte tittar på namnet, utan på vad som blir kvar i företaget när arbetet är slut. Vid robotiserad processautomation blir det en licens, en körningsmiljö, ett hanteringsverktyg, en processbeskrivning och en logg över de utförda åtgärderna, och av allt det är processbeskrivningen det viktigaste, för just den säger vad roboten gör när något inte stämmer med det väntade.

Vid ett arbetsflöde blir det själva arbetsflödet, åtkomstuppgifter till varje kopplat system, en körningslogg och en felgren, och här är det värt att fästa uppmärksamheten vid vem som äger åtkomstuppgifterna och var arbetsflödet körs. Om det körs i leverantörens konto med leverantörens nycklar betyder ett avbrott i relationen också ett avbrott i arbetet, och det är lättare att ordna när avtalet sluts än senare.

Vid en agent blir det, utöver allt föregående, också ansvaret för det den gjorde, och just därför är loggen där inte en teknisk petitess utan själva kärnan. Om du inte kan säga varför agenten i ett konkret fall handlade som den gjorde, kan du inte heller svara en kund som frågar varför hens ärende behandlades just så.

Vilka tidsfrister som redan har börjat

Eftersom förordningens krav träder i kraft stegvis är det värt att veta vad som redan gäller i dag och vad som ännu inte gör det. Skyldigheten att informera en människa om att hen kommunicerar med ett AI-system är tillämplig sedan den 2 augusti 2026, och den gäller en AI-agent eller chattbot som är synlig för kunderna på din webbplats, så om en sådan är installerad är det en fråga som ska lösas nu, inte i framtiden.

Kraven på högrisksystem, som gäller sådana områden som rekrytering och anställningsbeslut, börjar tillämpas den 2 december 2027, och det datumet flyttades nyligen, så i en del artiklar står det fortfarande ett tidigare år, medan de förbjudna metoderna och själva systemdefinitionen gäller redan nu.

Oberoende av förordningen om artificiell intelligens gäller också dataskyddskravet om beslut som fattas enbart automatiserat och som har rättsverkan eller på liknande sätt i betydande grad påverkar en människa. Det kravet beror inte på om mekanismen är en agent eller ett enkelt arbetsflöde: det som räknas är om beslutet om människan fattas av en maskin ensam.

Det är också värt att förstå varför den här gränsen är dragen just genom slutsatsförmågan, inte genom komplexiteten: ett program kan vara mycket komplicerat och ändå inte vara ett AI-system, om varje steg i det har bestämts av en människa, och omvänt — en helt liten lösning som använder en modell för att avgöra vad som ska göras omfattas av definitionen. Det betyder att svaret på frågan om skyldigheter inte ges av projektets budget, inte av antalet rader, utan bara av hur beslutet om nästa åtgärd fattas.

I praktiken gäller de här tidsfristerna oftast en konkret sak som många företag redan har: en chattbot eller en assistent på webbplatsen. Om den är synlig för kunden och bygger på en språkmodell, då gäller redan skyldigheten att säga att samtalspartnern inte är en människa, och praktiskt uppfylls den med en tydlig märkning i gränssnittet, inte med ett stycke i integritetspolicyn. Om det är ett enkelt regelträd med i förväg skrivna svar, då är det inte ett AI-system och den här skyldigheten uppstår inte, men skillnaden är värd att fästa i skrift, för om ett år minns ingen längre hur det var byggt.

Varför namnen blandas på marknaden

Förvirringen har också ett helt objektivt skäl, och det är inte bara marknadsföring: verktyg som tidigare gjorde en sak gör nu flera, så plattformar som började som arbetsflödesverktyg erbjuder nu också ett agentsteg, medan företag som sålde robotiserad processautomation nu beskriver samma produkter som sådana som arbetar av sig själva.

Det betyder att du inte längre kan avgöra mekanismen efter produktnamnet, och den enda säkra frågan till en offert är hur åtgärdsvägen bestäms i den konkreta lösningen: om en människa skriver in den, om den ritas som en graf, eller om modellen väljer den vid varje körning — och svaret på den enda frågan säger både pris, skörhet och om förordningens skyldigheter över huvud taget kan uppstå.

Det finns också ord man ska vara försiktig med på svenska: förkortningen RPA ska aldrig stå ensam vid första omnämnandet, utan skrivas ut som robotiserad processautomation (RPA), och den felaktiga formen robotikprocessautomation förekommer, för robotik är fysiska robotar och här handlar det om programvara.

En andra plats där namnen blandas är själva användningen av ordet ”automatisering”: på svenska betecknar det både styrning av industriella processer och automatisering av kontorsarbete, och det är två helt skilda marknader med skilda leverantörer. Om du söker en offert är det värt att säga vilken av de två som avses, för annars kommer en del av de offerter du får från en helt annan bransch.

Tre påståenden som är fel i offerter

Det första är att robotiserad processautomation skulle vara artificiell intelligens, och det är inte bara en terminologifråga, för därav följer skyldigheter: ett system som utför steg en människa har skrivit omfattas inte av definitionen av ett AI-system, och en offert som kallar roboten för artificiell intelligens säljer antingen dyrare än det behövs, eller skapar oro som saknar grund. Det andra är att agenten skulle vara helt enkelt en smartare chattbot, men skillnaden ligger inte i smartheten, utan i handlingen: chattboten genererar ett svar, agenten anropar verktyg och ändrar tillståndet i andra system, och just därför behöver agenten gränser som chattboten inte behöver, så ett företag som inte skiljer de två åt brukar ge agenten åtkomst som ingen har tänkt igenom.

Det tredje är att valet mellan de tre skulle vara ett val mellan tre leverantörer, men i själva verket kan ett och samma verktyg ofta göra alla tre: plattformar som började som arbetsflödesverktyg erbjuder nu också ett agentsteg, och det betyder att frågan inte är vad du ska köpa, utan hur åtgärdsvägen bestäms i den konkreta lösningen.

Så väljer du mekanism för ett konkret arbete

Valet är i praktiken kort, om frågorna ställs i rätt ordning: ta först reda på om de inblandade systemen har ett programmeringsgränssnitt, för om de har det kommer ett arbetsflöde nästan alltid att vara tåligare och billigare att förvalta än att upprepa skärmen, och därefter är frågan inte längre om mekanism, utan om omfattning. Om gränssnitt saknas och systemet inte kan bytas, då är robotiserad processautomation rätt verktyg, men med öppna ögon: i budgeten måste förvaltning finnas, och i projektet måste det finnas en ansvarig som lagar roboten när skärmen ändras. Om indata är ostrukturerade, varje fall skiljer sig och stegens ordning inte kan skrivas i förväg, först då är det värt att titta mot en agent, och även då måste du veta var den stannar och vem som övervakar den.

Den vanligaste praktiska lösningen är blandad: arbetsflödet styr kedjan och utför alla förutsebara steg, men på ett konkret ställe anropar det en modell för att bearbeta ostrukturerad indata, och resultatet lämnas tillbaka till kedjan. Det förenar förutsägbarhet med flexibilitet just där den behövs, och det är också det billigaste av de alternativ som över huvud taget fungerar.

Det finns ytterligare en praktisk omständighet som brukar avgöra valet mer än tekniken: var och en av de tre mekanismerna kräver en annan förvaltare, så ett arbetsflöde kan förvaltas av någon som förstår systemens gränssnitt, roboten behöver någon som behärskar just det verktyget och de skärmar den arbetar med, men agenten behöver dessutom någon som regelbundet tittar på vad den faktiskt gör. Om företaget inte har en sådan person och inte planerar att köpa förvaltning, då måste valet mellan mekanismerna börja med vilken av dem som faktiskt kommer att kunna förvaltas.

Det är också värt att namnge det fel som i det här valet kostar mest, och det är inte valet av mekanism, utan ordningen. Företag brukar först välja verktyg, sedan leta efter vad som ska automatiseras med det, och först därefter förstå att processen de ville automatisera ännu inte är beskriven. Den rätta ordningen är den omvända: först beskrivs arbetet med dess undantag, sedan tar man reda på om systemen har gränssnitt, och först då väljs mekanismen, för i det läget är valet vanligtvis uppenbart och tar fem minuter; lika vanligt är den motsatta ytterligheten, där företaget väntar tills allt är ordnat och inte börjar med något, och här är det nyttigt att minnas att ett arbetsflöde kan byggas för ett litet avsnitt och utvidgas senare, och att just det första avslutade avsnittet vanligtvis visar var flaskhalsen faktiskt sitter, mycket precisare än vilken förhandsbedömning som helst.

Det är också värt att säga att ett byte av mekanism senare inte är en katastrof, om själva processen är beskriven. Företag brukar vara rädda för ett felaktigt val som om det vore oåterkalleligt, men i praktiken är det största värdet i projektet just processbeskrivningen med dess undantag, och den förblir giltig oberoende av om den utförs av en robot, ett arbetsflöde eller en agent, så att byta utförare när beskrivningen redan är på plats är mycket billigare än att skriva beskrivningen på nytt.

Vad du ska fråga leverantören

Om en offert redan ligger på bordet räcker vanligtvis fyra frågor för att förstå vad som faktiskt erbjuds, oberoende av vilka ord som står i rubriken. Den första gäller vem som avgör nästa steg: ett inskrivet skript, en utritad graf eller en modell i körningsögonblicket, och just det svaret namnger mekanismen precisare än vilket produktnamn som helst i rubriken.

Den andra är vad som händer när något inte stämmer med det väntade, och här är det värt att begära ett konkret exempel, inte ett allmänt påstående om tillförlitlighet. Den tredje är vem som äger åtkomstuppgifterna och var lösningen körs, för därav beror om arbetet fortsätter om relationen med leverantören tar slut. Den fjärde är vad förvaltningen kostar per år och vad du exakt får för den, för just förvaltningen är den kostnad som oftast inte anges i offerterna alls.

Om svaret på någon av de här frågorna är oklart betyder det ännu inte att offerten är dålig, utan att den delen inte har tänkts igenom, och att komma överens om den är mycket billigare före avtalet än efter det första stoppet.

Den omvända listan duger också, nämligen frågor som inte avgör något, även om de ställs ofta: hur stora företag leverantören har betjänat, hur många år den har varit på marknaden och hur många processer den har automatiserat, säger något om erfarenhet, men ingenting om huruvida den konkreta mekanismen duger för den konkreta uppgiften. Lika lite hjälper frågan om vilken plattform leverantören använder, för en och samma plattform kan i dag arbeta i alla tre mekanismerna, och svaret på den frågan säger dig ingenting om lösningens skörhet eller förvaltningskostnad.

Slutligen är det värt att be leverantören visa ett exempel som redan är i drift och berätta vad som har gått sönder i det sedan installationen och varför. Svaret på den frågan säger mer om leverantörens arbetskvalitet än vilken referenslista som helst, för allt som har arbetat tillräckligt länge har gått sönder, och det som räknas är hur snabbt det upptäcktes och lagades.

Det är också ärligt att säga vår egen position, för den förklarar varför den här artikeln är skriven just så här: vi säljer inga licenser för robotiserad processautomation och är inte partner till någon sådan plattform, så vi har inget intresse av att du ska välja den dyraste mekanismen.

Vårt arbete är automatisering av affärsprocesser med arbetsflöden och gränssnitt mellan system som du redan har, inklusive den blandade varianten där kedjan styrs av ett arbetsflöde och modellen bara anropas i ett ostrukturerat steg, och separat AI-lösningar för företag där uppgiften verkligen kräver att slutsatser dras. Om du just nu har en offert där de här orden är blandade, eller helt enkelt inte är säker på vilken mekanism som duger för din uppgift, skicka oss en beskrivning: ofta är svaret att det räcker med en koppling, och det är det billigaste svar du kan få.