När behövs AI egentligen i automatisering?

AI-hypen och vardagens automation

Det finns ett mönster vi ser hos företag som börjar titta på automatisering just nu: första frågan är "ska vi använda AI?". Kort efter följer en demo med en LLM som läser fakturor, klassificerar e-post eller chattar med kunder.

Demon imponerar. Den ser smart ut. Men när den ska köras hundratusen gånger per år börjar problemen dyka upp: oförutsägbara svar, högre kostnader än man räknat med, och svårt att felsöka när något blir fel.

Det är inte AI:s fel. Det är att man valt fel verktyg för uppgiften.

Den här texten handlar om hur vi tänker kring AI i våra automationer: vad som ska vara deterministiskt, var språkmodeller faktiskt tillför värde, och hur du undviker att bygga ett system som blir dyrt och bräckligt utan att behöva vara det.

Deterministisk vs probabilistisk automation

Det finns två fundamentalt olika sätt att lösa en uppgift i ett automatiserat flöde:

Deterministiskt betyder att samma indata alltid ger samma resultat. Reglerna är skrivna i förväg: "om beloppet är över 50 000 kr, skicka för godkännande". Du kan testa det, du kan lita på det, och det kostar i princip ingenting att köra.

Probabilistiskt betyder att systemet gör en bedömning. Samma indata kan ge olika resultat olika gånger. En LLM som läser ett mejl och avgör om det är ett supportärende eller en offertförfrågan är probabilistisk. Den har rätt nästan alltid — men inte alltid.

I nästan alla affärsflöden behövs båda. Trick är att veta vilken som passar var.

Tre frågor som avgör

När vi designar ett flöde ställer vi tre frågor för varje steg:

Går det att beskriva med tydliga regler? Om svaret är ja — använd regler.
Är indata strukturerad? Belopp, datum, valda alternativ från en dropdown — strukturerad data hanteras bäst med kod.
Vad händer om systemet har fel? Om felet upptäcks omedelbart och kan rättas är probabilistik okej. Om det riskerar att gå vidare odetekterat — undvik det.

Om alla tre frågorna pekar mot deterministisk lösning ska steget vara deterministiskt. Det är billigare, snabbare och mer pålitligt. Punkt.

När AI faktiskt tillför värde

Det finns ändå uppgifter där en språkmodell är överlägsen — och det är värt att lyfta fram, eftersom det ofta är just dem som motiverar hela arkitekturen:

Ostrukturerad text

Att läsa ett mejl skrivet av en kund och plocka ut "vad vill den här personen?". Att tolka en faktura där varje leverantör har sitt eget format. Att hitta nyckeltal i ett pdf-protokoll.

Det här är klassiska AI-uppgifter. Att försöka lösa dem med regler leder till tusentals if-satser som ändå går sönder så fort en ny variant dyker upp.

Klassificering med många kategorier

När du har 30+ kategorier och varje inkommande objekt ska sorteras till rätt — och kategorierna är beskrivna i ord, inte siffror — är AI ofta rätt val. Reglerna blir helt enkelt för många att underhålla.

Sammanfattningar och utkast

Att sammanfatta en lång supportkonversation till en intern notering. Att skapa ett utkast till svar som en människa sedan godkänner. Här är AI bra på att spara tid — så länge en människa fortfarande är med på sista steget.

Arkitekturen vi använder i praktiken

I de flesta av våra projekt ser systemet ut ungefär så här: ett deterministiskt skelett med små, väldefinierade AI-anrop på de ställen där det verkligen behövs.

Ett konkret exempel — automatiserad hantering av inkommande offertförfrågningar via mejl:

Mejlet tas emot av en regelstyrd integration. Ingen AI.
AI läser mejlet och extraherar tre saker: kontaktperson, ungefärlig budget om den nämns, och vilken typ av tjänst kunden är ute efter. Det här är ett enda, tydligt LLM-anrop med strukturerad output.
Reglerna tar över igen. Är budgeten över ett tröskelvärde? Då skapas ett ärende i CRM och en notifikation går till säljansvarig. Är det en standardförfrågan? Då skickas ett automatiskt svar med priser och en länk till kalendern.
Loggning och spårbarhet — varje steg dokumenteras. Vad AI:n läste ut, vilka regler som triggades, vilket utfall det gav.

Notera att AI bara används på ett ställe — där det är överlägset. Resten är gammaldags kod och regler. Det gör hela flödet billigt att köra, lätt att felsöka och lätt att utöka.

Vad det här betyder för kostnaden

Det är inte ovanligt att vi ser system där en språkmodell anropas i varje steg av flödet. Då blir kostnaden snabbt ett problem.

Ett räkneexempel: ett företag som processar 50 000 inkommande mejl i månaden. Om varje mejl går genom tre LLM-anrop blir det 150 000 anrop. Med ett modernt modell-API kan det landa på flera tusen kr i månaden — bara för en del av flödet. Med samma volym men bara ett LLM-anrop per mejl, plus regler för resten, kan kostnaden ofta sänkas till under en tredjedel.

Det är inte bara en fråga om pris. Färre AI-anrop betyder också snabbare flöden, färre potentiella felkällor och mindre beroende av att en extern leverantörs API ska fungera just när du behöver det.

Tre vanliga fallgropar

När företag bygger AI-tunga flöden är det oftast något av följande som går fel:

1. AI används där en regel räcker

Den vanligaste fallgropen. "Om totalbeloppet är över X, skicka för godkännande" är en regel — inte en AI-uppgift. När vi ser LLM:er användas för enkla numeriska tröskelvärden eller datumberäkningar är det nästan alltid ett tecken på att teamet började med AI-verktyget och letade efter ett problem att lösa.

2. Ingen mänsklig kontrollpunkt vid hög påverkan

Om en automation kan skicka pengar, ingå avtal eller kontakta kunder i företagets namn — och det enda som hindrar det från att gå fel är en språkmodells bedömning — då är arkitekturen fel. Inför ett godkännandesteg eller en regelbaserad spärr.

3. Inget sätt att se vad AI:n faktiskt gjorde

Om något gick fel i veckan måste du kunna gå tillbaka och se exakt vilket beslut AI tog och varför. Utan loggar är systemet en black box, och den dagen något blir fel — och det blir det förr eller senare — har du inget att utgå från.

Hur du tänker kring nästa automation

När du står inför en ny process och funderar på om AI ska vara med, prova den här checklistan:

Skriv ner stegen i flödet, ett i taget
För varje steg, fråga: kan det beskrivas med regler?
Markera bara de steg där svaret är klart nej — det är där AI hör hemma
Fundera på vad som händer om AI gör fel just där, och bygg in en kontrollpunkt om risken är hög

Resultatet brukar bli ett system där 80–90 % är regelbaserat och 10–20 % är AI. Det är där vi ser de mest stabila, kostnadseffektiva och underhållsbara automationerna.

Sammanfattningsvis

AI är ett kraftfullt verktyg, men det är ett verktyg bland flera. I en bra automatisering är det inte huvudrollen — det är specialisten som kallas in när vanliga regler inte räcker till.

När vi hjälper kunder bygga automationer är ett av våra första jobb att sortera ut vad som faktiskt behöver AI och vad som klarar sig fint utan. Resultatet blir nästan alltid ett enklare, billigare och mer pålitligt system än det man först tänkte sig.

Vill du ha en konkret bedömning av vilka delar av era processer som passar för deterministisk automation och var AI faktiskt skulle göra skillnad? Hör av dig så går vi igenom det tillsammans.