Så skriver du en kravspec för ett AI-projekt

Om du någonsin har varit med om att köpa in eller bygga traditionell mjukvara vet du exakt hur en klassisk kravspecifikation ser ut. Den är ofta hundratals sidor lång och fylld med detaljerade skall-krav, processkartor och exakta beskrivningar av hur varje enskild knapp och meny ska fungera. Den lämnar helt enkelt inget åt slumpen.

När du försöker använda exakt samma mall för ett AI-projekt kommer du att krascha hårt.

Problemet är att traditionell mjukvara är deterministisk. Om du klickar på knapp A händer B. Varje gång, utan undantag. AI är däremot probabilistiskt. Det handlar om sannolikheter, mönsterigenkänning och kvalificerade gissningar. Du kan ju inte kravställa exakt hur en AI ska bete sig i varje tänkbar situation. Hela poängen med att använda AI är faktiskt att den ska kunna hantera situationer, frågor och data som du inte har tänkt på i förväg.

Så hur gör man då? Hur kravställer man något som är oförutsägbart till sin natur? Hur ser man till att man får det man betalar för när man inte kan specificera exakt hur slutresultatet ska bete sig i varje given sekund?

Släng den gamla mallen och tänk nytt

Det första och viktigaste du måste göra är att sluta tänka i termer av specifika funktioner och börja tänka i termer av utfall och värdeskapande. En bra kravspecifikation för ett AI-projekt handlar betydligt mindre om hur systemet ska fungera under huven. Den handlar mycket mer om vad det ska åstadkomma och vilka ramar det måste hålla sig inom för att inte ställa till skada.

Här är de fem viktigaste delarna du måste ha med i din kravspecifikation när du beställer eller planerar ett AI-projekt.

1. Det faktiska affärsproblemet (inte lösningen)

Det låter som en självklarhet, men det glöms ofta bort i ivern att implementera ny teknik. Många kravspecifikationer vi ser börjar med att man behöver en AI-chattbot som kan svara på kundfrågor på hemsidan.

Det där är inte ett problem. Det är en förutbestämd lösning.

Det verkliga problemet kanske är att kundtjänsten lägger 40 % av sin arbetstid på att svara på samma fem återkommande frågor om returer och leveranstider. Detta leder till oacceptabelt långa kötider för kunder med komplexa ärenden som faktiskt kräver mänsklig hjälp.

När du definierar problemet istället för lösningen ger du utvecklarna och AI-experterna frihet att hitta den bästa vägen dit. Kanske är en chattbot rätt väg att gå. Kanske är det mycket mer effektivt att bygga ett system som automatiskt kategoriserar, besvarar och stänger inkommande mejl. Lås inte fast er vid en specifik teknisk lösning för tidigt i processen. Beskriv smärtan, inte plåstret.

2. Definitionen av "tillräckligt bra" (framgångsmått)

I traditionell mjukvaruutveckling är målet ofta att systemet ska vara 100 % felfritt. En miniräknare eller ett bokföringssystem som räknar rätt 95 % av gångerna är helt värdelöst. En AI som klassificerar inkommande supportärenden rätt 95 % av gångerna kan däremot spara företaget miljontals kronor varje år.

Du måste definiera vad som är tillräckligt bra för att projektet ska betraktas som en framgång. Vilken träffsäkerhet krävs för att lösningen ska skapa värde? Vad händer när AI:n har fel? För den kommer att ha fel, det är oundvikligt.

Ett bra sätt att tänka här är att jämföra med hur ni gör idag. Om en människa gör rätt i 90 % av fallen när de utför en monoton uppgift, kanske det räcker att AI:n når 85 % om den gör det tusen gånger snabbare och aldrig tar kafferast. Eller så kräver er process att AI:n når 99 % innan den får agera på egen hand. Fram tills dess ska den kanske bara fungera som ett stöd som ger förslag till en mänsklig handläggare. Definiera era acceptanskriterier tydligt.

3. Data: Vad har vi, och hur ser den egentligen ut?

AI är ingenting utan data. Din kravspecifikation måste innehålla en ärlig utvärdering av er befintliga data.

Var finns datan? Är den snyggt strukturerad i en modern databas, eller ligger den utspridd i tusentals osorterade PDF-filer på en gammal filserver? Vem äger datan? Finns det personuppgifter (GDPR) eller annan känslig affärsinformation som måste tvättas bort innan den kan användas?

