DSGVO im Detail
Die Datenschutz-Grundverordnung gilt seit 2018, ist aber im Kontext autonomer KI-Agenten besonders sensibel: Der Agent kann eigenständig Daten verarbeiten, weiterleiten und neue Datensätze erzeugen. Damit das DSGVO-konform geschieht, sind sechs Bausteine zu adressieren — wir liefern in unseren Mandaten zu jedem dieser Bausteine ein dokumentiertes Mapping.
1. Rechtsgrundlage (Art. 6 DSGVO)
Klärung in Phase 1: Auf welcher Rechtsgrundlage verarbeitet der Agent personenbezogene Daten? Im B2B-Kontext typischerweise Art. 6 Abs. 1 lit. b (Vertragserfüllung), Art. 6 Abs. 1 lit. f (berechtigtes Interesse mit Interessenabwägung), oder bei sensitiven Kategorien Art. 9 mit eigenem Erlaubnistatbestand. Die Rechtsgrundlage steuert maßgeblich die zulässigen Datenflüsse.
2. Datenminimierung (Art. 5 Abs. 1 lit. c)
Der Agent soll nur die Daten erhalten, die für den definierten Zweck erforderlich sind. Konkret heißt das: PII-Pre-Processoren vor dem Reasoning-Schritt, Filterung sensibler Felder, ggf. Pseudonymisierung. Wir setzen Microsoft Presidio mit deutschen Erkennungsmustern ein — IBAN, Steuer-ID, deutsche Adressformate, Aktenzeichen, Personalnummern.
3. Auftragsverarbeitung (Art. 28)
LLM-Provider wie Anthropic, OpenAI, Google sind Auftragsverarbeiter, sobald personenbezogene Daten an ihre APIs gehen. Auftragsverarbeitungsverträge (DPAs) sind Pflicht. Bei Anthropic bekommen Sie einen DPA über das Privacy-Center, bei OpenAI über das Compliance-Portal. Wichtig: Der DPA verlangt die Aufnahme in Ihr Verzeichnis der Verarbeitungstätigkeiten.
4. Drittlandtransfer (Art. 44 ff.)
Anthropic, OpenAI, Google haben Server in den USA. Datentransfer dorthin braucht Standard-Vertragsklauseln (SCCs) plus zusätzliche technische Maßnahmen (Pseudonymisierung, Verschlüsselung). Wer das vermeiden will, setzt lokale Modelle ein — Hermes 4 von Nous Research, Llama 3.3 70B via Ollama, oder einen EU-gehosteten Inferenz-Provider (Mistral, Aleph Alpha mit europäischen Rechenzentren).
5. Betroffenenrechte (Art. 15–22)
Auskunft, Berichtigung, Löschung. Im Agenten-Kontext heißt das: Die persistente Konversations-Datenbank muss durchsuchbar und löschbar sein. Wir konfigurieren PostgreSQL mit User-ID-Indizierung, sodass DELETE FROM conversations WHERE user_id = … die einzige Operation ist, die zur DSGVO-Lösch-Aufforderung nötig wird. Bei Telegram/Slack ergänzen wir Lösch-Workflows, die auch die Plattform-seitigen Nachrichten entfernen.
6. Verzeichnis der Verarbeitungstätigkeiten (Art. 30)
Wir liefern in Phase 2 ein vorausgefülltes Verzeichnis-Eintrag-Template — Verantwortlicher, Zwecke, Datenkategorien, Empfänger, Löschfristen, technische Maßnahmen. Ihr Datenschutzbeauftragter prüft und nimmt es ins zentrale Verzeichnis auf.
EU AI Act
Seit 2024 stufenweise in Kraft, voll wirksam ab August 2026. Der AI Act klassifiziert KI-Anwendungen in vier Risikoklassen: unzulässig, hochrisikobehaftet, begrenzt-risikobehaftet, minimal-risikobehaftet.
Klassifizierung in unseren Mandaten
Die meisten unserer Use Cases (E-Mail-Triage, Concierge, Backoffice-Helpdesk, Service-Knowledge-Bot) fallen in die Klasse begrenztes Risiko. Pflichten: Transparenzpflicht („Sie sprechen mit einem KI-System“), klare Kennzeichnung, Möglichkeit zur Eskalation an einen Menschen.
Drei Use-Case-Klassen, die wir nicht ohne juristische Begleitung bedienen, weil sie als Hochrisiko eingestuft werden: Recruiting-Automation, Kreditentscheidungen / Bonitätsbewertung, Strafverfolgungs-Unterstützung. Diese erfordern Folgen-Abschätzung, externe Auditierung, Registrierung in der EU-Hochrisiko-Datenbank.
Transparenzpflichten in der Praxis
Wir setzen Transparenz konsistent um:
- Welcome-Message beim ersten Bot-Kontakt: „Sie schreiben mit einem KI-Assistenten. Mit ‚Mensch‘ erreichen Sie unser Team.“
- Chat-Header mit klarer Kennzeichnung als KI-System.
- Eskalationspfad dokumentiert und niedrigschwellig zugänglich.
- Datenschutzhinweis mit Link zur vollständigen Erklärung.
BSI IT-Grundschutz
Für Mandate aus der öffentlichen Hand und KRITIS-Bereichen modellieren wir nach IT-Grundschutz-Bausteinen. Die wichtigsten Bausteine im Agenten-Kontext:
- APP.6 Allgemeine Software — Standardanforderungen für die Komponenten Hermes Agent / OpenClaw.
- CON.10 Entwicklung von Webanwendungen — relevant für eigene Web-UI-Komponenten.
- OPS.1.2.5 Fernwartung — relevant für SSH-Sandbox-Backend und administrative Zugriffe.
- SYS.1.1 Allgemeiner Server — Hostinger-VPS oder Eigen-Hardware.
- SYS.1.5 Virtualisierung — Docker-Sandbox.
- NET.3.2 Firewall — ufw + Cloud-Firewall.
- DER.2.1 Behandlung von Sicherheitsvorfällen — Eskalationspfad bei Anomalien.
Auf Anfrage liefern wir ein Baustein-Mapping als Anhang zur Architektur-Dokumentation. Das Dokument hat in der Regel 12–18 Seiten und referenziert je Baustein die konkreten technischen und organisatorischen Maßnahmen.
Operative Sicherheitsmaßnahmen
Sandboxing per Default
Hermes mit Docker-Backend, jeder Tool-Aufruf in eigenem Container, Read-only-Mounts für sensitive Verzeichnisse, Drop-Privileges-Konfiguration, Networking auf das absolute Minimum reduziert.
Approval-Mode für externe Aktionen
Jede Aktion mit Außenwirkung — E-Mail-Versand, API-Call mit Schreibzugriff, CRM-Änderung — wird vor Ausführung explizit bestätigt. Der Approval-Mode lässt sich pro Tool aktivieren oder deaktivieren.
Whitelisting
Nur freigegebene User-IDs und Channels dürfen Befehle absetzen. In Slack: Channel-Whitelist. In Telegram: User-ID-Whitelist. In E-Mail: Absender-Domain-Whitelist plus DKIM/SPF-Prüfung.
Verschlüsselte Persistence
PostgreSQL mit TDE (Transparent Data Encryption), regelmäßige Tagessicherung mit AES-256-Verschlüsselung, Off-Site-Backup auf Hetzner Storage Box oder Backblaze B2 (mit eigener Verschlüsselung), 7-Tage-Retention für Logs (verlängerbar je nach gesetzlichem Rahmen).
Vier-Augen-Prinzip
Konfigurationsänderungen am produktiven Stack erfordern einen zweiten Gutachter. Git-Workflow mit Pull Requests, dokumentierte Review-Pflicht. Im Audit dokumentiert und nachvollziehbar.
Penetration-Test light
Vor Produktivgang testen wir die Standard-Angriffspfade: Prompt Injection mit präparierten Inputs, Tool-Misuse mit halluzinierten Befehlen, Authentication-Bypass an den Channel-Gateways, SQL-Injection in den Persistence-Layer (sollte durch ORM verhindert sein, wir prüfen es trotzdem).
Was wir nicht leisten
Wir sind weder Anwaltskanzlei noch Datenschutz-Beratungsfirma. Was wir leisten: technische und methodische Begleitung, Architektur-Dokumentation, vorbereitende Compliance-Mappings. Was Ihre Datenschutzbeauftragte und Ihre Rechtsabteilung leisten muss: rechtliche Bewertung, Folgen-Abschätzung bei Hochrisiko-Anwendungen, abschließende Genehmigung. Wir bringen die Welten zusammen und liefern die Dokumentationsgrundlage, auf der diese Bewertung gemacht werden kann.