So schützt du Nutzerdaten in deiner KI-gebauten App (ohne Security-Team)

Eine Coachin, die wir kennen, hat mit einem KI-App-Builder an einem Wochenende eine App zur Klientenverwaltung gebaut. Sitzungsnotizen, Ziele, Fortschritts-Check-ins — alles, was sie früher in einem Notizbuch hatte, jetzt durchsuchbar und organisiert. Es funktionierte so gut, dass zwei befreundete Coaches darum baten, es ebenfalls zu nutzen.

Da wurde es ihr bewusst: Sie führte nicht mehr ihre eigenen Notizen. Sie hielt die Notizen anderer Leute über deren Klient:innen — Gesundheitsdetails, persönliche Probleme, Namen. Wenn diese Daten lecken würden, wäre es nicht ihre Peinlichkeit. Es wäre deren.

Du brauchst kein Security-Team, um damit verantwortungsvoll umzugehen. Du brauchst drei Gewohnheiten und die Bereitschaft, deinem KI-Builder ein paar direkte Fragen zu stellen. Dieser Leitfaden behandelt, wie du Nutzerdaten in deiner KI-gebauten App auf dem Niveau schützt, das für ein kleines Produkt wirklich zählt.

Fang damit an, zu erkennen, welche Nutzerdaten du tatsächlich hältst

Die meisten Bauenden unterschätzen das. “Ich habe nur ein Anmeldeformular” heißt meist, du hast:

E-Mail-Adressen — genug, um jemanden zuzuspammen oder zu phishen.
Namen, die mit Verhalten verknüpft sind — was sie gekauft, was sie geschrieben haben, wann sie sich einloggen.
Was deine Nutzer:innen auch immer in Freitextfelder tippen — und Leute tippen alles in ein Notizfeld: Telefonnummern, medizinische Details, Gehälter, Beschwerden über ihre Chefin.

Nimm dir zehn Minuten und schreib jede Information auf, die deine App über eine Person speichert. Nicht die Datenbankfelder — die menschliche Bedeutung. “E-Mail”, “welche Nahrungsergänzungsmittel sie nehmen”, “Notizen, die ihr Trainer über sie geschrieben hat”. Diese Liste ist deine Verantwortungsfläche. Alles Weitere in diesem Beitrag geht darum, sie kleiner und sicherer zu machen.

Gewohnheit 1: Sammle weniger

Die billigsten Daten zum Schützen sind die, die du nie gesammelt hast. Bevor du irgendetwas schützt, verkleinere die Liste.

Geh die Liste durch, die du gerade gemacht hast, und frag bei jedem Punkt: Nutze ich das? Die App der Coachin fragte bei der Anmeldung nach dem Geburtsdatum, weil die Anmeldevorlage des KI-Builders es enthielt. Sie nutzte es nirgends. Ein Satz an ihren KI-Builder — “Entferne das Geburtsdatum aus der Anmeldung und lösche die Spalte” — und eine ganze Kategorie sensibler Daten war weg.

Häufige Dinge, die Apps sammeln und nie nutzen: Geburtsdaten, Telefonnummern, Anschriften, Geschlecht, “Wie hast du von uns erfahren?”. Wenn du es diesen Monat nicht nutzt, kannst du es später immer noch erfragen. Ein Leck kannst du nicht rückgängig machen.

Gewohnheit 2: Steuere, wer was sehen kann

Es gibt zwei Versionen dieser Frage, und du brauchst beide.

Innerhalb der App: Kann ein:e Nutzer:in die Daten einer/eines anderen sehen? Wenn deine App Klient:innen und Coaches hat, kann Klient:in A jemals die Notizen von Klient:in B sehen? Wir haben einen ganzen Leitfaden zu Nutzerberechtigungen in deiner KI-gebauten App geschrieben, aber die Kurzfassung: Beschreib die Regel deinem KI-Builder in klaren Worten (“ein Coach sieht nur seine eigenen Klient:innen; Klient:innen sehen nur sich selbst”) und teste es dann selbst mit zwei Konten. Log dich als ein:e Nutzer:in ein und versuch, durch Herumklicken an die Daten einer/eines anderen zu kommen. Fünf Minuten, zwei Testkonten. Dieser eine Test fängt das häufigste Leck in kleinen Apps.

Außerhalb der App: Wer kann die Datenbank selbst sehen? Das bist du, deine KI-App-Builder-Plattform und alle, mit denen du Logins geteilt hast. Womit wir bei den Fragen wären.

Gewohnheit 3: Stell deinem Builder diese fünf Fragen

Du musst die Antworten nicht tief verstehen. Du musst fragen, und die Antworten sollten selbstbewusste Jas sein. Füg diese eine nach der anderen in deinen KI-App-Builder ein:

