# Kravspecifikation til udbud af en LLM-gateway eller AI-platform

Opdateret 9. november 2026. Må frit kopieres, tilpasses og bruges i jeres egne udbudsmaterialer.

En virksomhed eller offentlig myndighed, der køber adgang til store sprogmodeller til medarbejdere og applikationer, køber som regel en gateway: én konto og ét API foran flere modeludbydere. Denne kravspecifikation indeholder 43 krav til det indkøb, ordnet i den rækkefølge, en sikkerheds- og indkøbsvurdering gennemgår dem. Ved hvert krav står, hvorfor det er vigtigt, og hvilken dokumentation I skal bede tilbudsgiveren om.

Den er leverandørneutral og kan bruges som kravbilag til en tilbudsindhentning, et offentligt udbud eller en sikkerhedsvurdering af leverandører. Kombinér den med de frivillige EU-modelkontraktbestemmelser for AI (MCC-AI) (https://public-buyers-community.ec.europa.eu/communities/procurement-ai/resources/updated-eu-ai-model-contractual-clauses) til AI-specifikke kontraktvilkår. De blev offentliggjort i marts 2025 i Europa-Kommissionens Public Buyers Community.

Hvert krav er formuleret, så en tilbudsgiver kan besvare det i ét afsnit og vedlægge dokumentationen. Markér de krav, der er mindstekrav for jer, vægt resten, og slet det, der ikke er relevant.

## 1. Dataplacering

| Skal | Nr. | Krav | Hvorfor det betyder noget | Dokumentation at bede om |
| --- | --- | --- | --- | --- |
| [ ] | 1 | Behandlingsregion. Leverandøren kan begrænse inferens til en region, ordregiveren angiver, for eksempel EU/EØS eller Europa, for hele organisationen, et team eller én API-nøgle, også ved nye forsøg og reserveruter. | Gateways skifter mellem udbydere. Uden en regionsregel, der dækker hvert forsøg, kan en reserverute flytte en prompt til en anden jurisdiktion, uden at nogen opdager det. | Routingpolitikken for begrænset trafik, de tilladte endpoints pr. region med deres placering, og hvad der sker, når intet endpoint i regionen kan betjene en forespørgsel. |
| [ ] | 2 | Definition af regionen. Leverandøren oplyser, hvilke lande hver region omfatter, for eksempel kun EU/EØS eller også Storbritannien, Schweiz eller andre lande. | Salgsmateriale bruger ofte Europa og EU i flæng. Jeres vurdering af overførsler afhænger af den præcise liste. | En skriftlig definition pr. region og behandlingsstedet for hver underdatabehandler i den. |
| [ ] | 3 | Placering af indgang og gateway. Leverandøren oplyser, hvor TLS termineres, hvor gatewayen kører, og hvilket værtsnavn der skal bruges til regional behandling. | En forespørgsel kan blive betjent af en model i den rigtige region og alligevel først passere et globalt edge-netværk. | Værtsnavne pr. region, hostingudbyder og region for load balancer og gateway samt et dataflowdiagram. |
| [ ] | 4 | Placering af metadata og logfiler. Leverandøren oplyser, hvor kontodata, forbrugsdata, driftslogfiler, backup og e-mail lagres og behandles. | Svar om dataplacering dækker ofte kun prompts. Metadata indeholder stadig personoplysninger som navne, e-mailadresser og IP-adresser. | En lagringsplacering pr. datakategori, herunder backup og transaktionel e-mail. |

## 2. Opbevaringstid og nul dataopbevaring

| Skal | Nr. | Krav | Hvorfor det betyder noget | Dokumentation at bede om |
| --- | --- | --- | --- | --- |
| [ ] | 5 | Ingen lagring af indhold hos leverandøren. Leverandøren behandler prompts og output udelukkende for at betjene forespørgslen eller oplyser præcist, hvilket indhold der lagres, hvor og hvor længe. | Gatewayen ser hver prompt, jeres organisation sender. Dens egen opbevaring er den første risiko, I skal kontrollere. | En beskrivelse af dataflowet, logskemaet med de felter, der skrives, og den tilsvarende bestemmelse i databehandleraftalen. |
| [ ] | 6 | Nul dataopbevaring hos modeludbydere. Ordregiveren kan kræve, at forespørgsler kun går til model-endpoints, der forpligter sig til ikke at beholde nogen kopi af indholdet, på niveau af organisation, team eller nøgle, og lavere niveauer kan ikke slå det fra. | Modeludbydere opbevarer normalt prompts i en periode til misbrugsovervågning, medmindre der gælder en aftale om nul dataopbevaring for endpointet. | Opbevaringsvilkår pr. udbyder, hvordan indstillingen håndhæves ved hver forespørgsel, og hvilke funktioner der er slået fra, mens den er aktiv. |
| [ ] | 7 | Funktioner, der lagrer indhold. Leverandøren oplister hver funktion, der lagrer indhold (prompt caching, gemte svar, samtaletilstand, filer, batchjob), med opbevaringsperiode og den indstilling, der slår den fra. | Tilsagn om opbevaring har som regel undtagelser for bestemte funktioner. Listen viser, hvor undtagelserne ligger. | En funktionsliste med opbevaringsperiode pr. funktion og den indstilling, der deaktiverer den. |
| [ ] | 8 | Sletning ved kontraktens ophør. Leverandøren sletter eller tilbageleverer ordregiverens data inden for en fastsat frist efter ophør af tjenesten og bekræfter det skriftligt. | Artikel 28, stk. 3, litra g), i databeskyttelsesforordningen kræver, at databehandleraftalen regulerer sletning eller tilbagelevering ved ophør af behandlingstjenesterne. | Bestemmelsen i databehandleraftalen med fristen, håndteringen af backup og et eksempel på en sletningsbekræftelse. |

