De fleste AI-piloter dør ikke på modelvalget, men på turen fra
De fleste AI-piloter dør ikke på modelvalget, men på turen fra udviklingskontoen til produktionskontoen. AWS har nu vist en måde at automatisere den tur for Amazon Quick: en MCP-server, der kører på Amazon Bedrock AgentCore, og som promoverer dashboards, datasæt og andre ressourcer mellem konti med en komplet auditlog.
Hvorfor promovering mellem konti stopper så mange piloter
En pilot bygges typisk i én AWS-konto, hvor teamet kan eksperimentere frit. Produktion ligger i en anden konto med strammere adgang og andre ejere. Mellem de to ligger et manuelt arbejde, som AWS selv beskriver som fejlbehæftet: eksportere, rette referencer, importere, tjekke at tingene ser rigtige ud.
Jeg har set den slags manuelt mellemled gå galt på tre måder. Ressourcer bliver kopieret med hånden og afviger gradvist fra hinanden. Ingen kan bagefter dokumentere, hvem der flyttede hvad og hvornår. Og promoveringen er så besværlig, at den bliver udskudt, så produktion halter efter udvikling.
Det flytter AWS mellem udvikling og produktion
I AWS' eksempel promoveres Amazon Quick-ressourcer som agenter, action connectors, vidensbaser, flows og spaces fra en udviklingskonto til en produktionskonto gennem ét kontrolleret trin i stedet for en række manuelle handlinger. Pointen er ikke selve kopieringen. Pointen er, at forløbet bliver gentageligt: samme input giver samme resultat, uanset hvem der starter det.
Udviklingskontoen kan være stedet, hvor man afprøver og justerer, mens produktionskontoen kun modtager det, der er besluttet at gå videre. Grænsen mellem de to konti bliver en bevidst port frem for en flaskehals.
Grænsen mellem de to konti bliver en bevidst port frem for en flaskehals.
Sådan arbejder en idempotent MCP-server på AgentCore
Løsningen er bygget som en MCP-server. MCP, Model Context Protocol, er den åbne protokol, der lader en agent kalde værktøjer på en ensartet måde. Her er værktøjet "promover denne ressource", og det kører på Amazon Bedrock AgentCore.
Det vigtigste designvalg er idempotens. Et idempotent kald kan gentages uden uønskede bivirkninger: kører en promovering to gange, ender produktion i samme tilstand som efter første gang. Det er afgørende, når en agent eller et script prøver igen efter en timeout, eller når to personer ved et uheld starter det samme. Uden idempotens risikerer man dubletter eller halvt overskrevne ressourcer.
Samme tankegang går igen i [flerkonto-adgang via AgentCore Gateway](/artikler/flerkonto-ai-agent-agentcore-gateway-mcp/) og i [multi-miljø adgang til Claude Platform på AWS](/artikler/multi-miljo-adgang-claude-platform-aws/): ét styret indgangspunkt i stedet for brede rettigheder på tværs af konti.
Auditlog gør udrulningen til noget, man kan stå til regnskab for
Hver promovering efterlader et spor: hvilken ressource, fra hvilken konto til hvilken, på hvis foranledning og med hvilket udfald. Det er forskellen på "vi tror, det blev rullet ud" og "her er beviset".
Jeg stoler ikke på en AI-løsning, der ikke kan fremvise et spor. Når loggen er en del af selve mekanismen og ikke noget, man skal huske at udfylde bagefter, behøver ingen at rekonstruere historikken, når nogen spørger. Det samme gælder, når man vil [evaluere og følge agenters adfærd](/artikler/agentcore-evaluations-framework-agnostisk-evaluering/): det, der ikke kan observeres, kan ikke styres.
Tjekliste: det skal være på plads før I automatiserer promovering
Automatisering forstærker det, der allerede er der, både gode og dårlige vaner. Disse punkter bør sidde, før I lader en agent eller en pipeline flytte ressourcer:
- **Klar kontoadskillelse.** Udvikling og produktion er separate konti med hver deres roller, og ingen bruger har fuld adgang til begge. - **Mindst mulige rettigheder.** Promoveringsværktøjet må kun kunne det, det skal: læse fra kilden og skrive de aftalte ressourcetyper i målet. - **Entydig identitet på ressourcer.** Idempotens kræver, at I kan genkende en ressource på tværs af konti, så en gentagen kørsel opdaterer frem for at duplikere. - **Godkendelsestrin.** Beslut, hvem der skal sige ja, før noget går i produktion, og hvad der kan gå igennem automatisk. - **Auditlog med ejer.** Loggen skal gemmes et sted, hvor den ikke kan rettes af dem, den handler om, og nogen skal have ansvaret for at læse den. - **Plan for tilbagerulning.** Vid på forhånd, hvordan I vender tilbage til forrige version, hvis en promovering viser sig forkert.
Det betyder det for danske virksomheder med agenter i drift
Mange danske virksomheder har efterhånden et par AI-løsninger, der virker i test, men som aldrig har været igennem en ordentlig overgang til drift. Her er overgangen ofte den svageste led, ikke teknologien. Et gentageligt, logget promoveringstrin gør det realistisk at holde udvikling og produktion adskilt uden at gøre hver udrulning til et projekt.
Som principal konsulent hos AI Enterprise driver Kim Like større AI-projekter fra problemafklaring til drift, og netop den sidste strækning er der, hvor de fleste planer skranter. Vores anbefaling er at begynde småt: vælg én type ressource, få tjeklisten ovenfor på plads, og lad auditloggen vise, om processen holder, før I udvider.
Mønsteret er ikke forbeholdt Amazon Quick. En MCP-server med idempotente kald og indbygget sporbarhed kan lige så vel flytte konfigurationer, prompts eller agentdefinitioner mellem miljøer. Det interessante er ikke det enkelte værktøj, men at promovering bliver en kontrolleret, dokumenteret handling, som både teknikere og revisorer kan forholde sig til.