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 jag har upptäckt att den är diskvalificerande tidigt. Många byggen klarar inte att ens besvaras längs den linjen, för ingen har räknat på det. Pitchen och produkten är inte samma sak. 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 80 MB stort PDF-dokument i din RAG-pipe och embedding-kostnaden gick från 12 dollar i månaden till 340.
När vi sitter och tittar på piloter som vi ska ta över så är det här jag fokuserar på först. Inte hur arkitekturen ser ut på pappret. 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 en intern checklista som vi går igenom i de första månaderna när vi tar in nya system. Den ser ut ungefär likadant varje gång, men jag fattar fortfarande inte varför så få byggteam använder något liknande själva. Det är inte raketforskning. Det är bara att skriva ner det man har lärt sig av att se grejer braka, så man slipper lära sig samma sak igen.
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 LangGraph-anrop som dör tyst i bakgrunden. Vi har sett båda.
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å 1290 kronor idag och 1450 igår. Det är en av de mest underskattade källorna till förtroendetapp jag har sett.
Tredje punkten är observability. 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 använder oftast en kombination av LiteLLM som proxy framför alla modellanrop, plus en enkel Postgres-tabell för traces. Inget fancy. Det räcker för att kunna svara på frågan "varför svarade boten det här" två veckor senare, vilket är ungefär den frågan som faktiskt 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 14 000 kronor utan att veta hur det gick till.
I kvartal fyra brukar vi sätta oss ner med kunden och faktiskt titta på vad systemet har kostat. Inte vad det skulle kosta enligt offerten. Vad det kostade. Sen jämför vi mot vad det gör. Om en AI-funktion kostar 8000 kronor i månaden men sparar två heltidsanställda så är det en bra deal. Om den kostar 8000 kronor i månaden och sparar fem minuter per dag åt en handläggare så får vi tänka om.
Det här är platsen där cloud versus lokalt börjar bli intressant på riktigt. För många system har vi i kvartal ett lagt allt på Anthropic Claude eller OpenAI gpt-5.4, eftersom det är snabbast väg till värde. När vi kommer fram till kvartal fyra och trafiken är förutsägbar så börjar vi titta på Llama 3.1 70B eller Qwen2.5 på en egen GPU via Ollama. Inte för att det är coolare. För att räkningen säger att det är värt det.
Sen finns det den andra sidan. Vi har också flyttat saker tillbaka från lokalt till moln när det visade sig att en open-source-modell drog tre gånger så lång svarstid och vi tappade användare på vägen. 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 loggar 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 försöker ställa frågan i första mötet nuförtiden. Det är en av de saker som faktiskt har förbättrat våra projekt mest, och som kostat noll kronor att införa.
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 30 procent snabbare att bygga men 60 procent 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 populärt. Det betyder ibland att vi rekommenderar lösningar som ser tråkigare ut än vad som skulle imponerat på en styrelse. Vi använder Postgres med pgvector istället för en specialiserad vektordatabas, eftersom det redan finns en Postgres som teamet förstår. Vi bygger på FastAPI istället för något nyare framework, eftersom det är vad utvecklarna har sett i sex år. Ibland väljer vi n8n för flöden där en LangGraph-orkestrering hade varit smartare, för att 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" som om det vore en oberoende dygd. Det är det inte. Best of breed betyder ofta best at demos. Det som är best at drift är ofta något ganska tråkigt som funkar.
Det vi ofta ser i fältet är att de bolag som fått ut mest värde av AI under det senaste året är de som har valt enklare arkitektur men kört den länge. Inte de som hoppat på varje ny modell och varje nytt framework 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. Vi brukar säga att två personer som båda har varit inne i koden under det senaste kvartalet är minimum för att kalla något för 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.
På Kapaciti gör vi mycket av det här. Hör av dig om du sitter med ett liknande problem.