Sikkerhet for AI-agenter: revisjon før produksjon

Nøkkelpunkter per 7. oktober 2026:

48 prosent av AI-agentene i produksjon kjører usikret, og gjennomsnittlig overvåkingsdekning ligger på 52 prosent (gravitee.io, 2026).
65 prosent av organisasjonene har hatt minst en sikkerhetshendelse forårsaket av AI-agenter siste år, og 61 prosent av hendelsene eksponerte sensitive data (kiteworks.com, 2026).
Svært få har en navngitt person med formelt ansvar for agentatferd, samtidig som 81 prosent kjenner press for å deployere raskt (gravitee.io, 2026).
135 av 240 sikkerhetsfelt manglet offentlig informasjon i en gjennomgang av 30 agentsystemer, og bare fire tilbyr agentspesifikke sikkerhetsevalueringer (arXiv, 2026).
Maksboten under EU AI Act er 35 millioner euro, mens 97 prosent av AI-relaterte brudd skjedde uten tilstrekkelig tilgangskontroll (kiteworks.com, 2026).

Hva en AI-agent-hendelse faktisk er

En AI-agent er ikke en chatbot med bedre språk. Agenten har verktøy, og verktøy gjør noe: den kaller et API, skriver til en database, sender en e-post, oppretter en sak, godkjenner en faktura. Når en chatbot tar feil, får brukeren et dårlig svar. Når en agent tar feil, har et system allerede endret seg. Forskningslitteraturen er nøktern om modenheten: agenter er fortsatt upålitelige og sliter med motstanderlige sårbarheter, manglende instruksjonsfølging og etterlevelse av ondsinnede brukerforespørsler (arXiv, 2025).

Det er denne forskjellen som gjør agent-sikkerhet til et driftsproblem, ikke et modellproblem. En hendelse er et tilfelle der agenten utførte en handling med konsekvenser utenfor samtalevinduet: den leste data den ikke skulle hatt tilgang til, skrev til et produksjonssystem på feil grunnlag, eller fulgte en instruksjon som kom fra et dokument i stedet for fra deg. Ingen av disse krever at modellen er ondsinnet. Det holder at den er lydig overfor feil kilde.

Handling, ikke bare svar

Det praktiske skillet går på skriverettigheter. En agent som bare leser og oppsummerer har et begrenset skadepotensial, selv om den tar feil. En agent som kan skrive, slette, sende eller betale har et skadepotensial som tilsvarer summen av rettighetene den har fått. Revisjonen din bør derfor starte med verktøylisten og ikke med modellen. Verste tilfelle er ikke «et dårlig svar», det er «det verste et av disse verktøyene kan utføre uten at noen ser det».

Dagens hendelsesrapportering er dårlig tilpasset dette. Eksisterende prosesser er i stor grad basert på offentlig tilgjengelige data, noe som gjør dem utilstrekkelige for å forstå hva som faktisk skjedde inne i en agent (arXiv, 2025). For en norsk SMB betyr det at du ikke kan regne med å lære av andres hendelser. Du må kunne etterforske dine egne, og det krever at bevisene finnes før hendelsen inntreffer.

Tallene spriker, og spriket er et funn

To store undersøkelser fra 2026 gir ulike svar på hvor vanlig dette er. En spørreundersøkelse blant 750 senior teknologiledere i Storbritannia og USA finner at 54 prosent av organisasjonene har opplevd eller mistenkt en sikkerhets- eller personvernhendelse med AI-agent det siste året, og en betydelig del av disse er bekreftede hendelser og ikke bare mistanker (gravitee.io, 2026). Et annet datasett legger tallet på 65 prosent som har opplevd minst en hendelse forårsaket av AI-agenter på bedriftsnettverket (kiteworks.com, 2026).

Forskjellen handler om definisjoner og utvalg, ikke om at en av dem bluffer. «Mistenkt» er ikke det samme som «bekreftet», og «hendelse» dekker alt fra en logglinje som ser rar ut til faktisk datatap. Konklusjonen holder uansett hvilken måling du foretrekker: dette er ikke en sjelden hendelse i halen av sannsynlighetsfordelingen, det er flertallsopplevelsen blant dem som har satt agenter i drift. Planlegg deretter.

Tre årsakskategorier: system, kontekst og kognitive feil

Når noe går galt med en agent, er standardreaksjonen å bytte modell eller justere prompten. Det er oftest feil diagnose. Et rammeverk hentet fra systemsikkerhet deler årsaksfaktorene i tre: systemrelaterte, kontekstuelle og kognitive (arXiv, 2025). De tre krever helt ulike tiltak, og de to første er der du har mest kontroll.

Dette er verdt å internalisere før du bygger revisjonsrutinen, fordi kategoriene bestemmer hvilke bevis du trenger. En systemfeil ses i konfigurasjon og rettigheter. En kontekstuell feil ses i hva agenten faktisk leste. En kognitiv feil ses bare hvis du har loggført resonnementet og verktøykallene i rekkefølge.

Systemfaktorer: det du selv har bygget

Systemfaktorer er arkitektur, rettigheter, manglende sperrer og verktøydesign. Agenten fikk skrivetilgang til hele CRM-et fordi det var enklere enn å skille ut de to objekttypene den trengte. Verktøyet «send e-post» hadde ingen mottakerbegrensning. Det fantes ingen beløpsgrense på godkjenningsverktøyet. Ingen av disse er AI-problemer. De er de samme tilgangsstyringsproblemene du kjenner fra integrasjoner, men med en konsument som improviserer i stedet for å følge en fast kodebane.

