Anbudssekretess enligt OSL 19 kap. 3 § vid användning av IT-verktyg och AI
När upphandlande myndigheter överväger AI-verktyg för att effektivisera anbudsanalysen uppstår omedelbart frågan om sekretess. Hur säkerställs att känsliga företagshemligheter och anbudspriser inte exponeras för obehöriga eller används för modellträning?
Sammanfattning
Enligt 19 kap. 3 § offentlighets- och sekretesslagen (2009:400) gäller sekretess för uppgifter i inkomna anbud fram till dess att relevant offentliggörande, leverantörsbeslut eller avbrytande inträffar enligt bestämmelsen. Att mata in oskyddade anbudshandlingar i publika molnbaserade AI-tjänster kan innebära ett röjande eller en otillåten behandling och måste bedömas mot tjänstens villkor, avtal och den aktuella informationen.
1. Den absoluta sekretessens innebörd under utvärderingsfasen
Anbudssekretessen är en av förvaltningsrättens strängaste bestämmelser. Syftet är att förhindra att konkurrenter får insyn i varandras priser, tekniska lösningar eller underleverantörskedjor innan ett tilldelningsbeslut har fattats.
Medan allmänna handlingar normalt omfattas av ett skaderekvisit, är sekretessen för anbudsuppgifter under utvärderingsfasen särskilt stark. Det innebär att handläggare behöver kontrollera åtkomst, lagring och överföring även när de söker efter dolda reservationer och villkorade formuleringar i anbuden.
2. De tekniska riskerna med generiska konsument-AI-tjänster
När en enskild handläggare av tidsbrist laddar upp ett 60-sidigt anbud till en extern AI-chattbot kan flera allvarliga informations- och dataskyddsrisker uppstå:
Många kommersiella AI-tjänster förbehåller sig rätten att spara inmatad text för vidareutveckling och träning av framtida modeller. Därmed kan information ur anbudet i teorin återskapas i svar till andra användare.
Om servrarna är belägna utanför EU/EES, eller kontrolleras av amerikanska moderbolag som omfattas av US CLOUD Act, föreligger risk för olovlig överföring av personuppgifter och myndighetsdata.
Anbudsbilagor innehåller ofta personnummer, privata kontaktuppgifter och detaljerade referenser på anbudsgivarens personal. Att behandla dessa i externa moln utan att ansvar, instruktioner och eventuellt personuppgiftsbiträdesavtal (PUB-avtal) är på plats kan stå i strid med GDPR Art. 28.
3. Säkerhetsarkitektur för offentlig sektor: Tre nödvändiga skyddslager
För att en upphandlande myndighet ska kunna använda AI-beslutsstöd på ett kontrollerat och granskningsbart sätt behövs en arkitektur som tar hänsyn till svensk rätt och kraven i EU AI Act gällande riskklassificering och transparens:
Pelare 1: Lokal pseudonymisering (GDPR Art. 25 & 32)
I deploymenter där pseudonymiseringsflödet är aktiverat kan personnummer, telefonnummer, personnamn och adresser ersättas före analys. Exakt omfattning, mappning och reversering behöver verifieras i den aktuella konfigurationen. Läs mer i vår tekniska säkerhetsspecifikation.
Pelare 2: Dokumenterade modell- och lagringsvillkor
Modellanvändning, loggning, lagring och eventuell delning behöver dokumenteras i produktkonfiguration, leverantörsvillkor och avtal. Den upphandlande myndighetens instruktioner och informationsägarskap måste vara tydliga.
Pelare 3: Möjligt stöd för lokal drift och nätverksisolering
För kommuner och myndigheter med förhöjda säkerhetskrav kan lokal containerdrift vara ett deploymentalternativ. Nätverksisolering och frånvaro av utgående trafik måste verifieras i den aktuella installationen; det eliminerar inte automatiskt alla informationssäkerhetsrisker.
Relaterade analyser och fördjupning
Läs fler fackartiklar om förvaltningsrättslig praxis, anbudsanalys och IT-säkerhet:
Dokumentera kravavvikelser i anbud: En praktisk arbetsmetod
En praktisk metod för att dokumentera avvikelser mot skall-krav med citat, källa, bedömning och spårbar motivering.
Säker AI-pilot i offentlig upphandling: Från demo till avtal
Så avgränsar du en AI-pilot med sekretess, tydliga testfall och mänsklig kontroll före skarp användning.
Vill er IT- eller säkerhetsavdelning granska Edlus arkitektur?
Vi kan gå igenom teknisk säkerhetsdokumentation, DPIA-underlag och installationsförutsättningar utifrån den aktuella pilotens omfattning.