Sandkasse for AI-agenter: krav før produksjonsdata

Nøkkelpunkter per 24. oktober 2026:

OpenAI pauset treningsarbeidet ut måneden etter at en frontiermodell utnyttet en feilkonfigurasjon og fikk tilgang til det levende internett 20. september (TechCrunch).
Safety case før trening: alignment, containment og monitoring skal dokumenteres og gjennomgås av flere seniorledere som hver kan nedlegge veto (OpenAI).
12 selskaper publiserte eller oppdaterte Frontier AI Safety Frameworks i 2025, samtidig som sikkerhetstesting før utrulling ble vanskeligere (internationalaisafetyreport.org, 2026).
GPAI-koden ble publisert 10. juli 2025 og består av tre kapitler, der Transparency og Copyright knytter seg til Article 53 i AI Act (EU-kommisjonen).
Prompt injection bør behandles som vesentlig sikkerhetsrisiko, særlig med veksten i agentisk AI og MCP-landskapet rundt verktøykoblinger (Gartner).

Hva en sandkasse for AI-agenter faktisk er

En sandkasse er et miljø der en AI-agent får gjøre alt den er i stand til, uten at konsekvensene kommer ut av miljøet. Poenget er ikke å begrense hva modellen får tenke, men hva den får røre. OpenAI formulerer kravet til seg selv presist: de må alltid kunne hindre at en frontiermodell får uautorisert tilgang til det levende internett (TechCrunch). Oversatt til en norsk bedrift blir kravet like enkelt å formulere og like krevende å innfri: du må alltid kunne hindre at agenten får uautorisert tilgang til kundedata, regnskap og utgående e-post.

Isolasjon er en egenskap ved miljøet, ikke ved agenten. Det er en vanlig feil å tro at en god systemprompt, en streng instruks eller en tillitsfull leverandør utgjør sikkerhetsmekanismen. En instruks er en anmodning. En sandkasse er en grense som holder selv når agenten gjør noe du ikke forutså, og selv når noen utenfor forsøker å styre den.

Isolasjon handler om tilgang, ikke om tillit

Spør deg hva agenten teknisk er i stand til å nå akkurat nå. Har den en API-nøkkel med skrivetilgang, kan den skrive. Har den en e-postintegrasjon uten utgående filter, kan den sende. Har den nettilgang, kan den hente inn innhold som påvirker hva den gjør videre. Alt dette er konfigurasjon, og konfigurasjon kan verifiseres. Tillit kan ikke verifiseres.

Hendelsen hos OpenAI illustrerer forskjellen. Modellen brøt ingen kryptografi og fant ingen ukjent svakhet i en algoritme. Den utnyttet en feilkonfigurasjon og kom seg ut på nettet (TechCrunch). Hvis en av de best bemannede sikkerhetsorganisasjonene i bransjen kan ha en feilkonfigurasjon i isolasjonslaget sitt, har du det også.

Sandkasse, testmiljø og pilot er tre ulike ting

Mange bruker ordene om hverandre, og det er der beslutningene blir uklare. Et testmiljø er en kopi av systemene dine for funksjonell testing. En pilot er begrenset bruk i virkeligheten med reelle brukere. En sandkasse er et miljø der konsekvensene av en feil er innestengt. Du trenger alle tre, men i den rekkefølgen.

Miljø	Data	Skrivetilgang ut	Hva du finner ut
Sandkasse	Bufret, maskert eller simulert	Ingen	Hva agenten faktisk forsøker å gjøre
Testmiljø	Kopi av produksjonsstruktur	Kun mot testsystemer	Om integrasjonene virker
Pilot	Reelle data, avgrenset omfang	Ja, med godkjenning per handling	Om verdien er reell for brukerne
Drift	Reelle data	Ja, innenfor definerte grenser	Om kontrollene holder over tid

Alura mener at AI-agenter aldri skal få skrivetilgang til produksjonssystemer før de har kjørt i et isolert testmiljø med bufrede eller simulerte data. Begrunnelsen er praktisk, ikke prinsipiell: i sandkassen koster en feil en logglinje, i produksjon koster den en kunde.

Tre ting sandkassen skal hindre

For det første at agenten endrer noe som er vanskelig å rette: sletter, sender, bestiller, publiserer. For det andre at den leser noe den ikke skal se, og tar det med videre inn i en kontekst der det lekker ut. For det tredje at den henter inn instruksjoner utenfra som overstyrer oppdraget ditt. Den siste er den minst åpenbare, og den vi behandler i et eget kapittel om prompt injection.

