Kunden går også jeres AI efter i sømmene

Den første halvdel af kundens sikkerhedsspørgeskema kender I udenad: Adgangsstyring, backup, kryptering, logning. Så kommer AI-afsnittet, og der bliver det sværere! For de spørgsmål har ofte ingen klar ejer hos jer endnu. Samtidigt skal salgschefen have det udfyldte skema retur på fredag.

I de spørgeskemaer, jeg har set, handler afsnittet om fire ting: Om I bruger kundedata til at træne modeller, hvilke modeller og tjenester funktionen bruger, hvor længe prompts og svar bliver liggende, og hvornår et menneske gennemgår resultatet. Så skriver nogen fire pæne afsnit (som hverken er løgn eller sjusk), men som er skrevet af en, der gerne vil have handlen hjem.

Problemet opstår, når kunden faktisk spørger videre, og det gør de, hvis personen i den anden ende har læst den slags svar før. Så står salgsdialogen stille, mens fristen nærmer sig, og ingen kan efterprøve svaret uden først at spørge den udvikler, der byggede funktionen. Sagerne herunder er anonymiserede eksempler fra mit eget arbejde som rådgiver.

Hvorfor en pæn forklaring ikke er et svar

I den første halvdel af skemaet har generelle beskrivelser ikke været nok i mange år. Skrev I, at backuppen blev testet, kom spørgsmålet om, hvornår I sidst havde gendannet data, og hvem der stod for testen. AI-spørgsmålene er kommet til senere og bliver ofte besvaret af andre end dem, der har resten af skemaet, men den samme person hos kunden læser begge halvdele med samme målestok.

Det første, man griber til, er ofte en AI-politik. Men kunden vil se, hvordan løsningen faktisk er sat op. Her handler det om den dokumentation, kunden beder om, ikke om jura. Jeg har vurderet leverandører for en kapitalfond og haft ansvaret for leverandørrisiko som interim it-direktør, og begge steder var det mig, der læste svarene.

Da svaret ikke passede til produktet

En virksomhed, der laver software til kontraktstyring, skulle svare på AI-afsnittet midt i en fremskreden salgsdialog. Det første udkast lød i store træk sådan:

Vi bruger en erhvervsløsning til AI. Kundedata bliver ikke brugt til træning, prompts bliver ikke gemt, og alle resultater bliver gennemgået af et menneske.

Ingen havde holdt de tre udsagn op mod, hvordan produktet faktisk fungerer. I stedet for endnu en runde med teksten bad jeg lead-udvikleren følge én kontrakt igennem, fra upload til den rapport, kunden ville få. I arbejdsgangen indgik en leverandør, der trak teksten ud af dokumenterne, og en OpenAI-model, der kørte på Azure OpenAI, og både dokumenter og opsummeringer blev gemt i produktet.

Så kunne teamet selv se, hvor svaret ikke holdt. Udsagnet om træning holdt for det forløb, vi havde fulgt, men påstanden om, at prompts ikke blev gemt, overså kopierne i logfiler, database og sikkerhedskopier. Brugerne godkendte den færdige rapport, mens det var systemet, der havde fremhævet de enkelte klausuler undervejs. Det rettede svar lød i store træk sådan:

Funktionen bruger de tjenester og roller, der står i den vedlagte leverandøroversigt. Hverken vi eller de leverandører bruger kundedata til at træne modeller under de aftaler, vi har gennemgået. Uploadede dokumenter, gemte opsummeringer og logfiler har hver sin opbevaringsperiode i samme oversigt. Rapporter godkendes af en bruger før udgivelse, mens de klausuler, systemet selv fremhæver, ikke gennemgås enkeltvis først.

De fire spørgsmål, og hvad standardsvaret mangler

Bruger I kundedata til at træne modeller? Det pæne svar siger nej og henviser til aftalerne. Men så mangler vi to ting: Leverandørens vilkår sammen med den faktiske opsætning, som viser, om der bliver trænet på data, og en oversigt over datastrømme, som viser, hvilke af jeres systemer der sender hvad til hvilken tjeneste.

Hvilke modeller og tjenester bruger funktionen, og hvem leverer dem? Det pæne svar nævner førende leverandører på erhvervsvilkår, men ingen navne. Her mangler vi: Hver tjeneste, dens rolle og den virksomhed, I har aftale med. Der ligger to ting i spørgsmålet "Hvem har bygget modellen" og "hvem behandler oplysningerne". Microsofts dokumentationbeskriver, at de Foundry-modeller, Azure sælger, ikke er i forbindelse med de tjenester, modeludbyderne selv driver, for eksempel OpenAI's.

Hvor længe gemmer I prompts og svar? Det pæne svar siger, at data behandles kortvarigt og ikke gemmes unødigt. Det, der mangler, er en dateret eksport af logningsopsætningen i produktion og opbevaringsperioderne hos leverandøren, i databasen, i brugernes gemte rapporter og i sikkerhedskopierne. Data ligger sjældent kun ét sted.

Hvornår gennemgår et menneske resultatet? Det pæne svar siger, at alt bliver gennemgået. Det, der mangler, er arbejdsgangene, som de er: Hvad der kræver godkendelse, hvad der bliver brugt uden, og en log over, hvem der godkendte hvad og hvornår.

