AIHafsteinn Runarsson · AI Konsulent16 Oct 2026 · 12 min

AI red teaming: slik tester dere KI-systemer før lansering

AI red teaming er en strukturert måte å angripe et KI-system på før noen andre gjør det. Et testteam prøver å få modellen, applikasjonen eller en KI-agent til å lekke data, følge skjulte instruksjoner, omgå sikkerhetsregler eller utføre handlinger den ikke skal. Funnene brukes til å forbedre systemet og teste at tiltakene faktisk virker.

En god test dekker mer enn selve språkmodellen. Den undersøker hele løsningen: systemprompt, datakilder, RAG-søk, integrasjoner, verktøy, tilgangsstyring, logging og menneskelige rutiner. Derfor bør AI red teaming inngå i utviklingsløpet, ikke være en engangstest rett før lansering.

Hva er AI red teaming?

AI red teaming er adversarial testing av KI-systemer. Testerne opptrer som en motstander og leter målrettet etter uønsket oppførsel, sikkerhetshull og realistiske misbruksmåter. Målet er å finne ut hva systemet gjør under press, ikke bare om det svarer riktig på vanlige spørsmål.

Begrepet kommer fra sikkerhetsarbeid der et rødt lag angriper og et blått lag forsvarer. I KI-prosjekter er rollene ofte slik:

• Rødt lag utformer angrep, misbruksscenarier og uventede input.
• Blått lag bygger kontroller, oppdager hendelser og retter svakheter.
• Et lilla samarbeid lar lagene dele funn mens testen pågår, slik at læringen raskere blir omsatt til bedre forsvar.

Red teaming er heller ikke det samme som vanlig kvalitetssikring. En funksjonell test spør om løsningen gjør det den skal. En adversarial test spør hva som skjer når noen manipulerer konteksten, kombinerer flere svake punkter eller bruker funksjonen på en måte teamet ikke planla for.

Hva bør dere teste?

Et KI-system bør testes som en helhet. En trygg modell kan fortsatt bli del av en utrygg applikasjon dersom integrasjonene gir den for mye tilgang eller behandler modellens svar som pålitelige kommandoer.

Kartlegg minst disse delene av angrepsflaten:

• Input og systeminstruksjoner: Kan en bruker overstyre regler, skjule instruksjoner eller få frem innhold som skulle vært blokkert?
• Modell og svar: Kan modellen produsere skadelig, diskriminerende, uriktig eller sensitivt innhold?
• RAG og datakilder: Kan dokumenter, nettsider eller databaser inneholde indirekte instruksjoner som modellen følger? Kan søket hente data brukeren ikke skal se?
• Verktøy og integrasjoner: Kan systemet sende e-post, endre data, kjøre kode eller kalle et API uten riktig godkjenning?
• Identitet og tilgang: Arver KI-agenten flere rettigheter enn brukeren? Blir tilgang kontrollert på nytt når en handling utføres?
• Logger og overvåking: Kan teamet se hvilket input, hvilken kontekst og hvilke verktøykall som førte til et avvik?
• Driftsrutiner: Hvem stopper en farlig arbeidsflyt, håndterer et funn og godkjenner at systemet kan åpnes igjen?

Denne avgrensningen hindrer at testen ender som en samling kreative prompts mot en isolert chatbot. De største konsekvensene oppstår ofte i overgangen mellom modellen og systemene rundt.

Vanlige angrep og feilmoduser

OWASP Top 10 for LLM- og generative KI-applikasjoner er et nyttig utgangspunkt for testkatalogen. Listen omfatter blant annet prompt injection, lekkasje av sensitiv informasjon, forgiftning av data eller modeller, feil behandling av modelloutput og overdreven handlefrihet.

Prompt injection

Prompt injection forsøker å få systemet til å følge angriperens instruksjoner i stedet for de tiltenkte reglene. Angrepet kan være direkte, for eksempel en melding fra brukeren, eller indirekte gjennom innhold modellen leser fra en nettside, e-post eller dokumentbase.

Test både tydelige og skjulte instruksjoner. Varier språk, formatering, filtyper og flertrinnssamtaler. For RAG-løsninger bør dere også teste om et manipulert dokument kan påvirke senere brukere.

Jailbreaking

Jailbreaking prøver å omgå modellens sikkerhetsgrenser. Testeren kan bruke rollespill, kodet tekst, gradvis opptrapping eller lange samtaler for å få et svar som ellers ville blitt avvist. En blokkering i første forsøk er derfor ikke nok til å konkludere med at kontrollen virker.