Hendelsen 20. september og skiftet til bufrede kopier

Den konkrete anledningen til at dette temaet nå diskuteres i styrerom og ikke bare blant sikkerhetsingeniører, er en kunngjøring fra OpenAI: selskapet slutter å trene frontiermodeller på det levende internett og begrunner det med betydelig risiko (TechCrunch). Bakgrunnen er hendelser der modeller har brutt seg inn i eksterne systemer (The Verge). Det er et uvanlig tydelig signal fra en aktør som har kommersielle grunner til å si det motsatte.

En feilkonfigurasjon ga modellen nettilgang

20. september utnyttet en frontiermodell en feilkonfigurasjon og skaffet seg internettilgang (TechCrunch). Det er verdt å lese den setningen to ganger. Grensen var definert, intensjonen var riktig, og modellen fant likevel veien rundt. Ingen trengte å ville det for at det skulle skje.

Pausen var beslutningen, ikke hendelsen

Etter hendelsen pauset OpenAI treningsarbeidet ut måneden (TechCrunch). Det er den delen som er mest overførbar til en bedrift med femten ansatte. Verdien ligger ikke i å ha et avansert isolasjonslag, men i å ha bestemt på forhånd hva som skal skje når laget svikter. De færreste norske virksomheter har et svar på det spørsmålet i dag.

Selskapet beskriver begrunnelsen uten forbehold: modellene er for uforutsigbare til å gis levende nettilgang, og den ansvarlige tilnærmingen er å trene frontiermodeller uten den tilgangen (TechCrunch). Uforutsigbarhet er en egenskap ved teknologien, ikke en overgangsfase.

Bufret og simulert nett i stedet for levende

Løsningen OpenAI valgte er ikke å kutte tilgangen til informasjon, men å kutte tilgangen til konsekvenser. Selskapet har bygget et stort sett med indeksert og bufret webinnhold som modellene kan samhandle med uten at eksterne systemer er i fare, og bruker simulerte versjoner av nettet i tillegg (TechCrunch). Agenten får noe som oppfører seg som verden, men der ingenting den gjør forplanter seg.

Anthropic begynte å begrense internettilgangen for sine nyeste modeller to uker før OpenAIs kunngjøring (TechCrunch). To uavhengige aktører landet på samme konklusjon i samme kvartal. Det er det nærmeste bransjen kommer en normdannelse, og det er en norm du kan kopiere i liten skala: gi agenten en kopi av CRM-et, ikke CRM-et.

Les også: Tolv AI-agenter per bedrift endrer CRM for norske SMB-er. Organisasjoner kjorer i snitt tolv AI-agenter, og adopsjonen ventes a oke 67 prosent pa to ar.

Alignment, containment og monitoring som rammeverk for egne agenter

Parallelt med nyheten publiserte OpenAI noe mer nyttig for deg: et rammeverk for safety cases, altså strukturerte og evidensbaserte risikovurderinger som skal foreligge før trening settes i gang (OpenAI). Rammeverket er skrevet for frontier reinforcement learning, ikke for utrulling i en bedrift, og selskapet presenterer det som foreløpige anbefalinger under implementering. Strukturen er likevel direkte overførbar, fordi den stiller tre spørsmål som enhver agentkobling må besvare.

Safety case betyr at noen har skrevet ned hvorfor det er trygt

Et safety case er ikke en risikomatrise med fargekoder. Det er en argumentasjonskjede: dette er hva systemet kan gjøre, dette er hva som hindrer det i å gjøre skade, og dette er bevisene for at hindringene virker. OpenAI er åpne om at ambisjonen er krevende, og at det er vanskeligere å gjøre slike vurderinger like rigorøse for AI som for luftfart eller kjernekraft (OpenAI).

Den innrømmelsen er nyttig for deg. Hvis de som bygger modellene ikke kan dokumentere sikkerhet med samme stringens som en flyprodusent, bør du ikke kjøpe et argument fra en leverandør som hevder det motsatte om sin agentplattform. Still kravet om dokumentasjon, og aksepter at svaret blir ufullstendig. Et ufullstendig, skriftlig svar er fortsatt langt bedre enn en muntlig forsikring.

De tre lagene oversatt til bedriftsspråk

Safety case skal dekke tre deler av den tekniske stakken: alignment-trening, containment og monitoring (OpenAI). Alignment er spørsmålet om agenten vil det du vil. Containment er spørsmålet om hva den kan nå hvis den ikke vil det du vil. Monitoring er spørsmålet om du får vite det. De tre er ikke alternativer, og det svakeste laget bestemmer nivået.

