Hva bør en kravspesifikasjon for en LLM-gateway eller KI-plattform inneholde?

Hvor data behandles, hva som lagres, hvem som kan trene på dataene, underleverandører og databehandleravtale, identitet og tilgang (SSO, SCIM, nøkler), kostnadskontroll, hvilke modeller og leverandører som er tillatt, revisjonslogger og eksport, støtte for pliktene etter KI-forordningen, exitvilkår og SLA. Malen dekker hvert område med 43 krav og dokumentasjonen dere bør be om.

Kan offentlige oppdragsgivere bruke malen i en anskaffelse?

Ja. Den kan fritt kopieres og redigeres. Offentlige oppdragsgivere bruker den typisk som kravspesifikasjon i konkurransegrunnlaget og legger EUs frivillige standard kontraktsklausuler for KI (MCC-AI) ved kontrakten. Kontroller kravene mot anskaffelsesregelverket og merk hvilke som er absolutte før kunngjøring.

Hva er EUs standard kontraktsklausuler for KI?

Malklausuler for kjøp av KI-systemer, publisert av Community of Practice on Public Procurement of AI på Kommisjonens Public Buyers Community. Oppdateringen fra mars 2025 har en full versjon for KI med høy risiko og en lett versjon for annen KI. De er frivillige og skal legges ved en kontrakt, som fortsatt må regulere personvern, ansvar og immaterielle rettigheter.

Er en modelleverandør underleverandør for en KI-gateway?

Som regel ja. Når en gateway videresender prompter med personopplysninger til en modelleverandør, behandler leverandøren dataene på vegne av gatewayen. Derfor ber rad 13 og 14 om en liste over underleverandører som omfatter inferensleverandører, og om varsel før nye legges til.

Hvor lenge bør en KI-plattform lagre forespørselslogger?

For bruk med høy risiko krever KI-forordningen artikkel 26 nr. 6 at idriftsettere oppbevarer loggene under sin kontroll i minst seks måneder, med mindre annen lovgivning bestemmer noe annet. Mange oppdragsgivere ber om 12 måneder med forespørselslogger som bare inneholder metadata, og ingen lagring av innhold.

Gjelder KI-forordningen for norske oppdragsgivere?

Forordningen er EØS-relevant, men er per 9. november 2026 ikke innlemmet i EØS-avtalen eller gjennomført i norsk rett. Regjeringen arbeider med innlemmelsen og en ny KI-lov, og har som mål å fremme loven for Stortinget våren 2027. Den gjelder likevel idriftsettere som er etablert i EU, og idriftsettere utenfor EU når utdataene fra KI-systemet brukes i EU (artikkel 2 nr. 1 bokstav b og c).

Kravspesifikasjon for anskaffelse av en LLM-gateway eller KI-plattform

Oppdatert 9. november 2026. Kan fritt kopieres, redigeres og brukes i egne konkurransegrunnlag.

En virksomhet eller et offentlig organ som kjøper tilgang til store språkmodeller for ansatte og applikasjoner, kjøper som regel en gateway: én konto og ett API foran flere modelleverandører. Denne malen inneholder 43 krav til en slik anskaffelse, gruppert slik en sikkerhets- og innkjøpsvurdering går gjennom dem. Hvert krav forklarer hvorfor det betyr noe og hvilken dokumentasjon dere bør be leverandøren om.

Malen er leverandørnøytral og kan brukes som kravspesifikasjon i en forespørsel om tilbud, et offentlig konkurransegrunnlag eller en sikkerhetsvurdering av en leverandør. For KI-spesifikke avtalevilkår kan den kombineres med de frivillige EUs standard kontraktsklausuler for KI (MCC-AI), publisert på Kommisjonens Public Buyers Community i mars 2025.

Norge er med i EØS, ikke i EU. Personvernforordningen gjelder i Norge gjennom EØS-avtalen og personopplysningsloven. KI-forordningen er EØS-relevant, men er per 9. november 2026 ikke innlemmet i EØS-avtalen eller gjennomført i norsk rett, og regjeringen har som mål å fremme en ny KI-lov for Stortinget våren 2027. Datoene for KI-forordningen i malen er EUs datoer.

Last ned malen (.md)Regneark (.csv)

CSV-filen åpnes i Excel, Google Sheets eller Numbers, med tomme kolonner for vekt, leverandørens svar og mottatt dokumentasjon.

Kravene

Hvert krav er formulert slik at leverandøren kan svare i ett avsnitt og legge ved dokumentasjon. Merk kravene som er absolutte for dere, vekt resten, og stryk det som ikke er relevant.

