Wer eigene Apps mit Claude Code, Codex oder Cursor baut, stößt früher oder später auf die DSGVO. Viele schieben das Thema deshalb so lange auf, bis sie gar nicht erst starten. Dabei geht es meistens nicht um Raketenwissenschaft, sondern um einige Grundlagen, die du sauber abdecken solltest.
Für dieses Video habe ich mit Felix Schweinebraten gesprochen. Felix ist Jurist (LL.M.) und IT-Experte und bietet genau zu diesen Fragen Beratung an. Mehr zu ihm findest du auf schweinebraten.it. In diesem Artikel fasse ich die wichtigsten Punkte zusammen. Er ist keine Rechtsberatung für deinen Einzelfall.
Wann die DSGVO überhaupt gilt
Personenbezogene Daten sind alle Informationen, die sich auf eine identifizierte oder identifizierbare Person beziehen. Dazu gehören Name, E-Mail-Adresse und Telefonnummer, aber auch IP-Adresse, Kundennummer, Standortdaten oder Chatverläufe. Identifizierbar heißt nicht, dass ein Name daneben stehen muss. Es reicht, wenn du die Daten mit zusätzlichen Informationen einer Person zuordnen kannst.
Die Pflichten entfallen nur dann, wenn du eine App wirklich nur für dich selbst baust und garantieren kannst, dass keine Daten anderer darin landen. Sobald du etwas für Kund:innen oder andere Nutzer:innen entwickelst, gilt die DSGVO.
Felix sagt dazu: Du musst nicht das 120-Prozent-Ergebnis erreichen. Wenn du die Grundlagen sauber abdeckst, bist du schon bei 90 bis 95 Prozent. Genau dort scheitern die meisten Projekte nicht.
Die Tools: Konto-Art entscheidet
Die Wahl des Accounts ist wichtiger, als viele denken. Bei privaten oder kostenlosen Konten kannst du oft keine technischen Einstellungen ändern, zum Beispiel das Training mit deinen Daten abschalten. Noch wichtiger: Einen Auftragsverarbeitungsvertrag (AVV) bekommst du meist nur in Business-, Pro-, Team- oder Enterprise-Tarifen. Wenn du dort sparst, fehlt dir ein Vertrag, den das Gesetz eigentlich verlangt.
Der Coding Agent selbst verarbeitet beim Programmieren übrigens selten personenbezogene Daten. Trotzdem kann es passieren, zum Beispiel wenn du mit echten Kundendaten testest.
Was tun, wenn echte Kundendaten im Coding Agent gelandet sind?
Es ist passiert, aber die Welt geht nicht unter. Wichtig ist, sauber zu dokumentieren: Welche Daten waren betroffen, wie viele, und wer ist betroffen? Dann minimierst du den Schaden und prüfst, welche Informationspflichten gegenüber den Betroffenen und möglicherweise der Datenschutzaufsicht bestehen. Die Pflichten sind im Detail genau geregelt. Wer sie verschweigt, macht die Lage in der Regel schlimmer.
Deshalb gilt die Faustregel: Teste mit synthetischen oder anonymisierten Daten, nicht mit echten Kundendaten.
Lokale Modelle: Auch hier gibt es Pflichten
Wenn du Modelle wie Qwen oder Llama auf einem eigenen Rechner betreibst, zu dem niemand von außen Zugriff hat, braucht es keinen AVV mit dem Modellanbieter. Stellst du das Modell aber auf einem gemieteten Server bei Hetzner oder einem anderen Hoster bereit, brauchst du einen AVV mit diesem Hoster.
Dein eigener Pflichtenkatalog verändert sich dadurch nur. Du musst deinen Kund:innen gegenüber trotzdem offenlegen, wer deine Daten verarbeitet.
Der Tech-Stack: EU ist nicht automatisch sicher
Die Aussage „US-Anbieter sind schlecht, EU-Anbieter sind automatisch sicher“ stimmt so nicht. Das Gesetz kennt keine solche Regel. Entscheidend ist, ob ein Anbieter die datenschutzrechtlichen Anforderungen erfüllt und welche Garantien gelten.
Für US-Anbieter gibt es mit dem Data Privacy Framework (DPF) eine Grundlage. Ein Anbieter muss sich dafür selbst zertifizieren. Steht ein großer Anbieter wie Supabase oder OpenAI im DPF, ist das eine gute Voraussetzung. Es betrifft aber nur den Anbieter selbst. Deine eigene Pflicht, den Vertrag zu prüfen und zu klären, ob er zu deinem Einsatz passt, bleibt.
Prüfe also im AVV mindestens: Welche Daten werden verarbeitet, zu welchem Zweck, wo, wie lange, und welche Unterauftragnehmer (Sub-Processors) nutzt der Anbieter? Du musst nicht jede Kette bis zum Ende nachverfolgen, aber einmal hinschauen solltest du.
Selbst Supabase bei dir zu hosten, ist nicht automatisch die Lösung. Ob sich das lohnt, hängt davon ab, welche Daten du verarbeitest, wie viele und wen sie betreffen. Bei Gesundheitsdaten sieht das anders aus als bei einem Shop mit Bestelldaten. Und auch bei eigenem Hosting bleiben viele Pflichten bestehen.
Datensparsamkeit: Nur sammeln, was du brauchst
Datenminimierung heißt: Du darfst nur Daten erheben, die du für deinen Zweck wirklich brauchst. Technisch kannst du oft viel mehr speichern, als du dürftest. Der Grundsatz „Privacy by Default und Privacy by Design“ verlangt, dass du das Nicht-Nötige gar nicht erst erhebst.
Speichere also nichts auf Vorrat, nur weil du es vielleicht später brauchst.
Rechte der Nutzer:innen: Export einplanen
Nutzer:innen haben Rechte, zum Beispiel auf Auskunft und Löschung. Deine App sollte deshalb von Anfang an so gebaut sein, dass du Daten strukturiert exportieren kannst, etwa als CSV oder JSON. Die Auskunft muss zeigen, welche Daten du verarbeitest, zu welchem Zweck, auf welcher Grundlage und wie lange.
Der Einwand „Das hat die Person doch selbst eingegeben“ zählt nicht. Die Person hat weiter Anspruch auf eine Kopie ihrer Daten.
KI in der App: Zwei Pflichten, die oft übersehen werden
Wenn du einen externen Sprachmodell-Dienst in deine App einbaust, etwa einen Kundenchat, kommt ein weiterer Dienstleister dazu. Auch hier gilt: Training deaktivieren, AVV prüfen, Zweck klären.
Seit August 2026 greift außerdem die Kennzeichnungspflicht aus dem AI Act. Nutzer:innen müssen erkennen können, dass sie mit einer KI interagieren. Ein klarer Hinweis wie „Dies ist ein KI-Chat“ reicht meist aus. Die genauen Anforderungen solltest du im Einzelfall prüfen.
Ein Beispiel aus Felix' Praxis: Ein Hotel-Chatbot soll Öffnungszeiten beantworten. Gäste schreiben aber, dass sie eine Laktoseintoleranz haben und fragen nach laktosefreien Alternativen am Frühstücksbuffet. Damit landen Gesundheitsdaten im System, obwohl du sie nie angefragt hast. Diese unaufgeforderten Daten musst du bedenken. Informiere deshalb Nutzer:innen von Anfang an, was mit ihren Eingaben passiert.
Welche Dokumente du brauchst
Für die Nutzer:innen deiner App brauchst du in den meisten Fällen eine eigene Datenschutzerklärung. Die Datenschutzerklärung in der Website-Fußzeile reicht dafür nicht.
Außerdem brauchst du AGB, die die Zusammenarbeit regeln: Haftung, Zahlungsbedingungen, Kündigungsfristen und Mitwirkungspflichten.
Wenn du für Kund:innen Software entwickelst und dabei personenbezogene Daten für sie verarbeitest, bist du oft Auftragsverarbeiter. Dann brauchst du einen eigenen AVV für diese Kund:innen.
Intern brauchst du außerdem ein Verzeichnis der Verarbeitungstätigkeiten und eine Dokumentation der technischen und organisatorischen Maßnahmen (TOM). Diese Unterlagen musst du nicht veröffentlichen, aber Behörden können sie anfordern.
Wenn deine Verarbeitung ein hohes Risiko birgt, etwa durch KI oder sensible Daten, ist außerdem eine Datenschutz-Folgenabschätzung (DSFA) nötig. Sie zwingt dich, Vor- und Nachteile abzuwägen und Maßnahmen wie Rollen- und Zugriffskonzepte festzulegen.
Warum du Rechtstexte nicht von der KI schreiben lassen solltest
Ein Datenschutztext aus einer KI sieht professionell aus, enthält aber oft Aussagen, die nicht zu deinem Fall passen oder schlicht falsch sind. Die Modelle greifen auf öffentliche Meinungen zurück, nicht auf die Rechtslage. Haftet musst du als Betreiber, nicht der KI-Anbieter.
Mein Fazit dazu: Die KI ist ein guter Gesprächspartner, um Fragen vorzubereiten. Die Verantwortung für die fertigen Dokumente trägst du.
Mein Fazit
Die DSGVO ist kein Grund, eigene Apps nicht zu bauen. Die Grundlagen sind:
- Klären, ob du überhaupt personenbezogene Daten verarbeitest
- Tarife mit AVV wählen und Training abschalten
- Mit synthetischen Daten testen
- Nur sammeln, was du brauchst, und Export einplanen
- Datenschutzerklärung, AGB und AVV für deine Kund:innen bereithalten
- Bei heiklen Fällen eine Fachperson einbeziehen
Felix bietet laut Video eine kostenlose, unverbindliche Erstberatung an. Die Kontaktdaten findest du auf schweinebraten.it.
