Der Datenfluss, den niemand kennt: Wo Ihre Daten in automatisierten Prozessen wirklich landen

Letzten Monat saß ich mit dem Geschäftsführer eines Maschinenbauers zusammen, knapp 80 Mitarbeiter, eine grundsolide Firma. Er war stolz auf seine Automatisierung. Eine Anfrage kommt über das Kontaktformular, wird mit Firmendaten angereichert, landet strukturiert im CRM, der Vertrieb bekommt eine Nachricht aufs Handy. Das lief seit anderthalb Jahren ohne Murren. Dann habe ich eine einzige Frage gestellt: Durch welche Länder laufen diese Daten eigentlich, vom Klick auf "Absenden" bis zur Nachricht im Vertrieb? Im Raum wurde es still. Niemand konnte es beantworten.

Das ist kein Einzelfall, das ist der Normalfall. Die meisten Unternehmen, die mir ihre Automatisierung als "DSGVO-konform" beschreiben, meinen damit: Wir haben mit deutschen oder europäischen Anbietern Verträge unterschrieben. Das ist nicht falsch, aber es ist die halbe Wahrheit. Wo Ihre Daten wirklich liegen, während ein automatisierter Prozess läuft, ist eine andere Frage. Und sie wird fast nie gestellt.

In diesem Artikel zeige ich Ihnen, warum der Datenfluss der blinde Fleck fast jeder Automatisierung ist, an welchen Stellen Daten unbemerkt das Land wechseln, und wie Sie Ihren eigenen Stack in unter zwei Stunden so aufzeichnen, dass Sie auf die Frage Ihrer Aufsichtsbehörde eine echte Antwort haben.

"DSGVO-konform" ist eine Behauptung über Daten, die Sie nie gesehen haben

Wenn ein Anbieter mit "DSGVO-konform" wirbt, sagt das etwas über seine Verträge aus, nichts über Ihren Prozess. Make hat seinen Hauptsitz in Prag und Server in der EU. Trotzdem kann ein Make-Szenario in fünf Minuten Daten an einen US-Dienst schicken, ohne dass Make dafür etwas kann. Die Plattform ist europäisch, der Datenfluss ist es nicht zwangsläufig.

Der Denkfehler steckt in der Annahme, Compliance sei eine Eigenschaft von Werkzeugen. Ist sie nicht. Compliance ist eine Eigenschaft des konkreten Weges, den ein einzelner Datensatz nimmt. Zwei Firmen können dasselbe Tool nutzen, dieselben Anbieter, dieselben AVV unterschrieben haben, und trotzdem hat die eine ein Drittlandproblem und die andere nicht. Es hängt davon ab, welche Module sie in welcher Reihenfolge verkettet haben.

Ich habe mir angewöhnt, in Erstgesprächen nicht nach der Tool-Liste zu fragen, sondern nach dem Weg eines einzigen Datensatzes. "Nehmen wir die letzte Bewerbung, die reinkam. Erzählen Sie mir, wo der Lebenslauf überall vorbeikommt, bis er im Postfach der Personalabteilung liegt." Die Antwort dauert selten unter zehn Minuten, und meistens ist sie lückenhaft. Genau in diesen Lücken sitzt das Risiko.

Festhalten lässt sich an dieser Stelle schon eines: Ein Vertrag mit einem EU-Anbieter ist die Eintrittskarte, nicht der Beweis. Den Beweis liefert nur der dokumentierte Weg der Daten.

Was ein Datenfluss eigentlich ist

Bevor wir tiefer gehen, lohnt eine saubere Unterscheidung, weil hier die meisten Missverständnisse beginnen. Ein Datenfluss ist die Antwort auf vier Fragen, gestellt für jeden einzelnen Schritt eines Prozesses: Welche personenbezogenen Daten? Wer verarbeitet sie? Wo physisch? Und wer steht noch dahinter?

Wo der Workflow läuft, sagt nichts darüber, wo die Daten liegen

Das ist die Unterscheidung, an der die meisten scheitern. Der Ort, an dem Ihr Automatisierungs-Tool die Logik ausführt, und der Ort, an dem die Daten am Ende liegen, sind zwei verschiedene Dinge.

Ein Beispiel. Sie betreiben n8n selbst gehostet auf einem Server in Frankfurt. Sauber, könnte man meinen, alles in Deutschland. Jetzt baut Ihr Workflow einen Schritt ein, der einen Text von der OpenAI-API zusammenfassen lässt. Der n8n-Server steht in Frankfurt, die Ausführung der Logik passiert in Frankfurt, aber der zu verarbeitende Text wird in dem Moment an OpenAI in die USA geschickt. Der Standort Ihrer Engine ist irrelevant für die Daten, die durch sie hindurchfließen. n8n ist hier nur das Förderband, nicht das Lager.

