Introduction

Die Einführung eines Empfangs‑Avatars (KI) auf einem Bildschirm oder Terminal im öffentlichen Raum wirft konkrete datenschutzrechtliche Fragen auf. Zwischen Sprachverwendung, der Aufbewahrung konversationeller Protokolle und möglichen Verbindungen zu Fachsystemen müssen Projektverantwortliche, Datenschutzbeauftragte und IT‑Sicherheitsverantwortliche vor Inbetriebnahme klare Regeln definieren.

Dieser Leitfaden bietet einen operativen und umsetzbaren Rahmen, um die DSGVO‑Konformität eines Projekts für einen Empfangs‑Avatar zu erarbeiten. Er kombiniert zu beachtende Grundsätze mit technischen und vertraglichen Patterns sowie konfigurierbaren Empfehlungen, die für eine professionelle Avatar‑Lösung auf Bildschirm oder Terminal anwendbar sind.

Warum frühzeitig über DSGVO nachdenken

Ein Projekt mit einem Empfangs‑Avatar ist nicht nur eine Frage von Ergonomie oder Performance. Je nach vorgesehenen Verarbeitungen (Spracherkennung, Protokollaufbewahrung, Anreicherung durch Fremdsysteme) kann das Risiko für die Rechte und Freiheiten betroffener Personen variieren. Daher empfiehlt es sich, die Verarbeitungen zu kartieren und sensible Datenflüsse bereits in der Konzeptionsphase zu identifizieren.

Anders ausgedrückt: Die DSGVO‑Konformität erst am Ende zu behandeln, macht die Anpassung meist teurer und komplexer. Präzise technische und organisatorische Entscheidungen vorab zu treffen erleichtert die Formulierung der Vertragsklauseln mit Lieferanten und beschränkt spätere Änderungen des Projektumfangs.

DSFA/DPIA und Projektgovernance: zu treffende Entscheidungen

Die Durchführung einer Datenschutz‑Folgenabschätzung (DSFA / DPIA) kann relevant sein, wenn das Projekt ein hohes Risiko für Betroffene birgt. Eine Organisation kann sich dafür entscheiden, diese Analyse bereits in der Pilotphase zu starten, insbesondere wenn der Avatar Sprachdaten verarbeitet oder Interaktionen mit Nutzerkonten bzw. Fachsystemen ermöglicht.

Zu formalisierende Governance‑Entscheidungen beinhalten insbesondere: den Umfang der vom Avatar verarbeiteten Daten, klar definierte Zwecke, den Verantwortlichen für die Verarbeitung, die Akteure als Auftragsverarbeiter sowie Regeln zur Daten‑Reversibilität. Die Dokumentation dieser Elemente erleichtert die Begründung technischer Entscheidungen und die Vorbereitung von Verträgen.

Einwilligung und UX auf Bildschirm oder Terminal: operative Patterns

Der Interaktionsmodus (Touch, Stimme oder hybrid) beeinflusst stark das Consent‑Design. Auf einer Touch‑Oberfläche ist es einfacher, eine Informationsseite oder ein Zustimmungsfenster vor Sitzungsbeginn anzuzeigen. Bei sprachlicher Interaktion sollte eine hörbare Informationsmeldung vorgesehen werden sowie eine explizite Einwilligungsmodalität, bevor Audio erfasst oder übertragen wird.

Drei gängige UX‑Patterns, die kontextabhängig angepasst werden können, sind: Vorabinformation mit Bestätigungsbutton für Touch‑Interaktionen; kurze Sprachankündigung gefolgt von einer sprachlichen oder taktilen Bestätigung vor der Aufzeichnung; ein passiver Modus ohne Aufzeichnung, wenn die Nutzerin oder der Nutzer ablehnt. Diese Optionen sollten in der Benutzerdokumentation beschrieben und auf dem Bildschirm leicht zugänglich sein.

Audioaufzeichnungen und Einwilligung: Vorsichtspunkte