1. Behandlingssted

Nr.	Krav	Hvorfor det betyr noe	Dokumentasjon å be om
1	Behandlingsregion. Leverandøren kan begrense inferens til en region oppdragsgiver angir, for eksempel EU/EØS eller Europa, for hele virksomheten, et team eller én API-nøkkel, også for nye forsøk og reserveruter.	Hvorfor det betyr noeGatewayer bytter mellom leverandører ved feil. Uten en regionregel som dekker hvert forsøk, kan en reserverute flytte en prompt til en annen jurisdiksjon uten at noen merker det.	Dokumentasjon å be omRutingsregelen for begrenset trafikk, endepunktene som er tillatt per region med behandlingssted, og hva som skjer når ingen endepunkter i regionen kan betjene en forespørsel.
2	Definisjon av region. Leverandøren oppgir hvilke land hver region omfatter, for eksempel bare EU/EØS, eller også Storbritannia, Sveits eller andre land.	Hvorfor det betyr noeSalgsmateriell bruker ofte Europa og EU om hverandre. Overføringsvurderingen deres avhenger av den nøyaktige listen.	Dokumentasjon å be omEn skriftlig definisjon per region og behandlingsstedet for hver underleverandør i den.
3	Inngang og gatewayens plassering. Leverandøren oppgir hvor TLS termineres, hvor gatewayen kjører og hvilket vertsnavn som skal brukes for regional behandling.	Hvorfor det betyr noeEn forespørsel kan betjenes av en modell i riktig region og likevel først gå gjennom et globalt kantnettverk.	Dokumentasjon å be omVertsnavn per region, driftsleverandør og region for lastbalansereren og gatewayen, og et dataflytdiagram.
4	Plassering av metadata og logger. Leverandøren oppgir hvor kontodata, bruksdata, driftslogger, sikkerhetskopier og e-post lagres og behandles.	Hvorfor det betyr noeSvar om dataresidens dekker ofte bare prompter. Metadata inneholder likevel personopplysninger som navn, e-postadresser og IP-adresser.	Dokumentasjon å be omLagringssted per datakategori, også for sikkerhetskopier og transaksjonell e-post.

2. Lagring og null datalagring

Nr.	Krav	Hvorfor det betyr noe	Dokumentasjon å be om
5	Ingen lagring av innhold hos leverandøren. Leverandøren behandler prompter og svar bare for å betjene forespørselen, eller oppgir nøyaktig hvilket innhold som lagres, hvor og hvor lenge.	Hvorfor det betyr noeGatewayen ser hver prompt virksomheten sender. Gatewayens egen lagring er det første stedet å sjekke.	Dokumentasjon å be omEn beskrivelse av dataflyten, loggskjemaet som viser hvilke felt som skrives, og den tilsvarende bestemmelsen i databehandleravtalen.
6	Null datalagring hos modelleverandørene. Oppdragsgiver kan kreve at forespørsler bare går til modellendepunkter som forplikter seg til ikke å beholde noen kopi av innholdet, på virksomhets-, team- eller nøkkelnivå, og lavere nivåer kan ikke slå det av.	Hvorfor det betyr noeModelleverandører beholder ofte prompter i en periode for misbruksovervåking, med mindre en avtale om null datalagring gjelder for endepunktet.	Dokumentasjon å be omLagringsvilkår per leverandør, hvordan innstillingen håndheves på hver forespørsel, og hvilke funksjoner som er slått av mens den er på.
7	Funksjoner som lagrer innhold. Leverandøren lister opp hver funksjon som lagrer innhold (mellomlagring av prompter, lagrede svar, samtaletilstand, filer, batchjobber) med lagringstid og innstillingen som slår den av.	Hvorfor det betyr noeForpliktelser om lagring har som regel unntak for enkelte funksjoner. Listen viser hvor unntakene er.	Dokumentasjon å be omEn funksjonsliste med lagringstid per funksjon og kontrollen som slår den av.
8	Sletting ved avtalens slutt. Leverandøren sletter eller returnerer oppdragsgivers data innen en angitt frist etter at tjenesten opphører, og bekrefter det skriftlig.	Hvorfor det betyr noePersonvernforordningen artikkel 28 nr. 3 bokstav g krever at databehandleravtalen regulerer sletting eller retur når tjenestene avsluttes.	Dokumentasjon å be omBestemmelsen i databehandleravtalen med fristen, behandlingen av sikkerhetskopier og et eksempel på slettebekreftelse.

3. Trening og bruk av data

