Was Sie zu personenbezogenen Daten bedenken sollten, bevor Sie einen Sprachassistenten bauen

Was ein Sprachassistent tatsächlich erzeugt

Wenn ein Gesprächs-Flow läuft, hinterlässt er mehrere verschiedene Arten von Daten, und sie sind nicht gleichwertig. Solange Sie sie nicht trennen, können Sie nicht beurteilen, wie viel davon Sie wirklich brauchen.

• Das Rohaudio: der Klang dessen, was die Person gesagt hat. Audio ist personenbezogen, soweit es den Sprecher identifizieren kann.
• Das Transkript: dieselbe Rede als Text. Es kann Namen, Adressen, Gesundheits- oder Finanzangaben enthalten.
• Erfasste Felder: was der Flow gezielt abfragt, etwa Name, Telefonnummer, Datum, Betrag.
• Hochgeladene Dokumente: ein Ausweis, eine Rechnung oder ein Bericht. Das Bild selbst und die daraus gelesenen Felder sind getrennte Daten.
• Technische Aufzeichnungen: IP-Adresse, Browserdaten, Sitzungszeit.

Wie das Datenschutzrecht das einordnet

In der EU fällt das unter die DSGVO, im Vereinigten Königreich unter die UK GDPR; beide definieren personenbezogene Daten als Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen. In der Türkei ist der entsprechende Rahmen das Gesetz Nr. 6698 (KVKK) mit einer vergleichbaren Definition. Eine Aufnahme oder ein Transkript kann unter beide fallen.

Zwei Pflichten tauchen in der Praxis fast immer auf: Sie brauchen eine Rechtsgrundlage für die Verarbeitung, und Sie müssen die Menschen über diese Verarbeitung informieren. Die Information ist eine eigene Pflicht und entfällt nicht, nur weil Sie auch eine Einwilligung eingeholt haben.

Manche Kategorien, etwa Gesundheits- und biometrische Daten, gelten als besonders und unterliegen strengeren Bedingungen. Ob eine Sprachaufnahme als biometrisches Datum zählt, hängt davon ab, was Sie damit tun: Einen Stimmabdruck zur Identifizierung zu nutzen ist etwas anderes, als nur aufzuschreiben, was jemand gesagt hat.

Fragen, die Sie vor dem Bau beantworten sollten

Die folgenden Fragen sind Designfragen, keine Rechtsfragen, doch ihre Antworten prägen Ihre rechtliche Lage unmittelbar. Wer sie vor dem Bau beantwortet, muss später nicht nachträglich Daten bereinigen.

• Müssen Sie das Rohaudio behalten, oder reicht das Transkript? Reicht das Transkript, speichern Sie das Audio gar nicht.
• Wie lange bewahren Sie Transkripte auf? Sie unbegrenzt zu behalten ist keine Entscheidung, sondern das Fehlen einer Entscheidung.
• Fragt der Flow etwas ab, das Sie gar nicht brauchen? Daten, die Sie nie erheben, müssen Sie nie schützen.
• Wenn die gelesenen Felder reichen: Müssen Sie das Dokumentbild behalten?
• Wer in Ihrer Organisation kann diese Daten sehen?
• An welchem Punkt im Flow erfährt die Person, dass das Gespräch aufgezeichnet wird?

Was das Flow-Design löst

Ein großer Teil der Datenschutzarbeit wird durch den Flow selbst erledigt, nicht durch ein Richtliniendokument. Daten, die Sie nie erheben, müssen Sie nie sichern, speichern oder löschen.

Einige Ansätze, die sich in der Praxis bewähren: den ersten Schritt zu einer Informationsnachricht machen; jedes Feld darauf prüfen, ob Sie es wirklich brauchen; aus Dokumenten nur die nötigen Felder lesen; und den Menschen die Wahl lassen, zu tippen statt zu sprechen.

In Agenola entscheidet, wer den Flow baut, welche Fragen gestellt werden, welches Dokument angefordert wird und was aufgezeichnet wird. Erfasste Felder und Transkripte bleiben in Ihrem Arbeitsbereich und sind im Dashboard sichtbar. Das macht das Tool nicht für Sie rechtskonform; es bedeutet, dass die Entscheidungen bei Ihnen liegen.

Drei häufige Fehler

• Alles aufzeichnen und später filtern wollen. Daten schaffen Verantwortung ab dem Moment, in dem sie erhoben werden.
• Den Hinweis ans Ende des Flows setzen. Niemand ist informiert, wenn er die Daten schon abgegeben hat.
• Sich darauf verlassen, dass ein Tool „konform“ ist. Konformität ist eine Eigenschaft der Organisation, die die Daten verarbeitet, und ihres Zwecks, nicht der Software.