Ti kundesites én udgivelsesvagt

Når man som jeg arbejder med AI-løsninger på tværs af flere virksomheders hjemmesider, er det fristende at lade automatiseringen køre parallelt. Flere sites, flere opgaver, flere agenter, der hver især tager sig af deres del. Det lyder effektivt. Problemet opstår, når to processer rører ved det samme indhold på samme tid, uden at nogen af dem ved det.

I mit tilfælde betød det, at en artikel blev genereret og publiceret af én agent, mens en anden agent samtidig arbejdede på en opdatering af den samme side. Resultatet var ikke en fejlmeddelelse eller et krak. Det var stille og næsten umærkeligt: den nyeste version overskrev den ældre, og en del indhold forsvandt uden varsel.

Det var ikke systemet, der advarede mig med det samme. Da jeg gik igennem publiceringshistorikken for de ti sites, kunne jeg se, at to udgivelser til samme side var sket inden for få minutter af hinanden, uden nogen koordinering mellem dem. Det skete kun i mindre skala, dengang, men det var nok til at vise mig, hvor sårbar processen var.

Det var et vendepunkt for mig. Jeg havde bygget en proces, der var god til at generere og publicere indhold hurtigt, men jeg havde ikke bygget noget, der sikrede, at kun én ting kunne skrive til en given side ad gangen. Automatisering uden et klart kontrolpunkt er ikke automatisering. Det er tilfældighed med god hastighed.

Den praktiske løsning blev enkel, men den krævede, at jeg tænkte processen om fra bunden. Ingen agent må længere publicere direkte til et af de ti sites. I stedet udpegede jeg én fast udgivelsesansvarlig for hele porteføljen, og alle andre skal nu sende deres ændring som en anmodning først.

Det betyder konkret, at hver ændring, uanset om det er en artikel, en layoutrettelse eller en kodeændring, lander som en anmodning hos den udgivelsesansvarlige. Vedkommende tjekker først, hvad der faktisk ligger live på sitet lige nu. Derefter indarbejdes ændringen oven på den aktuelle tilstand, den verificeres, og først derefter bliver den udgivet. Ingen anden proces kan omgå det trin. Det er en simpel regel, men den løser hele problemet ved roden, fordi der aldrig er tvivl om, hvilken tilstand der er den gældende, når noget nyt skal ind.

Denne udfordring minder mig om en generel pointe, jeg er stødt på flere gange i arbejdet med AI-drift: automatisering, der ikke har et klart ansvarssted, ender med at skabe mere støj og mere risiko, end den fjerner.

Hver af de ti sites har nu en fast rækkefølge, indholdet skal igennem. Først udarbejder den relevante agent et udkast eller en foreslået ændring. Dernæst sendes den som en anmodning til den udgivelsesansvarlige, der ikke publicerer noget uden selv at have set den aktuelle live version først.

Den udgivelsesansvarlige gennemgår anmodningen op mod det, der allerede ligger på sitet, indarbejder ændringen manuelt, verificerer at resultatet ser rigtigt ud, og udgiver det til sidst. Det tager lidt længere tid end at lade agenterne publicere direkte, men til gengæld ved jeg altid, hvem der har rørt hvad, og i hvilken rækkefølge. De ti sites bevæger sig i takt i stedet for at være ti separate lykkehjul.

De fleste mindre virksomheder, der begynder at bruge AI-agenter til indhold, marketing eller drift, starter med én proces ad gangen. Det er der ikke noget galt i. Problemet opstår først, når man skalerer op og lader flere automatiserede processer arbejde parallelt på samme systemer, uden at have tænkt over, hvad der sker, hvis de rører ved det samme på samme tid.

Min anbefaling til virksomheder, der er på vej i den retning, er enkel: byg et klart kontrolpunkt ind, før I skalerer antallet af automatiserede processer op. Det behøver ikke være avanceret. Det vigtigste er, at der findes ét sted, og gerne én ansvarlig, hvor det afgøres, om noget må gå live, og at ingen proces kan omgå det sted. Jo flere automatiserede processer der rører samme system, desto vigtigere er det kontrolpunkt.