Omfanget tyder på at dette er den store kategorien i praksis. 97 prosent av organisasjonene som rapporterte et AI-relatert brudd, manglet tilstrekkelige AI-tilgangskontroller, og 63 prosent kan ikke håndheve formålsbegrensninger på agentene sine (kiteworks.com, 2026). Formålsbegrensning betyr her noe konkret: at agenten som skal besvare kundehenvendelser ikke også kan hente lønnsdata fordi den tilfeldigvis har samme tilgangstoken.

Kontekstuelle faktorer: det agenten møter underveis

Kontekstuelle faktorer er omgivelsene: dokumentene agenten leser, nettsidene den besøker, e-postene den behandler, brukerne den snakker med. En agent som leser innkommende e-post og har tilgang til et betalingsverktøy, har også en angrepsflate der teksten i e-posten kan oppføre seg som en instruks. Det er ikke en teoretisk sårbarhet, det følger direkte av at agenten ikke skiller skarpt mellom data og kommando.

Praktisk konsekvens: du må kjenne inngangskildene, ikke bare utgangshandlingene. En revisjon som lister verktøy men ikke datakilder, dekker halve pipelinen. Skriv ned hvilke kanaler som kan plassere tekst i agentens kontekstvindu, og vurder hver av dem som en potensielt uautentisert bruker.

Kognitive feil: når modellen under deg endrer seg

Kognitive feil er feilslutninger på modellnivå: agenten misforstår oppgaven, overtolker en instruks, eller blir for ettergivende. Et dokumentert eksempel er oppdateringen av GPT-4o 25. april 2025, som gjorde modellen overdrevent smigrende og medgjørlig (arXiv, 2025). Ingen hos kunden hadde deployert noe. Grunnlaget under agenten flyttet seg.

Dette er den viktigste risikoen å forstå for en SMB som kjøper agenter fra en leverandør. Atferden til systemet ditt kan endres uten at du har gjort en endring, og uten at du får beskjed. Spør derfor leverandøren om varslingsrutiner ved modellbytte og om de holder en versjonslås. Hvis svaret er at de «alltid bruker nyeste modell», har du akseptert ukontrollerte produksjonsendringer uten å vite det.

Rammeverket: revisjon av agent-pipelinen i fire lag

En agent-revisjon som fungerer, stiller fire spørsmål i rekkefølge: hvem er agenten, hva kan den gjøre, ser vi hva den gjorde, og hvem stopper den. Hvert lag har et bevis som må kunne fremlegges skriftlig, og en betingelse som diskvalifiserer produksjonssetting. Dette er en go/no-go-sjekk, ikke en modenhetsvurdering med poengsum. Poengsummer lar folk sette i drift med halv dekning.

Lag	Spørsmålet revisjonen stiller	Bevis som må fremlegges	Går ikke i produksjon hvis
1. Identitet og tilgang	Hvem er agenten i systemene, og hva kan den nå?	Egen maskinidentitet, uttømmende rettighetsliste, dokumentert formålsbegrensning	Agenten bruker en ansatts konto eller en delt nøkkel
2. Handlingsrom og verktøy	Hvilke verktøy har den, og hva kan det verste kallet gjøre?	Verktøyregister der skrive-, slette- og utsendingsfunksjoner er merket, med grenseverdier	Verktøylisten ikke finnes skriftlig og komplett
3. Observerbarhet	Kan vi rekonstruere hva den gjorde for tre uker siden?	Aktivitetslogg med input, verktøykall, utfall og tidsstempel, med kjent lagringstid	Loggen mangler verktøykall, eller slettes før hendelser normalt oppdages
4. Stopp og ansvar	Hvem stopper den, hvordan, og hvor fort?	Navngitt eier, dokumentert bryter, testet nedstengning med måltid	Nedstengningen aldri er testet i produksjonslikt miljø

Lag 1: identitet og tilgang

En agent skal ha egen identitet, aldri lånt. Når agenten kjører på en ansatts konto, blir loggen ubrukelig som bevis, rettighetene blir tilfeldige, og avslutning av arbeidsforhold blir en sikkerhetshendelse. Dette er den mest utbredte snarveien i pilotfasen, og den er også den dyreste å rydde opp i senere, fordi tilgangene da er spredt over flere systemer uten felles oversikt.

Behandle agenten som en brukerkategori med eget risikoprofil. Bare 19 prosent av organisasjonene klassifiserer AI-agenter som likeverdige med menneskelige insider-trusler (kiteworks.com, 2026). Det er et merkelig standpunkt, gitt at en agent jobber døgnet rundt, aldri blir trøtt av å prøve igjen, og har perfekt hukommelse for alt den har lest.

Lag 2: handlingsrom og verktøy

Verktøyregisteret er det dokumentet flest mangler og som gir mest innsikt per time. Sett opp en tabell med alle verktøy agenten kan kalle, hva hvert kall gjør, om det leser eller skriver, hvilke grenseverdier som gjelder, og hva som skjer ved feil. Marker de kallene som er irreversible: utsending til kunder, betalinger, sletting, publisering. Irreversible kall bør kreve menneskelig godkjenning eller en hard grenseverdi, uten unntak i første produksjonsversjon.

