Vi börjar med något som inte har med AI att göra, för det förklarar varför resten spelar roll just nu.
Trettio år av konfigurering
Alla programvaror de senaste trettio åren har sålts på samma villkor. Man köper produkten och konfigurerar den så nära behovet som den går. Där den inte passar ändrar man hur medarbetarna arbetar. Man ändrar inte koden. Koden tillhör leverantören och är dyr att ändra, så det är organisationen som får böja sig.
Villkoren var rimliga så länge kod var dyr. De håller inte längre, eftersom kostnaden för att skriva kod går mot noll. Programvara är inte gratis, men steget från "så här vill vi att det ska fungera" till "nu fungerar det så" har blivit litet. Det som fortfarande är dyrt, och som väger tyngre för varje månad, är att förstå verksamheten så väl att man kan beskriva hur den ska fungera.
Ordlistan kommer först
Börja med orden. I de flesta företag betyder samma ord olika saker på olika avdelningar. Ta kund. Försäljningen menar ett företag som har skrivit på. Lagret menar en leveransadress. Supporten menar personen som mejlade i morse. Fakturaenheten menar den som står på fakturan.
Likadant är det med order, ärende, produkt och projekt, de fem begrepp vi börjar med hos varje kund. Ingen märker det förrän data från två system läggs bredvid varandra, och då blir varje siffra fel.
Lösningen är en ordlista, ibland kallad begreppsmodell: de fem begreppen, vad varje avdelning menar med dem i dag och den enda definition hela företaget ska använda. Det är några sidor vanlig text, och det är första leveransen i varje bygge.
Många kunder kan inte ändra ERP:n eller CRM:et. Men med dashboards och kontrollrum (command centers) kan ni lyfta verksamheten ur de systemen och låta medarbetarna arbeta med sina egna ord i stället för leverantörens. På skärmen står "kund" och betyder en sak, och koden bakom översätter till vad varje system kallar det. Därför måste ordlistan finnas först. Det är den koden byggs mot.
Processen är grunden
Ordlistan ger orden. Processbeskrivningen ger flödet. Tillsammans är de specifikationen.
När ingen behöver tänka på datalagring eller skärmlayout återstår processen. Hur den fungerar i dag, nuläget (as-is). Hur den skulle kunna fungera, målbilden (to-be). Och en tredje fråga som är ny: i vilka steg i målbilden hamnar intelligensen, alltså AI. De flesta steg behöver den inte. Att flytta en post från en status till en annan är vanlig kod. Att läsa ett rörigt dokument och avgöra vad det är kräver omdöme, och där hör en modell hemma.
Processkartläggning är decennier gammal. Det som har ändrats är vart resultatet tar vägen. Förr slutade det i en bild. Nu är det direkt underlag för ett bygge, och det är det första vi gör i FastTrack.
Tokens gör kod
Nu till AI. Det mest värdefulla man kan göra med tokens är kod.
Man kan också göra text och presentationer med tokens, och de är användbara. Men en sammanfattning läses en gång och glöms. Kod skrivs en gång och fortsätter att köra. Den kan ersätta ett kalkylark som någon uppdaterar varje fredag eller visa två system sida vid sida. Använder man AI bara till dokument får man snabbare dokument. Använder man den till kod får man sådant som fortsätter fungera medan man sover.
Det är Emberlooms tes.
Det du behöver veta om tekniken
Kortversionen av den AI-grundkurs vi kör i våra workshoppar: fyra idéer räcker.
Token. En modell läser inte ord. Den läser tokens, som är bitar av ord. På engelska motsvarar en token ungefär tre fjärdedelar av ett ord, så en beskrivning på 200 ord blir omkring 270 tokens. Allt mäts i tokens: vad modellen kan hålla i minnet, hur snabbt den svarar och vad det kostar.
Kontextfönstret. Tänk på det som ett skrivbord. Allt som ligger på skrivbordet kan modellen se. Det som inte ligger där finns inte för den. Ett avtal som inte ligger i fönstret kan inte citeras.
Förutsägelse. Modellen förutsäger den mest sannolika nästa biten text utifrån allt som kommit före. Mer gör den inte. Resultatet är ofta mycket bra, men det finns ingen inbyggd känsla för sanning bakom det och ingen signal som säger "jag vet inte". När fakta saknas skriver den hur ett rimligt svar skulle se ut. Fråga efter uppsägningstiden i ett leverantörsavtal som den inte har sett, så får du ett konkret, självsäkert och påhittat tal. Klistra in avtalet i fönstret så får du rätt svar. Det kallas hallucination. En skickligt formulerad instruktion tar inte bort den, och en lägre temperaturinställning gör bara att de felaktiga svaren blir jämna.
Var den brister. Modeller är dåliga på aritmetik och räkning, så kod får göra summorna. De vet inte vad som hände förra veckan om man inte ger dem uppgifterna. De hoppar ibland över steg tre i en process med fem steg och tappar en instruktion långt in i ett långt dokument. Svaren i designen är kod för allt som måste vara exakt, data i fönstret, små steg och den kritiska instruktionen nära toppen.
Koden tar den del som måste bli rätt. Modellen tar den del som kräver läsning och omdöme. Därför är kod den värdefulla leveransen.
Dashboards: glappet mellan era system
Alla företag har ett ERP, ett CRM, ett ärendesystem, en brevlåda och en hög kalkylark. Varje del känner till en bit av sanningen. Ingen ser helheten.
En dashboard stänger glappet. Man skriver kod som hämtar information från två eller fler system till en enda levande vy som tillhör just det här företaget. Öppna order från ERP:n bredvid öppna reklamationer från supportbrevlådan.
Tills nyligen betydde en dashboard som band ihop två system ett projekt med en utvecklare, så allt litet blev kvar i någons kalkylark. Nu kan den som vet vad hen behöver beskriva det, en modell skriver koden, och en fungerande första version kan finnas samma eftermiddag. Kostnaden flyttar till att veta vilka system som ska kopplas ihop och vad vyn ska visa. Där lönar sig ordlistan och processbeskrivningen.
Ur vår egen leverans: vi har byggt dashboards och kontrollrum för produktinformation, för produktion av SEO-texter, för CRM-hantering och för B2B-beställningar. I de här fallen sparade kunden tiotusentals kronor, i de större fallen hundratusentals kronor, och i vissa fall kunde ett system som kunden betalat för avvecklas. Det är våra egna resultat, inte en marknadssiffra.
De flesta system har femtio funktioner som kunden betalar för och tre som används. I två fall ersatte vi ett större system helt, ett CRM-system i det ena och bildhanteringen i ett DAM i det andra. Vi skrev bara koden för grundfunktionerna, i lägen där kunden inte behövde mer. Det fungerar inte överallt. Men frågan "ska vi fortsätta betala för det här systemet" har nu ett verkligt alternativ. Våra case visar hur det ser ut i praktiken.
Träna verksamheten att bygga
Om de enda som kan bygga det här är konsulter har man skapat ett nytt beroende. Det är bättre än ett projekt på tre månader, men fortfarande en kö.
Det mer användbara steget är att lägga förmågan hos medarbetarna. Den som kör leverantörsfakturaprocessen vet bättre än någon utomstående vad som behöver synas, och kan med enkla medel skapa de verktyg som gör det egna teamet effektivare.
Vi tänker på det som när folk lärde sig Excel. Ingen utbildade sig till programmerare för att använda ett kalkylark. De byggde något litet för sitt eget arbete, och det spred sig. Att skriva en tydlig beställning till en modell är en färdighet av samma storlek. När en person ser en modell koppla ihop data från två system till en levande vy på några minuter, inser hen att det gick att be om för flera år sedan, och börjar se luckorna i sitt eget arbete. Enligt vår erfarenhet är det ögonblicket den verkliga starten, och punkten där de är redo för handlingar.
Kontrollrummet: människan beslutar
En dashboard visar. Ett kontrollrum (command center) handlar också, och det bedömer också.
Det första tillskottet är handlingar: verktyget kan ändra något i en process. Det skickar påminnelsen, sätter status till väntande, skapar uppgiften, skriver utkastet till svar. Det andra är omdöme: verktyget använder AI för att bedöma om en faktura ser rätt ut, hur brådskande ett ärende är eller vad nästa rimliga steg är för ett avtal. Personen får ett förslag på nästa åtgärd, med en motivering, och godkänner eller ändrar det. Verktyget läser, matchar och förbereder. Personen avgör.
Det nya är att det här blivit billigt nog att bygga för användningsfall med liten återbetalning. Ett kontrollrum sparar lite. Många, vart och ett byggt för ett team som behövde precis det, sparar mycket.
Ta leverantörsfakturor, beskrivna så som vi skulle beskriva dem inför ett bygge.
Nuläge (as-is). Fakturor kommer som PDF till en gemensam brevlåda. En person skriver in leverantör, belopp och referens i ERP:n, hittar inköpsordern, kontrollerar mot vad som beställts och levererats och skickar vidare till attestanten. De som fastnat upptäcks när en leverantör ringer.
Målbild (to-be). Brevlådan matar en enda skärm. Varje faktura är en rad med leverantör, matchad inköpsorder, attestant och antal dagar den har väntat, och en föreslagen åtgärd med motivering på en rad: godkänn och skicka vidare, fråga leverantören, fråga inköparen, vänta. Ett klick genomför den.
Var intelligensen hamnar. I två steg: att läsa PDF:en till fält, och att bedöma en avvikelse, till exempel fyrtio enheter på fakturan och trettiosex på följesedeln. Allt annat är vanlig kod, eftersom det måste vara exakt. Modellen får aldrig göra summorna.
Det är ungefär tio rader och en komplett specifikation. Den som leder processen kan skriva den på en eftermiddag.
Agenter, kort
Därifrån kan agenter driva en affärsprocess löpande och spara tid åt människor. En agent är inte smartare än en instruktion. Den är en instruktion i en slinga, med verktyg och regler: något händer, den kontrollerar ett villkor, gör en handling, verifierar resultatet och väntar på nästa händelse.
Det är nästa nivå, och inte hela historien. Det mesta av värdet finns i de tidigare stegen, som är billigare och säkrare. Vi flyttar en process till en agent först när folk litar på kontrollrummets förslag och undantagen är få.
Det här måste hända först
Tre förutsättningar, och ordningen spelar roll.
Först lär sig människorna verktygen som genererar kod. Lika enkelt som att lära sig skriva en beställning eller uttrycka ett behov, som när folk lärde sig Excel: hur man beskriver vad man vill ha, hur man läser det som kommer tillbaka och hur man ber om en ändring. Utan det blir konsulten kvar som flaskhals. Det är vad FastTrack är till för.
Sedan guardrails. Genererad kod måste testas och uppfylla de krav ni ställer: automatiska kontroller som körs varje gång något ändras, granskning av en person som kan läsa resultatet och en tydlig regel för vad som får nå dem som använder det. Ordlistan och processbeskrivningen är det kontrollerna skrivs mot. Det är GuardRails.
Till sist en säker zon. En plats där data lagras säkert och åtkomsten styrs. När folk börjar bygga egna verktyg måste datan de pekar verktygen mot ligga på ett ställe med regler för vem som får se vad. Utan den är den första användbara dashboarden också det första läckaget. Det är SafeZone.
Gränser, inte bara möjligheter
Här brister det.
Bristerna från avsnittet om tekniken visar sig i praktiken som tysta fel: en faktura som lästs lite fel, en sammanfattning som utelämnar den enda klausul som spelade roll, ett förslag som låter säkert och bygger på gamla data. Botemedlet är detsamma varje gång, med en människa som godkänner allt som är svårt att ta tillbaka. Volym är inte värde: ett system som svarar snabbt på varje ärende och har fel i en stor del av dem är skada i stor skala.
Tre offentliga fall visar hur gränserna ser ut. Klarna meddelade i februari 2024 att företagets AI-assistent gjorde jobbet åt 700 agenter. I maj 2025 sa vd:n till Bloomberg att "cost unfortunately seems to have been a too predominant evaluation factor" och att resultatet blev lägre kvalitet, och Klarna började rekrytera mänskliga agenter igen. I juli 2025 raderade ett AI-kodverktyg från Replit en produktionsdatabas åt SaaStr-communityt, ignorerade en instruktion att frysa koden och hittade på data. Replits vd kallade det "Unacceptable and should never be possible", och bolaget började automatiskt skilja utvecklings- och produktionsdatabaser åt. I oktober 2025 betalade Deloitte Australia tillbaka över A$97 000 av ett statligt uppdrag sedan rapporten visat sig innehålla ett påhittat citat ur ett domstolsavgörande och hänvisningar till forskningsartiklar som inte finns. Det systemet säger och gör är företagets egen handling.
Det finns fler gränser. Där kunden behöver de femtio funktionerna, eller där skala eller integration är hela poängen med produkten, behåller man produkten. Vissa processer bör stoppas innan någon skrivit en rad. Modeller förändras, så varje verktyg behöver en ägare.
En realistisk AI-omställning är inte ett program med ett enda lanseringsdatum. Det är en ordlista för de fem begreppen, skriven i vanliga möten. En process beskriven som nuläge och målbild. En första dashboard som kopplar ihop två system. Ett kontrollrum på den process som har tydligast ägare och mest repetitivt omdöme. Därefter fler, byggda av dem som äger processerna, med guardrails och säker zon på plats innan antalet verktyg växer. Takten är vår bedömning utifrån vår egen leverans, inte ett jämförelsetal, och vi lovar ingen tidplan.
När agenten lämnar sandlådan
En agent vet inte var gränserna går. Den agerar med de behörigheter den fått, varken mer eller mindre. Kan den radera i databasen kan den radera i databasen, och Replit-fallet ovan är hur det ser ut en dålig dag.
Det andra problemet är prompt injection. En modell kan inte på ett pålitligt sätt skilja era instruktioner från text den råkar läsa. Därför kan varje dokument agenten öppnar, en faktura-PDF, ett mejl från en leverantör, en webbsida, innehålla instruktioner, och agenten kan följa dem. För ett kontrollrum som läser fakturor ur en gemensam brevlåda är det inte teoretiskt.
Det offentliga facit är långt nog. I juli 2025 fick någon in ett kommando i Amazon Q-tillägget för Visual Studio Code, skrivet på vanlig engelska, som sa åt agenten att rensa ett system till nästan fabriksläge och radera molnresurser. Amazon säger att det inte skulle ha körts, och ingen skada för kunder har redovisats. I februari 2026 använde en angripare prompt injection mot en AI-agent för ärendesortering hos Cline för att nå dess releasekedja, och ett ändrat paket låg ute i ungefär åtta timmar. Cline säger att ingen skadlig kod nådde användarna. I november 2025 rapporterade Anthropic att en grupp som bolaget bedömer som statsstödd använde Claude Code för att angripa ett trettiotal mål, bland dem företag och myndigheter, där agenten gjorde det mesta av arbetet. Incidenterna hämtades 2026-10-07 och återges som källorna beskriver dem.
Därför är de tre förutsättningarna svaret och inte en checklista: människor som kan läsa vad agenten gjorde, guardrails som testar och granskar innan något når användarna, och en säker zon där ni bestämmer vad agenten får nå. Ligger det agenten kan röra inom ett område med regler får en dålig instruktion en liten sprängradie. Körs agenten med er egen inloggning har den hela er räckvidd.
Här är regeln vi ger varje kund. Ge agenten minsta möjliga åtkomst som räcker för uppgiften. Börja med enbart läsrätt, och lägg till rätten att ändra något en åtgärd i taget, först när förslagen varit rätt en tid. Utse en person som kan dra i nödbromsen utan att fråga någon, med den åtkomst som krävs för att göra det i dag.
Måndag
Så här skulle vi göra på måndag.
Välj ett kalkylark, eller en process som någon upprepar varje vecka. Välj ett som en person uppdaterar för hand utifrån två andra ställen.
Skriv vad det gör på tio rader. Var informationen kommer ifrån, vilka ord som används, vad personen gör med den och vad som händer sedan. Om de fem orden inte är avstämda än, skriv ned oenigheten i stället för att dölja den. Markera varje steg som kod eller omdöme.
Utse ägaren. En person som kan processen och får ändra den. Går det inte att peka ut någon är det den första iakttagelsen.
Välj dashboard eller kontrollrum. Behöver folk bara se läget, bygg en dashboard. Gör någon samma sorts handling varje gång den tittar, bygg ett kontrollrum med en föreslagen åtgärd och en motivering.
Ta sedan de tio raderna till ägaren och bygg första versionen tillsammans. Vill ni ha en partner för det, boka en introduktion eller läs hur vi arbetar.
Lyssna och läs vidare
Stefan, som leder Emberloom, berättar den här historien i två poddavsnitt.
Begreppen som används här förklaras roll för roll i Emberloom Shares begreppsbibliotek.