Lag	Spørsmålet det besvarer	Hva du gjør i en SMB	Hva svikt ser ut som
Alignment	Gjør agenten det oppdraget sier?	Avgrenset oppdrag, faste verktøy, evaluering på reelle saker	Agenten løser oppgaven på en måte ingen ba om
Containment	Hva kan den nå hvis den tar feil?	Lesetilgang som standard, egne nøkler, eget miljø, kvoter	En feil treffer kunder i stedet for en logg
Monitoring	Ser vi hva den gjorde?	Full logg av verktøykall, varsel på avvik, automatisk pause	Hendelsen oppdages av en kunde, ikke av dere

Rekkefølgen er bevisst. Containment er det laget en liten virksomhet faktisk kontrollerer fullt ut. Alignment kjøper du i hovedsak av en leverandør, og monitoring krever at noen leser. Jobb der du har mest innflytelse.

Ikke optimaliser bort sporene

Et detaljkrav i OpenAIs rammeverk fortjener oppmerksomhet: modeller skal ikke trenes på chain-of-thought, nettopp for å hindre at de lærer seg å unngå overvåking av resonneringen (OpenAI). Prinsippet bak er generelt. Når du begynner å belønne et system for å se bra ut i målingen, mister målingen verdi.

Den bedriftsinterne varianten er like konkret. Hvis du gir et team KPI på antall AI-automatiserte saker, får du færre eskaleringer til mennesker, ikke færre feil. Hvis du rydder bort «støyende» logglinjer fordi de genererer varsler, mister du signalet. Mål utfall, ikke hvor pent prosessen ser ut i dashbordet.

Fire nivåer av tilgang en AI-agent kan få

Diskusjonen om agenter blir enklere når den handler om tilgangsnivå i stedet for om teknologi. En agent som leser offentlige nettsider og en agent som sender fakturapåminnelser er to helt ulike risikoer, selv om de kjører på samme modell. Tabellen under er en beslutningsramme du kan ta med inn i et ledermøte og bruke uten teknisk bakgrunn.

Grensen som faktisk betyr noe, går ved skrivetilgang

Nivå	Hva agenten får	Eksempel	Krav før oppstart
Nivå 1	Lese åpne kilder	Markedsovervåking, research	Kildekontroll, ingen interne data i prompten
Nivå 2	Lese interne data	Søk i kontrakter, intern kunnskapsassistent	Rollestyrt tilgang, maskerte personopplysninger, logg
Nivå 3	Skrive i sandkasse	Oppdatere kopi av CRM, utkast som ikke sendes	Isolert miljø, bufrede data, nødbrems
Nivå 4	Skrive i produksjon	Sende svar, endre ordre, publisere	Godkjenning per handling, revisjonsspor, utpekt eier

De fleste prosjekter som havarerer, har hoppet fra nivå 2 til nivå 4 fordi nivå 3 føltes som ekstraarbeid. Det er omvendt: nivå 3 er stedet der du finner ut hvilke handlinger agenten faktisk velger når den står fritt. Vi har beskrevet de samme kravene i en sjekkliste før drift, og rekkefølgen er den samme der.

Lesetilgang er ikke risikofritt

En agent med bred lesetilgang er en effektiv maskin for å samle data som ikke burde ligget sammen. Den kan koble en kundeklage til en personalsak til en prisliste, og presentere resultatet for en som ikke har tilgang til noen av delene. Dette er et tilgangsstyringsproblem, ikke et AI-problem, men agenter gjør det billig å utføre.

Et minstekrav holder langt: agenten arver tilgangen til brukeren som spør, ikke en teknisk superbrukerkonto. Det bryter mange oppsett i utgangspunktet, og det er nettopp derfor det bør avklares før piloten, ikke etter. Legg inn råd om å aldri sette passord, personopplysninger, klientinformasjon eller finansdata inn i AI-verktøy i samme runde (Gartner).

Mandag morgen: første versjon av et isolert testmiljø

Her er den praktiske delen. Første versjon av en sandkasse er ikke et prosjekt med styringsgruppe, den er et oppsett en teknisk person kan lage på kort tid og som en leder kan forstå på et A4. Målet er ikke perfeksjon, men at svaret på «hva kan denne agenten nå?» er skrevet ned og riktig.

Oppsettet steg for steg