Audioaufzeichnungen unterliegen speziellen Anforderungen. Wenn eine Organisation beschließt, Audioausschnitte zu speichern, sollte die ausdrückliche Einwilligung der betroffenen Person eingeholt und über Zwecke, Speicherdauer und mögliche Empfänger informiert werden. Wenn keine Aufzeichnungen gespeichert werden, ist es dennoch sinnvoll, diese Einschränkung klar zu kommunizieren, um Vertrauen zu schaffen.

Technisch muss die Lösung die Möglichkeit bieten, Audioerfassung je nach Konfiguration ein‑ oder auszuschalten. Bei SANIA ist die Sprachfunktion eine konfigurierbare Option, die je nach Projekt aktiviert oder deaktiviert werden kann. Es sind also Szenarien möglich, in denen Stimme lokal für die Erkennung verwendet wird, ohne Audio zu speichern, abhängig von Architekturentscheidungen und durchgeführten Verarbeitungen.

Konversationprotokolle, Anonymisierung und Aufbewahrungsdauer

Konversationsprotokolle können personenbezogene Daten oder indirekt identifizierende Elemente enthalten. Die Festlegung einer Aufbewahrungsrichtlinie sowie Maßnahmen zur Anonymisierung oder Pseudonymisierung sind pragmatische Ansätze zur Risikoreduzierung.

Anonymisierung bedeutet die irreversible Unmöglichkeit, eine Person zu identifizieren. Pseudonymisierung ersetzt direkte Identifikatoren durch reversible Schlüssel, die getrennt aufbewahrt werden. Je nach Projektkontext kann eine Organisation Pseudonymisierung vorziehen, um Audits und Debugging zu erleichtern und gleichzeitig das Datenexpositionsrisiko zu reduzieren.

Es wird empfohlen, die Arten der gespeicherten Logs zu dokumentieren (technische Metadaten, Transkripte, Audioausschnitte, Interface‑Ereignisse) und die Aufbewahrung auf die tatsächlich für die definierten operativen Zwecke erforderlichen Daten zu beschränken.

Übermittlungen an CRM, LLM oder andere Systeme: vertragliche Regeln und Patterns

Jede Datenübermittlung an ein CRM, einen externen LLM‑Dienst oder einen Drittanbieter muss vertraglich geregelt werden. Operativ ist zu klären, welche Informationen an diese Systeme weitergeleitet werden und das Prinzip der Datenminimierung anzuwenden.

Zu berücksichtigende vertragliche Klauseln mit Lieferanten und Integratoren sind Garantien zum Umgang mit Daten, das Verbot, die Daten zum unerlaubten Nachtraining von Modellen zu verwenden, Zusagen zur Datenlokalisierung sowie Unterstützungs‑pflichten bei der Wahrnehmung von Betroffenenrechten.

Schriftliche Zusagen der Lieferanten zu fordern erleichtert die Governance und erlaubt, technische Praktiken an regulatorische Anforderungen anzupassen.

  • Klauseln, die von Lieferanten und Auftragsverarbeitern einzufordern sind:

  • präzise Beschreibung der Verarbeitungszwecke und der Weisungen des Verantwortlichen

  • Verbot, Daten ohne ausdrückliche Zustimmung zum Nachtraining von Modellen zu nutzen

  • Zusagen zur Datenlokalisierung und zu internationalen Übermittlungen

  • technische und organisatorische Sicherheitsverpflichtungen entsprechend dem Risiko

  • Unterstützungs‑modalitäten zur Beantwortung von Betroffenenanfragen

Sicherung von Function Calls, Webhooks und Integrationen

Integrationen eröffnen Angriffsflächen. Webhooks, APIs und jegliche Mechanismen zum Aufruf von Funktionen müssen durch Authentifizierungs‑ und Autorisierungsmechanismen gesichert und im Transport verschlüsselt werden. Ebenso sinnvoll ist es, den Umfang der übermittelten Daten auf das strikt Notwendige zu begrenzen.

Praktische Maßnahmen sind u. a. die Dokumentation der Schnittstellen, die Beschränkung der API‑Key‑Scopes, das Einführen sicherer Protokolle für die Protokollierung sowie die Durchführung von Penetrationstests oder Security‑Reviews, um operationelle Integrationsrisiken zu reduzieren.

