Zero Data Retention klingt nach einer klaren Zusage: Eingaben und Ausgaben werden nicht dauerhaft gespeichert. Für vertrauliche B2B-Workflows reicht diese Aussage jedoch nicht aus. Entscheidend ist, welche Daten innerhalb eines konkreten Ablaufs verarbeitet werden, welche Systeme beteiligt sind und was in regulären sowie außergewöhnlichen Betriebszuständen geschieht.

Deshalb sollte ZDR nicht als einzelnes Häkchen im Provider-Vertrag, sondern als Abnahmefrage behandelt werden. Warum Zero Data Retention allein nicht genügt Ein KI-Workflow besteht selten nur aus einem Modellaufruf. Davor und danach können Formulare, Datenbanken, Automatisierungsplattformen, Protokolle, Monitoring-Dienste, Supportprozesse oder weitere APIs beteiligt sein.

Selbst wenn ein KI-Provider keine Inhalte dauerhaft speichert, können Daten an anderen Stellen des Workflows verbleiben. Eine belastbare Prüfung betrachtet daher die gesamte Verarbeitungskette statt nur eine isolierte Anbieterfunktion. Hinzu kommt, dass unterschiedliche Datenarten verschiedenen Regeln folgen können.

Inhalte, Metadaten, technische Logs und Safety-Signale sind nicht automatisch gleichbehandelt. Auch Ausnahmen bei Missbrauchsverdacht, Fehleranalysen oder Supportfällen können andere Zugriffs- und Speicherwege auslösen. Die zentrale Frage lautet deshalb: Wo verläuft die nachweisbare Daten- und Betriebsgrenze des konkreten Workflows?

Ein illustrativer B2B-Workflow Bei einer automatisierten Angebotsprüfung verarbeitet ein System beispielsweise Dokumente, Kontaktdaten, Preise, Leistungsbeschreibungen und interne Bewertungskriterien. Ein Modell kann Inhalte strukturieren oder Abweichungen markieren, während weitere Komponenten Dateien entgegennehmen, Ergebnisse speichern und Aufgaben an Mitarbeitende weiterleiten.

Für eine sichere Abnahme muss jede Station einschließlich möglicher Fallbacks dokumentiert sein. Dass der Modell-Endpoint ZDR unterstützt, beantwortet diese Gesamtfrage noch nicht. Ähnlich ist es bei einer Service-Triage. Kundenanfragen können zunächst klassifiziert, mit Kontodaten angereichert und anschließend an ein Ticketsystem oder ein Team übergeben werden.

Dabei entstehen neben dem Nachrichtentext möglicherweise Zeitstempel, Nutzerkennungen, Kategorien und Fehlermeldungen. Die Prüfung muss daher Anwendungsspeicher, menschliche Zugriffe und technisches Routing getrennt erfassen. Der Fünf-Punkte-Check für die Abnahme 1. Datenklasse und Zweck klären. Unternehmen sollten festhalten, ob der Workflow öffentliche, interne, vertrauliche oder besonders schützenswerte Informationen verarbeitet.

Ebenso wichtig ist der konkrete Zweck: Klassifikation, Zusammenfassung, Extraktion oder Entscheidungsunterstützung können unterschiedliche Datenumfänge erfordern. Eine klare Datenklassifizierung hilft, unnötige Eingaben zu vermeiden und passende Kontrollen festzulegen. 2. Speicherorte je Zustand erfassen.

Zu prüfen sind nicht nur der Modell-Endpoint, sondern auch Uploads, Zwischenspeicher, Datenbanken, Logs, Caches und verbundene Tools. Die Dokumentation sollte Normalbetrieb, Testbetrieb, Fehlerzustände und manuelle Wiederholungen unterscheiden. Erst diese Übersicht zeigt, ob die behauptete Datenminimierung im gesamten Ablauf gilt.

3. Sichtbarkeit von Inhalten und Signalen bestimmen. Rollen, Systeme und Dienstleister können Zugriff auf Inhalte, Metadaten oder Safety-Signale haben. Dabei ist zwischen automatisierter Verarbeitung, administrativer Einsicht, Supportzugriff und menschlicher Prüfung zu trennen. Eine allgemeine Aussage wie „Daten werden nicht für Training verwendet“ ersetzt diese Zugriffsklärung nicht.

4. Schlüssel, Rollen und Berechtigungen prüfen. API-Schlüssel sollten zweckgebunden, geschützt und regelmäßig kontrollierbar sein. Für Nutzer und technische Dienste braucht es nachvollziehbare Rollen, minimale Rechte und dokumentierte Verantwortlichkeiten. Relevant ist außerdem, wie Zugriffe entzogen, Vorfälle untersucht und Änderungen protokolliert werden.

5. Ausnahmen und Provider-Wechsel testen. Fehler, Safety-Flags, Einsprüche oder nicht erreichbare Dienste dürfen nicht zu einem unkontrollierten Datenfluss führen. Für Fallbacks muss feststehen, ob ein anderer Endpoint, ein anderes Modell oder eine manuelle Bearbeitung übernimmt. Auch beim Provider-Wechsel braucht das Unternehmen Klarheit darüber, welche Daten, Schlüssel, Protokolle und Integrationen angepasst oder gelöscht werden müssen.

Welche Nachweise zur Abnahme gehören Ein belastbares Artefakt kann je nach Workflow eine Datenflussübersicht, eine System- und Rollenmatrix, ein Löschkonzept oder ein dokumentierter Fehlertest sein. Ergänzend sind eine Liste der beteiligten Endpoints, definierte Aufbewahrungsregeln und ein Freigabeprotokoll sinnvoll.

Entscheidend ist nicht die Form des Dokuments, sondern seine Prüfbarkeit und Zuordnung zum tatsächlich eingesetzten System. Vertragsunterlagen des Providers sind wichtig, bilden aber nur einen Teil dieses Nachweises. Für Geschäftsführung und Fachverantwortliche schafft dieser Ansatz eine bessere Entscheidungsgrundlage.

Produkt- und Entwicklungsteams erhalten konkrete Abnahmekriterien, während Operations, Sales oder Marketing nachvollziehen können, welche Daten im Prozess zulässig sind. So wird KI-Datenschutz nicht auf eine technische Einzeloption reduziert. Er wird zu einer gemeinsamen Betriebsanforderung mit klaren Verantwortlichkeiten.

Pragmatischer Start für Unternehmen Der erste Schritt ist eine Bestandsaufnahme eines klar abgegrenzten Workflows. Teams sollten Ein- und Ausgaben, Systeme, Speicherorte, Rollen sowie Ausnahmewege gemeinsam erfassen und anschließend offene Punkte priorisieren. Danach lassen sich technische Einstellungen, Verträge und interne Prozesse gegen denselben Sollzustand prüfen.

Syda betrachtet solche Anforderungen im Zusammenhang mit KI-Automatisierung, Custom Software und digitalen Produkten, damit Architektur und Betrieb zusammenpassen. Zero Data Retention kann ein sinnvoller Baustein sein, ist aber kein vollständiger Sicherheitsnachweis. Abnahmefähig wird ein vertraulicher KI-Workflow erst, wenn Datenklassen, Speicherorte, Zugriffe, Berechtigungen und Ausnahmezustände nachvollziehbar dokumentiert sind.

Die entscheidende Frage ist daher nicht nur, ob ZDR aktiviert wurde. Sie lautet, ob die Daten- und Betriebsgrenze des gesamten Workflows belastbar nachgewiesen werden kann.