# Delt ansvar for språkmodeller: hvem sikrer hva

> Hvordan delt ansvar fra skyen gjelder for språkmodeller: modellene til Microsoft og CSA, EUs KI-forordning for leverandører og idriftsettere, og en tabell for API-bruk.

FireAI Security & Research Team (HisnLabs) · Published 2026-09-30
Canonical: https://hisnlabs.com/no/blog/delt-ansvar-for-sprakmodeller

Organisasjoner som bygger på en hostet språkmodell, får en sikkerhetstrent modell og en plattform fra leverandøren, men har fortsatt ansvaret for applikasjonen rundt den. Microsoft, Cloud Security Alliance og EUs KI-forordning fordeler hver for seg arbeidet mellom modelleverandøren og den som tar modellen i bruk, med ulik terminologi og ulik rettslig tyngde. Dette notatet sammenligner de tre og skisserer en praktisk fordeling for det vanlige tilfellet der en modell brukes gjennom et API. Det hører sammen med [How Anthropic red-teams Claude, and what it leaves to you](https://hisnlabs.com/en/blog/how-anthropic-red-teams-claude), som undersøker leverandørens side av grensen i ett publisert tilfelle.

## Bakgrunn: skymodellen, utvidet til KI

Modellen for delt ansvar i skyen tildeler hver kontroll til leverandøren eller kunden avhengig av tjenestetypen: programvare som tjeneste (SaaS), plattform som tjeneste (PaaS) eller infrastruktur som tjeneste (IaaS). Både Microsoft og Cloud Security Alliance (CSA) utvider denne tanken til generativ KI. Utvidelsen endrer terminologien mer enn logikken: Jo lenger ned i stakken en kunde bygger, desto flere kontroller eier kunden.

## Leverandørmodeller

### Microsoft: plattform, applikasjon og bruk

Microsofts modell for delt ansvar for KI beskriver en KI-basert applikasjon som tre lag: KI-plattformen, KI-applikasjonen og KI-bruken. Plattformlaget leverer modellen gjennom API-er og omfatter et sikkerhetssystem som filtrerer skadelige inndata og utdata. Applikasjonslaget er grensesnittet brukeren benytter, med forankring, plugins og datakoblinger, og det trenger sitt eget sikkerhetssystem. Brukslaget dekker hvordan mennesker bruker funksjonaliteten, og Microsoft viser til identitets- og tilgangskontroll, retningslinjer for akseptabel bruk og opplæring av brukere. [[1]](https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility-ai)

Hvor mye av hvert lag kunden eier, avhenger av distribusjonstypen. Siden oppgir at ansvaret varierer mellom SaaS, PaaS og IaaS, og anbefaler å begynne med SaaS-tilbud som Copilot, å gå over til PaaS-tjenester som Azure OpenAI Service bare når ferdige funksjoner ikke passer, og å reservere bygging av egne modeller for organisasjoner med dyp kompetanse. Siden legger til at veiledningen er illustrerende, brukes i styringsforstand og ikke endrer noen avtale med Microsoft. [[1]](https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility-ai)

### Microsoft: utvidelsen for agenter

En annen side fra Microsoft dekker agenter, som den skiller fra en ren modell fordi en agent handler uten at et menneske godkjenner hvert steg, planlegger og gjentar, har minne, har sin egen identitet og kan settes sammen med andre agenter. Den legger til tre lag: orkestrering av agenter, verktøy og handlinger, og minne og tilstand. I ansvarsmatrisen beholder kunden i PaaS-tilfellet agentens instruksjoner og omfang, tillatelser per verktøy og menneskelig godkjenning av handlinger med stor konsekvens, mens kjøremiljøet og orkestreringsplattformen tilhører Microsoft. [[2]](https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility-ai-agent)

Siden fører opp ansvar kunden alltid beholder: data, identitet og minste privilegium, autorisasjon av handlinger, menneskelig tilsyn, og akseptabel bruk og styring. Den oppgir også at autonomi aldri reduserer ansvarligheten. [[2]](https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility-ai-agent)

### Cloud Security Alliance: et forslag fra 2023

I et blogginnlegg datert 28. juli 2023 foreslo en CSA-fellow en modell med tre parter: leverandøren av KI-tjenesten, brukeren av KI-tjenesten som bygger en applikasjon, og virksomheten eller sluttbrukeren av den applikasjonen. Etter forslaget leverer en IaaS-leverandør infrastruktur og grunnmodeller, mens brukeren står for trening, datavalidering, promptfiltrering og applikasjonssikkerhet; i PaaS-tilfellet står brukeren for kontekst og applikasjonssikkerhet; i SaaS-tilfellet håndterer brukeren forankring, promptfiltrering og beskyttelse av immaterielle rettigheter. Innlegget presenterer dette som et forslag som skiller oppgaver fra hverandre, ikke som en standard. [[3]](https://cloudsecurityalliance.org/blog/2023/07/28/generative-ai-proposed-shared-responsibility-model)

## Regelverk: EUs KI-forordning fordeler plikter etter rolle

EUs KI-forordning tildeler plikter etter rolle. Ifølge Europakommisjonens spørsmål og svar om retningslinjene er en leverandør av en KI-modell for allmenne formål den enheten som utvikler modellen, eller får den utviklet, og bringer den i omsetning under eget navn. Leverandørens plikter omfatter teknisk dokumentasjon, dokumentasjon for utviklere lenger ned i verdikjeden om funksjoner og begrensninger, retningslinjer for etterlevelse av opphavsrett og et offentlig sammendrag av treningsinnholdet. Disse pliktene gjelder fra 2. august 2025. Modeller som antas å innebære systemisk risiko, med treningsberegning på eller over 10^25 flyttallsoperasjoner, har ytterligere plikter, blant annet adversarial testing og tiltak for cybersikkerhet. [[4]](https://digital-strategy.ec.europa.eu/en/faqs/guidelines-obligations-general-purpose-ai-providers)

Samme spørsmål og svar oppgir 2. august 2026 som datoen da håndhevingen, inkludert bøter, gjelder for disse leverandørene, og 2. august 2027 som fristen for modeller brakt i omsetning før 2. august 2025. Det oppgis også at en utvikler lenger ned i verdikjeden som endrer en modell, bare blir leverandør i unntakstilfeller, for eksempel ved bruk av mer enn en tredjedel av den opprinnelige treningsberegningen, slik at det meste av finjustering ikke flytter leverandørrollen. [[4]](https://digital-strategy.ec.europa.eu/en/faqs/guidelines-obligations-general-purpose-ai-providers)

Idriftsettere, det vil si organisasjoner som bruker KI-systemer, har et eget sett med plikter. En analyse fra et advokatfirma datert 24. juli 2026 fører opp merking av deepfakes og varsling av enkeltpersoner om følelsesgjenkjenning og biometrisk kategorisering som plikter for idriftsettere fra 2. august 2026. For høyrisikosystemer fører den opp kompetent menneskelig tilsyn, varsling av enkeltpersoner om at KI brukes, og konsultasjon med arbeidstakere. [[6]](https://www.dataprotectionreport.com/2026/07/the-eu-ai-act-when-does-it-become-enforceable-now/) Kommisjonens side med tidslinjen legger til at idriftsettere må sikre menneskelig tilsyn og overvåking og rapportere alvorlige hendelser når systemene er i omsetning. [[5]](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai)

### Utsettelsen gjennom Digital Omnibus

Fristene for høyrisikosystemer er flyttet. Kommisjonens side med tidslinjen oppgir 2. desember 2027 for høyrisikosystemer på sensitive områder som biometri, arbeidsliv og rettshåndhevelse, og 2. august 2028 for høyrisikosystemer innebygd i regulerte produkter, og viser til Digital Omnibus on AI, som den beskriver som trådt i kraft i juli 2026. [[5]](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) Analysen fra Norton Rose Fulbright oppgir de samme to datoene og opplyser at Omnibus er kunngjort i EUs regelverkssamling. [[6]](https://www.dataprotectionreport.com/2026/07/the-eu-ai-act-when-does-it-become-enforceable-now/) To uavhengige kilder er dermed enige om at utsettelsen ble vedtatt og ikke bare foreslått. Leverandørenes plikter for modeller for allmenne formål og åpenhetspliktene ovenfor flyttes ikke av disse to datoene.

## Fordeling av arbeidet når en modell brukes gjennom et API

For PaaS-tilfellet, der en applikasjon kaller en hostet modell, støtter kildene følgende fordeling. Radene fra Microsoft følger plattform- og applikasjonslagene beskrevet ovenfor; radene om testing av frontier-risiko, systemdokumentasjon og kanaler for sårbarhetsrapportering gjenspeiler leverandørpliktene i EUs retningslinjer og praksis som modelleverandører publiserer. Tabellen er en syntese laget av FireAI, ikke en tekst fra noen av kildene.

| Område | Leverandørens side | Din side |
| --- | --- | --- |
| Modellens atferd | Sikkerhetstrening og innretting av modellen | Systemprompt og vern i applikasjonen |
| Risikotesting | Testing av frontier-risiko i selve modellen | Testing av applikasjonen din, inkludert prompter, data og verktøy |
| Plattform | Plattformsikkerhet og grunnleggende filtre for inndata og utdata | Sikkerhetskontroller i applikasjonen for innhold, plugins og koblinger |
| Dokumentasjon | Systemkort og dokumentasjon for utviklere lenger ned i verdikjeden | Lese den, og registrere hvilken modell og versjon du tok i bruk |
| Data og verktøy | Ingenting utover API-avtalen | RAG-data, verktøy, agenter og tillatelsene deres |
| Utdata | Returnerer generert tekst | Håndtering av utdata videre: validering, escaping, menneskelig godkjenning |
| Drift | Kanal for rapportering av sårbarheter i modellen | Logging, overvåking og hendelseshåndtering for applikasjonen |
| Mennesker | Vilkår for bruk | Egne retningslinjer for bruk og opplæring av brukere |

*Ansvarsfordeling for en modell som brukes som hostet API (PaaS). Syntese laget av FireAI.*

To områder er delt i streng forstand. Det første er promptinjeksjon: Leverandøren trener modellen til å motstå injiserte instruksjoner, og idriftsetteren begrenser hva en injisert instruksjon kan oppnå, gjennom verktøytillatelser og datatilgang. Microsofts side om agenter beskriver den samme fordelingen og ber kunder behandle hentet innhold, utdata fra verktøy og meldinger fra andre agenter som upålitelige og legge en kontroll foran handlinger med stor konsekvens. [[2]](https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility-ai-agent) Det andre er personvern: Leverandøren fastsetter vilkårene for lagring og trening, og idriftsetteren avgjør hvilke data som i det hele tatt havner i en prompt eller en søkeindeks.

> FireAI, brannmuren for macOS som kjører på enheten og utvikles av HisnLabs, kontrollerer hvilke apper på en Mac som kan nå nettverket, og viser hver tilkobling i Aktivitet. Kontroll med utgående trafikk ligger på idriftsetterens side av grensen. [Download FireAI for Mac](https://hisnlabs.com/en/download)

## Anbefalinger

1. Fastslå først distribusjonstypen (SaaS, PaaS eller selvhostet), og skriv ned hvilke rader i fordelingen ovenfor organisasjonen eier.
2. Test idriftsetterens side direkte: systemprompten, dataene som hentes, verktøytillatelsene og håndteringen av utdata. Leverandørens testing av modellen dekker ikke disse.
3. Før en modell tas i bruk, bør du lese leverandørens systemkort og vilkårene for lagring og trening, og finne kanalen for rapportering av sårbarheter.
4. Begrens hva en injisert instruksjon kan gjøre: verktøy med minste privilegium, avgrenset datatilgang og menneskelig godkjenning for handlinger som ikke kan omgjøres.
5. Bestem hvilke data som kan inngå i prompter, og behold logger som er tilstrekkelige til å rekonstruere en hendelse.
6. Læringsmateriell om rammeverk og red teaming finnes i [FireAI University-kurset om rammeverk for KI-sikkerhet og red teaming](https://hisnlabs.com/en/university/ai-security-frameworks-and-red-teaming).

## Relevans for FireAI

En lokal app eller agent som kaller et modell-API, er en app på Mac-en, og destinasjonene den kontakter, er synlige for FireAI. [Aktivitet](https://hisnlabs.com/no/docs/activity-and-connection-history) viser hvilke apper som gikk på nett, og med [Regler](https://hisnlabs.com/no/docs/per-app-rules) kan en bruker tillate eller blokkere en app eller en bestemt destinasjon. Det er én kontroll på idriftsetterens side, på én Mac. FireAI inspiserer ikke prompter, vurderer ikke modellens utdata, oppdager ikke promptinjeksjon og vurderer ikke om en leverandør oppfyller noen rettslig forpliktelse.

## Begrensninger

- Microsoft-sidene er leverandørveiledning for Azure-produkter, beskriver seg selv som illustrerende og endrer ikke avtalevilkår. CSA-teksten er et forslag fra 2023.
- Dette notatet er ikke juridisk rådgivning. Om en organisasjon er leverandør, idriftsetter eller operatør av et høyrisikosystem etter EUs KI-forordning, avhenger av fakta som dette notatet ikke vurderer, og nasjonale myndigheter kan tolke forordningen ulikt.
- Datoene for Digital Omnibus kommer fra Kommisjonens side med tidslinjen og én analyse fra et advokatfirma. Selve forordningsteksten ble ikke gjennomgått for dette notatet.
- API-tabellen er en syntese, og enkelte leverandører plasserer noen av radene annerledes i vilkårene sine.

## Hvor FireAI og HisnLabs kommer inn

Din side av grensen omfatter det som forlater Mac-en. FireAI viser det og lar deg bestemme.

FireAI er HisnLabs’ eget produkt: en KI-brannmur som kjører direkte på Macen. Den viser hver tilkobling appene dine gjør, i klart språk, og lar deg bestemme hva som forlater Macen din — KI-en kjører lokalt, så trafikken din sendes aldri til oss eller noen andre. HisnLabs’ sikkerhetsforskningsteam er de som holder disse vurderingene pålitelige: de katalogiserer hvilke domener som er vanlig telemetri og hvilke som er en ekte tjeneste, sporer landet og nettverket bak en tilkobling, og trener den lokale modellen (FireAI Pilot-funksjonen) på ekte trafikkmønstre — uten at noe av det forlater Macen din.

Du kan lese om de tekniske valgene bak, eller prøve FireAI i 17 dager, på [FireAI, fra HisnLabs](https://hisnlabs.com/no/download).

## Sources

- [Microsoft Learn: Artificial intelligence shared responsibility model (page dated 24 August 2026)](https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility-ai)
- [Microsoft Learn: AI agent shared responsibility model (page dated 26 August 2026)](https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility-ai-agent)
- [Cloud Security Alliance: Generative AI: a proposed shared responsibility model (28 July 2023)](https://cloudsecurityalliance.org/blog/2023/07/28/generative-ai-proposed-shared-responsibility-model)
- [European Commission: Guidelines on the obligations of general-purpose AI model providers (FAQ)](https://digital-strategy.ec.europa.eu/en/faqs/guidelines-obligations-general-purpose-ai-providers)
- [European Commission: AI Act regulatory framework and application timeline](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai)
- [Norton Rose Fulbright, Data Protection Report: The EU AI Act, when does it become enforceable now? (24 July 2026)](https://www.dataprotectionreport.com/2026/07/the-eu-ai-act-when-does-it-become-enforceable-now/)
- [FireAI docs: Rules: app, website, domain, IP or a range](https://hisnlabs.com/en/docs/per-app-rules)
- [FireAI docs: Activity: every app that went online](https://hisnlabs.com/en/docs/activity-and-connection-history)
- [FireAI University: AI security frameworks and red teaming](https://hisnlabs.com/en/university/ai-security-frameworks-and-red-teaming)