Den arkitektoniske skift, der kræves for at styre AI-agenter

AI er ikke længere bare en chatbot, der genererer tekst. I virksomhedsmiljøer udfører AI-agenter handlinger som henting af følsomme data, udløsning af arbejdsgange, aktivering af værktøjer og logning af aktiviteter på tværs af systemer. Autonomi ændrer hele diskussionen om styring; kontroller og procedurer, der oprindeligt var designede for menneskelige brugere og traditionelle applikationer, var ikke bygget til at styre software, der kan udføre multi-trins handlinger i runtime.

Risikoen er ikke teoretisk. Små huller i synlighed, adgangskontrol og revision kan hurtigt udvikle sig til runtime-fejl, der er svære at opdage og endnu sværere at rette.

For at følge med denne nye æra kan styring af AI-agenter ikke gøres ved at tilføje flere politikdokumenter. Det kræver styring ved design: en arkitektonisk tilgang, hvor kontroller er indbygget i kontrolplanet og gennemføres kontinuerligt i runtime. Hvis agenter skal opføre sig som digitale kolleger, må de arve de samme virksomheds-sikkerhedsforanstaltninger som mennesker, plus stærkere runtime-overvågning.

Hvorfor styring bryder sammen i konvergensens æra

Virksomhedsarkitektur er gået ind i en æra af konvergens. Data og arbejdslaster strækker sig nu over multiple skyer, private datacentre og kantmiljøer.

Der er organisationer, der kører deres platforme i parallelle systemer, fordi de har multiple processer at styre samtidigt. Dette inkluderer separate identitetssystemer, logningsrørledninger, kataloger og godkendte processer. Resultatet er, hvad nogen kalder en “Frankenstein-platform”, hvor integrationsomkostningerne stiger med hver ny værktøj eller sky-miljø. I virkeligheden viser denne fragmentering sig i hverdagsrealiteten.

Ifølge en ny undersøgelse nævner 47% af respondentende komplicerede adgangskrav og processer, og 44% nævner begrænset synlighed i, hvor data befinder sig, som barrierer for at bruge data effektivt.

Dette er netop, hvor agenter afslører revnerne mellem systemer.

For at besvare et forretnings-spørgsmål kan en agent være nødt til at hente data fra et on-premises ERP-system, et cloud-baseret CRM, operations-telemetri i en anden cloud og dokumenter i en samarbejdssuite. Hvis organisationen gennemtvinger politik forskelligt på hver lokalitet, vil agenten enten fejle eller, værre, lykkes på måder, som du ikke kan forklare eller kontrollere.

Dette er øjeblikket, hvor virksomhedsledere skal være opmærksomme. Agenter tvinger en højere standard, der kræver konsistens på tværs af miljøer og ansvarlighed i runtime.

Styring er derfor blevet trukket ind i rampelyset af regulatorer og sikkerhedsagenter. Et eksempel på dette er NIST AI Risk Management Framework, som betoner risikostyring på tværs af AI-livscyklussen, ikke kun ved byggetidspunktet. Det er en påmindelse om, at overholdelse og tillid er operationelle ansvar, ikke en gangs checkliste.

Fra politik til platform

Styring ved design betyder, at styring følger med arbejdslasterne i stedet for at genopbygges i hver silo. I praksis afhænger dette af tre byggeklodser:

• En samlet kontrolplan

Et sted at definere og gennemtvinge identitet, adgang, politik, kataloger og berettigelse på tværs af skyer og datacentre.

Målet er at skrive politikker én gang og gennemtvinge dem, hvor data og modeller kører, i stedet for at genopbygge kontrolsystemer system for system. Dette forhindrer agent-adfærd-drift, hvor den samme agent opfører sig sikkert i ét miljø, men farligt i et andet.

En praktisk test er simpel: Hvis en bruger ikke kan få adgang til en kolonne, skal du verificere, at en agent, der handler på deres vegne, heller ikke kan få adgang til den. Dette skal indikere, om de skrevne politikker gennemtvinges på tværs af planet.

• En data-fabrik baseret på åbne standarder

Agenter har brug for kontekst for at fungere. Når denne kontekst er spredt over forskellige strukturer ejede af forskellige hold, hjælper en data-fabrik med at standardisere semantik og adgangsmønstre, så agenter ikke behøver at lære en ny sæt af regler for hver dataset.

Åbne tabel-formater som Apache Iceberg understøtter dette ved at tillade multiple motorer at dele den samme styrede data uden at kopiere den til en ny silo. Dette er vigtigt, fordi data-duplikation er, hvor styring normalt fejler. Når hold begynder at kopiere “kun det, agenten har brug for”, har du skabt en ny, mindre styret miljø.