## 3. Træning og brug af data

| Skal | Nr. | Krav | Hvorfor det betyder noget | Dokumentation at bede om |
| --- | --- | --- | --- | --- |
| [ ] | 9 | Ingen træning hos leverandøren. Leverandøren bruger ikke prompts, output eller metadata til at træne eller forbedre modeller. | Træning er den anvendelse, ordregivere oftest udelukker, og udelukkelsen binder kun, når den står i kontrakten. | Bestemmelsen i kontrakten eller databehandleraftalen og det tilsvarende afsnit i privatlivspolitikken. |
| [ ] | 10 | Ingen træning hos modeludbydere. Leverandøren sender kun ordregiverens trafik til udbydere, der forpligter sig til ikke at træne på den, og forklarer, hvordan det håndhæves ved hver forespørgsel. | Gatewayens eget tilsagn binder ikke modeludbyderne bag den. | Udbydervilkår pr. endpoint, håndhævelsesmekanismen og hvilken trafik den dækker. |
| [ ] | 11 | Anden sekundær brug. Leverandøren oplyser, om indhold eller metadata bruges til analyse, benchmarking, produktforbedring eller menneskelig gennemgang, og hvordan man fravælger det. | Sekundær brug ligger uden for de instrukser, en dataansvarlig giver en databehandler, medmindre den er aftalt. | En liste over sekundær brug, politikken for menneskelig gennemgang og indstillingen til fravalg. |

## 4. Underdatabehandlere og databehandleraftale