Nr.	Krav	Hvorfor det betyr noe	Dokumentasjon å be om
9	Ingen trening hos leverandøren. Leverandøren bruker ikke prompter, svar eller metadata til å trene eller forbedre modeller.	Hvorfor det betyr noeTrening er den bruken oppdragsgivere oftest utelukker, og den må stå i avtalen for å være bindende.	Dokumentasjon å be omBestemmelsen i avtalen eller databehandleravtalen og det tilsvarende avsnittet i personvernerklæringen.
10	Ingen trening hos modelleverandørene. Leverandøren ruter oppdragsgivers trafikk bare til leverandører som forplikter seg til ikke å trene på den, og forklarer hvordan dette håndheves per forespørsel.	Hvorfor det betyr noeGatewayens eget løfte binder ikke modelleverandørene bak den.	Dokumentasjon å be omLeverandørvilkår per endepunkt, mekanismen for håndheving og hvilken trafikk den dekker.
11	Annen sekundærbruk. Leverandøren oppgir om innhold eller metadata brukes til analyse, sammenligningstester, produktforbedring eller manuell gjennomgang, og hvordan dette kan reserveres mot.	Hvorfor det betyr noeSekundærbruk faller utenfor instruksene en behandlingsansvarlig gir en databehandler, med mindre den er avtalt.	Dokumentasjon å be omEn liste over sekundærbruk, retningslinjene for manuell gjennomgang og innstillingen for å reservere seg.

4. Underleverandører og databehandleravtale

Nr.	Krav	Hvorfor det betyr noe	Dokumentasjon å be om
12	Databehandleravtale. En databehandleravtale etter personvernforordningen artikkel 28 er tilgjengelig før signering og dekker formål, varighet, instrukser, taushetsplikt, sikkerhet, bistand, sletting og revisjoner.	Hvorfor det betyr noeArtikkel 28 nr. 3 lister opp hva databehandleravtalen skal inneholde. En gateway behandler personopplysninger i hver prompt som nevner en person.	Dokumentasjon å be omTeksten i databehandleravtalen, hvilket lands rett den er underlagt, og hvordan den signeres.
13	Liste over underleverandører. Leverandøren publiserer hver underleverandør med formål, hvilke data den håndterer og behandlingssted, også modell- og inferensleverandører.	Hvorfor det betyr noeFor en gateway er hver modelleverandør som kan betjene trafikken deres, en underleverandør.	Dokumentasjon å be omAdressen til listen og datoen for siste endring.
14	Varsel om nye underleverandører. Leverandøren varsler innen en angitt frist før en underleverandør legges til eller byttes ut, med rett til å protestere.	Hvorfor det betyr noeArtikkel 28 nr. 2 krever at den behandlingsansvarlige informeres om endringer og får mulighet til å protestere.	Dokumentasjon å be omBestemmelsen i databehandleravtalen med varslingsfristen og kanalen som brukes for varsler.
15	Overføring til tredjeland. For behandling utenfor EØS oppgir leverandøren overføringsgrunnlaget (beslutning om tilstrekkelig beskyttelsesnivå, standard personvernbestemmelser (SCC), UK IDTA).	Hvorfor det betyr noeOverføringer krever et rettslig grunnlag etter kapittel V i personvernforordningen, og oppdragsgiver dokumenterer sin vurdering.	Dokumentasjon å be omVedleggene til de standard personvernbestemmelsene og et sammendrag av leverandørens vurdering av overføringen (TIA).
16	Varsling om brudd. Leverandøren varsler om brudd på personopplysningssikkerheten uten ugrunnet opphold og innen et angitt antall timer.	Hvorfor det betyr noeDen behandlingsansvarlige har 72 timer på seg til å melde fra til tilsynsmyndigheten etter artikkel 33, så databehandlerens frist må være like kort eller kortere.	Dokumentasjon å be omBestemmelsen i databehandleravtalen, et sammendrag av prosessen for hendelseshåndtering og sikkerhetskontakten.

5. Identitet og tilgang

