Configuration Overview
To configure PII management in your Rasa project, you need to define theprivacy YAML config in your endpoints YAML configuration.
This configuration includes settings for tracker store PII management and anonymization rules.
For example, you can define the following privacy configuration in your endpoints.yml file:
endpoints.yml
Tracker Store Configuration
When you configure tracker store anonymization or deletion, you must configure a Lock Store. The background privacy manager requires a lock store and acquires a per-sender_id lock during anonymization and deletion jobs to avoid race conditions when reading and writing trackers.
Both anonymization and deletion use update() on the tracker store (deletion only when events need to be retained), so these operations complete in a single atomic operation (no separate delete-then-save).
The tracker_store_settings section allows you to configure PII management for the tracker store, including deletion and anonymization settings:
deletion: This section allows you to configure the deletion of PII data from the tracker store.min_after_session_end: The minimum number of minutes after which the session data is deleted from the tracker store. Must be greater than themin_after_session_endvalue in theanonymizationsection. WhenUSER_CHAT_INACTIVITY_IN_MINUTESis unset, eligibility is event-based (see Tracker variants and session eligibility); when set, it must be greater than the env value (time-based behavior is deprecated and applied per session).cron: The cron expression that defines when the deletion job should run. In the example, the job will run every day at 00:30 UTC. Must be different from thecronexpression in theanonymizationsection.
anonymization: This section allows you to configure the anonymization of PII data in the tracker store.min_after_session_end: The minimum number of minutes after which the session data is anonymized in the tracker store (grace period after session end). Must be less than themin_after_session_endvalue in thedeletionsection. WhenUSER_CHAT_INACTIVITY_IN_MINUTESis unset, eligibility is event-based; when set, it must be greater than the env value (time-based behavior is deprecated per session).cron: The cron expression that defines when the anonymization job should run. In the example, the job will run every day at 01:30 UTC. Must be different from thecronexpression in thedeletionsection.
deletion and anonymization sections are optional, and you can configure either or both of them based on your requirements.
If you do decide to configure them, you must provide both min_after_session_end and cron settings.
Anonymization Rules
Therules section allows you to define specific anonymization rules for slots that contain PII data.
slot: The name of the slot that contains PII data.anonymization: The anonymization method to be applied to the slot value.type: The type of anonymization, eitherredactormask.redaction_char: The character used for redaction (only applicable forredacttype).keep_left: The number of characters to keep to the left of the redaction character (default is0).keep_right: The number of characters to keep to the right of the redaction character (default is0).
Event Broker Configuration
You can also configure the event broker to stream anonymized events to dedicated topics or queues. The supported event broker types are Kafka and RabbitMQ, you can learn more about how to configure the streaming of anonymized events in the Kafka Event Broker documentation and RabbitMQ Event Broker documentation.Integrating with Consent Management Platforms
Rasa does not provide a built-in consent management platform (CMP) for managing user consent and PII data compliance. However, you can integrate Rasa with leading third-party CMPs like OneTrust, Usercentrics, Cookiebot, and CookieYes among others, to ensure GDPR, CCPA, and other privacy regulation compliance within your conversational AI workflows. You can implement this integration through a custom action that interacts with the CMP API. This custom action can check if the user has provided consent for PII data collection or can store the consent to the CMP if the consent was collected via a custom flow. Here’s an example for when you want to retrieve the consent status of a user id from the CMP API:- Create custom actions that interact with CMP APIs to store, retrieve and validate user consent:
actions.py
- Use consent information in flows to branch off conversation logic:
domain.yml