| Skal | Nr. | Krav | Hvorfor det betyder noget | Dokumentation at bede om |
| --- | --- | --- | --- | --- |
| [ ] | 12 | Databehandleraftale. En databehandleraftale efter artikel 28 i databeskyttelsesforordningen foreligger før underskrift og dækker genstand, varighed, instrukser, fortrolighed, sikkerhed, bistand, sletning og revision. | Artikel 28, stk. 3, fastlægger, hvad aftalen med databehandleren skal indeholde. En gateway behandler personoplysninger i hver prompt, der nævner en person. | Teksten til databehandleraftalen, lovvalget og hvordan den underskrives. |
| [ ] | 13 | Liste over underdatabehandlere. Leverandøren offentliggør hver underdatabehandler med formål, de data den behandler, og placering, herunder model- og inferensudbydere. | For en gateway er hver modeludbyder, der kan betjene jeres trafik, en underdatabehandler. | Listens URL og datoen for seneste ændring. |
| [ ] | 14 | Varsel om nye underdatabehandlere. Leverandøren giver et fastsat forhåndsvarsel, før en underdatabehandler tilføjes eller udskiftes, med ret til at gøre indsigelse. | Artikel 28, stk. 2, kræver, at den dataansvarlige underrettes om ændringer og får mulighed for at gøre indsigelse. | Bestemmelsen i databehandleraftalen med varslet og den kanal, varsler sendes via. |
| [ ] | 15 | Internationale overførsler. For al behandling uden for EØS angiver leverandøren overførselsgrundlaget (afgørelse om tilstrækkeligt beskyttelsesniveau, standardkontraktbestemmelser, UK IDTA). | Overførsler kræver et retsgrundlag efter kapitel V i databeskyttelsesforordningen, og ordregiveren dokumenterer sin vurdering. | Bilagene til standardkontraktbestemmelserne og et resumé af leverandørens vurdering af overførslens virkninger. |
| [ ] | 16 | Underretning om brud. Leverandøren underretter om brud på persondatasikkerheden uden unødig forsinkelse og inden for et fastsat antal timer. | Den dataansvarlige har efter artikel 33 72 timer til at anmelde til tilsynsmyndigheden, så databehandlerens frist skal være kortere eller lige så lang. | Bestemmelsen i databehandleraftalen, et resumé af processen for håndtering af hændelser og sikkerhedskontakten. |

## 5. Identitet og adgang

| Skal | Nr. | Krav | Hvorfor det betyder noget | Dokumentation at bede om |
| --- | --- | --- | --- | --- |
| [ ] | 17 | Single sign-on. Log ind via SAML 2.0 eller OpenID Connect med ordregiverens identitetsudbyder, for eksempel Microsoft Entra ID, Okta eller Google Workspace, til administrationskonsollen og for brugere. | Arbejdskonti knytter adgangen til ansættelsesforholdet, med ordregiverens MFA- og login-politikker. | Understøttede protokoller og identitetsudbydere, opsætningsvejledningen og en testforbindelse. |
| [ ] | 18 | Påkrævet SSO. Ordregiveren kan kræve SSO for alle brugere og slå adgangskoder og andre loginmetoder fra. | SSO ved siden af adgangskoder efterlader konti uden for identitetsudbyderens kontrol. | Indstillingen, og hvordan den håndterer eksisterende sessioner og API-nøgler. |
| [ ] | 19 | Brugerprovisionering. Provisionering og deprovisionering via SCIM 2.0 fra identitetsudbyderen, med kobling af grupper til roller eller teams. | Uden deprovisionering beholder fratrådte medarbejdere adgangen, indtil nogen husker at fjerne den. | De understøttede SCIM-ressourcer (brugere, grupper), og hvor hurtigt deprovisionering tilbagekalder sessioner og nøgler. |
| [ ] | 20 | Roller og API-nøgler. Rollebaseret adgang, en nøgle pr. person og pr. applikation, nøgler med afgrænsede rettigheder og øjeblikkelig tilbagekaldelse. | Delte nøgler skjuler, hvem der sendte hvilken forespørgsel, og kan ikke tilbagekaldes for én person. | Rollematrixen og nøglernes livscyklus: oprettelse, afgrænsning, rotation og tilbagekaldelse. |
| [ ] | 21 | Desktopapps og kodeagenter. Leverandøren oplyser, hvordan medarbejdere logger ind i AI-desktopapps og kodeagenter (for eksempel Claude Desktop, Claude Code og IDE-udvidelser): med arbejdskonto eller med udleverede nøgler. | Det er i disse værktøjer, private konti og kopierede nøgler dukker op uden for indkøbet. | Opsætningsvejledningen og listen over understøttede værktøjer. |

