Nesten halvparten av AI-agentene i produksjon er usikret

Nøkkelpunkter per 15. september 2026:

• 48 prosent av AI-agentene i produksjon kjører uten sikkerhet, mens 54 prosent av organisasjonene allerede har hatt en sikkerhetshendelse (gravitee.io, 2026).
• Nesten ingen har en navngitt person med formelt ansvar for hvordan AI-agentene oppfører seg, selv om det store flertallet planlegger å rulle ut flere agenter (gravitee.io, 2026).
• En styringsbaseline definerer minimumskravene hver agent må oppfylle før den får operere: observerbar, styrt og sikret (Microsoft).
• Agentflåtene doblet seg på fire måneder, fra rundt 37 agenter i snitt i desember 2025 til 38 prosent av virksomhetene med over hundre agenter (gravitee.io, 2026).
• Reguleringen er ustabil: av over 1000 kartlagte styringsdokumenter er 44 prosent av hard law-dokumentene vedtatt og 43 prosent bortfalt (airisk.mit.edu, 2026).

---

Hva en AI-agent er, og hvorfor den er et sikkerhetsobjekt

En AI-agent er ikke en chatbot med bedre språk. Agenter er programvaresystemer som kan få tilgang til data, ta beslutninger og utføre handlinger på tvers av forretningssystemer (Microsoft). Tre egenskaper, og det er den siste som flytter risikoen. En modell som tar feil, skriver en dårlig setning. En agent som tar feil, sender fakturaen, oppdaterer kunderegisteret eller lukker saken.

Derfor er styring av AI-agenter ikke først og fremst et AI-tema. Det er et tilgangsstyringstema, et driftstema og et ansvarstema som tilfeldigvis har en språkmodell i midten. Når du skal avgjøre om en agent får gå i produksjon, er spørsmålet ikke hvor god modellen er. Spørsmålet er hva agenten kan gjøre når den tar feil, hvem som ser det skje, og hvem som svarer for det etterpå.

Tilgang, beslutning og handling

De tre egenskapene bør leses som tre separate tillatelser, ikke som en pakke. Tilgang handler om hvilke data agenten kan lese, og om den leser mer enn personen den jobber på vegne av. Beslutning handler om hvor stort tolkningsrommet er før den velger handling. Handling handler om hva den kan endre i systemer der endringen har en konsekvens utenfor agenten selv.

Skillet er praktisk nyttig fordi det gir deg tre steder å bremse. Du kan gi bred lesetilgang og null skrivetilgang. Du kan la agenten foreslå en handling og kreve at et menneske utløser den. Du kan la den handle fritt i et system og aldri i et annet. De fleste dårlige agentoppsett kollapser disse tre til en enkelt ja-eller-nei-beslutning, og da blir svaret som regel ja.

Forskjellen på en assistent og en aktør

En assistent produserer et utkast som et menneske vurderer. En aktør utfører noe i et system uten at noen nødvendigvis ser mellomstegene. Overgangen mellom de to skjer sjelden som en formell beslutning. Den skjer når noen kobler et verktøy til en velfungerende assistent for å spare noen minutter, og ingen registrerer at systemets rolle nettopp endret seg.

Det er dette skiftet virksomheter bør fange opp i en gate. Når en assistent får sitt første skrivende verktøy, er den ikke lenger samme objekt. Den må da vurderes som en ny aktør i systemlandskapet, med egen identitet, egne rettigheter og et eget spor i loggen. Selvforbedrende oppsett gjør skillet enda viktigere, fordi agentens atferd kan endre seg uten at noen har endret koden (pålitelighet før hastighet).

Hvorfor agenten hører hjemme i risikoregisteret

Et sikkerhetsobjekt er noe som har en identitet, noen rettigheter, en eier og en logg. Målt mot den definisjonen er en agent i produksjon nærmere en integrasjonsbruker enn et verktøy. Den logger på, den henter data, den utfører kall, og den kan misbrukes eller kapres. Alle agenter må oppfylle alle baseline sikkerhetskrav før de settes i drift (Microsoft).

I praksis betyr det at agentene skal stå i samme oversikt som andre systemer med tilgang til produksjonsdata. Hvis en agent ikke finnes i noe register, finnes den heller ikke i noen risikovurdering, og da finnes den heller ikke i noen beredskapsplan. Det er den billigste feilen å rette og den dyreste å ignorere.

