Hoe je gebruikersdata beschermt in je met AI gebouwde app (zonder beveiligingsteam)

Een coach die we kennen bouwde in een weekend een klant-trackingapp met een AI-appbouwer. Sessienotities, doelen, voortgangscheck-ins — alles wat ze vroeger in een notitieboek bijhield, nu doorzoekbaar en georganiseerd. Het werkte zo goed dat twee coachvrienden vroegen of zij hem ook mochten gebruiken.

Toen drong het tot haar door: ze hield niet langer haar eigen notities bij. Ze hield andermans notities over hun klanten vast — gezondheidsdetails, persoonlijke worstelingen, namen. Als die data zou lekken, zou het niet haar schaamte zijn. Het zou die van hen zijn.

Je hebt geen beveiligingsteam nodig om dit verantwoord af te handelen. Je hebt drie gewoonten nodig en de bereidheid om je AI-bouwer een paar directe vragen te stellen. Deze gids behandelt hoe je gebruikersdata beschermt in je met AI gebouwde app op het niveau dat er echt toe doet voor een klein product.

Begin met opmerken welke gebruikersdata je echt vasthoudt

De meeste bouwers onderschatten dit. “Ik heb gewoon een aanmeldformulier” betekent meestal dat je hebt:

E-mailadressen — genoeg om iemand te spammen of te phishen.
Namen gekoppeld aan gedrag — wat ze kochten, wat ze schreven, wanneer ze inloggen.
Wat je gebruikers ook in vrije-tekstvakken typen — en mensen typen van alles in een notitieveld: telefoonnummers, medische details, salarissen, klachten over hun baas.

Neem tien minuten en schrijf elk stukje informatie op dat je app over een persoon opslaat. Niet de databasevelden — de menselijke betekenis. “E-mail”, “welke supplementen ze nemen”, “notities die hun trainer over ze schreef”. Die lijst is je verantwoordelijkheidsoppervlak. Al het andere in deze post gaat over het kleiner en veiliger maken ervan.

Gewoonte 1: verzamel minder

De goedkoopste data om te beschermen is data die je nooit verzamelde. Voordat je iets beschermt, krimp de lijst.

Loop de lijst door die je net maakte en vraag van elk item: gebruik ik dit? De app van de coach vroeg om geboortedatum bij aanmelding omdat het aanmeldsjabloon van de AI-bouwer het bevatte. Ze gebruikte het nergens. Eén zin tegen haar AI-bouwer — “verwijder geboortedatum uit aanmelding en verwijder de kolom” — en een hele categorie gevoelige data was weg.

Veelvoorkomende dingen die apps verzamelen en nooit gebruiken: geboortedatums, telefoonnummers, fysieke adressen, geslacht, “hoe heb je over ons gehoord”. Als je het deze maand niet gebruikt, kun je er altijd later om vragen. Je kunt het niet on-lekken.

Gewoonte 2: bepaal wie wat kan zien

Er zijn twee versies van deze vraag, en je hebt beide nodig.

Binnen de app: kan de ene gebruiker de data van een andere gebruiker zien? Als je app klanten en coaches heeft, kan klant A ooit de notities van klant B zien? We hebben een hele gids geschreven over gebruikersrechten in je met AI gebouwde app, maar de korte versie: beschrijf de regel in gewone taal aan je AI-bouwer (“een coach ziet alleen zijn eigen klanten; klanten zien alleen zichzelf”) en test het dan zelf met twee accounts. Log in als één gebruiker, probeer de data van een andere gebruiker te bereiken door rond te klikken. Vijf minuten, twee testaccounts. Deze ene test vangt het meest voorkomende lek in kleine apps.

Buiten de app: wie kan de database zelf zien? Dat zijn jij, je AI-bouwerplatform, en iedereen met wie je inloggegevens hebt gedeeld. Wat ons bij de vragen brengt.

Gewoonte 3: stel je bouwer deze vijf vragen

Je hoeft de antwoorden niet diepgaand te begrijpen. Je moet vragen, en de antwoorden moeten zelfverzekerde ja’s zijn. Plak deze één voor één in je AI-appbouwer:

“Worden gebruikerswachtwoorden gehasht opgeslagen, of kan iedereen ze lezen?” Het enige acceptabele antwoord bevat het woord “gehasht”. Als je app wachtwoorden opslaat die iedereen kan lezen, repareer het vandaag — het is meestal een fix van één prompt, en de meeste moderne bouwers doen dit standaard correct.
“Is de verbinding met de app versleuteld (HTTPS)?” Zoek naar het hangslot in je eigen browser. Als het adres van je app begint met https://, ben je klaar met deze.
“Als iemand het databasebestand kreeg, zouden ze de gevoelige velden kunnen lezen?” Dit gaat over versleuteling in rust. De meeste hostingplatforms handelen het automatisch af — vraag toch en schrijf het antwoord op.
“Welke externe diensten ontvangen gebruikersdata?” E-mailtools, analytics, betalingsverwerkers. Je verwijdert ze niet — je maakt je lijst compleet, want elke dienst die de data van je gebruikers vasthoudt, is onderdeel van je verantwoordelijkheidsoppervlak.
“Is er een back-up, en wie heeft er toegang toe?” Back-ups zijn kopieën van je data, en kopieën hebben ook bescherming nodig. (Als je helemaal geen back-ups hebt ingesteld, begin hier.)

Bewaar de antwoorden in een document. Dat document is het begin van je beveiligingshouding, en je zult blij zijn dat het bestaat de eerste keer dat een klant — of de advocaat van een klant — ernaar vraagt.

Wanneer iemand zegt “verwijder mijn data”

Iemand zal dat uiteindelijk doen, en de wet op de meeste plekken (AVG in Europa, vergelijkbare regels elders) zegt dat je het echt moet doen. Beslis nu wat je antwoord is:

Kun je één gebruiker en alles wat met ze verbonden is verwijderen? Vraag je AI-bouwer dit toe te voegen — “bouw een beheerdersactie die een gebruiker en al hun data verwijdert” — voordat je het onder deadline nodig hebt.
Verwijdert het verwijderen in de app ze ook uit je e-mailtool en analytics? Check je lijst van vraag 4.
Back-ups bevatten ze nog een tijdje. Dat is normaal en over het algemeen prima — weet het gewoon, zodat je het eerlijk kunt zeggen.

Een verwijderingsverzoek in een dag beantwoorden omdat je je voorbereidde, ziet er professioneel uit. Twee weken stuntelen ziet er precies uit als wat het is.

Schrijf de privacypagina in gewone taal

Sla het gegenereerde juridische gewauwel van 4.000 woorden voorlopig over. Schrijf vijf eerlijke zinnen: wat je verzamelt, waarom, wie het verder aanraakt (je e-mailtool, je betalingsverwerker), hoe lang je het bewaart, en hoe je om verwijdering vraagt. Zet hem op /privacy en link ernaar vanaf je aanmeldpagina.

Dit is geen juridisch advies, en als je oprecht gevoelige data afhandelt — gezondheid, kinderen, financiën — geef dan het geld uit aan een uur met een advocaat. Maar een heldere, eerlijke pagina verslaat een indrukwekkend uitziende die niemand kan lezen, en hem schrijven dwingt je om je eigen antwoorden echt te kennen.

De lat ligt lager dan je vreest, en hoger dan nul

Je verdedigt je niet tegen natiestaten. Je verdedigt je tegen de saaie, veelvoorkomende falen: een overgebleven dataveld dat niemand nodig had, een rechtenregel die niemand testte, een wachtwoordtabel die iemand vergat te hashen. Gebruikersdata beschermen op dit niveau is geen specialistenvaardigheid — elk van die falen is op te lossen met een prompt in gewone taal en een test van vijf minuten.

De coach van het begin deed dit allemaal in één middag: verwijderde twee ongebruikte velden, voerde de twee-accounttest uit (en ving één lek — klanten konden elkaars voornamen zien in een dropdown), stelde de vijf vragen, schreef haar privacypagina. Haar app zag er daarna niet anders uit. Maar toen haar vriendin vroeg “is dit ding veilig voor mijn klantnotities?”, had ze een echt antwoord.

Neem de middag. Je gebruikers gaven je hun data op vertrouwen — dit is hoe het behouden ervan eruitziet.