Nr.	Krav	Hvorfor det betyr noe	Dokumentasjon å be om
17	Enkel pålogging (SSO). Innlogging med SAML 2.0 eller OpenID Connect mot oppdragsgivers identitetsleverandør, for eksempel Microsoft Entra ID, Okta eller Google Workspace, både for administrasjonskonsollen og for brukerne.	Hvorfor det betyr noeJobbkontoer knytter tilgangen til ansettelsesforholdet, med oppdragsgivers MFA- og innloggingsregler.	Dokumentasjon å be omStøttede protokoller og identitetsleverandører, oppsettsveiledningen og en testtilkobling.
18	Påtvunget SSO. Oppdragsgiver kan kreve SSO for alle brukere og slå av passord og andre innloggingsmetoder.	Hvorfor det betyr noeSSO ved siden av passord etterlater kontoer utenfor identitetsleverandørens kontroll.	Dokumentasjon å be omInnstillingen, og hvordan den behandler eksisterende økter og API-nøkler.
19	Brukerprovisjonering. Provisjonering og deprovisjonering med SCIM 2.0 fra identitetsleverandøren, med gruppetilordning til roller eller team.	Hvorfor det betyr noeUten deprovisjonering beholder ansatte som slutter tilgangen til noen husker å fjerne den.	Dokumentasjon å be omSCIM-ressursene som støttes (brukere, grupper), og hvor raskt deprovisjonering tilbakekaller økter og nøkler.
20	Roller og API-nøkler. Rollebasert tilgang, en nøkkel per person og per applikasjon, avgrensede nøkler og umiddelbar tilbakekalling.	Hvorfor det betyr noeDelte nøkler skjuler hvem som sendte hvilken forespørsel, og kan ikke tilbakekalles for én person.	Dokumentasjon å be omRollematrisen og livssyklusen for nøkler: opprettelse, avgrensning, rotasjon og tilbakekalling.
21	Skrivebordsapper og kodeagenter. Leverandøren oppgir hvordan ansatte autentiserer seg i KI-apper på skrivebordet og kodeagenter (for eksempel Claude Desktop, Claude Code og IDE-utvidelser): innlogging med jobbkonto eller utdelte nøkler.	Hvorfor det betyr noeDet er i disse verktøyene private kontoer og kopierte nøkler dukker opp utenfor innkjøpsprosessen.	Dokumentasjon å be omOppsettsveiledningen og listen over støttede verktøy.

6. Kostnadskontroll

Nr.	Krav	Hvorfor det betyr noe	Dokumentasjon å be om
22	Budsjetter på nivåene dere styrer. Harde månedlige grenser per bruker, per applikasjon og per team eller avdeling, som stopper forbruket ved grensen.	Hvorfor det betyr noeAgenter og batchjobber kan bruke opp et månedsbudsjett på timer. En grense som bare varsler, er en rapport.	Dokumentasjon å be omNivåene som støttes, og hva som skjer ved grensen: stopp, varsel eller overforbruk.
23	Tak for virksomheten og varsler. Et tak for hele virksomheten og varsler før en grense nås.	Hvorfor det betyr noeØkonomiavdelingen trenger ett tall som ikke kan overskrides, uansett hva som skjer under det.	Dokumentasjon å be omInnstillingene og varslingskanalene.
24	Priser og fakturering. Pris per modell eller per plan, faktureringsvaluta, fakturaer med oppdragsgivers firmaopplysninger og MVA-nummer, og kostnadsrapportering per bruker og applikasjon for internfakturering.	Hvorfor det betyr noeTokenprisene varierer mellom modeller med flere størrelsesordener, så evalueringen trenger prisgrunnlaget og rapporteringen.	Dokumentasjon å be omPrislisten, en eksempelfaktura og en eksempelrapport over bruk.

7. Modelltilgang og godkjenningslister

Nr.	Krav	Hvorfor det betyr noe	Dokumentasjon å be om
25	Modellkatalog. Frontmodellene og modellene med åpne vekter som tilbys, og hvilke av dem som er tilgjengelige under hver regionregel.	Hvorfor det betyr noeEn modell som ikke er tilgjengelig i regionen deres, er utilgjengelig for dere når regionregelen er slått på.	Dokumentasjon å be omEn modelliste per region og retningslinjene for å legge til modeller.
26	Godkjenningslister for modeller. Administratorer velger hvilke modeller hvert team, hver applikasjon eller hver nøkkel kan bruke. Forespørsler til andre modeller avvises.	Hvorfor det betyr noeNår dere har godkjent en modell for et bruksområde, bør godkjenningen håndheves, ikke bare dokumenteres.	Dokumentasjon å be omInnstillingen og feilmeldingen som returneres for en modell som ikke er tillatt.
27	Godkjenningslister for leverandører. Administratorer velger hvilke inferensleverandører som kan betjene trafikken. Reserveruter respekterer listen, og nye leverandører legges aldri til uten godkjenning.	Hvorfor det betyr noeEn leverandør som legges til, blir et nytt sted der dataene deres behandles.	Dokumentasjon å be omInnstillingen, hvordan reserveruter følger den, og hva som skjer når leverandøren legger til en ny inferensleverandør.
28	Modellendringer. Leverandøren varsler på forhånd om utfasing og versjonsendringer av modeller, og oppdragsgiver kan låse en versjon.	Hvorfor det betyr noeEn modellendring uten varsel endrer kvaliteten på svarene og kan gjøre evalueringen av et bruksområde ugyldig.	Dokumentasjon å be omRetningslinjene for utfasing og varslingskanalen.
29	Åpenhet om ruting. Hvis leverandøren ruter automatisk mellom modeller eller leverandører, for kostnad eller tilgjengelighet, dokumenteres reglene, og det registreres hvilken modell og leverandør som betjente hver forespørsel.	Hvorfor det betyr noeAutomatisk ruting har bare verdi hvis dere kan se hvor hver forespørsel gikk.	Dokumentasjon å be omDokumentasjonen av rutingen og et eksempel på en oppføring per forespørsel.

