Stacken

För upphandlare och granskare

Krav att ställa på en AI-tjänst i offentlig sektor.

Listan är för er som ska upphandla, avropa eller godkänna en AI-tjänst i offentlig sektor: upphandlare, IT-chefer, informationssäkerhet och dataskyddsombud.

Så använder ni listan.

Varje krav har en kravtext som ni kan kopiera, ett förslag på om det ska vara ett ska-krav eller ett bör-krav, varför kravet finns och hur ni kontrollerar svaret. Ett ska-krav måste mötas för att anbudet ska kunna antas. Ett bör-krav kan ni utvärdera eller ge mervärde för. Välj de krav som passar er behovsanalys och riskbedömning, och flytta krav mellan ska och bör efter er situation.

Kraven beskriver vad tjänsten ska åstadkomma, inte hur den ska vara byggd. De är formulerade för att vara proportionerliga och för att inte peka ut en viss leverantör eller teknik, så som lagen om offentlig upphandling kräver (4 kap. 1 § och 9 kap.). Ändrar ni en kravtext, pröva att den fortfarande går att möta med likvärdiga lösningar.

Lagstödet är angivet med artikel eller paragraf så att ni hittar det. Det är inte en rättslig bedömning av er verksamhet. Stäm av lagstödet med er egen jurist. Det gäller särskilt AI-förordningen: kraven för högrisksystem gäller bara system som är högrisk, och för system enligt bilaga III tillämpas de från 2027-12-02 efter förordning (EU) 2026/1744.

Ni får kopiera och ändra kraven fritt.

Förkortningar: GDPR är dataskyddsförordningen (EU) 2016/679. AI-förordningen är förordning (EU) 2024/1689. NIS2 är direktiv (EU) 2022/2555, i Sverige genomfört genom cybersäkerhetslagen (2025:1506). Dataförordningen är förordning (EU) 2023/2854. LOU är lagen (2016:1145) om offentlig upphandling.

Ladda ned hela listan som CSV, som öppnas i Excel.

AStyrning och regler

KL-01

Ett gemensamt styrlager för AI-anrop

ska-krav

Kravtext

Anrop till språkmodeller och till anslutna verktyg och informationskällor inom den omfattning som anges i avtalet ska passera ett gemensamt styrlager där beställarens regler prövas innan anropet genomförs. Leverantören ska redovisa vilka anropsvägar som omfattas och vilka som inte gör det.

Varför
GDPR art. 24, 25 och 32 kräver lämpliga tekniska och organisatoriska åtgärder och inbyggt dataskydd. Utan en gemensam väg finns ingen plats där reglerna kan verkställas. För högrisksystem även AI-förordningen art. 26.1.
Så verifierar ni
Leverantören visar arkitekturen och ett nekat anrop. Leverantören visar hur det kontrolleras att ingen komponent når en modell eller ett verktyg förbi styrlagret, till exempel med en automatisk kontroll i bygget eller med nätverksregler, och lämnar en förteckning över anropsvägar som omfattas.
KL-02

Reglerna ligger utanför modellen

ska-krav

Kravtext

Regler för åtkomst, modellval och verktygsanvändning ska utvärderas av en komponent som är skild från språkmodellen, vara versionshanterade och kunna testas. Regler får inte enbart uttryckas som instruktioner till modellen.

Varför
GDPR art. 25 och 32. En instruktion till modellen kan förhandlas bort av användarens egen text.
Så verifierar ni
Leverantören visar en regel, dess version och dess tester, och ett anrop som nekas trots att användaren ber modellen att strunta i regeln.
KL-03

Stopp när en kontroll inte kan genomföras

ska-krav

Kravtext

Om regelprövning, identifiering av användaren eller skrivning till revisionsloggen inte kan genomföras ska anropet nekas. Tjänsten får inte falla tillbaka till ett läge utan kontroll.

Varför
GDPR art. 32.1 b om konfidentialitet och integritet. Etablerad praxis för säkerhetskritiska kontroller.
Så verifierar ni
Leverantören stänger av regelkomponenten respektive loggkomponenten i en testmiljö och visar att anropet nekas och att ingenting når modellen.
KL-04