Datenlokalität und die Entscheidung Edge vs Cloud

Die Entscheidung, Teile der Verarbeitung am Edge (auf dem Bildschirm oder Terminal) oder in der Cloud auszuführen, hat direkte Auswirkungen auf Vertraulichkeit und Latenz. Lokale Verarbeitung kann Datenübermittlungen an Drittinfrastrukturen begrenzen, während eine Cloud‑Architektur Wartung und Orchestrierung vereinfachen kann.

Es empfiehlt sich, diese Optionen anhand der Zwecke, des Datenvolumens und der vertraglichen Anforderungen zu bewerten. SANIA kann in Architekturen eingesetzt werden, die mit professionellen Bildschirmen oder Terminals kompatibel sind und sich je nach Projektkonfiguration in Edge‑ oder Cloud‑Umgebungen integrieren lassen. Diese Flexibilität sollte genutzt werden, um gegebenenfalls die Datenübermittlungen zu minimieren.

Operative Checkliste vor der Inbetriebnahme

Die nachfolgende Checkliste fasst konkrete Entscheidungen und Maßnahmen zusammen, die vor dem Rollout vor Ort zu prüfen sind. Sie zielt darauf ab, das Projekt nachvollziehbar zu machen und die Überprüfung durch DSB und IT‑Sicherheit zu erleichtern.

  • Verarbeitungen kartieren und die verfolgten Zwecke dokumentieren

  • Entscheiden, ob eine DSFA/DPIA erforderlich ist, und ggf. die Analyse bereits in der Pilotphase starten

  • Interaktionsmodus wählen (Touch, Stimme oder hybrid) und die entsprechende Consent‑UX definieren

  • Festlegen, ob Audioaufzeichnungen gespeichert werden und die Einwilligungsdokumentation formalisieren

  • Arten der zu behaltenden Logs definieren, Anonymisierung oder Pseudonymisierung anwenden und die Aufbewahrungsrichtlinie dokumentieren

  • Jede Übermittlung an CRM, LLM oder Dritte vertraglich regeln mit Klauseln zu Zwecken, Verboten des Nachtrainings und Datenlokalisierung (siehe obenstehende Liste für Details der zu verhandelnden Vertragsklauseln mit Dienstleistern und Integratoren).

FAQ

Q1: Muss für ein Empfangs‑Avatar stets eine DSFA/DPIA durchgeführt werden?

A: Die Notwendigkeit einer DSFA hängt vom Risiko der vorgesehenen Verarbeitungen ab. Wenn der Avatar Sprachdaten verarbeitet, Transkripte speichert oder Interaktionen mit Fachsystemen ermöglicht, ist es häufig sinnvoll, eine DSFA in Betracht zu ziehen. Die Entscheidung sollte dokumentiert und begründet werden.

Q2: Wie lassen sich 24/7‑Verfügbarkeit und Datenminimierung vereinbaren?

A: Die Verfügbarkeit des Dienstes verlangt nicht, dass alle Daten dauerhaft gespeichert werden. Es ist möglich, das System so zu entwerfen, dass nur die für den Betrieb notwendigen Elemente gespeichert werden, und Mechanismen wie Anonymisierung oder automatische Löschung entsprechend der definierten Aufbewahrungsrichtlinie zu verwenden.

Conclusion

Ein konformer Rollout eines Empfangs‑Avatars erfordert organisatorische Entscheidungen, technische Wahlmöglichkeiten und klare vertragliche Regelungen. SANIA als professioneller konversationeller Avatar, der für Touch‑ oder Sprachinteraktionen konfigurierbar und auf Bildschirm oder Terminal einsetzbar ist, bietet die notwendige Flexibilität, um die Architektur an Datenschutzanforderungen anzupassen.

Um zu erörtern, wie diese Prinzipien auf Ihr Projekt anzuwenden sind und welche SANIA‑Konfigurationen mit Ihren RGPD‑ und technischen Anforderungen kompatibel sind, können Sie eine Demo oder ein Planung‑Workshop anfragen.