Wenn ich mit Kunden über neue Software-Projekte spreche, kommt fast immer irgendwann die Frage: Ist das Ganze eigentlich DSGVO-konform, sobald KI im Spiel ist? Die ehrliche Antwort, die ich dann gebe, gefällt nicht jedem: Nein, automatisch ist gar nichts konform. Nicht weil ein europäischer Cloud-Anbieter draufsteht, nicht weil auf einer Website \"sicher\" steht, und auch nicht weil das Modell gerade das neueste am Markt ist.
Ich habe in den letzten Monaten mehrere Projekte gebaut, bei denen genau diese Frage im Zentrum stand. Und ich habe gelernt: Die eigentliche Gefahr liegt nicht in der KI selbst. Sie liegt im Datenfluss - also darin, welche Daten wohin geschickt werden und warum.
Warum die KI nicht das Problem ist, sondern der Datenfluss
Ein Beispiel aus der Praxis, das ich gerne nutze, um das zu erklären: Ich baue eine Software, die Kunden strukturiert. Sie soll erkennen, welche Kunden in der Nähe meines Firmensitzes liegen, welche sich zu Besuchstouren gruppieren lassen und welche aus welcher Region kommen. Dafür liegen in meinem System Namen, Firmen, Adressen, E-Mails, Telefonnummern und teilweise interne Notizen.
Die naheliegende, aber falsche Idee wäre: Alles an die KI schicken und sagen \"Sortiere mir das nach Entfernung und Relevanz\". Genau das würde ich nicht mehr machen. Für eine reine Entfernungsauswertung braucht die KI weder Namen noch E-Mail-Adresse noch Telefonnummer.
Es reicht, wenn meine Software intern vorbereitet: Kundennummer, Region, Entfernung, Status. Die KI bekommt dann sowas wie \"Kunde K-1048, Region Ludwigsburg, Entfernung 12 km, Bestandskunde\". Die echte Identität bleibt in meiner eigenen Datenbank. Erst wenn die KI eine Struktur zurückgibt, ordnet meine Anwendung intern wieder den echten Namen zu.
Die KI sollte nie mehr wissen, als sie für die konkrete Aufgabe unbedingt wissen muss.
Datenminimierung ist kein Nice-to-have
Die DSGVO verlangt unter anderem Zweckbindung, Datenminimierung und Nachweisbarkeit - geregelt in Art. 5 DSGVO. Praktisch heißt das: Ich darf nicht alles verarbeiten, nur weil es technisch möglich ist. Viele KI-Tools verleiten aber genau dazu, möglichst viel in einen Prompt zu werfen. Bequem, aber datenschutzrechtlich meistens keine gute Idee.
Wichtig ist außerdem der Unterschied zwischen Pseudonymisierung und Anonymisierung. Wenn ich aus \"Max Müller\" die Nummer \"K-1048\" mache, ist das keine echte Anonymisierung. Ich weiß ja in meiner eigenen Software immer noch, wer sich hinter der Nummer verbirgt. Es ist Pseudonymisierung - besser geschützt, aber weiterhin personenbezogen. Für die meisten Geschäftsanwendungen ist das trotzdem der realistische Weg, weil man Kunden später ja wieder zuordnen will.
Welcher KI-Anbieter passt eigentlich zu welchem Zweck
Sobald externe Dienste ins Spiel kommen, kommt automatisch das Thema Auftragsverarbeitung dazu. Nach Art. 28 DSGVO brauche ich in der Regel einen Vertrag, sobald ein Anbieter personenbezogene Daten in meinem Auftrag verarbeitet. Ich habe mir für Projekte drei unterschiedliche Bausteine genauer angeschaut, die ich in der Praxis auch schon eingesetzt habe.
Der IONOS AI Model Hub ist für mich vor allem interessant, weil er als europäische beziehungsweise deutsche KI-Infrastruktur positioniert ist. IONOS beschreibt auf der Produktseite, dass Daten unter Kontrolle des Kunden bleiben und nicht fürs Training genutzt werden. In der AI-Act-Dokumentation steht zudem, dass Inference-Endpunkte und Vektordatenbanken in ISO-27001-zertifizierten deutschen Rechenzentren laufen. Das ist eine gute Grundlage - aber eben nur eine Grundlage. Ob meine eigene Anwendung sauber gebaut ist, muss ich trotzdem selbst verantworten.
n8n ist etwas ganz anderes. Keine KI, sondern eine Automatisierungsplattform. Ich nutze es gerne, um Systeme zu verbinden und Workflows zu bauen. Genau das macht n8n aber zu einem zweischneidigen Schwert. Als Schutzbaustein kann ich damit eine Art Datenschutz-Schleuse bauen: Kundendaten kommen aus dem CRM, werden bereinigt und pseudonymisiert, bevor sie an eine KI gehen.
Gleichzeitig kann n8n gefährlich werden, wenn niemand mehr überblickt, welche Daten aus CRM, E-Mail, Sheets und Shop plötzlich zusammenlaufen. Bei Self-Hosting liegt die Verantwortung für Verschlüsselung, Zugriffsschutz und Updates komplett bei mir als Betreiber - n8n selbst ist dann weder Controller noch Processor. In der n8n Cloud, die aktuell in der EU auf Microsoft Azure läuft, ist n8n stärker Teil der Verarbeitung, mit Zugriffskontrollen, MFA und Audit Logging.
Langdock wiederum ist eine zentrale KI-Plattform fürs Unternehmen. Statt dass jeder Mitarbeiter private KI-Tools nutzt und irgendwelche Daten dort hineinkopiert, gibt es eine kontrollierte Oberfläche mit Rollen und Berechtigungen. Langdock beschreibt ISO-27001- und SOC-2-Zertifizierungen und schließt Training mit Kundendaten aus. Das reduziert Wildwuchs enorm - löst aber nicht das Grundproblem, wenn Mitarbeiter trotzdem komplette Kundenlisten in den Chat kopieren.
- IONOS AI Model Hub: KI-Infrastruktur mit europäischem Fokus - sinnvoll für eigene Softwareentwicklung
- n8n: Automatisierungs- und Integrationsschicht - mächtig, aber streng zu kontrollieren
- Langdock: Unternehmensplattform gegen Schatten-KI - ordnet die Nutzung, ersetzt aber keine Datenminimierung
Meine Architektur für maximale Sicherheit
Für mich hat sich eine Kombination bewährt, die ich auch bei Kundenprojekten im E-Commerce so umsetze. Die vollständigen Kundendaten bleiben in meiner eigenen Anwendung. Ein interner Dienst berechnet Entfernung, Region und Status selbst, ohne KI.
n8n kann optional als Workflow-Layer dienen, der Daten reduziert und nur freigegebene Felder weiterleitet. Die KI läuft über einen geprüften Anbieter wie IONOS. Und wenn Mitarbeiter selbst mit KI arbeiten sollen, passiert das über eine kontrollierte Umgebung wie Langdock statt über private Chatbots.
Der wichtigste Satz, den ich mir dabei immer wieder vor Augen halte: Kein Tool nimmt mir die Verantwortung für den Datenfluss ab. Egal wie gut der Anbieter ist.
Die Reihenfolge, die ich mittlerweile immer einhalte
Wenn ich heute ein neues Projekt mit KI-Anbindung starte, gehe ich eine feste Reihenfolge durch. Das klingt bürokratischer, als es ist - nach ein paar Projekten wird das zur Routine.
- Prüfen, ob ich für die Aufgabe überhaupt KI brauche
- Daten so weit wie möglich reduzieren
- Pseudonymisieren, wo Daten trotzdem gebraucht werden
- Anbieter sorgfältig prüfen (AV-Vertrag, Hosting, Trainingsnutzung)
- Verträge sauber abschließen
- Logging, Rechte und Löschkonzepte umsetzen
- Erst dann echte Kundendaten verarbeiten
Bei der Anbieterauswahl schaue ich mittlerweile nicht zuerst auf das beste Modell. Ich frage: Gibt es einen AV-Vertrag? Werden Daten fürs Training genutzt? Wo wird gehostet, EU oder Self-Hosting? Welche Unterauftragnehmer sind beteiligt? Wie lange werden Prompts gespeichert? Gibt es Rollen, SSO, MFA, Audit Logs? Erst wenn diese Fragen geklärt sind, macht es für mich Sinn, über Modellqualität zu sprechen.
Mein Fazit nach mehreren Projekten in diesem Bereich: DSGVO-konforme KI entsteht nicht durch einen einzelnen Anbieter, egal wie gut dessen Marketing klingt. Sie entsteht durch eine saubere Konstruktion, bei der sensible Kundendaten möglichst in der eigenen Software bleiben und die KI nur das sieht, was sie wirklich braucht. Das ist mehr Aufwand beim Bauen - aber genau dieser Aufwand ist am Ende der eigentliche Unterschied zwischen "wir nutzen halt KI" und einer Software, die ich auch guten Gewissens meinen eigenen Kunden erkläre.