## 6. Udgiftsstyring

| Skal | Nr. | Krav | Hvorfor det betyder noget | Dokumentation at bede om |
| --- | --- | --- | --- | --- |
| [ ] | 22 | Budgetter på de niveauer, I styrer. Faste månedlige grænser pr. bruger, pr. applikation og pr. team eller afdeling, som stopper forbruget ved grænsen. | Agenter og batchjob kan bruge et månedsbudget på få timer. En grænse, der kun advarer, er en rapport. | De understøttede niveauer, og hvad der sker ved grænsen: blokering, advarsel eller overskridelse. |
| [ ] | 23 | Loft for organisationen og advarsler. Et loft for hele organisationen og advarsler, før en grænse nås. | Økonomiafdelingen har brug for ét tal, der ikke kan overskrides, uanset hvad der sker nedenunder. | Indstillingerne og advarselskanalerne. |
| [ ] | 24 | Priser og fakturering. Pris pr. model eller pr. abonnement, faktureringsvaluta, fakturaer med ordregiverens firmaoplysninger og momsnummer samt omkostningsrapportering pr. bruger og applikation til intern viderefakturering. | Tokenpriser varierer mellem modeller med flere størrelsesordener, så evalueringen kræver prisgrundlaget og rapporteringen. | Prislisten, en eksempelfaktura og en eksempelrapport over forbrug. |

## 7. Modeladgang og tilladte lister

| Skal | Nr. | Krav | Hvorfor det betyder noget | Dokumentation at bede om |
| --- | --- | --- | --- | --- |
| [ ] | 25 | Modelkatalog. De udbudte frontier- og open weight-modeller, og hvilke af dem der er tilgængelige under hver regionsregel. | En model, der ikke er tilgængelig i jeres region, er ikke tilgængelig for jer, når regionsreglen er slået til. | En modelliste pr. region og politikken for at tilføje modeller. |
| [ ] | 26 | Tilladte modeller. Administratorer vælger, hvilke modeller hvert team, hver applikation eller hver nøgle må bruge. Forespørgsler til andre modeller afvises. | En godkendelse af en model, der kun står i et politikdokument, forhindrer ingen i at kalde en anden model. | Indstillingen og den fejl, der returneres for en model, der ikke er tilladt. |
| [ ] | 27 | Tilladte udbydere. Administratorer vælger, hvilke inferensudbydere der må betjene trafik. Reserveruter overholder listen, og nye udbydere tilføjes aldrig uden godkendelse. | En udbyder, som leverandøren tilføjer, er et nyt sted, hvor jeres data behandles. | Indstillingen, hvordan reserveruter anvender den, og hvad der sker, når leverandøren tilføjer en udbyder. |
| [ ] | 28 | Modelændringer. Leverandøren varsler udfasning af modeller og versionsskift på forhånd, og ordregiveren kan fastlåse en version. | Et stille modelskift ændrer outputtets kvalitet og kan gøre evalueringen af en anvendelse ugyldig. | Politikken for udfasning og varslingskanalen. |
| [ ] | 29 | Gennemsigtig routing. Hvis leverandøren automatisk router mellem modeller eller udbydere, af hensyn til pris eller tilgængelighed, dokumenterer den reglerne og registrerer, hvilken model og udbyder der betjente hver forespørgsel. | Automatisk routing har kun værdi, hvis I kan se, hvor hver forespørgsel gik hen. | Routingdokumentationen og et eksempel på en post pr. forespørgsel. |

## 8. Auditlogs og eksport