Tallene bak risikoen

Gravitee spurte 750 senior teknologiledere i Storbritannia og USA i april 2026 om hvordan de faktisk sikrer AI-agenter (gravitee.io, 2026). Hovedfunnet er ubehagelig konkret: 48 prosent av AI-agentene i produksjon kjører uten sikkerhet. Ikke i pilot, ikke i sandkasse, men i drift.

Det andre tallet er mer alvorlig enn det første, fordi det ikke handler om risiko lenger. 54 prosent av organisasjonene har allerede hatt en sikkerhetshendelse knyttet til AI-agenter, og en stor del av dem bekrefter hendelsen uttrykkelig. Hendelsene er ikke et framtidsscenario som skal modelleres. De er allerede en historisk hendelsesrate.

Måltall	Andel	Hva det forteller deg
AI-agenter i produksjon uten sikkerhet	48 prosent	Store deler av flåten står uten kontroller
Organisasjoner med sikkerhetshendelse	54 prosent	Risikoen er allerede realisert
Gjennomsnittlig overvåkingsdekning	52 prosent	Mye av atferden er ikke synlig
Alle agenter fullt sikret før produksjon	Et lite mindretall	Gaten finnes sjelden i praksis
Sikrer mer enn 81 prosent av agentene	Svært få	Nesten ingen har full dekning
Navngitt ansvarlig for agentatferd	Nesten ingen	Eierskapet er nesten fraværende
Planlegger flere agenter neste 12 måneder	Det store flertallet	Gapet vil vokse, ikke krympe

Overvåkingsdekningen er det underliggende problemet

Gjennomsnittlig overvåkingsdekning ligger på 52 prosent (gravitee.io, 2026). Det betyr at en betydelig del av det agentene gjør, ikke er synlig for noen i ettertid. Det er en vanskelig posisjon å håndtere en hendelse fra, fordi du verken kan avgrense omfanget eller dokumentere hva som faktisk skjedde.

Manglende observerbarhet er også grunnen til at hendelsestallene sannsynligvis er et gulv, ikke et tak. En organisasjon som ikke logger agentkall, kan ikke rapportere hendelser den aldri oppdaget. Når full innsikt er unntaket snarere enn regelen, bør du lese hendelsesraten som «minst dette», ikke som «omtrent dette».

Sikret før produksjon er sjeldnere enn det høres ut

Bare et lite mindretall sier at alle agentene er fullt sikret før produksjon, mens klart flere sier at de fleste agentene er sikret. Avstanden mellom «alle» og «de fleste» er hele poenget. En baseline som gjelder for de fleste agenter, er ikke en baseline. Det er en preferanse, og preferanser taper mot leveransefrister.

Svært få sikrer mer enn 81 prosent av agentene sine. Kombinert med at det store flertallet planlegger å rulle ut flere agenter det neste året, betyr det at dekningsgraden faller videre med mindre gaten strammes nå. Volum uten gate gir alltid lavere andel sikret, uansett hvor dyktig sikkerhetsteamet er.

Sektorforskjellene er store

Hendelsesraten er ikke jevnt fordelt. Telekomsektoren ligger klart over snittet (gravitee.io, 2026). Sektorer med mange systemintegrasjoner, høyt kundevolum og sterk automatiseringskultur får flere agenter raskere, og dermed flere flater å bomme på.

For norske virksomheter er dette mindre et spørsmål om bransjeetikett enn om integrasjonsdybde. Hvis agentene dine snakker med CRM, ERP, e-post og fakturering samtidig, ligner risikoprofilen din på de tunge sektorene uansett hva som står i bransjeregisteret. Antall agenter per bedrift har allerede begynt å endre hvordan kundedata beveger seg (agenter i CRM).

---

Les også: Sikkerhet i AI-agenter svikter i 73 prosent av utrullingene. 73 prosent av AI-utrullinger har minst én kritisk sårbarhet, og bare 12 prosent tester systematisk.

---

Styringsbaselinen: minimumskravene før en agent får operere

Det praktiske svaret på tallene over er en baseline. En styrings- og sikkerhetsbaseline definerer minimumskravene som hver agent må oppfylle før den får operere (Microsoft). Poenget er ikke å lage et nytt policydokument. Poenget er å ha en liste som kan gi svaret nei.

