AI er blevet markant lettere at bygge ind i digitale produkter.
Man behøver ikke længere et hold af specialister for at analysere dokumenter, kategorisere tekst, generere indhold eller lade brugere søge i store mængder information. Mange af funktionerne kan kobles på gennem et API, og en prototype kan ofte bygges på relativt kort tid.
Det åbner for løsninger, som for få år siden ville have været dyre eller urealistiske.
Og det gør det fristende at begynde med teknologien.
Hvad prøver vi at gøre bedre?
Hvis en kunde bad mig bygge AI ind i et eksisterende produkt, ville jeg begynde med problemet.
Bruger medarbejderne for lang tid på at finde information? Skal nogen manuelt læse og kategorisere hundredvis af dokumenter? Får support de samme spørgsmål igen og igen? Ligger der store mængder ustruktureret tekst, som kræver manuelt arbejde?
Så har vi noget at undersøge.
Det er den samme tilgang, jeg ville bruge til en app, et nyt CMS eller en integration. Først skal vi forstå opgaven. Derefter kan vi vælge teknologien.
AI ændrer mulighederne. Den rækkefølge ville jeg holde fast i.
AI kan ligge under overfladen
Chatten er blevet det mest synlige billede på AI. Derfor ender mange idéer hurtigt med et tekstfelt, hvor brugeren kan "spørge vores AI".
Forestil dig i stedet en virksomhed med 20.000 dokumenter. Medarbejderne bruger hver dag tid på at finde det rigtige dokument og derefter den relevante information inde i det.
Her kunne AI gøre søgningen bedre.
Brugeren kan stadig møde et almindeligt søgefelt, en liste med resultater og nogle filtre. Under overfladen kan AI hjælpe med at forstå spørgsmålet, finde relevant indhold eller opsummere resultaterne.
Det samme gælder kategorisering, behandling af henvendelser, forslag til tekster og en lang række andre opgaver.
En AI-funktion kan sagtens skabe værdi uden at ligne AI.
Hvad sker der, når den tager fejl?
Med AI kommer en anden type usikkerhed end den, vi normalt arbejder med i software.
Traditionel kode er typisk deterministisk. Er de samme betingelser opfyldt, forventer vi det samme resultat.
En AI-model kan levere noget, der ser overbevisende rigtigt ud, selv når det er forkert.
Derfor er konsekvensen af en fejl mindst lige så vigtig som modellens præcision.
Hvis AI foreslår en dårlig formulering til en produkttekst, kan brugeren rette den. Hvis den kategoriserer et dokument forkert, kan resultatet præsenteres som et forslag, der skal godkendes.
Hvis den derimod sender forkerte oplysninger videre til et andet system eller foretager en handling på kundens vegne, er risikoen en anden.
Den samme model kan derfor være glimrende til én opgave og uegnet til en anden.
Måske skal AI'en foreslå – ikke beslutte
Der er stor forskel på:
"Her er de tre dokumenter, jeg tror er relevante."
og:
"Jeg har på baggrund af dokumenterne gennemført denne handling."
I mange produkter giver det mening at lade AI'en tage det tidskrævende forarbejde og lade et menneske tage den endelige beslutning.
AI'en kan læse, sortere, opsummere og foreslå. Medarbejderen kontrollerer resultatet.
Hvis en opgave tidligere tog 20 minutter og nu tager to minutter at kontrollere, er der allerede skabt betydelig værdi.
Fuld automatisering behøver derfor heller ikke være målet. Den rigtige grænse afhænger af opgaven og konsekvensen, når noget går galt.
En flot prototype er den nemme del
Noget af det imponerende ved de nuværende AI-værktøjer er, hvor hurtigt man kan få noget til at virke.
Tag 50 dokumenter, forbind dem med en model og byg en simpel brugerflade. Kort efter kan man have en demonstration, der svarer overraskende godt på spørgsmål om materialet.
Så kommer virkeligheden.
- Hvad sker der med 100.000 dokumenter?
- Hvor hurtigt skal et svar komme?
- Hvad koster hvert kald?
- Hvordan måler vi kvaliteten?
- Hvad logger vi?
- Hvordan opdager vi, hvis modellen begynder at levere dårligere resultater?
- Og hvad gør produktet, når tjenesten bag modellen er utilgængelig?
Det er her, en demonstration bliver til software, der skal fungere hver dag.
AI har gjort det meget hurtigt at bevise, at en idé kan fungere. Arbejdet med at gøre den stabil, økonomisk fornuftig og driftbar er stadig en del af produktudviklingen.
Hvilke data skal modellen have adgang til?
En AI-funktion bliver sjældent bedre end det materiale, den har at arbejde med.
Hvis den skal svare på spørgsmål om virksomhedens dokumenter, skal vi derfor beslutte, hvilke dokumenter den må se, hvordan de bliver gjort tilgængelige, og hvem der må spørge om hvad.
Der er forskel på offentlige produktbeskrivelser og interne dokumenter med kundeoplysninger.
Det påvirker arkitekturen.
Hvor behandles data? Hvad bliver gemt? Hvilke oplysninger sendes til en ekstern leverandør? Hvordan håndterer vi brugerrettigheder? Og hvad sker der, når et dokument bliver rettet eller slettet i det oprindelige system?
AI kan sagtens indgå i følsomme og forretningskritiske arbejdsgange. Det kræver bare, at data og adgang bliver behandlet som en del af løsningen fra begyndelsen.
Nogle problemer har en enklere løsning
AI er særlig interessant, når opgaven tidligere har været vanskelig at beskrive med almindelige regler.
At forstå betydningen af en tekst, finde mønstre i dokumenter eller formulere et svar ud fra ustruktureret information er gode eksempler.
Andre opgaver er allerede meget præcise.
Hvis et system skal finde alle ubetalte fakturaer fra de seneste 30 dage, kan en databaseforespørgsel levere et hurtigt og forudsigeligt svar.
Hvis support bruger tid på at besvare det samme spørgsmål, kan årsagen også være, at svaret er svært at finde på hjemmesiden. Så kan bedre struktur eller søgning være mere værdifuldt end at lægge en chatbot ovenpå.
Det afgørende er, hvilken løsning der fjerner problemet med mindst mulig unødig kompleksitet.
Begynd med den mindste nyttige opgave
Jeg ville sjældent starte med ambitionen om at automatisere en hel proces.
Find én afgrænset opgave.
Noget mennesker bruger mærkbar tid på i dag. Noget hvor resultatet kan vurderes. Og gerne noget hvor en fejl kan opdages, før den får alvorlige konsekvenser.
Byg den del og brug rigtige data.
Hvis en medarbejder normalt bruger ti minutter på at finde og sammenfatte information fra fem dokumenter, har vi et ret godt udgangspunkt. Kan AI hjælpe med at gøre det på to minutter med samme eller bedre kvalitet, har vi noget konkret at måle på.
Derefter kan vi beslutte, om løsningen skal vokse.
Det er billigere at opdage begrænsningerne dér end efter at have bygget en hel AI-platform omkring en idé.
Skal vi så have AI?
Måske.
Jeg bruger selv AI hver dag, og teknologien har allerede ændret min egen arbejdsgang. Opgaver kan løses hurtigere, flere idéer kan afprøves, og ting, der tidligere krævede meget manuelt arbejde, kan automatiseres på nye måder.
Det gør AI værd at undersøge.
Men det ændrer ikke den rækkefølge, jeg ville arbejde i.
Forstå problemet. Find ud af, hvad der skal blive bedre. Afprøv den mindste løsning, der kan vise, om idéen holder. Og vælg derefter den teknologi, der passer til opgaven.
Spørgsmålet er ikke, om vi kan bygge AI ind i produktet.
Det kan vi sandsynligvis.
Spørgsmålet er, om produktet bliver bedre af det.
Jeg hjælper med at vurdere, hvilket problem en AI-løsning faktisk skal løse, hvor den skal placeres i arkitekturen, og hvornår en simplere løsning er det rigtige valg.
