I denne artikkelen
Viktige definisjoner
dropdown icon
Databehandling vs. datalagring
    Regional datasuverenitet
    Behandler lokalitetslogikk
    Datalagring for AI-agenter i Webex Contact Center
    Data Residency for AI Assistant i Webex Contact Center
Flyktig behandling og null oppbevaring
Styring av underdatabehandlere (Voicea- og LLM-leverandører)
Dataoppbevaring og livssyklusadministrasjon
dropdown icon
Kunnskapshåndtering og innholdsnøyaktighet
    Eksempel på scenario
Datasikkerhet, personvern og bosted i Webex Contact Center
list-menuI denne artikkelen
list-menuTilbakemelding?

Datalagring i Webex Contact Center sikrer at data bare holdes i minnet under beregning og aldri lagres utenfor det angitte området. Alle vedvarende kundedata (konfigurasjon, logger osv.) forblir innenfor den angitte regionen, og underbehandlere opererer under strenge kontraktsmessige, tekniske og revisjonskontroller. Media og sensitive data beholdes aldri etter behandling, og regionale krav til datalagring og personvern håndheves strengt. Knowledge Management bruker oppdateringer i sanntid for å sikre nøyaktig innhold, og all databehandling er justert etter forskriftsmessige standarder og sikkerhetsstandarder.

Viktige definisjoner

Noen viktige definisjoner i denne artikkelen inkluderer:

  • Databehandling: Handlingen med å utføre beregningsoperasjoner (for eksempel transkripsjon, inferens eller syntese) på kundedata. Ingen kundedata lagres under behandlingen; Data finnes bare midlertidig i flyktig minne (RAM) og fjernes umiddelbart etter at behandlingen er fullført.
  • Datalagring og lagring: Henviser til hvor kundedata lagres vedvarende ("i ro"). Dette inkluderer konfigurasjon, leierspesifikke innstillinger og lagrede logger.
  • Medieopphold: Medier (for eksempel lydstrømmer) forblir på sitt opprinnelige sted så lenge som mulig og flyttes ikke vedvarende eller lagres utenfor regionen, selv om behandlingen skjer i en annen geografi.
  • Underprosessor: En tredjeparts tjenesteleverandør engasjert for å utføre spesifikke funksjoner (f.eks. LLM-slutning, talegjenkjenning) på kundedata, under strenge kontraktsmessige og tekniske kontroller.

Databehandling vs. datalagring

For kunder som opererer i regulerte regioner som Singapore, skiller vi mellom hvor data lagres (Bosted) og hvor data beregnes (behandling).

Regional datasuverenitet

Regional datasuverenitet sikrer at kundedata administreres i samsvar med lokale forskrifter, og spesifiserer hvor data lagres og hvordan de håndteres under behandlingen. Følgende prinsipper gjelder:

  • Data i hvile: Alle faste kundedata, inkludert konfigurasjon, leierspesifikke innstillinger og lagrede logger, lagres i Singapore-regionen.
  • Data under overføring: For å utnytte GPU-klynger med høy ytelse som kreves for store språkmodeller (LLM-er) og avansert talegjenkjenning (ASR), kan data behandles utenfor Singapore. Behandling betyr imidlertid bare beregning: data overføres via krypterte TLS 1.2+ kanaler, eksisterer bare i RAM i løpet av behandlingen, og lagres ikke på behandlingsstedet.

Media forblir lagret i sin opprinnelsesregion så lenge som mulig. Bare forbigående behandling skjer utenfor, basert på organisatoriske og tjenestekrav.

Behandler lokalitetslogikk

Vi driver ikke lokale LLM-proxyer i alle geografier for å sikre:

  • Sikkerhetsparitet: Sentralisert behandling muliggjør umiddelbar distribusjon av sikkerhetsoppdateringer og modellbeskyttelseshåndhevelse.
  • Robusthet: Global distribusjon forhindrer avbrudd ved å omdirigere slutningsforespørsler hvis et lokalt datasenter opplever et problem.