Alura mener at ingen agent bør i produksjon før den er observerbar, styrt og sikret, og før en navngitt person eier atferden dens. Det er fire krav som kan verifiseres på under en time per agent, og de fanger opp de fleste feilene som blir dyre senere.

Baselinekrav	Hva det betyr konkret	Gate-spørsmål før produksjon
Observerbar	Kall, verktøybruk og utfall logges og kan gjenfinnes	Kan vi rekonstruere hva agenten gjorde i går?
Styrt	Scope, rettigheter og grenser er skrevet ned	Finnes det en liste over hva den ikke får gjøre?
Sikret	Egen identitet, minste privilegium, hemmeligheter i hvelv	Har agenten sin egen identitet, ikke en delt konto?
Etterlevende	Agenten overholder regelverk og interne standarder	Hvilke data berører den, og har vi grunnlag?
Godkjent stack	Kun godkjente rammeverk og protokoller	Er rammeverket på listen, eller er det et unntak?
Eid	Navngitt person ansvarlig for atferd	Hvem ringer vi klokken 23 hvis den går feil?

Observerbarhet er en forutsetning, ikke en funksjon

Hver agent må være observerbar, styrt og sikret (Microsoft). Rekkefølgen er ikke tilfeldig. Uten observerbarhet kan du verken verifisere at styringen virker eller oppdage at sikringen har sviktet. Logging er infrastrukturen de to andre kravene hviler på.

Minimum er at du kan svare på fire ting i ettertid: hvilken agent, på vegne av hvem, hvilke verktøy, og med hvilket utfall. Det holder ikke å logge promptene. Verktøykallene er der handlingene skjer, og det er handlingene som skaper konsekvens. En logg uten verktøykall dokumenterer samtalen, ikke hendelsen.

Ansvarlig AI som policygrunnlag

Ansvarlig AI-policyer definerer akseptabel bruk av AI og etablerer forventninger til rettferdighet, åpenhet og ansvarlighet (Microsoft). For en SMB trenger ikke dette å bli langt. Det trenger å bli operativt.

Test policyen slik: kan en produktansvarlig bruke den til å avvise et konkret agentforslag på en tirsdag? Hvis svaret er nei, er dokumentet en intensjonserklæring. Det som gjør policyen operativ, er som regel noen få forbudte bruksområder, noen få datakategorier med ekstra krav, og et krav om menneskelig godkjenning for handlinger som ikke kan rulles tilbake.

Baselinen må virke som gate, ikke som anbefaling

Forskjellen på en baseline og en huskeliste er at baselinen har makt til å stoppe en lansering. Det krever at noen faktisk kan si nei, og at det nei-et ikke kan overstyres i en chattetråd. I praksis betyr det et sted i utrullingsprosessen der kravene sjekkes, og et spor som viser hvem som godkjente.

Unntak er greit, men de må ha utløpsdato og en navngitt godkjenner. Et unntak uten dato er ikke et unntak. Det er en ny standard som ingen har vedtatt. Alle agenter må overholde regelverk og standarder, og unntaksregimet er der de fleste virksomheter mister den oversikten (Microsoft).

Scope og guardrails: hva agenten faktisk har lov til å gjøre

Scope er den korteste veien til lavere risiko, og den billigste. En agent som ikke har tilgang til et system, kan ikke gjøre skade i det systemet, uansett hvor kreativt den blir manipulert. Alura mener at scope og guardrails må defineres før skalering, ikke etter at flåten har doblet seg. Det er langt lettere å stramme inn en agent enn femti.

Handlingsnivå	Eksempel	Krav før produksjon
Kun lesing	Oppsummerer saker, søker i dokumenter	Datatilgang avgrenset, logging på
Foreslår handling	Skriver utkast til svar eller ordre	Menneskelig utløsning, ingen skriverettigheter
Reversibel handling	Oppretter utkast, flytter sak, setter tag	Egen identitet, angrefunksjon, varsling
Irreversibel handling	Sender e-post ut, utbetaler, sletter, endrer pris	Godkjenning fra menneske, beløpstak, kill switch

Skriv scope som en negativ liste

De fleste scope-dokumenter beskriver hva agenten skal gjøre. Det er nyttig for produktarbeidet og nesten verdiløst for sikkerheten. Den operative listen er den negative: systemer agenten aldri får skrive til, datakategorier den aldri får lese, og handlinger som alltid krever et menneske.