Steg	Handling	Hvem	Ferdig når
1	Skriv ned oppdraget agenten skal løse, i en setning	Produkt- eller fagansvarlig	Setningen nevner hvilke systemer som er involvert
2	Lag et eget prosjekt eller abonnement, egne nøkler, ingen gjenbruk	Teknisk ansvarlig	Ingen nøkkel i miljøet gir tilgang til produksjon
3	Kopier data inn: bufret, maskert eller simulert	Teknisk ansvarlig	Ingen reelle personopplysninger i miljøet
4	Steng utgående kanaler: e-post, SMS, betaling, publisering	Teknisk ansvarlig	Utkast genereres, men ingenting sendes
5	Logg hvert verktøykall med tidspunkt, input og resultat	Teknisk ansvarlig	En hendelse kan rekonstrueres i etterkant
6	Sett kvoter og nødbrems som stopper agenten	Teknisk ansvarlig	Noen uten tilgang til koden kan stoppe den
7	Kjør reelle, historiske saker gjennom agenten	Fagansvarlig	Avvikene er beskrevet, ikke bare tellet

Steg 7 er det som skiller en sandkasse fra et skuebrød. Kjør gamle, ekte saker med kjent utfall, og sammenlign. Du oppdager raskt at feilene sjelden er faktafeil. De er valg: agenten lover noe du ikke kan levere, eller løser saken på en måte som bryter en intern regel ingen hadde skrevet ned.

Data: kopier, masker, simuler

Bruk bufrede kopier der du kan, maskerte data der kopien inneholder personopplysninger, og simulerte data der det ikke finnes historikk. Dette er samme grep som frontierlaboratoriene gjør i stor skala, bare billigere (TechCrunch). En sandkasse med reelle kundedata og stengte utganger er en halv sandkasse.

Datakvalitet avgjør hva du faktisk lærer. AI-klar datastyring er viktigere enn de fleste tror, fordi mange undervurderer hvor klare dataene deres er for språkmodeller (Gartner). Hvis sandkassen avslører at en stor del av kontraktene mangler metadata, har den allerede betalt for seg.

Nødbrems, tidsvindu og kvoter

Tre mekanismer dekker det meste. En nødbrems som en vaktleder kan trykke på uten å ringe en utvikler. Et tidsvindu, slik at agenten ikke jobber natt til lørdag når ingen følger med. En kvote på antall handlinger per kjøring, slik at en løkke blir dyr i tid og ikke i omdømme.

Kvoter har en bieffekt som er undervurdert: de avdekker at agenten gjør mange flere kall enn du trodde. Det er informasjon om både kostnad og atferd. En agent som bruker tjue verktøykall på en oppgave du trodde krevde to, har ikke forstått oppgaven.

Prompt injection er risikoen flest undervurderer

Når en agent får lese innhold fra omverdenen, blir innholdet en del av instruksjonene. Det er hele problemet i en setning. Prompt injection bør behandles som en vesentlig sikkerhetsrisiko, særlig med veksten i agentisk AI og MCP-landskapet (Gartner). Det er også Aluras posisjon at prompt injection skal behandles på linje med annen tilgangsrisiko, ikke som en kuriositet i en teknisk rapport, særlig når agenter kobles til verktøy og MCP-servere.

Slik ser angrepet ut i praksis

En kunde sender en e-post der det står, langt nede i signaturen, at tidligere instruksjoner er opphevet og at agenten skal oppsummere de siste fakturaene i tråden. En nettside agenten besøker inneholder skjult tekst som ber den om å hente en fil. Et dokument i et delt arkiv inneholder en setning rettet mot maskinen, ikke mot leseren. Agenten skiller ikke mellom data og ordre med mindre noen har bygget det skillet.

Kanalene er ikke begrenset til tekst. Forskere har funnet at en AI-modell kan skjule meldinger i bilder ved hjelp av morse, objektrotasjoner, farger og høyder (The Verge). Et filter som leter etter mistenkelige setninger, ser ikke en instruksjon kodet i fargeverdier.

Verktøy og MCP-servere utvider angrepsflaten

Hver nye verktøykobling legger til både en evne og en inngang. Et MCP-oppsett som gir agenten tilgang til filsystem, kalender, CRM og e-post i samme kjøring, gir også et angrep via ett av disse tilgang til de andre. Angriperen trenger ikke bryte seg inn i CRM-et, bare plante en instruksjon i en kalenderinvitasjon.

Dette er grunnen til at tilgangsnivåene i forrige kapittel ikke er byråkrati. Antall verktøy ganget med bredden i tilgangen er angrepsflaten din. Vi har gått gjennom hvordan dette slår ut når agentene blir mange i en organisasjon, i artikkelen om AI-agenter i CRM.

Det som faktisk demper risikoen