Informationsklass styr modellval

ska-krav

Kravtext

Beställaren ska kunna ange vilka modeller som är godkända för varje informationsklass. Ett anrop med information av en viss klass ska nekas om den valda modellen inte är godkänd för klassen. Kravet gäller alla modellanrop i kedjan, även inbäddning, omrangordning, transkribering och andra stödmodeller.

Varför
GDPR art. 25 och 32. Beställarens egen informationsklassning, till exempel enligt metodstödet från Myndigheten för civilt försvar (tidigare MSB).
Så verifierar ni
Leverantören visar ett tillåtet och ett nekat anrop, för chatt och för minst en stödmodell, och att tjänsten inte väljer en reservmodell utanför den godkända listan.
KL-05

Behandling utanför EU/EES kräver beslut

ska-krav

Kravtext

Användning av en modell som behandlar data utanför EU/EES ska kräva ett uttryckligt beslut av beställaren per AI-tjänst. Beställaren ska kunna se var varje tillgänglig modell behandlar data.

Varför
GDPR kap. V, art. 44 till 49 om överföring till tredjeland.
Så verifierar ni
Leverantören visar förteckningen över modeller med behandlingsplats, och att en tjänst utan beslut inte kan använda en modell utanför EU/EES.
KL-06

Byte av modell utan ombyggnad

ska-krav

Kravtext

Beställaren ska kunna byta språkmodell för en AI-tjänst genom konfiguration, utan att tjänstens instruktioner, kunskapskällor eller integrationer behöver byggas om.

Varför
Praxis. Minskar beroendet av en enskild modelleverantör när modeller ändras, blir dyrare eller upphör.
Så verifierar ni
Leverantören byter modell för en tjänst under en visning och visar att samma frågor fungerar.
KL-07

Godkända verktygskopplingar med behörighet per person eller grupp

ska-krav

Kravtext

Bara kopplingar till verktyg och informationskällor som beställarens administratör har godkänt ska kunna användas. Åtkomst till en koppling ska kunna ges per person eller grupp, och varje ändring ska loggas.

Varför
GDPR art. 32. Cybersäkerhetslagen och NIS2 art. 21.2 i om åtkomstkontroll.
Så verifierar ni
En administratör ger en grupp åtkomst till en koppling, en person utanför gruppen nekas, och ändringen syns i loggen.

Till områdena

BSpårbarhet och logg

KL-08

Revisionsloggen skrivs innan svaret lämnas

ska-krav

Kravtext

Varje regelbeslut och varje anrop till modell eller verktyg ska skrivas till en revisionslogg innan svaret eller åtgärden lämnas ut. Kan posten inte skrivas ska anropet nekas.

Varför
GDPR art. 5.2 (ansvarsskyldighet) och art. 32. För högrisksystem AI-förordningen art. 12 och art. 26.6, som kräver att loggar sparas i minst sex månader.
Så verifierar ni
Leverantören visar en loggpost för ett nekat anrop, och att ett fel i loggskrivningen stoppar anropet.
KL-09

Ändringar i loggen upptäcks

ska-krav

Kravtext

Revisionsloggen ska vara skyddad så att en ändrad eller borttagen post kan upptäckas vid kontroll.

Varför
GDPR art. 32.1 b om integritet. NIS2 art. 21.
Så verifierar ni
Leverantören ändrar en post i en testmiljö och visar att kontrollen upptäcker det.
KL-10

Loggen går att lita på även mot leverantören

bör-krav

Kravtext

Beställaren ska kunna verifiera revisionsloggens integritet utan leverantörens medverkan, och loggen ska vara skyddad även mot den som driftar tjänsten, till exempel genom förankring hos tredje part eller nycklar som leverantören inte kontrollerar.

Varför
GDPR art. 5.2. Praxis när leverantören både driftar tjänsten och har administrativ åtkomst till den.
Så verifierar ni
Leverantören lämnar verktyg och instruktion för er egen kontroll av loggen och redovisar vem som kan radera eller återställa den.
KL-11