8. Revisjonslogger og eksport

Nr.	Krav	Hvorfor det betyr noe	Dokumentasjon å be om
30	Administratorlogg. Hver endring av brukere, nøkler, budsjetter og regler, med hvem, når og verdien før og etter.	Hvorfor det betyr noeRevisorer spør hvem som endret en regel og når. Uten verdien før og etter kan loggen ikke svare på hva som ble endret.	Dokumentasjon å be omEt eksempel på en loggoppføring og lagringstiden.
31	Forespørselslogg. For hver forespørsel: tidspunkt, bruker eller nøkkel, modell, leverandøren som betjente den, regionregel, status, tokens og kostnad, uten innhold med mindre oppdragsgiver velger det, med en angitt lagringstid.	Hvorfor det betyr noeFor bruk med høy risiko krever KI-forordningen artikkel 26 nr. 6 at idriftsettere oppbevarer logger under sin kontroll i minst seks måneder. Forespørselsloggen er også dokumentasjonen bak KI-registeret.	Dokumentasjon å be omFeltlisten, lagringstiden og et eksempel på en eksport.
32	Eksport. Logger kan eksporteres som CSV eller gjennom et API, og kan sendes til oppdragsgivers SIEM.	Hvorfor det betyr noeOppføringer oppdragsgiver ikke kan hente ut, kan ikke brukes i egen revisjon.	Dokumentasjon å be omFormater, begrensninger på rader eller tidsrom, og API-dokumentasjon.

9. KI-forordningen: plikter for idriftsettere

Nr.	Krav	Hvorfor det betyr noe	Dokumentasjon å be om
33	Støtte for KI-register og KI-kompetanse. Leverandøren gir informasjonen oppdragsgiver trenger til KI-registeret og tiltakene for KI-kompetanse etter artikkel 4: modellene som brukes per applikasjon, leverandørene deres og deres dokumenterte begrensninger.	Hvorfor det betyr noeArtikkel 4 har gjeldt i EU siden 2. februar 2025, og en oversikt over KI-systemer er utgangspunktet for alle andre plikter etter KI-forordningen.	Dokumentasjon å be omOppføringer av modell og leverandør per applikasjon, og lenker til modelldokumentasjonen.
34	Bruk med høy risiko. Hvis oppdragsgiver skal bruke tjenesten til et formål som er oppført i vedlegg III, oppgir leverandøren sin rolle etter KI-forordningen og godtar de relevante bestemmelsene i EUs standard kontraktsklausuler for KI (MCC-AI).	Hvorfor det betyr noePliktene for idriftsettere etter vedlegg III gjelder i EU fra 2. desember 2027 og avhenger av informasjon som bare leverandøren og modelleverandøren har.	Dokumentasjon å be omLeverandørens erklæring om sin rolle og et utfylt vedlegg til MCC-AI High Risk eller Light.
35	Dokumentasjon for KI-modeller for allmenne formål. For hver KI-modell for allmenne formål som tilbys, lenker leverandøren til dokumentasjonen modelleverandøren gjør tilgjengelig for leverandører lenger ned i kjeden, og til det offentlige sammendraget av treningsinnholdet.	Hvorfor det betyr noeArtikkel 53 pålegger leverandører av KI-modeller for allmenne formål å gjøre dette tilgjengelig, og oppdragsgivere arkiverer det per modell.	Dokumentasjon å be omLenker per modell og datoen de ble hentet.
36	Åpenhet. Leverandøren oppgir om utdata merkes i et maskinlesbart format, og hvordan leverandøren støtter oppdragsgivers opplysningsplikt.	Hvorfor det betyr noeÅpenhetspliktene i artikkel 50 gjelder i EU fra 2. august 2026.	Dokumentasjon å be omInformasjon om merking per modell og veiledning om opplysningsplikten.