Den negative listen har en praktisk fordel. Den er kort, den er testbar, og den overlever at produktet endrer seg. Når noen foreslår en ny funksjon, ser du umiddelbart om den bryter en grense eller bare utvider en oppgave.

Guardrails i lag, ikke i prompt

Instruksjoner i systemprompten er den svakeste formen for guardrail, fordi den kan påvirkes av innholdet agenten leser. Legg de harde grensene der de ikke kan overtales: i rettighetsmodellen, i API-laget og i verktøydefinisjonene. Prompten skal forklare intensjon, ikke håndheve grenser.

Et fungerende oppsett har minst tre lag. Rettigheter avgjør hva som teknisk er mulig. Policyer i integrasjonslaget avgjør hva som slipper gjennom av kall, beløp og volum. Menneskelig godkjenning avgjør det som ikke kan rulles tilbake. Kjente sårbarhetsmønstre i agentoppsett rammer nesten alltid virksomheter som bare har det første laget (kritiske sårbarheter).

Kill switch og degradert modus

Hver agent trenger en måte å bli stoppet på som ikke krever en utvikler. Det kan være et flagg, en deaktivert tilgang eller en bryter i et adminpanel, men det må være dokumentert og testet. En kill switch som aldri er prøvd, er en antakelse.

Degradert modus er det som gjør kill switch politisk mulig. Hvis alternativet til en fungerende agent er full stans i prosessen, vil ingen trekke i bryteren. Definer på forhånd hva som skjer når agenten slås av: køen går til mennesker, saker merkes, eller funksjonen faller tilbake til forrige løsning.

Eierskap og ansvar: den navngitte personen nesten ingen har

Nesten ingen organisasjoner har en navngitt person med formelt ansvar for AI-agentatferd (gravitee.io, 2026). Det er det mest handlingsbare funnet i hele undersøkelsen, fordi det er det eneste du kan endre på et ledermøte uten budsjett, prosjekt eller leverandør.

Eierskap er ikke det samme som skyld. Det er et navn som svarer på tre spørsmål: hva agenten har lov til, om den fortsatt oppfyller baselinen, og hvem som stopper den. Uten et navn fordeles alle tre spørsmålene på en gruppe, og grupper svarer sent.

Hvorfor «teamet eier det» ikke er eierskap

Når en agent oppfører seg feil, oppstår spørsmålene i rask rekkefølge: er dette en feil eller en tillatt handling, skal vi stoppe den, hvem varsler kunden, hvem sjekker loggen. Et team kan utføre alle oppgavene, men det kan ikke ta beslutningen om å stoppe noe som gir omsetning. Den beslutningen trenger en person med mandat.

Rolle	Eier	Beslutningen de faktisk tar
Agenteier (navngitt)	Agentens atferd i produksjon	Stopper eller godkjenner agenten
Produktansvarlig	Formål og scope	Hva agenten skal og ikke skal gjøre
Teknisk ansvarlig	Identitet, logging, rettigheter	Om baselinekravene er oppfylt teknisk
Sikkerhets- eller compliance-ansvarlig	Regelverk og datagrunnlag	Om agenten kan behandle disse dataene
Ledelse	Risikoappetitt	Godkjenner unntak, med utløpsdato

Hva agenteieren skal svare for

Eieren skal kunne svare på fire ting uten forberedelse: hva agenten gjør, hvilke systemer den skriver til, når den sist ble gjennomgått, og hvordan den stoppes. Det er en kort liste med vilje. Hvis eierskapet krever et dokument for å kunne besvares, er det ikke internalisert.

I en SMB er dette som regel produktansvarlig eller den som eier prosessen agenten jobber i, ikke IT-lederen. Den som eier prosessen, vet hva som er en akseptabel feil. IT-lederen vet hva som er teknisk mulig. Begge trengs, men det er prosesseieren som bør stå med navnet.

Fra pilot til produksjon: sjekklisten du kan kjøre mandag morgen

Dette avsnittet er ment å kunne gjennomføres på en uke, uten nye verktøy. Målet er ikke et modent styringsprogram. Målet er at du på fredag kan si hvor mange agenter du har, hva de kan gjøre, og hvem som eier hver av dem.

Lag inventaret først

Start med en enkel liste: navn, formål, hvilke systemer den leser fra, hvilke den skriver til, hvem som bygde den, og om den er i drift. Spør bredt, ikke bare i IT. Agenter oppstår i markedsføring, salg og kundeservice like ofte som i utviklingsteamet, og de er sjelden registrert noe sted.