Loggposten visar vem, vad och vilken regel

ska-krav

Kravtext

En loggpost ska visa vilken person och vilken AI-tjänst som gjorde anropet, tid, vilken modell eller vilket verktyg som användes, vilket regelbeslut som fattades och ett gemensamt spår-id som binder ihop anropets delar.

Varför
GDPR art. 5.2 och art. 30. För högrisksystem AI-förordningen art. 12.
Så verifierar ni
Leverantören följer ett anrop från fråga till svar med spår-id och visar posterna.
KL-12

Loggen minimerar personuppgifter

ska-krav

Kravtext

Revisionsloggen ska inte innehålla mer personuppgifter än nödvändigt. Frågor och svar ska bara sparas om beställaren har beslutat det, och då med en bestämd lagringstid och särskild läsbehörighet.

Varför
GDPR art. 5.1 c och e (minimering och lagringsbegränsning) och art. 25.
Så verifierar ni
Leverantören visar en loggpost och inställningen för att spara frågor och svar, av och på.
KL-13

Användning och kostnad syns per tjänst, modell och grupp

ska-krav

Kravtext

Beställaren ska kunna se användning och kostnad per AI-tjänst, modell, grupp och period. Saknat mätunderlag ska synas som saknat, inte som noll.

Varför
Praxis för ekonomisk styrning och uppföljning av avtalet.
Så verifierar ni
Leverantören visar rapporten efter ett känt antal testanrop.
KL-14

Kostnadstak

bör-krav

Kravtext

Beställaren ska kunna sätta tak för kostnad eller förbrukning, så att en enskild tjänst eller grupp inte kan förbruka obegränsat.

Varför
Praxis för ekonomisk styrning.
Så verifierar ni
Leverantören visar ett tak som nås och ett anrop som därefter nekas.

Till områdena

CÅtkomst och informationssäkerhet

KL-15

Inloggning med beställarens identitetslösning

ska-krav

Kravtext

Inloggning ska ske via beställarens identitetsleverantör med en öppen standard (SAML 2.0 eller OpenID Connect). Gruppmedlemskap från identitetsleverantören ska kunna styra åtkomst.

Varför
NIS2 art. 21.2 i och j om åtkomstkontroll och flerfaktorsautentisering. GDPR art. 32.
Så verifierar ni
Inloggning mot er testmiljö för identitet, och en användare utanför godkänd grupp som nekas.
KL-16

Roller och minsta behörighet

ska-krav

Kravtext

Rättigheter att använda, skapa och administrera AI-tjänster ska vara skilda roller, och varje användare ska bara ha de rättigheter rollen kräver.

Varför
NIS2 art. 21.2 i. GDPR art. 32.
Så verifierar ni
En användare utan rätt att skapa tjänster försöker skapa eller ändra en tjänst, både i gränssnittet och via API, och nekas.
KL-17

Identiteten följer anropet hela vägen

ska-krav

Kravtext

Användarens identitet ska följa anropet till de informationskällor och verktyg som anropas, så att källans egna behörigheter gäller. En gemensam tjänsteidentitet får inte ersätta användaren.

Varför
GDPR art. 5.1 f (integritet och konfidentialitet) och art. 32.
Så verifierar ni
Två användare med olika behörighet i en källa ställer samma fråga och får olika svar, och källans egen logg visar rätt person.
KL-18

Ingen oidentifierad trafik

ska-krav

Kravtext

Anrop från en användare som inte kan identifieras ska nekas, utom för tjänster som beställaren uttryckligen gjort publika.

Varför
GDPR art. 32. Praxis.
Så verifierar ni
Ett anrop utan giltig identitet nekas och loggas.
KL-19

Kunskapssökning respekterar källans behörighet

ska-krav

Kravtext

När en AI-tjänst söker i beställarens dokument ska användaren bara få svar, citat, titlar och källhänvisningar från dokument hen har behörighet till i källsystemet.

