Godkend AI-agenters deploys før

På aienterprisekonsulenten.dk arbejder jeg selvstændigt med små og mellemstore virksomheder og hjælper dem i gang med AI gennem workshops, oplæring og konkrete løsninger, der passer til deres hverdag. En del af det arbejde handler om at bruge AI-agenter til daglig drift, herunder deploys af kundeløsninger.

Den gamle proces var enkel og hurtig: agenten kørte sine tests, tolkede resultaterne som grønne, og udrullede ændringen. Bagefter tjekkede jeg, om alt så fornuftigt ud i loggen. Fungerede det, gik jeg videre. Var der noget galt, rullede vi tilbage. Det virkede godt i lang tid, fordi de fleste ændringer var små, og fejl var lette at spotte, når de først opstod.

Problemet er, at godkendelse efter udrulning kun fanger fejl, der er synlige i output. Den fanger ikke fejl, der ligger skjult i en tilstand, testene aldrig undersøgte.

Agenten skulle flytte en tabelstruktur til et nyt skema som led i en almindelig oprydning. Migrationsscriptet kørte uden fejl. Testsuiten bestod. Loggen viste ingen advarsler. Alt tydede på, at ændringen var sikker at rulle ud, og agenten godkendte den selv, fordi det lå inden for dens mandat på det tidspunkt.

Det, ingen af testene fangede, var, at migrationen ændrede rækkefølgen af data i en tabel, som en anden del af systemet stille og roligt gjorde antagelser om. Den fejl viste sig ikke som en teknisk exception. Den viste sig som forkert indhold på det live site, timer efter udrulningen, da en cachet visning endelig blev genopfrisket med de nye data i den forkerte rækkefølge.

Jeg opdagede det ikke ved at læse en logfil. Jeg opdagede det, fordi en kunde ringede og spurgte, hvorfor deres forside pludselig viste forkert indhold.

Dette er kernen i lektien, og den er værd at sætte ord på uden at overdrive den. Testene testede det, de var skrevet til at teste: at migrationen kørte, at ingen rækker gik tabt, at skemaet matchede den forventede struktur. De testede ikke rækkefølgen af data, fordi ingen havde forudset, at rækkefølgen betød noget for et system, der lå to lag væk fra selve migrationen.

Det er ikke en fejl i agenten. Det er en grænse for, hvad automatiserede tests kan opdage: de finder det, de er designet til at lede efter. En agent, der udelukkende styrer efter grønne tests, arver den samme blinde vinkel som testsuiten selv. Jo mere komplekst systemet bliver, desto større er sandsynligheden for, at en fejl opstår i et hjørne, testene aldrig var skrevet til at dække.

Det er også derfor, godkendelse efter udrulning er den forkerte rækkefølge for netop denne type ændring. Bagefter er skaden allerede sket. Kunden har allerede set det forkerte indhold.

Efter hændelsen indførte jeg et fast princip: enhver ændring, der rører ved skema, migration eller andet, der kan påvirke live data, skal have et separat godkendelsestrin, før den overhovedet rulles ud. Agenten forbereder ændringen, kører sine tests, og lægger en klar beskrivelse af, hvad den vil gøre og hvorfor. Men den udruller ikke selv.

Jeg gennemgår beskrivelsen, ikke kun testresultaterne. Det betyder, at jeg spørger mig selv, om ændringen kan påvirke noget, testene ikke dækker, ikke bare om testene er grønne. For migrationer betyder det konkret, at jeg tjekker, om andre dele af systemet gør antagelser om data, som migrationen kunne rykke ved.

Mindre ændringer, som ikke rører ved data eller skema, kører stadig i den gamle rytme med godkendelse efter udrulning. Det er en bevidst skelnen: risikoen ved en tekstændring er ikke den samme som risikoen ved en migration.

Den ærlige pris er tid. Et godkendelsestrin før udrulning betyder, at agenten ikke længere kan arbejde helt selvstændigt gennem en hel arbejdsdag. Jeg skal ind og kigge, tage stilling, og af og til stille spørgsmål tilbage til agenten om, hvorfor den har valgt en bestemt tilgang. Det er langsommere end den gamle proces.

Til gengæld har jeg ikke haft en eneste hændelse af samme type siden. Ikke fordi agenten er blevet klogere, men fordi jeg som menneske ser ting, testene ikke ser, når jeg får lov at se dem, før skaden sker i stedet for bagefter.

For en mindre virksomhed, der overvejer AI-agenter i drift, er det her den reelle afvejning: hastighed mod kontrol. Mit mål er at gøre AI brugbar for virksomheder uden et teknisk udgangspunkt, kort og konkret, og den brugbarhed hænger sammen med, at man ved, hvor grænsen for automatiseringen skal ligge.

Det enkleste princip, jeg er endt med, er dette: kan en fejl i denne opgave ramme en kunde, før nogen opdager det? Hvis ja, hører opgaven til i kategorien, der kræver godkendelse før udrulning. Hvis nej, hvis fejlen er synlig med det samme og let at rulle tilbage, kan agenten godt arbejde selvstændigt og blive tjekket bagefter.

Det betyder i praksis, at ting som skemaændringer, migrationer og alt, der rører ved produktionsdata, altid kræver et menneskeligt blik, før de sker. Ting som indholdsopdateringer, mindre stilrettelser eller isolerede funktionsændringer kan stadig køre i den hurtigere rytme.

Den samme tankegang gælder, uanset om det er ens egen drift eller en kundes. Jeg har set lignende principper spille en rolle andre steder i driften, blandt andet i [ti kundesites én udgivelsesvagt](/artikler/ti-kundesites-en-udgivelsesvagt-sadan-undgas-overskrevet-indhold/), hvor et enkelt kontrolpunkt viste sig at være mere værd end hurtighed alene, og i erfaringen med en [selv-reparerende AI-konsol, der gav falske alarmer](/artikler/my-self-repair-console-was-crying-wolf/), hvor tillid til automatik uden opsyn viste sig at koste mere, end den sparede.

Det handler ikke om at holde AI-agenter fra rattet. Det handler om at vide, hvornår man selv skal have hånden på rattet, før agenten sætter foden på speederen.