Trust center
Sicurezza, conformità e gestione dei dati in DialerBee
La piattaforma di contact center con IA, con isolamento multi-tenant, conformità default-deny, audit trail append-only e pratiche trasparenti sui dati dell'IA. Costruita per i settori regolamentati.
Risposta rapida
Come gestisce DialerBee sicurezza e conformità? DialerBee offre una sicurezza di livello enterprise con crittografia AES-256, Row-Level Security di PostgreSQL per l'isolamento multi-tenant, log di audit append-only e controlli di conformità default-deny per TCPA, GDPR, TDRA, CST e altro. Il single sign-on è disponibile tramite OIDC e SAML, con il provisioning degli utenti SCIM, e l'accesso a due fattori, una allow-list di IP e il timeout di inattività proteggono ogni login. Le funzionalità di IA sono opzionali, disattivate per impostazione predefinita, e i dati dei clienti non vengono mai usati per addestrare modelli condivisi.
Sicurezza
Difesa in profondità, non difesa sulla speranza
Ogni livello dello stack è protetto. L'isolamento dei tenant viene convalidato tramite test automatizzati e processi di revisione della sicurezza, non dato per scontato in base alle convenzioni di denominazione.
Crittografia ovunque
TLS 1.2+ per tutti i dati in transito. Crittografia AES-256 per i dati a riposo. La crittografia è progettata per essere applicata ai flussi di dati di produzione supportati, senza alcun fallback in chiaro previsto.
Controllo degli accessi basato sui ruoli
7 ruoli distinti, da agent a super_admin. Gli endpoint API sono progettati per applicare i controlli sui ruoli secondo il modello RBAC configurato. Principio del privilegio minimo ovunque.
Isolamento multi-tenant
Row-Level Security di PostgreSQL applicata su ogni tabella dei tenant. Test di sicurezza automatizzati verificano che il Tenant B non possa accedere ai dati del Tenant A.
Log di audit append-only
Audit trail append-only. UPDATE e DELETE revocati a livello di database. Le azioni amministrative e rilevanti per la sicurezza vengono registrate con autore, timestamp e contesto dove la registrazione di audit è configurata.
URL firmati per le registrazioni
Le registrazioni delle chiamate non sono mai esposte tramite percorsi diretti. URL firmati con scadenza di 1 ora. I link scaduti restituiscono 403, non audio obsoleto.
Backup e disaster recovery
Backup automatici del database con ripristino point-in-time. Replica delle registrazioni su storage secondario. Procedure di ripristino testate.
Monitoraggio dell'infrastruttura
Alert in tempo reale su stato dei servizi, budget di latenza e utilizzo delle risorse. Le dashboard Grafana dei livelli di servizio monitorano la disponibilità rispetto allo SLA di uptime del 99.95% offerto nel piano Enterprise.
Registrazione delle attività amministrative
Le azioni amministrative e rilevanti per la sicurezza (creazione di utenti, cambio di ruolo, modifica di campagne, aggiornamento della configurazione) vengono registrate dove la registrazione di audit è configurata.
Accesso e identità
L'accesso è concesso tramite una matrice di ruoli per tenant, un log di audit che registra utente e indirizzo IP, e chiavi API sottoposte a hash a riposo e limitate a un solo tenant. Il single sign-on è disponibile tramite OIDC e SAML, con il provisioning degli utenti SCIM, e l'accesso a due fattori, una allow-list di IP e il timeout di inattività proteggono ogni login.
Scopri sicurezza e accesso in dettaglioConformità
Default-deny. Policy configurate applicate prima di chiamare.
I percorsi di chiamata outbound configurati possono passare dal motore di conformità prima della chiamata. Il default-deny può essere applicato alle policy di conformità configurate, bloccando e registrando le chiamate che non superano i controlli richiesti.
Applicazione DNC/DNCR
Supporta i quadri normativi TDRA (Emirati Arabi Uniti), TCPA (USA), CST (Arabia Saudita), NTRA (Egitto) e TRC (Giordania). I numeri possono essere verificati prima di chiamare quando l'applicazione DNC/DNCR è configurata.
Orari di chiamata per giurisdizione
Regole sugli orari di chiamata applicate per giurisdizione. Predefinito EAU: 9:00-18:00 ora locale, da domenica a giovedì. Completamente configurabile per campagna.
Catena di prova del consenso
I registri del consenso possono includere URL di prova, indirizzo IP, user-agent, timestamp e fonte. Le policy di conservazione sono configurabili per campagna e giurisdizione.
Verifica della titolarità del CLI
Numeri di ID chiamante verificati per tenant e per giurisdizione. Nessun tenant può falsificare il CLI di un altro tenant. Titolarità sottoposta ad audit continuo.
Default-deny in caso di errore
Le policy default-deny configurate possono bloccare le chiamate quando i controlli di conformità falliscono, le impostazioni delle policy sono sconosciute o i servizi restituiscono errori.
Traccia append-only delle decisioni
Le decisioni di conformità possono essere registrate con timestamp, riferimento di audit e contesto dove la registrazione di audit è configurata. Le decisioni registrate sono append-only.
Policy di conservazione delle registrazioni
Periodi di conservazione configurabili per tenant. Registrazioni archiviate secondo i requisiti della giurisdizione. Applicazione automatica della scadenza.
Reportistica di conformità
Dashboard in tempo reale su tassi di blocco, corrispondenze DNC, scadenza dei consensi e violazioni degli orari di chiamata. Esportabili per audit normativi.
IA e pratiche sui dati
IA trasparente. I tuoi dati restano tuoi.
Le funzionalità di IA sono opzionali, disattivate per impostazione predefinita, e non usano mai il tuo audio per addestrare modelli condivisi. Pieno override umano in ogni fase.
Elaborazione audio minima
La classificazione AMD è progettata per elaborare un breve segmento iniziale dell'audio della chiamata. L'analisi audio dell'intera chiamata non viene eseguita senza un opt-in esplicito. La policy dettagliata sui dati dell'IA è disponibile su richiesta.
Nessuna conservazione a lungo termine delle trascrizioni
Le trascrizioni generate per la classificazione AMD vengono usate in tempo reale e non sono conservate a lungo termine. I risultati della classificazione vengono conservati; le trascrizioni grezze no.
Addestramento del modello per tenant
Il feedback AMD può essere limitato al tenant e governato dalle impostazioni di conservazione e IA del cliente. Nessuna contaminazione tra tenant per impostazione predefinita.
Nessun addestramento di modelli condivisi
Per impostazione predefinita, i dati delle chiamate dei clienti non vengono usati per addestrare modelli condivisi tra tenant. Il feedback AMD può essere limitato al tenant e governato dalle impostazioni di conservazione e IA del cliente.
Disattivato per impostazione predefinita
Le funzionalità di IA possono essere controllate tramite feature flag a livello di tenant e impostazioni di opt-in. Nulla si attiva senza una configurazione esplicita del tenant.
Override umano sempre disponibile
Gli agenti possono modificare qualsiasi classificazione dell'IA in qualsiasi momento. L'IA assiste; le persone decidono. Le decisioni automatizzate sono sempre verificabili.
Opt-out completo disponibile
I tenant possono disattivare completamente tutte le funzionalità di IA con una sola modifica di configurazione. La piattaforma funziona a piena capacità anche senza IA.
Audit trail delle decisioni dell'IA
Le classificazioni dell'IA possono essere registrate con punteggio di confidenza, versione del modello e stato dell'override umano dove la registrazione di audit è configurata.
Residenza e archiviazione dei dati
Sappi esattamente dove si trovano i tuoi dati
Tutti i dati sono isolati per tenant a ogni livello. Luoghi di archiviazione e policy di conservazione sono configurabili per tenant per soddisfare i requisiti della giurisdizione.
Archiviazione delle registrazioni su cloud privato
Le registrazioni delle chiamate sono archiviate in MinIO su infrastruttura cloud privata. Nessun object storage di terze parti. Pieno controllo su localizzazione dei dati e policy di accesso.
PostgreSQL per i dati strutturati
Tutti i dati strutturati (contatti, campagne, decisioni di conformità, log di audit) sono archiviati in PostgreSQL 16 con Row-Level Security applicata su ogni tabella dei tenant.
Redis per i dati temporanei
Dati di sessione, stato degli agenti in tempo reale e caching usano Redis. Temporanei per progettazione. Nessun dato persistente dei clienti archiviato nei livelli di cache.
Isolamento completo dei tenant
I controlli sono progettati per impedire l'accesso ai dati tra tenant, con Row-Level Security, token con ambito limitato e test di sicurezza automatizzati.
Conservazione configurabile
Le policy di conservazione delle registrazioni, dei log di audit e del ciclo di vita dei dati sono configurabili per tenant. Applicazione automatica dei periodi di conservazione.
Crittografia a ogni livello
Dati crittografati in transito tra tutti i servizi (mTLS). Crittografati a riposo in PostgreSQL, MinIO e nello storage di backup. La gestione delle chiavi segue le best practice del settore.
Avvertenza sulla conformità
DialerBee fornisce strumenti a supporto della conformità, controlli configurabili, log di audit e flussi di applicazione progettati per aiutare le organizzazioni a soddisfare i requisiti normativi. I clienti restano responsabili della propria conformità legale e dovrebbero rivolgersi a un consulente qualificato per i requisiti specifici della giurisdizione. I quadri normativi citati (TDRA, TCPA, CST, NTRA, TRC) sono soggetti a modifiche.
Postura di sicurezza
Stato di implementazione attuale del nostro programma di sicurezza
L'altra metà è la disponibilità. Il media gira su due nodi con failover degli agenti, e il database viene sottoposto a backup ogni notte e conservato off-site: tutto descritto nella affidabilità della piattaforma page.
Risorse sulla sicurezza
Documenti e policy
Scarica o richiedi la documentazione sulla sicurezza per la tua revisione.
Security Overview
Architettura, crittografia, controlli di accesso e dettagli sull'infrastruttura.
Richiedi il PDFAccordo sul trattamento dei dati
DPA standard per i titolari del trattamento. Condizioni allineate al GDPR.
Richiedi il DPAElenco dei sub-responsabili
Servizi di terze parti che trattano dati per nostro conto.
Visualizza l'elencoPolitica sui dati per l'IA
Come l'AMD elabora l'audio, ambito dell'addestramento e opzioni di opt-out.
Visualizza la policySegnalazione delle vulnerabilità
Segnala i problemi di sicurezza in modo responsabile. Rispondiamo entro 48 ore.
Segnala un problemaSintesi del penetration test
Un penetration test esterno indipendente è pianificato. Ne condivideremo una sintesi con i clienti sotto NDA una volta completato.
Richiedi la sintesiInformativa sulla privacy
Come raccogliamo, usiamo, conserviamo e proteggiamo i dati personali.
Leggi la policyTermini di servizio
Condizioni d'uso, uso accettabile, responsabilità e accordi.
Leggi i terminiPolicy di risposta agli incidenti
Come rileviamo, gestiamo e comunichiamo gli incidenti di sicurezza.
Richiedi i dettagliPer pacchetti di sicurezza enterprise, DPA personalizzati o questionari di conformità, contatta security@dialerbee.com
Ultimo aggiornamento: ottobre 2026 · SOC 2 Type II: pianificato
Un isolamento che puoi verificare
Non fidarti della nostra parola: chiedici di dimostrarlo
Ogni piattaforma dice che i tuoi dati sono separati da quelli di tutti gli altri. Una banca, un operatore telecom o un ente pubblico non vogliono la frase: vogliono sapere come viene applicata e come potrebbero verificarla. Ecco il meccanismo.
Applicato dal database, non dal codice applicativo
La separazione è implementata come row-level security in PostgreSQL. Ogni query viene filtrata per tenant nel database, quindi un errore nel codice applicativo non può restituire le righe di un altro tenant: il confine non dipende dal fatto che ogni sviluppatore si ricordi di aggiungere una clausola WHERE.
FORCE, non solo ENABLE
La row-level security è abilitata E forzata sulle tabelle dei tenant. Forzarla significa che anche il proprietario della tabella è soggetto alla policy, il che chiude la classica falla per cui il ruolo di database dell'applicazione stessa può leggere scavalcando le regole.
Default-deny, non default-allow
Quando manca un contesto tenant, la policy nega invece di ripiegare restituendo tutto. Una variabile di sessione non impostata non restituisce nulla: è il fallimento sicuro, l'opposto di ciò che fa un approccio basato su clausole WHERE quando ci si dimentica un filtro.
Anche la conformità fallisce in modo sicuro
Lo stesso principio vale per le chiamate: se il servizio di conformità non è raggiungibile, le chiamate vengono bloccate invece di passare senza verifica. Un sistema che chiama quando non può verificare il consenso è peggio di uno che si ferma.
La separazione va oltre il database
Pool di ID chiamante, knowledge base e retrieval, registrazioni, report e identità dei mittenti dei messaggi sono tutti limitati al tenant, così nulla attraversa un confine nemmeno ai margini: ciò che conta quando gestisci i marchi di altri.
Cosa chiederci. Porta il tuo team di sicurezza e chiedici di ripercorrere con loro il modello di isolamento: quali tabelle hanno la policy, cosa succede a una query senza contesto tenant, e come vengono limitati al tenant una registrazione o un pool di ID chiamante. Preferiamo rispondere in una revisione piuttosto che fartelo scoprire durante un pilota.
Domande su sicurezza o conformità?
Il nostro team è pronto a discutere i tuoi requisiti, condividere la documentazione e illustrarti le nostre pratiche di sicurezza.