Forvent at listen blir lengre enn ledelsen tror. Det er normalt: 38 prosent av organisasjonene hadde over hundre agenter i april 2026, opp fra et snitt på rundt 37 agenter i desember 2025 (gravitee.io, 2026). Vekst skjer raskere enn registreringen av den.

Klassifiser etter konsekvens, ikke etter teknologi

Sorter agentene etter hva som skjer hvis de gjør noe galt mange ganger på rad før noen oppdager det. Det er en bedre sorteringsnøkkel enn modellvalg, rammeverk eller antall brukere. En enkel agent som sender e-post til kunder, er farligere enn en avansert agent som oppsummerer interne dokumenter.

Bruk klassifiseringen til å prioritere. De som kan utføre irreversible handlinger mot kunder, penger eller persondata, går først. De som kun leser interne data, kan vente til neste runde. Prioritering er nødvendig fordi ingen SMB har kapasitet til å gjennomgå hele flåten samtidig.

Sett gaten og kjør de første agentene gjennom den

Ta baselinetabellen lenger opp, gjør den til et skjema på en side, og kjør de tre høyest prioriterte agentene gjennom den. Du vil oppdage to ting: at noen krav er trivielle å oppfylle, og at et par agenter ikke burde vært i produksjon. Begge deler er nyttige funn.

Deretter gjør du gaten obligatorisk for alt nytt, fra og med den dagen. Det er langt enklere å innføre en gate for framtidige agenter enn å rydde bakover. Ryddingen gjør du i takt med prioriteringslisten, ikke som en stor opprydningsleveranse som konkurrerer med kundeprosjekter.

Protokoller og standarder: MCP, A2A og sentral godkjenning

Hver agent må kun bruke godkjente rammeverk og protokoller, og to nøkkelprotokoller å ta i bruk er Model Context Protocol (MCP) og Agent-to-Agent Protocol (A2A) (Microsoft). Dette er et styringsgrep forkledd som et teknisk valg. Standardisering er det som gjør at kontroller kan innføres ett sted og virke overalt.

Alura mener at du bør standardisere på godkjente protokoller som MCP og A2A framfor å la hvert team finne opp sin egen integrasjonsmåte. Ikke fordi protokollene i seg selv er sikre, men fordi antall ulike integrasjonsmønstre er den variabelen som avgjør hvor dyrt det blir å sikre flåten senere.

Hva standardisering faktisk kjøper deg

Med en felles protokoll får du ett sted å logge verktøykall, ett sted å håndheve rettigheter, og ett sted å skru av en integrasjon. Med fem egenbygde integrasjonsmønstre får du fem steder, hvorav minst ett er udokumentert og bygget av noen som har sluttet. Kostnaden ved fragmentering betales ikke ved utrulling. Den betales ved første hendelse.

Sentral godkjenning betyr ikke sentral bygging. Teamene kan gjerne bygge sine egne agenter, så lenge de bygger dem på en godkjent liste over rammeverk, protokoller og modelltilbydere. Listen bør være kort, offentlig internt, og ha en tydelig prosess for å foreslå tillegg.

Hva du bør kreve av en MCP-server før den godkjennes

En MCP-server er en tilgangsvei inn i systemene dine, og bør vurderes som det. Krev at den har egen identitet mot baksystemet, at verktøyene den eksponerer er dokumentert med hvilke skriveoperasjoner de kan utføre, og at kall logges med nok kontekst til å kunne spores til en bruker og en agent.

Vær spesielt oppmerksom på servere som eksponerer generiske verktøy, for eksempel «kjør spørring» eller «kall dette endepunktet». De flytter effektivt hele rettighetsmodellen inn i agentens vurderingsevne. Det er sjelden et bevisst valg, og enda sjeldnere et dokumentert et. Markedet beveger seg mot ferdig sikrede agentmiljøer nettopp fordi dette arbeidet er tungt å gjøre selv (sikre agentmiljøer).

---

Les også: Sikre AI-agenter rykker nærmere SMB-bruk etter Ona-oppkjøp. OpenAI kjøper Ona for å gi AI-agenter sikre, vedvarende miljøer.

---

Sikkerhetsgjelden vokser når flåten dobles

AI-agentflåtene har omtrent doblet seg siden desember 2025, mens sikkerhetsdekningen knapt har endret seg (gravitee.io, 2026). Det er en dynamikk du kan regne på. Når teller vokser og nevner står stille, faller andelen sikret uten at noen har tatt en beslutning om at den skal falle.

