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, 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]
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]
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]
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]
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]
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]
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]
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] 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]
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] Analysen fra Norton Rose Fulbright oppgir de samme to datoene og opplyser at Omnibus er kunngjort i EUs regelverkssamling. [6] 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 |
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] 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.
Anbefalinger
- Fastslå først distribusjonstypen (SaaS, PaaS eller selvhostet), og skriv ned hvilke rader i fordelingen ovenfor organisasjonen eier.
- Test idriftsetterens side direkte: systemprompten, dataene som hentes, verktøytillatelsene og håndteringen av utdata. Leverandørens testing av modellen dekker ikke disse.
- 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.
- 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.
- Bestem hvilke data som kan inngå i prompter, og behold logger som er tilstrekkelige til å rekonstruere en hendelse.
- Læringsmateriell om rammeverk og red teaming finnes i FireAI University-kurset om rammeverk for KI-sikkerhet og 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 viser hvilke apper som gikk på nett, og med Regler 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.