Kortversion: AI är ofta som mest användbar när den gör ett litet, avgränsat bedömningsjobb: sorterar ett supportärende, uppskattar om ett svar är relevant eller markerar ett foto som sannolikt skadat. Det är inte samma sak som att låta modellen avgöra pris, kredit, ersättning eller om en kund ska nekas hjälp. Bygg därför flödet så att modellen lämnar ett bedömningsunderlag, medan ert system tillämpar den regel som faktiskt får konsekvenser.
En ny typ av AI-API gör det enklare att få tillbaka just klassificeringar och sannolikheter i stället för en fri text. Det kan vara ett bra tillfälle att städa upp produktbeslut som idag ligger gömda i en lång prompt. Men tekniken gör inte ett osäkert beslut säkert av sig själv.
Börja med beslutet, inte med modellen
Många AI-funktioner börjar med frågan: "Kan vi få modellen att göra detta?" En bättre startfråga är: "Vilken del av flödet är osäker, och vad händer om bedömningen blir fel?"
Det skiljer tre saker som ofta blandas ihop:
- Fakta eller regler. Är kunden aktiv? Är ordern betald? Är garantin fortfarande giltig? Använd databasen och vanliga affärsregler.
- Bedömning av ostrukturerat material. Vilket team bör läsa ärendet? Verkar bilden visa en transportskada? Matchar svaret frågan? Här kan AI ge ett användbart underlag.
- Ett beslut med konsekvens. Ska kunden få återbetalning, ett lån eller åtkomst till känsligt material? Här måste ansvarig verksamhetsregel, rätt behörighet och ofta en människa ligga efter AI-bedömningen.
OpenAI:s Decisions API blev allmänt tillgängligt den 22 oktober 2026 och är byggt för den mellersta kategorin. Det kan returnera en sannolikhet för ett påstående, ett val ur en fast uppsättning eller ett resultat mot en skala. Dokumentationen beskriver exempel som att klassificera innehåll, styra ärenden och prioritera arbete. Det är ett gränssnitt för bedömning – inte en ursäkt att hoppa över era kontrollsteg.
Gör sannolikheten till ett underlag
Anta att ett supportflöde ska identifiera sannolika uppsägningsärenden. Modellen kan få läsa den inkommande texten och lämna en sannolikhet. Det rätta produktionsflödet är sällan:
Exempel på en regel att undvika: Sannolikhet över 0,5 – avsluta abonnemanget.
Ett robustare flöde kan i stället vara:
- Modellen märker ärendet som sannolikt uppsägningsrelaterat.
- Systemet kontrollerar kundens identitet, avtal och vilka självbetjäningsalternativ som finns.
- Vid hög säkerhet visas rätt formulär eller skapas ett prioriterat ärende.
- En människa eller en separat, dokumenterad regel godkänner den irreversibla åtgärden.
Ett högt sannolikhetsvärde är inte ett bevis för att bedömningen är korrekt i ert flöde. Testa gränsvärden på representativa exempel och ge osäkra eller oväntade ärenden en reservväg.
Sannolikheten hjälper alltså er att välja nästa steg. Den ska inte bli en dold affärsregel som ingen produktägare vet finns.
Välj rätt tekniskt kontrakt
En klassificeringsfunktion behöver ett tydligt kontrakt mellan produkt, utveckling och drift. Skriv det innan ni väljer endpoint:
1. Frågan måste kunna granskas
"Är detta ett brådskande supportärende?" är för vagt. "Indikerar texten att kunden inte kan logga in och att ett pågående köp påverkas?" är möjligt att testa. En bra fråga innehåller den avgränsning som en supportchef skulle använda vid manuell triage.
2. Svaren måste vara begränsade
För ärenderouting fungerar en liten, bestämd lista – exempelvis faktura, leverans, konto och tekniskt fel – bättre än en fri modelltext. För prioritet fungerar en dokumenterad skala bättre än ordet "bråttom". När svaret är typat kan ni logga, mäta och ändra regler utan att försöka tolka prosa i efterhand.
3. Gränsvärdet är en produktregel
Bestäm vem som äger gränsvärdet, vad som händer mellan två nivåer och hur länge beslutet ska sparas. Om tröskeln ändras från 0,80 till 0,65 är det en produktändring med kundpåverkan, inte bara en modelljustering.
En liten pilot som går att stoppa
API:t är allmänt tillgängligt och stöder enligt dokumentationen den 23 oktober 2026 bara modellen gpt-6-luna. Även en allmänt tillgänglig tjänst behöver testas i ert eget flöde. Välj därför ett användningsfall där ni kan jämföra AI:n med dagens arbetssätt och där ett fel kan rättas utan skada.
En lämplig pilot kan vara sortering av inkommande formulär till rätt kö. Undvik som första pilot beslut om betalning, behörighet, anställning, försäkring eller annan åtgärd som innebär betydande nackdel för en individ.
För varje pilot behöver ni minst:
- ett litet testset med verkliga, avidentifierade exempel och ett förväntat utfall;
- en reservväg när bedömningen är osäker, data saknas eller API:t inte svarar;
- dataminimerad loggning av frågans version, modellresultat, tröskel, efterföljande systemregel och faktisk utgång – inte hela kundtexten som standard;
- regelbunden stickprovskontroll av en person som förstår verksamheten;
- en enkel avstängningsknapp som återställer det tidigare flödet.
Mät inte bara träffsäkerhet. Mät även felroutningar, tid till lösning, antal manuella omtag och om vissa kundärenden systematiskt hamnar fel. Ett snabbt resultat som skapar merarbete för supporten är inte en vinst.
När behövs något annat?
Ett bedömnings-API är inte rätt verktyg när ni behöver generera en förklaring, extrahera ett större objekt enligt eget schema eller låta en modell begära ett verktygsanrop. OpenAI skiljer själv mellan dessa fall: deras guide hänvisar till Structured Outputs för egna JSON-strukturer och till function calling när modellen ska begära ett verktyg.
Det viktiga är inte vilken produktetikett som används, utan att gränsen är tydlig: AI:n får tolka ostrukturerat underlag, medan era regler och behörigheter styr vad som faktiskt sker.
Slutsats: beslutet att ta nu
Om ni har ett arbetsflöde där en människa idag sorterar, prioriterar eller gör en första enkel bedömning kan typade AI-svar vara värda en begränsad pilot. Sätt då en mätbar fråga, en liten uppsättning möjliga svar och en mänskligt ägd regel efteråt. Det är så AI blir en kontrollerbar del av produkten – inte en ny, osynlig beslutsfattare.