GDPR är inte bara ett juridiskt dokument. Det är ett produktbeslut.

Ett svenskt företag bygger en ny kundportal. Registreringen fungerar, gränssnittet är snyggt och integrationen med CRM-systemet är nästan klar. Först veckan före lansering får juristen se lösningen.

Då kommer frågorna.

Varför måste kunden ange födelsedatum? Varför sparas avslutade konton utan tidsgräns? Varför kan alla administratörer se samtliga kunduppgifter? Hur ska användaren få en kopia av sin information eller begära radering?

Plötsligt blir GDPR ett hinder som måste ”läggas till” i efterhand.

Problemet är inte lagen. Problemet är att integritet aldrig behandlades som en del av produktdesignen.

GDPR påverkar vilka uppgifter en produkt samlar in, hur länge de sparas, vem som får se dem och vilka val användaren får. Därför bör dataskydd diskuteras samtidigt som teamet bestämmer funktioner, användarflöden, datamodell och systemarkitektur.

Privacy by Design är ett krav – inte en rekommendation

Artikel 25 i GDPR kräver dataskydd genom design och dataskydd som standard. Den personuppgiftsansvariga ska genomföra lämpliga tekniska och organisatoriska åtgärder både när metoderna för behandlingen bestäms och när behandlingen faktiskt genomförs. Hänsyn ska tas till teknikens utveckling, kostnader, ändamål och riskerna för människors rättigheter och friheter.

Integritetsskyddsmyndigheten, IMY, understryker att kravet gäller alla personuppgiftsansvariga och företag oavsett storlek. Myndigheten beskriver också inbyggt dataskydd som ett sätt att skapa bättre och mer kostnadseffektivt skydd, eftersom problemen hanteras när systemet utformas – inte efter lanseringen.

Privacy by Design innebär alltså inte att ett företag måste välja den dyraste tekniska lösningen. Det innebär att dataskydd ska vara en dokumenterad del av produktens beslut och anpassas efter den faktiska risken.

Svenska företag behandlar allt mer data

Frågan blir viktigare när svenska företag bygger fler digitala tjänster och inför AI.

SCB:s senaste sammanställning visar att 35 procent av svenska företag med minst tio anställda använde AI under 2025. Bland små företag med 10–49 anställda var andelen omkring 31 procent, bland medelstora företag 50 procent och bland stora företag 72 procent. Sverige låg samtidigt tydligt över EU-genomsnittet på 20 procent.

AI, analysverktyg, molntjänster och automatiserade kundflöden kan skapa stor affärsnytta. Men de innebär ofta att fler personuppgifter samlas in, kopieras mellan system eller används för nya ändamål.

IMY uppdaterade under 2026 sin vägledning om GDPR och AI. Där betonas att dataskydd gäller när personuppgifter används vid både utveckling och användning av AI. Myndigheten framhåller också att jurister och tekniker behöver arbeta tvärfunktionellt för att digital innovation ska bli hållbar.

Det är i praktiken kärnan i Privacy by Design: dataskydd kan inte delegeras enbart till juridikavdelningen.

Börja med ändamålet – inte med alla data ni kan samla in

En vanlig produktidé börjar med frågan:

”Vilken information kan vi samla in?”

Ett dataskyddsvänligt projekt börjar i stället med:

”Vilken information behöver vi för att leverera den här funktionen?”

Anta att ett bokningssystem behöver kundens namn, kontaktuppgifter och vald tid. Då ska företaget kunna förklara varför systemet även frågar efter födelsedatum, kön, arbetsgivare eller exakt position.

Uppgiftsminimering innebär att personuppgifter ska vara relevanta och inte mer omfattande än vad ändamålet kräver. IMY rekommenderar att verksamheten analyserar behovet före behandlingen och säkerställer att endast nödvändig behandling utförs som standard.

För produktteamet betyder det att varje fält i ett formulär bör ha ett tydligt svar på tre frågor:

Varför behöver vi uppgiften?
Vilken rättslig grund stödjer behandlingen?
När ska uppgiften tas bort?

Kan teamet inte svara, bör fältet sannolikt inte finnas.

Dataskydd som standard förändrar användarupplevelsen

Integritet ska inte vara ett alternativ som användaren måste leta efter.

Dataskydd som standard innebär att produktens grundinställningar ska vara integritetsvänliga. IMY nämner bland annat att samtyckesrutor inte ska vara förifyllda och att personuppgifter inte automatiskt ska delas med tredje part.

Det påverkar konkreta designbeslut:

Ett konto bör inte vara offentligt som standard. Marknadsföring bör inte aktiveras automatiskt. En mobilapp bör inte begära tillgång till kontakter eller position innan funktionen behöver det. En SaaS-tjänst bör inte visa kunddata för alla med administratörsbehörighet.

En bra tumregel är att användaren ska kunna använda kärntjänsten utan att behöva ge företaget mer information än nödvändigt.

Detta är inte bara efterlevnad. Det kan också skapa förtroende. En produkt som förklarar varför en uppgift behövs och ger tydliga val känns mer genomtänkt än en produkt som begär tillgång till allt.

