Vad du verkligen ska be din AI-leverantör om i offerten

Det börjar nästan alltid likadant. Ett svenskt bolag med 30 till 150 anställda bestämmer sig för att automatisera någonting. Kanske kundtjänst, kanske intern dokumenthantering, kanske en pipeline som i dag kräver tre personer och ett Excel-ark. De skickar ut en förfrågan till två eller tre leverantörer, får tillbaka offerter med fina ord om "intelligent automation" och "skräddarsydda lösningar", och väljer den som ser mest trovärdig ut till rimligast pris. Sex månader senare sitter de fast. Inte för att tekniken inte fungerar, utan för att de aldrig ställde rätt frågor från början.

Vi på Kapaciti har sett det mönstret tillräckligt många gånger för att veta att problemet sällan är den tekniska lösningen i sig. Det är vad som inte står i offerten. De flesta AI-leverantörer skickar dokument som beskriver funktionalitet, tidsplan och pris. Det som saknas är det som avgör om du fortfarande har kontroll om två år, om du kan byta leverantör utan att börja om från noll, och om du faktiskt kan förstå vad systemet gör med dina kunders data varje dag.

Modellberoende och vad som händer när priset tredubblas

De flesta AI-lösningar som byggs i dag vilar på en extern språkmodell. OpenAI, Anthropic, Google, eller någon av de mindre aktörerna. Det är i sig inget fel med det. Men det skapar ett beroendeförhållande som väldigt få offerter adresserar explicit. Frågan du behöver ställa är enkel: vad händer om leverantören av den underliggande modellen höjer sitt pris med faktor tre? Det är inte ett hypotetiskt scenario. OpenAI har justerat sin prissättning flera gånger sedan lanseringen, och marknaden är fortfarande i ett skede där prismodeller kan förändras snabbt.

En seriös AI-leverantör ska kunna svara på vilken eller vilka modeller lösningen använder, hur hårt systemet är kopplat till just den modellen, och vad som krävs för att byta. Om svaret är "vi kan migrera till en annan modell på ett par veckor" vill du veta vad det innebär i praktik. Behöver alla prompts skrivas om? Måste finetuning göras från grunden? Finns det abstraktionslager som gör bytet hanterbart, eller är varje API-anrop hårdkodat mot en specifik leverantör?

Vi byggde nyligen en dokumentklassificerare åt ett fastighetsbolag i Mellansverige. Från dag ett designade vi systemet med ett modell-agnostiskt gränssnitt. När kunden efter tre månader ville testa en billigare modell för enklare ärenden kunde vi byta ut den underliggande motorn på en eftermiddag, utan att röra resten av arkitekturen. Den flexibiliteten var inte en lyxfunktion. Den var en direkt konsekvens av att kunden ställde frågan tidigt i processen.

Vem äger vad när samarbetet tar slut

Det här är den fråga som flest missar helt, och den som gör mest ont i efterhand. När du anlitar en leverantör för att bygga en AI-lösning skapas en rad tillgångar under projektets gång. Prompts som finjusterats under veckor av iteration. Finetunade modeller som tränats på din data. Embeddings som representerar ditt företags samlade kunskap i vektorform. Dataset som kuraterats och rensats. Pipelines som kopplar ihop allt.

Frågan är brutalt konkret: vem äger de här sakerna om ni avslutar samarbetet? Kan du exportera dina embeddings i ett standardformat? Får du behålla de prompts som utvecklats? Har du rätt att ta med dig den finetunade modellen, eller sitter den låst i leverantörens infrastruktur? Det är inte ovanligt att leverantörer betraktar prompts och pipelines som sin intellektuella egendom. Det kan vara helt rimligt i vissa fall, men du behöver veta det innan du skriver på.

En exit-klausul i avtalet ska specificera exakt vilka artefakter du har rätt till, i vilka format de levereras, och inom vilken tidsram efter avslutat samarbete. Om leverantören tvekar att skriva det svart på vitt bör du fundera på varför. Ett bolag vi arbetade med hade byggt sin hela reklamationsprocess på en AI-lösning från en annan leverantör. När de ville byta fick de reda på att alla prompts och den finetunade modellen "tillhörde plattformen". De fick börja om. Tre månaders arbete och ett par hundra tusen kronor, borta.

Kan du se vad agenten faktiskt gjorde i går

Observability är ett begrepp som de flesta tekniker förstår men som sällan dyker upp i affärsofferter. I en traditionell IT-lösning har du loggar, dashboards och notifieringar som visar dig vad systemet gjort. I en AI-lösning är det inte självklart. Många agentbaserade system fungerar som svarta lådor: du ser resultatet men inte processen. Det är ett problem.

Du vill kunna svara på frågor som: hur många ärenden hanterade AI-agenten i går? Vilka beslut tog den? Hur ofta eskalerade den till en människa, och varför? Vilka ärenden tog längst tid, och vad var det som orsakade fördröjningen? Utan den typen av insyn flyger du blint. Du kan inte optimera det du inte kan mäta, och du kan inte felsöka det du inte kan observera.