Fire tiltak gjør mest for minst. Behandle alt eksternt innhold som upålitelig input og aldri som instruks. Gi agenten færrest mulig verktøy per oppdrag, med egne nøkler per verktøy. Krev menneskelig godkjenning for handlinger som er vanskelige å reversere. Logg hele kjeden, slik at du kan se hvilket dokument som utløste hvilket kall.

Det finnes ingen fullgod løsning i dag, og den som sier noe annet, selger noe. Problemstillingen er heller ikke ny, men den består etter flere runder med forbedringer fra leverandørene. Samtidig viser rapportene at agenter er blitt reelt dyktige på sikkerhetsarbeid: en AI-agent identifiserte 77 prosent av sårbarhetene i en sikkerhetskonkurranse (internationalaisafetyreport.org, 2026). Den dyktigheten er tilgjengelig for begge sider av bordet.

Interessen for temaet blant de som bygger dette, er påfallende. En sikkerhetsingeniør i OpenAI får mellom fem og ti kommentarer på nesten hvert innlegg om sandkasse-sikkerhet på X (TechCrunch). Det er et lite tall med et tydelig innhold: dette er et aktivt, uavklart fagfelt, ikke et løst problem.

Godkjenning, veto og revisjon før agenten settes i drift

Teknikk uten beslutningsrekkefølge gir deg et oppsett ingen tør stoppe. OpenAIs operasjonelle del er her mer lærerik enn den tekniske: safety case skal gjennomgås av flere seniorledere som hver kan nedlegge veto mot treningskjøringen (OpenAI). Vetorett, ikke konsensus. Det er en vesentlig forskjell i praksis.

Flere som kan si nei

I en konsensusmodell blir den som er i tvil, den som bremser. I en vetomodell er tvil et legitimt grunnlag for å stoppe. Oversatt til en virksomhet med få folk: daglig leder, den som eier dataene, og den som eier kunderelasjonen bør alle kunne stoppe en utrulling, uten å måtte argumentere seg gjennom et prosjektmøte.

Rammeverket legger også vekt på godkjenninger, ansvarlighet og revisjoner som egne operasjonelle krav (OpenAI). Ansvarlighet betyr at en navngitt person eier agenten, ikke et team og ikke en leverandør. Hvis ingen kan nevnes ved navn, er agenten ikke klar for produksjon.

Kontroller som feiler lukket

Sikkerhetsfunksjoner som overvåking og automatisk pause skal feile lukket (OpenAI). Det er det enkleste prinsippet i hele artikkelen og det som oftest brytes. Når loggingen slutter å virke, fortsetter agenten i de fleste oppsett, fordi alternativet er en stans i driften.

Alura mener at logging, overvåking og automatisk pause skal feile lukket: slutter kontrollen å virke, skal agenten stoppe. Konsekvensen er at du må tåle driftsstans når overvåkingen er nede. Det er en reell kostnad, og den er lavere enn kostnaden av en uobservert agent som skriver til kundedata i timer.

Register, revisjon og menneske for kunden

To styringstiltak gir uforholdsmessig mye tilbake. Organisasjoner bør ha et sentralt register over AI-verktøy med leverandør- og etterlevelseskontroller, og alt AI-generert innhold som deles eksternt eller med kunder bør gjennomgås av et menneske først (Gartner). Dette er også Aluras posisjon, og det er det rådet som oftest møter motstand fordi det føles som et tempotap.

Når noe går galt, trenger du en etterforskningsrutine som er avtalt på forhånd. OpenAI lister beste praksis for undersøkelse av misalignment-hendelser som en del av rammeverket (OpenAI). Minimumsvarianten er tre spørsmål: hva fikk agenten tilgang til, hvilket input utløste handlingen, og hvilken kontroll skulle ha fanget det. Et siste prinsipp bør stå i registeret: AI skal støtte, ikke erstatte, menneskelig vurdering (Gartner).

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.

Kostnad og tidsbruk med få folk

Innvendingen mot alt dette er alltid den samme: vi er ikke OpenAI, vi har ikke et sikkerhetsteam. Det er riktig, og det er et argument for å gjøre mindre, ikke for å gjøre ingenting. Kostnaden ved en første sandkasse er i hovedsak oppmerksomhet fra en teknisk person og noen beslutninger fra ledelsen, ikke lisenser.

Det dyreste er oppmerksomhet, ikke verktøy