10. Exit og portabilitet

Nr.	Krav	Hvorfor det betyr noe	Dokumentasjon å be om
37	Standard grensesnitt. API-et følger et utbredt grensesnitt, for eksempel det OpenAI-kompatible formatet for chat completions, slik at applikasjoner kan flyttes uten omskriving.	Hvorfor det betyr noeEt proprietært grensesnitt gjør et leverandørbytte til et utviklingsprosjekt.	Dokumentasjon å be omAPI-referansen og SDK-ene og verktøyene som er kjent for å fungere med det.
38	Dataeksport ved exit. Oppdragsgiver kan eksportere konfigurasjon, brukere, metadata om nøkler, bruk og logger i et maskinlesbart format før og etter oppsigelse.	Hvorfor det betyr noeDer tjenesten er en databehandlingstjeneste etter EUs dataforordning (Data Act), gir kapittel VI kunden rett til å bytte leverandør, og fra 12. januar 2027 kan det ikke kreves byttegebyrer.	Dokumentasjon å be omEksportformater, bistanden som tilbys ved overgang, og hvor lenge dataene er tilgjengelige etter oppsigelse.
39	Avtaleperiode og oppsigelse. Avtaleperiode, oppsigelsestid, eventuelle gebyrer ved oppsigelse og overgangsperioden.	Hvorfor det betyr noeLange avtaleperioder og oppsigelsesgebyrer avgjør hva en exit koster.	Dokumentasjon å be omDe kommersielle vilkårene og bestemmelsen om oppsigelse.

11. Support og SLA

Nr.	Krav	Hvorfor det betyr noe	Dokumentasjon å be om
40	Oppetids-SLA. En månedlig forpliktelse om tilgjengelighet med servicekreditter, målemetode og unntak.	Hvorfor det betyr noeKI flytter inn i produksjonsprosesser, der nedetid har en kostnad.	Dokumentasjon å be omSLA-dokumentet, den offentlige statussiden og tilgjengeligheten de siste 12 månedene.
41	Reserverute ved leverandørfeil. Når en modelleverandør er utilgjengelig, går forespørsler videre til en annen godkjent leverandør av samme modell, innenfor regionregelen og godkjenningslisten.	Hvorfor det betyr noeEn reserverute som ignorerer regionen eller godkjenningslisten, bryter reglene akkurat når en hendelse allerede pågår.	Dokumentasjon å be omUtformingen av reserverutene og antall leverandører per modell under hver regionregel.
42	Support og kommunikasjon ved hendelser. Supportkanaler, responstider etter alvorlighetsgrad, språk og hvordan hendelser kommuniseres.	Hvorfor det betyr noeOppdragsgivers egen hendelsesprosess avhenger av leverandørens.	Dokumentasjon å be omRetningslinjene for support, adressen til statussiden og nylige hendelsesrapporter.
43	Sikkerhetsdokumentasjon. En sikkerhetsoversikt, et utfylt sikkerhetsspørreskjema og de revisjonsrapportene eller sertifiseringene leverandøren og driftsleverandørene har.	Hvorfor det betyr noeDette er det sikkerhetsteamet hos oppdragsgiver vurderer før godkjenning. Å be om det sammen med tilbudet sparer en runde.	Dokumentasjon å be omSikkerhetssiden, et utfylt spørreskjema som det åpne sikkerhetsspørreskjemaet for LLM-gatewayer, og eventuelle rapporter.

Last ned malen (.md)Regneark (.csv)

Slik svarer Standard Compute

Standard Compute er en europeisk KI-gateway: én bedriftskonto og ett API for Claude, GPT, Gemini og åpne modeller, drevet av Standard Compute AS i Oslo. Dette er våre svar på kravene over, med de formuleringene vi bruker på sikkerhetssiden og i databehandleravtalen. Numrene viser til radene i malen.