Bygg in gallring i systemet

Många system är bra på att samla in data men dåliga på att ta bort den.

Personuppgifter exporteras till kalkylblad, kopieras till CRM-system, hamnar i säkerhetskopior och sparas i gamla användarkonton. När kunden begär radering blir uppgiften ett manuellt projekt.

Privacy by Design innebär att gallring ska vara en funktion i systemet.

IMY lyfter inbyggda lagringstider som ett sätt att följa principen om lagringsminimering. Personuppgifter ska inte sparas längre än vad ändamålet kräver.

Produktkraven bör därför ange vad som händer när ett avtal upphör, ett konto avslutas eller ett ärende blir inaktuellt. Vissa uppgifter kan behöva sparas på grund av exempelvis bokföringsregler, medan andra bör raderas eller anonymiseras automatiskt.

”Vi sparar allt tills någon säger något” är inte en hållbar lagringspolicy.

Behörigheter är också produktdesign

Det räcker inte att databasen är krypterad om för många människor har åtkomst till innehållet.

En säljare behöver kanske se kontaktuppgifter och kundhistorik. En supportmedarbetare behöver se aktuella ärenden. En ekonom behöver se fakturauppgifter. Det betyder inte att alla tre roller behöver tillgång till allt.

IMY rekommenderar organisatoriska och tekniska åtgärder som begränsar åtkomsten efter arbetsuppgift. Alla medarbetare behöver normalt inte ha tillgång till samtliga personuppgifter som verksamheten behandlar.

Rollbaserade behörigheter, loggning och regelbunden granskning bör därför finnas i produktens kravlista från början.

Att bygga en genomtänkt behörighetsmodell efter att systemet redan används är ofta komplicerat. Datamodellen, gränssnittet och API:erna kan då vara byggda kring antagandet att alla interna användare får se allt.

Förbered användarnas rättigheter tekniskt

GDPR ger registrerade flera rättigheter, men de blir dyra att hantera om produkten inte stödjer dem.

Ett system bör kunna:

  • hitta alla uppgifter som tillhör en person,
  • rätta felaktig information,
  • exportera uppgifter i ett begripligt format,
  • begränsa behandling när det krävs,
  • radera eller anonymisera uppgifter enligt fastställda regler.

Det innebär att personuppgifter behöver vara strukturerade och spårbara. Om information ligger blandad i fritextfält, mejl, loggar och dokument blir varje begäran ett manuellt detektivarbete.

Privacy by Design handlar därför lika mycket om datamodellering som om juridik.

Incidentstatistiken visar varför designbesluten spelar roll

Under 2025 tog IMY emot 12 276 anmälningar om personuppgiftsincidenter, nästan 90 procent fler än under 2024. Det var den högsta nivån sedan GDPR började tillämpas 2018. Flera stora incidenter var kopplade till leverantörer som hanterade uppgifter åt många andra organisationer.

Statistiken betyder inte att alla incidenter berodde på dålig programvarudesign. Men den visar hur snabbt konsekvenserna kan spridas när en central tjänst har för bred åtkomst, lagrar stora datamängder eller saknar tillräckliga skydd.

Ett system som samlar in färre uppgifter, separerar kunders data och begränsar behörigheter kan minska skadan även när en incident inträffar.

En praktisk process för svenska programvaruprojekt

Privacy by Design behöver inte göra utvecklingen långsam. Det kan byggas in i företagets vanliga produktprocess.

Innan utvecklingen börjar bör teamet kartlägga vilka personuppgifter som behövs, ändamålet, den rättsliga grunden, lagringstiden och vilka aktörer som får tillgång.

Under designfasen bör teamet granska standardinställningar, användarval, behörigheter och informationsflöden.

Under utvecklingen bör tekniska skydd, loggning, gallring och funktioner för användarnas rättigheter implementeras och testas.

Före lansering bör företaget genomföra en riskanalys och dokumentera de tekniska och organisatoriska åtgärderna. IMY betonar uttryckligen behovet av riskanalys, dokumentation samt instruktioner och utbildning för utvecklare och andra berörda.

Efter lanseringen behöver besluten följas upp när funktioner, leverantörer eller ändamål förändras.

Slutsats: integritet är en del av produktens kvalitet

GDPR ska inte komma in som ett godkännande i slutet av projektet. Då är formulären redan skapade, databasen redan strukturerad och integrationerna redan byggda.

Dataskydd behöver påverka produkten från första skissen.

Det betyder inte att jurister ska styra varje knapp eller kodrad. Det betyder att produktägare, utvecklare, designers, säkerhetsansvariga och juridisk kompetens tillsammans ska fatta informerade beslut.

En väl utformad produkt samlar inte in allt den kan. Den samlar in det den behöver.

Den sparar inte information för alltid. Den vet när uppgifterna ska tas bort.

Den ger inte alla full åtkomst. Den visar rätt information för rätt person.

GDPR är därför inte bara en juridisk skyldighet. Det är ett ramverk för att bygga digitala produkter som användare och kunder faktiskt kan lita på.