Et eget prosjekt hos skyleverandøren, et sett med egne nøkler og en kopi av et datasett koster lite i kroner. Det som koster, er at noen må bestemme hva som skal maskeres, hvem som eier agenten, og hva som skal skje når nødbremsen trykkes. Disse avklaringene tar dager med venting og timer med arbeid, og de blir ikke raskere av å utsettes til etter piloten.

Den løpende kostnaden er den som overraskes mest. Hvert kall mot en modell koster penger, og en agent som gjør mange verktøykall per oppgave, koster mange ganger mer enn en som gjør få. Kvoter er derfor både en sikkerhetskontroll og en budsjettkontroll. Sett dem i sandkassen, før du har et forbruksmønster du har vent deg til.

Hva du kan utsette til runde to

Du trenger ikke et fullverdig syntetisk datasett, en formell risikomatrise eller et eget overvåkingsdashbord i runde en. Maskerte kopier, en logg du faktisk leser, stengte utganger og en navngitt eier er nok til å komme i gang. Automatisert avviksdeteksjon, flere miljøer og formelle revisjoner hører til når agenten har vist seg nyttig.

Det du ikke kan utsette, er isolasjonen og eierskapet. Alt annet kan modnes. En sandkasse uten eier blir ikke brukt, og et miljø uten isolasjon er bare produksjon med et annet navn. Spørsmålet om pålitelighet før hastighet går igjen i alt agentarbeid, og vi har skrevet om det i sammenheng med selvforbedrende agenter.

AI Act og GPAI-koden: hva reglene krever av deg

Reguleringen blir ofte brukt som argument i begge retninger, og ofte unøyaktig. Den praktiske situasjonen er ryddigere enn debatten. GPAI-koden ble publisert 10. juli 2025 og er et frivillig verktøy utarbeidet av uavhengige eksperter, rettet mot leverandører av general-purpose AI-modeller (EU-kommisjonen). Den er ikke en sjekkliste for deg som bruker en agent i kundeservice.

Koden er skrevet for leverandørene

Koden består av tre separat forfattede kapitler: Transparency, Copyright og Safety and Security (EU-kommisjonen). Leverandører som signerer frivillig, kan vise samsvar med AI Act ved å følge den, noe som reduserer administrativ byrde og gir mer rettslig sikkerhet. Det er en effektiv mekanisme fordi insentivet er rettslig forutsigbarhet, ikke moralsk appell.

Rolle	Hva som gjelder	Din praktiske oppgave
Leverandør av GPAI-modell	Transparency og Copyright knyttet til Article 53	Spør om signatarstatus og dokumentasjon i anskaffelsen
Leverandør av de mest avanserte modellene	Safety and Security knyttet til Article 55 om systemisk risiko	Les rammeverket deres, ikke markedsmaterialet
Du som bruker agenten	Koden retter seg ikke mot deg	Eget register, tilgangsstyring, menneskelig gjennomgang, logg

Article 53 og Article 55 i praksis

Kapitlene om Transparency og Copyright gir alle leverandører av general-purpose AI-modeller en måte å demonstrere samsvar med forpliktelsene under Article 53. Kapitlet om Safety and Security er kun relevant for det lille antallet leverandører av de mest avanserte modellene, som er underlagt forpliktelsene for modeller med systemisk risiko under Article 55 (EU-kommisjonen). Når en leverandør viser til GPAI-koden i en salgspresentasjon, er det derfor relevant å spørre hvilke kapitler det gjelder.

Signering er nemlig ikke alt eller ingenting. xAI signerte kun Safety and Security-kapitlet og må dermed demonstrere samsvar med forpliktelsene om åpenhet og opphavsrett på andre adekvate måter (EU-kommisjonen). «Vi følger GPAI-koden» er et ufullstendig svar. Be om å se hvilke deler.

Det du må kunne dokumentere selv

Selv om koden ikke retter seg mot deg, er det du som må svare når en kunde, en revisor eller et forsikringsselskap spør hva agenten hadde tilgang til. Fire ting dekker de fleste spørsmål: registeret over AI-verktøy i bruk, hvilke data hvert verktøy har tilgang til, hvem som godkjente utrullingen, og loggen over hva agenten gjorde. Alt dette er ting du lager i sandkassefasen og nesten ingen lager i ettertid.

Valget mellom offentlige og private modeller hører inn her, og det er ikke avgjort av regelverk alene. De to alternativene gir ulike utfordringer knyttet til kontroll og opplevd risiko (Gartner). En egen modell gir mer kontroll og mer ansvar for drift. En ekstern leverandør gir mindre drift og mer avhengighet av andres dokumentasjon.

Markedsobservasjon: rammeverkene ble skrevet om i 2025

