Daten im PowerDesk-Client
Diese Seite beschreibt das tatsächlich umgesetzte Verhalten von AíPowerDesk auf der Seite des Anwenders. Sie richtet sich an Datenschutzbeauftragte, Auditoren, Betriebsräte und Administratoren, die nicht nur wissen müssen, ob Daten verarbeitet werden, sondern wo sie liegen, wie sie heißen, wie lange sie bleiben und wodurch sie wieder verschwinden.
Die übergeordnete Einordnung — Betriebsmodelle, Verantwortlichkeiten, AI Act, DSGVO — finden Sie auf der Seite Compliance.
Was mit „PowerDesk-Client" gemeint ist
Der PowerDesk-Client ist die Benutzeroberfläche von AíPowerDesk, so wie sie beim Anwender läuft. Sie erscheint in drei Ausprägungen, die sich technisch denselben Speicher teilen:
| Ausprägung | Aufruf | Besonderheit |
|---|---|---|
| Widget in der STARFACE App | eingebettet in die STARFACE-Oberfläche | der Regelfall |
| Eigenständige Rufliste im Browser | eigener Tab bzw. eigenes Fenster | teilt Anmeldung und Daten mit dem Widget |
| Installierte App (PWA) | Startmenü / Homescreen | zusätzlich ein Offline-Rahmen (siehe unten) |
Technisch korrekt wäre „Endgerät", der Begriff ist im STARFACE-Umfeld aber bereits für Telefone und Softphones belegt. Entscheidend für den Datenschutz ist ohnehin nicht das Gerät, sondern das Browser-Profil, in dem der Client läuft: Dort liegen die Daten, und dort werden sie auch wieder gelöscht. Ein Anwender mit Notebook, Smartphone und Tablet hat drei getrennte Datenbestände, die sich unabhängig voneinander aktualisieren.
Welche Daten es gibt und wie sie sich unterscheiden
Die folgenden Begriffe werden im Alltag häufig vermischt. Für die datenschutzrechtliche Bewertung ist die Unterscheidung wesentlich, weil sie sich in Entstehung, Inhaltstiefe und Aufbewahrung deutlich unterscheiden.
| Datenart | Woraus sie entsteht | Inhaltstiefe |
|---|---|---|
| Ruflisteneintrag | automatisch aus den Verbindungsdaten der STARFACE | Verkehrsdaten: Wer, wann, wie lange, mit welchem Ergebnis — zuzüglich des Ruflistenkommentars |
| Ruflistenkommentar | von einem Anwender geschrieben oder von AíPowerDesk mit der Kurzfassung der Zusammenfassung befüllt | so viel, wie der Anwender hineinschreibt — bzw. verdichteter Gesprächsinhalt, wenn die Kurzfassung eingetragen wurde |
| Transkription | Verschriftlichung des gesprochenen Wortes | Gesprächsinhalt im Volltext |
| Live-Transkription | entsteht während des Gesprächs, ohne Audioaufnahme | wie Transkription |
| Gesprächszusammenfassung | KI-Verdichtung einer Transkription | verdichteter Gesprächsinhalt, KI-generiert und als solche gekennzeichnet |
| Gesprächsaufzeichnung | Audioaufnahme über das Modul Call Recording | das Gespräch selbst |
Ein Ruflisteneintrag entsteht immer — auch dann, wenn weder transkribiert noch aufgezeichnet wird. Eine Gesprächszusammenfassung entsteht nie ohne eine vorausgegangene Transkription. Wer also Gesprächsinhalte aus der Verarbeitung heraushalten will, setzt bei der Transkription an, nicht bei der Zusammenfassung.
AíPowerDesk trägt die Kurzfassung der Gesprächszusammenfassung in den Ruflistenkommentar ein. Das ist gewollt — so sieht man den Gesprächsinhalt schon in der Listenansicht, ohne den Eintrag zu öffnen. Für die datenschutzrechtliche Bewertung hat es aber zwei Folgen, die man kennen muss:
- Der Ruflisteneintrag selbst trägt damit Gesprächsinhalt, nicht nur Verkehrsdaten. Wer den Eintrag sehen darf, sieht die Kurzfassung — auch ohne eigenes Recht auf Transkript oder Zusammenfassung. Wer diese Trennung braucht, muss bereits die Sichtbarkeit des Ruflisteneintrags entsprechend einschränken; ein restriktives Transkript-Recht allein genügt dafür nicht.
- Der Inhalt liegt damit auch im Ruflisten-Cache des Clients (siehe nächster Abschnitt) — dort, wo sonst nur Verkehrsdaten lägen.
Nachvollziehbar bleibt die Herkunft: Der Kommentar führt Autor und Änderungsdatum mit, und ein Schreibschutz verhindert, dass ein manuell geschriebener Text überschrieben wird. Aus der Zusammenfassungsansicht lässt sich eine Zusammenfassung zusätzlich per übernehmen. Das Setzen des Kommentars ist ein eigenes Recht und lässt sich getrennt vergeben.
Wo der Client Daten ablegt
Alle genannten Ablagen liegen im Browser-Profil des Anwenders auf dessen Rechner. Sie sind für einen Auditor in jedem Chromium-Browser unter F12 → Application nachvollziehbar (siehe Prüfhinweise).
| Ablage | Technischer Ort | Inhalt | Lebensdauer |
|---|---|---|---|
| Ruflisten-Cache | IndexedDB, Datenbank CallListDB_<Benutzer-ID>, Objektspeicher callListEntries | Ruflisteneinträge inkl. Rufnummern, Namen, Zeiten, Dauer, Ergebnis, Gruppe sowie dem Ruflistenkommentar — der die Kurzfassung der Zusammenfassung enthalten kann | bis zum nächsten Reset (siehe unten) |
| Zusammenfassungs-Cache | dieselbe Datenbank, Objektspeicher transcriptionSummaries | Gesprächszusammenfassungen | bis zum nächsten Reset; nach 7 Tagen wird ohnehin erneut beim Server nachgefragt |
| Persönliche Einstellungen | localStorage | Filter, Spaltenbreiten, ausgeblendete Einträge, Ansichtsauswahl, letzter Abrufzeitpunkt | bis zum Reset bzw. Löschen der Browserdaten |
| Softphone-Einstellungen | localStorage | Serveradresse, Benutzername und Kennwort des optionalen WebRTC-Softphones sowie eine gerätebezogene Zufalls-Kennung | bis der Anwender sie ändert oder die Browserdaten löscht |
| Registrierungs-Kennung | sessionStorage | technische Kennung der SIP-Registrierung dieses Tabs | endet mit dem Tab |
| Offline-Rahmen (nur PWA) | Service-Worker-Cache | ausschließlich Programmdateien, Symbole und das Seitengerüst | bis zum nächsten Modulupdate |
Pro angemeldetem Benutzer eine eigene Datenbank. Der Name der Ruflisten-Datenbank enthält die STARFACE-Benutzer-ID. Meldet sich am selben Browser ein anderer Benutzer an, werden die Datenbanken aller übrigen Benutzer gelöscht. Auch ausgeblendete Einträge werden je Benutzer getrennt gehalten.
Nutzt ein Anwender das optionale WebRTC-Softphone, liegt dessen Kennwort unverschlüsselt im localStorage des Browsers — lesbar für jeden, der Zugriff auf dieses Browser-Profil hat. Verwenden Sie dafür ein eigenes SIP-Kennwort, nicht das STARFACE-Anmeldekennwort des Benutzers, und richten Sie das Softphone nicht auf gemeinsam genutzten Arbeitsplätzen ein.
Was der Client nicht dauerhaft speichert
Die Abgrenzung nach unten ist für die Bewertung genauso wichtig:
- Transkript-Volltexte werden nicht dauerhaft im Client abgelegt. Sie werden beim Öffnen eines Gesprächs geholt und leben nur in der laufenden Sitzung; beim Schließen oder Neuladen sind sie fort. Dauerhaft gespeichert werden clientseitig nur Ruflisteneinträge — samt Ruflistenkommentar — und Zusammenfassungen.
- Audiodaten werden nicht im Client gespeichert. Voicemail- und Aufzeichnungswiedergabe erfolgt aus der STARFACE heraus.
- Der Offline-Rahmen der installierten App enthält keine Gesprächsdaten. Alle Datenpfade zur STARFACE sind vom Zwischenspeichern ausgenommen; zwischengespeichert werden nur Programmdateien.
- Während eines laufenden Gesprächs liegt die Live-Transkription ausschließlich im Arbeitsspeicher — auf dem Server wie im Client. Dauerhaft geschrieben wird erst beim Auflegen.
Welche Daten den Client verlassen
| Weg | Was übertragen wird | Wann |
|---|---|---|
| STARFACE-Anlage | sämtliche Abrufe und Eingaben | laufend; jeder Abruf wird serverseitig gegen die Berechtigungen des Benutzers geprüft |
| KI-Provider | Zusammenfassungen, bei Rückfragen des Assistenten auch Transkripte | nur bei Nutzung des KI-Assistenten; Ziel ist das konfigurierte KI-Profil (lokal oder extern) |
| Push-Dienst des Browserherstellers | Name und Rufnummer des Anrufers sowie eine Anruf-Kennung | optional nur wenn der Anwender Hintergrund-Benachrichtigungen selbst aktiviert hat |
| Ticket-/CRM-System | von Ihnen festgelegte Felder | optional nur bei eingerichtetem Export über EventBridge |
Zwei Punkte verdienen besondere Beachtung:
KI-Assistent. Reichen die Zusammenfassungen für eine Frage nicht aus, kann der Assistent gezielt Transkripte nachfordern. Jede dieser Nachforderungen läuft über dieselben geprüften Abrufe wie die Oberfläche — es gibt keinen Weg zum Modell, der die Berechtigungen umgeht. Der Assistent sieht damit nie mehr, als der fragende Benutzer selbst sehen dürfte.
Hintergrund-Benachrichtigungen. Diese Funktion ist bewusst nicht vorausgewählt. Wird sie aktiviert, läuft die Zustellung technisch bedingt über den Push-Dienst des jeweiligen Browserherstellers. Der Inhalt ist Ende-zu-Ende verschlüsselt, der Zustellweg ist jedoch ein Dienst außerhalb Ihrer Anlage. Wenn das für Ihren Einsatz nicht tragfähig ist, lassen Sie die Funktion deaktiviert.
Wenn Berechtigungen nachträglich eingeschränkt werden
Dies ist die Kernfrage jeder Prüfung: Gilt „einmal Zugriff, immer Zugriff"?
Nein. AíPowerDesk setzt einen Entzug aktiv bis in den Client durch. Dafür greifen drei Mechanismen.
1. Rechteänderung — vollständiger lokaler Reset
Der Client merkt sich, mit welchen Berechtigungen er zuletzt gearbeitet hat. Bei jedem Start vergleicht er diesen Stand mit den aktuellen Berechtigungen. Weichen sie ab, wird der gesamte lokale Bestand gelöscht und unter den neuen Berechtigungen neu aufgebaut:
- alle Ruflisteneinträge aus dem Ruflisten-Cache,
- alle gespeicherten Gesprächszusammenfassungen,
- die gespeicherten Filterlisten (Benutzer, Gruppen, Partner, Bearbeiter).
Wichtig ist der Unterschied zwischen ausblenden und löschen: Es wird gelöscht. Ein bloßes Filtern würde die Verkehrsdaten in den Entwicklerwerkzeugen des Browsers lesbar lassen.
Bis der Neuaufbau abgeschlossen ist, bleiben Detailabrufe gesperrt. Wird der Vorgang unterbrochen, wird er beim nächsten Start wiederholt.
2. Privates Gespräch — sofortiger Entzug
Markiert ein Gesprächsteilnehmer ein Gespräch als privat, wirkt das unmittelbar gegenüber allen anderen:
- Ein laufendes Mithören wird aufgelegt, ein neues ist nicht mehr möglich.
- Eine von Dritten gestartete Live-Transkription wird serverseitig entzogen; der Client verwirft daraufhin den gesamten bis dahin angezeigten Transkriptstand.
- Der Eintrag verschwindet aus allen Ruflisten-Auslieferungen und wird bei verbundenen Clients samt Zusammenfassung lokal gelöscht — nicht als gesperrt markiert. Denn ein sichtbarer Eintrag mit Schloss-Symbol würde weiterhin verraten, wer wann wie lange mit wem gesprochen hat, und genau das ist bei einem ausdrücklich geschützten Gespräch das Wesentliche.
- Für die Teilnehmer selbst bleibt das Gespräch sichtbar und trägt eine Kennzeichnung.
Wer zum Zeitpunkt der Markierung nicht verbunden war, wird beim nächsten Start nachgeholt: Der Client meldet, welche Gespräche er lokal hält, und bekommt die Teilmenge zurück, die er löschen muss.
3. Gelöschte Ruflisteneinträge
Löschungen in der STARFACE werden über einen eigenen laufenden Abgleich in den Client nachgezogen.
Grenzen und bekannte Einschränkungen
Die beschriebenen Mechanismen sind wirksam, aber sie haben Grenzen. Wir benennen ihre Grenzen ausdrücklich, damit Sie sie in Ihrem Löschkonzept berücksichtigen können.
- Die Löschung greift erst, wenn der Client wieder läuft. Sie setzt voraus, dass der Anwender AíPowerDesk erneut öffnet und die Anlage erreichbar ist. Ein Gerät, das nach der Rechteänderung nie wieder online geht, behält seinen Datenbestand — bis es das nächste Mal genutzt wird.
- Es ist eine Löschung in einer Browser-Datenbank, keine sichere Löschung des Datenträgers. Freigegebene Speicherbereiche können auf Dateisystemebene fortbestehen, bis sie überschrieben werden. Für ausgemusterte Geräte gelten Ihre üblichen Regeln zur Datenträgervernichtung.
- Selbst erzeugte Kopien sind nicht erfasst. Was ein Anwender exportiert, ins CRM oder Ticketsystem übernommen, per E-Mail versendet, kopiert, ausgedruckt oder als Screenshot festgehalten hat, liegt außerhalb der Reichweite jedes technischen Entzugs. Das gilt für jede Software und ist der Grund, warum ein Berechtigungskonzept organisatorische Regeln nicht ersetzt.
- Ein Anwender kann auf mehreren Geräten arbeiten. Jedes Browser-Profil zieht einzeln nach, sobald es das nächste Mal geöffnet wird.
- Das Aufräumen fremder Benutzerdatenbanken auf einem gemeinsam genutzten Browser ist Bestmöglich-Verhalten. Es funktioniert in allen aktuellen Browsern, aber ältere Safari- und Firefox-Versionen stellen die dafür nötige Schnittstelle nicht bereit. Auf gemeinsam genutzten Arbeitsplätzen sind getrennte Browser-Profile oder Betriebssystem-Benutzer die verlässlichere Lösung.
- Unmittelbar nach dem Auflegen kann es einige Sekunden dauern, bis eine nachträglich gesetzte Privat-Markierung auch über die Rufliste greift — so lange, bis der zugehörige Verbindungsdatensatz auf der STARFACE geschrieben ist.
- Zusammenfassungen privater Gespräche werden weiterhin erzeugt, sofern die automatische Zusammenfassung aktiv ist. Lesen können sie ausschließlich die Gesprächsteilnehmer. Soll für ein Gespräch gar keine Zusammenfassung entstehen, ist die automatische Zusammenfassung der falsche Ort dafür — greifen Sie stattdessen über die Regelwerke von Call Recording ein.
Wir können zusichern, dass AíPowerDesk einen Rechteentzug aktiv bis in den lokalen Speicher des Clients durchsetzt, sobald dieser das nächste Mal läuft. Wir können nicht zusichern, dass Daten, die einmal zu einem Anwender geflossen sind, restlos und unwiederbringlich verschwinden. Diese Grenze hat jede Software, die Daten anzeigt. Sie ist der Grund, weshalb ein restriktives Ausgangs-Berechtigungskonzept wirksamer ist als jede nachträgliche Korrektur.
Lokalen Datenbestand gezielt löschen
| Ziel | Vorgehen | Wirkung |
|---|---|---|
| Ruflistendaten neu aufbauen | Im Client: Menü → | löscht Ruflisten-Cache, Zusammenfassungs-Cache und gespeicherte Filterlisten und lädt neu |
| Rechteänderung durchsetzen | Berechtigungen anpassen; der Reset läuft beim nächsten Start des Clients automatisch | wie oben, ohne Zutun des Anwenders |
| Alles entfernen | Browserdaten für die Adresse der STARFACE löschen | entfernt zusätzlich Einstellungen, Softphone-Daten und den Offline-Rahmen |
| Arbeitsplatzwechsel | Anmeldung des neuen Benutzers am selben Browser | löscht die Datenbanken der übrigen Benutzer |
Prüfhinweise für Auditoren
Der gesamte lokale Bestand lässt sich ohne Zusatzwerkzeuge einsehen. In einem Chromium-Browser:
- AíPowerDesk öffnen und mit F12 die Entwicklerwerkzeuge starten.
- Registerkarte Application wählen.
- Unter Storage → IndexedDB die Datenbank
CallListDB_<Benutzer-ID>öffnen. Die beiden ObjektspeichercallListEntriesundtranscriptionSummarieszeigen exakt den Bestand, der oben beschrieben ist. - Unter Storage → Local Storage liegen die persönlichen Einstellungen.
- Unter Application → Cache Storage lässt sich nachvollziehen, dass der Offline-Rahmen ausschließlich Programmdateien enthält.
Für eine Wirksamkeitsprüfung des Rechteentzugs:
- Bestand im Client erzeugen lassen und in der IndexedDB sichtbar machen.
- Die Berechtigungen des Benutzers in der Modulkonfiguration einschränken.
- Den Client neu laden — der Bestand wird gelöscht und unter den neuen Berechtigungen neu aufgebaut.
- Erneut in der IndexedDB prüfen: Die nicht mehr zugänglichen Einträge sind fort, nicht nur ausgeblendet.
Für die Wirksamkeitsprüfung des privaten Gesprächs genügt es, ein Gespräch als Teilnehmer privat zu markieren, während ein zweiter Benutzer die Rufliste geöffnet hat: Der Eintrag verschwindet dort unmittelbar und ist auch in dessen IndexedDB nicht mehr vorhanden.
Weiterführende Dokumentation
- Compliance — Betriebsmodelle, Verantwortlichkeiten, AI Act und DSGVO
- Live-Transkription oder Call Recording? — welcher Weg zur Gesprächsdokumentation zu Ihren Anforderungen passt
- Glossar — verbindliche Begriffsdefinitionen