Den arkitektoniske skiftet som kreves for å styre AI-agenter

AI er ikke lenger bare en chatbot som genererer tekst. I bedriftsmiljøer tar AI-agenter handlinger som å hente sensitive data, utløse arbeidsflyter, ringe verktøy og logge aktivitet over systemer. Autonomi endrer hele diskusjonen om styring; kontroller og prosedyrer som opprinnelig var designet for menneskelige brukere og tradisjonelle applikasjoner var ikke bygget for å styre programvare som kan utføre flertrinns handlinger på kjøretid.

Risikoen er ikke teoretisk. Små hull i synlighet, tilgangskontroll og overvåkbarhet kan raskt bli til kjøretidsfeil som er vanskelige å oppdage og enda vanskeligere å reversere.

For å holde tritt med denne nye æraen, kan styring av AI-agenter ikke gjøres ved å legge til flere politidokumenter. Det krever styring ved design: en arkitektonisk tilnærming hvor kontroller er innbygget i kontrollplanet og påtvinges kontinuerlig på kjøretid. Hvis agenter skal fungere som digitale kolleger, må de arve de samme bedriftssikkerhetsskranker som mennesker, pluss sterkere overvåkning på kjøretid.

Hvorfor styring feiler i konvergensens æra

Bedriftsarkitektur har gått inn i en æra av konvergens. Data og arbeidsbelastninger omfatter nå flere skyer, private datasentre og kantmiljøer.

Det finnes organisasjoner som kjører sine plattformer i parallellsystemer fordi de har flere prosesser å håndtere samtidig. Dette inkluderer separate identitetssystemer, loggpiper, kataloger og godkjente prosesser. Resultatet er det noen kaller en “Frankenstein-plattform”, hvor integrasjonskostnadene øker med hver nytt verktøy eller skyemiljø. Faktisk viser denne fragmenteringen seg i hverdagsrealiteten.

Ifølge en nylig undersøkelse, nevner 47% av respondentene kompliserte tilgangskrav og prosesser, og 44% nevner begrensede muligheter for å se hvor data befinner seg som barrierer for å bruke data effektivt.

Dette er nettopp der agenter avslører sprekker mellom systemer.

For å svare på et forretnings-spørsmål, må en agent hente data fra et lokalt ERP-system, et sky-basert CRM, operasjonell telemetri i en annen sky og dokumenter i et samarbeidsverktøy. Hvis organisasjonen påtvinger politikk forskjellig i hver plass, vil agenten enten feile eller, verre, lykkes på måter du ikke kan forklare eller kontrollere.

Dette er øyeblikket når bedriftsledere må være oppmerksomme. Agenter tvinger en høyere standard som krever konsistens over miljøer og ansvar på kjøretid.

Styring, av denne grunn, blir trukket inn i rampelyset av regulatorer og sikkerhetsbyråer. Et eksempel på dette er NIST AI Risk Management Framework, som betoner risikostyring over hele AI-livssyklusen, ikke bare på byggetid. Det er en påminnelse om at samsvar og tillit er operative ansvar, ikke en gangs kontrollister.

Fra politikk til plattform

Styring ved design betyr at styring følger med arbeidsbelastningen i stedet for å bli gjennomført i hver silo. I praksis avhenger dette av tre byggeklosser:

• En forent kontrollplane

En plass å definere og påtvinge identitet, tilgang, politikk, kataloger og berettigelse over skyer og datasentre.

Målet er å skrive politikker én gang og påtvinge dem hvor data og modeller kjører, i stedet for å bygge kontrollsystemer system for system. Dette forhindrer atferdsglede hos agenter, hvor samme agent oppfører seg trygt i ett miljø, men farlig i et annet.

En praktisk test er enkel: hvis en bruker ikke kan få tilgang til en kolonne, verifiser at en agent som handler på deres vegne heller ikke kan få tilgang til den. Dette bør indikere om skrevne politikker påtvinges over hele planet.

• En datafabrikk basert på åpne standarder

Agenter trenger kontekst for å fungere. Når denne konteksten er spredt over forskjellige strukturer eid av forskjellige team, hjelper en datafabrikk med å standardisere semantikk og tilgangsmønster, så agenter ikke må lære en ny sett med regler for hver datasett.

Åpne tabellformater som Apache Iceberg støtter dette ved å tillate flere motorer å dele samme styrt data uten å kopiere det inn i en ny silo. Dette er viktig fordi dataduplisering er der styring vanligvis feiler. Når team starter å kopiere “bare det agenten trenger”, har du skapt et nytt, mindre styrt miljø.

