Bygger ni för pitch eller drift?
Sex månader är inte särskilt lång tid, men det räcker för att veta om en AI-pilot faktiskt funkar eller om den bara fungerade i demosalen. Det är den enklaste filtreringen jag har. När någon visar upp en pilot och vill ha applåder så frågar jag mig själv vad det här kommer kosta att äga om ett halvår. Inte vad det kostade att bygga. Inte vad det kostar att köra demot. Vad det kostar att äga.
Den frågan låter banal, men den sorterar tidigt. Min gissning är att många byggen inte ens går att besvara längs den linjen, eftersom ingen har räknat på det. Pitchen och produkten är två olika saker. Det är där vi börjar.
Pilot är förälskelse, drift är äktenskap
En pilot är som en första dejt. Allt får vara nytt. Du bjuder på dina bästa anekdoter, glömmer att berätta att du brukar snarka, och sopar undan sådant som inte passar in i bilden. Det är inte oärligt. Det är så piloter funkar. Du bygger den smalaste möjliga vägen från input till output där allt fungerar, och resten lämnar du i en kommentar eller i ett TODO.
Drift är något helt annat. Drift är när samma flöde har körts varje natt i fyra månader och någon ringer en söndag för att rapporten inte landade på fredagen. Drift är när Anthropic deprecatar en modellversion och du har sex flöden som hårdkodat modellnamnet i miljöfilen. Drift är när någon tankat upp ett gigantiskt PDF-dokument i din dokumentsökning och kostnaden för inbäddningar plötsligt är en helt annan post i budgeten.
När jag tittar på en pilot som någon vill ta vidare är det här jag fokuserar på först. Inte hur arkitekturen ser ut på pappret, utan hur den beter sig när någon använder den fel. För det är det som händer. Folk kommer använda den fel. Det är en av få saker du kan vara säker på i förväg.
Det vi tittar på i kvartal ett
Vi har satt ihop en intern checklista för de första månaderna med ett nytt system, tänkt att se likadan ut varje gång vi går igenom den. Jag fattar fortfarande inte varför så få byggteam sätter ihop något liknande själva. Det är inte raketforskning. Det är bara att skriva ner de mönster man vet sänker AI-system i drift, så man slipper lära sig dem på hårda vägen.
Första punkten är felhantering. I en demo skickar du in tre meningar, modellen svarar, du visar upp resultatet på en stor skärm. I drift skickar någon in en bild som tolkas som text eller ett helt tomt fält där det skulle stått en mening. Vad händer då. Returneras ett begripligt felmeddelande till användaren eller fastnar hela flödet i ett anrop som dör tyst i bakgrunden. Båda utgångarna är lika troliga om ingen provat.
Andra punkten handlar om att AI-svar inte är deterministiska. Det är en självklarhet som folk fortfarande blir överraskade av i månad fyra. Hur hanterar systemet att samma fråga ger två olika svar. Finns det validering på output, eller skickas allt rakt vidare till en slutkund som börjar undra varför offerten landade på ett belopp idag och ett annat igår. Jag tror att det är en av de mest underskattade källorna till förlorat förtroende.
Tredje punkten är observability, alltså insyn i vad systemet gör medan det kör. Hur ser du vad som händer i systemet just nu. Inte i förra veckan i en loggfil som ingen läser. Just nu. Vi lägger LiteLLM som proxy framför alla modellanrop, plus en enkel Postgres-tabell där varje anrop får ett spår. Inget märkvärdigt. Det räcker för att kunna svara på frågan "varför svarade boten det här" två veckor senare, vilket är den fråga som förr eller senare ställs.
Det vi räknar på i kvartal fyra
Kostnadsbilden i AI-system är konstig på ett sätt som många missar i början. Det är inte som AWS-fakturan där du har ett ganska bra mentalt grepp om vad varje resurs gör. Det är mer som mobilräkningen 2008 där du plötsligt har ringt till Polen för en förskräckande summa utan att veta hur det gick till.
I kvartal fyra ska man sätta sig ner och faktiskt titta på vad systemet har kostat. Inte vad det skulle kosta enligt offerten. Vad det kostade. Sen jämför man mot vad det gör. Ta ett räkneexempel med påhittade tal: en AI-funktion som kostar några tusenlappar i månaden och sparar två heltidstjänster är en bra affär, medan samma kostnad för fem sparade minuter per dag åt en handläggare betyder att man får tänka om.
Det här är platsen där cloud versus lokalt börjar bli intressant på riktigt. I kvartal ett är det oftast rätt att lägga allt på Anthropic Claude eller OpenAI gpt-5.4, eftersom det är snabbaste vägen till värde. När kvartal fyra kommer och trafiken är förutsägbar blir Llama 3.1 70B eller Qwen2.5 på en egen GPU intressant att titta på. Inte för att det är coolare. För att räkningen kan säga att det är värt det.
Sen finns det den andra sidan. Vägen går lika gärna tillbaka från lokalt till moln, när en öppen modell visar sig dra så mycket längre svarstid att användarna tappar tålamodet. Det finns inget principiellt svar här. Det är räkneövningar varje halvår.
Vem äger systemet när konsulten gått hem
Det här är den fråga som borde ställas mycket tidigare än den brukar. Vem äger det här systemet om sex månader. Inte juridiskt. Operativt. Vem är personen som blir ringd på söndagskvällen när chatboten börjat svara på engelska till en svensk kund.
Vi har en princip internt som handlar om att ingenting vi bygger får vara beroende av att vi är kvar. Det betyder att alla prompts ska ligga i versionskontroll i en repo som kunden äger. Alla modellanrop går via LiteLLM eller motsvarande proxy, så att byta från Anthropic Claude till en lokal Llama 3.1 70B blir en config-ändring och inte en omskrivning. Data bor i kundens egen Postgres eller Supabase, inte i någon SaaS-tjänst vi har konto hos. Vi kan logga in när det behövs, men vi vill aldrig vara den enda som kan grejen.
Min teori är att en stor del av AI-skulden i svenska bolag just nu beror på piloter som byggdes utan att någon tänkte på överlämning. Konsulten levererade, faktura skickades, sen försvann konsulten. Sex månader senare sitter en utvecklare på kundsidan och försöker förstå varför chatboten plötsligt börjat hallucinera priser, utan att ens veta vilken modellversion som används bakom.
Det är inte konsultens fel ensam. Det är ofta inte tydligt vid avtalsstart vem som ska kunna det här systemet om sex månader. Vi ställer frågan i första mötet. Det kostar ingenting att göra, och jag tror att det är den billigaste förbättringen ett projekt kan få.
Sex månader senare-frågan styr besluten idag
När jag jobbar med ett system och behöver välja mellan två tekniska lösningar så är det här en av de mer användbara mentala genvägarna jag har. Hur kommer det här se ut om sex månader. Den ena lösningen är snabbare att bygga och klart svårare att förvalta. Då vet jag svaret. Den andra är lite klumpigare initialt men lättare för någon annan att ta över. Då vet jag också svaret.
Det här är inte alltid det som imponerar. Det betyder att vi hellre rekommenderar lösningar som ser tråkigare ut än vad som skulle imponerat på en styrelse. Vi väljer Postgres med pgvector framför en specialiserad vektordatabas när det redan finns en Postgres som teamet förstår. Vi bygger hellre på FastAPI än på något nyare framework när det är vad utvecklarna redan kan. Ibland är n8n rätt val för flöden där en LangGraph-orkestrering hade varit smartare, om någon på kundsidan vill kunna ändra själv utan att ringa oss.
Det jag är trött på är att höra arkitekter prata om "best of breed", alltså att alltid välja den vassaste komponenten i varje led, som om det vore en dygd i sig. Det är det inte. Det vassaste på pappret är ofta bara det som ser bäst ut i en demo. Det som håller i drift är ofta något ganska tråkigt som funkar.
Min uppfattning är att de bolag som får ut mest värde av AI är de som valt enklare arkitektur och kört den länge, snarare än de som hoppar på varje ny modell och varje nytt ramverk varje månad. Det finns ett värde i att inte byta. Det värdet är svårt att kvantifiera, men det är verkligt och det syns i fakturan.
Om du sitter med en pilot just nu
Om du sitter med en pilot som du funderar på att skala upp så är det här ungefär det jag skulle göra först. Ta fram en lista över alla externa beroenden. Modeller, API-nycklar, allt som faktureras månadsvis. Räkna sedan ut vad varje beroende skulle kosta om trafiken tiodubblas. Du kommer bli förvånad. Vissa kostnader skalar linjärt. Andra hoppar plötsligt vid en viss volym för att du går över i en annan prisnivå.
Sen tittar du på vem som faktiskt kan systemet. Om det är en person så har du ett problem, oavsett om personen är intern eller konsult. Om det är noll personer har du ett större problem. Två personer som båda varit inne i koden under det senaste kvartalet är enligt mig minimum för att kalla något ett produktionssystem.
Och slutligen, kör en simulering där du låter någon medvetet använda systemet fel. Ingen formell penetrationstest. Bara någon som klickar på fel knapp och skickar in tjugo förfrågningar parallellt utan paus. Se vad som händer. Om svaret är "vet inte, det har vi aldrig testat" så är det inte ett produktionssystem ännu, oavsett vad pitchen från sex månader sedan sade.
Det här är sådant vi arbetar med på Kapaciti. Hör av dig om du sitter med ett liknande problem.