Datalagring for AI-agenter i Webex Contact Center

Datalagring for AI-agentkomponenter varierer etter region og tjenesteleverandør. Tabellen nedenfor oppsummerer hvor data behandles og lagres for viktige AI-komponenter på tvers av ulike AI-agentområder:

Regionen

Databehandling (ÅSR / TTS / Core)

Databehandling (LLM)

Datalagring (lagring)

produs1 (US)

AWS: N. Virginia, N. California

Azure STT/TTS: USA, øst, USA, vest

Deepgram: N. Virginia, N. California

ElleveLabs: N. Virginia, N. California

Azure Open AI: N. Virginia, N. California

LLM Proxy: N. Virginia, N. California

USA (Home DC)

prodeu1 (Storbritannia)

AWS: London, Storbritannia

Azure STT/TTS: Storbritannia, sør, Sør-Afrika, nord

Azure Open AI: London, Storbritannia

LLM Proxy: London, Storbritannia

Storbritannia (Home DC)

prodeu2 (EU)

AWS: Frankfurt, Tyskland

Azure STT/TTS: UAE, nord, Tyskland, vest, sentralt

Azure Open AI: Frankfurt, Tyskland

LLM Proxy: Frankfurt, Tyskland

EU (Home DC)

prodca1 (Canada)

AWS: Canada sentralt

Azure STT/TTS: Global*

Azure Open AI: Global*

LLM Proxy: Canada sentrale

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: Sentral-India

Azure Open AI: Sentral-India

LLM Proxy: Mumbai, India

India (Home DC)

*Disse forespørslene kan ende opp i et hvilket som helst datasenter, globalt, der disse modellene driftes. Du finner mer informasjon om Azure Data Residency her.

Data Residency for AI Assistant i Webex Contact Center

Datalagring for AI Assistant-komponenter varierer etter region og tjenesteleverandør. Tabellen nedenfor oppsummerer hvor data behandles og lagres for viktige AI Assistanct-komponenter på tvers av ulike AI-områder:

Regionen

AWS

Azure STT/TTS

Voicea STT

LLM Proxy (intern)

Azure Open AI

produs1 (US)

N. Virginia, N. California USA, øst, USA, vest Global**

N. Virginia, N. California

N. Virginia, N. California

prodeu1 (Storbritannia)

London, Storbritannia

Storbritannia, sør, Sør-Afrika, nord Global**

London, Storbritannia

London, Storbritannia

prodeu2 (EU)

Frankfurt, Tyskland

De forente arabiske emirater, nord, Tyskland, det vestre Midtvesten Global**

Frankfurt, Tyskland

Frankfurt, Tyskland

prodca1 (Canada)

Sentral-Canada Global* Global**

Sentral-Canada

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/Stillehavsområdet (Mumbai), India Sentral-India Ikke tilgjengelig Sydney, Australia Sydney, Australia

*Disse forespørslene kan ende opp i et hvilket som helst datasenter, globalt, der disse modellene driftes. Du finner mer informasjon om Azure Data Residency her.

** Voicea ligger i Europa-vest1/Brussel/Belgia og Europa-vest4/Amsterdam/Nederland. Voicea gjør kun databehandling. Ingen data beholdes på Voicea-distribusjonssteder.

Flyktig behandling og null oppbevaring

