Personal information, identities, organization records, and support content handled according to their sensitivity — with minimization, erasure, and data-rights workflows.
| Classification | Typical Rumbe Data | Expected Handling |
|---|---|---|
| High | PII, PHI, credentials, authenticated identities, sensitive attachments | Encryption, restricted access, detailed auditing, controlled export and deletion workflows |
| Medium | Ticket metadata, operational summaries, organization settings, agent performance data | Tenant isolation, role-aware access, retention controls, activity logging |
| Low | Public widget styling, non-sensitive help content, public configuration | Integrity controls, tenant ownership, change tracking where appropriate |
Classification should be validated against the customer’s own data inventory and regulatory obligations.
User and agent identity records may include names, email addresses, company associations, roles, authentication state, and support-history references. These records should be treated as high-sensitivity personal data when they can identify or profile an individual.
Rumbe’s documented architecture includes encryption for PII-designated fields, tenant-aware access, RBAC, and audit logging.
Where implemented, blinded indexing can use an HMAC-derived lookup value rather than relying on a directly readable email address for every search operation. This enables deterministic lookup while reducing exposure of the underlying personal value in indexes.
HMAC-based lookup is not anonymization. The source value remains personal data when the system can associate the index with an identifiable record.
Rumbe’s architecture supports minimization by separating operational metadata, source documents, AI transaction hashes, and sensitive content. For example, an AI request can be represented in an audit trail by a SHA-256 hash rather than storing a second complete copy of its payload.
Customers should configure forms, prompts, attachments, retention, exports, and integrations to collect only the data required for the approved support purpose.
Structured deletedAt patterns can support staged deletion, restoration windows, and data-rights workflows. PII-heavy tables can be designed for targeted scrubbing or erasure without immediately destroying unrelated operational records.
Soft deletion alone does not complete a GDPR erasure request. A complete workflow may also need to address backups, logs, exports, attachments, third-party systems, legal holds, and processor instructions.
Commercial and legal handling should be coordinated through Vovance Inc. and the applicable customer contract.
Customers determine what information they collect, which knowledge sources they upload, which integrations they enable, how long data is retained, and which users receive access. They should maintain a data inventory, lawful basis, privacy notices, role assignments, deletion process, and incident response procedure.
Yes. The mapped architecture treats user identities, agent identities, and PII-heavy records as high-sensitivity data requiring elevated safeguards.
No. Soft deletion is an enabling pattern. Complete erasure may require handling database records, files, backups, exports, logs, and subprocessors.
No. It reduces direct exposure in an index but remains linked to personal data when the organization can resolve it to an individual.
Rumbe is designed to support GDPR-aligned access, correction, export, and erasure workflows. Legal compliance depends on documented procedures, contracts, and actual operation.
Vovance Inc. can discuss Rumbe AI’s architecture, available controls, deployment assumptions, and contractual options for your use case.