Informasjon om verktøyene agenten bruker er en av tre informasjonstyper som er identifisert som nyttig for å avklare årsaksfaktorer etter en hendelse (arXiv, 2025). Det betyr at registeret ikke bare er et designdokument. Det er et bevisdokument, og det må holdes oppdatert når noen legger til et verktøy i uke tolv.

Lag 3: observerbarhet

Gjennomsnittlig overvåkingsdekning for AI-agenter ligger på 52 prosent, og bare noen få prosent av organisasjonene sikrer mer enn 81 prosent av agentene sine (gravitee.io, 2026). Halv dekning er en spesielt dårlig tilstand, fordi den gir en følelse av innsikt uten å gi den. Du oppdager hendelsene i den delen av flåten som faktisk er overvåket, og konkluderer at det går greit.

Testen på om observerbarheten holder, er enkel: velg en tilfeldig dag for tre uker siden og rekonstruer alt agenten gjorde den dagen, inkludert hvilke verktøy den kalte og med hvilke parametre. Klarer du ikke det på under en time, har du ikke en aktivitetslogg. Du har en applikasjonslogg.

Lag 4: stopp og ansvar

Dette laget er der tallene er verst. 60 prosent av organisasjonene kan ikke terminere en AI-agent som oppfører seg dårlig (kiteworks.com, 2026), og svært få har en navngitt person med formelt ansvar for agentatferd (gravitee.io, 2026). Kombinasjonen gir et system ingen eier og ingen kan slå av.

Alura mener at ingen AI-agent bør settes i produksjon uten en navngitt ansvarlig person og en avtalt måte å stoppe den på. Navngitt betyr en person, ikke en avdeling og ikke «IT». Avtalt betyr at nedstengningen er beskrevet, testet og kjent av den som har nattevakt. En bryter som bare utvikleren vet om, er ingen bryter klokka 23 på en lørdag.

Loggene og dokumentasjonen som må finnes før drift

Tre informasjonstyper er pekt ut som særlig nyttige for å avklare årsaksfaktorer etter en agenthendelse: aktivitetslogger, systemdokumentasjon og tilgang, og informasjon om verktøyene agenten bruker (arXiv, 2025). Disse tre er samtidig det som typisk mangler når noe har gått galt, fordi de ikke føles nødvendige mens alt virker.

Alura mener at aktivitetslogger, systemdokumentasjon og oversikt over agentens verktøy er en del av leveransen, ikke noe som ettermonteres etter første hendelse. Grunnen er praktisk: ettermontert loggføring gir deg ikke bevis for det som skjedde før du monterte den. Den første hendelsen er nesten alltid den du ikke kan etterforske.

Aktivitetsloggen: hva som faktisk må stå der

En brukbar aktivitetslogg inneholder, per agentkjøring: tidsstempel, agentidentitet, utløsende hendelse, innkommende kontekst med kilde, hvert verktøykall med parametre, verktøyets svar, og sluttilstanden. Uten parametrene på verktøykallet kan du se at agenten sendte en e-post, men ikke til hvem eller med hvilket innhold. Da har du en teller, ikke et spor.

Logg også avbrutte og avviste kall. Når en agent forsøkte å nå et system den ikke hadde tilgang til, er det det mest verdifulle signalet du får. Det forteller enten at kontekstkilden har blitt forgiftet, eller at oppgavedefinisjonen og rettighetene ikke henger sammen. Begge krever handling før de blir en hendelse.

Systemdokumentasjon og tilgangsoversikt

Systemdokumentasjonen skal svare på hvordan agenten er satt sammen: hvilken modell, hvilken orkestrering, hvilke datakilder, hvilke rettigheter, hvilke mennesker i løkken, og hvilke terskler som utløser eskalering. Dette er ikke et arkitekturdiagram for salgsmøter. Det er dokumentet en revisor, en kunde eller en etterforsker får når de spør hva systemet gjør.

Hold det kort og versjonert. Et dokument på to sider som stemmer, er verdt mer enn tjue sider som ble sanne i mars. Knytt det til verktøyregisteret fra lag to, slik at en endring i verktøy tvinger en endring i dokumentasjonen.

Lagringstid er en designbeslutning, ikke en detalj

Lagringstiden hos leverandøren avgjør hvor langt tilbake du kan etterforske. Anthropic lagrer for eksempel input og output i 30 dager som standard, og opptil to år ved oppdagede brudd på bruksretningslinjene (arXiv, 2025). Det er en rimelig policy, men den er ikke dimensjonert etter din hendelsesoppdagelse.

Regn ut gapet selv: hvor lang tid går det typisk fra en feil oppstår til noen ser den hos dere? Hvis svaret er lengre enn leverandørens standard lagringstid, må du loggføre selv på din side av integrasjonen. Samtidig er agentlogger ofte personopplysninger, så lagringstiden må ha et behandlingsgrunnlag og en slettefrist. Dette er et krav som trekker i to retninger, og det løses med bevisst valg, ikke med standardinnstillinger.

Mandag morgen: inventar, klassifisering og tilgangsrevisjon

Fase en i agentstyring er inventar, klassifisering og tilgangsrevisjoner, med en realistisk tidsramme på fire til åtte uker (kiteworks.com, 2026). Det er overkommelig for en SMB og krever ingen ny plattform. Det krever at noen får det som jobb og ikke som sidesysler.

