Demoen fungerer alltid: slik skiller du et ekte AI-system fra et innøvd et
Praktiske spørsmål å stille en AI-leverandør som avslører om demoen viser et system som virker, eller bare en nøye iscenesatt sti gjennom det.
Alle AI-demoer fungerer. Det er nettopp det en demo er til for. Leverandøren valgte dokumentene, kundeoppføringen, spørsmålet og øyeblikket for å klikke. Ingenting av dette er uærlig, men ingenting av det er bevis heller. Jobben din i det møtet er å finne ut om det finnes et system under forestillingen, og som regel klarer du det på tretti minutter med de riktige spørsmålene.
Ta med ditt eget materiale
Det mest nyttige du kan gjøre i et leverandørmøte, er å overta tastaturet. Gi systemet et dokument fra din egen virksomhet: en rotete kontrakt, en supporttråd der tre personer snakker i munnen på hverandre, en faktura fra leverandøren med det verste formatet. Be dem kjøre den direkte, uforberedt.
Følg med på hva som endrer seg. Responstid, forbehold, formatering, hvor sikkert svaret er. Et system som holder formen på et innspill ingen har iscenesatt, har møtt virkeligheten minst én gang.
Hvis leverandøren sier nei, spør hvorfor. «Dataene deres er ikke lastet inn i sandkassen» er et rimelig svar. Godta det, og legg så testen inn skriftlig som en betingelse før du signerer, med dine filer og din definisjon av hva som er bestått.
Spør hva som skjer når det tar feil
Se bort fra treffprosenten et øyeblikk, og spør om resten. Hvis systemet har rett 92 % av tiden, hvordan ser de andre 8 % ut fra brukerens stol? Det finnes bare tre muligheter: det sier at det ikke vet, det eskalerer til et menneske, eller det produserer et selvsikkert feil svar.
Systemer som feiler høylytt er billige i drift. Systemer som feiler stille er dyre, fordi kostnaden lander på kunden som handlet på feil informasjon, og på den ansatte som bruker en uke på å rydde opp.
Be så om å få se et tilfelle der systemet nektet å svare. Team med et fungerende produkt viser gjerne fram dette med en viss stolthet, for tilbakeholdenhet er den vanskelige delen å bygge.
Spør hvor svaret kom fra
Alt som berører ditt eget materiale — retningslinjer, priser, kontrakter, produktspesifikasjoner — bør oppgi kilden sin. Be om en kildehenvisning, og åpne den. Spørsmålet er ikke om det dukket opp en lenke. Det er om dokumentet det vises til faktisk sier det svaret påstår.
Gjør dette to ganger. To slike sjekker forteller deg mer om et system enn en time med lysbilder.
Spør om dagen etter at dataene endrer seg
Demoer kjører på et frosset øyeblikksbilde. Virksomheten din er ikke frosset. Disse spørsmålene skiller et produkt fra en prototype:
- Hvordan kommer ny eller korrigert informasjon inn, hvor ofte, og hvem har ansvaret?
- Når et dokument slettes eller erstattes, hvor lang tid går det før systemet slutter å bruke det?
- Respekterer systemet de tilgangsrettighetene dere allerede har, eller får alle de samme svarene uansett rolle?
- Når den underliggende modellen endres, får dere teste før endringen når brukerne deres?
- Hvem har vakt når det ryker klokka ni en mandag, og hva er responstiden?
Vage svar her er det sterkeste signalet du får i hele møtet. Et team som har hatt noe i produksjon, har vært gjennom alle fem.
Be om tall som koster noe å framskaffe
Prosenter på et lysbilde er gratis. Be om tall med form: hvor mange brukere, over hvor mange måneder, målt mot hvilket utgangspunkt, og hvem som målte. «Løser 60 % av førstelinjehenvendelsene» betyr lite før du vet hva de andre 40 % koster å omdirigere, og om tallet kom fra en pilot med ti personer eller et år med tusen.
Gode leverandører svarer med detaljer og forbehold. Noen som har levert et ekte system, vet nøyaktig hvor det knaker, og sier det uten å bli presset.
Spør hva det ikke kan
Be leverandøren beskrive bruksområdene der systemet passer dårlig. Et trygt team har svaret klart, og det er som regel presist: lange dokumenter i skannet form, språk utenfor evalueringsutvalget deres, alt som krever en skjønnsvurdering med juridisk risiko.
Et team som sier at systemet håndterer hva som helst, forteller deg at de ennå ikke har kjørt det noe sted som er hardt nok til å finne ytterkantene. Da finner du dem i stedet — etter at kontrakten er signert.
Det siste spørsmålet
Før du går, be om å få se hva en eksisterende kunde ser en helt vanlig tirsdag. Ikke demoen: dashbordet, loggene, køen med eskalerte saker, rapporten noen leser fredag morgen. Ekte systemer samler opp slikt lite glamorøst inventar fordi noen har måttet drifte dem. En innøvd demo har ingen tirsdag.
Vi sitter ofte på kjøpersiden av det bordet, og mønsteret holder: systemene som overlever disse spørsmålene, ser sjelden imponerende ut i en demo. De ser kjedelige, konkrete og gjennominstrumenterte ut. Det er slik det ser ut når noe virker.