We are deploying a Dialogflow ES bot via the Genesys Cloud integration. As part of a SOC2 compliance review, I noticed that the entire conversation transcript between the caller and the bot is saved in plain text within the Genesys Cloud interaction history. If a caller randomly blurts out their credit card number or social security number to the bot (even if not prompted), it is logged permanently.
Is there a supported mechanism to intercept and redact PII from the bot transcript before it is committed to the Genesys Cloud database? I know we can redact audio, but the text transcript from the bot seems harder to filter pre-storage.
We use Dialogflow for our after-hours triage. The transcripts are passed directly from Google to Genesys via the integration connector. Genesys Cloud itself doesn’t have an inline text-redaction engine that intercepts that specific data stream before storage.
However, you can handle this on the Google side! Dialogflow has a feature called ‘DLP (Data Loss Prevention) Integration’. If you enable DLP in your Google Cloud project, you can configure it to automatically mask PII (like replacing credit cards with asterisks) in the Dialogflow payload before the response is sent back to the Genesys Bot Connector. That way, Genesys only ever receives and stores the redacted version.
Bia is spot on! We automate all our Dialogflow deployments via Terraform and turning on DLP is standard practice for us now.
Another angle if you aren’t using Dialogflow: If you use a custom bot via the generic Bot Connector API, you have to build that DLP filter into your own middleware. Your webhook receives the user’s utterance, you run it through a regex or AWS Comprehend Medical (if it’s healthcare), redact it, and then log that safe string instead. But if you’re using the native Dialogflow connector, Google’s DLP is definitely the easiest path.
As a warning for GDPR compliance, be careful with ‘Silent’ redaction if the bot actually needs that data to function.
If the user says ‘My account is 12345’, and DLP changes it to ‘My account is *****’, the bot intent matching might fail because it no longer sees the digits it expects for the Account_Number slot. You have to ensure that Dialogflow processes the raw input for slot filling first, and only applies the DLP mask to the transcript payload that gets sent to the fulfillment/logging layers. Google’s native DLP handles this correctly, but custom middleware often breaks routing if you redact too early in the pipeline.