KI-sikkerhet: 7 avgjørende grep etter Nadellas advarsel

En KI-assistent som skriver et førsteutkast, er én ting. En agent som kan lese kundedata, endre filer og sende informasjon videre, er noe annet. I det øyeblikket vi gir modellen verktøy, blir kvaliteten på svaret bare en del av spørsmålet. Vi må også vite hva systemet har lov til å gjøre, hvordan handlingene kontrolleres, og hvem som kan stoppe det.

Den 10. oktober 2026 publiserte Microsofts administrerende direktør Satya Nadella essayet «Models as Insider Risks in the Super Intelligence Era». Hovedpoenget hans er at sikkerhetskontroller må ligge utenfor modellen. Det er en nyttig retning for debatten om KI-sikkerhet.

Samtidig kommer budskapet få dager etter en rekke Microsoft-annonseringer om nettopp kontroll, agentadministrasjon og lokal KI. Det gir grunn til å lese teksten med både teknisk interesse og kommersiell skepsis. For en norsk bedrift er det viktigste hva prinsippene betyr i praksis: Hvordan bruker vi teknologien uten å gi den større myndighet enn oppgaven krever?

Denne guiden skiller mellom de dokumenterte utspillene, vår vurdering av dem og konkrete forslag til sikrere arbeidsflyter. De praktiske eksemplene er tenkte situasjoner, ikke beskrivelser av hendelser hos Kodemagisks kunder.

KI-sikkerhet

KI-sikkerhet handler her om å holde en assistent eller agent innenfor et tydelig mandat. Systemet skal kunne hjelpe med oppgaven, men tilgangen til data, verktøy og handlinger må være begrenset og etterprøvbar. Et godt svar er verdifullt. Et godt svar fra et system med unødvendig vide rettigheter kan likevel være en dårlig løsning.

Dette er særlig relevant når en bedrift går fra å spørre en chatbot om råd til å koble KI direkte til egne systemer. En tekstassistent kan foreslå et kundesvar. En agent med e-posttilgang kan sende det. En assistent kan forklare en kodeendring. En agent med produksjonstilgang kan gjennomføre den. Forskjellen ligger i konsekvensene av en feil.

Sikkerhet bør derfor vurderes sammen med nytten. Spør hva oppgaven faktisk krever, og hva som kan skje dersom en misforståelse blir til en handling. Et forslag til bloggoverskrift trenger en annen arbeidsflyt enn endring av betalingsinformasjon. Begge kan bruke språkmodeller, men det er liten grunn til å gi dem samme fullmakter.

Vi anbefaler å begynne med et enkelt kart: hvilke opplysninger systemet kan lese, hvilke forslag det kan lage, og hvilke handlinger det kan utføre. Kartet bør være forståelig for både den som bestiller løsningen og den som bygger den. Hvis beskrivelsen bare sier at agenten «har tilgang til bedriftens verktøy», er mandatet for uklart til å kunne vurderes ordentlig.

Hvorfor en språkmodell krever andre kontroller

Det er fristende å si at vanlig programvare er forståelig, mens KI er en svart boks. Forskjellen er mer nyansert. Også tradisjonell programvare kan være komplisert, ha mange avhengigheter og være vanskelig å feilsøke. Likevel kan en utvikler ofte undersøke konkrete regler, tilstandsendringer og kjøringen som førte til et resultat.

Et generert svar gir ikke i seg selv tilsvarende innsyn i hvorfor modellen valgte akkurat den formuleringen eller handlingen. En velformulert forklaring fra agenten bør derfor ikke brukes som eneste bevis på at oppgaven ble løst riktig. Kontroller resultatet mot kilder, forventninger og den faktiske tilstanden i systemene den brukte.

Tenk på en agent som sier at den bare endret en produktbeskrivelse. Det avgjørende er hvilke felter innholdssystemet faktisk registrerte som endret. En forklaring kan hjelpe redaktøren å forstå forslaget. Endringshistorikken gir et annet og mer konkret grunnlag for kontroll. Når begge er tilgjengelige, blir det lettere å oppdage et avvik før kunden ser det.

Poenget er praktisk: Bygg kontrollene rundt observerbare handlinger og tydelige rettigheter. Bedriften trenger ikke å forstå alle detaljene i en språkmodell for å kreve at publisering, tilgangsendringer og andre viktige operasjoner følger egne regler.

Hva Nadella faktisk ber om

Nadella foreslår å behandle modellen som en mulig intern risiko: Den har tilgang og kapasitet, men bør ikke være sin egen kontrollinstans. Essayet beskriver modellmangfold, lesbare og manipulasjonssikre spor, løpende verifikasjon, uavhengige kontroller og revisjon, isolasjon og åpenhet om hendelser. Han omtaler også menneskelig ansvar og muligheten for at en autorisert person stanser systemet underveis. Les originalessayet på X.

Dette er et argument for kontroller rundt modellen. Å planlegge for at en modell kan være kompromittert er en sikkerhetsantakelse, ikke bevis på et faktisk angrep.

Mot slutten skriver han:

It will be the one that enables us to trust the model the least.

Et robust system bør altså være minst mulig avhengig av modellen. Kilde: Nadella.

