Demon fungerade. Varför släpper vi den inte?

Det är fredag eftermiddag. Teamet visar sin AI-assistent för ledningen. Den läser ett kundmejl, hittar ordernumret, kollar leveransstatus och skriver ett vänligt svar på tio sekunder. Det blir tyst i rummet, och sedan säger någon: ”Wow. När kan vi ha det här på riktigt?”

Det var i mars. Nu är det oktober, och assistenten finns fortfarande bara i demomiljön. Den har hunnit visas för styrelsen, två konsulter och en praktikant. Den har inte svarat på en enda riktig kund.

Ingen har sagt nej. Det har bara hela tiden dykt upp något mer att vara orolig för. Tänk om den svarar fel. Tänk om den hittar på. Tänk om det blir dyrt. Tänk om juristerna inte gillar det. Så demon står där, lika imponerande som i mars, och används av ingen.

Om det här låter bekant är ni i gott sällskap. Det är kanske det vanligaste sättet för AI-projekt att dö: inte med ett misslyckande, utan med en lång väntan.

Det är inte tekniken som håller er tillbaka

När man frågar team varför de inte har släppt får man nästan alltid samma svar: ”Vi är inte säkra på att den är tillräckligt bra.”

Det låter som ett tekniskt problem, men det är det sällan. Ställ följdfrågan ”hur bra behöver den vara?” och det blir oftast tyst. Ingen har bestämt det. Och när ribban inte är bestämd kan man aldrig nå den.

Det är som att springa ett lopp där ingen har sagt var mållinjen är. Hur fort ni än springer kommer ni aldrig fram. Ni blir bara tröttare.

Det goda beskedet är att det här går att lösa på en eftermiddag. Det kräver inte bättre AI. Det kräver att ni gör om fem rädslor till fem beslut.

Fem rädslor, fem beslut

Rädsla 1: ”Tänk om den svarar fel”

Den kommer att svara fel ibland. Det gör era medarbetare också. Frågan är inte om den gör fel, utan hur ofta, hur allvarligt och vad som händer då.

Beslutet: Bestäm hur bra den behöver vara, och mät det på riktiga exempel. Femtio verkliga kundfrågor räcker för att börja. Om assistenten svarar rätt på 46 av dem, och de fyra felen är sådana som en människa fångar innan svaret skickas, då har ni något att ta ställning till. Hur ni gör det steg för steg står i Hur bra är bra nog?

Rädsla 2: ”Tänk om den hittar på”

AI-modeller kan låta helt säkra när de har fel. Det kallas hallucinationer, och det är en rimlig sak att vara orolig för.

Beslutet: Bestäm vad assistenten ska göra när den inte vet. ”Jag vet inte, men jag kopplar dig till en kollega” är ett bra svar. Testa sedan just det: ställ frågor som den inte ska kunna svara på, och kontrollera att den säger det i stället för att gissa. Det är ett av de första testerna i Ert första test av AI-svaren.

Rädsla 3: ”Tänk om kunderna märker det”

Det gör de, om ni släpper till alla på en gång.

Beslutet: Släpp inte till alla. Börja med tio användare, gärna interna, och sedan en liten andel av kunderna. Låt en människa godkänna svaren i början. Ni lär er mer på en vecka med tio riktiga användare än på en månad till i demomiljön. Mer om det i Släpp till tio användare först.

Rädsla 4: ”Tänk om det blir dyrt”

Det kan det bli, men det går att räkna på innan.

Beslutet: Räkna på kostnaden per svar med riktiga exempel, och sätt ett tak per månad. För de flesta interna och kundnära assistenter blir kostnaden per svar ören eller kronor. Det är sällan pengarna som stoppar ett projekt; det är osäkerheten om dem.

Rädsla 5: ”Tänk om juristen säger nej”

Om juristen får se projektet för första gången veckan innan släppet är risken stor att svaret blir nej, eller i alla fall ”vänta”.

Beslutet: Bjud in juristen och den som ansvarar för informationssäkerhet nu, med tre konkreta frågor: vilken data skickas till vilken leverantör, var lagras den, och vem kan se den? De flesta frågor går att svara på med leverantörens avtal och en enkel skiss över dataflödet.

Det som faktiskt gör det säkert

Det kan kännas som att det säkraste är att vänta tills allt är perfekt. Men det är tvärtom. Det som gör en AI-funktion säker är inte att den aldrig gör fel. Det är att ni har en plan för när den gör det.

Tre saker räcker för att våga ta första steget:

1. En ribba. Ni vet hur bra den behöver vara, och ni kan mäta det på riktiga exempel.
2. Ett skyddsnät. En människa ser svaren innan de går ut, eller kan rätta dem i efterhand, och användarna kan säga till när något är fel.
3. En avstängningsknapp. Om något går snett kan ni stänga av funktionen på en minut, utan att behöva göra en ny release.

Med de tre på plats är ett släpp till tio användare mindre riskabelt än det mesta annat ni gör den veckan.

Vem bestämmer?

En sak till håller många projekt kvar i demoläge: ingen har mandat att säga ja.

Utvecklarna väntar på ett klartecken från verksamheten. Verksamheten väntar på att utvecklarna ska säga att det är klart. Ledningen tror att någon annan har beslutat. Alla är försiktiga, och ingen äger frågan.

Utse en person som äger beslutet att släppa. Ge personen ribban från ovan, resultatet från testerna och skyddsnätet. Då är beslutet inte längre ett hopp ut i det okända. Det är en bedömning av siffror som alla har sett.

Vad ni inte behöver innan första släppet

Det är lika viktigt att veta vad som kan vänta. Inget av det här behövs för att släppa till tio användare:

• En perfekt prompt. Den blir bättre av riktiga användare, inte av fler veckor i demomiljön.
• Den senaste modellen. Den ni har klarar demon; den kommer att klara tio användare.
• En fullständig plattform för övervakning. En enkel logg över frågor, svar och användarnas omdömen räcker en bra bit.
• Stöd för alla tänkbara frågor. Börja med de vanligaste, och låt assistenten säga ”det kan jag inte hjälpa till med” om resten.

Vill ni gå djupare i hur själva systemet byggs så att det tål drift, finns den tekniska serien Luniat Engineering på engelska. Hela serien Våga hela vägen hittar ni på seriens sida.