# New in 3.13.0 Rasa provides tools to help you manage personally identifiable information (PII) collected by your assistant. Rasa provides a comprehensive solution for managing personally identifiable information (PII) collected by your assistant. The PII management capability allows you to: - Identify and anonymize PII from slot events, user and bot messages. - Configure PII anonymization for specific slots. - Manage PII data retention policies in the tracker store. - Stream anonymized events to event brokers. Among supported event brokers are Kafka and RabbitMQ. ## PII Identification Rasa adopts a tiered approach to PII identification, which includes: 1. **Slot-based PII identification**: The sensitive data is stored in a slot whose name is defined in the `privacy` YAML config. This enables Rasa to use the existing [CALM slot filling](/content/docs/reference/primitives/slots/#calm-slot-mappings/index.html) mechanisms to identify PII in user messages, bot responses and [slot events](/content/docs/reference/primitives/events/#slot-event/index.html). To learn more about how to configure PII slots, see the [Anonymization Rules](/content/docs/reference/config/pii-management/configuring-pii-management/#anonymization-rules/index.html) section below. 2. **GLiNER PII identification**: Optional integration with [GLiNER PII model](https://huggingface.co/urchade/gliner_multi_pii-v1) to identify PII in two particular edge cases: - end chat user could be specifying some PII in their user message that is not captured by any domain slot. - usage of free text slots like problem description or customer notes that could have multiple types of PII. To learn more about how to configure GLiNER PII identification, see the [GLiNER requirements](/content/docs/reference/config/pii-management/prerequisites/#gliner-requirements/index.html) section below. ## PII Anonymization Rasa supports two types of PII anonymization: - **redaction**: replaces PII plaintext value with a redaction character (default is `*`) across the full length of the PII value. This anonymization method can be configured to keep N characters of the PII value to the left or right of the redaction character. For example, for a credit card number `1234-5678-9012-3456` and a redaction character `*` with `left=0` and `right=4`, the anonymized value would be `****-****-****-3456`. - **masking**: replaces PII plaintext value with the uppercase slot or entity name (e.g. `[EMAIL_ADDRESS]`). To learn more about how to configure PII anonymization, see the [Anonymization Rules](/content/docs/reference/config/pii-management/configuring-pii-management/#anonymization-rules/index.html) section below. ## Performance The PII management capability helps you comply with data protection regulations and ensure that sensitive user data is handled appropriately without compromising the functionality of your assistant. Rasa ensures that the PII management capability does not affect the performance of your assistant. ### PII Management Jobs The PII management jobs, such as publishing anonymized events to the supported event brokers, anonymization and deletion in the tracker store, are run in the background using a job scheduler. This allows your assistant to continue processing user requests without significant delays. When anonymization or deletion in the tracker store is configured, a [Lock Store](/content/docs/reference/integrations/lock-stores/index.html) is required. The background privacy manager acquires a per-`sender_id` lock while anonymization or deletion jobs perform read-modify-write on trackers, which prevents race conditions when multiple processes or jobs access the same conversation. Both anonymization and deletion use the tracker store's `update` method (deletion only when events need to be retained), so these operations complete in a single atomic operation on the [tracker store](/content/docs/reference/integrations/tracker-stores/index.html) (including SQL, which no longer uses a separate delete/save sequence). If you have configured both the anonymization and deletion jobs with overlapping cron triggers, Rasa ensures that both jobs are run sequentially to avoid a potential race condition in updating the tracker store. First the anonymization job is run, followed by the deletion job as long as the deletion job is due to run once the anonymization job is completed. ### Tracker Variants and Session Eligibility Privacy cron jobs (anonymization and deletion) process trackers according to how sessions are represented in events: - **Legacy trackers**: No `session_id` in any event metadata. They can contain multiple `ActionExecuted(action_session_start)` events (e.g. after session expiry a new session starts). Sessions are split by `action_session_start` first. Eligibility for anonymization or deletion is time-based using `LEGACY_DEFAULT_INACTIVITY_MINUTES` (30 minutes when `USER_CHAT_INACTIVITY_IN_MINUTES` is unset) plus `min_after_session_end`. - **New trackers**: Events have `session_id` in metadata. They have `ConversationInactive` after session timeout; a subset also have `SessionEnded`. Events are grouped by `session_id` (not split by `action_session_start`). A session is eligible for anonymization or deletion only if it contains `ConversationInactive` or `SessionEnded`; retention uses `min_after_session_end` after that event. - **Hybrid trackers**: A tracker can have both legacy events (no `session_id`) and new events (with `session_id`). Legacy events form a single prefix (all events before the >=3.16 rasa version upgrade); after the upgrade all new events have `session_id`. The legacy prefix is expanded via the same logic as legacy trackers (split by `action_session_start`), and each sub-session is evaluated individually; `session_id` runs are processed per run so reassembly preserves order. ### Deletion Cron Job The deletion cron job is responsible for deleting PII data from the tracker store, and it runs periodically based on the configured cron schedule. The deletion job removes PII data that is no longer needed, based on the configured retention period and the [session eligibility logic](/content/docs/reference/config/pii-management/overview/#tracker-variants-and-session-eligibility/index.html) above. It loops through conversation sessions in the tracker store (including trackers that contain multiple sessions, split or grouped as described for legacy, new, and hybrid trackers). A session is considered eligible for deletion when it has ended and the retention period has passed: - for event-based behavior (when `USER_CHAT_INACTIVITY_IN_MINUTES` is unset), sessions that contain `SessionEnded` use `min_after_session_end` after that event. - for legacy segments, 30 minutes plus `min_after_session_end`; when the env var is set, time-based eligibility (env var value + `min_after_session_end`) is applied per session but is deprecated.