# 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) (https://public-buyers-community.ec.europa.eu/communities/procurement-ai/resources/updated-eu-ai-model-contractual-clauses), 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.

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

| Absolutt | 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. | Gatewayer 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. | Rutingsregelen 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. | Salgsmateriell bruker ofte Europa og EU om hverandre. Overføringsvurderingen deres avhenger av den nøyaktige listen. | En 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. | En forespørsel kan betjenes av en modell i riktig region og likevel først gå gjennom et globalt kantnettverk. | Vertsnavn 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. | Svar om dataresidens dekker ofte bare prompter. Metadata inneholder likevel personopplysninger som navn, e-postadresser og IP-adresser. | Lagringssted per datakategori, også for sikkerhetskopier og transaksjonell e-post. |

## 2. Lagring og null datalagring

| Absolutt | 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. | Gatewayen ser hver prompt virksomheten sender. Gatewayens egen lagring er det første stedet å sjekke. | En 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. | Modelleverandører beholder ofte prompter i en periode for misbruksovervåking, med mindre en avtale om null datalagring gjelder for endepunktet. | Lagringsvilkå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. | Forpliktelser om lagring har som regel unntak for enkelte funksjoner. Listen viser hvor unntakene er. | En 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. | Personvernforordningen artikkel 28 nr. 3 bokstav g krever at databehandleravtalen regulerer sletting eller retur når tjenestene avsluttes. | Bestemmelsen i databehandleravtalen med fristen, behandlingen av sikkerhetskopier og et eksempel på slettebekreftelse. |

## 3. Trening og bruk av data

| Absolutt | 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. | Trening er den bruken oppdragsgivere oftest utelukker, og den må stå i avtalen for å være bindende. | Bestemmelsen 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. | Gatewayens eget løfte binder ikke modelleverandørene bak den. | Leverandø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. | Sekundærbruk faller utenfor instruksene en behandlingsansvarlig gir en databehandler, med mindre den er avtalt. | En liste over sekundærbruk, retningslinjene for manuell gjennomgang og innstillingen for å reservere seg. |

## 4. Underleverandører og databehandleravtale

| Absolutt | 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. | Artikkel 28 nr. 3 lister opp hva databehandleravtalen skal inneholde. En gateway behandler personopplysninger i hver prompt som nevner en person. | Teksten 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. | For en gateway er hver modelleverandør som kan betjene trafikken deres, en underleverandør. | Adressen 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. | Artikkel 28 nr. 2 krever at den behandlingsansvarlige informeres om endringer og får mulighet til å protestere. | Bestemmelsen 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). | Overføringer krever et rettslig grunnlag etter kapittel V i personvernforordningen, og oppdragsgiver dokumenterer sin vurdering. | Vedleggene 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. | Den behandlingsansvarlige har 72 timer på seg til å melde fra til tilsynsmyndigheten etter artikkel 33, så databehandlerens frist må være like kort eller kortere. | Bestemmelsen i databehandleravtalen, et sammendrag av prosessen for hendelseshåndtering og sikkerhetskontakten. |

## 5. Identitet og tilgang

| Absolutt | 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. | Jobbkontoer knytter tilgangen til ansettelsesforholdet, med oppdragsgivers MFA- og innloggingsregler. | Stø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. | SSO ved siden av passord etterlater kontoer utenfor identitetsleverandørens kontroll. | Innstillingen, 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. | Uten deprovisjonering beholder ansatte som slutter tilgangen til noen husker å fjerne den. | SCIM-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. | Delte nøkler skjuler hvem som sendte hvilken forespørsel, og kan ikke tilbakekalles for én person. | Rollematrisen 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. | Det er i disse verktøyene private kontoer og kopierte nøkler dukker opp utenfor innkjøpsprosessen. | Oppsettsveiledningen og listen over støttede verktøy. |

## 6. Kostnadskontroll

| Absolutt | 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. | Agenter og batchjobber kan bruke opp et månedsbudsjett på timer. En grense som bare varsler, er en rapport. | Nivå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. | Økonomiavdelingen trenger ett tall som ikke kan overskrides, uansett hva som skjer under det. | Innstillingene 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. | Tokenprisene varierer mellom modeller med flere størrelsesordener, så evalueringen trenger prisgrunnlaget og rapporteringen. | Prislisten, en eksempelfaktura og en eksempelrapport over bruk. |

## 7. Modelltilgang og godkjenningslister