“Werden Nutzerpasswörter gehasht gespeichert, oder kann sie jemand lesen?” Die einzig akzeptable Antwort enthält das Wort “gehasht”. Wenn deine App Passwörter speichert, die jeder lesen kann, behebe es heute — es ist meist eine Ein-Prompt-Korrektur, und die meisten modernen Builder machen das standardmäßig richtig.
“Ist die Verbindung zur App verschlüsselt (HTTPS)?” Achte auf das Schloss-Symbol in deinem eigenen Browser. Wenn die Adresse deiner App mit https:// beginnt, bist du hiermit fertig.
“Wenn jemand die Datenbankdatei bekäme, könnte er die sensiblen Felder lesen?” Hier geht es um Verschlüsselung im Ruhezustand. Die meisten Hosting-Plattformen erledigen das automatisch — frag trotzdem und schreib die Antwort auf.
“Welche Drittanbieter-Dienste erhalten Nutzerdaten?” E-Mail-Tools, Analytics, Zahlungsdienstleister. Du entfernst sie nicht — du machst deine Liste vollständig, denn jeder Dienst, der die Daten deiner Nutzer:innen hält, ist Teil deiner Verantwortungsfläche.
“Gibt es ein Backup, und wer hat Zugriff darauf?” Backups sind Kopien deiner Daten, und Kopien müssen auch geschützt werden. (Wenn du noch gar keine Backups eingerichtet hast, fang hier an.)

Speichere die Antworten in einem Dokument. Dieses Dokument ist der Anfang deiner Sicherheitslage, und du wirst froh sein, dass es existiert, wenn dich das erste Mal ein:e Kund:in — oder die Anwältin einer/eines Kund:in — fragt.

Wenn jemand sagt “Lösch meine Daten”

Irgendwann sagt es jemand, und das Gesetz an den meisten Orten (DSGVO in Europa, ähnliche Regeln anderswo) sagt, dass du es tatsächlich tun musst. Entscheide jetzt, wie deine Antwort lautet:

Kannst du eine:n Nutzer:in und alles, was mit ihm/ihr verknüpft ist, löschen? Bitte deinen KI-Builder, das einzubauen — “Bau eine Admin-Aktion, die eine:n Nutzer:in und alle seine/ihre Daten löscht” —, bevor du es unter Zeitdruck brauchst.
Entfernt das Löschen in der App sie auch aus deinem E-Mail-Tool und deinen Analytics? Prüfe deine Liste aus Frage 4.
Backups enthalten sie noch eine Weile. Das ist normal und in der Regel in Ordnung — wisse es nur, damit du es ehrlich sagen kannst.

Eine Löschanfrage an einem Tag zu beantworten, weil du vorbereitet warst, wirkt professionell. Zwei Wochen lang herumzurudern wirkt nach genau dem, was es ist.

Schreib die Datenschutzseite in klarer Sprache

Lass das 4.000-Wörter-Juristendeutsch vorerst weg. Schreib fünf ehrliche Sätze: was du sammelst, warum, wer es sonst noch anfasst (dein E-Mail-Tool, dein Zahlungsdienstleister), wie lange du es aufbewahrst und wie man die Löschung beantragt. Pack sie unter /privacy und verlink sie von deiner Anmeldeseite.

Das ist keine Rechtsberatung, und wenn du wirklich sensible Daten verarbeitest — Gesundheit, Kinder, Finanzen —, gib das Geld für eine Stunde mit einer Anwältin aus. Aber eine klare, ehrliche Seite schlägt eine beeindruckend aussehende, die niemand lesen kann, und sie zu schreiben zwingt dich, deine eigenen Antworten wirklich zu kennen.

Die Latte liegt niedriger, als du fürchtest, und höher als null

Du verteidigst nicht gegen Nationalstaaten. Du verteidigst gegen die langweiligen, häufigen Pannen: ein übrig gebliebenes Datenfeld, das niemand brauchte, eine Berechtigungsregel, die niemand getestet hat, eine Passworttabelle, die jemand zu hashen vergaß. Nutzerdaten auf diesem Niveau zu schützen ist keine Spezialistenfähigkeit — jede dieser Pannen ist mit einem Prompt in klarer Sprache und einem Fünf-Minuten-Test behebbar.

Die Coachin vom Anfang hat all das an einem Nachmittag gemacht: zwei ungenutzte Felder gelöscht, den Zwei-Konten-Test durchgeführt (und ein Leck erwischt — Klient:innen konnten in einem Dropdown die Vornamen der anderen sehen), die fünf Fragen gestellt, ihre Datenschutzseite geschrieben. Ihre App sah danach kein bisschen anders aus. Aber als ihre Freundin fragte “Ist das Ding sicher für meine Klientennotizen?”, hatte sie eine echte Antwort.

Nimm dir den Nachmittag. Deine Nutzer:innen haben dir ihre Daten im Vertrauen gegeben — so sieht es aus, dieses Vertrauen zu halten.