Datenschutz ist bei uns kein Anhang im Kleingedruckten, sondern eine Bauentscheidung. Sechs Punkte, in denen wir konkret werden - wo deine Daten leben, wer drankommt, wie wir KI absichern, und was im Auftragsverarbeitungsvertrag steht.
Datenschutz wird oft als Pflichtübung behandelt - ein Cookie-Banner oben drauf, eine Erklärung im Footer, fertig. Wir sehen das anders. Wenn wir Software für deinen Betrieb bauen, gehören Datenschutz und Datensparsamkeit zur ersten Skizze - nicht zur letzten.
Diese Seite zeigt dir, woran wir uns halten. Sie ist nicht die Datenschutzerklärung von wendwerk.de - die findest du im Footer als rechtliches Dokument. Sie ist unser Konzept: wo wir hosten, wie wir KI einsetzen, welche Verträge wir abschließen, wer Zugriff hat. Wenn du dich für ein Projekt mit uns entscheidest, wird genau das die Grundlage.
EU-Hosting
Alles, was deine Software an Daten speichert, liegt auf Servern in der EU oder Deutschland.
Verträge
Ein Auftragsverarbeitungsvertrag mit dir, ein Vertrag mit jedem Dienstleister, der mit deinen Daten arbeitet.
Datensparsamkeit
Wir speichern, was wir brauchen - und nicht mehr. Auch nicht "für später" oder "weil es ginge".
Software braucht einen Ort, an dem sie läuft, und einen, an dem die Daten liegen. Bei uns sind das ausschließlich Anbieter in der EU oder in Deutschland. Web-Frontends laufen auf Vercel in der Frankfurter Region. Datenbanken und Anmeldungen liegen auf Supabase in Frankfurt (Region eu-central-1). Wo eigene Server nötig sind, sitzen die bei Hetzner oder IONOS - beide deutsch, beide DSGVO-konform.
Das ist eine bewusste Entscheidung. Es gibt günstigere US-Anbieter, es gibt schnellere globale CDNs. Aber für Software, die im deutschen Mittelstand laufen soll, ist EU-Hosting kein Nice-to-have, sondern Voraussetzung - rechtlich und praktisch. Im Vertrag steht jeder einzelne Anbieter, der mit deinen Daten in Berührung kommt, namentlich drin. Du weißt jederzeit, wo deine Daten liegen, und du kannst es überprüfen.
Hintergrund ist das Schrems-II-Urteil (EuGH 2020), das die rechtliche Lage für US-Cloud-Anbieter erheblich verschärft hat. Daten an US-Server zu übermitteln ist nicht grundsätzlich verboten, aber an aufwendige Prüfungen geknüpft - und in vielen Fällen schlicht riskant. Die deutsche Datenschutzkonferenz hat 2024 in ihren Beschlüssen mehrfach klargestellt, dass die Wahl EU-basierter Anbieter die rechtlich sauberste Lösung ist.
Praktisch heißt das: Vercel betreibt seine Serverless-Functions in Frankfurt (Region fra1), Supabase nutzt AWS Frankfurt für die Projekte, die in eu-central-1 liegen. Hetzner und IONOS betreiben eigene Rechenzentren in Deutschland. Damit ist die Datenverarbeitung an jedem Punkt im EU-Raum verankert - inklusive Backups, Logs und temporären Kopien.
Wenn wir für dich Software bauen, in der personenbezogene Daten verarbeitet werden - Kundenkontakte, Nutzeranmeldungen, was auch immer -, sind wir rechtlich dein Auftragsverarbeiter. Das muss schriftlich geregelt sein. Bei uns ist das Standard, nicht Sonderfall: Bei jedem Projekt mit Personenbezug schließen wir mit dir einen Auftragsverarbeitungsvertrag (AVV) ab. Du musst nicht danach fragen, und du musst ihn nicht selbst entwerfen.
Im AVV steht, welche Daten verarbeitet werden, zu welchem Zweck, wie lange, wer Zugriff hat, welche technischen und organisatorischen Maßnahmen wir einsetzen, und was passiert, wenn etwas schiefgeht. Er enthält außerdem die Liste der Unter-Auftragsverarbeiter - also der Anbieter wie Vercel, Supabase oder Hetzner, deren Dienste wir nutzen, und mit denen wir wiederum eigene Verträge geschlossen haben. Diese Verträge bekommst du auf Wunsch im Original zur Einsicht.
Die rechtliche Grundlage ist Art. 28 DSGVO: Wer personenbezogene Daten im Auftrag eines anderen verarbeitet, muss das auf Basis eines schriftlichen Vertrages tun, der bestimmte Mindestinhalte enthält. Ohne AVV ist die Verarbeitung schlicht rechtswidrig - und im Schadensfall haftet im Zweifel der Auftraggeber, weil er die Datenverarbeitung nicht ordnungsgemäß ausgelagert hat.
Bei vielen Dienstleistern muss der Kunde den AVV explizit einfordern - bei manchen ist er gegen Aufpreis zu haben, bei anderen versteckt im Self-Service-Portal. Wir machen das anders: Der AVV liegt auf dem Tisch, bevor die erste Zeile Code geschrieben wird. Du musst nicht prüfen, ob du ihn brauchst - wenn überhaupt personenbezogene Daten im Spiel sind, gibt es ihn automatisch.
KI-Funktionen in deiner Software laufen bei uns nicht über die kostenlosen Endkunden-Chats von OpenAI oder Anthropic. Wir nutzen die API-Zugänge mit Geschäftsvertrag - bei uns als Standard Anthropic Claude, je nach Anwendungsfall auch andere Anbieter. In diesen Geschäftsverträgen ist vertraglich ausgeschlossen, dass deine Eingaben zum weiteren Training der Modelle genutzt werden. Was reingeht, kommt nicht in das nächste Modell-Update.
Wo der Anwendungsfall es verlangt, routen wir KI-Anfragen über EU-Regionen - das ist je nach Anbieter unterschiedlich aufwendig, aber technisch möglich. Wo es zu sensibel wird oder wo EU-Verarbeitung explizit Pflicht ist, setzen wir europäische Anbieter (Mistral) oder lokale Modelle ein. Welcher Anbieter konkret für welche KI-Funktion in deinem Projekt zuständig ist, steht im Auftragsverarbeitungsvertrag - mit Namen, Region und Zweck. Du weißt, was passiert, und du kannst es nachvollziehen.
Die rechtliche Grundlage ist hier doppelt: einerseits die DSGVO, andererseits seit 2024 der EU AI Act. Beide verlangen, dass die Nutzung von KI-Diensten transparent geregelt und vertraglich abgesichert ist. Die Datenschutzkonferenz hat 2024 in einer eigenen Orientierungshilfe ausdrücklich klargestellt, dass die naive Nutzung öffentlicher KI-Tools mit personenbezogenen Daten in der Regel rechtswidrig ist.
Anthropic schließt auf seinen Geschäftsverträgen den Standard-AVV mit Modul für internationale Übermittlungen ab. OpenAI bietet seit 2024 für API-Kunden Zero Data Retention an - Anfragen werden nicht gespeichert, nicht ans Training weitergegeben. Wer das nutzt, erfüllt die DSGVO-Anforderungen weitgehend. Wer aber die kostenlosen Endkunden-Chats nutzt, tut das nicht - dort ist die Trainingsnutzung der Default. Genau diesen Unterschied machen wir in jedem Projekt explizit transparent.
Der beste Datenschutz ist das, was nie gespeichert wird. Bei jeder Software, die wir bauen, prüfen wir am Anfang gemeinsam mit dir: Welche Daten brauchen wir tatsächlich, damit das Werkzeug seine Aufgabe erfüllt? Was wäre nice to have, aber nicht nötig? Was wäre eine Erinnerungs-Hilfe, die wir genauso gut weglassen können? Vieles, was Systeme von der Stange standardmäßig sammeln - Tracking, IP-Logs, Klick-Pfade, Geräte-Fingerprints - bauen wir bewusst gar nicht erst ein.
Für die Anmeldung deiner Mitarbeiter und Kunden nutzen wir nach Möglichkeit den Magic-Link-Login: Statt Passwort gibt man die E-Mail-Adresse ein und bekommt einen einmaligen Anmelde-Link per Mail. Damit speichern wir keine Passwörter und vermeiden die ganze Klasse von Passwort-bezogenen Datenpannen. Datensparsamkeit ist keine Tugend, die wir nachträglich aufkleben. Sie ist eine Architektur-Entscheidung am ersten Tag.
Der rechtliche Begriff ist Privacy by Design und Privacy by Default - festgeschrieben in Art. 25 DSGVO. Die Idee: Datenschutz beginnt nicht beim fertigen System, sondern bei der Architektur. Datenminimierung ist ein eigener Grundsatz in Art. 5 Abs. 1 lit. c DSGVO: Es dürfen nur so viele Daten verarbeitet werden, wie für den jeweiligen Zweck tatsächlich nötig sind.
Magic-Link-Logins sind in den vergangenen Jahren zum Standard in der Industrie geworden, weil sie zwei Probleme gleichzeitig lösen: Sie speichern keine Passwörter (also auch keine Passwort-Datenbanken, die geknackt werden könnten), und sie verlangen vom Nutzer keine eigene Passwort-Hygiene. Auch Banken und große Plattformen setzen das zunehmend ein. Wo ein klassischer Login nötig ist - etwa weil ein bestehendes System mitspielt -, nutzen wir bewährte Standards mit gehashten Passwörtern (bcrypt, argon2).
Auf deine Daten hat im Regelfall genau eine Person Zugriff - der Mensch, der das Projekt baut und betreut. Bei laufenden Projekten also Johannes Hohls als technischer Verantwortlicher. Wenn das Projekt größer wird und weitere Entwicklerinnen oder Entwickler einsteigen, werden sie namentlich in den Auftragsverarbeitungsvertrag aufgenommen - mit eigener Vertraulichkeitsverpflichtung. Es gibt keine anonymen Service-Accounts, die "halt einfach so" Zugriff haben.
Innerhalb deines Betriebs entscheidest du, wer was sehen darf. Software, die wir bauen, hat von Anfang an ein Rollensystem - Geschäftsführung sieht anderes als Buchhaltung, Buchhaltung anderes als Außendienst. Das ist nicht nur sauber, sondern auch DSGVO-konform: Zugriffsrechte sind Teil der technisch-organisatorischen Maßnahmen, die wir im AVV beschreiben. Die Frage "wer hätte eigentlich gerade Zugriff auf was?" muss in deinem Betrieb jederzeit beantwortbar sein.
Der Fachbegriff ist Need-to-know-Prinzip - jeder bekommt nur Zugriff auf die Daten, die er für seine Aufgabe tatsächlich braucht. In der DSGVO steckt das in Art. 32 (Sicherheit der Verarbeitung) und in den dort geforderten technischen und organisatorischen Maßnahmen (TOMs). Klassische Beispiele: Rollen- und Rechtekonzepte, getrennte Zugänge für unterschiedliche Funktionsbereiche, Protokollierung sensibler Zugriffe.
Praktisch heißt das in der Software: Beim Anlegen jedes Benutzerkontos wird eine Rolle vergeben. Die Rolle steuert, welche Bereiche der Software sichtbar sind, welche Datensätze geladen werden, welche Aktionen erlaubt sind. Wer keine Rolle für einen Bereich hat, sieht nicht einmal, dass es ihn gibt - damit ist nicht nur der unbefugte Zugriff, sondern auch das unbefugte Wissen davon ausgeschlossen.
Wenn deine Software personenbezogene Daten verarbeitet, haben die betroffenen Personen Rechte: Auskunft, Berichtigung, Löschung, Einschränkung, Datenübertragbarkeit, Widerspruch. Wir bauen diese Rechte von Anfang an in die Software ein, statt sie nachträglich anzuflicken. Wenn jemand Auskunft will, gibt es einen Knopf dafür. Wenn jemand Löschung verlangt, gibt es einen sauberen Prozess - und keine Excel-Liste, die in einem alten Backup weiterlebt.
Und wenn etwas schiefgeht - eine Datenpanne, ein Sicherheitsvorfall, ein versehentlicher Zugriff - wirst du innerhalb von 24 Stunden informiert. So steht es im AVV, so haben wir es im Prozess. Du brauchst keine Panik haben, sondern eine klare Information darüber, was passiert ist, was wir tun, und was deine Pflichten als Verantwortlicher gegenüber den Aufsichtsbehörden und Betroffenen sind. Datenschutz heißt im Ernstfall: Du bist nicht allein damit.
Die Rechte der Betroffenen stehen in Art. 15-22 DSGVO. Die Meldepflicht bei Datenschutzverletzungen regelt Art. 33 DSGVO: Der Verantwortliche muss eine Datenpanne innerhalb von 72 Stunden bei der Aufsichtsbehörde melden. Damit du das einhalten kannst, müssen wir dich als Auftragsverarbeiter unverzüglich informieren - in unserem AVV ist die Frist auf 24 Stunden ab Bekanntwerden festgelegt.
Praktisch bauen wir alle Software-Anwendungen so, dass die Rechte der Betroffenen ohne manuellen Eingriff durchsetzbar sind: ein Export aller eigenen Daten zum Download, ein Löschen-Knopf, der den Datensatz tatsächlich entfernt (inklusive abgeleiteter Kopien), ein Schalter für Widerspruch gegen bestimmte Verarbeitungen. Damit erfüllst du deine Pflicht und musst nicht jedes Mal das technische Team anrufen - das spart Zeit, Geld und vermeidet menschliche Fehler im Prozess.
Datenschutz ist keine Funktion, die man am Ende einbaut. Es ist eine Bauentscheidung am Anfang - und sie zahlt sich über die ganze Lebensdauer der Software aus.
Wir bauen Software nicht für ein Jahr, sondern für die nächsten fünf oder zehn. In dieser Zeit wird sich vieles ändern: Gesetze, Bedrohungslagen, deine Belegschaft, deine Kunden. Was sich nicht ändern wird, ist die Tatsache, dass Vertrauen die teuerste Währung im Digitalen ist - und dass es einfacher zu verlieren als zu gewinnen ist. Datenschutz, wie wir ihn handhaben, ist unsere Antwort darauf.
Wie KI bei uns konkret zum Einsatz kommt, steht unter Was ist eigentlich KI und Was KI nicht kann, auch wenn es so wirkt. Warum wir generell zuerst die solide Grundlage und dann erst die KI bauen, liest du unter Erst die Werkzeuge, dann die KI.