Microsofts verktøy: hva er tilgjengelig nå?

Microsoft publiserte flere relevante annonseringer 7. oktober 2026. De dekker ulike deler av agentarbeid, og de har forskjellig status. Tabellen viser produsentens beskrivelser slik de forelå ved gjennomgangen 12. oktober. Den er ikke en uavhengig test av produktene.

Statusene er hentet fra Microsofts tekniske MXC-annonsering, Windows-annonsering og Surface-annonsering.

MXC setter grenser, men konfigurasjonen avgjør

Microsoft beskriver MXC som et lag som håndhever tilgangspolicy utenfor agentens egen kontroll. Løsningen kan avgrense blant annet filer og nettverk. Dokumentasjonen skiller mellom flere isolasjonsformer og driftsmoduser. En viktig detalj er at «Permissive» registrerer tilgang som policyen ellers ville avvist, men lar operasjonen fortsette. «Learning» blokkerer og registrerer. «Enforcement» håndhever grensene uten denne aktivitetsrapporten. Kilde: Windows Developer Blog.

Vår vurdering: En bedrift bør få demonstrert den faktiske konfigurasjonen. Et produktnavn eller en aktivert rapport forteller ikke alene om uønsket tilgang blir stoppet. Be leverandøren prøve en operasjon agenten ikke skal kunne gjennomføre, og vis resultatet i målsystemet. Suppler avgrensningen med egen logging av viktige handlinger. Det gir et konkret svar på hva oppsettet beskytter, og hva som fortsatt krever andre tiltak.

HydraFusion ruter oppgaver; det beviser ikke sikkerhet

Microsoft og GitHub beskriver HydraFusion som en orkestrator som kan velge én eller flere modeller ut fra ytelse, kostnad og forsinkelse. Windows-utvidelsen skal også kunne bruke lokale modeller; den var varslet i eksperimentell preview senere i oktober. Kilder: den tekniske forklaringen og Windows-annonseringen.

Vår vurdering: Denne typen ruting kan være nyttig, men bør vurderes separat fra kontroll av en viktig beslutning. At et system kan bruke flere modeller, forteller ikke hvem som kontrollerer resultatet, hvilke data kontrollen bygger på, eller om utførelsen kan blokkeres. Når en leverandør bruker ord som «multimodell» i et sikkerhetsargument, be om en forklaring av den konkrete arbeidsflyten og feiltilfellene den skal håndtere.

Surface Laptop Ultra: lokal kapasitet er én del av bildet

Microsoft oppgir en veiledende startpris på 2 599 amerikanske dollar og opptil 128 GB fellesminne, avhengig av konfigurasjon. Forhåndsbestilling åpnet 7. oktober, med tilgjengelighet fra 16. oktober. Maksimalt minne er dermed ikke det samme som hva startprisen inkluderer. Kilde: Microsoft Devices Blog.

Vår vurdering: Lokal modellkjøring kan være interessant når en bedrift vil styre hvor behandlingen foregår. Men en lokal agent trenger fortsatt et tydelig mandat. Hvis arbeidsflyten sender data gjennom andre verktøy, eller har tilgang til mapper den ikke trenger, løser ikke plasseringen alene problemet. Vurder dataflyten fra start til slutt før dere kjøper maskinvare for å oppnå kontroll. Dette er et arkitekturspørsmål like mye som et kapasitetsspørsmål.

Når sikkerhetsbudskapet også støtter en forretning

Det er rimelig å se en kommersiell sammenheng mellom Microsofts nye verktøy og Nadellas sikkerhetsbudskap. Kontroll, agentidentitet, modellorkestrering og lokal kapasitet er både tekniske behov og områder selskapet vil selge løsninger innenfor. Det er vår redaksjonelle tolkning av tidspunktet og innholdet i de dokumenterte utspillene.

Essayet navngir ikke produktene. Vi har derfor ikke grunnlag for å fremstille det som et bevist, skjult salgskatalogprosjekt. Den sterkere kritikken er også mer nyttig: Gode sikkerhetsprinsipper må kunne vurderes uavhengig av leverandøren som presenterer dem. En bedrift bør kunne etterspørre de samme kontrollene hos Microsoft, andre plattformer eller en egen løsning.

Det krever spørsmål som kan besvares med en demonstrasjon. Kan dere stoppe en kjøring uten å vente på at agenten følger en instruks? Hvem kan endre rettighetene? Hvilke handlinger blir registrert? Hva skjer hvis modellen finner en tekst som oppfordrer den til å overskride oppgaven? Hvilke deler av oppsettet fortsetter å virke hvis dere bytter modell?

Det er også verdt å undersøke hvem som kontrollerer leverandørens egne påstander. En selger kan vise et godt eksempel, og en utvikler kan forklare en gjennomtenkt design. Begge deler er nyttig. Før systemet får større fullmakter, bør bedriften likevel be om prøver som utfordrer løsningen, og be en person uten ansvar for salget vurdere funnene.

Kommersiell interesse gjør ikke et sikkerhetsråd feil. Den gjør det nødvendig å skille rådet fra kjøpsbeslutningen. Start med risikoen dere vil redusere. Formuler et målbart krav. Sammenlign deretter hvordan mulige løsninger oppfyller kravet. På den måten blir innkjøpet styrt av behovet, og en oppsiktsvekkende produktlansering får ikke definere hele problemet på forhånd.

