Fra AI-prototype til driftsikker løsning: Det tog vi med til NextStep Randers
Med AI kan du bygge en app eller et internt IT-system ved at beskrive, hvad du gerne vil have. Måske har du allerede prøvet det: Du skriver din idé, ser løsningen tage form og opdager, at noget, der før virkede uoverskueligt, pludselig er inden for rækkevidde.
Men hvornår er løsningen klar til, at medarbejdere eller kunder kan bruge den? Og hvad skal der til, før virksomheden kan være afhængig af den i hverdagen?
Det var temaet for mit oplæg på NextStep Randers. Her får du en gennemgang af vejen fra den første fungerende udgave til en løsning, som andre trygt kan bruge. Du behøver hverken have hørt oplægget eller kunne skrive kode for at følge med.
Gratis guide og tjekliste: Fra AI-prototype til sikker drift
Har du bygget en løsning med AI og vil gerne gøre den klar til drift? Vi har udarbejdet en guide og en tjekliste, der hjælper dig med at gennemgå din AI-prototype, så du kan se, hvad der er på plads, og hvad der mangler, før andre trygt kan bruge den.
Åbn guiden og tjeklisten
Det er let at blive begejstret. Det blev jeg også
Hos Holion udvikler vi skræddersyede softwareløsninger. En del af arbejdet er at skrive tilbud, der beskriver kundens behov, vores forslag og den forventede pris.
Det tager tid, så jeg fik en idé: Hvad hvis vi optog kundemødet, fik AI til at omdanne samtalen til tekst og derefter lod AI skrive tilbuddet? Jeg havde allerede bygget en løsning, der kunne sætte indholdet op i et flot dokument.
Fra kundemøde til færdigt tilbud. Automatisk.
De første dele kom hurtigt til at virke. Men efterhånden blev det tydeligt, at et godt tilbud kræver mere end et referat af en samtale. Vi skal også vurdere, hvad der kan lade sig gøre, afgrænse opgaven og tage stilling til tid, pris og risiko. Nogle gange skal vi udfordre kundens forslag for at finde en bedre løsning.
I stedet for at stoppe op og genoverveje idéen byggede jeg videre. Hver begrænsning blev mødt med en ny funktion. Til sidst var projektet blevet svært at overskue, og vi valgte at bruge tiden på andre ting.
Jeg havde fået AI til at bygge en masse. Men jeg havde ikke været tydelig nok om, hvilken opgave løsningen egentlig skulle løse.
Det er den første læring: Inden du bygger videre, skal du kunne forklare, hvad løsningen skal hjælpe med, og hvad der fortsat kræver et menneskes vurdering.
For min tilbudsgenerator kunne en mindre opgave eksempelvis have været at lave et udkast til et mødereferat. Så kunne vi selv bruge referatet som grundlag for tilbuddet. Det ville være en mere afgrænset opgave med en tydelig plads til vores faglighed.
Når formålet er klart, kommer næste spørgsmål: Hvordan ved vi, om det, vi har bygget, er klar til brug?
Der er tre forskellige betydninger af “det virker”
En prototype er en tidlig udgave, som bruges til at afprøve en idé. Den kan vise, at en optagelse kan blive til tekst, eller at et system kan samle virksomhedens opgaver på én skærm.
Det er et vigtigt første skridt. Men en vellykket demonstration fortæller ikke, om oplysningerne er beskyttet, eller hvad der sker, hvis noget går galt.
Jeg plejer derfor at stille tre spørgsmål:
- Virker idéen? Kan prototypen udføre den opgave, vi forestiller os?
- Kan andre trygt bruge løsningen? Er oplysningerne beskyttet, og fungerer de vigtigste arbejdsgange også i praksis?
- Kan vi holde løsningen kørende? Opdager vi problemer, og ved vi, hvem der skal løse dem?
AI har gjort det første spørgsmål meget lettere at besvare. De næste to kræver stadig planlægning, afprøvning og et tydeligt ansvar.
Spørgsmålene skal følge projektet fra starten. Hvis løsningen skal håndtere kundedata, er beskyttelsen af dem eksempelvis en del af opgaven allerede under udviklingen.
Før andre tager løsningen i brug, skal sikkerheden fungere bag skærmen
Noget af det svære ved software er, at en løsning godt kan se færdig ud, selv om vigtige dele mangler.
Det oplevede vi hos en kunde. Direktøren havde med AI bygget et imponerende system, der samlede store dele af virksomheden, blandt andet virksomhedens mails. Systemet havde en login-side, og AI havde forsikret ham om, at sikkerheden var i orden.
Da vi gennemgik løsningen, viste det sig, at man kunne hente oplysninger fra systemet uden at være logget ind.
Hvordan kan det lade sig gøre, når der er en login-side?
Fordi det, du ser på skærmen, kun er én del af systemet. Bagved ligger den del, der behandler forespørgsler og henter oplysninger. Den skal kontrollere, hvem der spørger, og hvad personen må få adgang til, hver gang nogen beder om data.
Hvis kontrollen kun findes på skærmen, kan en uvedkommende i nogle tilfælde gå uden om den.
Et login skal derfor følges af adgangskontrol: Systemet skal håndhæve, hvilke oplysninger hver bruger må se og ændre.
For et tilbudssystem kan det betyde, at en kunde må se sine egne tilbud, mens en medarbejder må se tilbuddene for de kunder, vedkommende arbejder med. Det skal også testes, at de ikke kan få adgang til mere.
En besked til AI er ikke en lås
Det samme princip gælder den AI, der hjælper med at bygge løsningen.
Du kan skrive: “Du må ikke ændre eller slette vores kundedata.” Sådan en instruktion kaldes en prompt. Den fortæller AI, hvad den skal gøre, men forhindrer ikke i sig selv en fejl.
Derfor skal adgangen begrænses i selve systemet. Hvis AI kun skal arbejde på en prøveversion, bør den kun have adgang til det, der er nødvendigt for den opgave.
Tænk på det som en nøgle: En person, der skal ind på kontoret, behøver ikke også få adgang til pengeskabet.
Det er også grunden til, at nye funktioner bør udvikles og afprøves i et separat testmiljø. Det er en prøveudgave af systemet, hvor fejl kan opdages uden at ramme de kunder og medarbejdere, der bruger den rigtige løsning. Brug så vidt muligt opdigtede testdata dér.
Løsningen skal også kunne håndtere en almindelig, besværlig hverdag
Sikkerhed er afgørende, men den gør ikke alene en prototype klar til brug. Løsningen skal også fungere, når mennesker og andre systemer gør noget uventet.
Forestil dig, at tilbudsgeneratoren skulle tages i brug. Så ville vi blandt andet skulle undersøge:
- Hvad sker der med kundens oplysninger? Hvor gemmes optagelsen og mødereferatet, hvem får adgang, og sendes indholdet videre til en AI-tjeneste?
- Hvad sker der, hvis en del af processen fejler? Får medarbejderen tydeligt besked, hvis kun halvdelen af mødet er blevet omdannet til tekst?
- Kan vi stole på indholdet? Hvordan opdager vi, hvis AI foreslår en forkert pris eller skriver, at vi har lovet noget, som aldrig blev aftalt?
- Hvad sker der ved mere brug? Kan flere medarbejdere arbejde samtidig, og hvad koster det, når antallet af optagelser vokser?
De spørgsmål viser, hvorfor det er nødvendigt at teste mere end det forløb, hvor alt går godt.
En test kan eksempelvis være at afbryde forbindelsen under en upload eller prøve med en optagelse med dårlig lyd. Formålet er at se, om løsningen håndterer problemet forståeligt, og om arbejdet kan fortsætte uden tab af oplysninger.
AI kan hjælpe med at skrive og udføre tests. Men der er stadig brug for at kontrollere, om testene undersøger det, der betyder noget for brugerne. En besked om, at “alle tests er bestået”, er kun nyttig, hvis de relevante situationer faktisk er blevet afprøvet.
Hvis løsningen selv bruger AI, skal indholdet også vurderes. Et system kan godt gennemføre hele processen uden en teknisk fejl og alligevel levere et forkert tilbud. Derfor skal det være tydeligt, hvornår et menneske skal gennemgå og godkende resultatet.
Når løsningen er taget i brug, begynder ansvaret for driften
Selv en grundigt afprøvet løsning kan få problemer. En ekstern tjeneste kan holde op med at svare, en opdatering kan ændre noget, eller en fejl kan vise sig efter længere tids brug.
Drift handler om at holde løsningen brugbar over tid og håndtere de problemer, der opstår.
Jeg har udviklet apps siden 2010, hvor jeg var med til at bygge Danske Banks mobilbank, og senere var jeg også med på MobilePay. Den slags projekter lærer én, hvor vigtigt det er, at en løsning bliver ved med at fungere, efter den første begejstring har lagt sig.
Her er tre spørgsmål særligt nyttige:
Kan vi opdage problemet?
Systemet skal holde øje med vigtige fejl og give en ansvarlig person besked. Det kan være, når tilbud ikke bliver oprettet, eller forbruget af en betalt AI-tjeneste pludselig stiger kraftigt.
Kan vi forstå, hvad der skete?
Der skal være en historik over relevante hændelser, så man kan undersøge fejlen. Det kaldes en log. Den kan eksempelvis vise, hvornår en behandling stoppede, uden at gemme hele kundens samtale eller hemmelige adgangskoder.
Kan vi få løsningen tilbage i normal drift?
Der skal være en plan for at rette fejlen, gå tilbage til en tidligere version eller gendanne mistede oplysninger fra en sikkerhedskopi.
En sikkerhedskopi, også kaldet en backup, skal afprøves. Først når I har gennemført en gendannelse, ved I, om kopien kan bruges, og hvor lang tid det tager at komme videre.
Der skal også stå et navn ud for ansvaret. Hvem reagerer på en alarm? Hvem informerer brugerne? Og hvem sørger for løbende opdateringer?
Beskrivelsen skal være klar nok til, at andre kan overtage, når den person, der byggede løsningen, er på ferie.
Du kan styre projektet uden selv at kunne skrive kode
Det kan virke som mange ting at holde styr på. Men din opgave som ejer eller leder er at få de væsentlige spørgsmål besvaret og sørge for, at nogen har ansvaret for dem.
Start med disse fem:
- Hvilken opgave skal løsningen løse, og hvad har vi valgt fra?
- Hvad er afprøvet, og hvad mangler vi stadig at undersøge?
- Hvad kan der ske med kunderne, oplysningerne og forretningen, hvis løsningen fejler?
- Hvad koster løsningen ved den brug, vi forventer, og hvis brugen vokser?
- Hvem har ansvaret for at holde den kørende og håndtere fejl?
Bed om konkrete svar. “Der er styr på backup” kan eksempelvis følges op med: “Hvornår har vi sidst prøvet at gendanne systemet, og lykkedes det?”
Den slags spørgsmål gør det lettere at se forskel på noget, der er besluttet, noget, der er gennemført, og noget, vi stadig håber virker.
Sådan kommer du videre med dit eget projekt
Hvis du allerede har bygget noget med AI, er et godt næste skridt at få overblik over løsningen, før du tilføjer flere funktioner.
Hos Holion har vi lavet en gratis guide, Fra AI-prototype til sikker drift, som hjælper dig gennem den vurdering.
Har du et eksisterende projekt, kan du bruge guidens færdige instruktion til en AI-gennemgang. Den kan kopieres ind i det AI-værktøj, der har adgang til projektet. Instruktionen beder AI om at undersøge løsningen, dokumentere fund og prioritere problemerne uden at ændre i projektet.
Er du stadig i gang med at bygge, kan du bruge guidens emner til at arbejde med blandt andet sikkerhed, afprøvning og drift undervejs.
Fremgangsmåden er den samme i begge tilfælde:
- Gennemgå løsningen. Find ud af, hvad der er på plads, hvad der mangler, og hvad der ikke kan vurderes endnu.
- Prioritér problemerne. Begynd med det, der kan udsætte brugere, oplysninger eller forretningen for væsentlig skade.
- Kontrollér resultatet. Afprøv rettelserne i et testmiljø. Undersøg eksempelvis, om adgang bliver afvist, om en sikkerhedskopi kan gendannes, og om en alarm når frem.
En AI-gennemgang kan give et nyttigt overblik, men AI kan overse fejl og tage fejl i sine konklusioner. Ved løsninger med følsomme oplysninger, betalinger eller store konsekvenser ved fejl bør en erfaren udvikler eller sikkerhedsspecialist hjælpe med vurderingen.
Byg hurtigt, test grundigt og tag ansvar
Jeg bruger selv AI hver dag og er begejstret for, hvor meget lettere det er blevet at omsætte idéer til noget konkret.
Erfaringen med min tilbudsgenerator mindede mig samtidig om, at hastigheden kræver tydelige valg. Vi skal vide, hvad vi vil løse, holde fast i afgrænsningen og undersøge, om løsningen er klar til det ansvar, vi giver den.
Den fungerende prototype er en vigtig begyndelse. Vejen videre handler om at beskytte oplysningerne, afprøve hverdagen og sørge for, at nogen kan reagere, når noget går galt.
Har du bygget en løsning med AI og er i tvivl om, hvad der mangler, før andre kan bruge den? Ring til os på 82 30 34 20, eller book et uforpligtende møde.
