KI nutzen.
Daten bewusst schützen.

In ein privates Chat-Konto: nein. Dort fehlt der Vertrag zur Auftragsverarbeitung, und je nach Einstellung können Eingaben zum Training verwendet werden. Mit einem Geschäftsangebot und Vertrag sieht das anders aus, die Übermittlung in die USA bleibt aber ein Thema. Mit der Schleuse aus diesem Bauplan geht gar kein Klartext mehr raus.

Bei der Pseudonymisierung gibt es einen Schlüssel, mit dem du zurückrechnen kannst. Bei der Anonymisierung gibt es keinen Weg zurück. Für Support brauchst du fast immer den Weg zurück, weil die Antwort bei der richtigen Person ankommen soll. Anonymisierung ist für Statistiken und Wissensbasen da.

Leider nein. Telefonnummern, Kundennummern, Adressen und Mailadressen identifizieren genauso gut. Dazu kommen Details wie Beruf plus Ort. Und Schwärzen ohne Typ macht den Text für die KI schwer verständlich. Typisierte Platzhalter lösen beides.

Das lässt sich am konkreten Fall testen. Für viele Einordnungsaufgaben ist unwichtig, ob die Kundin Petra oder [PERSON_1] heißt. Wichtig ist, dass der Typ erkennbar bleibt und derselbe Name immer denselben Platzhalter bekommt. Schwierig wird es nur, wenn der Name selbst Teil der Aufgabe ist, etwa bei der Prüfung einer Schreibweise.

Für den Arbeitsalltag oft ja. Microsoft 365 Copilot arbeitet in der Umgebung, die viele Unternehmen schon geprüft und freigegeben haben. Deshalb ist er für viele der realistische Einstieg. Dieser Bauplan ist für automatisierte Abläufe gedacht, bei denen du ein bestimmtes Modell nutzen willst oder Daten aus mehreren Systemen zusammenführst.

Ja, mit europäischen Anbietern oder lokalen Modellen. Offene Modelle sind für Einordnung und einfache Entwürfe oft schon gut genug. Qualität und Hardwarebedarf hängen von Modell und Aufgabe ab. Viele Teams kombinieren: lokal für den Wächter und die Embeddings, das große Modell nur für die bereinigte Aufgabe.

Das hängt von seinen realistischen Identifizierungsmöglichkeiten ab. Der EuGH verneint einen automatischen Personenbezug für jeden Empfänger, aber auch einen automatischen Wegfall. Platzhalter allein belegen keine Anonymität. Die konkrete Übermittlung braucht eine dokumentierte Prüfung.

Wenn ein Dienst personenbezogene Daten in deinem Auftrag verarbeitet, ist Art. 28 DSGVO maßgeblich. Prüft zunächst Rollen und Datenflüsse. Die bloße Hoffnung, dass keine Erkennungslücke auftritt, ersetzt diese Prüfung nicht.

Dann muss geprüft werden, ob die betroffene Übermittlung auf einer anderen tragfähigen Grundlage fortgeführt werden kann. Standardvertragsklauseln erfordern eine eigene Bewertung und gegebenenfalls zusätzliche Maßnahmen. Ist kein angemessener Schutz erreichbar, muss die Übermittlung ausgesetzt werden.

Prüft die Informationspflichten aus Art. 13 und 14 DSGVO einschließlich Zweck, Rechtsgrundlage, Empfängern oder Empfängerkategorien und gegebenenfalls Drittlandtransfer. Ein einzelner allgemeiner Satz über KI ersetzt die vollständigen Pflichtangaben nicht.

Sie ist erforderlich, wenn die Verarbeitung voraussichtlich ein hohes Risiko für Rechte und Freiheiten verursacht. Art. 35 DSGVO, behördliche Listen und der konkrete Umfang sind zu prüfen. Haltet auch die Begründung fest, wenn ihr keine Folgenabschätzung für erforderlich haltet.

Für besondere Kategorien nach Art. 9 DSGVO gelten deutlich strengere Regeln. In diesem Bauplan gehen solche Vorgänge gar nicht zur US-KI. Der Wächter soll sie erkennen und an einen Menschen oder ein freigegebenes lokales Modell geben. Seine Erkennung ist keine Garantie. Das Labor oben zeigt genau diesen Fall.