Amodei løfter en annen del av samme debatt

Lenken til Dario Amodeis «We Must Pace the Frontier», datert september 2026, leder til et annet essay enn Nadellas. Amodei foreslår eksterne evaluatorer med løpende innsyn, koordinering mellom demokratiske land og selskaper og et videre forsøk på global koordinering. Han argumenterer for at utviklingstempoet må gi sikkerhetsarbeidet tid til å holde følge.

Vår vurdering er at disse perspektivene kan utfylle hverandre. Ett spørsmål gjelder kontrollene rundt en agent som brukes i dag. Et annet gjelder hvordan de største modellene utvikles og granskes. Norske bedrifter har begrenset innflytelse på det siste, men de kan stille konkrete krav til løsningene de tar i bruk.

Det er derfor liten grunn til å vente på enighet om hele KI-industriens retning før dere avklarer hvem som kan publisere fra innholdssystemet, hvilke kundedata en assistent får lese, eller hvordan en automatisering stoppes. Disse valgene er innenfor bedriftens eget handlingsrom. De følgende grepene er vårt forslag til hvordan arbeidet kan begynne.

Minste tilgang: start med oppgaven

OWASP beskriver «Excessive Agency» som risiko knyttet til for stor funksjonalitet, for vide rettigheter og for mye autonomi. Prosjektet anbefaler blant annet at viktige handlinger godkjennes av mennesker, og at tilganger håndheves i systemene agenten bruker. Anbefalingene nedenfor konkretiserer disse kontrollbehovene med våre egne, hypotetiske arbeidsflyter.

Gi en KI-agent bare tilgangen den trenger for en bestemt oppgave. Det begrenser hva som kan gå galt når agenten misforstår en beskjed, bruker feil informasjon eller blir påvirket av innhold den leser. En god beskrivelse av ønsket oppførsel er nyttig, men tilgangsreglene må håndheves av systemet rundt modellen.

Begynn med et enkelt spørsmål: Hva skal agenten faktisk gjøre? Å oppsummere en bestilling krever en annen tilgang enn å endre leveringsadressen. Å skrive et forslag til et blogginnlegg krever en annen tilgang enn å publisere det. Hvis alle oppgavene får samme brede adgang, mister virksomheten muligheten til å kontrollere konsekvensene hver for seg.

Tenk deg en nettbutikk som prøver en agent til kundeservice. Dette er et hypotetisk eksempel. Agenten skal finne status på en ordre og foreslå et svar til kunden. Da trenger den kanskje ordrenummer, leveringsstatus og relevante produktopplysninger. Den trenger ikke hele kunderegisteret, betalingsinformasjon eller muligheten til å opprette refusjoner. Et avgrenset verktøy som henter én bestemt ordre, gir en tydeligere grense enn generell tilgang til databasen.

Avklar også hvilke kunder, dokumenter og arbeidsområder agenten får bruke. Tilgang til én kundes sak skal ikke automatisk gi tilgang til alle andre saker. Systemet må kontrollere brukerens rettigheter hver gang agenten ber om opplysninger. Modellen bør ikke få bestemme hvem en forespørsel tilhører eller hvilke rettigheter forespørselen gir.

Denne delen av KI-sikkerhet handler ofte om å gjøre eksisterende tilgangsstyring mer presis. Skriv ned tillatte handlinger, forventet databehov og handlinger som krever et menneske. Da får både utviklere og virksomhetens ansvarlige et konkret grunnlag for å vurdere om tilgangen er passende.

Skill mellom lesing, forslag og handling

Del arbeidsflyten i trinn med ulike rettigheter. Agenten kan først lese utvalgte opplysninger, deretter lage et forslag og til slutt be et eget system om å utføre en godkjent handling. Ikke la et vellykket lesetrinn automatisk åpne døren til publisering, betaling eller endring av kundedata.

Lesetilgang er heller ikke risikofritt. Opplysninger kan bli sendt videre hvis agenten samtidig kan bruke eksterne tjenester, sende meldinger eller åpne vilkårlige nettadresser. Se derfor tilgang til informasjon og muligheten til å sende informasjon ut i sammenheng. En agent som skal lage interne sammendrag, trenger sjelden fri adgang til å sende innhold til eksterne mottakere.

For en utvikler kan dette bety å lage små verktøy med tydelige parametere. Et verktøy for å foreslå en refusjon kan returnere beløp og begrunnelse uten å flytte penger. Et annet verktøy kan gjennomføre refusjonen etter at nødvendige kontroller er bestått. Kontroller beløpsgrenser, mottaker og ordretilknytning i vanlig programkode, også når modellen leverer et overbevisende forslag.

Gjør overgangene synlige for brukeren. Et forslag som lagres som utkast, bør fremstå som et utkast. En knapp som godkjenner en utsendelse, bør vise hva som sendes og til hvem. Hvis brukeren tror at agenten bare skriver tekst, mens den i praksis også endrer systemet, er arbeidsflyten vanskelig å kontrollere.

