Nebuly Anonymization Module

Nebuly is built with a privacy-first architecture. Personal and sensitive information can be removed or pseudonymized before downstream analytics are performed, allowing Nebuly to analyze AI usage while minimizing exposure of identifying information. Nebuly is designed to analyze patterns across AI interactions rather than evaluate individuals. It does not require employee identity records to perform its analytics and is not designed to produce individual employee performance scores, rankings, or profiles. Anonymization is handled by the Nebuly Anonymization Module (NAM), which combines deterministic pattern-based detection with contextual AI-based detection. Customers can also anonymize data before sending it to Nebuly, adding an additional layer of protection.

​

Where anonymization happens

Conversation data enters Nebuly through the Interaction API. PII handling takes place before downstream analytics. At a high level, the processing pipeline is:

1. PII removal and anonymization
2. Enrichment — including intent, topic, sentiment, implicit feedback, and keywords
3. Clustering and analytics — higher-level patterns across interactions

Because PII handling happens before enrichment and clustering, downstream analytics can operate on cleaned, non-identifying content.

​

Nebuly Anonymization Module

The Nebuly Anonymization Module (NAM) is a real-time processing component integrated into the Nebuly deployment. It combines two complementary detection mechanisms:

• Pattern-based detection for structured identifiers that can be recognized deterministically.
• AI-based contextual detection for personal or confidential information that requires understanding the surrounding text.

The PII removal module can be used within Nebuly to sanitize interactions and can also be used as a standalone component.

​

Pattern-based detection

Nebuly uses regular expressions to identify structured forms of sensitive information and replace them with typed placeholders. Default and configurable rules can cover identifiers such as:

• Email addresses
• Phone numbers
• Credit card numbers
• IBANs
• Medical license identifiers
• US ITINs
• US passport numbers
• US Social Security Numbers
• Other customer-specific structured identifiers

Regex rules are deterministic and can be extended with additional patterns to meet customer requirements. For ingestion-time protections configured in NAM, structured identifiers can be removed before the interaction is persisted to downstream Nebuly storage and message-processing systems.

​

AI-based contextual detection

Pattern matching alone cannot reliably detect all sensitive information. Nebuly therefore also uses a custom-trained language model to identify contextual and unstructured information. By default, the model can detect categories including:

• PERSON — names and surnames, including partial names, initials, misspellings, and names embedded in longer strings
• EMAIL_ADDRESS — including malformed or non-standard email formats
• IBAN_CODE
• CREDIT_CARD
• MEDICAL_LICENSE
• PHONE_NUMBER
• US_ITIN
• US_PASSPORT
• US_SSN
• LOCATION — including addresses, cities, regions, landmarks, and partial locations
• DATE — including standard, informal, and ambiguous date expressions

Because detection is contextual rather than based only on strict formatting, the model can identify information even when users introduce typos, unusual spacing, or other variations. In self-hosted deployments, the model runs locally within the customer’s environment. NAM produces a structured mask that Nebuly uses when rendering anonymized content in the platform.

​

Custom sensitive entities

Different organizations have different definitions of what must be considered sensitive. Nebuly’s contextual detection is therefore configurable and extendable during setup. Customers can define additional entities by providing a clear definition and representative examples. Examples include:

• IT_FISCAL_CODE — Italian Codice Fiscale
• IT_COMPANY_NAME — company names and legal entities
• IT_INVOICE_CODE — invoice and SDI identifiers
• PAYROLL — salaries, bonuses, compensation, payroll IDs, and payslip information
• FINANCIAL_CONFIDENTIAL — confidential revenue, margin, or internal financial information
• SOURCE_CODE_SNIPPETS — proprietary source code, configuration, or credentials
• Competitor names
• Geography-specific identifiers
• Other customer-defined confidential information

Detection categories can be configured with additional validation and deny-list controls to help manage false positives.

​

Customer-side anonymization

Organizations can anonymize or redact data before it reaches Nebuly. This creates an additional customer-controlled layer in front of Nebuly’s own anonymization. It is particularly useful for organizations that already operate an internal sanitization pipeline or have policies requiring confidential information to be removed at the source. In this setup:

1. The customer sanitizes the original conversation data.
2. The sanitized interaction is sent to Nebuly.
3. Nebuly’s configured anonymization controls provide an additional layer of protection.

​

Per-interaction privacy controls

The Interaction API provides privacy controls that can be applied to individual interactions.

​

anonymize

Use anonymize = true to enable PII anonymization for an interaction. Nebuly detects sensitive information and renders cleaned, non-identifying content for downstream use in the platform.

​

hide_content

Use hide_content = true when the full interaction content should not be visible in the Nebuly UI. Nebuly can still compute analytics on the interaction, while its content is hidden from users of the platform. These controls address different requirements and can be combined:

• anonymize removes or masks sensitive information.
• hide_content controls whether interaction content is visible.

​

User pseudonymization

User identifiers do not need to be sent to Nebuly in their original form. Customers can hash user IDs before sending them to Nebuly. Nebuly can then hash those identifiers again, creating a double-hashing scheme. This provides a stable identifier for aggregate analytics while reducing the ability to recover the original user identity, including for someone who has access to the customer-side hashing keys.

​

Access to conversation content

Anonymization is complemented by access controls governing who can view conversation data. Nebuly supports:

• Role-Based Access Control (RBAC)
• Single Sign-On (SSO) with Microsoft Entra ID, Okta, and Google
• Project-level permissions
• Identity-provider group scoping

Conversation content can be masked in the UI and made available only to users with the appropriate permissions. For more information, see Permissions and user management.

​

Self-hosted deployments

For organizations with strict data-residency or security requirements, Nebuly can be deployed entirely inside the customer’s infrastructure. Supported environments include:

• Microsoft Azure
• AWS
• GCP
• On-premises Kubernetes deployments

In a self-hosted deployment, conversational data remains inside the customer’s environment. Nebuly’s AI processing, including contextual anonymization, runs locally without sending conversation content to third-party AI providers. See Deployment modes for more information.

​

Data retention and deletion

Nebuly follows a data-minimization approach: customers choose what information to send through the Interaction API, typically including:

• User input
• AI output
• Conversation ID
• Optional metadata and tags
• Optional pseudonymized user identifiers

Data retention is configurable, and retention can be applied as part of the processing pipeline. Project administrators can delete project records when required.

​

Encryption

Nebuly protects data both in transit and at rest. In transit, communications use TLS and application traffic is served over HTTPS. At rest, conversational data, primary storage, and backups are encrypted using AES-256 with cloud-provider managed key services and access controls.