Bygga GDPR-säkra appar: en praktisk checklista för EU-grundare

Börja med vad som räknas som persondata

GDPR gäller så snart din app behandlar uppgifter som kan identifiera en person – en e-postadress i ett kontaktformulär räcker. De flesta små appar passerar den gränsen omedelbart, vilket är skälet till att det är värt att hantera redan från första versionen i stället för att bygga om senare.

Observera att detta är en praktisk teknisk checklista, inte juridisk rådgivning. För allt med verklig exponering: prata med någon kvalificerad i ditt land.

Samtycke före lagring, inte efter

Regeln folk oftast får om bakvänt: du behöver samtycke innan du sätter icke-nödvändiga cookies eller lagrar spårningsdata, inte i efterhand. Praktiskt innebär det att analysskript inte får laddas förrän besökaren accepterat, och att en samtyckesruta måste erbjuda ett verkligt nej som är lika lätt att klicka som ja.

Samma sak gäller inuti din egen app. Om du sparar ett utkast, en inställning eller en sessionsmarkör i lokal lagring för bekvämlighets skull snarare än av nödvändighet, lägg det bakom samma samtyckeskontroll.

Vet var din data fysiskt ligger

Du bör kunna svara, för varje kategori av data din app rör, var den lagras och vem som kommer åt den. Det inkluderar den självklara databasen, men också mindre uppenbara flöden: analys, e-postleverans, betalhantering och varje AI-tjänst appen anropar. Var och en av dem är ett personuppgiftsbiträde i kedjan.

Det är här genereringsmetoden börjar spela roll. När AI-genereringen körs lokalt i webbläsaren behandlas prompten på användarens egen enhet och blir aldrig någon överföring till tredje part alls. När den körs i molnet är det ytterligare ett biträde att redovisa.

De konkreta svaren för en app byggd här

Eftersom poängen med avsnittet ovan är att du ska kunna svara på frågan snarare än att peka i riktningen, här är svaren för en NorthernGo-app i grundläget.

Appdata går till den inbyggda Supabase-databasen i PostgreSQL via window.NorthernGoDB. Underbiträdena för infrastrukturen är Supabase och Firebase, och kundapplikationsdata och drift körs på servrar inom EU/EES. Plattformen drivs av en enskild firma med Nicklas Långberg i Lycksele som ansvarig – vilket är värt att veta just för att "vem är biträdet, exakt" är en fråga du förväntas kunna svara på om dina leverantörer, inte bara om ditt eget företag.

Molngenerering av kod använder Googles Gemini-modeller. Det är ett biträde i din byggkedja snarare än i appens datastig: det ser din prompt, inte dina användares poster. Lokal generering via WebGPU tar bort det ur bilden helt, vilket är en genuin skillnad och samtidigt en mindre än den låter – jämförelsen mellan lokalt och moln går igenom var respektive väg landar, men för efterlevnaden väger den färdiga appens datahantering avsevärt tyngre än hur koden skrevs.

Vem är personuppgiftsansvarig och vem är biträde?

Att få det här om bakvänt orsakar mer besvär än något tekniskt misstag, så det är värt att säga rakt ut.

Du är personuppgiftsansvarig för datan din app samlar in. Dina användares poster hör till din relation med dem. NorthernGo agerar personuppgiftsbiträde för den inbyggda standardlagringen, och när du godkänner plattformens villkor ingås ett standardiserat biträdesavtal som täcker den lagringen.

Vad som följer av det är den del folk inte räknar med: att uppfylla dina slutanvändares rättigheter är ditt ansvar, inte plattformens. Om en av dina användare ber om en kopia av sin data eller ber dig radera den, landar begäran hos dig. Ingen hanterar den i ditt ställe, och "plattformen lagrar den" är inget svar. Vilket är precis därför nästa avsnitt inte är valfritt.

Knappen för att radera kontot är inte valfri

Det här är det enda stället där plattformen slutar vara neutral och tvingar fram något.

Varje genererad app som har inloggning måste också leverera ett synligt sätt att radera kontot. Det står inskrivet i genereringsreglerna som ett krav enligt GDPR artikel 17, och det är inte ett förslag modellen får väga mot andra prioriteringar. I praktiken betyder det:

• En tydlig knapp i profil-, inställnings- eller kontomenyn, i anslutning till utloggningen, formgiven som en varningsåtgärd.
• Ett bekräftelsesteg först. Ett klick får aldrig radera direkt; rutan måste klart säga att kontot och all sparad data raderas permanent och inte kan återskapas.
• Själva raderingen går via await window.NorthernGoDB.deleteAccount(). Att bygga en egen raderingsrutt med fetch, eller att försöka rensa användaren genom att loopa delete(), är uttryckligen uteslutet – en hemsnickrad variant lämnar med säkerhet kvar autentiseringsposten eller delar av datan.
• Ett kvitto efteråt, och sedan tillbaka till den utloggade vyn.

if (confirm('Detta raderar ditt konto och all din data permanent. Fortsätta?')) {
  try {
    await window.NorthernGoDB.deleteAccount();
    visaMeddelande('Ditt konto och all din data har raderats.');
    location.reload();
  } catch (err) {
    visaMeddelande(err.message);
  }
}