Velg graden av automatikk etter konsekvensene. En avgrenset kategorisering kan ofte utføres automatisk når feil er enkle å oppdage og rette. En handling som påvirker penger, tilgang eller kundens rettigheter, trenger sterkere kontroller. Målet er en tydelig forbindelse mellom oppgaven, tillatelsen og konsekvensen.

Isolasjon som begrenser skade

Kjør agenten i et avgrenset miljø med kontrollerte forbindelser til resten av virksomheten. Da blir det lettere å begrense konsekvensene av feil og å stanse en oppgave uten å forstyrre alt annet. Isolasjon bør dekke både arbeidsområdet, verktøyene, nettverkstilgangen og opplysningene agenten kan bruke.

Et separat miljø hjelper lite hvis agenten samtidig får nøkler med omfattende tilgang til produksjonssystemene. Se derfor på hele kjeden. Hvilke filer er tilgjengelige? Hvilke tjenester kan agenten kontakte? Hvilke handlinger kan verktøyene utføre? Hvor lenge varer tilgangen? Grensene må gjelde i praksis, også når modellen ber om noe annet.

Tenk deg en kodeagent som skal rette en feil på en nettside. I dette hypotetiske eksemplet får den arbeide i en egen kopi av prosjektet, lese relevante filer og kjøre avtalte kontroller. Den får ikke produksjonsnøkler eller adgang til å sette endringene i drift. Resultatet er en endring som utvikleren kan inspisere og prøve før den påvirker kunder.

Et publiseringssystem kan bruke samme prinsipp. En innholdsagent kan skrive til et bestemt utkast og laste opp et bilde, mens publisering ligger bak en separat tillatelse. Begrensningen bør finnes i verktøyet eller publiseringsplattformen. En beskjed om å huske å unngå publisering er ikke en teknisk tilgangsgrense.

Avgrens også tiden og ressursene agenten får bruke. Sett grenser for oppgavens varighet, antall verktøykall og kostnad der det er relevant. En oppgave som går i sirkel, skal kunne stoppe på en kontrollert måte. Virksomheten trenger et forståelig resultat også når agenten ikke lykkes: hva som ble gjort, hva som gjenstår, og hvilke endringer som allerede finnes.

En nødstopp som faktisk virker

Lag en måte å stoppe agenten på som fungerer uten at modellen samarbeider. En avbrytelsesknapp i grensesnittet er nyttig, men den må være koblet til kontrollene som styrer kjøringen, tilgangen og handlingene. Ellers kan brukeren tro at arbeidet er stoppet mens en bakgrunnsoppgave fortsetter.

Bestem hva stopp betyr i den aktuelle arbeidsflyten. Skal nye verktøykall blokkeres? Skal ventende utsendelser holdes tilbake? Skal midlertidig tilgang trekkes tilbake? Skal en pågående jobb avsluttes? Ulike systemer trenger ulike mekanismer, men konsekvensen må være tydelig for den som trykker på knappen.

En nødstopp kan ikke gjøre alle tidligere handlinger ugjort. En e-post som allerede er sendt, kan normalt ikke behandles som om den aldri ble sendt. Derfor er det viktig å skille mellom å stanse videre arbeid og å rette opp det som har skjedd. Vis hvilke handlinger som er gjennomført, og hvilke som fortsatt venter.

Utpek noen som har ansvar for å bruke stoppfunksjonen og følge opp etterpå. I en liten bedrift kan det være den samme personen som har ansvar for kundeservice eller nettstedet. Personen trenger en kort, tilgjengelig instruks om hvordan kjøringen stoppes, hvor hendelsesloggen finnes, og hvordan berørte oppgaver identifiseres.

Prøv stoppfunksjonen før agenten får arbeide selvstendig. Start en ufarlig testoppgave, avbryt den underveis og kontroller at nye handlinger faktisk blokkeres. Prøv også en oppgave med handlinger som ligger i kø. En nødstopp er en del av driften og må fungere når resten av arbeidsflyten er uoversiktlig.

Logger som tåler kritiske spørsmål

Registrer viktige handlinger utenfor modellens egen kontroll. En slik logg gjør det mulig å undersøke hva systemet faktisk gjorde, hvilke verktøy det brukte og hvilke godkjenninger det fikk. Agentens egen oppsummering kan hjelpe med lesbarheten, men den bør ikke være eneste dokumentasjon av hendelsesforløpet.

Start med spørsmålene dere kan få etter en feil: Hvilken oppgave var aktiv? Hvem startet den? Hvilke opplysninger ble hentet? Hvilket verktøy endret ordren? Hvem godkjente utsendelsen? Hva svarte tjenesten som mottok forespørselen? Logg strukturerte hendelser som gjør disse spørsmålene mulige å besvare.

Knytt hendelsene til en oppgave og bruk tydelige tidsstempler. Det er ofte nyttig å registrere hvilke modell- og verktøyversjoner som ble brukt, samt resultatet av tilgangskontroller. Hvis en handling ble avvist, bør det også komme frem. En serie vellykkede hendelser alene forteller lite om agenten samtidig forsøkte noe den ikke hadde lov til.