Varför
GDPR art. 5.1 f. Offentlighets- och sekretesslagen (2009:400) när handlingarna omfattas av sekretess.
Så verifierar ni
Två användare med olika behörighet till dokument ställer samma fråga. Den som saknar behörighet får varken svar, titel eller filnamn.
KL-20

Separation mellan kunder

bör-krav

Kravtext

Beställarens data och tjänster ska vara separerade från andra kunders. Leverantören ska beskriva separationen (instans, databas, nätverk, nycklar) och hur den kontrolleras.

Varför
GDPR art. 32. NIS2 art. 21.
Så verifierar ni
Leverantören lämnar en arkitekturbeskrivning och visar ett prov där en annan kunds tjänst inte nås.
KL-21

Kryptering

ska-krav

Kravtext

Data ska vara krypterade under överföring (minst TLS 1.2) och vid lagring. Leverantören ska redovisa hur nycklar hanteras och vem som har åtkomst till dem.

Varför
GDPR art. 32.1 a. NIS2 art. 21.2 h om kryptografi och kryptering.
Så verifierar ni
Leverantören lämnar en redovisning av konfigurationen. Ni testar själva vilken TLS-version tjänsten svarar med.
KL-22

Tekniskt skydd mot personuppgifter i inmatningen

bör-krav

Kravtext

Tjänsten ska kunna upptäcka och maska personnummer och liknande identifierare innan de når en modell eller loggen, enligt beställarens regel. Leverantören ska redovisa skyddets kända begränsningar.

Varför
GDPR art. 25. Ett tekniskt skydd kompletterar villkor och instruktioner till användarna.
Så verifierar ni
Ett testpersonnummer i en fråga stoppas eller ersätts innan det når modellen. Leverantören redovisar träffsäkerhet och vilka slags uppgifter skyddet missar.
KL-23

Utgående trafik bara till godkända mål

bör-krav

Kravtext

AI-tjänster och tillhörande komponenter ska bara kunna skicka data till mål som beställaren har godkänt.

Varför
GDPR art. 32. NIS2 art. 21.
Så verifierar ni
Ett nätverksprov där ett anrop till ett mål som inte är godkänt stoppas.
KL-24

Säker utveckling och leveranskedja

ska-krav

Kravtext

Leverantören ska ha en dokumenterad process för säker utveckling, sårbarhetshantering och uppdateringar. Programpaket ska vara signerade och ha en förteckning över beståndsdelar (SBOM) som beställaren kan få.

Varför
NIS2 art. 21.2 d och e om leveranskedjan och säkerhet vid utveckling och underhåll. Cyberresiliensförordningen (EU) 2024/2847 där den är tillämplig.
Så verifierar ni
Leverantören lämnar processbeskrivningen, en SBOM och visar en verifierad signatur för en aktuell version.

Till områdena

DDataskydd

KL-25

Data inom EU/EES

ska-krav

Kravtext

Beställarens data, inklusive loggar, metadata, konfiguration och säkerhetskopior, ska lagras och behandlas inom EU/EES. Undantag kräver beslut enligt KL-05.

Varför
GDPR kap. V, art. 44 till 49.
Så verifierar ni
Leverantören lämnar en förteckning över lagringsplatser per datatyp och per underbiträde.
KL-26

Ingen träning på beställarens data

ska-krav

Kravtext

Beställarens data får inte användas för att träna eller förbättra modeller. Modelleverantörer ska inte lagra frågor och svar utöver vad som krävs för att leverera svaret. Kravet ska gälla hela kedjan av underbiträden och redovisas per modell.

Varför
GDPR art. 5.1 b (ändamålsbegränsning) och art. 28.
Så verifierar ni
Leverantören lämnar avtalsvillkoren per modelleverantör och visar inställningarna.
KL-27

Personuppgiftsbiträdesavtal med underbiträden

ska-krav

Kravtext

Leverantören ska teckna personuppgiftsbiträdesavtal enligt GDPR art. 28 med en förteckning över underbiträden, land och ändamål, och ge beställaren möjlighet att invända mot nya underbiträden.

Varför
GDPR art. 28.2 till 28.4.
Så verifierar ni
Leverantören lämnar avtalsmallen och den aktuella förteckningen över underbiträden.
KL-28

