KI-Agents arbeiten anders als ein einzelner Chat-Prompt — sie rufen eigenständig Tools auf, verketten API-Calls und treffen Entscheidungen über mehrere Schritte. Genau das macht die DSGVO-Frage komplexer: Daten fließen nicht nur einmal zum Anbieter, sondern durch eine Kette von Diensten. Was du konkret beachten musst, wenn du autonome Workflows mit personenbezogenen Daten einsetzt.
TL;DR
- Was DSGVO bei KI-Agents konkret bedeutet (Personenbezug, DPA, EU-Endpunkt)
- Datenflüsse bei Agent-Tool-Calls — wo landen deine Daten wirklich?
- Logging und Nachvollziehbarkeit als Pflicht
- Auftragsverarbeitung bei Agent-APIs — ein DPA reicht nicht immer
- Status-Übersicht der großen Cloud-Tools
- Lokale Modelle und Anonymisierung als Alternativen
- Entscheidungs-Matrix pro Use-Case
Was DSGVO bei KI-Agents konkret heißt
Die DSGVO regelt, wie personenbezogene Daten verarbeitet werden dürfen. “Personenbezogen” heißt: Daten, die einer identifizierbaren natürlichen Person zugeordnet werden können — direkt (Name, E-Mail) oder indirekt (Gehaltsangabe plus Position plus Stadt = identifizierbar).
Bei einem einzelnen Chat-Prompt ist die Sache übersichtlich: du gibst Daten ein, der Anbieter verarbeitet sie, fertig. Bei einem KI-Agent wird es komplexer, weil der Agent eigenständig entscheidet, welche Tools er aufruft und welche Daten er weitergibt. Ein n8n-Workflow, der Kundendaten aus einem CRM zieht, durch Claude analysieren lässt und das Ergebnis per E-Mail verschickt, hat drei verschiedene Datenverarbeitungsschritte — jeder mit eigenen DSGVO-Anforderungen.
Grundsätzlich brauchst du für jede Verarbeitung personenbezogener Daten:
- Eine Rechtsgrundlage für die Verarbeitung (z.B. Vertragsdurchführung, berechtigtes Interesse, Einwilligung)
- Einen Auftragsverarbeitungsvertrag (DPA) mit dem Anbieter
- Technische und organisatorische Maßnahmen zur Sicherheit
- Information der Betroffenen, dass und wie ihre Daten verarbeitet werden
Punkt 2 ist bei Agents besonders kritisch: nicht ein DPA, sondern potenziell eines pro externem Dienst in der Kette.
Datenflüsse bei Agent-Tool-Calls
Ein klassischer KI-Agent in n8n oder einem vergleichbaren Workflow-Tool funktioniert so: der Agent bekommt eine Aufgabe, entscheidet sich für einen Tool-Call (z.B. “Kundendaten abrufen”), bekommt das Ergebnis zurück, entscheidet sich für den nächsten Schritt (z.B. “Zusammenfassung erstellen”), und so weiter. Jeder dieser Schritte ist ein eigener Datenfluss.
Warum das DSGVO-relevant ist:
- Daten verlassen deinen Kontext mehrfach. Bei einem einfachen Prompt geht ein Request raus und eine Antwort kommt zurück. Bei einem Agent-Workflow können Daten durch 5-10 verschiedene API-Calls fließen — zum LLM, zur Datenbank, zum E-Mail-Dienst, zum CRM, zurück zum LLM.
- Der Agent entscheidet selbst, welche Daten er weitergibt. Du kontrollierst nicht Zeile für Zeile, was an welchen Dienst geht. Der Agent könnte entscheiden, den vollen Kundennamen in einen API-Call zu packen, den du nur für anonymisierte Daten vorgesehen hast.
- Zwischenergebnisse werden gespeichert. Viele Agent-Frameworks halten den Kontext über mehrere Schritte hinweg — das bedeutet, personenbezogene Daten aus Schritt 1 sind möglicherweise noch im Kontext, wenn Schritt 5 einen ganz anderen Dienst aufruft.
Praktische Konsequenz: Bevor du einen Agent-Workflow mit personenbezogenen Daten einrichtest, zeichne den Datenfluss auf. Welche externen Dienste werden aufgerufen? Welche Daten gehen wohin? Wo werden Zwischenergebnisse gespeichert? Das ist dein Verarbeitungsverzeichnis nach Art. 30 DSGVO.
Logging und Nachvollziehbarkeit
KI-Agents erzeugen deutlich mehr Logs als ein einzelner Chat. Jeder Tool-Call, jede Entscheidung, jeder Zwischenschritt wird typischerweise protokolliert. Das ist einerseits gut — Nachvollziehbarkeit ist eine DSGVO-Anforderung. Andererseits entstehen dabei neue Datenschutz-Risiken.
Was du sicherstellen musst:
- Logs enthalten personenbezogene Daten. Wenn der Agent einen Kundennamen verarbeitet, taucht dieser Name in den Workflow-Logs auf. Diese Logs sind selbst personenbezogene Daten und unterliegen der DSGVO.
- Aufbewahrungsfristen definieren. Logs dürfen nicht unbegrenzt gespeichert werden. Definiere, wie lange Agent-Logs aufbewahrt werden, und lösche sie danach automatisch.
- Zugriff auf Logs beschränken. Nicht jeder im Team braucht Zugriff auf die vollständigen Agent-Logs. Rollenbasierter Zugriff ist Pflicht.
- Nachvollziehbarkeit gewährleisten. Du musst im Nachhinein erklären können, warum der Agent welche Daten wohin geschickt hat. Bei einem autonomen Workflow ist das schwieriger als bei einem manuellen Prompt — deshalb sind strukturierte Logs wichtiger, nicht weniger wichtig.
Tipp für n8n-Nutzer: n8n speichert Execution-Logs mit allen Zwischenergebnissen. Wenn du personenbezogene Daten verarbeitest, konfiguriere die Log-Retention in den n8n-Settings und prüfe, ob die Execution-Daten auf deinem eigenen Server bleiben (Self-Host) oder in der Cloud landen.
Auftragsverarbeitung bei Agent-APIs
Bei einem einfachen Claude-Prompt hast du eine Auftragsverarbeitung: du und Anthropic. Bei einem Agent-Workflow hast du potenziell eine Kette von Auftragsverarbeitungen.
Beispiel: Dein n8n-Agent nutzt Claude API (Anthropic), liest Daten aus Airtable, und verschickt E-Mails über Resend. Das sind drei externe Dienste — du brauchst mit jedem ein DPA, sofern personenbezogene Daten fließen.
Worauf du achten musst:
- Sub-Auftragsverarbeiter prüfen. Dein DPA mit Anthropic reicht nicht, wenn der Agent auch Daten an Drittdienste weiterleitet. Jeder Dienst in der Kette braucht sein eigenes DPA.
- Unterauftragsverarbeiter-Listen prüfen. Große Anbieter haben eigene Sub-Prozessoren. Anthropic nutzt z.B. AWS als Infrastruktur — das steht im DPA-Anhang. Prüfe diese Listen für jeden Dienst in deinem Agent-Workflow.
- API-Keys sind keine DPAs. Ein API-Key bei einem Dienst zu haben bedeutet nicht, dass du einen Auftragsverarbeitungsvertrag hast. Das DPA muss separat abgeschlossen werden.
Sonderfall Self-Hosted Agents: Wenn du n8n auf deinem eigenen Server betreibst und der Agent nur lokale Modelle (Ollama) nutzt, hast du keine externe Auftragsverarbeitung — du bist selbst der Verantwortliche. Sobald aber ein einziger Tool-Call an eine externe API geht (z.B. Claude für eine Zusammenfassung), brauchst du für diesen Dienst ein DPA.
Status der großen Cloud-Tools
Claude (Anthropic)
Privatkonto Claude Pro: kein DPA, keine echte EU-Garantie. Geeignet für nicht-personenbezogene Aufgaben (Brainstorming, Recherche zu öffentlichen Themen, Code-Snippets). Nicht für Mandantendaten oder Agent-Workflows mit Personenbezug.
Claude API mit DPA: Anthropic bietet einen Auftragsverarbeitungsvertrag plus EU-Endpunkt. Das ist DSGVO-tauglich, sofern du den Vertrag tatsächlich abschließt und die EU-Region konfigurierst. Für Agent-Workflows die sauberste Cloud-Option.
Claude Team / Enterprise: Auftragsverarbeitungsvertrag im Team-Tarif inkludiert. Saubere Lösung für KMU mit 5-50 Mitarbeitenden.
ChatGPT (OpenAI)
Privatkonto ChatGPT Plus: kein DPA. Standardmäßig werden deine Eingaben für Training verwendet, das kannst du opt-outen. Nicht DSGVO-konform für personenbezogene Berufsdaten.
ChatGPT Enterprise: explizit als DSGVO-konforme Variante positioniert, mit DPA, kein Training auf Eingaben. Saubere Lösung, aber teuer.
OpenAI API mit DPA: ähnlich wie Anthropic — API-Zugang mit Enterprise-Vertrag, opt-out vom Training. Für Agent-Workflows über Assistants API relevant.
Gemini (Google)
Privatkonto Gemini Advanced: Privacy-Standard von Google, was für personenbezogene Daten heikel ist. Nicht für Berufsdaten.
Google Workspace Enterprise mit Gemini: über das Data Processing Addendum als Teil von Workspace nutzbar. Für KMU, die ohnehin in Google Workspace leben, der pragmatischste Weg.
Lokale Modelle als saubere Alternative
Wenn das KI-Modell auf deinem eigenen Server läuft, verlassen die Daten deinen Server nie. DSGVO ist dann grundsätzlich kein Compliance-Problem mehr, weil keine Auftragsverarbeitung an Dritte stattfindet — du bist selbst der Verantwortliche.
Für Agent-Workflows ist das besonders interessant: ein lokales Modell als “Gehirn” des Agents eliminiert den größten Datenfluss (Prompts und Antworten zum LLM-Anbieter). Tool-Calls an externe Dienste musst du trotzdem einzeln bewerten.
Praktische Optionen:
- Ollama: einfaches Setup für Mistral, Llama, Gemma als lokale LLMs. Geeignet für Belegerfassung, Standard-Kommunikation, einfache Klassifikation.
- llama.cpp: Low-Level-Performance-Setup für leistungs-kritische Anwendungen
- LM Studio: GUI-Variante für nicht-technische User
- ComfyUI: für Bild-Generierung lokal — siehe ComfyUI auf AMD RX 7900 XTX
Wichtig: “Lokal” ist eine technische Lösung, keine vollständige Compliance. Du musst trotzdem deine eigenen Maßnahmen treffen — Backups verschlüsseln, Zugriffsrechte kontrollieren, Audit-Logs führen, alles dokumentieren.
Anonymisierung als Pragmatik-Lösung
Für viele Aufgaben reicht eine Anonymisierung vor dem Prompt, sodass die KI nie personenbezogene Daten sieht. Bei Agent-Workflows ist das allerdings schwieriger umzusetzen, weil der Agent selbst entscheidet, welche Daten er in den nächsten Schritt mitnimmt.
Praktischer Ansatz für Agents: Anonymisiere die Daten am Eingang des Workflows — bevor der Agent sie sieht. Wenn der Agent Daten aus einer Datenbank zieht, baue einen Anonymisierungs-Schritt zwischen Datenbank-Abfrage und Agent-Input ein.
Beispiel Marketing-Reporting: Statt “wie hat Klient Müller im Q3 performed” frage “wie hat Klient X im Q3 performed”. Die Daten sind nach Anonymisierung nicht mehr personenbezogen, jede Cloud-KI ist wieder okay.
Wichtig: Pseudonymisierung (Initialen, IDs) reicht nicht — die Daten bleiben personenbezogen. Echte Anonymisierung verlangt, dass keine Re-Identifizierung möglich ist. Bei einzelnen Personen-Datensätzen ist das oft nicht praktikabel — dann brauchst du DPA-Cloud oder lokales Modell.
Entscheidungs-Matrix nach Use-Case
| Use-Case | Empfehlung |
|---|---|
| Brainstorming, allgemeine Recherche, öffentliche Themen | Standard-Privatkonto reicht (Claude Pro, ChatGPT Plus) |
| Marketing-Texte ohne Mandantenbezug | Standard-Privatkonto |
| Berufliche Aufgaben mit anonymisierten Daten | Standard-Privatkonto (nach Anonymisierung) |
| Agent-Workflow ohne Personenbezug (z.B. Content-Pipeline) | Standard-API, DPA empfohlen |
| Agent-Workflow mit Kundendaten (CRM, E-Mail) | API mit DPA + DPA pro externem Dienst |
| Mandanten-Texte (Anwälte, Steuerberater, Coaches) | Lokales Modell ODER API mit DPA |
| Bewerbungs-Sichtung HR | Lokales Modell (Bewerber-Daten besonders sensibel) |
| Mitarbeiter-Daten (Reporting, Performance) | API mit DPA, EU-Endpunkt |
| Patientendaten (Ärzte, Therapeuten) | Lokales Modell, Air-Gap empfohlen |
| Autonomer Agent mit Multi-Tool-Zugriff | Self-Hosted Agent + lokales LLM, externe Calls nur mit DPA |
Häufige Fallstricke
“Wir haben ja eine SaaS-Lizenz” reicht nicht. Eine Lizenz ist kein DPA. Du brauchst zusätzlich den Auftragsverarbeitungsvertrag. Bei vielen SaaS-Anbietern gibt es das DPA in den AGB-Anhängen — oft musst du es aktiv abschließen, nicht nur akzeptieren.
“Die Daten waren nur kurz im Tool” reicht nicht. DSGVO greift bei jeder Verarbeitung, auch bei sekundenlanger. Ein einziger Prompt mit personenbezogenen Daten ohne DPA ist formal ein Verstoß.
“Der Agent hat das selbst entschieden” reicht nicht. Du bist als Betreiber des Agents verantwortlich für die Datenverarbeitung — nicht der Agent. Wenn der Agent eigenständig personenbezogene Daten an einen Dienst ohne DPA weiterleitet, ist das dein Verstoß.
“Das Tool ist amerikanisch und sicher” reicht nicht. Die Tatsache, dass ein Tool eine SOC-2-Zertifizierung hat, sagt nichts über DSGVO-Konformität. Es geht um spezifische EU-Regeln (u.a. Datenübermittlung in Drittländer), die mit US-Sicherheitsstandards orthogonal sind.
“Wir nutzen es nur intern” reicht nicht. Auch interne Verarbeitung von Mitarbeiterdaten ist personenbezogene Datenverarbeitung. Mitarbeiter sind dann die Betroffenen, deren Rechte gewahrt werden müssen.
Was du jetzt tun kannst
Drei Schritte, in dieser Reihenfolge:
1. Datenfluss-Inventar: Zeichne für jeden Agent-Workflow auf, welche Daten wohin fließen. Welche externen Dienste werden aufgerufen? Welche davon haben ein DPA in Kraft? Wo fließen personenbezogene Daten?
2. Lücken-Analyse: Wo fehlt dir das DPA? Wo loggt der Agent personenbezogene Daten ohne Aufbewahrungsfrist? Wo entscheidet der Agent autonom über Datenweiterleitung, die du nicht kontrollierst?
3. Entscheidung: Pro Lücke entscheiden — DPA abschließen, auf Enterprise umsteigen, lokal arbeiten, Anonymisierung einbauen, oder den Tool-Call aus dem Workflow entfernen. Eine Entscheidung pro Dienst in der Kette, nicht pauschal.
Bei Solo-Selbstständigen reicht meistens die Kombination “Anthropic Claude API mit DPA für berufliche Aufgaben” plus “Ollama lokal für sensible Inputs” plus “n8n Self-Hosted für Agent-Workflows”. Total-Aufwand: ein Nachmittag Setup, danach ist das Setup stabil.
Verwandte Themen
Meine Einschätzung
Ich bin kein Anwalt — aber ich arbeite jeden Tag mit KI-Agents, die Daten verarbeiten, und habe mein eigenes Setup DSGVO-konform aufgebaut. Was mich bei diesem Thema am meisten stört: die Angst vor DSGVO wird in DACH als Ausrede benutzt, um gar nichts zu machen. In meiner Praxis zeigt sich: wer einen Nachmittag in DPA-Abschlüsse und n8n-Self-Hosting investiert, hat 90 Prozent der Compliance-Fragen gelöst. Die verbleibenden 10 Prozent betreffen Sonderfälle, die tatsächlich einen Fachanwalt brauchen. Mein Rat: nicht von der Komplexität lähmen lassen, sondern mit der Entscheidungs-Matrix oben starten und pro Use-Case eine klare Entscheidung treffen.
Quellen
- DSGVO Art. 28 — Auftragsverarbeitung, offizieller Text
- DSGVO Art. 30 — Verzeichnis von Verarbeitungstätigkeiten
- BfDI Pressemeldungen 2024-2026 zu KI-Cloud-Diensten und Agent-Systemen