Hvis agenter kan fungere over datasett uten å innføre nye tillgangshull, fungerer styring som det skal.

• Sanntids overvåkbarhet og avstamning

Agenter er bare styrbare hvis du kan se hva de gjør på kjøretid.

Overvåkbarhet her er ikke bare et “nice-to-have”, men er grunnlaget for kjøretidskontroller og hendelsesrespons.

Spesifikt må det være end-to-end bevis for agenthandling. Agenter bør kunne bevise handlinger, som hvilke data som ble aksessert og hvilke verktøy som ble ringt, og derfra kan avstamning koble utdata tilbake til inndata. Dette tillater team å granske disse beslutningene og feilsøke feil, hvis nødvendig, og dermed bevise overholdelse.

Behandle agenter som “digitale kolleger”

En av de mest nyttige mentale modellene er å behandle agenter som digitale kolleger.

Her er en sammenligning som bryter dette ned: like som ansatte har tilgangsbrikker som gir adgang til noen bygninger og rom, men ikke andre, tillater styring agenter å ha tilgang med begrensninger. En nøkkeltillegg er at agenter må være situasjonsbevisste på hva de er tillatt å avsløre.

Vurdér en støtteagent. Den må kanskje aksessere tidligere støttesaker for å løse et problem, men den kan ikke lekke en annen kundes private detaljer mens den gjør det. Annet sagt, agenten kan bruke begrensede kunnskaper til å granske, men må likevel påtvinge avsløringsgrenser. Dette er ikke et “prompt-skriveri”-problem som vi historisk har visst hvordan vi skal navigere; i stedet er det et identitets- og kjøretidsenføringsproblem.

Hva endrer seg i 2026: agenter flytter fra eksperimenter til produksjon

2026 er året når eksperimenter slutter, og agenter tar produksjonssetet.

Dette skiftet tvinger bedrifter til å operere med to hastigheter. En er innovasjonshastighet, hvor team tester nye modeller, verktøy og agentarbeidsflyter for å få en konkurransefordel. Og den andre er sikkerhastighet, hvor systemer må møte overholdelses- og operative krav, som kan inkludere streng tilgangskontroll og blindsoner.

Uten en arkitektonisk styring, vil disse to hastighetene komme i konflikt.

Hvis team deployerer disse agentene før de er styrt, vil det bli en lappeteppa av enkeltkontroller og operative feil. Og hvis det motsatte skjer, får du en feilmodus hvor sikkerhet blokkerer alt, og innovasjon flytter til skygge-IT, som undergraver styring.

Målet er ikke å velge en hastighet. Det er å bygge en arkitektur som støtter begge.

En praktisk sjekkeliste for å styre agenter på kjøretid

• Hvis du bygger eller skalerer agenter, er det avgjørende å spørre deg selv følgende spørsmål for å avsløre om styring virkelig er arkitektonisk: Kan du forklare, fra ende til ende, hva data en agent aksesserte for å produsere et svar eller utføre en handling?
• Er tilgangsbeslutninger konsistente over hybridmiljøer, eller forskjeller de seg etter plattform?
• Har du telemetri for agenthandling, inkludert verktøykall, politikk kontroller og menneskelig eskalering?
• Kan du bremses, pause eller karantene en agent på kjøretid hvis den oppfører seg uventet?
• Har du en plan for overvåking etter deploy som samsvare med dine regulatoriske forpliktelser og risikoappetitt?

Hvis du ikke kan svare på disse, behandl agent-deployeringen som en produksjons hendelse som venter på å skje.

Styringsskiftet må være arkitektonisk, eller det eksisterer ikke

Agenter vil bli en standardtillegg til bedriftsoperasjoner. Spørsmålet er om de vil bli en pålitelig del av bedriftsoperasjoner.

Hvis agenter ikke styres like trygt som mennesker og kritiske programvare, vil konsekvensene være reelle. Vi vil se disse konsekvensene i datalækasje, overholdelsesfeil, operative nedtider og tap av tillit til AI-programmer.

Lederne må slutte å behandle agentstyring som en dokumenteringsøvelse. Ettersom plattformkapasiteter utvides, bør agentstyring være en av dem som tar på seg tilsyn over andre roller. Dette betyr å innbygge kontroller i kontrollplanet, gjøre handlinger overvåkbare og beslutninger granskbare. Og deretter skalerer.

Dette er hvordan du får agenter som flytter raskt uten å bryte bedriften.