AI-automation 101: vad det är och när det lönar sig
AI-automation är när ett arbetsflöde körs av mjukvara i stället för av en person, och där en språkmodell sköter de steg som kräver tolkning. Skillnaden mot vanlig automatisering är att indata får variera: ett mejl formulerat på tre sätt, en faktura i fem layouter, ett ärende utan tydlig kategori. Är indata redan strukturerad behövs ingen AI, och då blir det både billigare och mer pålitligt utan.
Vad skiljer AI-automation från RPA och vanlig automatisering?
RPA, robotic process automation, följer inspelade regler och klickar sig genom gränssnitt. Det fungerar utmärkt så länge skärmen ser likadan ut. AI-automation tillför tolkning, vilket är det som gör att indata får variera. De utesluter inte varandra: den vanligaste uppsättningen är att en språkmodell läser och klassificerar, och att vanlig kod eller RPA gör själva verkställandet.
| Vanlig automatisering / RPA | AI-automation | |
|---|---|---|
| Indata | Måste ha känt format | Får variera i formulering och layout |
| Beslut | Fasta regler | Tolkning, sedan fasta regler |
| Går sönder när | Formatet ändras | Underlaget saknas eller är motstridigt |
| Felen syns | Direkt, flödet stannar | Tyst, om ingen loggar och granskar |
| Kostnad per körning | I princip noll | Tokenkostnad per anrop |
| Passar | Strukturerad data | Text, dokument, ärenden |
Vilka delar består ett AI-flöde av?
Nästan varje automation jag bygger har samma tre delar, och det är värt att kunna skilja på dem eftersom de har helt olika felbeteende.
- Utlösaren. Något händer: ett mejl kommer in, ett formulär skickas, klockan blir sju. Här går det sällan fel.
- Tolkningen. Vad handlar det här om, vilka fält ska ut, vart ska det? Det är här språkmodellen gör nytta, och det är här felen uppstår.
- Verkställandet. Skriv till affärssystemet, skicka mejlet, skapa ärendet. Vanlig integration, och det ska vara vanlig kod.
Varför ska modellen aldrig räkna?
Den vanligaste designmissen jag ser är att låta språkmodellen summera belopp eller jämföra siffror. En modell ger dig ett rimligt svar, inte ett korrekt. Summeringar, uppslag och kontroller ska göras i kod som ger identiskt resultat varje körning. Modellen ska läsa, klassificera och formulera. Håller du den gränsen försvinner en stor del av de fel som får folk att tappa förtroendet för automationer.
Hur vet du om det lönar sig?
Räkna innan du bygger. Det tar tjugo minuter och avgör hela projektet.
- Hur många gånger i månaden körs processen? Under femtio gånger är det sällan värt det, om inte varje körning är dyr.
- Hur lång tid tar den per gång, mätt och inte gissat? Fråga den som faktiskt gör den, inte chefen.
- Vad kostar den tiden? Timkostnad gånger timmar, per månad.
- Vad kostar bygget och driften? Automationer är inte gratis att förvalta.
- Betalar den av sig inom ett år? Gör den inte det, bygg något annat först.
Var ska människan vara kvar?
Automationer som fattar beslut utan insyn blir avstängda inom ett halvår, oftast efter en enda incident. Bygg därför in ett godkännandesteg före allt som är svårt att ångra: utbetalningar, avtal, mejl till kund, borttagning av data. Frågor om leveransstatus kan gå automatiskt. Reklamationer kan det inte. Var gränsen går ska stå i en uttrycklig lista när flödet byggs, inte avgöras av modellen i stunden.
Vilken process ska ni börja med?
De flesta vill börja med den viktigaste processen. Gör inte det. Börja med en process som är irriterande men ofarlig, där ett fel kostar en ursäkt och inte en kund. Ni lär er hur det känns att förvalta ett flöde, och ni får siffror på träffsäkerheten innan ni sätter något kritiskt i drift.
Vanliga frågor
Vad kostar det att komma igång med AI-automation?
Priset följer hur många system som ska kopplas ihop, inte hur avancerad modellen är. En avgränsad automation mot ett eller två system är ett litet projekt; samma flöde mot ett affärssystem utan API är ett betydligt större. Be alltid om en kostnad efter att processen kartlagts, aldrig före, och var skeptisk mot fasta paketpriser som sätts innan någon sett era system.
Behöver vi egna utvecklare för att förvalta flödet?
Nej, men ni behöver någon som äger det. Ett flöde byggt i n8n går att läsa och justera av en teknisk intresserad person utan utvecklarbakgrund. Det som kräver utvecklare är integrationer mot system utan API och ändringar i kodsteg. Utan en utpekad ägare slutar flödet fungera vid första systemuppdateringen och ingen märker det.
Vad händer om språkmodellen gör fel?
Det beror helt på var felet får hamna. I ett flöde byggt med godkännandesteg före allt som är svårt att ångra blir ett fel en rättelse i granskningskön. I ett flöde utan sådana steg blir det ett felaktigt mejl till kund eller en felbokförd faktura. Det är alltså inte modellen som avgör konsekvensen utan konstruktionen runt den.
Hur lång tid tar det innan en automation är i drift?
En avgränsad automation är oftast i drift inom fyra till åtta veckor från första mötet. Det som drar ut på tiden är nästan aldrig bygget, utan åtkomst till system, beslut om vem som får godkänna vad, och att hitta tillräckligt med verklig data att testa mot.