Be din leverantör visa ett konkret exempel på hur loggning och spårbarhet fungerar i deras lösning. Inte en mockup eller en PowerPoint, utan faktisk data från ett liknande projekt. Varje anrop till en språkmodell bör loggas med input, output, latens och kostnad. Varje beslut som agenten fattar bör kunna spåras tillbaka till en specifik kontext. Det handlar inte om att misstro tekniken. Det handlar om att kunna svara när din kund, din styrelse eller Datainspektionen frågar vad som hände.

Vi loggar varje modell-anrop med fullständig kontext. Det innebär att vi kan gå tillbaka tre veckor och visa exakt varför systemet klassificerade ett visst ärende som det gjorde, vilken data det baserade beslutet på, och hur lång tid det tog. Den transparensen kostar nästan ingenting att bygga in från start, men den är extremt dyr att lägga till i efterhand.

Var lagras dina kunders data, och vem har tillgång

Säkerhetsfrågan i AI-projekt är mer komplex än i traditionell systemutveckling, av en specifik anledning: din data skickas ofta till tredjepartstjänster för inferens. När en kund skriver ett meddelande till din AI-drivna kundtjänst kan det meddelandet hamna på OpenAIs servrar i USA, bearbetas där, och svaret skickas tillbaka. Det är inte nödvändigtvis fel, men du behöver veta att det sker och vad det innebär juridiskt och avtalsmässigt.

Fråga leverantören var data lagras i vila och under transport. Fråga vilka tredjeparter som har tillgång till data under bearbetning. Fråga hur länge data sparas hos respektive part, och vad som händer med den efteråt. Fråga om data används för att träna modeller hos tredjeparten, och i så fall om det går att stänga av. De flesta stora modell-leverantörer erbjuder alternativ där din data inte används för träning, men det måste aktiveras explicit. Din AI-leverantör bör kunna visa att det är gjort.

För bolag som hanterar personuppgifter, hälsodata eller finansiell information är det här inte förhandlingsbart. GDPR ställer krav på att du vet var data behandlas och att du har laglig grund för överföring utanför EU. Om din leverantör inte kan svara tydligt på var dina kunders data hamnar fysiskt, ner till region och datacenter, är det en varningssignal som inte ska ignoreras.

SLA, latens och ett kostnadstak du faktiskt kan lita på

AI-system har en egenskap som skiljer dem från de flesta andra IT-lösningar: kostnaden per operation varierar med användningen och ibland med längden på konversationen. Ett supportärende som kräver tio tur-retur-anrop kostar tio gånger mer i tokens än ett som löses på ett svar. Det gör kostnadsplanering svårare, och det gör SLA-frågan mer intressant.

En bra offert specificerar ett kostnadstak per kund eller per period. Det skyddar dig mot scenariot där ett oväntat högt antal ärenden, eller en plötslig ökning i genomsnittlig konversationslängd, driver kostnaden långt bortom vad du budgeterade. Utan ett sådant tak tar du all finansiell risk medan leverantören har noll.

Latens är en annan dimension som sällan syns i offerter men som påverkar användarupplevelsen direkt. Om din AI-agent tar fyra sekunder att svara en kund i en chatt är det en helt annan produkt än en som svarar på 800 millisekunder. Fråga vilken genomsnittlig svarstid leverantören garanterar, och vad som händer vid toppbelastning. Fråga vad som händer om den underliggande modell-leverantören har driftstörning. Finns det fallback? Köas förfrågningar eller tappas de?

Vi specificerar alltid P95-latens i våra avtal, alltså den svarstid som 95 procent av alla anrop ligger under. Vi sätter kostnadstak per månad med automatisk notifiering vid 80 procent av taket. Det är inte komplicerat att göra. Det kräver bara att någon insisterar på att det ska finnas med.

Frågorna som förändrar maktbalansen

Det gemensamma i alla de här punkterna är att de flyttar maktbalansen. En offert som bara beskriver funktionalitet ger leverantören tolkningsföreträde på allt annat. En offert som adresserar modellberoende, äganderätt, observability, datasäkerhet och kostnadstak ger dig som beställare kontroll och valmöjlighet.

Ingen av de här frågorna är orimliga att ställa. Ingen seriös leverantör borde bli förvånad av dem. Tvärtom, en leverantör som reagerar positivt och har genomtänkta svar är sannolikt en leverantör som byggt system som faktiskt fungerar i produktion, inte bara i demo. Om du bara tar med dig en sak från den här texten, låt det vara detta: be om ett konkret exempel. Inte en förklaring av hur det "borde" fungera, utan faktisk output från ett befintligt system. Be att få se loggarna. Be att få se exit-klausulen i ett befintligt kundavtal. Be att få se vad som händer när modellen byts ut. Det är i detaljerna du ser skillnaden mellan en leverantör som förstår vad de bygger och en som bara säljer det.