| Skal | Nr. | Krav | Hvorfor det betyder noget | Dokumentation at bede om |
| --- | --- | --- | --- | --- |
| [ ] | 30 | Administratorlog. Hver ændring af brugere, nøgler, budgetter og politikker, med hvem, hvornår og værdien før og efter. | Revisorer spørger, hvem der ændrede en politik og hvornår. Uden værdien før og efter kan loggen ikke svare på, hvad der blev ændret. | Et eksempel på en logpost og opbevaringsperioden. |
| [ ] | 31 | Forespørgselslog. For hver forespørgsel: tidspunkt, bruger eller nøgle, model, betjenende udbyder, regionsregel, status, tokens og omkostning, uden indhold medmindre ordregiveren vælger det til, med en fastsat opbevaringsperiode. | Ved højrisikoanvendelser kræver artikel 26, stk. 6, i AI-forordningen, at idriftsættere opbevarer de logfiler, der er under deres kontrol, i mindst seks måneder. Forespørgselsloggen er også dokumentationen bag AI-oversigten. | Feltlisten, opbevaringsperioden og et eksempel på en eksport. |
| [ ] | 32 | Eksport. Logfiler kan eksporteres som CSV eller via et API og sendes til ordregiverens SIEM. | Data, ordregiveren ikke kan få ud, kan ikke bruges i dennes egen revision. | Formater, begrænsninger på rækker eller tidsrum og API-dokumentation. |

## 9. Idriftsætterens forpligtelser efter AI-forordningen

| Skal | Nr. | Krav | Hvorfor det betyder noget | Dokumentation at bede om |
| --- | --- | --- | --- | --- |
| [ ] | 33 | Støtte til oversigt og AI-færdigheder. Leverandøren leverer de oplysninger, ordregiveren har brug for til sin oversigt over AI-systemer og sine tiltag for AI-færdigheder efter artikel 4: de modeller, hver applikation bruger, deres udbydere og deres dokumenterede begrænsninger. | Artikel 4 har gældet siden 2. februar 2025, og en oversigt er udgangspunktet for alle andre forpligtelser i AI-forordningen. | Oplysninger om model og udbyder pr. applikation og links til modeldokumentation. |
| [ ] | 34 | Højrisikoanvendelser. Vil ordregiveren bruge tjenesten til et formål i bilag III, oplyser leverandøren sin rolle efter AI-forordningen og tilslutter sig de relevante bestemmelser i EU-modelkontraktbestemmelserne for AI. | Idriftsætterens forpligtelser for bilag III gælder fra 2. december 2027 og afhænger af oplysninger, som kun leverandøren og modeludbyderen har. | Leverandørens erklæring om sin rolle og et udfyldt MCC-AI-bilag (High Risk eller Light). |
| [ ] | 35 | Dokumentation for AI-modeller til almen brug. For hver udbudt AI-model til almen brug linker leverandøren til den dokumentation, modellens udbyder stiller til rådighed for udbydere længere nede i værdikæden, og til det offentlige resumé af træningsindholdet. | Artikel 53 forpligter udbydere af AI-modeller til almen brug til at stille dette til rådighed, og ordregivere arkiverer det pr. model. | Links pr. model og datoen for hentning. |
| [ ] | 36 | Gennemsigtighed. Leverandøren oplyser, om output bærer en maskinlæsbar mærkning, og hvordan den understøtter ordregiverens oplysningspligter. | Gennemsigtighedsforpligtelserne i artikel 50 gælder fra 2. august 2026. | Oplysninger om mærkning pr. model og vejledning om oplysning. |

## 10. Exit og portabilitet