Nr.	Status	Vårt svar
Nr. 1	Tilgjengelig, slås på	Sett en Europa-regel for bedriften, et team eller én nøkkel, så blir hver forespørsel, også nye forsøk og reserveruter, betjent bare av godkjente europeiske inferensendepunkter. Kan ingen europeiske endepunkter betjene den, blir forespørselen avvist før prompten sendes.
Nr. 2	Tilgjengelig	En Europa-regel slipper bare inn de godkjente europeiske inferensendepunktene som står på listen vår over underleverandører, hver med sitt behandlingssted.
Nr. 3	Tilgjengelig	EU-gatewayen vår på eu.stdcmpt.com terminerer TLS og kjører i Finland, og kontodataene deres lagres i Frankfurt.
Nr. 4	Tilgjengelig	Konto- og bruksdataene deres lagres i Frankfurt i Tyskland. Forespørselsloggene inneholder bare metadata (modell, leverandør, tokens, kostnad og status), aldri promptene eller svarene deres. Hver underleverandør for plattformen står oppført med behandlingssted.
Nr. 5	Tilgjengelig	Vi behandler promptene deres i minnet for å betjene hver forespørsel, og skriver dem aldri til lagring eller logger.
Nr. 6	Tilgjengelig, slås på	Slå på null datalagring (Zero Retention) for bedriften, et team eller en nøkkel, så rutes hver forespørsel bare til inferensendepunkter som forplikter seg til ikke å beholde noen kopi av dataene deres. Team og nøkler arver kravet og kan aldri slå det av.
Nr. 8	Tilgjengelig	Databehandleravtalen fastsetter at vi sletter eller returnerer alle andre personopplysninger om kunden innen 30 dager etter at avtalen opphører (punkt 10).
Nr. 9, 10	Tilgjengelig	Standard Compute trener aldri på promptene eller svarene deres. Med en regionregel eller Zero Retention slått på går hver forespørsel bare til leverandører som forplikter seg til ikke å trene på den.
Nr. 12, 16	Tilgjengelig	Signer databehandleravtalen vår i dashbordet på noen minutter. Den forplikter oss til ingen trening på dataene deres, ingen lagring av innholdet deres og varsling om brudd innen 72 timer. Avtalen er underlagt norsk rett.
Nr. 13, 14	Tilgjengelig	Vi publiserer hver underleverandør med formål, data og sted, og varsler dere 14 dager før vi legger til en ny underleverandør.
Nr. 15	Tilgjengelig	Overføringer utenfor EØS eller Storbritannia til et land uten beslutning om tilstrekkelig beskyttelsesnivå reguleres av EUs standard personvernbestemmelser (SCC) og, for data fra Storbritannia, UK IDTA (databehandleravtalen punkt 6).
Nr. 17	Tilgjengelig	Koble til Microsoft Entra ID eller en annen SAML-identitetsleverandør, så logger de ansatte inn i Standard Compute med jobbkontoen sin. Alle på det verifiserte domenet deres blir automatisk med i bedriften.
Nr. 18	Delvis	SAML-innlogging er tilgjengelig for alle bedrifter med SSO. Passordinnlogging er fortsatt tilgjengelig ved siden av, så SSO er ikke eneste vei inn.
Nr. 19, 21	Tilgjengelig	De ansatte logger inn i Claude Desktop og Claude Code med Microsoft-jobbkontoen sin, gjennom EU-gatewayen vår, så det er ingen API-nøkler å dele ut. Tilgangen følger Microsoft Entra-gruppene deres gjennom SCIM-provisjonering.
Nr. 20	Tilgjengelig	Organiser bedriften i team, inviter kolleger på e-post, og gi hver person og hver app sin egen nøkkel, alt under én bedriftskonto. Rollene er administrator og medlem.
Nr. 22, 23	Delvis	Hver person og hver app får et fast månedsbudsjett som aldri overskrides, og dere kan sette utgiftstak per nøkkel og for hele bedriften. Det finnes ikke et eget budsjett per team: team styres gjennom budsjettene til personene og appene i teamet.
Nr. 24	Tilgjengelig	Faste månedsplaner per person eller app, uten overraskelser per token, og Stripe-fakturaer med firmanavn og MVA-nummer. Prisene er i amerikanske dollar.
Nr. 25	Tilgjengelig	Kjør ledende åpne modeller, blant annet GLM, DeepSeek, MiniMax og Kimi, ved siden av Claude, GPT og Gemini gjennom ett API. GLM, DeepSeek og MiniMax betjenes også av europeiske leverandører for arbeidsområder med Europa-regel.
Nr. 26	Tilgjengelig	Bestem hvilke modeller hver nøkkel kan bruke, slik at hver app og hver ansatt får akkurat de modellene dere godkjenner.
Nr. 27	Tilgjengelig	Velg nøyaktig hvilke inferensleverandører som kan behandle dataene deres, for hele bedriften, et team eller én nøkkel. Lavere nivåer kan bare stramme inn reglene, nye leverandører legges aldri til uten at en administrator godkjenner det, og reserveruter kan aldri gå utenom listen deres.
Nr. 29	Tilgjengelig	Hvert steg går til den billigste modellen som kan gjøre jobben og den billigste leverandøren som er rask nok til å betjene den, og oppføringen for forespørselen viser modellen og leverandøren som betjente den.
Nr. 30, 31, 32	Tilgjengelig	Hver endring en administrator gjør, registreres med verdien før og etter, og dere kan eksportere en oppføring for hver forespørsel som viser modellen, leverandøren som betjente den og regionregelen som gjaldt, lagret i 12 måneder. Eksporten er CSV.
Nr. 33	Tilgjengelig	En nøkkel per person og per app, modellene hver nøkkel får bruke, og modell og leverandøren som betjente hver forespørsel: oppføringene sjekklisten vår til KI-forordningen for idriftsettere ber om.
Nr. 37	Tilgjengelig	Ett OpenAI-kompatibelt API (chat completions-formatet) for alle modeller, beskrevet i API-referansen.
Nr. 40, 41	Tilgjengelig	Går en leverandør ned, sendes forespørselen automatisk videre til en annen godkjent leverandør av samme modell, uten å gå utenfor regionregelen eller leverandørreglene deres. Enterprise inkluderer en månedlig oppetids-SLA på 99,9 % med servicekreditter. Driftsstatus er offentlig på /status.
Nr. 43	Tilgjengelig	Sikkerhetssiden vår, det utfylte sikkerhetsspørreskjemaet, listen over underleverandører og databehandleravtalen er offentlige.