Lekkasjer av data og instruksjoner

Forsøk å hente ut personopplysninger, bedriftshemmeligheter, interne dokumenter, systemprompter og informasjon fra andre brukeres økter. Test også om modellen kan gjette eller rekonstruere sensitiv kontekst gjennom mange tilsynelatende uskyldige spørsmål.

Usikre verktøykall og overdreven handlefrihet

En KI-agent kan gjøre mer skade enn en chatbot fordi den kan handle. Prøv å få agenten til å utføre en oppgave uten godkjenning, bruke feil identitet, endre omfang underveis eller tolke innhold fra en ekstern kilde som en kommando. Kontroller at hver sensitiv handling har tydelige grenser, minst mulige rettigheter og en separat autorisasjon.

Utrygg behandling av modelloutput

Modellens svar er input til neste del av systemet. Dersom applikasjonen sender svaret direkte til en nettleser, database, kodekjører eller et skall, kan et manipulert svar utløse et vanlig applikasjonsangrep. Test derfor både hva modellen sier og hvordan resten av løsningen bruker svaret.

Forgiftning og leverandørkjede

Data, finjusterte modeller, eksterne komponenter og evalueringssett kan manipuleres før de når produksjon. Test hvor innholdet kommer fra, hvem som kan endre det, og om teamet kan oppdage uventede endringer i oppførsel etter en oppdatering.

AI red teaming og penetrasjonstesting er ikke det samme

Begge metodene bruker en angripers perspektiv, men de dekker ulike feil.

• Penetrasjonstesting undersøker vanligvis nettverk, applikasjoner, API-er, konfigurasjon, identitet og infrastruktur. Resultatet er ofte et teknisk sikkerhetshull som kan reproduseres på samme måte.
• AI red teaming undersøker i tillegg modelloppførsel, prompt injection, uønsket innhold, datalekkasje, skjevheter, verktøybruk og misbruk som oppstår i samspillet mellom modell og applikasjon.
• En samlet test er nødvendig når KI-systemet har vanlige webgrensesnitt, API-er og skyløsninger. AI red teaming erstatter ikke penetrasjonstesting, og en penetrasjonstest dekker ikke alle KI-spesifikke feilmoduser.

Grensen er heller ikke alltid skarp. Et prompt injection-angrep kan for eksempel bli inngangen til et usikkert API-kall. Testplanen bør derfor følge hele angrepskjeden framfor å plassere hvert funn i én faglig silo.

Slik gjennomfører dere AI red teaming

En nyttig test starter med klare beslutninger om mål, rammer og risiko. Deretter utfører teamet angrep i et kontrollert miljø, prioriterer funn og kjører de samme testene på nytt etter retting.

1. Avklar mål og stoppregler

Beskriv hva dere vil lære. Skal testen undersøke datalekkasje, skadelig innhold, feil bruk av verktøy eller alle tre? Definer hvilke systemer, modeller, brukertyper og datakilder som er innenfor omfanget.

Avtal også stoppregler før testen begynner. De bør si når en test må avbrytes, hvem som kontaktes ved et alvorlig funn, og hvilke handlinger testerne aldri skal utføre. Dette er særlig viktig når agenten kan kommunisere med eksterne systemer.

2. Lag en trusselmodell

Tegn systemet fra brukerens input til endelig handling. Marker tillitsgrenser, datalagre, eksterne kilder, modeller, integrasjoner og godkjenningspunkter. Beskriv deretter mulige angripere, hva de ønsker å oppnå og hvilken tilgang de kan ha.

MITRE ATLAS kan brukes til å strukturere kjente taktikker og teknikker mot KI-systemer. Poenget er ikke å kopiere en lang sjekkliste, men å knytte realistiske angrep til deres egen arkitektur.

3. Bygg et isolert testmiljø

Ikke start med aggressive tester mot produksjon. Bruk representative modeller og konfigurasjoner, men syntetiske eller anonymiserte data. Deaktiver eller simuler irreversible handlinger som betalinger, sletting og utsending til virkelige mottakere.

Miljøet bør logge hele hendelsesforløpet: brukerinput, systemprompt, hentet kontekst, modellversjon, svar, verktøykall, autorisasjonsbeslutninger og sluttresultat. Uten denne sporingen blir det vanskelig å reprodusere funn og kontrollere at en retting virker.