Alura mener du bør starte med inventar, klassifisering og tilgangsrevisjon nå, i stedet for å vente på at reguleringen blir ferdig. Begrunnelsen er at alle tre jobbene må gjøres uansett hvilken retning regelverket tar, og at de blir dyrere for hver måned flåten vokser.

Uke	Aktivitet	Konkret leveranse	Hvem
1 til 2	Inventar	Liste over alle agenter, automatiseringer og AI-integrasjoner i drift, med eier og utløser	Produktansvarlig med IT
3 til 4	Klassifisering	Hver agent plassert i lav, middels eller høy risiko etter datatype og skriverettigheter	Eier av hver agent
5 til 6	Tilgangsrevisjon	Rettighetsliste per agent, fjerning av arvet og ubrukt tilgang, egen identitet innført	IT eller leverandør
7 til 8	Stopp og logg	Testet nedstengning, aktivitetslogg med verktøykall, navngitt ansvarlig per agent	Ledelsen signerer

Inventaret: finn også de du ikke vet om

Inventaret er lettere og vanskeligere enn det ser ut. Lett, fordi de offisielle agentene står i et prosjektdokument. Vanskelig, fordi de uoffisielle ikke gjør det. 73 prosent av organisasjonene bekymrer seg for at uautorisert AI-bruk skaper usynlige tap av data (kiteworks.com, 2026), og bekymringen er velbegrunnet når enhver ansatt kan koble en AI-assistent til e-post og filer på et kvarter.

Gå etter sporene i stedet for etter folks hukommelse. Sjekk hvilke OAuth-tilkoblinger som er godkjent mot Microsoft 365 eller Google Workspace, hvilke API-nøkler som er utstedt det siste året, hvilke abonnementer som ligger på firmakortet, og hvilke tredjeparter som har aktive webhooks. Spør deretter avdelingene, men bruk funnene som utgangspunkt. Et spørsmål med et konkret funn gir mye bedre svar enn et åpent spørsmål.

Klassifiseringen: to akser er nok

Ikke bygg et risikorammeverk med tolv dimensjoner. To akser bærer nesten all beslutningen: hvor sensitive data agenten kan nå, og om den kan skrive eller sende noe utenfor huset. En agent som leser åpen dokumentasjon og svarer internt er lav risiko selv om den tar feil ofte. En agent som leser kundedata og kan svare kunden direkte, er høy risiko selv om den er treffsikker.

Klassifiseringen forutsetter at du vet hvor de sensitive dataene ligger, og det er ikke gitt. Bare 33 prosent av organisasjonene har fullstendig kunnskap om hvor sensitive data befinner seg (kiteworks.com, 2026). Hvis du er i de to tredjedelene, er dataoversikt en forutsetning for agentstyring og ikke en parallell oppgave.

Tilgangsrevisjonen: fjern det arvede

Mesteparten av gevinsten i denne fasen kommer av å fjerne tilgang, ikke av å legge til kontroller. Gå gjennom hver agent og krev at hver enkelt rettighet begrunnes med en faktisk oppgave agenten utfører. Rettigheter som ikke kan begrunnes, fjernes samme dag. Rettigheter som ble gitt «for å teste», fjernes uten diskusjon.

Legg deretter inn formålsbegrensning der det er teknisk mulig: egen identitet per agent, tilgang til navngitte objekttyper i stedet for hele systemer, og grenseverdier på de verktøyene som koster penger eller går ut til kunder. Dette er arbeidet 63 prosent sier de ikke klarer å håndheve i dag (kiteworks.com, 2026). Det er også arbeidet som gjør de andre tre lagene i revisjonen gjennomførbare.

Hva hendelsene koster i data, drift og penger

Agenthendelser har et karakteristisk utfallsmønster. Det vanligste er ikke driftsstans, det er at data kommer ut der de ikke skulle: 61 prosent av AI-agent-hendelsene involverte eksponering av sensitive data (kiteworks.com, 2026). Det har direkte betydning for den som bygger business case, fordi datalekkasje har en annen kostnadsprofil enn nedetid: den oppdages senere, den rammer omdømme og avtaler, og den utløser varslingsplikt.

Utfall av AI-agent-hendelser	Andel av hendelsene	Hva det betyr i praksis
Eksponering av sensitive data	61 %	Varslingsplikt, kundedialog, mulig tilsynssak
Operasjonell forstyrrelse	43 %	Manuell opprydding, stans i den automatiserte prosessen
Utilsiktede handlinger i forretningsprosesser	41 %	Feil ordre, feil sak, feil kundekommunikasjon som må rettes
Økonomiske tap	35 %	Direkte kostnad, ikke bare risiko
Tjenesteforsinkelser	31 %	Brudd på egne svartider og SLA-er

Utfallene overlapper, og det er poenget

Andelene summerer til langt over hundre fordi en hendelse gir flere utfall samtidig. En agent som sender feil vedlegg til feil kunde, gir både dataeksponering, en utilsiktet handling i en forretningsprosess og en driftsforstyrrelse mens noen rydder. Det er derfor kostnadsestimater basert på en enkelt feiltype blir for lave.