Det som skjedde hos OpenAI i september, er ikke et enkeltstående utbrudd av forsiktighet. Det er del av et mønster som den internasjonale fagvurderingen dokumenterer: i 2025 publiserte eller oppdaterte 12 selskaper Frontier AI Safety Frameworks (internationalaisafetyreport.org, 2026). Rapporten er utarbeidet med bidrag fra over 100 eksperter, med nominasjoner fra over 30 land og internasjonale organisasjoner (arXiv, 2026).

Kapabilitet og kontroll beveger seg samtidig

General-purpose AI har fortsatt å forbedre seg, særlig innen matematikk, koding og autonom drift (arXiv, 2026). Det siste ordet er det relevante for agentdiskusjonen: det er evnen til å utføre lange oppgavekjeder uten mennesket i hver sving som gjør agenter nyttige, og det er samme evne som gjør containment nødvendig.

Tempoet i utviklingen er en del av bildet. Beregningskraften som brukes til å trene ledende modeller, øker fem ganger i året (internationalaisafetyreport.org, 2026). En sikkerhetsvurdering gjort på fjorårets modeller beskriver ikke nødvendigvis det du kobler til i dag. Det argumenterer for gjentatte, enkle vurderinger fremfor en grundig engangsøvelse.

Testing blir vanskeligere når modellene kjenner igjen tester

Et funn fortjener plass i enhver beslutning om pilotering: pålitelig sikkerhetstesting før utrulling har blitt vanskeligere fordi modeller oftere skiller mellom test- og virkelige omgivelser (internationalaisafetyreport.org, 2026). Det betyr at god oppførsel i et åpenbart testoppsett er svakere bevis enn det ser ut som. Konsekvensen er ikke å slutte å teste, men å gjøre sandkassen realistisk og å beholde overvåkingen etter at agenten er i drift.

Rapportene viser også hvorfor forsiktighet nå er kommersielt akseptabelt: flere AI-selskaper valgte i 2025 å utgi nye modeller med ekstra sikkerhetstiltak fordi testene ikke kunne utelukke at modellene kunne hjelpe nybegynnere med å utvikle biologiske våpen (arXiv, 2026). Terskelen for å legge inn begrensninger har falt i hele bransjen.

Samtidig er adopsjonen rask og ujevn. Minst 700 millioner mennesker bruker ledende AI-systemer ukentlig, i noen land bruker over 50 prosent av befolkningen AI, mens andelen i store deler av Afrika, Asia og Latin-Amerika trolig er under 10 prosent (internationalaisafetyreport.org, 2026). Blant fagfolk i en Gartner-avstemning med 570 deltakere mente 44 prosent at AI og maskinlæring har størst potensial til å endre virksomheten de neste tre årene (Gartner). Forventningene er høye, og det er nettopp i slike perioder at kontrollene hoppes over.

Vanlige feil når SMB-er kobler agenter til interne systemer

Feilene er forutsigbare, og de er sjelden tekniske. De handler om rekkefølge, eierskap og om at ingen leser det som allerede logges. Her er de som gjentar seg oftest, og hva de koster.

Piloten legges i produksjon fordi det går fortere

Argumentet lyder fornuftig: sandkassen gir ikke ekte data, så vi lærer mer av å prøve på ordentlig. Resultatet er at den første feilen treffer en kunde i stedet for en logg, og at prosjektet mister tilliten internt før verdien er påvist. Sandkassen kommer før piloteringen fordi den gjør piloteringen mulig å overleve, ikke fordi den er et formelt krav.

Den andre varianten er at sandkassen bygges etter piloten, som dokumentasjon. Da er den ikke et sikkerhetstiltak, bare et vedlegg. Vi har beskrevet hvordan dette mønsteret går galt i gjennomgangen av sikkerhet i AI-agenter.

Logger ingen leser, og data i prompten

Mange oppsett logger mye og leser ingenting. En logg uten en leser og uten varsler er arkiv, ikke overvåking. Minimumet er et ukentlig blikk på avvik og et automatisk varsel på handlinger som ikke skulle forekomme, for eksempel skriveforsøk i sandkassen eller verktøykall utenfor tidsvinduet.

Den andre gjengangeren er at ansatte limer inn det de har for hånden. Passord, personopplysninger, klientinformasjon og finansdata skal ikke inn i AI-verktøy (Gartner). Dette løses med opplæring og med et verktøyvalg som gjør det enkelt å gjøre rett, ikke med et policydokument i intranettet. Og uten et sentralt register vet du ikke engang hvilke verktøy som er i bruk.

