AI-agenter bliver til ansatte: Er du klar?
Fra pilotprojekter til produktion
AI-agenter bevæger sig fra eksperimenter til infrastruktur. De læser, beslutter og handler. Nogle gange som reaktion på et menneske. Nogle gange på egen hånd.
Hastigheden er funktionen.
Hastigheden er også risikoen.
Det, der ændrer sig, når agenter bliver til "infrastruktur", er, at de holder op med at være et enkelt teams værktøj og begynder at blive en delt afhængighed. De berører identitet, data, samarbejdsflader og operationelle arbejdsgange. I det øjeblik en agent kan udløse handlinger på tværs af systemer, er spørgsmålet ikke længere "virker det", men "kan vi kontrollere det i stor skala". Microsofts vejledning til implementering af AI-agenter er eksplicit omkring rækkefølgen: planlæg agenter, styr og sikring af agenter, byg agenter, og betjen derefter agenter. Hvis du vender den rækkefølge, får du typisk implementering før kontrol.
Hvorfor agenter er sværere end apps
Microsofts Cloud Adoption Framework beskriver agenter som software, der kan ræsonnere over input, bruge værktøjer og udføre handlinger, bakket op af instruktioner, hentning, handlinger og hukommelse. Denne kombination er det, der gør agenter nyttige, og det, der gør dem sværere at styre end traditionelle apps. Du implementerer ikke bare kode. Du implementerer beslutningsløkker med rækkevidde i data og systemer.
I praksis betyder "værktøjer" API-adgang, workflow-udløsere, filhandlinger, identitetsopslag, ticketautomatisering og administratorhandlinger. "Hentning" betyder, at agenten kan trække information fra interne kilder og syntetisere den til output og beslutninger. "Hukommelse" betyder, at den kan bære kontekst på tværs af interaktioner, hvilket er effektivt, men også øger risikoen for, at data opbevares, genbruges eller dukker op på det forkerte sted, hvis kontrollerne er svage. Derfor forbinder Cloud Adoption Framework agentstyring med mere end IAM: datastyring, observerbarhed, sikkerhedskontroller og udviklingspraksis skal arbejde sammen.
Gjennom samarbejde med Fortytwo, pensjonerte Bufdir dets aldrende «Mine Ansatte»-oppsett og gik over til en ny tilgangsmodell bygget på CheckID og «Lederportalen».
Forskellen var umiddelbar: onboardingen af nye medarbejdere og midlertidige medarbejdere blev renere og mere sikker; manuelle rutiner blev luget ud, og organisationen havde endelig et grundlag for korrekte adgangskontrol og en klar køreplan for adgangskodefri godkendelse.
Hvad der går i stykker først
Det første, der går i stykker i de fleste organisationer, er ikke modellen. Det er ejerskab.
Ejerskab mislykkes, fordi agentidentiteter ser vildledende bekendte ud. De skabes som "endnu en appidentitet" og bliver derefter hurtigt operationelle aktører. Når en agent kan køre kontinuerligt, overlever den det sprint, der skabte den. Når den overlever sprintet, har den brug for en livscyklus. Når den har brug for en livscyklus, har den brug for en reel ansvarlig part med fornyelsesmyndighed, ikke bare en person, der engang skrev koden.
Hvorfor dette nu er et emne for ledelsen
Derfor er agentidentitet nu et emne for ledelsen. Hvis man behandler agentidentiteter som almindelige app-appidentiteter, ender man med den samme fejltilstand som det sidste årti med serviceprincipaler, bare med mere autonomi og større overfladeareal.
Risikokurven ændrer sig, fordi agenter reducerer friktion. Reduceret friktion er pointen. Det betyder også, at flere handlinger sker automatisk, og at flere systemer kan kædes sammen. En enkelt identitet med overautorisationer kan blive en genvej gennem ellers veldesignede kontroller. Når noget går galt, sker det hurtigere og spreder sig mere, fordi agenten er bygget til at flytte arbejdet fremad uden at vente på godkendelser i hvert trin.
Agentspredning er, hvordan du mister kontrollen
Microsoft kalder det agent sprawl: Agenter dukker op i lommer af virksomheden, formerer sig hurtigt og overlever det projekt, der skabte dem. Tilladelserne er normalt for brede, fordi "det var nemmere", og så kommer ingen tilbage for at reducere dem. Når noget ser mistænkeligt ud i loggene, er der ingen ansvarlig person til at spørge, hvad agenten skal gøre. Det er sådan, små automatiseringer bliver til sikkerhedshændelser.
Udbredelse er ikke kun "for mange agenter". Det er for mange agenter uden en fælles standard for navngivning, metadata, risikoniveauinddeling og gennemgang. Det er agenter oprettet i forskellige produkter, af forskellige teams, med forskellige antagelser om dataadgang, operationelle grænser og overvågning. Man ender med identiteter, der kan autentificere, kalde API'er og udføre handlinger, mens organisationen kæmper med at besvare grundlæggende spørgsmål som, hvad agenten er til, hvilke data den må røre ved, og om nogen har gennemgået dens tilladelser i det sidste kvartal. Microsofts vejledning peger eksplicit på behovet for organisationsomfattende styring og sikkerhedspraksis for agenter, fordi team-for-team-styring ikke holder, når agenter spreder sig.
Microsofts retning: først styring, derefter skalering
Microsofts svar i Entras økosystem er at skabe førsteklasses identiteter for agenter gennem Entra Agent ID og at placere agentstyring i en implementeringslivscyklus, der starter med planlægning og styring, ikke værktøjer. Du planlægger, du styrer og sikrer, du bygger, du driver. Hvis du inverterer den rækkefølge, får du skalering før kontrol.
Det praktiske skift her er standardisering. I stedet for at hvert team opfinder sit eget identitetsmønster, bevæger man sig mod gentagelige identitets- og styringsbyggesten. I Entra Agent ID behandles opdagelse også som et førsteklasses problem gennem Agent Registry, der beskrives som et centraliseret metadatalager og en opdagelsesmekanisme for implementerede agenter på tværs af organisationen. Det er vigtigt, fordi styring starter med at vide, hvad der findes, ikke at gætte.
Hvordan bør et udøvende mandat se ud?
Den skal være kort, håndhævelig og bygget til virkeligheden. Virkeligheden omfatter omorganisationer, leverandørskift, travle teams og projekter, der afsluttes. Mandatet skal definere, hvordan agenter har tilladelse til at eksistere i din lejer, hvordan de ejes, og hvordan de lukkes ned.
Ansvarlighed, der overlever organisationsændringer
Start med ansvarlighed, der overlever organisationsændringer. Entra Agent ID introducerer administrative relationer, der adskiller teknisk kontrol fra forretningsansvar, herunder sponsorer. En sponsor er påkrævet, når man opretter en agentidentitet eller en agentplan. Det er en indbygget tvangsfunktion: hver agent skal have et menneske eller en gruppe, der kan forklare, hvorfor den eksisterer, og beslutte, hvornår den skal fornyes eller fjernes.
Denne adskillelse er vigtig, fordi tekniske administratorer ikke behøver at være dem, der retfærdiggør forretningsformålet, og virksomhedsejere ikke behøver administratorrettigheder for at være ansvarlige. Sponsorer træffer livscyklusbeslutninger og holder "hvorfor"-spørgsmålet i live. Ejerne håndterer teknisk administration. Dette undgår den klassiske fælde, hvor ansvarlighed ligger i en Jira-sag eller en afgået medarbejders indbakke.
Livscyklus som standard, ikke som undtagelse
Kræv derefter livscyklus som standard. Midlertidige agenter bør ikke blive permanente beboere. Din baseline bør omfatte udløb, periodisk gennemgang og et register, der lader dig finde ud af, hvad der findes, og hvorfor. Microsoft beskriver eksplicit et centraliseret agentregister som en opdagelsesmekanisme med metadata om registrerede agenter. Det er sådan, du forhindrer usynlige agenter i at akkumulere usynlige rettigheder.
Et register er ikke bureaukrati. Det er grundlæggende operationel kontrol. Det bør indeholde tilstrækkelige metadata til at træffe hurtige beslutninger, såsom formål, sponsor, miljø, dataomfang og hvornår det sidst blev gennemgået. Uden det bliver "adgangsgennemgang" gætteri. Med det bliver fornyelse en beslutning i stedet for et ritual. Microsofts Agentregister er positioneret præcist til denne synlighed og organisering i stor skala, herunder vejledning om agentmetadata og synlighedsmønstre.
Grænser, der begrænser eksplosionsradiusen
Endelig skal du sætte grænser for, hvor agenter kan køre, og hvad de kan røre ved. Cloud Adoption Framework-styringsperspektivet forbinder datastyring og compliance, observerbarhed, sikkerhedskontroller og udviklingspraksis. Dette er ikke kun et IAM-problem. Det er Purview og datakontroller, det er overvågning og omkostningssynlighed, det er trusselsbeskyttelse, og det er sikre byggemønstre.
Det er her, mange organisationer underinvesterer. De fokuserer på godkendelse og glemmer, at agentens værdi kommer fra adgang til data og evnen til at handle. Hvis du ikke kombinerer identitetskontroller med datakontroller og overvågning, vil du ikke se forskellen mellem "travl agent" og "kompromitteret agent", før det allerede er dyrt. Cloud Adoption Frameworks styrings- og sikkerhedsvejledning er tydelig om, at disse kontroller skal være ensartede på tværs af organisationen og ikke genopfindes pr. team.
Fortytwo udsigt
AI-agenter bør behandles som digitale kolleger med en strengere kontrakt end mennesker. Mennesker har kontekst og dømmekraft. Agenter har hastighed. Dit job er at sikre, at hastigheden ikke overstiger intentionen.
En "strengere kontrakt" betyder, at agenten aldrig må være vag. Den har et formål, der kan rummes i én sætning, en sponsor, der er ansvarlig, grænser, der håndhæves, og en livscyklus, der slutter, medmindre den fornyes. Sådan bevarer du autonomien nyttig i stedet for risikabel.
Resultatstandarden, der holder dig ærlig
Hvis du ønsker ét praktisk resultat for ledelsen, så sigt efter dette: hver aktør er identificerbar, tilskrivelig, gennemgåelig og inddæmbar. Hvis du ikke kan gøre disse fire ting, har du ikke styring. Du har håb.
Identificerbar betyder, at du kan finde den og forstå, hvad den bruges til, uden arkæologi.
Tilskrivelig betyder, at der findes en sponsor, som kan forny eller trække den tilbage.
"Kan gennemgås" betyder, at tilladelser og omfang med jævne mellemrum godkendes på baggrund af den aktuelle virkelighed og ikke sidste års antagelser.
Inddæmbar betyder, at politikker og grænser begrænser skader, når noget går galt, så hændelser ikke bliver til problemer for hele lejeren.