At 35 prosent av hendelsene produserte økonomiske tap er det tallet som flytter en ledergruppe (kiteworks.com, 2026). Det er ikke en teoretisk risiko lenger, men en realisert kostnad i omtrent hver tredje hendelse. Hvis flertallet av organisasjoner har hatt minst en hendelse, er forventningsverdien for en SMB som kjører agenter uten styring, ikke null.

Skygge-AI legger på regningen

Agenter ingen har registrert er dyrere enn de registrerte. Skygge-AI legger omtrent 670 000 dollar til gjennomsnittlig bruddkostnad, målt mot en gjennomsnittlig bruddkostnad i USA på rundt 10 millioner dollar (kiteworks.com, 2026). Tallene er amerikanske og store, og en norsk SMB skal ikke lese dem som sitt eget budsjett. Forholdet mellom dem er likevel overførbart: det som ikke står i inventaret, koster mer når det går galt.

Bakgrunnen er at 92 prosent sier generativ AI fundamentalt har endret hvordan ansatte får tilgang til og deler informasjon (kiteworks.com, 2026). Når delingsmønsteret endres hos alle ansatte samtidig, holder det ikke å styre de offisielle prosjektene. Inventaret må dekke verktøyene folk tok i bruk selv.

Hva moden styring er verdt

Styring har en målbar effekt på hvor fort du kommer deg ut av en hendelse. Organisasjoner med moden AI-styring løser brudd 70 dager raskere enn de uten (kiteworks.com, 2026). Sytti dager er forskjellen mellom en håndtert sak og en sak som preger et helt kvartal.

Dette er argumentet som faktisk virker internt. Revisjonen selger ikke seg selv som forsikring, men som responstid. Når du har inventar, klassifisering, logger og en bryter, går du fra å etterforske til å handle. Når du mangler dem, går de første ukene til å finne ut hva systemet egentlig har tilgang til.

Markedsbildet: 30 agentsystemer og store hull i åpenheten

Hvis du vil vurdere en leverandør på dokumentert sikkerhetsarbeid, må informasjonen finnes. En systematisk gjennomgang av 30 agentiske AI-systemer, basert på offentlig informasjon og e-postkorrespondanse med utviklerne, viser at den ofte ikke gjør det (arXiv, 2026). Det er et marked der produktbeskrivelsene er detaljerte og sikkerhetsbeskrivelsene er tomme.

Gjennomgangen samlet 45 informasjonsfelt per system i seks kategorier: juridiske forhold, tekniske egenskaper, autonomi og kontroll, økosysteminteraksjon, evaluering og sikkerhet (arXiv, 2026). Det gir en nyttig mal for hva du selv bør kreve av en leverandør, og en kald vurdering av hvor mye du kan forvente å få.

Hullene i åpenheten er konsentrert om sikkerhet

Mønsteret er systematisk og ikke tilfeldig: de fleste sikkerhetsrelaterte feltene har ingen offentlig tilgjengelig informasjon, konkret 135 av 240 sikkerhetsfelt, mens 227 av 1 350 felt totalt var tomme (arXiv, 2026). Sikkerhet er altså ikke like underdokumentert som resten. Det er langt verre dokumentert enn resten.

Da forskerne kontaktet selskapene direkte, ga 23 prosent en form for respons, men bare fire av 30 ga substansielle kommentarer (arXiv, 2026). Gjennomsnittlig lengde på de feltene som faktisk hadde innhold, var 14 ord. Det er omtrent en setning per spørsmål om hvordan et autonomt system som kan handle på dine data, er sikret.

Sikkerhetsevalueringer og rammeverk: hvem viser til hva

Bare fire av agentene tilbyr agentspesifikke sikkerhetsevalueringer (arXiv, 2026). Det er verdt å dvele ved. En modellevaluering sier noe om hva modellen svarer. En agentevaluering sier noe om hva systemet gjør når det har verktøy, og det er den risikoen du faktisk importerer. Nesten ingen leverandører publiserer den.

Rammeverksdekningen varierer kraftig med hvor selskapet er inkorporert. 15 av 30 agenter refererer til et AI-sikkerhetsrammeverk, 10 av 30 har ingen dokumentasjon av et slikt rammeverk, og en mindre gruppe mangler dokumenterte compliance-standarder helt. Flertallet av selskapene i indeksen er inkorporert i USA, 21 av 30 (arXiv, 2026).

Opprinnelse	Viser til AI-sikkerhetsrammeverk	Dokumenterer compliance-standarder
USA	95 %	100 %
Kina	40 %	20 %
Andre	76 %	75 %

Tolk tabellen forsiktig. Den måler dokumentasjon, ikke faktisk sikkerhet. Et selskap kan ha god praksis og dårlig publisering. Men dokumentasjon er det eneste du som kjøper kan verifisere før du signerer, og en leverandør som ikke dokumenterer compliance-standarder, gir deg ingenting å holde dem til.

Tre grunnmodellfamilier under nesten alt

Nesten alle de indekserte agentene hviler på bare tre grunnmodellfamilier: GPT, Claude og Gemini (arXiv, 2026). Det har en direkte konsekvens for leverandørvalg: modellkvaliteten er i stor grad en felles komponent, ikke et differensierende trekk hos den enkelte agentleverandøren.

Alura mener leverandører derfor bør vurderes på dokumentert sikkerhetsarbeid og ikke bare på modellkvalitet, siden nesten alle agenter hviler på de samme tre grunnmodellfamiliene. Det som faktisk skiller leverandørene, er orkestreringen, tilgangsstyringen, loggene, stoppmekanismene og hvor godt de håndterer at modellen under dem endres. Det er også der de færreste vil svare konkret uten at du presser.

