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 overvakning kan komme raskt, og forvandle seg 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 policydokumenter. 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 handle som digitale kolleger, må de arve de samme bedriftssikkerhetsskranker som mennesker, pluss sterkere kjøretidstilsyn.

Hvorfor styring feiler i konvergensæraen

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 parallelle systemer fordi de har flere prosesser å håndtere samtidig. Dette inkluderer separate identitetssystemer, loggpiper, kataloger og godkjente prosesser. Resultatet er hva noen kaller en “Frankenstein-plattform”, hvor integrasjonsoverhodet øker med hver nytt verktøy eller sky-miljø. Faktisk viser denne fragmenteringen seg i hverdagsrealiteten.

Ifølge en nylig undersøkelse, angir 47% av respondentene kompliserte tilgangskrav og prosesser, og 44% angir 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 kanskje hente data fra et lokale ERP-system, en sky-basert CRM, operasjonell telemetri i en annen sky og dokumenter i et samarbeidsverktøy. Hvis organisasjonen pålegger policy 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å merke til. Agenter tvinger en høyere standard som krever konsistens over miljøer og ansvar på kjøretid.

Styring, av denne grunn, trekkes 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 operasjonelle ansvar, ikke en gangs sjekklister.

Fra policy 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 samlet kontrollplane

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

Målet er å skrive policyer en gang og påtvinge dem hvor data og modeller kjører, i stedet for å bygge kontrollsystemer system for system. Dette forhindrer agent-atferd-glede, 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 om en agent som handler på deres vegne ikke kan få tilgang heller. Dette bør indikere om skrevne policyer påtvinges over hele planet.

• En data-duk grundet i åpne standarder

Agenter trenger kontekst for å operere. Når denne konteksten er spredt over forskjellige strukturer eid av forskjellige lag, hjelper en data-duk 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 data-duplisering er der styring vanligvis feiler. Når lag begynner å kopiere “bare det agenten trenger”, har du skapt en ny, mindre styrt miljø.

Hvis agenter kan operere over datasett uten å introdusere nye tillgangsgap, fungerer styring som ønsket.

• Sanntids-observasjon og avstamning

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

Observasjon her er ikke bare et “nice-to-have”, men er grunnlaget for kjøretids-kontroller og hendelses-respons.

Spesifikt må det finnes en slutt-til-slutt-bevis for agent-handlinger. 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 lag å granske disse beslutningene og feilsøke feil, hvis nødvendig, og dermed bevise totalt samsvar.

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 hente tidligere støtte-saker 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; isteden er det et identitet- og kjøretids-påtvingingsproblem.

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 lag tester nye modeller, verktøy og agent-arbeidsflyter for å få en konkurransefordel. Og den andre er den sikre hastighet, hvor systemer må møte samsvar og operasjonelle krav, som kan inkludere streng tilgangskontroll og blinde flekker.

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

Hvis lag deployer disse agentene før de er styrt, vil det være et lappe-teppe av enkelt-kontroller og operasjonelle feil. Og hvis det motsatte skjer, får du en feilmodus hvor sikkerhet blokkerer alt, og innovasjon flytter til skygge-IT, og undergraver styring.

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

En praktisk sjekklister 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 er virkelig 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 hybrid-miljøer, eller forskjeller de seg etter plattform?
• Har du telemetri for agent-handlinger, inkludert verktøy-kall, policy-sjekker og menneskelige eskalasjoner?
• Kan du brems eller karantene en agent på kjøretid hvis den oppfører seg uventet?
• Har du en etter-deployerings-overvåkingsplan som samsvarer med dine regulatoriske forpliktelser og risiko-appetitt?

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

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

Agenter vil bli en standard-tillegg til bedrifts-operasjoner. Spørsmålet er om de vil bli en pålitelig del av bedrifts-operasjoner.

Hvis agenter ikke styres like trygt som mennesker og kritiske programvare, vil konsekvensene være reelle. Vi vil se disse konsekvensene i data-lekkasje, samsvar-feil, operasjonelle nedtider og tap av tillit til AI-programmer.

Ledere må slutte å behandle agent-styring som en dokument-øvelse. Etterhvert som plattform-kapasiteter utvides, bør agent-styring være en av dem som tar på seg tilsyn over andre roller. Dette betyr å innbygge kontroller i kontrollplanet, gjøre handlinger observerbare og beslutninger granskbare. Og deretter skalerer.

Det er hvordan du får agenter som beveger seg raskt uten å bryte bedriften.