AI-agenter udfordrer den governance, du netop har bygget

Meget af den AI-governance, der er blevet udviklet de seneste år, hviler på en antagelse, der sjældent bliver sagt højt: Et menneske skriver noget ind, læser svaret og vurderer, om det kan bruges. Mennesket er altså sikkerhedsforanstaltningen. Politikken skal blot gøre det klart, hvad mennesket må skrive ind.

Agenter fjerner det led. Og når mennesket ikke længere er den primære kontrolmekanisme, opstår der en række nye governance-udfordringer. Fire af dem er særligt vigtige:

1: Agenter er kode

Det lyder banalt, indtil man tænker på, hvordan kode plejer at blive behandlet i en organisation. Kode bliver versionsstyret, reviewet, testet, dokumenteret og udrullet gennem en proces, nogen har ansvaret for. En agent bygget ind i en chatgrænseflade bliver ofte ikke underlagt de samme krav, selvom den kan påvirke forretningskritiske processer.

Så det første spørgsmål er ikke, hvad agenten må. Det er, hvem der har ansvaret for koden, og hvordan organisationen opdager det, hvis agenten begynder at opføre sig anderledes end forventet.

2: Agenter kan handle autonomt

En sprogmodel svarer. En agent handler. Forskellen betyder, at fejl ikke længere bliver opdaget i det øjeblik, de opstår, men et stykke tid efter, når konsekvensen viser sig et andet sted i organisationen.

Det ændrer, hvad governance skal levere. Det er ikke nok at godkende, hvad en agent må gøre. Man skal også vide, hvordan den stoppes, hvem der bliver informeret, hvis noget går galt, og hvordan man ruller handlingerne tilbage. Det er lige så meget en driftsopgave som en governance-opgave. Og det kræver andre kompetencer end dem, der bruges til at skrive et regelsæt.

3: Agenter kan have bias

Det er det punkt, der er lettest at nikke genkendende til og sværest at gøre noget ved. En agent er formet af instruktioner, data, modeller og de valg, mennesker træffer under designet. Hvad skal agenten prioritere? Hvad regner den for et godt svar? Hvornår vurderer den, at noget er færdigt?

Når agenten først kører, træffer den de samme valg igen og igen. En medarbejder med en skæv vurdering bliver korrigeret af en kollega i løbet af en uge. Derfor er en gennemgang af, hvad der egentlig er blevet lagt ind i agenten ikke et akademisk hensyn. Det er den billigste kvalitetssikring, der findes, og den skal ske, inden agenten bliver sat i drift.

4: Agenter kan blive dyrere, end du regner med

Rejsen fra gratis værktøjer over i en abonnementsmodel gør omkostningen synlig, og token-forbruget bliver noget, man kan følge. Det er faktisk overskueligt at se, hvor mange tokens der bliver brugt. Med den synlighed følger et nyt fænomen, som nogen har døbt token maxing, altså at forbruget vokser, indtil nogen sætter en grænse.

Agenter arbejder anderledes end en person i en chat. En medarbejder stopper typisk, når opgaven er løst. En agent stopper først, når dens instruktion er gennemført, og de to ting er ikke nødvendigvis det samme. Derfor skal forbruget styres som en driftsomkostning med et loft og en ejer, ikke som en licens, der bliver betalt en gang om året. Ellers bliver det økonomien, der sætter grænserne, og det sker typisk midt i en måned og uden varsel.

Konklusion: Lav guardrails, ikke kun policies

Forskellen mellem guardrails og policies er hele pointen. En policy er et dokument, nogen skal kende og vælge at følge. En guardrail er en begrænsning, som er bygget ind i løsningen og holder, uanset om nogen har læst et bestemt dokument. Det kan fx være adgangsrettigheder, forbrugslofter, godkendelsestrin, før en handling får konsekvenser, og logs.

Policies er stadig nødvendige. De forklarer hensigten og gælder de steder, hvor teknikken ikke kan sætte grænsen. Men i det øjeblik systemet kan handle selv, kan kontrollen ikke længere bo i et dokument. Den skal bo i systemet.