Dieselbe Logik gilt umgekehrt. Sie können ein US-Tool wie Zapier nutzen und trotzdem dafür sorgen, dass bestimmte Daten den EU-Raum nie verlassen, wenn Sie die Module bewusst auswählen. Das Tool-Logo auf der Rechnung sagt Ihnen nichts. Der Weg der einzelnen Felder sagt Ihnen alles.

Die Kette hinter der Kette: Sub-Auftragsverarbeiter

Jeder Anbieter, mit dem Sie einen Auftragsverarbeitungsvertrag schließen, hat selbst wieder Dienstleister. Make nutzt Cloud-Infrastruktur. Ihr CRM nutzt einen E-Mail-Versanddienst. Der E-Mail-Versanddienst nutzt vielleicht ein US-Rechenzentrum für die Zustellbarkeitsprüfung. Diese Kette nennt sich Sub-Auftragsverarbeitung, und sie ist der Teil, den fast niemand liest.

Jeder seriöse Anbieter führt seine Sub-Auftragsverarbeiter in einer Liste auf, meist auf einer Unterseite mit Titeln wie "Subprocessors" oder "Unterauftragsverarbeiter". Diese Liste ist langweilig zu lesen und enthält genau die Information, die im Ernstfall zählt. Ich habe schon Listen gesehen, in denen ein angeblich rein europäischer Newsletter-Dienst einen US-amerikanischen Analytics-Anbieter als Sub-Verarbeiter führte, durch den jede geöffnete E-Mail-Adresse lief. Niemand im Unternehmen wusste das, weil niemand die Liste je geöffnet hatte.

Die Kette hinter der Kette ist kein juristisches Detail für Spezialisten. Sie entscheidet, ob Ihre Aussage "die Daten bleiben in Europa" stimmt oder eine Hoffnung ist.

Drei Stellen, an denen Daten unbemerkt das Land wechseln

Theorie hilft hier wenig. Schauen wir uns drei reale Konstellationen an, die ich so oder so ähnlich mehrfach gesehen habe. Unterschiedliche Größen, dasselbe Muster: Der Datenfluss tut etwas, das niemand beabsichtigt hat.

Szenario 1: Die harmlose E-Mail-Automatisierung einer Solo-Beraterin

Eine selbstständige Beraterin, ein Mensch, kein Team, automatisiert ihre Lead-Bearbeitung. Kontaktformular auf der Website, die Anfrage geht per Zapier in ein Google Sheet, von dort eine personalisierte Antwort über ein KI-Tool, das den Entwurf formuliert. Klingt nach dem unschuldigsten Setup der Welt.

Der Datenfluss sieht anders aus. Das Formular läuft über einen US-Formularanbieter. Zapier ist ein US-Unternehmen. Google Sheets liegt je nach Konto-Konfiguration in einem US-Rechenzentrum. Das KI-Tool schickt den Namen und das Anliegen der anfragenden Person an ein Sprachmodell in den USA. Eine einzige Kontaktanfrage, vier Übergaben, jede davon mit einem Transfer in die USA. Die Beraterin war überzeugt, "nur ein bisschen Automatisierung" zu betreiben. Tatsächlich hatte sie eine Drittland-Übermittlungskette gebaut, ohne es zu merken.

Das ist nicht automatisch illegal, dazu gleich mehr. Aber sie konnte auf die simple Frage, wo die Daten ihrer Interessenten liegen, keine Antwort geben. Und eine Antwort schuldet sie laut Datenschutzerklärung jedem, der fragt.

Szenario 2: Der Anreicherungs-Schritt beim 120-Personen-Betrieb

Ein mittelständischer Dienstleister, rund 120 Mitarbeiter, hat einen sauberen Stack. CRM aus Deutschland, Automatisierung über ein EU-gehostetes Tool, alles vertraglich abgedeckt. Der Datenschutzbeauftragte hatte gute Arbeit geleistet. Bis jemand im Vertrieb einen praktischen Schritt einbaute: Wenn ein neuer Lead reinkommt, wird die Firma automatisch "angereichert", also mit Branchendaten, Mitarbeiterzahl und Umsatz ergänzt. Dafür schickt der Workflow den Firmennamen und die E-Mail-Adresse der Kontaktperson an einen Anreicherungsdienst.