Et grunnleggende aspekt ved vår AI-arkitektur er forpliktelsen til flyktig behandling og null datalagring. Vår tilnærming prioriterer personvern og sikkerhet ved å sikre at kundeinformasjon aldri lagres eller beholdes under AI-operasjoner.

  • ASR &; TTS-synlighet: Under sanntidstranskripsjon (ASR) eller talesyntese (TTS) finnes data bare i behandlingsmotorens flyktige minne (RAM) og fjernes umiddelbart etter bruk. Ingen data lagres eller beholdes etter behandling.
  • Tilgangskontroll: Ingen menneskelige ansatte (interne eller underprosessorer) har tilgang til rå lyd- eller tekststrømmer i slutningsfasen.
  • Ingen sekundær bruk: Vi opprettholder strenge kontraktsmessige og tekniske barrierer for å sikre at kundedata - inkludert ledetekster og lyd - aldri brukes til å lære, omskolere eller forbedre fundamentmodeller som eies av underprosessorer.

Styring av underdatabehandlere (Voicea- og LLM-leverandører)

Vi gjennomfører strenge risikovurderinger av tredjeparter på alle underbehandlere.

  • Tredjeparts risikovurderinger: Alle underprosessorer gjennomgår en grundig vurdering.
  • Kryptering: Data som sendes til underprosessorer krypteres under overføring, behandles bare i RAM og lagres aldri.
  • Revisjon: Alle API-anrop til underbehandlere logges for revisjonsformål (bare metadata; sensitiv nyttelast er ekskludert fra logger).
  • Hendelsesansvar: I tilfelle en datahendelse hos en underbehandler, opprettholder [din bedrift] hovedansvaret og håndterer alle kundevarsler og utbedringer i henhold til vårt standard databehandlingstillegg (DPA).

Dataoppbevaring og livssyklusadministrasjon

For å sikre åpenhet viser følgende tabell nøyaktig hvor lenge data oppbevares i økosystemet vårt:

Datatype

Oppbevaringsperiode (i dager)

Lagringsstatus

Formål

Lyd/transkripsjon i sanntid

0

Ikke lagret

Purged umiddelbart etter at økten er avsluttet.

AI-agentøkthistorikk

X

Lagret (SG)

Gir kontekst for flere TURN samtaler.

Driftslogger

90

Lagret (SG)

Feilsøking og overvåking av systemtilstand.

Krypteringsnøkler for leier

Ubestemt

Lagret (KMS)

Kundeadministrerte nøkler eller systemnøkler for inaktive data.

Kunnskapshåndtering og innholdsnøyaktighet

Vår AI Assistant bruker en Retrieval-Augmented Generation (RAG) arkitektur. Dette sikrer at AI gir svar basert på dine spesifikke "Ground Truth" -dokumenter i stedet for intern modellopplæring.

  • URL-/dokumentoppdateringer: Når en kunnskapskilde oppdateres, indekserer systemet innholdet på nytt og erstatter tidligere versjoner.
  • Ventetid: Oppdatert innhold gjenspeiles vanligvis i AI-svarene innen [X] minutter.
  • Håndtering av hurtigbuffer: Aktive økter bruker konteksten som er tilgjengelig ved starten av økten, men alle påfølgende økter blir tvunget til å spørre etter den nyeste indeksen, noe som forhindrer gjenbruk av foreldede eller "hallusinerte" data.

Edge Case - Hvis en bestemt regional forskrift forbyr behandling utenfor regionen, kan det være nødvendig med ytterligere kontroller eller lokale behandlingsalternativer.

Viktig – «behandling» innebærer aldri datalagring. All vedvarende datalagring overholder strenge regionale bostedsregler.

ElevenLabs og Deepgram brukes som EU-baserte underprosessorer for visse tale- og transkripsjonsoppgaver, alltid under strenge kontraktsmessige og tekniske kontroller, med null dataoppbevaring etter behandling.

Eksempel på scenario

En bruker i Singapore starter en transkripsjonsøkt. Lydstrømmen behandles i sanntid av et globalt LLM-knutepunkt via krypterte kanaler, men ingen lyd eller transkripsjon lagres under eller etter behandling utenfor Singapore. Bare tillatt kontekst eller logger (aldri selve innholdet) beholdes i henhold til tabellen ovenfor.

Var denne artikkelen nyttig?
Var denne artikkelen nyttig?