Overdragelsesproblemet: hvad dit team skal eje, før konsulenterne går

Et AI-projekt har to afslutninger. Den første er lanceringen, som alle fejrer. Den anden er mere stilfærdig og kommer måneder senere, når en leverandør ændrer en formular, en regel bliver justeret, eller en modelversion bliver udfaset, og systemet begynder at give dårligere svar. På det tidspunkt er spørgsmålet enkelt: hvem retter det?

Hvis det ærlige svar er "vi bliver nødt til at ringe til konsulenterne igen", har du ikke købt et system. Du har lejet det, og taxameteret kører stadig.

Hvad ejerskab egentlig betyder

Ejerskab er ikke en mappe med dokumenter, der bliver overleveret på den sidste dag. Det er fire praktiske evner inde i din virksomhed.

Du kan drive det: nogen ved, hvordan man tjekker, om det virker i dag, og får besked, når det ikke gør. Du kan ændre det: nogen kan justere en regel, tilføje en dokumentkilde eller opdatere en prompt uden at oprette en supportsag. Du kan bedømme det: nogen kan skelne godt output fra dårligt, med dokumentation frem for fornemmelser. Og du kan udskifte det: du ved, hvad systemet afhænger af, hvad det ville koste at flytte, og hvem andre der kunne udføre arbejdet.

De fleste overdragelser leverer den første evne og springer de tre andre over. Det er derfor, systemer skrider.

Den dokumentation, der betyder noget

Dokumentation bliver skrevet for at opfylde en kontraktbestemmelse, så den beskriver arkitektur, ingen nogensinde kommer til at røre, og udelader det, folk faktisk har brug for. Hold listen kort, og insister på dette:

• En drejebog for fejl. De fem mest sandsynlige ting, der kan gå galt, hvordan hver af dem ser ud udefra, og de første tre skridt for hver. Skrevet til den, der har vagten, ikke til en ingeniør.
• Et evalueringssæt. Hundrede til to hundrede virkelige sager med det korrekte svar til hver, aftalt med de folk, der udfører arbejdet. Det er det enkeltstående mest værdifulde produkt i hele projektet.
• En ændringslog med begrundelser. Ikke bare hvad der blev konfigureret, men hvorfor en regel findes. Regler uden begrundelser bliver slettet af den næste person.
• Et afhængigheds- og omkostningsark. Hver model, API og leverandør; hvad det koster om måneden; datoer for kontraktfornyelse; hvad der går i stykker, hvis det forsvinder.
• Et datakort. Hvilke data der går hvorhen, hvem der kan se dem, hvor længe de opbevares. Din juridiske afdeling og dit sikkerhedsteam får brug for det uden varsel.

Alt andet er valgfrit. Hvis et dokument ikke hjælper nogen med at drive, ændre, bedømme eller udskifte systemet, er det pynt.

De tre personer, du har brug for

Du behøver ikke at ansætte et maskinlæringsteam. Du har brug for tre navngivne personer, og du bør udpege dem, før projektet begynder — ikke i den sidste måned.

En forretningsejer, der beslutter, hvad systemet skal gøre, og som har budgettet. Vedkommende godkender ændringer og siger nej til udvidelser af omfanget. Det er ikke en teknisk rolle.

En teknisk forvalter, der kan læse konfigurationen, foretage en kontrolleret ændring, teste den og sætte den i produktion. Ofte en eksisterende udvikler eller en it-medarbejder, hvor der er frigjort tid. Vedkommende behøver ikke at kunne bygge modeller, men skal kunne ændre og udrulle det, der findes.

En kvalitetsansvarlig fra den afdeling, systemet betjener — den erfarne skadebehandler, den ledende sygeplejerske, supportchefen. Vedkommende vedligeholder evalueringssættet og afgør, hvad "godt" betyder. Uden denne rolle bliver kvalitet et spørgsmål om holdninger inden for få uger.

Samlet intern omkostning: som regel en brøkdel af en fuldtidsstilling hver, når systemet er stabilt. Fejlkilden er ikke udgiften. Det er, at ingen blev udpeget.

Test overdragelsen, mens du stadig kan brokke dig

Accepter ikke dokumentation som bevis på overdragelse. Kør en live-test i de sidste uger af samarbejdet, mens konsulenterne stadig er under kontrakt.

Vælg en reel ændring — tilføj et nyt produkt til vidensbasen, stram en regel om, hvad systemet nægter at svare på, indsæt en opdateret prisliste. Bed dit eget team om at gøre det, med konsulenterne til stede i lokalet, men tavse. Tag tid på det. Lad derefter din kvalitetsansvarlige køre evalueringssættet og bekræfte, at intet andet gik i stykker.

Hvis dit team klarer det på en dag, ejer du systemet. Hvis det tager en uge og tre spørgsmål, har du fundet præcis de huller, der skal lukkes, før fakturaerne stopper. Begge resultater er langt mere værd end en underskrevet overdragelsesformular.

Skriv det ind i kontrakten fra begyndelsen. Milepæle for overdragelse, et navngivet modtagende team og en overvåget ændringstest er alle lettere at forhandle, før arbejdet går i gang, end bagefter.

Vi arbejder på den måde hos Hercules A, og det betyder, at vores samarbejder slutter. Det er hele pointen. Målestokken for et godt AI-projekt er ikke, hvor dybt konsulenterne sidder begravet et år senere — det er, hvor trygt dine egne folk ændrer systemet uden at ringe til nogen.