Vi körde en AI-workshop med 12 mellanchefer. Här är vad de inte visste

Det var en tisdag i mars och vi hade bokat in tolv mellanchefer från ett medelstort industriföretag i Västerbotten. Uppdraget var en halvdagsworkshop om AI i verksamheten. Inte en säljpitch, utan ett ärligt samtal om vad tekniken faktiskt gör, vad den kostar och var den passar. Vi hade förberett demos, kostnadskalkyler och tre konkreta case från deras egen bransch. Det som slog oss hårdast var inte vad deltagarna frågade, utan vad de tog för givet. Missförstånden var systematiska, och de dyker upp på nästan varje workshop vi kör.

ChatGPT är inte samma sak som AI i er verksamhet

Den vanligaste ingången vi möter är att någon i ledningsgruppen har testat ChatGPT privat, blivit imponerad och sedan föreslagit att "vi borde använda AI". Det är ungefär som att ha kört en Tesla på provkörning och sedan föreslå att företaget ska bygga en elbilsfabrik. ChatGPT i webbläsaren och ett API-anslutet AI-flöde i er verksamhet är fundamentalt olika saker, och skillnaden handlar inte bara om teknik utan om styrning, säkerhet och kostnad.

När en medarbetare klistrar in kunddata i ChatGPT skickas den informationen till OpenAI:s servrar. Det som händer med datan beror på vilken plan ni har, vilka villkor som gäller och hur modellen tränas. Med ett API-anrop har ni kontroll. Ni bestämmer vilken data som skickas, ni loggar varje anrop, ni kan köra trafiken genom en gateway som filtrerar känslig information innan den lämnar ert nätverk. Det är därför säkerhetsavdelningen bryr sig om skillnaden. Inte för att de vill bromsa innovation, utan för att de behöver veta var datan tar vägen.

På workshopen hade tre av tolv deltagare redan använt ChatGPT för att sammanfatta styrelseprotokoll. Ingen hade kollat med IT. Det är inte illvilja, det är ett systemfel: organisationen har inte gett folk ett legitimt verktyg, så de hittar egna vägar. Lösningen är inte att förbjuda, utan att erbjuda en kanal som uppfyller samma behov med rätt styrning.

Hallucinationer är inte ett modellfel, det är en designfråga

Ordet "hallucination" har blivit ett slagträ i diskussionen om AI. Vi hör det på varje workshop, oftast formulerat som "men modellen hittar ju på saker". Det stämmer, men förklaringen stannar där för de flesta. Det som saknas är förståelsen för varför modellen hittar på, och att det i hög grad går att styra.

En språkmodell genererar text genom att förutsäga nästa token baserat på sannolikhet. Utan kontext gissar den utifrån sin träningsdata. Med rätt kontext, exempelvis ett specifikt dokument, en databas eller en uppsättning regler, kan den grunda sina svar i fakta istället för statistiska mönster. Det kallas grounding, och det är kärnan i nästan varje produktionsflöde vi bygger.

Ett konkret exempel: en av workshopdeltagarna berättade att de hade testat att låta ChatGPT svara på kundfrågor om deras produkter. Resultatet var att modellen uppfann specifikationer som inte existerade. Problemet var inte att modellen var dålig. Problemet var att den inte hade tillgång till produktdatabasen. Den fick en fråga utan kontext och gjorde det enda den kan, den genererade ett plausibelt svar. Lösningen handlar om att mata modellen med rätt information vid rätt tillfälle, inte om att vänta på en modell som aldrig gissar fel.

Vi brukar säga att hallucinationer är ett symptom, inte en diagnos. Symptom på att flödet saknar grounding, att prompten är för öppen, eller att modellen ombeds svara på något den inte borde svara på alls. Behandlingen är arkitektur, inte tålamod.

Token-ekonomi: från 30 öre till 30 kronor

Kostnadsbilden för AI-anrop är något som förvånar nästan alla vi pratar med. Antingen tror folk att det är gratis (för att de betalar 20 dollar i månaden för ChatGPT Plus och extrapolerar därifrån) eller så tror de att det är orimligt dyrt (för att de hört om företag som fått fakturor på hundratusentals kronor).

Verkligheten beror helt på vad ni gör. Ett enkelt klassificeringsanrop, där ni skickar ett kort kundmeddelande och ber modellen sortera det i rätt kategori, kostar kanske 0,3 öre. Tusen sådana anrop om dagen landar på tre kronor. Det är ingenting. Men om ni tar ett helt styrelseprotokoll på 40 sidor, skickar in det som kontext tillsammans med en komplex fråga och ber modellen producera en sammanfattning med källhänvisningar, kan ett enda anrop kosta 15 till 30 kronor beroende på modell.

Skillnaden handlar om tokens. En token är ungefär tre fjärdedels ord på svenska. Varje token ni skickar in kostar pengar, och varje token modellen genererar kostar ännu mer. En typisk A4-sida med text är cirka 500 tokens. Ett kontrakt på 80 sidor är 40 000 tokens. Priset skalas linjärt, så designbesluten avgör allt. Ska hela dokumentet in varje gång, eller räcker ett relevant utdrag? Ska modellen skriva en sida eller ett stycke? De frågorna avgör om ert AI-flöde kostar 50 kronor i månaden eller 5 000.