Tenk deg at en kundeserviceagent foreslår å endre leveringsadressen i en hypotetisk nettbutikk. En nyttig logg viser forespørselen, foreslått endring, kontrollen av kundens tilgang, eventuell godkjenning og resultatet fra ordresystemet. Et utsagn fra agenten om at adressen ble oppdatert, dokumenterer ikke at ordresystemet faktisk godtok endringen.

Loggene må dessuten være beskyttet mot uautoriserte endringer og sletting. Agenten som utfører oppgaven, bør ikke kunne redigere dokumentasjonen av sine egne handlinger. Velg et lagringsoppsett som gjør relevante endringer sporbare. Husk samtidig at en logg beskriver observerbare hendelser; den gir ikke nødvendigvis en sikker forklaring på modellens interne vurderinger.

Beskytt også opplysningene i loggen

Logg det som trengs for kontroll og feilsøking, og unngå å samle sensitive opplysninger uten en klar grunn. En logg kan ellers bli en ekstra samling av kundedata, interne dokumenter og hemmeligheter. Å registrere alt ukritisk kan gjøre et problem vanskeligere å håndtere.

Skill mellom dokumentasjon av en handling og full kopiering av alt innholdet. For enkelte hendelser holder det å registrere referansen til ordren, handlingstypen og resultatet. Andre undersøkelser kan kreve mer detaljer. Vurder behovet på forhånd, og bruk tilgangskontroll også for dem som kan lese loggene.

Pass særlig på verktøyparametere og feilmeldinger. De kan inneholde adgangsnøkler eller andre opplysninger som aldri bør vises i en vanlig driftslogg. Maskering bør skje før data lagres. Ikke forvent at modellen konsekvent skal gjenkjenne og fjerne alle hemmeligheter fra sin egen beskrivelse.

Definer hvem som kan lese hvilke opplysninger, og hvor lenge dere faktisk trenger dem. Kundeservice trenger kanskje en oversikt over handlingene i én sak, mens utviklere trenger tekniske feilkoder. Det betyr ikke at alle skal ha tilgang til hele samtalen eller alle dokumentene agenten brukte.

Kontroller loggene med realistiske testdata før løsningen tas i bruk. Kan dere følge en oppgave fra start til slutt? Er feilen forståelig? Finnes det opplysninger som ikke burde vært lagret? God KI-sikkerhet krever både sporbarhet og begrensning av informasjon. Loggene skal hjelpe virksomheten å undersøke en hendelse uten å skape unødvendig tilgang til mer data.

Flere modeller kan hjelpe, men deler også blindsoner

Bruk gjerne en ekstra modell som en kontroll, men vurder resultatet mot konkrete krav og eksterne kilder. To modeller som er enige, kan fortsatt ta feil. Verdien ligger i hvordan kontrollen er utformet og hvilke feil den faktisk oppdager.

En ekstra modell kan for eksempel undersøke om et svar mangler kildehenvisninger, om et forslag bryter med en oppgitt beløpsgrense, eller om en tekst inneholder påstander som krever dokumentasjon. Det er mer nyttig enn å be modellen gi en generell vurdering av om alt ser bra ut. Jo tydeligere kontrollspørsmålet er, desto lettere blir det å prøve kontrollen med kjente feil.

Modellene kan likevel dele antakelser, kunnskapshull eller sårbarhet for det samme innholdet. Hvis begge får et dokument med en skjult instruks, kan begge påvirkes. Hvis begge vurderer feil ordredata, løser ikke enighet problemet. Flere modeller gir derfor ingen automatisk garanti for uavhengighet.

I et hypotetisk innholdssystem kan én modell skrive en artikkel og en annen markere udokumenterte faktapåstander. Det kan hjelpe redaktøren å finne steder som trenger kontroll. Redaktøren må fortsatt åpne de relevante kildene og undersøke hva de faktisk sier. En kontrollmodell som selv finner på en kilde, kan ellers gjøre teksten mer overbevisende uten å gjøre den riktigere.

Bruk vanlige systemkontroller når kravet kan uttrykkes presist. Beløpsgrenser, tillatte mottakere, obligatoriske felter og tilgangsregler kan ofte kontrolleres direkte. Da kan modeller brukes til oppgaver som krever språklig vurdering, mens klare grenser håndheves på en forutsigbar måte. Kombinasjonen bør velges ut fra risikoen og kostnaden i den konkrete arbeidsflyten.

Menneskelig godkjenning må være konkret

Gi personen som godkjenner, nok informasjon til å forstå handlingen og konsekvensen. En godkjenning av en uklar plan er et svakt kontrollpunkt. Det samme gjelder en knapp som sier fortsett, mens det er vanskelig å se hva agenten vil gjøre videre.

Vis den konkrete handlingen: mottaker, innhold, beløp, dokument eller endring. Ved kodeendringer bør utvikleren kunne inspisere forskjellen og se relevante testresultater. Ved publisering bør redaktøren få se teksten, bildet, kildene og siden som skal oppdateres. Ikke legg hele vurderingsbyrden i en lang samtalehistorikk.

Godkjenningen må være knyttet til det forslaget personen faktisk så. Hvis agenten endrer mottaker eller innhold etterpå, bør systemet kreve en ny vurdering når endringen er vesentlig. Ellers kan en tillatelse til én handling bli brukt til en annen.

