Ratgeber · Recht & Compliance
DSGVO und Browser-Audio-Analyse: Was rechtens ist
Ein Browser-Audio-Visualizer verarbeitet Audio-Daten, die als personenbezogene Daten gelten können, wenn ein Mikrofon aktiv ist oder die Audio-Datei Stimme enthält. Die DSGVO greift damit auch dann, wenn die Verarbeitung komplett clientseitig läuft. Dieser Ratgeber zeigt, welche Rechtsgrundlagen für welchen Anwendungsfall gelten, welche Informationspflichten der Betreiber hat und ob ein lokal-im-Browser-Verarbeiten überhaupt DSGVO-pflichtig ist.
Wann fällt Audio überhaupt unter die DSGVO
Die DSGVO greift, wenn personenbezogene Daten verarbeitet werden. Audio-Daten können personenbezogen sein, müssen es aber nicht.
Personenbezogen sind Audio-Daten wenn sie eine identifizierbare Person enthalten oder zuordenbar machen. Klassische Beispiele: Stimm-Aufnahmen (Podcast, Sprach-Memo, Mikrofon-Live-Eingabe), Audio mit Hintergrund-Geräuschen die Standorte erkennen lassen, gesungene Musik bei der die Interpreten erkennbar sind, Audio-Dateien mit Metadaten (ID3-Tags mit Käufer-Information).
Nicht personenbezogen sind Audio-Daten wie reine Instrumental-Musik ohne Personenbezug, Synthesizer-erzeugte Klänge, Audio-Dateien mit anonymisierten Metadaten. Wenn jemand eine MP3 von einem Lizenz-Anbieter wie Artlist herunterlädt und im Visualizer abspielt, ist das in der Regel nicht personenbezogen.
Für die meisten Visualizer-Anwendungen gilt: das geladene Audio kann personenbezogen sein, wenn der Nutzer die Datei selbst aufgenommen hat oder darin identifizierbare Stimmen vorkommen. Die DSGVO greift damit grundsätzlich.
Wer ist Verantwortlicher?
Art. 4 Nr. 7 DSGVO definiert den Verantwortlichen als “natürliche oder juristische Person, die allein oder gemeinsam mit anderen über die Zwecke und Mittel der Verarbeitung von personenbezogenen Daten entscheidet”.
Im Fall eines clientseitigen Audio-Visualizers ist die Frage, ob der Betreiber der Website Verantwortlicher der Audio-Verarbeitung ist.
Argument pro Verantwortlicher: Der Betreiber stellt das Tool zur Verfügung, definiert die Funktionen (welche Visualisierungs-Modi, welche Audio-Formate), legt die Architektur fest (clientseitig vs serverseitig).
Argument contra Verantwortlicher: Der Betreiber hat keinen Zugriff auf die Audio-Daten, kann sie nicht einsehen, nicht speichern, nicht weiterleiten. Die Verarbeitung findet vollständig in der Sphäre des Nutzers (sein Browser, sein Computer) statt. Der Nutzer entscheidet, welche Audio-Datei er lädt und was er mit dem Ergebnis macht.
Die herrschende Meinung der Aufsichtsbehörden (Datenschutzkonferenz, Landesdatenschutzbeauftragte) tendiert zur zweiten Auffassung: bei rein clientseitiger Verarbeitung ohne Server-Transfer ist der Betreiber nicht Verantwortlicher der Audio-Verarbeitung. Er ist Verantwortlicher für die Website selbst (Server-Logs, Cookies, Analytics), nicht für die Audio-Daten.
Diese Einordnung reduziert die DSGVO-Pflichten erheblich: keine Auftragsverarbeitungs-Verträge nötig, keine Datenschutz-Folgenabschätzung für die Audio-Verarbeitung, keine Aufbewahrungsfristen für Audio-Daten (die nie gespeichert werden).
Mikrofon-Zugriff: zusätzliche Pflichten
Wenn das Tool Mikrofon-Zugriff über die Web Audio API anfordert (navigator.mediaDevices.getUserMedia({audio: true})), gilt eine Sondersituation. Der Browser fragt automatisch um Erlaubnis, und der Nutzer muss explizit zustimmen, bevor das Mikrofon aktiv wird.
DSGVO-rechtlich ist diese Browser-Einwilligung in der Regel ausreichend für die Verarbeitung (Art. 6 Abs. 1 lit. a). Die Einwilligung ist freiwillig (Nutzer kann ablehnen), informiert (Browser zeigt, welche Website auf das Mikrofon zugreifen will) und widerruflich (Nutzer kann jederzeit die Mikrofon-Erlaubnis in den Browser-Einstellungen entziehen).
Trotzdem solltest du in der Datenschutzerklärung zwei Dinge klar machen: erstens, dass das Mikrofon nur für die Visualisierung genutzt wird und keine Aufzeichnung passiert, zweitens, dass keine Daten an Server übertragen werden.
Datenschutzerklärung als Pflicht-Übung
Auch wenn die Audio-Verarbeitung selbst nicht DSGVO-pflichtig ist, brauchst du eine Datenschutzerklärung für die Website. Pflichten nach Art. 13 DSGVO:
Verantwortlicher und Kontaktdaten: Name, Anschrift, E-Mail des Betreibers, ggf. Datenschutzbeauftragter.
Zwecke und Rechtsgrundlagen der Verarbeitung: für jede Datenverarbeitung auf der Website. Bei einem Audio-Visualizer typisch: Server-Logs (berechtigtes Interesse, Art. 6 Abs. 1 lit. f), Cookie-Consent (Einwilligung, Art. 6 Abs. 1 lit. a), Analytics (Einwilligung), AdSense (Einwilligung).
Empfänger der Daten: Hosting-Anbieter, Analytics-Anbieter, Werbe-Netzwerke. Server-Standort EU oder Ausland mit Hinweis auf Übermittlungs-Rechtsgrundlage.
Aufbewahrungsdauer: für jede Datenkategorie die Speicherdauer. Audio-Daten typischerweise “keine Speicherung, ausschließlich clientseitige Verarbeitung”.
Betroffenenrechte: Auskunft (Art. 15), Berichtigung (Art. 16), Löschung (Art. 17), Einschränkung (Art. 18), Widerspruch (Art. 21), Datenportabilität (Art. 20).
Beschwerderecht bei der zuständigen Datenschutzaufsichtsbehörde (für AKARA Solutions GmbH: Unabhängiges Landeszentrum für Datenschutz Schleswig-Holstein, ULD).
Cookie-Consent für Drittanbieter
Audio-Visualizer im Browser sind meist statische Websites mit Tool-Funktion, aber sie nutzen oft Drittanbieter: Google AdSense (Werbung), Umami oder Plausible (Analytics), Cloudflare oder Netlify (CDN), Google Search Console (Suchmaschinen-Verifikation).
Drittanbieter, die personenbezogene Daten verarbeiten (AdSense, Google Analytics), brauchen Einwilligung nach Art. 6 Abs. 1 lit. a DSGVO und § 25 TTDSG (Cookie-Consent für nicht-essenzielle Cookies). Praktisch heißt das: ein Cookie-Banner, der vor dem Laden der AdSense- und Analytics-Skripte die Nutzer-Einwilligung einholt.
Anbieter, die rein technisch arbeiten (Cloudflare als Reverse-Proxy, statische Hoster wie Netlify), brauchen keine Einwilligung, weil sie nicht zur Verarbeitung personenbezogener Daten beitragen (über das Lieferdesign hinaus).
Pragmatischer Setup für einen Audio-Visualizer:
- Server-Logs (Hosting-Anbieter): berechtigtes Interesse, keine Einwilligung
- Umami (privacy-first Analytics): kann oft ohne Cookies konfiguriert werden, in dem Fall keine Einwilligung
- AdSense: Einwilligung via Cookie-Banner mit Google Consent Mode v2
- Audio-Verarbeitung im Browser: keine separate Einwilligung nötig
Browser-Permission und Trust-Layer
Die DSGVO ist nur eine Seite der Medaille. Praktisch wichtiger für die Nutzer-Wahrnehmung ist die Transparenz, wo Daten verarbeitet werden. Audio-Visualizer im Browser haben hier einen klaren Vorteil:
- Keine Upload-Pflicht: Audio bleibt auf dem Nutzer-Gerät
- Keine Cloud-Speicherung: keine Server, die Audio-Daten halten
- Keine Konten: keine Anmeldung, keine Profile, kein Cross-Device-Tracking
- Transparenter Code: wenn der Code Open Source ist, kann jeder die clientseitige Verarbeitung verifizieren
Diese Punkte sollten in der Datenschutzerklärung und im Tool-UI sichtbar gemacht werden. Eine “100 % im Browser, kein Upload”-Botschaft auf der Landingpage ist sowohl Marketing-Argument als auch Datenschutz-Information.
Sonderfall: Microphone-Recording-Apps
Wenn das Tool nicht nur visualisiert, sondern Audio aufnimmt (z.B. zum späteren Export oder zur Live-Streaming-Integration), ändert sich die DSGVO-Situation deutlich. Eine Aufnahme-Funktion verarbeitet personenbezogene Daten aktiv, mit Speicherung (zumindest im Browser-RAM) und potentiell Datei-Export auf die Festplatte.
Pflichten für Recording-Apps:
- Klare Informationspflicht vor jeder Aufnahme (Mic-Icon mit Beschriftung “Aufnahme läuft”)
- Explizite Einwilligung über Browser-Permission hinaus (ggf. zusätzliche Tool-Einwilligung)
- Datenminimierung: nur die zur Visualisierung nötigen Daten, keine zusätzlichen Analysedaten (z.B. Spracherkennung, Sentiment-Analyse) ohne separate Einwilligung
- Speicherbegrenzung: Audio im RAM, nicht im localStorage oder IndexedDB ohne explizite Nutzer-Aktion
Für reine Visualisierung ohne Aufnahme-Funktion sind diese Pflichten nicht relevant.
Was im Audio-Tool DSGVO-konform sein muss
Ein clientseitiger Browser-Audio-Visualizer ist DSGVO-rechtlich entspannt, sofern er sich an drei Regeln hält. Erstens: keine Audio-Daten an Server übertragen, alles im Browser-RAM. Zweitens: transparente Datenschutzerklärung, die die clientseitige Architektur als Privacy-Feature klar macht. Drittens: für alle externen Drittanbieter (AdSense, Analytics, Werbung) korrekt ein Cookie-Consent-Banner einsetzen, der Einwilligung vor dem Laden der Skripte einholt. Wer diese drei Punkte berücksichtigt, hat einen DSGVO-konformen Audio-Visualizer ohne die Bürokratie, die Cloud-basierte Konkurrenz erfordert.
FAQ
Häufige Fragen
Greift die DSGVO bei rein clientseitiger Audio-Analyse?
Ja, sobald personenbezogene Daten verarbeitet werden, was bei Audio mit Stimme gegeben sein kann. Die DSGVO definiert Verarbeitung weit (Art. 4 Nr. 2): jede automatisierte Operation, einschließlich Erheben, Erfassen, Auslesen. Die clientseitige Analyse im Browser ist eine Verarbeitung. Allerdings: wer keine Daten an Server überträgt, hat keine Verantwortlichen-Position gem. Art. 4 Nr. 7 als datenverarbeitende Stelle, sondern stellt nur die technische Möglichkeit zur Selbstverarbeitung bereit. Die Pflichten sind dadurch deutlich reduziert.
Brauche ich eine Datenschutzerklärung, wenn nichts an Server geht?
Ja, weil deine Website typischerweise weitere Daten verarbeitet (Server-Logs, Cookies, Drittanbieter wie AdSense, Umami-Analytics). Die Datenschutzerklärung muss diese Verarbeitungen offen legen und klar machen, dass die Audio-Analyse selbst lokal im Browser stattfindet (also nicht in die Datenschutzerklärung als Server-Verarbeitung gehört). Wer eine bewusst transparente Datenschutzerklärung schreibt, weist auf die clientseitige Verarbeitung als Privacy-Feature hin.
Was ist mit Mikrofon-Zugriff für Live-Visualisierung?
Sobald die Web Audio API auf das Mikrofon zugreift (via navigator.mediaDevices.getUserMedia), gilt das als Verarbeitung personenbezogener Daten, weil aufgenommene Stimme eindeutig einer Person zugeordnet werden kann. Rechtsgrundlage: Einwilligung des Nutzers nach Art. 6 Abs. 1 lit. a DSGVO. Der Browser fragt automatisch um Mikrofon-Erlaubnis, was die DSGVO-Einwilligung in der Praxis abdeckt. Trotzdem solltest du in der Datenschutzerklärung erklären, was mit den Mikrofon-Daten passiert (in unserem Fall: nichts außer der Visualisierung im Browser).
Welche Logs sind beim Audio-Tool zulässig?
Server-Logs ohne personenbezogene Audio-Daten sind nach Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse) zulässig: IP-Adresse, Zeitstempel, Page-View. Diese Logs sind für Sicherheit und Performance relevant und stehen in der Datenschutzerklärung. Nicht zulässig: Logs, die Audio-Inhalte, Dateinamen mit personenbezogenem Bezug oder Mikrofon-Inhalte speichern. Wenn dein Tool tatsächlich nur clientseitig arbeitet, gibt es solche Logs technisch gar nicht.
Was gilt für Kinder unter 16?
Für Nutzer unter 16 Jahren gilt nach Art. 8 DSGVO eine erhöhte Schutzanforderung: bei Einwilligungs-basierten Verarbeitungen brauchst du die Zustimmung der Erziehungsberechtigten. Praktisch heißt das: ein Audio-Visualizer ohne Altersbeschränkung sollte keine Einwilligungs-basierten Funktionen (Mikrofon-Zugriff für Aufnahme, Datei-Upload mit Stimm-Analyse) ohne Hinweis auf das Mindestalter anbieten. Bei rein audio-analytischer Visualisierung ohne Personenbezug (z.B. Instrumental-MP3) ist das weniger kritisch.
Quellen