Uanset hvilket spørgsmål der kommer, har kunden brug for de samme fire oplysninger. Kald dem de fire hv-ord: Hvad dokumentationen dækker, hvor den kommer fra, hvem der har efterprøvet den, og hvornår. Tabellen herunder er ikke fra en af sagerne her, men et eksempel på, hvordan sådan et register kan se ud, når det er udfyldt.

Uden en dato kan kunden ikke se, om materialet stadig passer på produktionen. Holder registret, kan I bruge de fire hv-ord på et spørgsmål, I aldrig har set før.

Da logningen sagde noget andet end svaret

Et softwarehus, der laver analyseværktøjer, havde allerede sendt sit svar. Produktet skrev tekstforslag til kundernes rapporter, og svaret lød i store træk sådan:

Prompts og svar behandles kortvarigt. Vores AI-leverandør træner ikke på kundedata, og vi opbevarer ikke følsomme oplysninger unødigt.

Kunden bad om at se de indstillinger, der styrer opbevaring. Inden nogen sendte et skærmbillede fra leverandørens konsol, fulgte platformsudvikleren et testkald gennem virksomhedens egne systemer. Fejlsøgningsloggen gemte både forespørgslen og modellens svar, fordi en log, der var slået til under en fejlsøgning, aldrig blev slået fra igen.

Leverandørens vilkår for brug af kundedata til træning sagde altså ingenting om, hvad applikationen selv skrev ned. OpenAIs API-dokumentation angiver, at API-data som udgangspunkt ikke bruges til træning, at logfiler til misbrugsovervågning gemmes i op til 30 dage, og at visse funktioner gemmer applikationsdata efter andre regler.

Teamet stoppede den opsamling, der ikke var brug for, og ryddede op i de kopier, der allerede lå. Forespørgsels-id, svartider og fejlkoder blev liggende, mens prompten og modelsvaret røg ud af den almindelige logning. Udviklerne testede både kald, der lykkedes, og kald, der fejlede, for en eksport viser, hvad der er sat op, ikke hvad der sker i drift.

De gamle logdata forsvandt ikke af den grund. Adgangen til dem blev begrænset, og de fik en slettefrist, som blev skrevet ned i en særskilt oprydningsnotat. Det rettede svar lød i store træk sådan:

Rå prompts og genererede svar indgår ikke længere i applikationens fejlsøgningslog. Den vedlagte produktionsopsætning og de tilhørende testkald viser det, både når et kald lykkes, og når det fejler. Brugernes gemte rapporter følger opbevaringsperioderne i det vedlagte opbevaringsregister, hvor leverandørens egen opbevaring også står. Adgangsbegrænsning og slettefrister for de gamle logfiler står i den vedlagte oprydningsnotat.

Kunden lukkede punktet, da eksporten, testkaldene, opbevaringsregistret og oprydningsnotatet var sendt. Systemet gemte stadig forespørgsels-id og brugernes rapporter, men nu var opbevaringen beskrevet rigtigt.

Hvad et forkert svar koster

En leverandør af fakturasoftware havde svaret, at alle AI-genererede posteringer blev gennemgået af et menneske, inden de blev bogført. Under en demonstration tog kundens controller en helt almindelig faktura og spurgte, hvem der havde godkendt den. Produktteamet måtte forklare, at posteringer, hvor modellen var sikker nok efter en fastsat grænse, blev bogført automatisk, mens medarbejderne tog sig af undtagelserne og lavede stikprøver bagefter.

Controlleren stoppede udrulningen, og indkøbsafdelingen satte den større aftale i bero. Ledelsen rettede svaret direkte over for kunden uden at kalde det en misforståelse, og udviklerne begrænsede integrationens rettigheder, så produktet kun kunne lave udkast. Piloten kørte videre i mindre skala, men den større aftale kom ikke med i den budgetrunde, og leverandøren betalte selv for det ekstra arbejde.

Sådan kommer I i gang uden at bygge et stort kontrolapparat

1. Følg én rigtig sag gennem produktet sammen med den udvikler, der har bygget funktionen, fra de data, der sendes ind, til det, kunden får.
2. Skriv datastrømmene og leverandøroversigten ned, mens I stadig husker detaljerne.
3. Træk den faktiske logningsopsætning ud af produktion, dater udtrækket, og kør testkald, der både lykkes og fejler.
4. Beskriv arbejdsgangene, som de er, både dem, der kræver godkendelse, og dem, der bliver brugt uden.

Har I flere AI-funktioner med hver sine datastrømme, tager I dem én ad gangen. Aftal så, hvem der vedligeholder hvert dokument, typisk udviklingschefen for de tekniske dokumenter og produktchefen for arbejdsgangene, og hvad der udløser en ny gennemgang: skift af leverandør, ændret logning eller ændret adfærd i produktet.

Næste gang skal I ikke starte forfra

Tag jeres seneste svar på AI-afsnittet frem, og læs det, som om en leverandør havde sendt det til jer. Hvis I selv ville stille et opfølgende spørgsmål, stiller kunden det sandsynligvis også. Prøv derefter at besvare hele AI-afsnittet alene ud fra de fire dokumenter, listen ovenfor giver jer, og skriv hullerne ned. Det er billigere at finde dem selv end at få dem fundet på et pilotmøde.

Videre læsning

Hvornår brug af AI skal godkendes og hvem der ejer styringen af AI.