I august holdt jeg et oplæg om at bruge Claude Code til arkitekturbeslutninger. Titlen var Governance at your fingertips. Jeg viste, hvordan man lægger arkitekturen i git, kører beslutninger gennem en fast arbejdsgang, som agenten arbejder inden for, og lader et menneske godkende, hvor det betyder noget. Agenten beslutter ikke. Den forbereder.
Så kom der et spørgsmål fra salen. Hvordan styrer I egentlig, hvad agenterne må?
Jeg svarede. Men jeg kunne høre på mig selv, at jeg svarede om mit eget setup. Om gates i min egen arbejdsgang. Ikke om organisationen omkring mig. Jeg kom til at stå som ham, der bare bruger løs og ikke har tænkt over rammerne.
Og der er noget om det. Jeg er tit forholdsvis naiv i min tilgang. Jeg prøver tingene af først og finder ud af rammerne bagefter.
I del 12 sluttede jeg med at spørge, hvor din organisation er henne. Jeg havde egentlig tænkt mig at bruge den her artikel på at svare på det. Men spørgsmålet viste sig at være det mindst brugbare. Det er nemt at svare på og svært at bruge. Du kan godt fornemme, at I er tidligt i det. Det fortæller dig ikke, hvad du gør på mandag.
Det apparat du har, bærer det ikke
Spørgsmålet fra salen var det rigtige spørgsmål. Det var bare stillet til den forkerte del af problemet.
For hvem skal egentlig svare på det i en organisation? Hvem beslutter, hvad agenter må, og hvor grænsen går?
I de fleste virksomheder ender det ét af tre steder. En styregruppe. En projektorganisation. Eller linjeledelsen. De strukturer er ikke tilfældige eller dårlige — de er bare bygget til noget andet. Til projekter med en start og en slutning, et budget og en leverance.
AI-arbejde ser ikke sådan ud. Det er løbende. Det går på tværs. Og det ændrer, hvordan folks arbejde ser ud, mens det står på.
Kører man det alligevel gennem det eksisterende apparat, går det galt tre steder.
Governance kommer på plads, men læringen bliver siddende hos det team, der lavede pilotprojektet. Ingen andre får glæde af den.
Beslutninger eskalerer opad, fordi det er der, autoriteten sidder. Også når den bedste beslutning kunne træffes tæt på arbejdet.
Og påvirkningen på roller og opgaver er der ingen, der ejer. Det er hverken IT's eller HR's bord, så det bliver ingens.
Det skyldes ikke, at nogen gør noget forkert, men at strukturen ikke er bygget til opgaven.
Det skyldes ikke, at nogen gør noget forkert, men at strukturen ikke er bygget til opgaven.
De fire strukturer, og hvor de hører til
Melissa Reeve beskriver i bogen Hyperadaptive fire strukturer, der er bygget til netop den opgave. Jeg har taget dem til mig, fordi de svarer på det, jeg ikke kunne svare på fra scenen.
Et AI Council sætter retning og guardrails. Det beslutter, hvad der er i spil, hvad der ikke er, og hvordan AI-investeringerne hænger sammen med strategien. Det er tværfagligt sammensat, og her er et råd fra bogen, jeg godt kan lide: tag skeptikerne med. De stiller de spørgsmål, der ellers først dukker op, når det er dyrt.
Activation Hubs er det sted, teams går hen, når de skal have noget til at virke i praksis. Teknisk hjælp, oplæring, koordinering. Impact Hubs holder til gengæld øje med, hvad automatiseringen gør ved roller og opgaver. Hvilke kompetencer mangler, hvilke roller er ved at ændre sig, hvem skal have hjælp. Det er organisationens tidlige varsling på mennesker. Og en Knowledge Engine samler use cases, politikker og erfaringer ét sted, så læring ikke bliver siddende hos det team, der gjorde det først.
Så langt bogen. Her er det, jeg selv er kommet frem til, mens jeg tænkte over den.
De fire strukturer hører ikke til det samme sted i organisationen.
Council og Knowledge Engine giver kun mening én gang. Ét sted der sætter retning, ét sted hvor viden samles. Har du to councils, har du to retninger.
Activation Hubs og Impact Hubs er det modsatte. De skal være netværk tæt på de teams, de betjener. Et hub, der sidder langt fra arbejdet, bliver en ticketkø. Man skriver ind, man venter, man får et svar der ikke helt passer. Det er præcis den friktion, strukturen skulle fjerne.
Det er forskellen mellem et competence center og et netværk, og den forskel opstår ikke af sig selv. Nogen skal beslutte den.
Rækkefølgen er designbeslutningen
Nu kommer den del, jeg synes er den interessante. Ikke hvilke strukturer der findes, men hvornår du bygger dem.
De fleste modenhedsmodeller, man støder på, stopper ved diagnosen. De fortæller dig, hvor du er, men ikke hvad du bygger som det næste. Og det er det spørgsmål, man reelt sidder med.
Reeve gør det bedre end de fleste. Hun knytter konkrete træk til hvert stadie, og rækkefølgen herunder følger hendes. Jeg har bare haft brug for at oversætte den til noget, jeg kan bruge på en mandag.
Rækkefølgen er ikke tilfældig: council kommer først, før pilotprojekterne, ikke efter. Retningen og rammerne skal være der, mens folk begynder at prøve ting af. Ellers bruger du det første år på at rydde op i eksperimenter, ingen havde aftalt. Det er også her, mit svar fra scenen hørte hjemme. Ikke "sådan gør jeg selv", men "her er det sted, hvor vi beslutter, hvad agenter må".
Activation Hubs og Knowledge Engine, når eksperimenterne bliver til arbejdsgange. Så længe det er enkeltpersoner, der prøver ting af, har du ikke brug for en struktur. Når AI begynder at indgå i det daglige arbejde flere steder, har du brug for et sted at få hjælp og et sted, hvor erfaringen samles. Springer du Knowledge Engine over, gentager hvert team de samme fejl. Det er dyrt, og det er stille. Ingen opdager det.
Impact Hubs, når agenter begynder at flytte roller. Ikke bagefter. Det er den fejl, jeg tror er nemmest at lave, fordi den tekniske del af automatisering lykkes længe før den menneskelige del gør. Du kan have agenter i produktion og et team, der ikke ved, hvad deres arbejde er om et halvt år.
Alle fire, synkroniseret, når du skalerer. Synkroniseringen er ikke pynt: fire strukturer, der ikke taler sammen, genskaber præcis de siloer, de skulle opløse, og nu har du bare fire nye.
Og så den fejl, der er værd at nævne til sidst, fordi den er den mest fristende. At bygge alle fire på én gang.
Det ser grundigt ud. Det ligner nogen, der tager det alvorligt. Men strukturer koster. De koster møder, koordinering og folks tid. Det er lidt som at ansætte en teamleder, før der er et team. Rollen er rigtig nok. Den er bare tom. Bygger du strukturerne, før der er noget for dem at lave, har du overhead uden værdi. Og du har brugt den troværdighed, du får brug for senere.
Det er en model, ikke et bevis
Jeg må hellere sige det ligeud. Jeg har ikke prøvet det af hos en kunde endnu.
Den kommer fra en bog, jeg har læst, og fra det, jeg selv har tænkt videre undervejs. Den har ikke mødt en rigtig organisation med budgetter, travlhed og folk, der har en holdning til, hvem der bestemmer hvad. Det kommer den forhåbentlig til.
Men jeg fandt ud af, at jeg selv manglede den. Jeg har brugt et halvt år på at skrive om, hvordan man arbejder med agenter i praksis, og jeg havde ikke tænkt over, hvem i organisationen der sætter rammerne for det. Det var derfor, spørgsmålet fra salen ramte.
I del 14 går jeg videre til det, der ligger under strukturerne. Hvor beslutningerne hører hjemme, og hvorfor det tekniske lag og det organisatoriske lag skal designes sammen i stedet for efter hinanden.