Unngå samtidig å be om bekreftelse for hver ubetydelige operasjon. For mange avbrytelser kan gjøre godkjenning til en vane uten reell vurdering. Legg kontrollpunktene der en feil vil få merkbare konsekvenser, og bruk tydelige grenser for mindre handlinger som kan utføres automatisk.

Avklar også hva som skjer når ingen svarer. En tidsfrist er ikke det samme som en godkjenning. En agent som venter på tillatelse til å sende en kundemelding, bør ikke tolke stillhet som samtykke. Vis at oppgaven venter, og gi den ansvarlige en enkel måte å avvise eller endre forslaget på. Menneskelig kontroll virker best når personen har både oversikt, tid og mulighet til å gripe inn.

Test systemet gjennom hele levetiden

Test agentens faktiske arbeidsflyt før bruk og etter endringer. Modell, instruksjoner, verktøy og datakilder virker sammen, så en god språkmodell alene sier lite om hvor trygt hele systemet fungerer. En test bør kontrollere både resultatet og veien systemet tok for å komme dit.

Lag et lite sett med representative oppgaver fra virksomheten. Ta med vanlige saker, uklare beskjeder, manglende opplysninger og situasjoner der agenten må stoppe. Beskriv på forhånd hvilke handlinger som er tillatt, hva et godt resultat innebærer, og hvilke hendelser som skal finnes i loggen. Da blir vurderingen mer konkret enn at svaret virker fornuftig.

Undersøk spesielt om agenten følger tilgangsgrensene. Kan den hente en annen kundes ordre? Kan den publisere et utkast uten riktig tillatelse? Kan den sende informasjon til en mottaker som ikke er godkjent? Slike kontroller handler om systemets håndheving, ikke bare om hva agenten lover i teksten sin.

Gjenta relevante prøver når dere endrer modell, instruksjoner, verktøy eller integrasjoner. En oppdatering kan påvirke hvilken handling agenten velger og hvordan den håndterer feil. Registrer hvilke versjoner testene gjaldt, slik at et tidligere godkjent resultat ikke brukes som bevis for en annen løsning.

Følg også med under vanlig bruk. Se etter oppgaver som stopper, uventede verktøykall, avviste handlinger og tilbakemeldinger fra brukerne. Velg konkrete signaler som noen har ansvar for å følge opp. KI-sikkerhet blir en del av driften når virksomheten kan oppdage endret oppførsel og justere grensene før problemer vokser.

Prøv feilsituasjonene før kundene møter dem

Test hva som skjer når forutsetningene svikter. En tjeneste kan være utilgjengelig, et svar kan være ufullstendig, eller en handling kan bli utført selv om bekreftelsen ikke når tilbake. Agenten må håndtere slike situasjoner uten å dikte opp et vellykket resultat eller gjenta en følsom handling ukritisk.

I et hypotetisk ordresystem kan en refusjon bli gjennomført mens forespørselen får tidsavbrudd. Hvis agenten straks prøver igjen uten å undersøke status, kan den samme refusjonen bli gjennomført to ganger. Verktøyet bør være laget slik at gjentatte forespørsler om samme handling håndteres kontrollert. Test også hvordan agenten forklarer usikkerheten til den ansvarlige.

Prøv innhold som forsøker å gi agenten nye instrukser. Det kan være en e-post, en nettside eller et dokument som ber systemet overse tidligere regler eller sende opplysninger videre. Slike data må ikke automatisk få samme myndighet som virksomhetens instruksjoner. Undersøk både modellens reaksjon og om verktøyene fortsatt håndhever grensene.

Ta med manglende godkjenning, stopp underveis og oppgaver som avsluttes med delvise endringer. Kan virksomheten finne ut hva som gjenstår? Kan en person overta uten å gjenta allerede utført arbeid? Et tydelig delresultat er ofte tryggere enn at agenten prøver stadig nye veier for å fullføre.

Når en prøve avdekker en feil, behold den som en ny kontroll i testsettet. Rett den aktuelle svakheten, og prøv den berørte arbeidsflyten igjen. Målet er ikke å bevise at agenten aldri kan gjøre feil. Målet er å vite hvilke grenser som håndheves, hvordan feil oppdages, og hvem som kan ta over når automatikk ikke lenger er passende.

En praktisk start for norske bedrifter

Begynn med en oppgave dere kan beskrive og måle. «Vi skal bruke KI» er for bredt. «Vi skal få et forslag til svar på spørsmål om leveringstider, basert på godkjent informasjon» er konkret. Det gjør det enklere å velge datagrunnlag, avgrense tilgang og finne en person som faktisk kan vurdere resultatet.

En liten pilot kan bygges rundt disse sju grepene. Dette er vår praktiske prioritering, ikke en ordrett gjengivelse av Nadellas liste:

• Avklar oppgaven, dataene og minste nødvendige tilgang.
• Skill forslag fra handlinger i andre systemer.
• Isoler kjøringen og prøv at nødstopp fungerer.
• Registrer viktige handlinger uavhengig av agentens forklaring.
• Bruk kontrollmodeller der de tilfører verdi, og gi mennesker et tydelig beslutningsgrunnlag.
• Test misforståelser, manipulerte inndata og endringer i oppsettet.
• Sørg for uavhengig gjennomgang og en plan for håndtering av hendelser.