Regeln överlever också ändringar. När du ber om en ändring i en befintlig app bevaras din design och dina funktioner – med ett medvetet undantag: har appen inloggning men saknar raderingsknappen läggs den till i den uppdateringen, och en befintlig knapp tas aldrig bort. Det är den enda funktion plattformen lägger till i din app utan att bli tillfrågad. Se databas- och inloggnings-API:t för hur kontoavgränsningen fungerar under ytan.

Egen Databas flyttar ansvaret till dig

Inställningen Egen Databas speglar varje skrivning dina appar gör till en HTTP-endpoint du väljer själv, som JSON. Den är genuint användbar, och den förändrar din position.

Data som går till din egen endpoint ligger utanför plattformens insyn. Ingenting sparas eller granskas på den vägen, och plattformen agerar uttryckligen inte biträde för den. Det betyder två saker du själv måste skriva ner: vad den endpointen gör med datan, och var den ligger. Sitter det mottagande systemet utanför EU/EES har du infört en överföring som grunduppsättningen inte hade, och den är din att dokumentera och motivera. Samma sak gäller webhook-integrationer och dina egna Stripe-nycklar.

Rätten till tillgång, praktiskt

Radering får all uppmärksamhet, men begäran om registerutdrag orsakar mer panik, eftersom det inte finns någon knapp för det. Den realistiska hållningen är att bygga exporten medan du fortfarande minns din egen datamodell.

Du har redan delarna. window.NorthernGoDB.get(kollektion) returnerar posterna för den inloggade användaren, och window.NorthernGo.exportCSV(poster, 'min-data.csv') gör en array till en nedladdningsbar fil. En knapp för "Ladda ner min data" intill raderingsknappen kostar ungefär tio rader och förvandlar ett stressigt mejl till en länk du skickar.

Uppgiftsminimering är ett designbeslut, inte en policy

Varje fält du lägger till i ett formulär är ett fält du måste skydda, motivera, lokalisera på begäran och till slut radera. Den billigaste efterlevnadsåtgärden som finns är att inte samla in datan.

Två saker är värda att nämna specifikt. Generatorn lägger proaktivt till grundläggande integritets-UI när en app samlar in persondata – en stängbar cookiebanner och kryssrutor om integritetspolicyn i formulär. Betrakta det som en utgångspunkt snarare än ett resultat: en banner är ett gränssnittselement, och efterlevnaden avgörs av om den faktiskt blockerar något. En genererad app laddar inte analys som standard, så ganska ofta finns det ingenting bakom bannern att spärra, och det ärliga draget är antingen att ta bort bannern eller att koppla den till det du själv lagt till.

Det andra är lokal lagring. Textutkast, sparade filter och cachade inställningar är lagring, och bekvämlighetslagring kräver samtycke. Skriver din app till localStorage för något annat än att hålla sessionen levande hör det bakom samma kontroll – och håller den appdata snarare än inställningar hör den förmodligen i databasen i stället.

Vad plattformen inte gör för dig

En ärlig lista, eftersom antagandet om motsatsen är hur folk hamnar i blåsväder.

• Ingen förteckning över behandlingar. Ingenting genererar eller underhåller din dokumentation.
• Inga lagringstider. Kollektioner har ingen livslängd. En post du sparar ligger kvar tills något raderar den, och "vi sparar data i tolv månader" är ett löfte du själv måste implementera.
• Ingen samtyckeslogg i appen. Den genererade bannern sparar ett val i webbläsaren, inte ett spår som går att granska.
• Inget flöde för begäranden från de registrerade. Ingen inkorg, inga tidsfrister, inga mallar. Begäranden kommer som vanlig e-post till dig.
• Ingen schemakontroll. Ingenting hindrar en app från att spara ett fält du aldrig tänkt samla in, vilket är ett minimeringsproblem lika mycket som ett datakvalitetsproblem. Läs vad du faktiskt skriver.
• Ingen juridisk granskning. Ingenting här, inklusive den här sidan, är juridisk rådgivning.

Checklista före lansering

1. En samtyckesruta med ett verkligt nej, som blockerar analys tills den accepteras.
2. En integritetspolicy som namnger dina faktiska biträden, inte en mall-lista.
3. Ett dokumenterat svar på var varje datakategori lagras.
4. Ett fungerande sätt att radera en specifik användares data på begäran.
5. Formulär som bara samlar in det du verkligen behöver – varje extra fält är extra ansvar.
6. Uttryckliga samtyckesrutor på allt som publicerar användarinnehåll offentligt.
7. En synlig funktion för att radera kontot i varje app som har inloggning, bakom en bekräftelse.
8. Ett beslut om lagringstid per kollektion, nedskrivet, och kod som upprätthåller det.
9. En exportväg för begäran om registerutdrag, helst som en knapp snarare än en manuell process.
10. Använder du en egen endpoint, webhooks eller egna betalnycklar: ett dokumenterat svar på vart datan går och om den lämnar EU/EES.

En sista sak som är lätt att missa. Portabilitet är en dataskyddsfråga och inte bara en kommersiell – rätten till tillgång förutsätter att du kan få ut datan, vilket är svårt om appen och dess poster är inlåsta i en plattform. Den överlappningen behandlas i guiden om att undvika inlåsning, och den är ett gott skäl att testa din egen export innan någon annan ber dig om den.