| Skal | Nr. | Krav | Hvorfor det betyder noget | Dokumentation at bede om |
| --- | --- | --- | --- | --- |
| [ ] | 37 | Standardgrænseflade. API'et følger en udbredt grænseflade, for eksempel det OpenAI-kompatible chat completions-format, så applikationer kan flytte uden omskrivning. | En proprietær grænseflade gør et leverandørskift til et softwareprojekt. | API-referencen og de SDK'er og værktøjer, der vides at fungere med den. |
| [ ] | 38 | Dataeksport ved exit. Ordregiveren kan eksportere konfiguration, brugere, nøglemetadata, forbrug og logfiler i et maskinlæsbart format før og efter opsigelse. | Er tjenesten en databehandlingstjeneste efter dataforordningen (Data Act), giver kapitel VI kunden ret til at skifte, og fra 12. januar 2027 må der ikke opkræves skiftegebyrer. | Eksportformater, den tilbudte bistand ved overgangen, og hvor længe data er tilgængelige efter opsigelse. |
| [ ] | 39 | Løbetid og opsigelse. Kontraktens løbetid, opsigelsesvarsel, eventuelle gebyrer ved ophør og overgangsperioden. | Lange bindingsperioder og ophørsgebyrer afgør, hvad en exit koster. | De kommercielle vilkår og ophørsbestemmelsen. |

## 11. Support og SLA

| Skal | Nr. | Krav | Hvorfor det betyder noget | Dokumentation at bede om |
| --- | --- | --- | --- | --- |
| [ ] | 40 | Oppetids-SLA. Et månedligt tilgængelighedstilsagn med servicekreditter, målemetoden og undtagelserne. | AI rykker ind i produktionsprocesser, hvor nedetid koster penge. | SLA-dokumentet, den offentlige statusside og tilgængeligheden de seneste 12 måneder. |
| [ ] | 41 | Failover mellem udbydere. Når en modeludbyder er utilgængelig, skifter forespørgsler til en anden godkendt udbyder af samme model, inden for regions- og listereglerne. | En failover, der ignorerer regionen eller listen, bryder reglerne netop, når en hændelse allerede er i gang. | Failoverdesignet og antallet af udbydere pr. model under hver regionsregel. |
| [ ] | 42 | Support og kommunikation ved hændelser. Supportkanaler, svartider efter alvorlighed, sprog, og hvordan hændelser kommunikeres. | Ordregiverens egen hændelsesproces afhænger af leverandørens. | Supportpolitikken, statussidens URL og nylige hændelsesrapporter. |
| [ ] | 43 | Sikkerhedsdokumentation. En sikkerhedsoversigt, et udfyldt sikkerhedsspørgeskema og de erklæringer eller certificeringer, leverandøren og dennes hostingudbydere har. | Det er det, ordregiverens sikkerhedsteam gennemgår før godkendelse. At bede om det sammen med udbuddet sparer en runde. | Sikkerhedssiden, et udfyldt spørgeskema som det åbne sikkerhedsspørgeskema for LLM-gateways (https://standardcompute.com/sikkerhedsspoergeskema-llm-gateway) og eventuelle erklæringer. |

---

## Kilder

- [Opdaterede EU-modelkontraktbestemmelser for AI (MCC-AI High Risk og Light), Public Buyers Community, 5. marts 2025](https://public-buyers-community.ec.europa.eu/communities/procurement-ai/resources/updated-eu-ai-model-contractual-clauses)
- [Forordning (EU) 2016/679, databeskyttelsesforordningen (GDPR), artikel 28 og 33, EUR-Lex](https://eur-lex.europa.eu/legal-content/DA/TXT/?uri=CELEX:32016R0679)
- [Forordning (EU) 2024/1689, forordningen om kunstig intelligens, artikel 4, 26, 50 og 53, EUR-Lex](https://eur-lex.europa.eu/legal-content/DA/TXT/?uri=CELEX:32024R1689)
- [Forordning (EU) 2023/2854, dataforordningen (Data Act), kapitel VI om skift mellem 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 kravspecifikation til udbud af en LLM-gateway eller AI-platform fra https://standardcompute.com/kravspecifikation-ai-platform-udbud (version 9. november 2026). Fri til at kopiere og redigere. Ikke juridisk rådgivning._