Et beslektet funn er lett å overse: de fleste agentene oppgir ikke sin AI-natur til sluttbrukere eller tredjeparter som standard (arXiv, 2026). Hvis en agent snakker med kundene dine, er dette en innstilling du må finne og slå på, ikke noe du kan anta ligger i produktet.

Tempopresset som overkjører sikkerhetsdekningen

Antallet agenter vokser langt raskere enn kontrollene rundt dem. Agentflåtene har omtrent doblet seg siden desember 2025, fra et gjennomsnitt på rundt 37 agenter per organisasjon, og i april 2026 hadde 38 prosent mer enn 100 agenter (gravitee.io, 2026). Veksten stopper ikke der: det store flertallet planlegger å deployere flere de neste tolv månedene.

Samtidig oppgir 81 prosent at de kjenner press for å deployere AI-agenter raskt, selv uten full sikkerhet (gravitee.io, 2026). Det er sjelden man får en så ærlig måling av en kjent dynamikk. Presset kommer ikke fra uvitenhet om risiko. Det kommer fra at risikoen taper mot leveringsfrister.

«De fleste er sikret» er ikke en sikkerhetsstatus

Bare et lite mindretall av organisasjonene sier at alle agenter er fullt sikret og styrt før de settes i produksjon, mens flertallet sier at «de fleste» er det (gravitee.io, 2026). «De fleste» betyr at det finnes agenter i produksjon ingen har gått gjennom, og at ingen vet hvilke. Det er en arkitektur der sikkerheten til helheten bestemmes av den agenten du glemte.

Denne fordelingen er grunnen til at revisjonen i denne artikkelen er formulert som go/no-go. «De fleste» høres akseptabelt ut i en styresak. I drift betyr det at et ukjent antall agenter kan nå dataene dine uten at noen har sjekket med hvilke rettigheter.

Beredskapen folk rapporterer, og den de har

Nesten alle sier de er minst noe forberedt på å håndtere AI-agenter som en egen kategori brukere, men bare et mindretall sier «svært» forberedt (gravitee.io, 2026). «Minst noe forberedt» er den svakeste bekreftelsen et spørreskjema kan gi, og den er ikke uforenlig med at under en tiendedel har plassert ansvaret hos en navngitt person.

Gapet mellom opplevd og faktisk beredskap er forutsigbart, og det løses ikke med flere undersøkelser. Det løses med en test: la noen prøve å stoppe en agent i produksjon på en vanlig tirsdag og mål hvor lang tid det tar. Den øvelsen avgjør hvilket av de to svarene som gjelder for deg.

EU AI Act, bøter og det reguleringen ennå ikke beskriver

Bøtenivået i EU AI Act er høyt nok til å flytte oppmerksomhet: maksimalt 35 millioner euro, eller en fastsatt andel av global årlig omsetning, for manglende overholdelse (kiteworks.com, 2026). For en norsk SMB vil den omsetningsbaserte terskelen være den relevante, og den er beregnet for å gjøre vondt uansett selskapsstørrelse.

Markedet selv er ikke overbevist om at regelverket treffer agenter. Bare et mindretall mener dagens regulering er tilstrekkelig for AI-agentrisiko (gravitee.io, 2026). Det er en uvanlig situasjon: de regulerte sier at reglene er for svake, samtidig som de fleste ikke har gjennomført de tiltakene reglene peker mot.

Hullet: ingen har beskrevet hvordan du etterforsker

Det konkrete hullet er prosedyremessig. EU har ikke beskrevet hvordan en rotårsaksanalyse skal gjennomføres, eller hvilken informasjon den skal baseres på (arXiv, 2025). Du kan altså bli pålagt å finne årsaken til en hendelse uten at noen har sagt hva som utgjør tilstrekkelig bevis.

Det praktiske svaret er å bestemme det selv, skriftlig, før du trenger det. Definer hva en rotårsaksanalyse hos dere inneholder: hvilke logger som hentes, hvem som gjør analysen, hvilken tidsramme, og hvordan funnene dokumenteres. En egendefinert, konsekvent brukt prosedyre står seg bedre i et tilsyn enn ingen prosedyre og en henvisning til at kravet var uklart.

Ikke vent på klarhet som ikke kommer

Bare 13 prosent av organisasjonene har formelt integrert AI i sine forretningsstrategier (kiteworks.com, 2026). Lav strategisk formalisering kombinert med rask teknisk utrulling er nøyaktig den tilstanden der regulatorisk risiko bygger seg opp uten at noen eier den.

Det meste av det reguleringen vil kreve, er likevel kjent allerede: at du vet hvilke AI-systemer du bruker, hva de gjør, hvilke data de behandler, hvem som er ansvarlig, og at du kan dokumentere det. Ingen rimelig tolkning av regelverket vil kreve mindre enn det. Derfor er inventar, klassifisering og tilgangsrevisjon arbeid du ikke kaster bort, uansett hvordan detaljene lander.

Leverandørspørsmålene som avdekker svak agentsikkerhet

