AI-agent-kæder: den skjulte

Da AI-agenter for alvor rykkede ind i produktionsmiljøer, lå fokus naturligt på agenten som enhed. Kunne den holde sig inden for sine instrukser? Kunne den undgå at give forkerte svar? Det arbejde er stadig vigtigt. Det dækker bare kun en del af risikobilledet.

Det, jeg ser de fleste virksomheder overse, er, at agenter i praksis sjældent arbejder alene. En agent, der håndterer kundeservice, kalder måske en anden agent til at slå op i et CRM-system, som igen kalder en tredje til at opdatere en database. Hver overgang i den kæde er et sted, hvor adgang, kontekst og ansvar kan glide.

Jeg har set præcis den type kæder hos en global virksomhed med drift i flere lande, som jeg har hjulpet med automatisering: en agent, der oprindeligt fik adgang til ét system til ét formål, endte som et led i en længere proces, ingen havde designet som helhed. Systemet fungerede, indtil det ikke gjorde, og fejlfinding blev markant sværere, fordi ingen enkelt agent havde gjort noget forkert isoleret set.

Permission creep er ikke nyt i IT-sikkerhed. AI-agenter gør det bare langt hurtigere at ende i en situation, hvor adgangen ikke længere matcher behovet. Når en agent skal løse en ny opgave, er den nemmeste vej ofte at give den bredere adgang i stedet for at bygge en præcis, afgrænset rettighed til netop den opgave.

Problemet forstærkes, når agenter selv kan anmode om eller videregive adgang til andre agenter i en kæde. En agent, der oprindeligt kun måtte læse data, kan ende med skriveadgang, fordi en efterfølgende opgave krævede det, og ingen efterfølgende har strammet adgangen igen. Over tid akkumuleres rettigheder, som ingen længere kan redegøre fuldt ud for.

Det handler ikke om, at agenterne handler ondsindet. Adgang er i praksis lettere at udvide end at indskrænke, og den logik forstærkes markant, når flere agenter er koblet sammen i en arbejdsgang. Uden en systematisk gennemgang af, hvilken adgang der reelt er nødvendig for hvert led, vokser overfladen for fejl og misbrug stille og roligt.

Et af de mest oversete problemer i agent-kæder er, at ejerskabet bliver tyndere, jo længere man bevæger sig ind i kæden. Den første agent har typisk en klar ejer: en afdeling, et team, en navngiven ansvarlig. Når den agent trigger en anden, som trigger en tredje, forsvinder ejerskabet ofte i overgangene.

Spørgsmålet bliver: hvem er ansvarlig, hvis noget går galt i led tre? Teamet, der byggede den første agent? Systemet, den anden agent trak data fra? Den, der oprindeligt godkendte kæden som helhed, hvis en sådan person overhovedet findes?

I mange organisationer er svaret uklart, fordi kæden er vokset organisk over tid, agent for agent, uden en samlet governance-model. Det er ikke ondskabsfuldt design. Det er en naturlig konsekvens af, at agenter er nemme at koble sammen, mens governance-strukturerne omkring dem sjældent bygges til at følge med i samme tempo.

Sporbarhed er den tredje brik, der ofte mangler. Når én agent handler, er det som regel muligt at se, hvad den gjorde, og hvornår. Når fem agenter arbejder sammen i en kæde, bliver det markant sværere at rekonstruere den fulde hændelseskæde bagefter.

Det bliver tydeligt, når noget går galt: en forkert beslutning, en datalæk, en handling, der aldrig burde være sket. Uden en samlet log på tværs af hele kæden, ikke bare pr. agent, er det næsten umuligt at afgøre, hvor fejlen opstod, og hvorfor. Det gør det svært at rette op med præcision, og det gør det endnu sværere at forhindre den i at ske igen.

Manglende sporbarhed er ikke kun et teknisk problem. Det er et governance-problem, fordi det svækker organisationens evne til at stå til ansvar, internt og over for kunder, samarbejdspartnere og eventuelt myndigheder, hvis en agent-kæde har håndteret persondata eller forretningskritiske beslutninger.

Der findes ikke én genvej, der løser det her. Der er en retning, jeg selv bygger efter i mine egne systemer. Det starter med agent-identitet: hver agent skal have en unik, sporbar identitet, ligesom man ville kræve det af en medarbejder eller en systemkonto. Uden det er det umuligt at afgøre, hvem der reelt gjorde hvad i en kæde.

Dernæst kommer løbende overvågning, ikke kun ved opsætning, men gennem hele agentens levetid. Adgang og adfærd skal gennemgås jævnligt, ikke kun når noget allerede er gået galt. Det handler om at fange permission creep, før den bliver et reelt problem.

Endelig kræver det håndhævelse, der virker før bruddet, ikke bagefter. Konkrete grænser for, hvad en agent kan gøre, og hvad den kan videregive til den næste agent i kæden, håndhævet automatisk, ikke kun som en politik på papir. Jeg tænker selv agent-kæder som en samlet arkitektonisk beslutning fra starten, ikke en samling enkeltstående agenter, der senere kobles sammen ad hoc.

For danske virksomheder, der allerede har eller er ved at sætte AI-agenter i drift, er pointen ikke, at man skal stoppe eller bremse udrulningen. Pointen er, at governance-arbejdet skal flytte fokus fra den enkelte agent til hele kæden, den indgår i.

Det betyder i praksis, at man som virksomhed bør kortlægge, hvilke agenter der taler sammen, hvilken adgang der reelt flyder mellem dem, og hvem der har ansvaret for kæden som helhed, ikke kun for de enkelte led. Det kræver både teknisk indsigt og en klar organisatorisk beslutning om ejerskab.

De virksomheder, der får styr på det nu, mens agent-landskabet stadig er relativt overskueligt, står markant bedre rustet end dem, der venter, til kæderne er blevet så komplekse, at ingen længere kan overskue dem. Governance omkring agent-kæder er ikke en eftertanke. Det er en forudsætning for, at AI-agenter kan skaleres sikkert i produktion.