- Головна
- /
- Стаття
Data Residency у Webex Contact Center гарантує, що дані зберігаються лише в пам'яті під час обчислень і ніколи не зберігаються поза визначеним регіоном. Усі постійні дані клієнтів (конфігурація, журнали тощо) залишаються в межах визначеного регіону, а субпроцесори працюють під суворим договірним, технічним та аудитським контролем. Медіа та конфіденційні дані ніколи не зберігаються після обробки, а вимоги щодо регіонального проживання та конфіденційності суворо дотримуються. Управління знаннями використовує оновлення в режимі реального часу для забезпечення точності контенту, при цьому вся обробка даних відповідає нормативним і безпековим стандартам.
Ключові визначення
Деякі ключові визначення в цій статті включають:
- Обробка даних: Виконання обчислювальних операцій (таких як транскрипція, висновки або синтез) над даними клієнта. Під час обробки не зберігаються дані клієнта; дані існують лише тимчасово у волатильній пам'яті (RAM) і видаляються одразу після завершення обробки.
- Резиденція та зберігання даних: Позначає місце, де дані клієнтів постійно зберігаються ("у стані спокою"). Це включає налаштування, специфічні для орендаря налаштування та збережені журнали.
- Медіарезиденція: Медіа (наприклад, аудіопотоки) залишаються у своєму початковому місці якомога довше і не постійно переміщуються чи зберігаються за межами регіону, навіть якщо обробка відбувається в іншій географії.
- Субпроцесор: Сторонній постачальник послуг, залучений для виконання конкретних функцій (наприклад, виведення LLM, розпізнавання мовлення) над даними клієнтів під суворим договірним і технічним контролем.
Обробка даних проти резиденції даних
Для клієнтів, які працюють у регульованих регіонах, таких як Сінгапур, ми розрізняємо місця зберігання даних (резидентство) і де обчислюються дані (обробка).
Регіональний суверенітет даних
Регіональний суверенітет даних гарантує, що дані клієнтів керуються відповідно до місцевих нормативів, визначаючи, де зберігаються дані та як вони обробляються під час обробки. Застосовуються такі принципи:
- Дані в стані спокою: Усі постійні дані клієнтів, включно з конфігурацією, специфічними для орендарів налаштуваннями та збереженими журналами, зберігаються в регіоні Сінгапуру.
- Дані в дорозі: Для використання високопродуктивних кластерів GPU, необхідних для великих мовних моделей (LLM) та розширеного розпізнавання мовлення (ASR), дані можуть оброблятися поза межами Сінгапуру. Однак обробка означає лише обчислення: дані передаються через зашифровані канали TLS 1.2+, існують лише в оперативній пам'яті протягом усього часу обробки і не зберігаються на місці обробки.
Медіа зберігаються у своєму вихідному регіоні якомога довше. Лише тимчасова обробка відбувається поза межами, залежно від організаційних та сервісних вимог.
Логіка локальності обробки
Ми не використовуємо локальні проксі LLM у всіх регіонах для забезпечення:
- Паритет безпеки: Централізована обробка дозволяє негайно впроваджувати патчі безпеки та забезпечувати контроль моделей.
- Стійкість: Глобальне розповсюдження запобігає збоїв, перенаправляючи запити на висновки, якщо локальний дата-центр стикається з проблемою.
Резиденція даних для AI-агентів у Webex Contact Center
Резиденція даних для компонентів AI-агентів залежить від регіону та провайдера послуг. Наступна таблиця підсумовує, де обробляються та зберігаються дані для ключових компонентів ШІ в різних регіонах агентів ШІ:
|
Регіон |
Обробка даних (ASR / TTS / Core) |
Обробка даних (LLM) |
Резиденція даних (зберігання) |
|---|---|---|---|
|
produs1 (США) |
AWS: Північна Вірджинія, Північна Каліфорнія
Azure STT/TTS: East US, West US
Діпграм: Північна Вірджинія, Північна Каліфорнія
ElevenLabs: Північна Вірджинія, Північна Каліфорнія |
Azure Open AI: N. Virginia, N. California
LLM Проксі: Північна Вірджинія, Північна Каліфорнія |
США (Home DC) |
|
prodeu1 (Велика Британія) |
AWS: Лондон, Великобританія
Azure STT/TTS: UK Південь, Південна Африка Північ |
Azure Open AI: London, UK
LLM проксі: Лондон, Великобританія |
Велика Британія (Home DC) |
|
prodeu2 (ЄС) |
AWS: Франкфурт, Німеччина
Azure STT/TTS: UAE North, Germany West Central |
Azure Open AI: Frankfurt, Germany
LLM Проксі: Франкфурт, Німеччина |
EU (Home DC) |
|
prodca1 (Канада) |
AWS: Центральна Канада
Azure STT/TTS: Global* |
Azure Open AI: Global*
LLM Proxy: Canada Central |
Канада (Home DC) |
|
prodjp1 (Японія) |
AWS: Токіо, Японія
Azure STT/TTS: Global* |
Azure Open AI: Global*
LLM Proxy: Токіо, Японія |
Японія (Home DC) |
|
prodanz1 (Австралія) |
AWS: Сідней, Австралія
Azure STT/TTS: Global* |
Azure Open AI: Global*
LLM Проксі: Сідней, Австралія 31 |
Австралія (Home DC) |
|
prodsg1 (Сінгапур) |
AWS: Сінгапур
Azure STT/TTS: Global* |
Azure Open AI: Global*
LLM проксі: Сідней, Австралія |
Сінгапур (Home DC) |
|
prodin1 (Індія) |
AWS: Мумбаї, Індія
Azure STT/TTS: Central India |
Azure Open AI: Central India
LLM проксі: Мумбаї, Індія |
Індія (Home DC) |
*Ці запити можуть потрапити в будь-який дата-центр по всьому світу, де розміщені ці моделі. Більше інформації про Azure Data Residency можна знайти тут.
Data Residency for AI Assistant у Webex Contact Center
Резиденція даних для компонентів AI Assistant залежить від регіону та постачальника послуг. Наступна таблиця узагальнює, де обробляються та зберігаються дані для ключових компонентів AI Assistanct у різних регіонах ШІ:
|
Регіон |
AWS | Azure STT/TTS |
Voicea STT |
Проксі LLM (внутрішня) | Azure Open AI |
|---|---|---|---|---|---|
|
produs1 (США) |
Північна Вірджинія, Північна Каліфорнія | Схід США, Захід США | Global** |
Північна Вірджинія, Північна Каліфорнія |
Північна Вірджинія, Північна Каліфорнія |
|
prodeu1 (Велика Британія) |
Лондон, Великобританія
|
Велика Британія Південь, Південна Африка Північ | Global** |
Лондон, Великобританія |
Лондон, Великобританія |
|
prodeu2 (ЄС) |
Франкфурт, Німеччина |
ОАЕ Північ, Німеччина Західна Центральна | Global** |
Франкфурт, Німеччина |
Франкфурт, Німеччина |
|
prodca1 (Канада) |
Канада Центральна | Global* | Global** |
Канада Центральна |
Global* |
|
prodjp1 (Японія) |
Токіо, Японія | Global* | Global** |
Токіо, Японія |
Global* |
|
prodanz1 (Австралія) |
Сідней, Австралія | Global* | Global** |
Сідней, Австралія |
Global* |
|
prodsg1 (Сінгапур) |
Сінгапур | Global* | Global** |
Сідней, Австралія |
Global* |
|
prodin1 (Індія) |
Азіатсько-Тихоокеанський регіон (Мумбаї), Індія | Центральна Індія | Немає даних | Сідней, Австралія | Сідней, Австралія |
*Ці запити можуть потрапити в будь-який дата-центр по всьому світу, де розміщені ці моделі. Більше інформації про Azure Data Residency можна знайти тут.
** Voicea проживає в Європі-Захід1/Брюсселі/Бельгії та європі-захід4/Амстердамі/Нідерландах. Voicea займається лише обробкою даних. Дані не зберігаються на сайтах розгортання Voicea.
Ефемерна обробка та нульове утримання
Фундаментальним аспектом нашої архітектури ШІ є відданість тимчасовій обробці та нульовому збереженню даних. Наш підхід ставить у пріоритет конфіденційність і безпеку даних, гарантуючи, що інформація клієнтів ніколи не зберігається і не зберігається під час операцій з ШІ.
- Видимість ASR та TTS: Під час транскрипції в реальному часі (ASR) або синтезі мовлення (TTS) дані зберігаються лише у енергостабільній пам'яті (RAM) процесорного рушія і видаляються одразу після використання. Після обробки жодні дані не зберігаються і не зберігаються.
- Контроль доступу: жоден працівник (внутрішнього чи підпроцесорного) не має доступу до сирих аудіо- або текстових потоків під час фази виведення.
- Відсутність вторинного використання: Ми підтримуємо суворі договірні та технічні бар'єри, щоб гарантувати, що дані клієнтів — включно з підказками та аудіо — ніколи не використовуються для навчання, перенавчання чи покращення базових моделей, що належать субпроцесорам.
Управління субпроцесорами (провайдери Voicea та LLM)
Ми проводимо ретельні оцінки ризиків від третіх сторін для всіх субпроцесорів.
- Оцінка ризиків третіх сторін: Усі субпроцесори проходять ретельну оцінку.
- Шифрування: Дані, що надсилаються субпроцесорам, шифруються під час транспортування, обробляються лише в оперативній пам'яті і ніколи не зберігаються.
- Аудитуваність: Усі виклики API до субпроцесорів реєструються для цілей аудиту (лише метадані; чутливі корисні навантаження виключаються з журналів).
- Відповідальність за інциденти: У разі інциденту з даними на субпроцесорі [Ваша компанія] несе основну відповідальність і здійснює всі сповіщення клієнтів та усунення відповідно до нашого стандартного додатку до обробки даних (DPA).
Збереження даних і управління життєвим циклом
Для забезпечення прозорості наступна таблиця точно показує, як довго дані зберігаються в нашій екосистемі:
|
Тип даних |
Період утримання (у днях) |
Стан зберігання |
Призначення |
|---|---|---|---|
|
Аудіо/транскрипт у реальному часі |
0 |
Не зберігається |
Відразу після завершення сесії його очищають. |
|
Історія сесій агента ШІ |
X |
Збережено (SG) |
Надає контекст для мульти TURN розмов. |
|
Журнали експлуатації |
90 |
Збережено (SG) |
Діагностика несправностей і моніторинг стану системи. |
|
Ключі шифрування орендаря |
невизначений |
Збережені (KMS) |
Керовані клієнтом або системні ключі для даних у стані спокою. |
Управління знаннями та точність контенту
Наш AI Assistant використовує архітектуру Retrieval-Augmented Generation (RAG ). Це гарантує, що ШІ надає відповіді на основі ваших конкретних документів «Ground Truth», а не внутрішнього навчання моделі.
- URL/Оновлення документів: Коли джерело знань оновлюється, система повторно індексує вміст і замінює попередні версії.
- Затримка: Оновлений контент зазвичай відображається у відповідях ШІ протягом [X] хвилин.
- Обробка кешу: Активні сесії використовують контекст, доступний на початку сесії; однак усі наступні сесії змушені звертатися до найсвіжішого індексу, що запобігає повторному використанню застарілих або «галюцинованих» даних.
Крайній випадок — якщо певне регіональне регулювання забороняє обробку за межами регіону, можуть знадобитися додаткові контролі або локальні варіанти обробки.
Важливо — «Обробка» ніколи не передбачає зберігання даних; Усе постійне зберігання даних суворо дотримується регіональних правил проживання.
ElevenLabs і Deepgram використовуються як субпроцесори на базі ЄС для певних завдань мовлення та транскрипції, завжди під суворим договірним і технічним контролем, без жодного збереження даних після обробки.
Приклад сценарію
Користувач у Сінгапурі ініціює сесію транскрипції. Аудіопотік обробляється в реальному часі глобальним LLM-хабом через зашифровані канали, але жоден аудіо чи транскрипт не зберігаються під час чи після обробки поза межами Сінгапуру. Зберігаються лише дозволений контекст або журнали (ніколи сам вміст), як зазначено в таблиці вище.