Vi visade en kalkyl på workshopen. Ett flöde som klassificerar och dirigerar inkommande ärenden för deras kundtjänst, med ungefär 200 ärenden per dag, landade på cirka 180 kronor i månaden i API-kostnad. Reaktionen var nästan besviken. "Så lite?" Jo, för att jobbet som görs är litet per anrop. Det är volymen gånger komplexiteten som bestämmer notan, och de flesta operativa flöden är enkla anrop i stor volym.

Context window är inte oändligt, och det påverkar era dokument

En av de mer tekniska punkterna, men en som har direkta konsekvenser för hur ni designar AI-lösningar: modellen ser inte allt på en gång. Den har ett context window, en maxgräns för hur mycket text den kan ta in och producera i ett enda anrop. För de modernaste modellerna ligger den gränsen på mellan 100 000 och 200 000 tokens, alltså ungefär 300 till 600 sidor text.

Det låter generöst, och det är det i många fall. Men det finns två problem. Det första är kostnaden vi just pratade om. Att fylla context window till max kostar pengar varje gång. Det andra är mer subtilt: modeller presterar sämre mitt i långa texter. Forskningen visar att information som ligger i början och slutet av kontexten får mer uppmärksamhet än det som ligger i mitten. Det kallas "lost in the middle"-fenomenet och det betyder att ni inte kan slänga in 200 sidor och hoppas på det bästa.

I praktiken innebär det att era AI-flöden behöver ett steg som väljer ut rätt information innan den skickas till modellen. Det kan vara en enkel sökning i en vektordatabas, en regelbaserad filtrering eller en kombination. Poängen är att den som designar flödet måste tänka på vilken information modellen behöver för just den uppgiften, inte bara skicka allt som finns. Det är som att ge en ny medarbetare en pärm med rätt avsnitt markerade istället för att tippa företagets hela filserver på skrivbordet.

På workshopen testade vi detta live. Vi tog ett 90-sidigt kvalitetsdokument som företaget använder och ställde samma fråga två gånger: en gång med hela dokumentet som kontext, en gång med bara det relevanta avsnittet (fem sidor). Svaret från det kortare anropet var mer precist, snabbare och kostade en tiondel. Flera i rummet nickade igenkännande. Mindre är ofta mer, även med AI.

Att vänta på bättre modeller är en fälla

Det sista missförståndet är kanske det mest skadliga, för det förklär sig som försiktighet. "Vi väntar tills tekniken mognar." Det är en rimlig hållning om man pratar om kvantdatorer eller kärnfusion. Det är en farlig hållning när konkurrenterna redan automatiserar sina flöden.

Anledningen är enkel: värdet av AI i verksamheten ligger inte i modellen, utan i integrationen. Att koppla ihop en modell med ert ärendesystem, era produktdata, era processer. Det arbetet tar tid, kräver intern kompetens och förändring i arbetssätt. Det arbetet försvinner inte när nästa modellgeneration kommer. Tvärtom, det blir mer värdefullt, för en bättre modell i samma integration ger bättre resultat utan att ni behöver bygga om.

De företag som väntar bygger inte kompetens. De lär sig inte var AI passar och inte passar i just deras verksamhet. De har inga interna champions som förstår begränsningarna. När de väl bestämmer sig att "nu är det dags" står de med en kompetensklyfta som tar sex till tolv månader att täppa till, medan deras konkurrenter redan itererar på sin tredje version.

Vi brukar rekommendera att börja med ett avgränsat pilotprojekt. Inte för att tekniken kräver det, utan för att organisationen gör det. Välj ett flöde som är repetitivt, mätbart och inte affärskritiskt. Bygg det, mät resultatet, lär er av processen. Kostnaden för en pilot är försumbar jämfört med kostnaden av att stå still i tolv månader.

Det handlar inte om att veta allt, utan om att veta rätt saker

Workshopen avslutades inte med en sammanfattning eller en checklista. Den avslutades med en öppen fråga: givet det ni nu vet, vilket enda flöde i er verksamhet skulle ni vilja testa först? Svaren var specifika och realistiska. Ärendesortering. Offertgranskning. Dokumentsammanfattning inför ledningsgruppsmöten. Ingen föreslog att ersätta hela avdelningar eller bygga en egen GPT.

Det var den viktigaste insikten från dagen. Inte att deltagarna lärde sig vad tokens eller context windows är (även om det hjälper), utan att de slutade se AI som en magisk svart låda och började se det som ett verktyg med specifika egenskaper, begränsningar och kostnader. Ett verktyg man kan resonera om, fatta beslut kring och ställa krav på. Det är utgångspunkten för allt vi bygger, och det enda rådet vi skickar med varje grupp: förstå verktygen innan ni fattar beslut om dem, men vänta inte med att förstå dem.