Dieser Dienst sitzt in den USA. Er bekommt bei jedem neuen Lead eine echte E-Mail-Adresse, also ein personenbezogenes Datum. Der Vertriebsmitarbeiter hat das nicht aus Böswilligkeit gebaut, sondern weil es den Job leichter machte. Der Datenschutzbeauftragte wusste nichts davon, weil dieser eine Schritt nach seiner Prüfung dazukam. Genau hier liegt das strukturelle Problem: Automatisierungen werden nicht einmal gebaut und dann eingefroren. Sie wachsen. Und jeder neue Baustein kann den Datenfluss verändern, ohne dass jemand die ursprüngliche Bewertung anfasst.

Bei diesem Kunden haben wir den Anreicherungs-Schritt nicht gestrichen, sondern umgebaut. Statt der personenbezogenen E-Mail-Adresse geht jetzt nur noch die Firmendomain an den Dienst, also der Teil nach dem @-Zeichen. Damit verschwindet der Personenbezug an dieser Stelle, der Nutzen bleibt fast vollständig erhalten. Solche Lösungen findet man nur, wenn man den Fluss Feld für Feld kennt.

Szenario 3: Der Konzern und das eine Logging-Tool

Bei größeren Organisationen ist es selten ein fachlicher Schritt, der das Problem verursacht, sondern die Infrastruktur darunter. Ein Konzern mit mehreren Tausend Mitarbeitern hatte seine Kern-Automatisierung vorbildlich europäisch aufgesetzt. Das Problem saß im Monitoring. Jede Workflow-Ausführung, inklusive der verarbeiteten Datensätze, wurde zu Debugging-Zwecken an ein zentrales Logging-Tool geschickt. Dieses Tool lief in einer US-Cloud-Region, weil es vor Jahren die IT-Abteilung so eingerichtet hatte, lange bevor jemand an Automatisierung dachte.

Das Ergebnis: Die eigentlichen Daten blieben in Europa, aber jeder Fehlerfall und jedes Debug-Log mit den vollen Datensätzen landete in einem US-Rechenzentrum. Logs sind der am häufigsten übersehene Datenfluss überhaupt, weil sie als technisches Beiwerk gelten und nicht als Verarbeitung. Sie sind aber Verarbeitung, wenn personenbezogene Daten drinstehen. Und in Klartext-Logs steht erstaunlich oft alles drin.

Drei Größen, drei Stellen, ein gemeinsamer Nenner: Niemand hatte den vollständigen Weg je aufgezeichnet. Das Risiko entsteht nicht durch böse Absicht, sondern durch fehlende Sicht.

Der Einwand, der immer kommt: "Das sind doch nur Geschäftsdaten"

An dieser Stelle hebt in fast jedem Workshop jemand die Hand: Wir verarbeiten doch keine sensiblen Personendaten, das sind Geschäftskontakte, Firmen-E-Mails, B2B. Der Einwand klingt vernünftig und ist trotzdem falsch. Eine Adresse wie max.mustermann@firma.de ist ein personenbezogenes Datum, auch wenn sie rein geschäftlich genutzt wird. Sie identifiziert eine konkrete Person. Die DSGVO unterscheidet nicht zwischen privat und beruflich, sobald ein Mensch identifizierbar ist, greift sie.

Das gilt erst recht für die Felder, die in B2B-Automatisierungen ständig mitlaufen: Name der Ansprechperson, Durchwahl, Position, Notizen aus dem Vertriebsgespräch. Eine Notiz wie "Herr Müller war am Telefon ungehalten" ist ein personenbezogenes Datum mit Bewertungscharakter. Wenn die durch einen US-Dienst läuft, ist das kein Bagatellfall, nur weil es ums Geschäft geht.

Ich sage das nicht, um Panik zu verbreiten, sondern weil dieser Irrtum dazu führt, dass ganze Datenflüsse gar nicht erst geprüft werden. "Ist ja nur B2B" ist der Satz, hinter dem sich die meisten unbemerkten Drittlandtransfers verstecken. Wer ihn streicht, schaut genauer hin, und genau das ist der Zweck der Übung.

Die Tabelle, die ich in jedem Projekt aufmale

Wenn ich einen Stack durchleuchte, entsteht am Ende immer dieselbe Tabelle. Sie ist unspektakulär und genau deshalb so nützlich. Eine Zeile pro Verarbeitungsschritt, und sie zwingt dazu, jede der vier Fragen zu beantworten. Hier ein gekürztes Beispiel aus einem realen Lead-Prozess:

Sobald diese Tabelle auf dem Tisch liegt, verändert sich das Gespräch. Aus "wir sind eigentlich konform" wird "an Zeile drei, vier und sechs müssen wir ran". Das ist kein angenehmer Moment für den Kunden, aber es ist der erste ehrliche. Die Tabelle macht das Unsichtbare sichtbar, und nur Sichtbares lässt sich entscheiden.

Wichtig an der Tabelle ist die letzte Spalte. "Drittland: ja" ist kein Urteil, sondern eine Markierung. Ob ein Drittlandtransfer zulässig ist, hängt von der Rechtsgrundlage ab, und damit sind wir bei der Frage, die mir am häufigsten gestellt wird.

Ist eine US-Cloud nach Schrems II automatisch verboten?

Nein. Diese Frage bekomme ich in fast jedem Projekt, und die kurze Antwort lautet: Ein Transfer in die USA ist nicht pauschal verboten, er braucht aber eine tragfähige Rechtsgrundlage. Seit dem EU-US Data Privacy Framework von 2023 gibt es wieder einen Angemessenheitsbeschluss für US-Unternehmen, die sich unter diesem Rahmen zertifiziert haben. Schickt Ihr Workflow Daten an einen Anbieter, der auf der DPF-Liste steht, ist der Transfer auf dieser Basis grundsätzlich abgedeckt.

Die Betonung liegt auf "zertifiziert". Nicht jedes US-Unternehmen ist unter dem DPF gelistet, und die Zertifizierung kann widerrufen werden. Außerdem ist der Beschluss politisch angreifbar, ein "Schrems III" gilt unter Datenschützern als realistische Möglichkeit. Wer seinen kompletten Datenfluss heute auf den DPF-Status eines einzelnen Anbieters stützt, baut auf einem Fundament, das wackeln kann.

Mein pragmatischer Rat: Prüfen Sie für jeden US-Dienst in Ihrer Tabelle, ob er DPF-zertifiziert ist, die Liste ist öffentlich einsehbar. Wo möglich, reduzieren Sie zusätzlich die Menge der personenbezogenen Daten, die diesen Weg überhaupt nehmen, so wie im zweiten Szenario mit der Domain statt der vollen Adresse. Datensparsamkeit am Übergabepunkt ist die robusteste Absicherung, weil sie unabhängig von der nächsten politischen Entscheidung funktioniert.

Damit ist die juristische Lage skizziert. Doch selbst wer die Rechtsgrundlagen kennt, hat oft ein zweites Problem: Die offiziellen Datenschutzunterlagen beschreiben längst nicht mehr, was der Workflow im Betrieb anstellt.

Das Verzeichnis sagt etwas anderes als der Workflow

Jedes Unternehmen, das personenbezogene Daten verarbeitet, muss ein Verzeichnis von Verarbeitungstätigkeiten führen, kurz VVT. Darin steht, welche Daten zu welchem Zweck verarbeitet werden, mit welchen Dienstleistern und wohin sie fließen. In der Theorie ist das genau die Tabelle, über die wir hier reden. In der Praxis stammt das VVT oft aus dem Jahr, in dem die Firma es einmal angelegt hat, und seitdem hat sich der Stack drei Mal verändert.

Genau hier entsteht die gefährlichste Form von Schein-Compliance. Auf dem Papier ist alles dokumentiert und sauber. Im laufenden Betrieb macht die Automatisierung etwas, das im Papier nicht vorkommt. Der Anreicherungs-Schritt aus dem zweiten Szenario stand in keinem Verzeichnis, weil er Monate nach der letzten Aktualisierung dazukam. Das Dokument war nicht falsch, es war veraltet, und veraltet ist im Datenschutz fast dasselbe wie falsch.

Mein Rat: Behandeln Sie das VVT nicht als Pflichtübung für den Aktenordner, sondern als lebendes Abbild Ihrer Datenflüsse. Jede neue Automatisierung, jeder neue Anreicherungs- oder Logging-Schritt gehört hinein, bevor er produktiv geht, nicht ein Jahr später bei der nächsten Prüfung. Das klingt nach Bürokratie, ist aber Selbstschutz. Das Verzeichnis ist die einzige Stelle, an der Ihr Wissen über den Datenfluss überlebt, wenn die Person geht, die den Workflow gebaut hat. Deshalb beginnt jede ehrliche Bestandsaufnahme nicht im Aktenordner, sondern im Workflow selbst.

So mappen Sie Ihren eigenen Datenfluss in unter zwei Stunden

Sie brauchen dafür keinen Datenschutzbeauftragten und kein teures Tool. Sie brauchen ein leeres Dokument, Zugriff auf Ihre Automatisierung und die Disziplin, jeden Schritt einzeln anzuschauen. So gehe ich vor.