Velg gjerne en arbeidsflyt som har et naturlig stoppunkt før kunden påvirkes. Et innholdsutkast er et godt eksempel på et slikt stoppunkt. En redaktør kan se teksten, kontrollere kilder og bestemme om den skal publiseres. Systemet trenger ikke publiseringsrettigheter for å bidra til arbeidet. Den avgrensningen gjør pilotens konsekvenser lettere å forstå.

Definer også hva dere vil lære. Kanskje skal piloten avklare om assistenten finner riktig informasjon, om den ber om hjelp når grunnlaget mangler, og om fagpersonen sparer tid etter at kontrollarbeidet er regnet med. Registrer hvor det oppstår ekstraarbeid. Hvis et forslag ser raskt ut, men bruker lang tid på retting og verifikasjon, er det viktig informasjon for neste beslutning.

Det er lurt å inkludere dem som skal bruke løsningen. En utvikler kan demonstrere at en tilgangsregel fungerer, men en kundebehandler vet hvilke formuleringer som kan skape forventninger bedriften ikke kan innfri. En redaktør vet hvilke kilder som må undersøkes. En ansvarlig for drift vet hvem som faktisk kan reagere når noe stanser. Sikkerhet blir mer konkret når disse perspektivene møter samme arbeidsflyt.

Hva må være på plass før agenten får mer ansvar?

Skriv akseptkriteriene før dere vurderer utvidet tilgang. Et kriterium bør beskrive både forventet resultat og hva som skal skje når systemet ikke kan levere. «Svarene virker gode» er vanskelig å kontrollere. «Forslaget bruker godkjent leveringsinformasjon og varsler når den mangler» gir et tydeligere grunnlag.

For en hypotetisk kundeservicepilot kunne dere kreve at assistenten bare leser den aktuelle saken, at et svar ikke blir sendt uten godkjenning, og at alle forsøk på endringer utenfor mandatet blir avvist. Det må også være mulig å finne igjen hvilket forslag som ble godkjent, av hvem og på hvilket datagrunnlag. Den konkrete listen bør tilpasses oppgaven og risikoen i bedriften.

En uavhengig gjennomgang trenger et definert mandat. Be den som vurderer løsningen undersøke tilgangene, stopprutinen og konkrete prøveresultater. Gjennomgangen bør gjøre det tydelig hva som ble undersøkt, hva som ikke ble undersøkt, og hvilke antakelser vurderingen bygger på. Et ubestemt «godkjent»-stempel er mindre nyttig enn en presis beskrivelse av funn og begrensninger.

Lag dessuten en enkel hendelsesrutine før dere trenger den. Bestem hvem som kan stanse agenten, hvem som undersøker om andre systemer er berørt, og hvem som tar beslutningen om videre kjøring. Bevar relevante spor. Skill mellom å stanse nye handlinger og å rydde opp i det som allerede er utført. Hvis en melding er sendt feil, blir ikke meldingen usendt bare fordi modellen stoppes.

Ved en hendelse bør den ansvarlige samle bekreftede opplysninger: hva som ble gjort, hvilke data eller personer som kan være berørt, og hvilke tiltak som faktisk er gjennomført. Kommunikasjonen må bygge på det som er undersøkt. En agentgenerert forklaring alene er ikke et tilstrekkelig grunnlag for å friskmelde systemet. Eventuelle krav til varsling må avklares ut fra den konkrete situasjonen og relevante avtaler og regler.

Utvid mandatet ett steg om gangen. Hvis dere senere vil tillate utsending, bør dere først prøve en liten, tydelig avgrenset kategori meldinger. Ta vare på tidligere testtilfeller og kjør dem igjen etter endringen. På den måten kan dere se om den nye nytten faktisk veier opp for den nye risikoen, og om tidligere grenser fortsatt holder.

En pilot er vellykket når bedriften har bedre grunnlag for å velge. Det kan bety å utvide løsningen. Det kan også bety å beholde den som assistent, endre arbeidsflyten eller stoppe forsøket. Alle tre er fornuftige utfall dersom beslutningen bygger på observerte resultater og tydelige behov.

Ofte stilte spørsmål om KI-sikkerhet

Sier Nadella at vi ikke kan bruke KI?

Nei. Essayets retning er sterkere kontroll rundt modellene. Vår praktiske anbefaling er å vurdere bruken etter oppgave, tilgang og konsekvenser. En assistent som foreslår formuleringer, trenger ikke samme fullmakter som en agent som kan endre kundedata. Les Nadellas originaltekst.

Det er derfor bedre å stille et konkret spørsmål enn å velge mellom total tillit og total avvisning: Hva kan løsningen gjøre hvis den tar feil? Dersom svaret er at den bare lager et utkast som en person vurderer, er risikobildet annerledes enn når den selv utfører irreversible handlinger. Arbeidsflyten rundt modellen avgjør mye av hva bedriften bør kreve.

Hva betyr det å behandle en modell som en intern risiko?