De fleste leverandørsamtaler om AI-agenter handler om hva agenten kan gjøre. Få handler om hva som skjer når den gjør noe galt. Spørsmålene under er laget for å skille leverandører som har gjort sikkerhetsarbeidet fra dem som har skrevet om det. Testen er ikke om svaret er betryggende, men om det er spesifikt og verifiserbart.

Spørsmål til leverandøren	Hva et godt svar inneholder	Varsellampe
Hvilke verktøy kan agenten kalle, og hvilke av dem skriver eller sender noe?	En komplett liste med skrive- og sendefunksjoner merket, og grenseverdier per verktøy	«Det avhenger av konfigurasjonen din»
Kan jeg se en eksempellogg fra en agentkjøring?	En faktisk logglinje med verktøykall, parametre og utfall	Skjermbilde av et dashbord med antall kjøringer
Hvor lenge lagres input og output, og hvor?	Konkret antall dager, hvilken region, og hvem hos dem som kan lese det	«I henhold til gjeldende personvernregler»
Hvordan stopper jeg agenten, og hvor fort får den effekt?	En dokumentert bryter kunden selv kan bruke, med måltid	Stopp skjer ved å kontakte support
Hvilken modell kjører under, og hva skjer når den oppdateres?	Navngitt modellversjon, varslingsrutine og mulighet for versjonslås	«Vi bruker alltid den nyeste modellen»
Har agenten vært gjennom en agentspesifikk sikkerhetsevaluering?	En rapport eller en beskrivelse av metode og funn	Henvisning til modellleverandørens evalueringer
Hvilket AI-sikkerhetsrammeverk følger dere, og hvem har verifisert det?	Navngitt rammeverk, omfang og ekstern verifisering der den finnes	Et logo-felt på nettsiden uten dokument bak
Oppgir agenten at den er AI til kunder og tredjeparter som standard?	Ja, med beskrivelse av hvordan, eller en innstilling du kan slå på	Spørsmålet må sjekkes med utviklingsavdelingen

Hvordan du leser svarene

Forvent korte svar og vær forberedt på å grave. Når gjennomsnittlig lengde på utfylte informasjonsfelt i en systematisk gjennomgang av 30 agentsystemer er 14 ord, er det ikke fordi spørsmålene var enkle (arXiv, 2026). Det er fordi detaljnivået ikke finnes offentlig. Du må be om det i en innkjøpsprosess, der leverandøren har et insentiv til å svare.

Et nyttig grep: be om å få svarene skriftlig som vedlegg til avtalen, ikke i et møte. Det endrer kvaliteten på svaret umiddelbart. Leverandører som er trygge på sitt sikkerhetsarbeid, har ingen innvendinger mot å feste det til papir. De som nøler, har gitt deg svaret.

Tre krav som bør inn i avtalen

Uansett hvor samtalen lander, bør tre ting stå i kontrakten. Tilgang til logger i et format du kan analysere, inkludert verktøykall og parametre, og innenfor en frist som gjør etterforskning mulig. Varsling ved modellbytte eller annen endring som kan endre atferd, med en frist som gir deg tid til å teste. En stoppmekanisme du selv kontrollerer, med et avtalt måltid fra du trykker til effekten er der.

Legg til et fjerde punkt hvis agenten behandler kundedata: hvor lenge leverandøren lagrer input og output, og hva som skjer med dataene ved mistanke om misbruk. Policyene varierer, og et konkret eksempel på hvordan dette kan se ut er 30 dagers standard lagring med opptil to år ved oppdagede brudd på bruksretningslinjene (arXiv, 2025). Du trenger ikke like tallene, men du trenger å kjenne dem.

Vanlige feil norske SMB-er gjør når agenter settes i produksjon

Feilene er påfallende like fra selskap til selskap, og de er nesten alle organisatoriske heller enn tekniske. Det er godt nytt: organisatoriske feil kan rettes på uker uten at noen må bygge om arkitekturen. Det krever at noen får mandat og en frist.

Pilot blir produksjon uten at noen bestemte det

Den mest utbredte feilen er at piloten glir over i drift. Noen bygger en agent for å teste, den fungerer, folk begynner å bruke den, og seks måneder senere er den en del av en kundeprosess uten at den noen gang har passert en go/no-go. Tilgangene er fortsatt de brede tilgangene fra testfasen, fordi ingen hadde grunn til å stramme dem inn.

Botemiddelet er en eksplisitt overgang. Definer at en agent er i pilot til de fire lagene er dokumentert, og at pilot betyr ingen kundekontakt og ingen skriverettigheter til produksjonsdata. Da blir glidningen synlig, fordi noen må aktivt bryte regelen i stedet for bare å la tiden gå.

Tilgang kopiert fra et menneske, og ingen eier når det smeller

Den nest vanligste feilen er at agenten får en kopi av en ansatts tilgangsprofil, fordi det er den raskeste veien til at ting virker. Problemet er at en ansatt har brede rettigheter kombinert med dømmekraft og et begrenset antall arbeidstimer. En agent får rettighetene uten de to andre, og uten en logg som skiller dens handlinger fra personens.

Den tredje er ansvarsvakuumet. Når svært få har en navngitt ansvarlig for agentatferd (gravitee.io, 2026) og 60 prosent ikke kan terminere en agent som oppfører seg dårlig (kiteworks.com, 2026), er det vanlige mønsteret at hendelsen oppdages av en kunde, eskaleres til IT som ikke eier systemet, og håndteres av leverandøren som ikke eier dataene. Skriv ned navnet på en person per agent. Det koster ingenting og fjerner det meste av forsinkelsen.