Schritt 1: Einen echten Datensatz als Leitfaden nehmen

Nehmen Sie sich nicht "den Prozess" abstrakt vor, sondern einen konkreten, echten Vorgang. Die letzte Bewerbung, die letzte Bestellung, die letzte Supportanfrage. Reale Daten zwingen Sie, jeden Schritt ehrlich nachzuvollziehen, statt das Idealbild aus der Doku abzuschreiben.

Schritt 2: Jeden Schritt aufmachen und die Felder notieren

Gehen Sie Ihren Workflow Modul für Modul durch und schreiben Sie für jeden Schritt auf, welche personenbezogenen Felder ihn passieren. Nicht "Kundendaten", sondern konkret: Name, E-Mail, Telefonnummer, Freitext. Der Detailgrad entscheidet über den Wert der Übung. Pauschale Kategorien verstecken genau die Felder, die später zum Problem werden.

Schritt 3: Pro Anbieter den Speicherort und die Sub-Liste prüfen

Für jeden Anbieter, der auftaucht, klären Sie zwei Dinge: In welcher Region liegen die Daten laut Vertrag, und wen führt er als Sub-Auftragsverarbeiter? Die Region steht meist in den AVV oder den Sicherheitsdokumenten. Die Sub-Liste finden Sie über eine Suche nach dem Anbieternamen plus "subprocessors". Diese halbe Stunde Lektüre ist unbeliebt und unverzichtbar.

Schritt 4: Die Drittland-Spalte ausfüllen und markieren

Tragen Sie für jeden Schritt ein, ob Daten den EU-Raum verlassen. Bei "ja" notieren Sie die Rechtsgrundlage, also DPF-Zertifizierung, Standardvertragsklauseln oder Einwilligung. Wo Sie keine Rechtsgrundlage benennen können, haben Sie eine Lücke gefunden, und das Finden ist der ganze Zweck.

Schritt 5: Die Logs nicht vergessen

Zum Schluss die Frage, die fast immer untergeht: Wohin gehen Ihre Logs, Fehlerbenachrichtigungen und Monitoring-Daten? Schauen Sie in die Benachrichtigungs- und Logging-Einstellungen Ihres Tools. Häufig steht dort der überraschendste Eintrag der ganzen Tabelle.

Nach diesen fünf Schritten halten Sie etwas in der Hand, das die meisten Unternehmen schlicht nicht haben: eine wahrheitsgemäße Karte ihres eigenen Datenflusses. Ob daraus Handlungsbedarf folgt, entscheidet sich danach. Aber jetzt entscheiden Sie es auf Basis von Fakten statt von Annahmen.

Was ich daraus gelernt habe

Nach Dutzenden solcher Durchleuchtungen ist mir eines klar geworden: Das Datenschutzrisiko in der Automatisierung sitzt fast nie in einem bewussten Verstoß. Niemand baut absichtlich eine illegale Übermittlungskette. Das Risiko sitzt in der Lücke zwischen dem, was eine Firma über ihren Prozess glaubt, und dem, was der Prozess im Betrieb tut. Diese Lücke wird mit jeder neuen Automatisierung größer, weil Workflows wachsen und niemand die alte Bewertung anfasst.

Der zweite Punkt: Datenschutz in der Automatisierung ist kein Vertragsthema, sondern ein Architekturthema. Die wirksamsten Verbesserungen, die ich gesehen habe, waren keine neuen AVV, sondern kleine Eingriffe in den Datenfluss. Eine Domain statt einer Adresse. Ein Logging-Ziel in der EU. Ein Anreicherungs-Schritt, der nur noch nicht-personenbezogene Felder verarbeitet. Solche Änderungen kosten eine Stunde Arbeit und lösen Probleme, die ein Anwalt Ihnen nur teuer bestätigen könnte.

Und der dritte, fast banale Punkt: Die Firma, die ihren Datenfluss kennt, schläft besser. Nicht weil sie keine Drittlandtransfers hätte, die hat fast jeder, sondern weil sie auf jede Frage eine Antwort geben kann. Wenn die Aufsichtsbehörde anklopft, wenn ein Interessent nach Auskunft fragt, wenn ein Kunde wissen will, wo seine Daten liegen, dann ist die Tabelle der Unterschied zwischen souveräner Antwort und betretenem Schweigen. Den Geschäftsführer des Maschinenbauers vom Anfang habe ich übrigens wieder getroffen. Seine erste Automatisierung läuft heute fast unverändert. Geändert hat sich, dass er jetzt weiß, wo die Daten liegen. Und das war die ganze Arbeit wert.