> ## Documentation Index
> Fetch the complete documentation index at: https://docs.operata.com/llms.txt
> Use this file to discover all available pages before exploring further.

# PII in Operata

> What counts as personally identifiable information in the data Operata collects, and how redaction at the edge controls what leaves your environment.

Personally identifiable information (PII) in Operata is any field on a contact record that can identify a real person — phone numbers, agent names, custom attributes carrying customer data — and you decide which of those fields leave your environment by configuring redaction at the edge of your AWS account.

## How it works

The data Operata ingests carries PII in three places:

* **Contact metadata** — customer phone numbers, queue names, custom attributes set by your flows, and any other field on the Amazon Connect Contact Trace Record (CTR) or the Genesys Cloud / NICE CXOne equivalents.
* **Agent context** — agent usernames, machine identifiers, and any account-level attributes you map to agents.
* **Conversational content** — Contact Lens transcripts and sentiment fields, Amazon Lex slot values, and contact-flow log entries.

Operata does not see any of these fields until they leave your environment. Redaction runs at the edge of your AWS account through the [Cloud Collector](/docs/concepts-cloud-collector), so the fields you redact never reach Operata in the first place. There is no Operata-side "delete PII" step — if a field is in the payload Operata received, the field is stored.

The redaction model is allow-list or deny-list per field path. You configure it through the [redaction API](/docs/api-data-redaction) and apply it to one or more sources: CTRs, Contact Lens, contact-flow logs, and Lex events.

## Why redaction runs at the edge

Redacting at the edge means your AWS account remains the boundary of PII control. Operata cannot accidentally store fields it never received, audits are simpler (the redaction config is the single source of truth for what crosses the boundary), and the contract is reversible — change the config, and the next CTR honors the new rules.

The allow-list and deny-list shape is deliberate: a deny-list is easy to start with ("don't send me phone numbers"), an allow-list is the safer default for high-regulation tenants ("send only the fields I name"). Both compile to the same execution.

## Related

* [Privacy and redaction](/docs/concepts-privacy-and-redaction) — the model behind redaction across all sources.
* [Cloud Collector](/docs/concepts-cloud-collector) — where redaction runs.
* [Get redaction config](/docs/api-get-redaction-config) — read the current allow/deny rules for a source.
* [Update redaction config](/docs/api-update-redaction-config) — change the rules. Idempotent.
* [Delete redaction config](/docs/api-delete-redaction-config) — remove rules for a source.
* [Configure CTR redaction](/docs/guides-configure-ctr-redaction) — the redaction guide for Amazon Connect.
* [Configure Genesys redaction](/docs/guides-configure-genesys-redaction) — the redaction guide for Genesys Cloud.