Doblingen skjer på fire måneder, ikke på fire år

Tidsrommet er det som gjør dette til et styringsproblem. Fire måneder er kortere enn de fleste årshjul for risikovurdering, kortere enn mange internrevisjonssykluser, og betydelig kortere enn tiden det tar å innføre et nytt kontrollrammeverk. Styringen taper ikke fordi den er feil. Den taper fordi den går saktere enn utrullingen.

Retningen er heller ikke i tvil. Det store flertallet planlegger å utplassere flere agenter de neste 12 månedene, og en gjennomsnittlig Fortune 500-virksomhet forventes å ha rundt 150 000 agenter innen 2028 (gravitee.io, 2026). Tall i den størrelsesorden er ikke relevante for en norsk SMB direkte, men de forteller hvilken retning verktøyene og leverandørene bygges for.

Gjelden er tempo minus gate

Sikkerhetsgjeld oppstår i differansen mellom hvor raskt agenter settes i drift og hvor raskt de gjennomgås. Hvis du setter i drift fire agenter i måneden og gjennomgår en, bygger du gjeld med tre i måneden, uansett hvor god gjennomgangen er. Dette er en kapasitetsligning, ikke en holdningsligning.

Det gir to reelle knapper: bremse utrullingstakten, eller gjøre gjennomgangen billigere. Den andre er nesten alltid den riktige. En gate på en side som tar tjue minutter, skalerer. En sikkerhetsgjennomgang på tre uker gjør det ikke, og vil bli omgått av folk som har frister å holde.

Regulering og etterlevelse: hva styringsdokumentene faktisk dekker

MIT AI Risk Initiative har klassifisert over 1000 AI-styringsdokumenter fra AGORA-datasettet med en LLM-basert pipeline (airisk.mit.edu, 2026). Bildet som kommer ut, er nyttig for planlegging: styringslandskapet er stort, bredt formulert og ujevnt dekkende.

Dokumentene fokuserer mest på modellsikkerhetsrisikoer og mindre på sosioøkonomiske risikoer, og dekningen er ujevn på tvers av sektorer og livssyklusstadier. Rammeverkene er dessuten ofte brede og retter seg mot AI-systemer og AI-modeller generelt, ikke mot agenter som utfører handlinger i dine systemer.

Hard law er i bevegelse, og mye av den forsvinner

Status for hard law-dokumenter	Andel	Konsekvens for planlegging
Vedtatt	44 prosent	Dette er det som faktisk er gjeldende rett
Bortfalt	43 prosent	Nesten like mye har falt bort underveis
Fortsatt foreslått	12 prosent	Liten andel venter på behandling

Fordelingen forklarer hvorfor det er dårlig strategi å vente på klarhet. Rundt like mye hard law har falt bort som er vedtatt (airisk.mit.edu, 2026). Et regelverk du planlegger etterlevelse mot i dag, kan forsvinne før du er ferdig med prosjektet.

Hullene ligger der agentene dine opererer

Taksonomien MIT bruker, dekker 24 underdomener, 14 sektorer og fire ulike roller i styringsprosessen, og over 500 dokumenter retter seg mot AI Deployers og AI Developers. Nesten 80 prosent av dokumentene nevner nedstrømsstadier, altså fasene etter at systemet er bygget. Likevel konkluderer analysen med potensielle hull i styringsdekningen.

For deg som tar i bruk agenter framfor å bygge modeller, betyr det at du trolig er i en rolle mange dokumenter adresserer, men på et detaljnivå som ikke gir deg konkrete krav. Du får prinsipper. Du får ikke en sjekkliste. Den må du skrive selv, og den blir raskere å skrive enn å vente på.

Sett en intern baseline før reglene lander

Alura mener at du ikke skal vente på at reguleringen definerer kravene for deg. Sett en intern baseline nå, og juster den når reglene lander. En intern baseline har den fordelen at den kan skrives på et nivå som passer din risiko, og strammes senere uten at noe må bygges om fra bunnen.

Det er dessuten et rimelig sannsynlig utfall at de første kravene som treffer deg i praksis, kommer fra en kunde eller en anskaffelse, ikke fra en lovtekst. Store innkjøpere begynner å spørre om agentstyring i leverandørvurderinger. Da er en dokumentert baseline en salgsfordel, ikke bare en kostnad. For agenter som handler på vegne av enkeltpersoner, er definisjonsarbeidet fortsatt uavklart (AI Act og agenter).

