- Home
- /
- Article
Data Residency in Webex Contact Center ensures that data is only held in memory during computation and is never stored outside its designated region. All persistent customer data (configuration, logs, etc.) remains within the specified region, and sub-processors operate under strict contractual, technical, and audit controls. Media and sensitive data are never retained after processing, and regional data residency and privacy requirements are strictly enforced. Knowledge management uses real-time updates to ensure content accuracy, with all data handling aligned to regulatory and security standards.
Key definitions
Some key definitions in this article include:
- Data Processing: The act of performing computational operations (such as transcription, inference, or synthesis) on customer data. No customer data is stored during processing; data exists only temporarily in volatile memory (RAM) and is purged immediately after processing is completed.
- Data Residency and Storage: Refers to where customer data is persistently stored (“at rest”). This includes configuration, tenant-specific settings, and stored logs.
- Media Residency: Media (such as audio streams) remain in their originating location for as long as possible and are not persistently moved or stored outside the region, even if processing occurs in another geography.
- Sub-processor: A third-party service provider engaged to perform specific functions (e.g., LLM inference, speech recognition) on customer data, under strict contractual and technical controls.
Data Processing vs. Data Residency
For customers operating in regulated regions such as Singapore, we distinguish between where data is stored (Residency) and where data is computed (Processing).
Regional Data Sovereignty
Regional data sovereignty ensures that customer data is managed in compliance with local regulations, specifying where data is stored and how it is handled during processing. The following principles apply:
- Data at Rest: All persistent customer data, including configuration, tenant-specific settings, and stored logs, is housed within the Singapore Region.
- Data in Transit: To leverage high-performance GPU clusters required for Large Language Models (LLMs) and Advanced Speech Recognition (ASR), data may be processed outside Singapore. However, processing means computation only: data is transmitted via encrypted TLS 1.2+ channels, exists only in RAM for the duration of processing, and is not stored at the processing location.
Media remains stored in its originating region as long as possible. Only transient processing occurs outside, based on organizational and service requirements.
Processing Locality Logic
We do not operate local LLM proxies in every geography to ensure:
- Security Parity: Centralized processing allows for immediate deployment of security patches and model guardrail enforcement.
- Resiliency: Global distribution prevents outages by rerouting inference requests if a local data center experiences an issue.
Data Residency for AI Agents in Webex Contact Center
Data residency for AI Agent components varies by region and service provider. The following table summarizes where data is processed and stored for key AI components across different AI Agent regions:
|
Region |
Data Processing (ASR / TTS / Core) |
Data Processing (LLM) |
Data Residency (Storage) |
|---|---|---|---|
|
produs1 (US) |
AWS: N. Virginia, N. California
Azure STT/TTS: East US, West US
Deepgram: N. Virginia, N. California
ElevenLabs: N. Virginia, N. California |
Azure Open AI: N. Virginia, N. California
LLM Proxy: N. Virginia, N. California |
US (Home DC) |
|
prodeu1 (UK) |
AWS: London, UK
Azure STT/TTS: UK South, South Africa North |
Azure Open AI: London, UK
LLM Proxy: London, UK |
UK (Home DC) |
|
prodeu2 (EU) |
AWS: Frankfurt, Germany
Azure STT/TTS: UAE North, Germany West Central |
Azure Open AI: Frankfurt, Germany
LLM Proxy: Frankfurt, Germany |
EU (Home DC) |
|
prodca1 (Canada) |
AWS: Canada Central
Azure STT/TTS: Global* |
Azure Open AI: Global*
LLM Proxy: Canada Central |
Canada (Home DC) |
|
prodjp1 (Japan) |
AWS: Tokyo, Japan
Azure STT/TTS: Global* |
Azure Open AI: Global*
LLM Proxy: Tokyo, Japan |
Japan (Home DC) |
|
prodanz1 (Australia) |
AWS: Sydney, Australia
Azure STT/TTS: Global* |
Azure Open AI: Global*
LLM Proxy: Sydney, Australia 31 |
Australia (Home DC) |
|
prodsg1 (Singapore) |
AWS: Singapore
Azure STT/TTS: Global* |
Azure Open AI: Global*
LLM Proxy: Sydney, Australia |
Singapore (Home DC) |
|
prodin1 (India) |
AWS: Mumbai, India
Azure STT/TTS: Central India |
Azure Open AI: Central India
LLM Proxy: Mumbai, India |
India (Home DC) |
*These requests can end up in any data center, globally, where these models are hosted. More information about Azure Data Residency can be found here.
Data Residency for AI Assistant in Webex Contact Center
Data residency for AI Assistant components varies by region and service provider. The following table summarizes where data is processed and stored for key AI Assistanct components across different AI regions:
|
Region |
AWS | Azure STT/TTS |
Voicea STT |
LLM Proxy (Internal) | Azure Open AI |
|---|---|---|---|---|---|
|
produs1 (US) |
N. Virginia, N. California | East US, West US | Global** |
N. Virginia, N. California |
N. Virginia, N. California |
|
prodeu1 (UK) |
London, UK
|
UK South, South Africa North | Global** |
London, UK |
London, UK |
|
prodeu2 (EU) |
Frankfurt, Germany |
UAE North, Germany West Central | Global** |
Frankfurt, Germany |
Frankfurt, Germany |
|
prodca1 (Canada) |
Canada Central | Global* | Global** |
Canada Central |
Global* |
|
prodjp1 (Japan) |
Tokyo, Japan | Global* | Global** |
Tokyo, Japan |
Global* |
|
prodanz1 (Australia) |
Sydney, Australia | Global* | Global** |
Sydney, Australia |
Global* |
|
prodsg1 (Singapore) |
Singapore | Global* | Global** |
Sydney, Australia |
Global* |
|
prodin1 (India) |
Asia Pacific (Mumbai), India | Central India | NA | Sydney, Australia | Sydney, Australia |
*These requests can end up in any data center, globally, where these models are hosted. More information about Azure Data Residency can be found here.
** Voicea resides in europe-west1/Brussels/Belgium and europe-west4/Amsterdam/Netherlands. Voicea does data processing only. No data is persisted on Voicea deployment sites.
Ephemeral Processing and Zero Retention
A fundamental aspect of our AI architecture is the commitment to ephemeral processing and zero data retention. Our approach prioritizes data privacy and security by ensuring that customer information is never stored or retained during AI operations.
- ASR & TTS Visibility: During real-time transcription (ASR) or speech synthesis (TTS), data exists only in the volatile memory (RAM) of the processing engine and is purged immediately after use. No data is stored or retained after processing.
- Access Control: No human employees (internal or sub-processor) have access to raw audio or text streams during the inference phase.
- No Secondary Usage: We maintain strict contractual and technical barriers to ensure customer data—including prompts and audio—is never used to train, retrain, or improve foundation models owned by sub-processors.
Sub-processor Governance (Voicea and LLM Providers)
We conduct rigorous third-party risk assessments on all sub-processors.
- Third-party Risk Assessments: All sub-processors undergo rigorous assessment.
- Encryption: Data sent to sub-processors is encrypted in transit, processed only in RAM, and never stored.
- Auditability: All API calls to sub-processors are logged for audit purposes (metadata only; sensitive payloads are excluded from logs).
- Incident Accountability: In the event of a data incident at a sub-processor, [Your Company] maintains primary accountability and handles all customer notifications and remediation per our standard Data Processing Addendum (DPA).
Data Retention and Lifecycle Management
To ensure transparency, the following table outlines exactly how long data is held within our ecosystem:
|
Data type |
Retention period (in Days) |
Storage status |
Purpose |
|---|---|---|---|
|
Real-time Audio/Transcript |
0 |
Not stored |
Purged immediately after the session ends. |
|
AI Agent Session History |
X |
Stored (SG) |
Provides context for multi turn conversations. |
|
Operational Logs |
90 |
Stored (SG) |
Troubleshooting and system health monitoring. |
|
Tenant Encryption Keys |
indefinite |
Stored (KMS) |
Customer-managed or system keys for data at rest. |
Knowledge Management and Content Accuracy
Our AI Assistant uses a Retrieval-Augmented Generation (RAG) architecture. This ensures the AI provides responses based on your specific "Ground Truth" documents rather than internal model training.
- URL/Document Updates: When a knowledge source is updated, the system re-indexes the content and replaces previous versions.
- Latency: Updated content typically reflects in the AI’s responses within [X] minutes.
- Cache Handling: Active sessions use the context available at the start of the session; however, all subsequent sessions are forced to query the most recent index, preventing the reuse of stale or "hallucinated" data.
Edge Case—If a specific regional regulation prohibits any processing outside the region, additional controls or local processing options may be required.
Important—"Processing" never implies data storage; all persistent data storage adheres strictly to regional residency rules.
ElevenLabs and Deepgram are used as EU-based sub-processors for certain speech and transcription tasks, always under strict contractual and technical controls, with zero data retention after processing.
Example scenario
A user in Singapore initiates a transcription session. The audio stream is processed in real-time by a global LLM hub via encrypted channels, but no audio or transcript is stored during or after processing outside Singapore. Only permitted context or logs (never the content itself) are retained as per the table above.