Die Einordnung richtet sich nach Zweck und tatsächlichem Einsatz. Ein Support-Entwurf allein belegt weder Hochrisiko noch eine Ausnahme von allen Pflichten. Prüft insbesondere Transparenz, menschliche Kontrolle und die für euch anwendbaren Anforderungen anhand der aktuellen Rechtsfassung.

Nie hundertprozentig. Auch Muster für Nummern und Adressen übersehen abweichende Schreibweisen. Namen und indirekte Hinweise sind besonders schwierig. Deshalb drei Schichten, ein Wächter und regelmäßige Tests mit echten, intern geprüften Mails. Miss auch die übersehenen Angaben und Fehlalarme. Verbessere gezielt dort, wo etwas durchrutscht.

Reguläre Ausdrücke finden nur, was eine feste Form hat. Namen und Orte haben keine. Presidio verbindet Muster mit einem Sprachmodell, ist quelloffen, läuft lokal und lässt sich um eigene Erkenner erweitern. Für deutsche Texte braucht es ein deutsches Sprachmodell und etwas Feinarbeit.

Um Embeddings zu erzeugen, muss das Modell den Text lesen. Läuft das über eine US-Schnittstelle, geht der Text dorthin, im schlimmsten Fall vor der Schleuse. Gute mehrsprachige Embedding-Modelle laufen auch auf einem normalen Server ohne Grafikkarte.

In einer eigenen, verschlüsselten Tabelle auf deinem Server, getrennt von n8n und ohne Zugriff für den KI-Anbieter. Pro Vorgang ein eigener Satz Zuordnungen. Gelöscht wird nach einer festen Frist, sobald der Vorgang abgeschlossen ist. Das Ticket selbst mit den echten Daten liegt ohnehin in deinem Ticketsystem.

Nie automatisch an die KI. Wenn der Inhalt gebraucht wird, liest ihn eine lokale Texterkennung aus. Danach läuft der Text durch dieselbe Schleuse wie die Mail. Bilder mit Gesichtern, Unterschriften oder Ausweisen bleiben grundsätzlich im Haus.

Sie kann es versuchen. Das nennt sich Prompt Injection. Die wirksamste Abwehr ist, der KI wenig Macht zu geben: Sie ordnet ein und schreibt Entwürfe, sie schickt nichts ab, ändert keine Daten und ruft keine Werkzeuge auf. Ein festes Ausgabeformat und menschliche Prüfung reduzieren weitere Risiken, garantieren aber keine vollständige Abwehr.

n8n sieht die Mail im Klartext. Selbst gehostet bestimmst du Standort, Speicherung, Protokolle und Zugriffe. Außerdem kannst du die Schleuse, den Tresor und die Vektordatenbank im selben abgeschotteten Netz betreiben.

Ein Mensch aus dem Support. Die KI bereitet vor, der Mensch entscheidet und schickt ab. Das Team sollte Prüfzeit und Fehler messen und daraus lernen. Abschaffen würde ich sie bei Kundenantworten nicht.

Mit einer Sammlung typischer Mails, in denen alle personenbezogenen Angaben vorher von Hand markiert wurden. Die Schleuse läuft darüber, und du zählst, was gefunden wurde und was nicht. Dazu ein Protokoll, das nur die bereinigte Fassung speichert, damit du stichprobenartig prüfen kannst, was wirklich rausging.

Übermittlung stoppen, Vorfall dokumentieren und mit Datenschutz und IT bewerten. Besteht die Meldepflicht nach Art. 33 DSGVO, ist die Aufsicht unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden zu informieren. Die Ausnahme bei voraussichtlich fehlendem Risiko und eine Information Betroffener nach Art. 34 sind gesondert zu prüfen.

Wenn das System geeignet ist, Leistung oder Verhalten einzelner Mitarbeitender zu überwachen, ja. Das ist bei Ticketsystemen mit Bearbeitungszeiten schnell der Fall. Eine Betriebsvereinbarung, die klar regelt, was ausgewertet wird und was nicht, schafft Vertrauen auf beiden Seiten.

Ob sich der Aufwand lohnt, hängt von Volumen, Betriebskosten, Fehlern und Prüfaufwand ab. Der Gewinn: Das Team bekommt vorsortierte Anfragen und gute Entwürfe, und du kannst jederzeit erklären, welche Daten wohin geflossen sind. Gerade das Zweite ist im Gespräch mit Datenschutz und Geschäftsführung Gold wert.