Anfragen betroffener Personen

Als Admin oder Inhaber bearbeitest du unter Einstellungen > Richtlinien > Anfragen betroffener Personen Löschanfragen. Tale verfolgt die Anfrage, ihre Freigabe und Wartezeit sowie das Ergebnis der Löschung. Prüfe vor der Einreichung Identität und passenden Umfang nach dem Verfahren deiner Organisation.

Eine Anfrage einreichen

1. Wähle Anfrage einreichen und suche die Person nach Name oder E-Mail. Prüfe, ob du das richtige Konto ausgewählt hast.
2. Wähle den Rechtsgrund und schreibe unter Begründung, worum es geht. Verweise auf deinen internen Fall.
3. Gib exakt ERASE ein und wähle Anfrage einreichen.
4. Öffne den Beleg und prüfe Status, Frist und die nächste erforderliche Aktion.

Die Löschung entfernt betroffene Daten endgültig; sie verschiebt sie nicht in den Papierkorb. Der Beleg erfasst Kategorien und Anzahlen, darunter Chats, Dokumente und Uploads, Einstellungen, Feedback, Benachrichtigungen, Nutzung und das Bereinigen von Personenkennungen im Audit-Protokoll. Sie löscht außerdem die Verläufe der Läufe des Standard-Agenten, die die Person gestartet hat, und die Dateien, die nur diese Verläufe enthielten; die Ergebnisdateien, die eine Aufgabe behält, bleiben. Die Löschung entfernt außerdem die getrennten Sandbox-Arbeitsbereiche der Agentenläufe, die die Person gestartet hat, auch wenn darin noch Arbeit läuft; der Beleg zählt sie unter Sandbox-Arbeitsbereiche. Ein Arbeitsbereich zählt erst, wenn der Sandbox-Dienst seine Dateien gelöscht hat, was bei einem großen eine Weile dauern kann. Bis dahin, oder solange das Löschen wiederholt fehlschlägt, lautet der Beleg Teilweise und nennt sandboxWorkspaces unter den fehlgeschlagenen Durchläufen; wähle später Erneut versuchen, und die Löschung wird abgeschlossen, sobald die Dateien entfernt sind. Unter Kubernetes zählt ein Arbeitsbereich, sobald sein Volume an den Storage-Provisioner des Clusters übergeben ist; mit einer StorageClass, deren reclaimPolicy Retain ist, bleiben die Dateien des Volumes, bis ein Operator das Volume entfernt, obwohl der Beleg den Arbeitsbereich zählt. Ein Sandbox-Dienst oder Gerät, das noch nicht auf diese Version aktualisiert ist, kann die Löschung nicht bestätigen; der Beleg bleibt dann Teilweise, bis es aktualisiert ist.

Die Kategorie Modellanfragen umfasst Anfragen an die Modell-API und direkte Modellaufrufe in Automationen. Abgerechnete Anfragen werden entfernt. Eine noch laufende Anfrage behält die Daten, die für ihre Abrechnung nötig sind; die Identität der Person wird durch ein Pseudonym ersetzt. Spätere Nutzung wird unter diesem Pseudonym verbucht. Schlägt das Entfernen des Automationslaufs oder der Identität fehl, bleibt der Beleg Teilweise und die davon abhängige Bereinigung der Nutzungsdaten wartet auf einen neuen Versuch.

Aufgaben, die die Person als Reviewer nennen, verlieren diese Zuweisung. Eine Prüfanfrage, die noch auf sie wartet, geht an die erste berechtigte Person der Ersatzfolge: den Ersteller der Aufgabe oder des Projekts. Diese Person wird benachrichtigt. Bei einer archivierten Aufgabe geht die Prüfanfrage ohne Benachrichtigung weiter. Prüfentscheidungen, die die Person bereits getroffen hat, bleiben ohne ihren Namen erhalten.

Bei der Löschung bleiben die Inhalte gespeicherter Automatisierungsversionen und ihre Testberichte unverändert. Die Löschung ersetzt die Kennung der Person durch ein Pseudonym, wenn sie eine Version gespeichert oder deren Tests geprüft, sie live geschaltet, ihren Trigger eingerichtet, sie in einem Projekt installiert oder sie gelöscht hat.

Die Löschung geeigneter Läufe einer Person verändert keine Werte, die in Tests aufbewahrter Automatisierungsversionen übernommen wurden. Prüfe diese Inhalte separat nach dem Verfahren deiner Organisation. Nutze synthetische Beispiele, wenn du einen Lauf als Test speicherst.

Vorher die Richtlinie prüfen

Nur der Inhaber kann diese Richtlinie ändern. Strengere Schutzmaßnahmen gelten sofort. Lockerungen werden 24 Stunden vorgemerkt, damit jeder Admin sie abbrechen kann. Prüfe die wirksamen Einstellungen und Hinweise auf ausstehende Änderungen, bevor du mit einem neuen Wert planst.

Den Beleg verfolgen

Ein offener Beleg kann eine zweite Anfrage für dieselbe Person verhindern. Arbeite mit diesem Beleg weiter. War die Anfrage schon bei der Einreichung blockiert, muss ein neuer Versuch erneut die aktuelle Freigabe- und Wartezeitregel erfüllen. Ein Beleg, der auf Freigabe wartet, behält die bei der Einreichung festgehaltene Freigabepflicht: Schaltest du das Vier-Augen-Prinzip später aus, gibt ihn das nicht frei.

Automationsläufe, die bei einem Upgrade zurückgehalten wurden, bleiben erhalten, solange ihre früheren externen Aktionen nicht überprüft sind. Die Löschung entfernt weiterhin die anderen geeigneten Automationsläufe der Person und weist gelöschte und aufbewahrte Läufe getrennt aus. Der Beleg bleibt teilweise abgeschlossen. Diese Ausführungssperren sind von Legal Holds unabhängig und können derzeit nicht aufgehoben werden. Eine Stopp-Anfrage oder ein erneuter Löschversuch hebt sie nicht auf. Eine Organisation mit solchen Sperren kann ebenfalls nicht gelöscht werden.

Die Frist verwalten

Die Liste zeigt die erfasste Frist und mögliche Überschreitungen. Nutze Frist verlängern für eine begründete Verlängerung, solange die Aktion verfügbar ist. Die Anwendung erlaubt eine Verlängerung vor Ablauf der ursprünglichen Frist und protokolliert Grund und Admin.

Die Frist unterstützt die Nachverfolgung. Deine Organisation bleibt für die Prüfung und die Kommunikation mit der Person verantwortlich. Ein abgeschlossener Tale-Beleg bestätigt für sich allein keine Löschung in unabhängigen externen Systemen oder Backups.

Das Ergebnis prüfen

Öffne die Kategorieanzahlen, Fehler und Audit-Zeitleiste des Belegs. Eine abgeschlossene Aktion, eine gesperrte Kategorie und ein fehlgeschlagener Durchlauf haben unterschiedliche Ergebnisse. Halte diese Unterschiede im Fall fest. Zugehörige Admin-Ereignisse findest du in den Audit-Logs.