Markedsobservasjon: presset på rask utrulling

81 prosent føler press på å utplassere AI-agenter raskt, selv uten full sikkerhet (gravitee.io, 2026). Det tallet forklarer de andre tallene. Manglende sikring er sjelden et resultat av uvitenhet i teknologiledelsen. Det er et resultat av prioritering under tidspress.

Presset er et lederproblem, ikke et teknikerproblem

Når et klart flertall av teknologilederne kjenner press på å levere raskt uten full sikkerhet, er problemet plassert over teamnivå. Utviklere velger sjelden bort logging fordi de synes logging er unødvendig. De velger det bort fordi noen har kommunisert at demoen skal være klar til styremøtet.

Løsningen er tilsvarende plassert. Ledelsen må gjøre baselinen til en del av ferdig-definisjonen, på samme måte som at et produkt ikke er ferdig før det er testet. Uten en eksplisitt ferdig-definisjon vinner fristen hver gang, og resultatet blir en flåte der mange agenter kjører uten kontroller.

Beredskap for agenter som egne brukere

De aller fleste sier de er minst noe forberedt på å håndtere agenter som egne brukere, men bare et mindretall er svært forberedt (gravitee.io, 2026). Gapet mellom «noe» og «svært» er der de reelle kostnadene ligger: identitetshåndtering, livssyklus, tilbaketrekking av tilgang og revisjon.

Praktisk sett betyr «agent som egen bruker» at agenten opprettes, får rettigheter, gjennomgås og deaktiveres som en ansatt. De fleste virksomheter har allerede prosesser for dette for mennesker. Den raskeste veien videre er å gjenbruke dem, ikke å bygge et parallelt regime for AI.

Vanlige feil norske virksomheter gjør når de skalerer AI-agenter

Feilene under går igjen på tvers av bransjer og størrelser. Ingen av dem skyldes mangel på kompetanse. De skyldes at agenter blir tatt i bruk raskere enn de blir registrert, og at ingen eier beslutningen om å stoppe noe som virker.

Pilotunntaket som aldri utløper

En agent settes opp «bare som pilot», og får derfor lettere krav: ingen egen identitet, begrenset logging, ingen formell eier. Seks måneder senere står den i en forretningskritisk prosess, fortsatt med pilotoppsettet. Ingen tok en beslutning om å sette den i produksjon. Den gled inn.

Botemiddelet er billig: gi hver pilot en utløpsdato ved oppstart. Når datoen passerer, går agenten enten gjennom gaten eller av. Det tvinger fram en beslutning, og det er beslutningen, ikke teknologien, som mangler i de fleste tilfeller.

Delte tjenestekontoer og lånte rettigheter

Agenten kjører på en eksisterende integrasjonsbruker eller, verre, på tokenet til en ansatt med brede rettigheter. Det gir to problemer samtidig: agenten får mer tilgang enn den trenger, og loggene kan ikke skille agentens handlinger fra menneskets.

Egen identitet per agent er det enkeltgrepet som gir mest sikkerhet per arbeidstime. Det gjør minste privilegium mulig, det gjør sporing mulig, og det gjør at du kan trekke tilbake tilgangen til en enkelt agent uten å bryte noe annet.

Logging som ingen leser

Mange virksomheter logger mer enn de tror, og ser mindre enn de tror. Loggene finnes i verktøyet, men ingen har definert hva som er unormalt, og ingen har ansvar for å se etter. Da er logging kun nyttig etter at noe har gått galt, og bare hvis noen vet hvor de skal lete.

Start med et par enkle terskler per agent: uventet volum, kall mot systemer den normalt ikke rører, og feilrate over et nivå. Det trenger ikke være avansert deteksjon. Det trenger å være noe som sender et varsel til den navngitte eieren.

Hvert team med sin egen integrasjonsmåte

Tre team bygger tre agenter med tre ulike rammeverk, tre måter å håndtere hemmeligheter på, og tre loggformater. Hver av dem er forsvarlig isolert sett. Samlet gir de en flåte som ikke kan styres med en kontroll, og en kostnad som vokser lineært med antall agenter.