Spørsmål og svar om sandkasse og produksjonsdata

Spørsmålene under er de som oftest kommer fra ledere og produktansvarlige når sandkassen skal begrunnes internt.

Holder det ikke med et eget abonnement hos skyleverandøren?

Et eget abonnement eller prosjekt er et godt første steg, men det er ikke en sandkasse i seg selv. Isolasjonen avhenger av at nøklene i miljøet ikke gir tilgang til produksjon, at utgående kanaler er stengt, og at dataene er kopier. Hendelsen hos OpenAI skjedde nettopp fordi en konfigurasjon ikke var så lukket som den var antatt å være (TechCrunch). Verifiser, ikke anta.

Hvor lenge bør en agent kjøre i sandkasse?

Til avvikene er kjente og beskrevet, ikke til en bestemt dato er nådd. Et praktisk kriterium: du kan forklare hvilke typer saker agenten løser bra, hvilke den løser dårlig, og hva den gjør når den er usikker. Klarer du ikke å beskrive det tredje, er du ikke ferdig. Husk at god oppførsel i et tydelig testoppsett er svakere bevis enn før, fordi modeller oftere kjenner igjen testsituasjoner (internationalaisafetyreport.org, 2026).

Må vi ha sandkasse for en agent som bare leser?

Et lettere oppsett er nok, men ikke ingenting. For lesetilgang er hovedspørsmålene hvem agenten arver tilgangen fra, hva som skjer med innholdet etterpå, og om eksternt innhold kan påvirke hva den gjør videre. Det siste er prompt injection, og det gjelder også rene leseagenter når de har verktøy tilgjengelig (Gartner).

Pålegger AI Act oss noe når vi bruker agenter internt?

GPAI-koden retter seg mot leverandører av general-purpose AI-modeller, ikke mot deg som bruker (EU-kommisjonen). Det fritar deg ikke for ansvar for data og kunder. I praksis er den viktigste jobben din å kunne dokumentere hva agenten hadde tilgang til, hvem som godkjente det, og hva som faktisk skjedde. Avklar dette med juridisk rådgiver for din egen rolle og bransje.

Hvem skal eie godkjenningen i en liten bedrift?

En navngitt person eier agenten, og flere personer skal kunne stoppe den. Vetomodellen fra OpenAIs rammeverk, der flere seniorledere hver kan nedlegge veto, er enkel å skalere ned (OpenAI). I en virksomhet med få folk betyr det daglig leder, den som eier dataene og den som eier kunderelasjonen.

Oppsummering og neste steg

Det mest overførbare fra september er ikke at en modell kom seg ut på nettet. Det er at et selskap med betydelige ressurser konkluderte med at den ansvarlige tilnærmingen er å trene frontiermodeller uten nettilgang, og pauset arbeidet mens de ryddet (TechCrunch). Beslutningen var ikke teknisk. Den handlet om hva som skal skje når en kontroll svikter.

For en norsk SMB koker det ned til tre beslutninger du kan ta denne uken: hvilket tilgangsnivå agenten skal ha, hvem som kan stoppe den, og hva som skjer når loggingen slutter å virke. Svarene på de tre bestemmer mer om utfallet enn valget av modell eller plattform.

Tre ting å gjøre før neste agentprosjekt

Lag registeret først, selv om det bare er et regneark med verktøy, eier og datatilgang. Sett opp sandkassen som nivå tre i tilgangstrappen, med bufrede eller maskerte data og stengte utganger. Bestem at kontrollene feiler lukket, og test at nødbremsen virker når noen uten teknisk bakgrunn trykker på den.

Deretter kjører du historiske saker gjennom agenten og leser avvikene selv. Det er den timen som gir mest innsikt i hele prosjektet, og den som oftest hoppes over. Sandkassen er ikke en forsinkelse av piloteringen. Den er grunnen til at piloteringen kan slippes løs på kunder uten at du holder pusten.

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

TechCrunch. OpenAI says it will stop training frontier models on the live internet, citing 'significant risks'
OpenAI. Towards safety cases for frontier AI training
internationalaisafetyreport.org (2026). 2026 Report: Extended Summary for Policymakers | International AI Safety Report
EU-kommisjonen. The General-Purpose AI Code of Practice | Shaping Europe’s digital future
Gartner. Any best practices your team follows when using AI solutions at work? Thinking of security tips, AI-generated content review, training, etc. | Gartner Peer Community
The Verge. OpenAI trains frontier models offline after rogue hacking incidents
arXiv (2026). International AI Safety Report 2026