Hur du skyddar användardata i din AI-byggda app (utan ett säkerhetsteam)

En coach vi känner byggde en app för klientuppföljning med en AI-appbyggare under en helg. Sessionsanteckningar, mål, lägeskontroller — allt hon brukade ha i ett anteckningsblock, nu sökbart och organiserat. Det fungerade så bra att två coachvänner bad att få använda det också.

Det var då det slog henne: hon förde inte längre sina egna anteckningar. Hon höll andra människors anteckningar om deras klienter — hälsodetaljer, personliga svårigheter, namn. Om den datan läckte ut skulle det inte vara hennes pinsamhet. Det skulle vara deras.

Du behöver inget säkerhetsteam för att hantera det här ansvarsfullt. Du behöver tre vanor och viljan att ställa några direkta frågor till din AI-byggare. Den här guiden täcker hur du skyddar användardata i din AI-byggda app på den nivå som faktiskt spelar roll för en liten produkt.

Börja med att lägga märke till vilken användardata du faktiskt håller

De flesta byggare underskattar det här. “Jag har bara ett registreringsformulär” betyder oftast att du har:

Mejladresser — nog för att spamma eller nätfiska någon.
Namn kopplade till beteende — vad de köpte, vad de skrev, när de loggar in.
Vadhelst dina användare skriver i fritextrutor — och folk skriver in vad som helst i ett anteckningsfält: telefonnummer, medicinska detaljer, löner, klagomål om sin chef.

Ta tio minuter och skriv ner varje bit information din app lagrar om en person. Inte databasfälten — den mänskliga innebörden. “Mejl”, “vilka kosttillskott de tar”, “anteckningar deras tränare skrev om dem”. Den listan är din ansvarsyta. Allt annat i det här inlägget handlar om att göra den mindre och säkrare.

Vana 1: Samla in mindre

Den billigaste datan att skydda är data du aldrig samlat in. Innan du skyddar något, krymp listan.

Gå igenom listan du just gjorde och fråga om varje objekt: använder jag det här? Coachens app frågade efter födelsedatum vid registrering för att AI-byggarens registreringsmall innehöll det. Hon använde det aldrig någonstans. En mening till hennes AI-byggare — “ta bort födelsedatum från registreringen och radera kolumnen” — och en hel kategori av känslig data var borta.

Vanliga saker appar samlar in och aldrig använder: födelsedatum, telefonnummer, fysiska adresser, kön, “hur hörde du talas om oss”. Om du inte använder det den här månaden kan du alltid be om det senare. Du kan inte av-läcka det.

Vana 2: Kontrollera vem som kan se vad

Det finns två versioner av den här frågan, och du behöver båda.

Inuti appen: kan en användare se en annan användares data? Om din app har klienter och coacher, kan klient A någonsin se klient B:s anteckningar? Vi har skrivit en hel guide om användarbehörigheter i din AI-byggda app, men kortversionen: beskriv regeln för din AI-byggare på vanlig svenska (“en coach ser bara sina egna klienter; klienter ser bara sig själva”) och sedan testa det själv med två konton. Logga in som en användare, försök nå en annan användares data genom att klicka runt. Fem minuter, två testkonton. Det här enda testet fångar den vanligaste läckan i små appar.

Utanför appen: vem kan se själva databasen? Det är du, din AI-byggarplattform, och alla du har delat inloggningar med. Vilket för oss till frågorna.

Vana 3: Ställ din byggare dessa fem frågor

Du behöver inte förstå svaren på djupet. Du behöver fråga, och svaren borde vara självsäkra ja. Klistra in dessa i din AI-appbyggare en i taget:

“Lagras användarlösenord hashade, eller kan vem som helst läsa dem?” Det enda godtagbara svaret innehåller ordet “hashade”. Om din app lagrar lösenord som vem som helst kan läsa, fixa det idag — det är oftast en en-prompts-fix, och de flesta moderna byggare gör det här korrekt som standard.
“Är anslutningen till appen krypterad (HTTPS)?” Leta efter hänglåset i din egen webbläsare. Om din apps adress börjar med https:// är du klar med den här.
“Om någon fick tag på databasfilen, skulle de kunna läsa de känsliga fälten?” Det här handlar om kryptering i vila. De flesta hostingplattformar hanterar det automatiskt — fråga ändå och skriv ner svaret.
“Vilka tredjepartstjänster tar emot användardata?” Mejlverktyg, analys, betalningsförmedlare. Du tar inte bort dem — du gör din lista komplett, för varje tjänst som håller dina användares data är en del av din ansvarsyta.
“Finns det en backup, och vem kan komma åt den?” Backuper är kopior av din data, och kopior behöver också skydd. (Om du inte har satt upp backuper alls, börja här.)

Spara svaren i ett dokument. Det dokumentet är början på din säkerhetshållning, och du kommer vara glad att det finns första gången en kund — eller en kunds advokat — frågar.

När någon säger “radera min data”

Någon kommer så småningom göra det, och lagen på de flesta ställen (GDPR i Europa, liknande regler på andra håll) säger att du faktiskt måste göra det. Bestäm nu vad ditt svar är:

Kan du radera en användare och allt kopplat till dem? Be din AI-byggare lägga till det här — “bygg en administratörsåtgärd som raderar en användare och all deras data” — innan du behöver det under tidspress.
Tar radering av dem i appen också bort dem från ditt mejlverktyg och din analys? Kolla din lista från fråga 4.
Backuper innehåller dem fortfarande ett tag. Det är normalt och i allmänhet okej — vet det bara, så att du kan säga det ärligt.

Att svara på en raderingsbegäran på en dag för att du förberett dig ser professionellt ut. Att skrapa ihop det på två veckor ser ut precis som det är.

Skriv integritetssidan på vanligt språk

Hoppa över de 4 000 ord genererad juridiksvenska för nu. Skriv fem ärliga meningar: vad du samlar in, varför, vem mer som rör det (ditt mejlverktyg, din betalningsförmedlare), hur länge du behåller det, och hur man ber om radering. Lägg den på /privacy och länka till den från din registreringssida.

Det här är inte juridisk rådgivning, och om du hanterar verkligt känslig data — hälsa, barn, ekonomi — lägg pengarna på en timme med en advokat. Men en tydlig, ärlig sida slår en imponerandeseende som ingen kan läsa, och att skriva den tvingar dig att faktiskt kunna dina egna svar.

Ribban är lägre än du fruktar, och högre än noll

Du försvarar dig inte mot nationalstater. Du försvarar dig mot de tråkiga, vanliga misslyckandena: ett kvarglömt datafält ingen behövde, en behörighetsregel ingen testade, en lösenordstabell någon glömde att hasha. Att skydda användardata på den här nivån är inte en specialistfärdighet — vart och ett av de misslyckandena går att fixa med en prompt på vanligt språk och ett femminuterstest.

Coachen från början gjorde allt det här på en eftermiddag: raderade två oanvända fält, körde tvåkontotestet (och fångade en läcka — klienter kunde se varandras förnamn i en rullgardinsmeny), ställde de fem frågorna, skrev sin integritetssida. Hennes app såg inte annorlunda ut efteråt. Men när hennes vän frågade “är den här grejen säker för mina klientanteckningar?”, hade hon ett riktigt svar.

Ta eftermiddagen. Dina användare gav dig sin data på förtroende — det här är hur det ser ut att förvalta det.