AgentCore Policy Authoring: naturligt sprog

Jeg har set gang på gang, i mit eget arbejde med agentisk automatisering, at den, der forstår forretningsrisikoen ved en AI-agent, sjældent er den samme, der kan skrive politik-kode. En complianceansvarlig ved præcis, at en supportagent aldrig må godkende refusioner over et vist beløb uden en menneskelig godkendelse, men vedkommende kan ikke selv omsætte det til Dogwood, det politiksprog, AgentCore bruger til at styre, hvad en agent må og ikke må gøre.

Det er den flaskehals, Policy Authoring adresserer. Værktøjet tager en beskrivelse på almindeligt sprog, for eksempel "denne agent må kun kalde betalingsværktøjet mellem klokken 8 og 16 på hverdage", og oversætter den til en syntaktisk korrekt Dogwood-politik, som AgentCores runtime kan håndhæve direkte. Politikken bliver ikke en hensigtserklæring i et dokument et sted, den bliver en regel, agenten fysisk ikke kan bryde.

Den nye udvidelse retter sig især mod tidsbaserede begrænsninger, og det er ikke tilfældigt. Så snart en virksomhed kører mere end én agent i produktion, opstår behovet for at koordinere, hvornår hver enkelt agent må udføre bestemte handlinger, og det bliver hurtigt uoverskueligt at holde styr på manuelt.

Med den udvidede Policy Authoring kan man beskrive den slags regler samlet: en fakturagodkendelsesagent må kun eskalere sager i arbejdstiden, mens en overvågningsagent skal have lov til at reagere døgnet rundt. Begge dele formuleres som almindelige sætninger, og AgentCore omsætter dem til politikker, der gælder for de rigtige agenter uden at nogen skal skrive separate konfigurationsfiler for hver enkelt.

Det er en forskel, der betyder noget i praksis. Jeg har set den slags regler leve i et regneark eller i hovedet på en enkelt medarbejder, og jeg har set en agent i god tro udføre en handling uden for det tilsigtede tidsrum, simpelthen fordi ingen havde fået kodet begrænsningen korrekt. Det er ikke en dramatisk fejl. Det er den slags stille fejl, der først bliver synlig, når nogen spørger, hvorfor noget skete klokken tre om natten.

Det mest markante skifte er organisatorisk snarere end teknisk. Når en politik kan skrives og opdateres i almindeligt sprog, flytter ejerskabet af sikkerhedsreglerne fra udviklerteamet til dem, der faktisk har ansvaret for risikoen, altså jura, compliance og forretningsledelse.

Det løser et problem, jeg selv støder på jævnligt: en politik, der kun kan ændres af en udvikler, bliver i praksis en politik, ingen ændrer, fordi det kræver en sprint-prioritering at rette en enkelt regel. Når politik-teamet selv kan formulere og opdatere reglerne, uden en mellemled, bliver governance noget, der reelt følger med, når forretningen ændrer sig, i stedet for noget, der halter to kvartaler bagefter.

Det betyder ikke, at udviklerteamet er ude af billedet. Den genererede Dogwood-politik skal stadig gennemgås og godkendes, før den ruller i produktion, men selve forfatterskabet flytter til dem med den domænemæssige indsigt.

Naturligt sprog er fleksibelt, og det er både styrken og risikoen ved denne type værktøj. En sætning som "agenten må kun tilgå kundedata i arbejdstiden" kan tolkes forskelligt afhængigt af, om "arbejdstiden" betyder virksomhedens åbningstid, medarbejderens tidszone eller agentens serverregion.

Den praktiske løsning er at behandle den genererede Dogwood-politik som et udkast, der altid skal valideres, ikke som et endeligt produkt. Jeg anbefaler, at politik-teamet får vist den oversatte politik i et læsbart format, ikke bare rå Dogwood-syntaks, så de kan bekræfte, at oversættelsen rammer det, de faktisk mente. Det er en ekstra kontrol, der koster minutter, men som forhindrer, at en tvetydig formulering bliver til en produktionshændelse.

Det er også værd at teste politikken mod konkrete scenarier, før den går live. En regel, der lyder rigtig i teorien, kan vise sig at blokere en legitim handling eller, værre, lade en uønsket handling passere, fordi grænsetilfældet aldrig blev overvejet i formuleringen.

For danske virksomheder, der er i gang med eller overvejer at sætte AI-agenter i produktion, er den her udvikling relevant af en konkret grund: den sænker adgangsbarrieren for at have en reel governance-proces, uden at det kræver et dedikeret udviklerteam til at vedligeholde politikkerne.

Jeg ser jævnligt, i mit arbejde med at sætte agenter i produktion, at governance bliver den svageste kæde, når projektet skal fra pilot til drift. Ansvaret ligger typisk hos folk, der forstår risikoen, men ikke koden, og det skaber en flaskehals, som ofte forsinker lanceringen mere end selve den tekniske implementering.

Et værktøj, der lader compliance- og forretningsansvarlige formulere og opdatere sikkerhedspolitikker direkte, uden at stå i kø til en udviklerressource, flytter den flaskehals. Det gør det realistisk at holde politikkerne opdateret i takt med, at agenternes ansvarsområde vokser, hvilket i sidste ende er forudsætningen for at kunne skalere fra én agent i produktion til et helt økosystem af dem.