Det betyr å planlegge for at en aktør med tilgang kan gjøre noe feil eller bli påvirket til å overskride mandatet. En praktisk måte å bruke tanken på er å begrense tilgangen, kontrollere viktige handlinger og sørge for at andre kan undersøke hva som skjedde. Dette trenger ikke å innebære en påstand om menneskelige hensikter hos modellen.

Tenk på en assistent som hjelper med én kundesak. Den bør få opplysningene som trengs for den saken. Den trenger ikke automatisk adgang til hele kunderegisteret. Da blir sikkerhet et spørsmål om fullmakter og konsekvenser, og bedriften kan undersøke dem uten å måtte avgjøre hva modellen «egentlig vil».

Er en ekstra modell nok til å kontrollere en viktig beslutning?

En ekstra modell kan tilføre nyttige spørsmål eller finne avvik, men antallet modeller er ikke et kvalitetsbevis. Kontrollen må bygge på relevante kilder og riktig forståelse av oppgaven. Hvis begge modellene får det samme mangelfulle grunnlaget, kan de ende med samme feil.

Vi anbefaler å bruke modeller som hjelp til kontrollarbeidet og samtidig beholde tydelige regler for handlinger med store konsekvenser. Vis den ansvarlige personen hva som skal gjøres, hvilke opplysninger forslaget bygger på, og hvilke endringer det vil føre til. En godkjenningsknapp har begrenset verdi dersom den skjuler selve beslutningsgrunnlaget.

Blir agenten trygg dersom modellen kjører lokalt?

Lokal kjøring beskriver hvor modellen behandler oppgaven. Det sier ikke alene hvilke filer, nettverk eller andre systemer agenten kan bruke. I vår vurdering må lokal kjøring derfor sees sammen med tilganger, verktøy og dataflyt.

En tenkt lokal assistent kan for eksempel ha god kontroll på modellens kjøring, men samtidig bruke et verktøy som sender et dokument til en ekstern tjeneste. Da må bedriften vurdere den overføringen separat. Start med en oversikt over hele arbeidsflyten: innhenting, modellbehandling, verktøykall, lagring og eventuelle overføringer. Plasseringen er én egenskap ved løsningen; den erstatter ikke kartleggingen.

Er Microsofts annonserte agentfunksjoner allerede tilgjengelige?

De har ulik status. Gjennomgangen vår er datert 12. oktober 2026; statusene og lenkene står i produkttabellen tidligere i artikkelen. Bruk den som utgangspunkt, og kontroller den aktuelle dokumentasjonen før dere planlegger en implementering. Produktplaner og faktisk tilgjengelighet kan endre seg.

Be dessuten om informasjon for deres konkrete oppsett. En funksjon kan være presentert i en overordnet lansering uten at den er ferdig tilgjengelig for alle plattformer, kunder eller arbeidsflyter. Det er et godt innkjøpsspørsmål å få demonstrert funksjonen dere faktisk skal bruke, og å få avklart hvilke deler av leveransen som er avhengige av kommende oppdateringer.

Hvor bør en liten bedrift begynne med KI-sikkerhet?

Velg én avgrenset oppgave, en navngitt ansvarlig og et naturlig stoppunkt før en viktig handling. Bruk et begrenset datagrunnlag. Prøv både vanlige saker og situasjoner der informasjonen er mangelfull eller motstridende. Undersøk også hva systemet gjør når det forsøker å bruke en tilgang det ikke har.

Mål resultatet etter at kontroll og retting er medregnet. En liten bedrift trenger et forståelig svar på om løsningen hjelper, hvem som følger den opp, og hvordan den stoppes. Utvid deretter bare de delene som har en tydelig begrunnelse. Det gjør både investeringen og ansvaret lettere å håndtere, og det gir mer nyttig erfaring enn et stort prosjekt med uklare fullmakter.

Konklusjon: tillit må kunne etterprøves

Nadellas utspill gir en anledning til å stille bedre spørsmål om agentene vi tar i bruk. De samme spørsmålene bør følge hele innkjøpet og implementeringen: Hvilken oppgave løser systemet? Hvilke rettigheter trenger det? Hvem kontrollerer viktige handlinger? Hvordan oppdager og stanser vi et avvik?

Det er mulig å være interessert i KI og samtidig kreve tydelige svar. En modell kan bidra med nyttige forslag selv om vi ikke gir den adgang til å utføre alle handlingene den foreslår. Slik kan bedriften hente erfaring og verdi innenfor grenser den forstår.

Det kommersielle sikkerhetsbudskapet bør vurderes med samme nøkternhet. Et produkt kan være nyttig, men verdien ligger i de kontrollene som faktisk virker i deres arbeidsflyt. Be om demonstrasjoner, dokumenter begrensningene og gi den ansvarlige personen et reelt beslutningsgrunnlag.

For Kodemagisk er den praktiske retningen tydelig: Start med behovet, bygg inn avgrensningene og utvid på grunnlag av observerte resultater. Hvis dere vurderer en KI-assistent i en nettside, kundeportal eller intern arbeidsflyt, kan en god første samtale handle om oppgaven og fullmaktene. Se hvordan vi jobber med webapplikasjoner og interne verktøy, eller ta kontakt for å diskutere behovet.