Vilka arbetsflöden är värda att bygga AI för?

Kort sammanfattning

• Börja med ett återkommande problem och ett tydligt resultat, inte med en modell.
• Kontrollera underlag, åtkomst, risk och vem som ansvarar när svaret är osäkert.
• Testa den minsta användbara delen mot dagens arbetssätt. Välj regler, sökning eller ingen ny lösning om det räcker.

Börja med arbetet som behöver bli gjort

Ett arbetsflöde är en bättre startpunkt än en lista över möjliga AI-funktioner. Beskriv vem som gör arbetet, vad som sätter igång det och vilket resultat personen behöver. ”Hjälpa supporten” är för brett. ”Hitta rätt instruktion för ett inkommande produktärende och föreslå ett svar som en handläggare granskar” går att undersöka.

Skilj också på att arbetet känns långsamt och att det är värt att bygga något nytt. Väntan kan bero på otydligt ansvar, saknade uppgifter eller en godkännandekö. En språkmodell löser inte automatiskt något av det. Rita först upp dagens steg och markera var problemet faktiskt uppstår.

Beskriv indata, resultat och osäkerhet

Skriv ned vilka uppgifter som finns när arbetet börjar. Är de strukturerade fält, fritext, dokument eller muntlig kunskap? Ange sedan vad ett användbart resultat är: ett hittat dokument, ett utkast, en klassificering eller en ändring i ett system. De kräver olika kontroller.

Markera vad systemet inte kan veta. Om ett ärende saknar produktversion ska lösningen kanske fråga efter den, inte gissa. Om underlaget motsäger sig självt kan rätt resultat vara att lämna frågan till en person. Ett användbart arbetsflöde behöver kunna uttrycka osäkerhet och avstå, inte bara producera något som ser färdigt ut.

Kontrollera data och åtkomst före modellval

Finns informationen i en källa som någon ansvarar för? Går det att avgöra om den är aktuell? Har den tänkta användaren rätt att läsa den, och får den behandlas i den valda miljön? Att informationen går att hämta tekniskt betyder inte att den får användas för varje person eller ändamål.

Ta med den som äger informationen och den som ansvarar för åtkomst i avgränsningen. Om dessa frågor saknar svar är nästa steg att reda ut dem. Det är inte att välja en större modell.

Hypotetiskt exempel: ett förslag till supportsvar

Följande exempel är påhittat och beskriver inte en kund eller en levererad lösning.

En handläggare får en fråga om hur en produktinställning ändras. Indata är frågan, produktens namn och version samt godkända instruktioner. Resultatet ska vara ett svarsförslag med hänvisning till instruktionen. Handläggaren granskar och skickar svaret. Ingen inställning ändras automatiskt.

Börja med att pröva om förbättrad sökning räcker. Om handläggaren snabbt kan hitta rätt avsnitt behövs kanske ingen genererad text. Om ett utkast ändå kan hjälpa ska det tydligt skilja mellan belagda uppgifter och det som saknas. Fel version eller motstridiga instruktioner ska leda till en fråga eller överlämning.

Ett illustrativt beslutsunderlag kan se ut så här:

Arbetsflöde: hitta instruktion och föreslå svar
Tillåtet resultat: utkast med källa
Saknad produktversion: fråga användaren
Motsägande källor: lämna till ansvarig person
Extern handling: handläggaren granskar och skickar

Detta är ett diskussionsunderlag, inte en implementation. Det gör gränsen mellan hjälp och handling synlig innan något byggs.

Välj det minsta testet och ett användbart kriterium

Samla verkliga, behörigt tillgängliga exempel från arbetsflödet. Ta med svåra fall, saknade uppgifter och situationer där inget svar bör ges. Låt personer som kan arbetet beskriva vad de skulle godkänna och varför.

Jämför testet med dagens arbetssätt och ett enklare alternativ. I exemplet kan kriteriet vara att handläggaren kan kontrollera varje instruktion mot rätt version utan att behöva reparera påhittade uppgifter. Följ även arbetet med granskning och rättelser. Ett snabbt utkast som kräver omfattande kontroll behöver inte vara en förbättring.

Börja utan automatiska externa handlingar. Bestäm vem som granskar, vem som får stoppa testet och hur man återgår till det tidigare arbetssättet. Utöka först när underlaget motiverar det.

Beslutschecklista: bygg, förenkla eller avstå

• Finns ett återkommande behov med en namngiven användare och ansvarig?
• Är indata, tillåtet resultat och osäkra fall beskrivna?
• Finns aktuella källor och tillåten åtkomst?
• Kan resultatet kontrolleras av någon som förstår arbetet?
• Är konsekvensen av ett fel rimlig och går handlingen att återkalla?
• Finns ett mindre test och en tydlig grund för att fortsätta eller stoppa?

Avstå från att bygga AI när enkla regler eller sökning löser behovet, när underlaget inte får användas eller när ingen kan bedöma resultatet. Pausa också om felets konsekvenser inte kan hanteras eller ansvaret saknas. Ett välgrundat nej är ett användbart beslut.

När arbetsflödet är valt kommer nästa fråga: behövs en språkmodell, sökning, vanliga regler eller en kombination? Det avgörs av uppgiften, inte av vilket verktyg som är mest lockande.

En AI-produktionssprint kan vara nästa steg när arbetsflödet, ansvaret och testet är avgränsade. Börja med det beslutet, inte med ett löfte om automation.