Dette er den feilen som er dyrest å rette i ettertid, og enklest å hindre på forhånd. En kort liste over godkjente rammeverk og protokoller, vedtatt før agent nummer fem, sparer et helt migrasjonsprosjekt senere.

Spørsmål og svar om styring og sikring av AI-agenter

Spørsmålene under er de som oftest kommer fra ledere og produktansvarlige som skal ta beslutningen om en konkret agent, ikke bygge et program.

Må hver agent virkelig ha sin egen identitet?

Ja, hvis den kan skrive til et system. Uten egen identitet kan du verken gi minste privilegium, spore handlinger eller trekke tilbake tilgang uten bivirkninger. For rene leseagenter mot interne dokumenter kan kravet være lettere, men skillet bør være eksplisitt og dokumentert, ikke praktisk betinget.

Hvor mye overvåking er nok?

Nok er når du kan rekonstruere en hendelse i ettertid og oppdage den mens den pågår. Snittet i markedet ligger på 52 prosent overvåkingsdekning, og det er ikke et nivå å sikte mot (gravitee.io, 2026). Prioriter full dekning på agenter som utfører irreversible handlinger, og aksepter lavere dekning der konsekvensen er begrenset.

Hvem bør eie agentens atferd i en SMB uten eget sikkerhetsteam?

Prosesseieren, med teknisk støtte. Den som eier kundeservice, bør eie kundeserviceagenten. Vedkommende trenger ikke kunne konfigurere rettighetene selv, men skal kunne svare på hva agenten gjør, når den sist ble gjennomgått, og hvordan den stoppes. I en liten organisasjon er dette som regel en person som allerede sitter i ledergruppen.

Bør vi vente på at reguleringen blir tydeligere?

Nei. Bare et mindretall mener dagens regulering er tilstrekkelig for AI-agentrisiko (gravitee.io, 2026), og styringslandskapet er i bevegelse, med en betydelig andel hard law som faller bort underveis (airisk.mit.edu, 2026). En intern baseline kan justeres. En utsatt beslutning kan ikke tas igjen etter en hendelse.

Hva gjør vi med agentene som allerede står i produksjon usikret?

Prioriter etter konsekvens, ikke etter alder. Ta de som kan utføre irreversible handlinger mot kunder, penger eller persondata først. Gi hver av dem en eier og en logg innen kort tid, og stram scope der det er billigst. Resten kan tas i takt, så lenge gaten hindrer at bunken vokser videre.

Oppsummering og neste steg før neste agent settes i drift

Tallene i denne artikkelen peker alle samme vei. Agentene blir flere raskere enn de blir styrt, hendelsene har allerede skjedd hos flertallet av organisasjonene, og eierskapet mangler nesten overalt. Ingen av disse problemene krever ny teknologi for å løses. De krever en liste, en gate og et navn.

Det som skiller virksomhetene som håndterer dette godt, er ikke størrelsen på sikkerhetsbudsjettet. Det er om baselinen er streng nok til å gi nei som svar, og lett nok til at ingen forsøker å gå rundt den.

Beslutningene som bør tas denne uken

Skriv inventaret over agentene dine og finn ut hvilke som kan skrive til produksjonssystemer. Gi hver av dem en navngitt eier, ikke et team. Gjør baselinen til en obligatorisk gate for alt nytt fra og med i dag, med unntak som har utløpsdato og godkjenner. Vedta en kort liste over godkjente rammeverk og protokoller før flåten vokser videre.

Deretter måler du en ting hver måned: andelen agenter i produksjon som oppfyller baselinen. Det er det eneste nøkkeltallet som fanger opp både utrullingstakt og styringskapasitet i samme linje. Hvis den andelen faller, skalerer du raskere enn du styrer, og da er det utrullingstakten som må justeres, ikke ambisjonen.

I Alura kombinerer vi teknisk AI-kompetanse med praktisk forståelse for GDPR, EU AI Act og Datatilsynets forventninger. Vi hjelper norske virksomheter å bygge AI som tåler en revisjon, uten å bremse innovasjonen.

Bestill en compliance-vurdering: vi kartlegger dine AI-systemer mot gjeldende og kommende krav, og leverer en handlingsplan som faktisk er gjennomførbar. Uforpliktende.

Kilder

• gravitee.io (2026). State of AI Agent Security Report 2026
• Microsoft. Govern and secure AI agents - Microsoft Learn
• airisk.mit.edu (2026). Mapping the AI Governance Landscape: April 2026 Update