Ofte stilte spørsmål om sikkerhet for AI-agenter

Spørsmålene under er de som oftest kommer opp når en ledergruppe tar denne diskusjonen for første gang. Svarene er holdt korte og med henvisning til tall der de finnes.

Er en AI-agent virkelig mer risikabel enn en vanlig integrasjon?

Ja, på tre punkter. En integrasjon følger en fast kodebane, en agent velger handling ut fra tekst den leser underveis, noe som gjør innkommende data til en mulig instruksjonskanal. En integrasjon feiler forutsigbart, en agent kan feile kreativt. Og agenter er dokumentert upålitelige i dagens modenhetsnivå, med motstanderlige sårbarheter og problemer med instruksjonsfølging (arXiv, 2025). Rettighetsstyringen du kjenner fra integrasjoner er fortsatt riktig, men den må være strammere.

Hvordan finner vi agentene ingen har registrert?

Start i tilgangsloggene, ikke i samtalene. Gjennomgå godkjente OAuth-tilkoblinger i Microsoft 365 eller Google Workspace, utstedte API-nøkler siste tolv måneder, aktive webhooks mot tredjeparter, og abonnementer på firmakort. Kryss deretter av mot avdelingene. Bekymringen for usynlige datatap fra uautorisert AI-bruk deles av 73 prosent (kiteworks.com, 2026), så regn med å finne noe.

Hvor lenge bør vi lagre agentlogger?

Lenger enn tiden det typisk tar dere å oppdage en feil, og kortere enn det personvernregelverket tillater for den datatypen. Merk at leverandørens lagringstid kan være kortere enn din: 30 dager som standard er et dokumentert eksempel, med opptil to år ved oppdagede brudd på bruksretningslinjene (arXiv, 2025). Hvis gapet mellom deres frist og din oppdagelsestid er stort, må du loggføre på egen side.

Gjelder EU AI Act for en norsk SMB som bare kjøper agenter?

Du blir ikke fri for ansvar ved å kjøpe i stedet for å bygge. Bøtenivået er opp mot 35 millioner euro for manglende overholdelse, eller en fastsatt andel av global årlig omsetning (kiteworks.com, 2026), og dokumentasjonsplikten følger den som bruker systemet i egen virksomhet. Praktisk håndtering: krev dokumentasjonen fra leverandøren skriftlig, hold ditt eget inventar, og bygg en rotårsaksprosedyre selv, siden EU ikke har beskrevet hvordan en slik analyse skal gjennomføres (arXiv, 2025).

Trenger vi en egen rolle for AI-sikkerhet?

Ikke en ny stilling i en SMB, men en navngitt person med mandatet skrevet ned. Når svært få har formelt individuelt ansvar for agentatferd (gravitee.io, 2026), er terskelen for å skille seg positivt ut lav. Rollen trenger tre fullmakter: å stoppe en agent uten å spørre, å avvise produksjonssetting som mangler logger eller eier, og å kreve dokumentasjon fra leverandører før signering.

Oppsummering og neste steg

Hovedbildet er tydelig nok til å handle på. 48 prosent av AI-agentene i produksjon kjører usikret, overvåkingen dekker i gjennomsnitt 52 prosent av flåten, og under en tiendedel av organisasjonene har en navngitt ansvarlig for hva agentene gjør (gravitee.io, 2026). Samtidig har flertallet allerede hatt minst en hendelse, og det vanligste utfallet er at sensitive data kommer ut (kiteworks.com, 2026). Dette er ikke et framtidsscenario som skal planlegges for. Det er nåsituasjonen i markedet du kjøper i.

Markedet gir deg lite hjelp til å velge trygt. I en systematisk gjennomgang av 30 agentsystemer var flertallet av sikkerhetsfeltene tomme, bare fire tilbyr agentspesifikke sikkerhetsevalueringer, og nesten alle agentene hviler på de samme tre grunnmodellfamiliene (arXiv, 2026). Det flytter vurderingen fra modellkvalitet til dokumentert sikkerhetsarbeid, logger, stoppmekanismer og kontraktsfestede krav. Det er den delen du kan påvirke.

Neste steg er avgrenset og målbart. Sett av fire til åtte uker til inventar, klassifisering og tilgangsrevisjon (kiteworks.com, 2026), og avslutt perioden med fire konkrete leveranser: en liste over alle agenter med eier, en risikoklassifisering per agent, en revidert rettighetsliste, og en testet nedstengning. Krev deretter aktivitetslogger, systemdokumentasjon og verktøyoversikt som del av hver leveranse framover, ikke som noe som ettermonteres etter første hendelse.

Den enkleste testen på om dere er klare, tar en halvtime: velg en agent i produksjon, finn ut hvem som eier den, stopp den, og rekonstruer hva den gjorde i forrige uke. Går det greit, har dere en pipeline som tåler drift. Går det ikke, har dere nettopp funnet rekkefølgen på arbeidet.

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 | Gravitee
kiteworks.com (2026). AI Agent Security Incidents Hit 65% of Firms in 2026
arXiv (2026). The 2025 AI Agent IndexDocumenting Technical and Safety Features of Deployed Agentic AI Systems
arXiv (2025). Incident Analysis for AI Agents