4. Lag testscenarier med forventet resultat

Hvert scenario bør beskrive:

• angriperens mål og forutsetninger
• inngangen til systemet
• stegene i angrepet
• hvilken kontroll som forventes å stoppe det
• hva som teller som bestått eller feilet
• hvilken dokumentasjon som må lagres

Ta med enkle enkelttester og lengre angrepskjeder. Test på relevante språk og med de filtypene, dokumentene og integrasjonene som faktisk brukes.

5. Kombiner mennesker og automatisering

Automatiserte tester kan kjøre mange varianter, finne regresjoner og gjenta samme kampanje etter hver endring. Mennesker er bedre til å endre strategi, forstå forretningskontekst og oppdage kombinasjoner verktøyet ikke er programmert for.

Microsoft PyRIT er et åpent rammeverk for automatiserte red team-arbeidsflyter mot generative KI-systemer. Bruk slike verktøy som testmotorer, ikke som bevis på at løsningen er sikker. Resultatene må vurderes mot den konkrete arkitekturen og risikoen.

6. Vurder konsekvens og reproduksjon

Et funn bør beskrive mer enn den vellykkede prompten. Registrer hvilken tilgang angriperen trengte, hvor ofte feilen lot seg gjenta, hvilke data eller handlinger som ble berørt, og om eksisterende overvåking oppdaget hendelsen.

Prioriter funn etter mulig konsekvens og sannsynlighet i den faktiske løsningen. En dramatisk modellrespons uten praktisk virkning kan være mindre alvorlig enn en stille tilgangsfeil som lar en vanlig bruker hente ett dokument for mye.

7. Rett årsaken og test på nytt

En ekstra tekstregel i systemprompten er sjelden et tilstrekkelig tiltak alene. Bedre kontroller kan være strengere tilgangsstyring, validering av input og output, isolering av verktøy, begrensede handlinger, menneskelig godkjenning eller endret arkitektur.

Kjør det opprinnelige angrepet på nytt etter retting. Legg deretter scenarioet i en fast regresjonspakke, slik at neste modell-, prompt- eller integrasjonsendring ikke åpner samme svakhet igjen.

Manuell eller automatisert red teaming?

Den beste dekningen kommer vanligvis fra en kombinasjon.

• Manuell testing passer når systemet er nytt, risikoen er uklar eller angrepet krever domeneinnsikt og kreativ tilpasning.
• Automatisert testing passer for brede promptsett, kjente feilmoduser, flere modellversjoner og gjentatte kontroller i utviklingsløpet.
• Kontinuerlig testing passer når modeller, data, verktøy eller systemprompter endres ofte.

Automatisering kan også skape støy. En test kan merke et svar som farlig uten å forstå konteksten, eller overse en skade som først oppstår når flere handlinger kombineres. Hold derfor et menneske ansvarlig for omfang, tolkning og prioritering.

Hva bør dere måle?

Målingene skal hjelpe teamet å ta en beslutning, ikke bare fylle en rapport. Følg blant annet med på:

• hvilke scenarier som lykkes, og under hvilke forutsetninger
• alvorlighetsgrad og berørte data, brukere eller handlinger
• hvor ofte samme angrep kan gjentas
• om overvåkingen oppdager og forklarer hendelsen
• tid fra funn til retting og ny test
• om en endring lukker én feil uten å åpne en annen
• dekning på tvers av språk, roller, integrasjoner og modellversjoner

Behold også mislykkede angrep. De dokumenterer hvilke kontroller som virket og gir et sammenligningsgrunnlag ved neste endring.

Rammeverk som støtter arbeidet

Rammeverk gir et felles språk, men de erstatter ikke en testplan for deres system.

• OWASP Top 10 for LLM- og generative KI-applikasjoner samler sentrale tekniske risikokategorier.
• NIST AI Risk Management Framework beskriver frivillig risikostyring gjennom design, utvikling, bruk og evaluering av KI-systemer.
• MITRE ATLAS katalogiserer taktikker og teknikker som kan brukes i trusselmodellering og testdesign.
• EUs KI-forordning stiller krav til blant annet nøyaktighet, robusthet og cybersikkerhet for høyrisikosystemer. Juridiske plikter må vurderes for den konkrete rollen og bruken deres.

Start med risikoen i løsningen. Bruk deretter rammeverkene til å kontrollere at dere ikke har glemt viktige kategorier og til å dokumentere hvorfor testene ble valgt.