Radering som når kopiorna

ska-krav

Kravtext

Personuppgifter ska kunna raderas på begäran, och raderingen ska omfatta härledda kopior som index, sammanfattningar och cache. Vid avtalets slut ska data raderas eller lämnas tillbaka inom avtalad tid, med kvitto.

Varför
GDPR art. 17 och art. 28.3 g.
Så verifierar ni
En testanvändare raderas. Leverantören visar vad som finns kvar och var.

Till områdena

EDrift

KL-29

Övervakning och larm

ska-krav

Kravtext

Tjänstens komponenter ska övervakas så att fel och avbrott upptäcks, och larm ska gå till en bemannad mottagare.

Varför
NIS2 art. 21.2 b om incidenthantering.
Så verifierar ni
Leverantören visar larmreglerna och ett provlarm.
KL-30

Säkerhetskopiering med bevisad återställning

ska-krav

Kravtext

Data ska säkerhetskopieras till en annan fysisk plats, och återställning ska provas regelbundet för den miljö beställaren använder.

Varför
GDPR art. 32.1 c. NIS2 art. 21.2 c om kontinuitet.
Så verifierar ni
Leverantören lämnar protokollet från det senaste återställningsprovet.

Till områdena

FModeller och integrationer

KL-31

Flera modeller, även sådana som drivs inom EU

ska-krav

Kravtext

Beställaren ska kunna välja mellan flera språkmodeller, varav minst en som drivs inom EU/EES, och välja modell per AI-tjänst.

Varför
Praxis mot inlåsning. Förutsättning för KL-05 och KL-25.
Så verifierar ni
Leverantören visar förteckningen över modeller och ett modellval per tjänst.
KL-32

Svar med källhänvisning

ska-krav

Kravtext

När en AI-tjänst svarar ur beställarens kunskapskällor ska svaret ange vilka källor det bygger på, och tjänsten ska kunna avstå från att svara när underlaget saknas.

Varför
Förvaltningslagen (2017:900) 32 § om motivering av beslut, när tjänsten används som stöd i handläggning. Praxis.
Så verifierar ni
Ett svar med källor, och ett avstående när källa saknas.
KL-33

Verktyg via öppet protokoll

ska-krav

Kravtext

Kopplingar till verktyg och informationskällor ska kunna göras via ett öppet, dokumenterat protokoll (till exempel Model Context Protocol eller likvärdigt), utan kodändring hos leverantören.

Varför
LOU 9 kap.: tekniska specifikationer ska tillåta likvärdiga lösningar. Praxis.
Så verifierar ni
En ny koppling registreras och används under en visning.

Till områdena

GLeverantör och exit

KL-34

Export i öppna format

ska-krav

Kravtext

Beställaren ska kunna exportera sina data, konfiguration, loggar och kunskapsunderlag i öppna, dokumenterade format, utan tekniska eller ekonomiska hinder.

Varför
Dataförordningen kap. VI, art. 23 till 31 om byte av databehandlingstjänst. Avgifter för byte förbjuds från 2027-01-12. GDPR art. 20 för personuppgifter.
Så verifierar ni
Leverantören gör en export av testdata och lämnar en beskrivning av formatet.
KL-35

Ledningssystem för informationssäkerhet och AI

ska-krav

Kravtext

Leverantören ska ha ett ledningssystem för informationssäkerhet och ett för AI, certifierade enligt ISO/IEC 27001 respektive ISO/IEC 42001 eller likvärdigt, och redovisa omfattning och tillämplighetsförklaring.

Varför
Praxis. GDPR art. 32.3 och art. 42 om certifiering som stöd för att visa lämpliga åtgärder. LOU kräver att likvärdiga bevis godtas.
Så verifierar ni
Leverantören lämnar certifikat, omfattning och tillämplighetsförklaring.

Till områdena

Listan är sammanställd av Digitalist, som bygger och driver Stacken. Säkerhet och dataskydd i Stacken

Se hur Stacken svarar på kraven.

Boka demo och samtal Ta med kravlistan till visningen.