Många AI-projekt misslyckas för att man upptäcker halvvägs in att datan man trodde man hade antingen inte existerar, är av usel kvalitet eller är inlåst i ett gammalt system som helt saknar API:er. Var ärlig här. Om er data är en enda röra, skriv det. Det påverkar i allra högsta grad vad ett AI-projekt kostar och hur lång tid det kommer att ta att genomföra.

4. Riskhantering och ovanliga scenarier

Eftersom AI är probabilistiskt måste du planera för när saker går fel. Vad är det värsta som kan hända om systemet fattar fel beslut?

Om en AI rekommenderar fel film på Netflix är skadan minimal. Om en AI fattar fel beslut om ett banklån eller en medicinsk diagnos är konsekvenserna mycket allvarliga. Din kravspecifikation måste lista de största riskerna och hur de ska hanteras.

Ska systemet ha en reservmekanism där det lämnar över till en människa om det är osäkert? Hur mäter vi osäkerhet? Vilka ovanliga men möjliga scenarier måste systemet absolut kunna hantera korrekt? Genom att definiera dessa risker tidigt kan utvecklarna bygga in skyddsnät från dag ett.

5. Ramar, begränsningar och etik

Här sätter du upp staketet som AI:n får leka innanför. Det handlar givetvis om klassiska projektramar som budget, tidsramar och tekniska begränsningar. Ett exempel kan vara att lösningen måste fungera i er befintliga molnmiljö. I AI-projekt handlar det dock lika mycket om etik och varumärke.

Får AI:n fatta egna beslut som påverkar kunder direkt, eller ska den alltid ha en människa i loopen? Vilka källor får den hämta information från? Finns det specifika ord, konkurrenter eller ämnen den absolut inte får nämna? Vilken personlighet och ton ska den ha om den kommunicerar med kunder?

Vad du ska skippa helt och hållet

Lika viktigt som vad du tar med är vad du medvetet utelämnar.

Skippa de djupa tekniska detaljerna. Du behöver inte skriva om ni ska använda RAG, finjustering, vektordatabaser eller vilken specifik språkmodell från OpenAI eller Anthropic som ska ligga i botten. Det är tekniska arkitekturbeslut som bör fattas av de experter som bygger systemet, baserat på det affärsproblem och de begränsningar du har beskrivit. Tekniken utvecklas så snabbt att den modell du kravställer idag kan vara föråldrad när projektet väl startar.

Skippa också kraven på att systemet ska vara perfekt eller aldrig göra fel. Om du kräver 100 % träffsäkerhet kommer du aldrig att få ett färdigt system. Du kommer bara att bränna pengar på oändliga justeringar.

Börja smått och bevisa värdet

Det sämsta du kan göra är att skriva en massiv kravspecifikation för ett gigantiskt, företagsövergripande AI-system som ska lösa alla era problem på en och samma gång. Risken för misslyckande är stor, och det kommer att ta månader innan ni ser något som helst värde.

Bryt istället ner det. Hitta ett specifikt, avgränsat problem där AI kan göra stor skillnad snabbt. Skriv en kort, koncis kravspecifikation för just det problemet. Ett utmärkt sätt att testa vattnet och validera er idé är att bygga en PoC på en vecka. Då får ni snabbt se om tekniken faktiskt kan lösa ert problem i praktiken, med er egen data, innan ni plöjer ner tid och pengar i ett fullskaligt implementationsprojekt.

Att kravställa AI handlar i slutändan om att acceptera en viss grad av osäkerhet. Du bygger inte ett statiskt kugghjul som ska snurra exakt likadant varje gång. Du anställer i praktiken en digital medarbetare. Ge den tydliga mål, rätt verktyg, tillgång till bra information och tydliga gränser för vad den får och inte får göra, så kommer den nog att överraska dig positivt.

Det fina med AI just nu är att tröskeln aldrig varit lägre. Verktyg som för två år sedan krävde ett helt utvecklingsteam kan idag sättas upp på veckor. Det handlar inte om att bygga om hela företaget över en natt, utan om att hitta rätt ställe att börja på. Om du funderar på hur ni bäst kommer igång med AI i er verksamhet får du gärna prata med oss. Vi hjälper er gärna att bolla idéer och se vad som faktiskt är möjligt att göra.