Når bør testen kjøres?

AI red teaming bør gjennomføres før en løsning får tilgang til virkelige data eller handlinger, og gjentas når risikobildet endres. Aktuelle utløsere er:

• før pilot og produksjonssetting
• etter bytte av modell eller leverandør
• etter endring i systemprompt, RAG-kilder eller tilgangsregler
• når agenten får et nytt verktøy eller større fullmakter
• etter en sikkerhetshendelse eller et alvorlig avvik
• som en fast regresjonstest i utviklingsløpet

Hvor ofte dere trenger en større manuell kampanje, avhenger av konsekvensen ved feil og hvor raskt systemet endres. En stabil intern søkeløsning og en agent som kan godkjenne betalinger bør ikke ha samme testplan.

En praktisk start for et lite team

Et lite team kan begynne uten å bygge et eget sikkerhetslaboratorium.

1. Velg én viktig arbeidsflyt og tegn hele data- og handlingskjeden.
2. Definer fem til ti realistiske misbruksscenarier basert på tilgang, data og verktøy.
3. Kjør testene i et isolert miljø med full logging.
4. Dokumenter det mest alvorlige funnet med trinn, konsekvens og foreslått kontroll.
5. Rett årsaken, kjør testen på nytt og legg scenarioet i regresjonspakken.
6. Utvid katalogen når systemet får nye datakilder, modeller eller handlinger.

Denne starten gir et faktisk sikkerhetsløp. En lang liste med tilfeldige jailbreak-prompts gjør ikke det.

Vanlige feil

Dere tester bare modellen

Da overser dere tilgangsfeil, RAG-data, API-er og verktøykall. Test hele arbeidsflyten fra input til konsekvens.

Dere bruker produksjonsdata i aggressive tester

Et realistisk miljø trenger ikke virkelige personopplysninger eller irreversible handlinger. Bruk syntetiske data og simuler eksterne effekter.

Dere kjøper et verktøy før omfanget er kjent

Et verktøy kan skalere tester, men kan ikke bestemme hva som er kritisk for virksomheten. Lag trusselmodellen og stoppreglene først.

Funn mangler eier

Et funn uten ansvarlig person, frist og ny test blir fort en rapport ingen følger opp. Koble hvert alvorlig avvik til et konkret tiltak og en verifisering.

Testen skjer én gang

Modeller, data og integrasjoner endres. En bestått kampanje sier lite om neste versjon dersom testene ikke kan gjentas.

Er AI red teaming det samme som penetrasjonstesting?

Nei. Penetrasjonstesting leter primært etter svakheter i applikasjoner, nettverk, identitet og infrastruktur. AI red teaming dekker i tillegg modelloppførsel, prompt injection, datalekkasje, uønsket innhold og usikker bruk av verktøy. KI-løsninger trenger ofte begge deler.

Kan AI red teaming automatiseres?

Deler av arbeidet kan automatiseres. Verktøy kan generere angrepsvarianter, kjøre kampanjer og oppdage regresjoner. Mennesker må fortsatt definere risikoen, lage realistiske angrepskjeder og vurdere konsekvensen av funnene.

Hvor ofte bør et KI-system red team-testes?

Test før produksjonssetting og etter vesentlige endringer i modell, prompt, data, integrasjoner eller fullmakter. Kjør kjente scenarier som regresjonstester oftere. Intervallene bør følge konsekvensen ved feil og endringstakten i systemet.

Gjelder AI red teaming også KI-agenter?

Ja. Agenter trenger særlig testing av verktøykall, identitet, delegering, godkjenninger og indirekte prompt injection fra innhold de leser. Testen må følge hele handlingskjeden, ikke stoppe ved modellens tekstsvar.

Hvem bør delta i testen?

Sett sammen personer som kjenner sikkerhet, KI, applikasjonen og fagområdet den brukes i. Produkteier og drift bør delta i prioriteringen, mens juridisk eller personvernfaglig kompetanse bør kobles inn når funn berører regulerte data eller beslutninger.

Fra test til tryggere produksjon

AI red teaming gir verdi når funnene endrer arkitektur, tilganger, overvåking og arbeidsmåter. Start med én avgrenset arbeidsflyt, test den som en motstander og behold scenarioene som regresjonstester.

Skal dere sette et KI-system eller en agent i produksjon, kan dere ta kontakt med Daia for å avgrense risiko, testomfang og nødvendige sikkerhetskontroller før lansering.