Rader som ikke står her, besvarer dere sammen med kontaktpersonen deres hos oss i tilbudet. Malen over er fortsatt leverandørnøytral: bruk den med hvilken som helst leverandør.

Opprett en bedriftskonto

Spørsmål

Hva bør en kravspesifikasjon for en LLM-gateway eller KI-plattform inneholde?: Hvor data behandles, hva som lagres, hvem som kan trene på dataene, underleverandører og databehandleravtale, identitet og tilgang (SSO, SCIM, nøkler), kostnadskontroll, hvilke modeller og leverandører som er tillatt, revisjonslogger og eksport, støtte for pliktene etter KI-forordningen, exitvilkår og SLA. Malen dekker hvert område med 43 krav og dokumentasjonen dere bør be om.
Kan offentlige oppdragsgivere bruke malen i en anskaffelse?: Ja. Den kan fritt kopieres og redigeres. Offentlige oppdragsgivere bruker den typisk som kravspesifikasjon i konkurransegrunnlaget og legger EUs frivillige standard kontraktsklausuler for KI (MCC-AI) ved kontrakten. Kontroller kravene mot anskaffelsesregelverket og merk hvilke som er absolutte før kunngjøring.
Hva er EUs standard kontraktsklausuler for KI?: Malklausuler for kjøp av KI-systemer, publisert av Community of Practice on Public Procurement of AI på Kommisjonens Public Buyers Community. Oppdateringen fra mars 2025 har en full versjon for KI med høy risiko og en lett versjon for annen KI. De er frivillige og skal legges ved en kontrakt, som fortsatt må regulere personvern, ansvar og immaterielle rettigheter.
Er en modelleverandør underleverandør for en KI-gateway?: Som regel ja. Når en gateway videresender prompter med personopplysninger til en modelleverandør, behandler leverandøren dataene på vegne av gatewayen. Derfor ber rad 13 og 14 om en liste over underleverandører som omfatter inferensleverandører, og om varsel før nye legges til.
Hvor lenge bør en KI-plattform lagre forespørselslogger?: For bruk med høy risiko krever KI-forordningen artikkel 26 nr. 6 at idriftsettere oppbevarer loggene under sin kontroll i minst seks måneder, med mindre annen lovgivning bestemmer noe annet. Mange oppdragsgivere ber om 12 måneder med forespørselslogger som bare inneholder metadata, og ingen lagring av innhold.
Gjelder KI-forordningen for norske oppdragsgivere?: Forordningen er EØS-relevant, men er per 9. november 2026 ikke innlemmet i EØS-avtalen eller gjennomført i norsk rett. Regjeringen arbeider med innlemmelsen og en ny KI-lov, og har som mål å fremme loven for Stortinget våren 2027. Den gjelder likevel idriftsettere som er etablert i EU, og idriftsettere utenfor EU når utdataene fra KI-systemet brukes i EU (artikkel 2 nr. 1 bokstav b og c).

Kilder

Svar på hele malen med én leverandør: en europeisk gateway til frontmodeller og åpne modeller, med kontrollene samlet på én bedriftskonto.