Hvis agenter kan fungere på tværs af datasets uden at introducere nye tilladelses-lukker, fungerer styring, som det skal.

• Real-time overvågning og afstamning

Agenter er kun styrbare, hvis du kan se, hvad de gør i runtime.

Overvågning her er ikke kun et “nice-to-have”, men er grundlaget for runtime-kontroller og incident-svar.

Specifikt skal der være end-to-end-bevis for agent-handlinger. Agenter skal kunne bevise handlinger, såsom hvilke data der blev adgang til og hvilke værktøjer der blev aktiveret, og derefter kan afstamning forbinde output til input. Dette tillader hold at gennemgå disse beslutninger og fejlfinde fejl, hvis nødvendigt, og derefter bevise overholdelse.

Behandle agenter som “digitale kolleger”

En af de mest nyttige mentale modeller er at behandle agenter som digitale kolleger.

Her er en sammenligning, der bryder dette ned: Ligesom medarbejdere har adgangsbajere, der giver adgang til visse bygninger og rum, men ikke andre, tillader styring agenter at have adgang med begrænsninger. En vigtig tilføjelse er, at agenter må være situationsbevidste om, hvad de er tilladt at afsløre.

Overvej en support-agent. Den kan være nødt til at få adgang til tidligere support-sager for at løse et problem, men den kan ikke lække en anden kundes private detaljer, mens den gør det. Andre ord, agenten kan bruge begrænset viden til at resonere, men den skal stadig gennemtvinge afsløringens grænser. Dette er ikke et “prompt-skriveri”-problem, som vi historisk har vidst, hvordan vi skal navigere; i stedet er det et identitets- og runtime-gennemtvingelses-problem.

Hvad ændrer sig i 2026: agenter flytter fra eksperimenter til produktion

2026 er året, hvor eksperimenterne sluttes, og agenterne tager produktionssædet.

Dette skift tvinger virksomheder til at operere i to hastigheder. Den ene er innovationshastighed, hvor hold tester nye modeller, værktøjer og agent-arbejdsgange for at opnå en konkurrencemæssig fordel. Og den anden er den sikre hastighed, hvor systemer må opfylde overholdelses- og operationelle krav, som kan inkludere stramme adgangskontroller og blindspots.

Uden en fast arkitektonisk styring vil disse to hastigheder komme i konflikt.

Hvis hold deployer disse agenter, før de er styret, vil der være et patchwork af enkeltstående kontroller og operationelle fejl. Og hvis det modsatte sker, får du en fejltilstand, hvor sikkerhed blokerer alt, og innovation flytter til skygge-IT, hvilket undergraver styring.

Målet er ikke at vælge en hastighed. Det er at bygge en arkitektur, der understøtter begge.

En praktisk checklist for at styre agenter i runtime

• Hvis du bygger eller skalerer agenter, er det afgørende at stille dig selv følgende spørgsmål for at afsløre, om styring er virkelig arkitektonisk: Kan du forklare, end-to-end, hvilke data en agent har adgang til for at producere et svar eller udføre en handling?
• Er adgangsbeslutninger konsistente på tværs af hybrid-miljøer, eller adskiller de sig efter platform?
• Har du telemetri for agent-handlinger, herunder værktøj-aktiveringer, politik-kontroller og menneskelige eskaleringer?
• Kan du bremse, pause eller karantæne en agent i runtime, hvis den opfører sig uventet?
• Har du en post-deploy-moniteringsplan, der er i overensstemmelse med dine regulatoriske forpligtelser og risiko-appetit?

Hvis du ikke kan besvare disse spørgsmål, skal du behandle din agent-deployment som en produktion-incident, der venter på at ske.

Styringsskiftet skal være arkitektonisk, eller også eksisterer det ikke

Agenter vil blive en standardtilføjelse til virksomhedsoperationer. Spørgsmålet er, om de vil blive en pålidelig del af virksomhedsoperationer.

Hvis agenter ikke styres mindst lige så tillidsværdigt som mennesker og kritiske software, vil konsekvenserne være reelle. Vi vil se disse konsekvenser i data-lækage, overholdelsesfejl, operationelle fejl og tab af tillid til AI-programmer.

Lederne skal ophøre med at behandle agent-styring som en dokumentations-øvelse. Da platform-kapaciteterne udvides, skal agent-styring være en af dem, der overtager oversigt over andre roller. Dette indebærer at indbygge kontroller i kontrolplanet, gøre handlinger observerbare og beslutninger revisionssikre. Og derefter skaleres.

Dette er, hvordan du får agenter, der flytter sig hurtigt uden at bryde virksomheden.