Sobald eine KI-Funktion Kundennamen, E-Mails, Support-Tickets oder Dokumente verarbeitet, ist die DSGVO im Spiel — und in der Schweiz zusätzlich das revDSG. Das Sprachmodell ist dabei kein rechtlicher Sonderfall, sondern ein weiterer Empfänger und ein weiterer Verarbeitungsschritt. Die Fragen sind die bekannten: Auf welcher Grundlage werden die Daten verarbeitet, wer erhält sie, wo werden sie gespeichert, wie lange, und können Betroffene ihre Rechte ausüben? Neu ist, dass diese Fragen bei KI-Funktionen leicht übersehen werden, weil die Verarbeitung im Code verborgen ist.
Die Rechtsgrundlage klären
Für die meisten Funktionen in einem B2B-SaaS ist der Anbieter Auftragsverarbeiter seines Kunden. Der Kunde entscheidet, welche Daten er ins Produkt lädt, und braucht dafür seine eigene Rechtsgrundlage. Der Anbieter muss sicherstellen, dass die KI-Verarbeitung vom Auftrag gedeckt ist: Eine Zusammenfassungsfunktion für Tickets ist etwas anderes als die Verwendung derselben Tickets, um eigene Modelle zu verbessern. Letzteres ist eine eigene Verarbeitung zu eigenen Zwecken und braucht eine eigene Grundlage — oft scheitert sie genau daran.
Im B2C-Bereich ist der Anbieter selbst Verantwortlicher. Hier stützt sich eine KI-Funktion, die der Nutzer aktiv aufruft, meist auf die Vertragserfüllung. Für Analysen im Hintergrund, Profilbildung oder die Weiterverwendung von Eingaben für Trainingszwecke reicht das in der Regel nicht.
Der Modellanbieter als Unterauftragsverarbeiter
Wer ein externes Sprachmodell über eine Schnittstelle nutzt, gibt Daten an einen Dienstleister weiter. Dieser ist Unterauftragsverarbeiter und muss in der Liste der Unterauftragsverarbeiter erscheinen, die Kunden im Auftragsverarbeitungsvertrag zugesagt wurde. Mit dem Modellanbieter selbst braucht es einen Auftragsverarbeitungsvertrag, der regelt, dass Eingaben nicht für das Training verwendet werden, wie lange sie gespeichert bleiben und wie Sicherheitsvorfälle gemeldet werden. Die grossen Anbieter bieten für ihre Geschäftsschnittstellen entsprechende Bedingungen an; sie sollten trotzdem gelesen und dokumentiert werden.
Wo die Daten verarbeitet werden
Liegt die Verarbeitung ausserhalb des EWR und der Schweiz, handelt es sich um eine Drittlandübermittlung. Für die USA ist zu prüfen, ob der Anbieter unter dem Data Privacy Framework zertifiziert ist; andernfalls braucht es Standardvertragsklauseln und eine Beurteilung des Zugriffsrisikos. Viele B2B-Kunden im DACH-Raum verlangen inzwischen ohnehin Verarbeitung in Europa. Mehrere Modellanbieter und Cloud-Plattformen bieten europäische Regionen an, mit teils anderem Modellangebot als die globale Schnittstelle. Diese Entscheidung sollte früh fallen, weil sie Architektur und Verträge prägt.
Datenminimierung im Prompt
Der wirksamste Schutz ist, Personendaten gar nicht erst an das Modell zu senden, wo sie nicht gebraucht werden. Für eine Kategorisierung von Support-Tickets braucht das Modell den Inhalt, aber selten Namen, E-Mail-Adressen oder Telefonnummern. Diese lassen sich vor dem Versand durch Platzhalter ersetzen und nach der Antwort wieder einsetzen. Auch Gesprächsverläufe und Suchergebnisse sollten auf das Nötige gekürzt werden — das senkt nebenbei die Kosten.
Besondere Vorsicht gilt bei besonders schützenswerten Daten: Gesundheitsangaben, religiöse Überzeugungen, biometrische Merkmale. Wenn eine KI-Funktion solche Daten verarbeiten kann, etwa weil Nutzer Freitext eingeben, gehört das in die Risikobeurteilung, auch wenn es nicht der beabsichtigte Zweck ist.
Protokolle sind auch Personendaten
Für Qualitätssicherung und Fehlersuche werden Prompts und Antworten oft protokolliert. Diese Protokolle enthalten dieselben Personendaten wie die ursprüngliche Anfrage und unterliegen denselben Regeln: Zweckbindung, begrenzte Aufbewahrung, Zugriffsbeschränkung. Sie sind auch Teil einer Auskunft, wenn eine betroffene Person wissen will, welche Daten über sie verarbeitet werden, und müssen bei einer Löschung berücksichtigt werden. Eine feste Aufbewahrungsfrist und eine Pseudonymisierung der Protokolle lösen die meisten Probleme.
Transparenz gegenüber Nutzern
Die Datenschutzerklärung muss die KI-Verarbeitung nennen: welche Daten, zu welchem Zweck, an welche Empfänger, in welche Länder. Seit dem 2. August 2026 gelten zudem die Transparenzpflichten des EU AI Act: Menschen müssen erkennen können, dass sie mit einem KI-System interagieren, sofern das nicht offensichtlich ist. Für Entscheidungen, die ausschliesslich automatisiert getroffen werden und erhebliche Auswirkungen auf Personen haben, setzt Artikel 22 DSGVO zusätzliche Grenzen. Die meisten SaaS-Funktionen unterstützen Menschen bei Entscheidungen und fallen nicht darunter — das sollte aber begründet festgehalten werden.
Wann eine Datenschutz-Folgenabschätzung nötig ist
Neue Technologien, umfangreiche Verarbeitung, Profilbildung oder besonders schützenswerte Daten sind typische Auslöser für eine Datenschutz-Folgenabschätzung. Eine KI-Funktion, die Bewerbungen bewertet, Gesundheitsangaben zusammenfasst oder das Verhalten von Mitarbeitenden auswertet, braucht sie fast sicher. Eine Funktion, die Texte umformuliert, die der Nutzer selbst eingibt, meist nicht. Die Abgrenzung sollte dokumentiert werden, denn genau danach fragen Kunden in Lieferantenprüfungen.
Eine Checkliste für den Start
- Ist die KI-Verarbeitung vom Auftrag bzw. vom Zweck gedeckt?
- Ist der Modellanbieter vertraglich gebunden und in der Unterauftragsverarbeiter-Liste?
- Wo werden Daten verarbeitet, und auf welcher Grundlage werden sie übermittelt?
- Werden Personendaten vor dem Versand minimiert?
- Haben Protokolle eine Aufbewahrungsfrist und sind sie in Auskunft und Löschung eingebunden?
- Nennt die Datenschutzerklärung die KI-Verarbeitung, und ist die KI-Interaktion erkennbar?
Wer diese Fragen sauber beantworten kann, hat für die meisten KI-Funktionen eine solide Grundlage. Innopulse setzt diese Anforderungen in eigenen Produkten um und unterstützt SaaS-Anbieter bei der technischen und organisatorischen Umsetzung; für rechtliche Einzelfallfragen empfehlen wir eine spezialisierte Kanzlei.

