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) til AI-specifikke kontraktvilkår. De blev offentliggjort i marts 2025 i Europa-Kommissionens Public Buyers Community.
Download kravspecifikationen (.md)Regneark (.csv)
CSV-filen åbner i Excel, Google Sheets eller Numbers, med tomme kolonner til vægtning, tilbudsgiverens svar og modtaget dokumentation.
Kravene
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
| 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. | Hvorfor det betyder nogetGateways 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. | Dokumentation at bede omRoutingpolitikken 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. | Hvorfor det betyder nogetSalgsmateriale bruger ofte Europa og EU i flæng. Jeres vurdering af overførsler afhænger af den præcise liste. | Dokumentation at bede omEn 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. | Hvorfor det betyder nogetEn forespørgsel kan blive betjent af en model i den rigtige region og alligevel først passere et globalt edge-netværk. | Dokumentation at bede omVæ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. | Hvorfor det betyder nogetSvar om dataplacering dækker ofte kun prompts. Metadata indeholder stadig personoplysninger som navne, e-mailadresser og IP-adresser. | Dokumentation at bede omEn lagringsplacering pr. datakategori, herunder backup og transaktionel e-mail. |
2. Opbevaringstid og nul dataopbevaring
| 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. | Hvorfor det betyder nogetGatewayen ser hver prompt, jeres organisation sender. Dens egen opbevaring er den første risiko, I skal kontrollere. | Dokumentation at bede omEn 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. | Hvorfor det betyder nogetModeludbydere opbevarer normalt prompts i en periode til misbrugsovervågning, medmindre der gælder en aftale om nul dataopbevaring for endpointet. | Dokumentation at bede omOpbevaringsvilkå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. | Hvorfor det betyder nogetTilsagn om opbevaring har som regel undtagelser for bestemte funktioner. Listen viser, hvor undtagelserne ligger. | Dokumentation at bede omEn 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. | Hvorfor det betyder nogetArtikel 28, stk. 3, litra g), i databeskyttelsesforordningen kræver, at databehandleraftalen regulerer sletning eller tilbagelevering ved ophør af behandlingstjenesterne. | Dokumentation at bede omBestemmelsen i databehandleraftalen med fristen, håndteringen af backup og et eksempel på en sletningsbekræftelse. |
3. Træning og brug af data
| 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. | Hvorfor det betyder nogetTræning er den anvendelse, ordregivere oftest udelukker, og udelukkelsen binder kun, når den står i kontrakten. | Dokumentation at bede omBestemmelsen 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. | Hvorfor det betyder nogetGatewayens eget tilsagn binder ikke modeludbyderne bag den. | Dokumentation at bede omUdbydervilkå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. | Hvorfor det betyder nogetSekundær brug ligger uden for de instrukser, en dataansvarlig giver en databehandler, medmindre den er aftalt. | Dokumentation at bede omEn liste over sekundær brug, politikken for menneskelig gennemgang og indstillingen til fravalg. |
4. Underdatabehandlere og databehandleraftale
| 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. | Hvorfor det betyder nogetArtikel 28, stk. 3, fastlægger, hvad aftalen med databehandleren skal indeholde. En gateway behandler personoplysninger i hver prompt, der nævner en person. | Dokumentation at bede omTeksten 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. | Hvorfor det betyder nogetFor en gateway er hver modeludbyder, der kan betjene jeres trafik, en underdatabehandler. | Dokumentation at bede omListens 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. | Hvorfor det betyder nogetArtikel 28, stk. 2, kræver, at den dataansvarlige underrettes om ændringer og får mulighed for at gøre indsigelse. | Dokumentation at bede omBestemmelsen 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). | Hvorfor det betyder nogetOverførsler kræver et retsgrundlag efter kapitel V i databeskyttelsesforordningen, og ordregiveren dokumenterer sin vurdering. | Dokumentation at bede omBilagene 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. | Hvorfor det betyder nogetDen dataansvarlige har efter artikel 33 72 timer til at anmelde til tilsynsmyndigheden, så databehandlerens frist skal være kortere eller lige så lang. | Dokumentation at bede omBestemmelsen i databehandleraftalen, et resumé af processen for håndtering af hændelser og sikkerhedskontakten. |
5. Identitet og adgang
| 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. | Hvorfor det betyder nogetArbejdskonti knytter adgangen til ansættelsesforholdet, med ordregiverens MFA- og login-politikker. | Dokumentation at bede omUnderstø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. | Hvorfor det betyder nogetSSO ved siden af adgangskoder efterlader konti uden for identitetsudbyderens kontrol. | Dokumentation at bede omIndstillingen, 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. | Hvorfor det betyder nogetUden deprovisionering beholder fratrådte medarbejdere adgangen, indtil nogen husker at fjerne den. | Dokumentation at bede omDe 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. | Hvorfor det betyder nogetDelte nøgler skjuler, hvem der sendte hvilken forespørgsel, og kan ikke tilbagekaldes for én person. | Dokumentation at bede omRollematrixen 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. | Hvorfor det betyder nogetDet er i disse værktøjer, private konti og kopierede nøgler dukker op uden for indkøbet. | Dokumentation at bede omOpsætningsvejledningen og listen over understøttede værktøjer. |
6. Udgiftsstyring
| 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. | Hvorfor det betyder nogetAgenter og batchjob kan bruge et månedsbudget på få timer. En grænse, der kun advarer, er en rapport. | Dokumentation at bede omDe 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. | Hvorfor det betyder nogetØkonomiafdelingen har brug for ét tal, der ikke kan overskrides, uanset hvad der sker nedenunder. | Dokumentation at bede omIndstillingerne 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. | Hvorfor det betyder nogetTokenpriser varierer mellem modeller med flere størrelsesordener, så evalueringen kræver prisgrundlaget og rapporteringen. | Dokumentation at bede omPrislisten, en eksempelfaktura og en eksempelrapport over forbrug. |
7. Modeladgang og tilladte lister
| 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. | Hvorfor det betyder nogetEn model, der ikke er tilgængelig i jeres region, er ikke tilgængelig for jer, når regionsreglen er slået til. | Dokumentation at bede omEn 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. | Hvorfor det betyder nogetEn godkendelse af en model, der kun står i et politikdokument, forhindrer ingen i at kalde en anden model. | Dokumentation at bede omIndstillingen 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. | Hvorfor det betyder nogetEn udbyder, som leverandøren tilføjer, er et nyt sted, hvor jeres data behandles. | Dokumentation at bede omIndstillingen, 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. | Hvorfor det betyder nogetEt stille modelskift ændrer outputtets kvalitet og kan gøre evalueringen af en anvendelse ugyldig. | Dokumentation at bede omPolitikken 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. | Hvorfor det betyder nogetAutomatisk routing har kun værdi, hvis I kan se, hvor hver forespørgsel gik hen. | Dokumentation at bede omRoutingdokumentationen og et eksempel på en post pr. forespørgsel. |
8. Auditlogs og eksport
| 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. | Hvorfor det betyder nogetRevisorer 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. | Dokumentation at bede omEt 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. | Hvorfor det betyder nogetVed 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. | Dokumentation at bede omFeltlisten, opbevaringsperioden og et eksempel på en eksport. |
| 32 | Eksport. Logfiler kan eksporteres som CSV eller via et API og sendes til ordregiverens SIEM. | Hvorfor det betyder nogetData, ordregiveren ikke kan få ud, kan ikke bruges i dennes egen revision. | Dokumentation at bede omFormater, begrænsninger på rækker eller tidsrum og API-dokumentation. |
9. Idriftsætterens forpligtelser efter AI-forordningen
| 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. | Hvorfor det betyder nogetArtikel 4 har gældet siden 2. februar 2025, og en oversigt er udgangspunktet for alle andre forpligtelser i AI-forordningen. | Dokumentation at bede omOplysninger 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. | Hvorfor det betyder nogetIdriftsætterens forpligtelser for bilag III gælder fra 2. december 2027 og afhænger af oplysninger, som kun leverandøren og modeludbyderen har. | Dokumentation at bede omLeverandø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. | Hvorfor det betyder nogetArtikel 53 forpligter udbydere af AI-modeller til almen brug til at stille dette til rådighed, og ordregivere arkiverer det pr. model. | Dokumentation at bede omLinks 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. | Hvorfor det betyder nogetGennemsigtighedsforpligtelserne i artikel 50 gælder fra 2. august 2026. | Dokumentation at bede omOplysninger om mærkning pr. model og vejledning om oplysning. |
10. Exit og portabilitet
| 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. | Hvorfor det betyder nogetEn proprietær grænseflade gør et leverandørskift til et softwareprojekt. | Dokumentation at bede omAPI-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. | Hvorfor det betyder nogetEr 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. | Dokumentation at bede omEksportformater, 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. | Hvorfor det betyder nogetLange bindingsperioder og ophørsgebyrer afgør, hvad en exit koster. | Dokumentation at bede omDe kommercielle vilkår og ophørsbestemmelsen. |
11. Support og SLA
| Nr. | Krav | Hvorfor det betyder noget | Dokumentation at bede om |
|---|---|---|---|
| 40 | Oppetids-SLA. Et månedligt tilgængelighedstilsagn med servicekreditter, målemetoden og undtagelserne. | Hvorfor det betyder nogetAI rykker ind i produktionsprocesser, hvor nedetid koster penge. | Dokumentation at bede omSLA-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. | Hvorfor det betyder nogetEn failover, der ignorerer regionen eller listen, bryder reglerne netop, når en hændelse allerede er i gang. | Dokumentation at bede omFailoverdesignet 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. | Hvorfor det betyder nogetOrdregiverens egen hændelsesproces afhænger af leverandørens. | Dokumentation at bede omSupportpolitikken, 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. | Hvorfor det betyder nogetDet er det, ordregiverens sikkerhedsteam gennemgår før godkendelse. At bede om det sammen med udbuddet sparer en runde. | Dokumentation at bede omSikkerhedssiden, et udfyldt spørgeskema som det åbne sikkerhedsspørgeskema for LLM-gateways og eventuelle erklæringer. |
Sådan svarer Standard Compute
Standard Compute er en europæisk AI-gateway: én virksomhedskonto og ét API til Claude, GPT, Gemini og åbne modeller, drevet af Standard Compute AS i Oslo. Her er vores svar på kravene ovenfor, med samme formuleringer som på vores sikkerhedsside og i vores databehandleraftale. Numrene henviser til rækkerne i kravspecifikationen.
| Nr. | Status | Vores svar |
|---|---|---|
| Nr. 1 | Tilgængelig, slås til | Sæt en Europa-regel for jeres virksomhed, et team eller en enkelt nøgle, og hver forespørgsel, også nye forsøg og reserveruter, betjenes kun af godkendte europæiske inferens-endpoints. Kan intet europæisk endpoint betjene den, afvises forespørgslen, før jeres prompt sendes. |
| Nr. 2 | Tilgængelig | En Europa-regel tillader kun de godkendte europæiske inferens-endpoints, der står på vores liste over underdatabehandlere, hver med sit behandlingssted. |
| Nr. 3 | Tilgængelig | Vores EU-gateway på eu.stdcmpt.com terminerer TLS og kører i Finland, og jeres kontodata lagres i Frankfurt. |
| Nr. 4 | Tilgængelig | Jeres konto- og forbrugsdata lagres i Frankfurt, Tyskland. Forespørgselsposter indeholder kun metadata (model, udbyder, tokens, omkostning og status), aldrig jeres prompts eller output. Hver underdatabehandler på platformen er opført med sin placering. |
| Nr. 5 | Tilgængelig | Vi behandler jeres prompts i hukommelsen for at betjene hver forespørgsel og skriver dem aldrig til lager eller logfiler. |
| Nr. 6 | Tilgængelig, slås til | Slå nul dataopbevaring til for jeres virksomhed, et team eller en nøgle, og hver forespørgsel går kun til inferens-endpoints, der forpligter sig til ikke at beholde nogen kopi af jeres data. Teams og nøgler arver kravet og kan aldrig slå det fra under jer. |
| Nr. 8 | Tilgængelig | Databehandleraftalen fastsætter sletning eller tilbagelevering af alle øvrige personoplysninger om kunden inden for 30 dage efter ophør (punkt 10). |
| Nr. 9, 10 | Tilgængelig | Standard Compute træner aldrig på jeres prompts eller output. Med en regionsregel eller nul dataopbevaring slået til går hver forespørgsel kun til udbydere, der forpligter sig til ikke at træne på den. |
| Nr. 12, 16 | Tilgængelig | Underskriv vores databehandleraftale i dashboardet på få minutter. Den forpligter os til ingen træning på jeres data, ingen opbevaring af jeres indhold og underretning om brud inden for 72 timer. Databehandleraftalen er underlagt norsk ret. |
| Nr. 13, 14 | Tilgængelig | Vi offentliggør hver underdatabehandler med formål, data og placering og giver jer 14 dages varsel, før vi tilføjer en ny. |
| Nr. 15 | Tilgængelig | Overførsler uden for EØS eller Storbritannien til et land uden afgørelse om tilstrækkeligt beskyttelsesniveau er omfattet af EU's standardkontraktbestemmelser og, for data fra Storbritannien, UK IDTA (databehandleraftalen punkt 6). |
| Nr. 17 | Tilgængelig | Forbind Microsoft Entra ID eller en anden SAML-identitetsudbyder, så jeres medarbejdere logger ind på Standard Compute med deres arbejdskonti. Alle på jeres verificerede domæne bliver automatisk en del af jeres virksomhed. |
| Nr. 18 | Delvist | SAML-login er tilgængeligt for alle virksomheder med SSO. Login med adgangskode er fortsat tilgængeligt ved siden af, så SSO er ikke den eneste vej ind. |
| Nr. 19, 21 | Tilgængelig | Medarbejdere logger ind i Claude Desktop og Claude Code med deres Microsoft-arbejdskonto via vores EU-gateway, så der ikke skal udleveres API-nøgler. Adgangen følger jeres Microsoft Entra-grupper via SCIM-provisionering. |
| Nr. 20 | Tilgængelig | Opdel jeres virksomhed i teams, invitér kolleger via e-mail, og giv hver person og hver app sin egen nøgle, alt sammen under én virksomhedskonto. Rollerne er administrator og medlem. |
| Nr. 22, 23 | Delvist | Hver person og hver app får et fast månedsbudget, der aldrig overskrides, og I kan sætte udgiftslofter pr. nøgle og for hele virksomheden. Der er intet separat budget pr. team: teams styres gennem budgetterne for deres personer og apps. |
| Nr. 24 | Tilgængelig | Faste månedlige abonnementer pr. person eller app, uden overraskelser pr. token, og Stripe-fakturaer med jeres firmanavn og momsnummer. Priserne er i amerikanske dollar. |
| Nr. 25 | Tilgængelig | Brug førende åbne modeller, blandt andet GLM, DeepSeek, MiniMax og Kimi, sammen med Claude, GPT og Gemini via ét API. GLM, DeepSeek og MiniMax leveres også af europæiske udbydere til arbejdsområder, der er begrænset til Europa. |
| Nr. 26 | Tilgængelig | Bestem, hvilke modeller hver nøgle må bruge, så hver app og hvert teammedlem får præcis de modeller, I godkender. |
| Nr. 27 | Tilgængelig | Vælg præcist, hvilke inferensudbydere der må håndtere jeres data, for hele virksomheden, et team eller en enkelt nøgle. Lavere niveauer kan kun indsnævre reglerne, nye udbydere tilføjes aldrig uden en administrators godkendelse, og reserveruter kan aldrig gå uden om jeres liste. |
| Nr. 29 | Tilgængelig | Hvert trin går til den billigste model, der kan løse det, og den billigste udbyder, der er hurtig nok, og forespørgselsposten viser den model og den udbyder, der betjente forespørgslen. |
| Nr. 30, 31, 32 | Tilgængelig | Hver administratorændring registreres med værdien før og efter, og I kan eksportere en post for hver forespørgsel med modellen, den udbyder, der betjente den, og den gældende regionsregel, opbevaret i 12 måneder. Eksporter er CSV. |
| Nr. 33 | Tilgængelig | En nøgle pr. person og pr. app, de modeller hver nøgle må bruge, og model og betjenende udbyder for hver forespørgsel: de poster, vores tjekliste til AI-forordningen for idriftsættere beder om. |
| Nr. 37 | Tilgængelig | Ét OpenAI-kompatibelt API (chat completions-format) til alle modeller, beskrevet i API-referencen. |
| Nr. 40, 41 | Tilgængelig | Går en udbyder ned, skifter jeres forespørgsel automatisk til en anden godkendt udbyder af samme model uden at forlade jeres regions- eller udbyderregler. Enterprise omfatter en månedlig oppetids-SLA på 99,9 % med servicekreditter. Den aktuelle status er offentlig på /status. |
| Nr. 43 | Tilgængelig | Vores sikkerhedsside, vores udfyldte sikkerhedsspørgeskema, listen over underdatabehandlere og databehandleraftalen er offentlige. |
Rækker, der ikke er nævnt her, besvarer I i jeres tilbud sammen med jeres kontaktperson hos os. Kravspecifikationen ovenfor er fortsat leverandørneutral: brug den med enhver leverandør.
Spørgsmål
- Hvad skal et udbud af en LLM-gateway eller AI-platform indeholde?
- Hvor data behandles, hvad der opbevares, hvem der må træne på dem, underdatabehandlerne og databehandleraftalen, identitet og adgang (SSO, SCIM, nøgler), udgiftsstyring, hvilke modeller og udbydere der er tilladt, auditlogs og eksport, støtte til idriftsætterens forpligtelser efter AI-forordningen, exitvilkår og SLA. Denne kravspecifikation dækker hvert område med 43 krav og den dokumentation, I skal bede om.
- Kan offentlige ordregivere bruge kravspecifikationen i et udbud?
- Ja. Den må frit kopieres og tilpasses. Offentlige ordregivere bruger den typisk som bilag med de tekniske krav og vedlægger de frivillige EU-modelkontraktbestemmelser for AI (MCC-AI) til kontrakten. Kontrollér kravene mod jeres udbudsregler, og markér mindstekravene, før I offentliggør.
- Hvad er EU-modelkontraktbestemmelserne for AI?
- Standardbestemmelser til indkøb af AI-systemer, offentliggjort af Community of Practice on Public Procurement of AI i Europa-Kommissionens Public Buyers Community. Opdateringen fra marts 2025 har en fuld version til højrisiko-AI og en kort version (Light) til anden AI. De er frivillige og beregnet som bilag til en kontrakt, som stadig skal regulere databeskyttelse, ansvar og immaterielle rettigheder.
- Er en modeludbyder underdatabehandler for en AI-gateway?
- Som regel ja. Når en gateway sender prompts med personoplysninger videre til en modeludbyder, behandler udbyderen oplysningerne på gatewayens vegne. Derfor beder række 13 og 14 om en liste over underdatabehandlere, der omfatter inferensudbydere, og om varsel, før nye kommer til.
- Hvor længe bør en AI-platform opbevare forespørgselslogs?
- 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, medmindre anden lovgivning fastsætter andet. Mange ordregivere beder om 12 måneders forespørgselsposter med kun metadata og intet lagret indhold.
Kilder
- Opdaterede EU-modelkontraktbestemmelser for AI (MCC-AI High Risk og Light), Public Buyers Community, 5. marts 2025
- Forordning (EU) 2016/679, databeskyttelsesforordningen (GDPR), artikel 28 og 33, EUR-Lex
- Forordning (EU) 2024/1689, forordningen om kunstig intelligens, artikel 4, 26, 50 og 53, EUR-Lex
- Forordning (EU) 2023/2854, dataforordningen (Data Act), kapitel VI om skift mellem databehandlingstjenester, EUR-Lex
- RFC 7644, SCIM 2.0-protokollen og SAML 2.0 core, OASIS
Relateret
Besvar hele kravspecifikationen med én leverandør: en europæisk gateway til frontier- og åbne modeller, med alle kontroller på én virksomhedskonto.