| Absolutt | 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. | En modell som ikke er tilgjengelig i regionen deres, er utilgjengelig for dere når regionregelen er slått på. | En 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. | Når dere har godkjent en modell for et bruksområde, bør godkjenningen håndheves, ikke bare dokumenteres. | Innstillingen 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. | En leverandør som legges til, blir et nytt sted der dataene deres behandles. | Innstillingen, 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. | En modellendring uten varsel endrer kvaliteten på svarene og kan gjøre evalueringen av et bruksområde ugyldig. | Retningslinjene 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. | Automatisk ruting har bare verdi hvis dere kan se hvor hver forespørsel gikk. | Dokumentasjonen av rutingen og et eksempel på en oppføring per forespørsel. |

## 8. Revisjonslogger og eksport

| Absolutt | 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. | Revisorer 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. | Et 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. | For 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. | Feltlisten, lagringstiden og et eksempel på en eksport. |
| [ ] | 32 | Eksport. Logger kan eksporteres som CSV eller gjennom et API, og kan sendes til oppdragsgivers SIEM. | Oppføringer oppdragsgiver ikke kan hente ut, kan ikke brukes i egen revisjon. | Formater, begrensninger på rader eller tidsrom, og API-dokumentasjon. |

## 9. KI-forordningen: plikter for idriftsettere

| Absolutt | 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. | Artikkel 4 har gjeldt i EU siden 2. februar 2025, og en oversikt over KI-systemer er utgangspunktet for alle andre plikter etter KI-forordningen. | Oppfø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). | Pliktene for idriftsettere etter vedlegg III gjelder i EU fra 2. desember 2027 og avhenger av informasjon som bare leverandøren og modelleverandøren har. | Leverandø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. | Artikkel 53 pålegger leverandører av KI-modeller for allmenne formål å gjøre dette tilgjengelig, og oppdragsgivere arkiverer det per modell. | Lenker 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. | Åpenhetspliktene i artikkel 50 gjelder i EU fra 2. august 2026. | Informasjon om merking per modell og veiledning om opplysningsplikten. |

## 10. Exit og portabilitet

| Absolutt | 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. | Et proprietært grensesnitt gjør et leverandørbytte til et utviklingsprosjekt. | API-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. | Der 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. | Eksportformater, 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. | Lange avtaleperioder og oppsigelsesgebyrer avgjør hva en exit koster. | De kommersielle vilkårene og bestemmelsen om oppsigelse. |

## 11. Support og SLA

| Absolutt | Nr. | Krav | Hvorfor det betyr noe | Dokumentasjon å be om |
| --- | --- | --- | --- | --- |
| [ ] | 40 | Oppetids-SLA. En månedlig forpliktelse om tilgjengelighet med servicekreditter, målemetode og unntak. | KI flytter inn i produksjonsprosesser, der nedetid har en kostnad. | SLA-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. | En reserverute som ignorerer regionen eller godkjenningslisten, bryter reglene akkurat når en hendelse allerede pågår. | Utformingen 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. | Oppdragsgivers egen hendelsesprosess avhenger av leverandørens. | Retningslinjene 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. | Dette er det sikkerhetsteamet hos oppdragsgiver vurderer før godkjenning. Å be om det sammen med tilbudet sparer en runde. | Sikkerhetssiden, et utfylt spørreskjema som det åpne sikkerhetsspørreskjemaet for LLM-gatewayer (https://standardcompute.com/sikkerhetssporreskjema-llm-gateway), og eventuelle rapporter. |

---

## Kilder

- [Oppdaterte EU-kontraktsklausuler for KI (MCC-AI High Risk og Light), Public Buyers Community, 5. mars 2025](https://public-buyers-community.ec.europa.eu/communities/procurement-ai/resources/updated-eu-ai-model-contractual-clauses)
- [Forordning (EU) 2016/679, personvernforordningen (GDPR), artikkel 28 og 33, EUR-Lex](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679)
- [Lov om behandling av personopplysninger (personopplysningsloven), Lovdata](https://lovdata.no/dokument/NL/lov/2018-06-15-38)
- [Forordning (EU) 2024/1689, KI-forordningen, artikkel 4, 26, 50 og 53, EUR-Lex](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689)
- [Forordning (EU) 2023/2854, dataforordningen (Data Act), kapittel VI om bytte mellom databehandlingstjenester, EUR-Lex](https://eur-lex.europa.eu/eli/reg/2023/2854/oj)
- [RFC 7644, SCIM 2.0-protokollen](https://www.rfc-editor.org/rfc/rfc7644) og [SAML 2.0 core, OASIS](https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf)

_Gratis kravspesifikasjon for LLM-gateway og KI-plattform fra https://standardcompute.com/kravspesifikasjon-ki-plattform-anbud (versjon 9. november 2026). Kan fritt kopieres og redigeres. Ikke juridisk rådgivning._