Centro de confianza
Seguridad, cumplimiento y prácticas de datos en DialerBee
La plataforma de contact center con IA, con aislamiento multi-tenant, cumplimiento con denegación por defecto, registros de auditoría de solo anexión y prácticas de datos de IA transparentes. Creada para sectores regulados.
Respuesta rápida
¿Cómo gestiona DialerBee la seguridad y el cumplimiento? DialerBee ofrece seguridad de nivel empresarial con cifrado AES-256, Row-Level Security de PostgreSQL para el aislamiento multi-tenant, registros de auditoría de solo anexión y controles de cumplimiento con denegación por defecto para TCPA, RGPD, TDRA, CST y más. El inicio de sesión único (SSO) está disponible mediante OIDC y SAML, con aprovisionamiento de usuarios SCIM, y el inicio de sesión en dos pasos, una lista de IP permitidas y el cierre por inactividad protegen cada acceso. Las funciones de IA son opcionales, están desactivadas por defecto y los datos de los clientes nunca se usan para entrenar modelos compartidos.
Seguridad
Defensa en profundidad, no defensa por esperanza
Cada capa del stack está reforzada. El aislamiento entre tenants se valida mediante pruebas automatizadas y procesos de revisión de seguridad, no se da por hecho a partir de convenciones de nombres.
Cifrado en todas partes
TLS 1.2+ para todos los datos en tránsito. Cifrado AES-256 para los datos en reposo. El cifrado está diseñado para aplicarse en los flujos de datos de producción compatibles, sin ninguna alternativa prevista en texto plano.
Control de acceso basado en roles
7 roles distintos, de agente a super_admin. Los endpoints de la API están diseñados para aplicar verificaciones de rol según el modelo RBAC configurado. Principio de mínimo privilegio en todo el sistema.
Aislamiento multi-tenant
Row-Level Security de PostgreSQL aplicada en cada tabla de tenant. Las pruebas de seguridad automatizadas validan que el Tenant B no pueda acceder a los datos del Tenant A.
Registros de auditoría de solo anexión
Rastro de auditoría de solo anexión. UPDATE y DELETE revocados a nivel de base de datos. Las acciones administrativas y relevantes para la seguridad se registran con el autor, la marca de tiempo y el contexto donde el registro de auditoría está configurado.
URL de grabación firmadas
Las grabaciones de llamadas nunca se exponen mediante rutas directas. URL firmadas con caducidad de 1 hora. Los enlaces caducados devuelven 403, no audio obsoleto.
Copias de seguridad y recuperación ante desastres
Copias de seguridad automatizadas de la base de datos con recuperación a un punto en el tiempo. Replicación de grabaciones a un almacenamiento secundario. Procedimientos de restauración probados.
Monitoreo de infraestructura
Alertas en tiempo real sobre la salud del servicio, los presupuestos de latencia y el uso de recursos. Los paneles de nivel de servicio en Grafana miden la disponibilidad frente al SLA de 99.95% de disponibilidad que se ofrece en el plan Enterprise.
Registro de actividad administrativa
Las acciones administrativas y relevantes para la seguridad —creación de usuarios, cambios de rol, modificaciones de campañas, actualizaciones de configuración— se registran donde el registro de auditoría está configurado.
Acceso e identidad
El acceso se concede mediante una matriz de roles por tenant, un registro de auditoría que guarda el usuario y la dirección IP, y claves de API almacenadas con hash y limitadas a un solo tenant. El inicio de sesión único (SSO) está disponible mediante OIDC y SAML, con aprovisionamiento de usuarios SCIM, y el inicio de sesión en dos pasos, una lista de IP permitidas y el cierre por inactividad protegen cada acceso.
Vea la seguridad y el acceso en detalleCumplimiento
Denegación por defecto. Políticas configuradas aplicadas antes de marcar.
Las rutas de marcación saliente configuradas pueden pasar por el motor de cumplimiento antes de marcar. La denegación por defecto puede aplicarse a las políticas de cumplimiento configuradas, bloqueando y registrando las llamadas que no superan las verificaciones requeridas.
Aplicación de DNC/DNCR
Admite los marcos TDRA (EAU), TCPA (EE. UU.), CST (Arabia Saudita), NTRA (Egipto) y TRC (Jordania). Los números pueden verificarse antes de marcar cuando la aplicación de DNC/DNCR está configurada.
Horarios de llamada por jurisdicción
Reglas de horario de llamadas aplicadas por jurisdicción. Valor predeterminado en EAU: 9:00-18:00 hora local, de domingo a jueves. Totalmente configurable por campaña.
Cadena de prueba del consentimiento
Los registros de consentimiento pueden incluir URL de prueba, dirección IP, user-agent, marca de tiempo y origen. Las políticas de retención se configuran por campaña y jurisdicción.
Verificación de titularidad del CLI
Los números de identificador de llamada se verifican por tenant y por jurisdicción. Ningún tenant puede suplantar el CLI de otro tenant. La titularidad se audita de forma continua.
Denegación por defecto ante fallos
Las políticas de denegación por defecto configuradas pueden bloquear llamadas cuando fallan las verificaciones de cumplimiento, se desconoce la configuración de la política o los servicios devuelven errores.
Rastro de decisiones de solo anexión
Las decisiones de cumplimiento pueden registrarse con marca de tiempo, referencia de auditoría y contexto donde el registro de auditoría está configurado. Las decisiones registradas son de solo anexión.
Políticas de retención de grabaciones
Periodos de retención configurables por tenant. Grabaciones almacenadas según los requisitos de cada jurisdicción. Caducidad aplicada automáticamente.
Informes de cumplimiento
Paneles en tiempo real con tasas de bloqueo, tasas de coincidencia con DNC, vencimiento del consentimiento e infracciones de horario de llamadas. Exportables para auditorías regulatorias.
Prácticas de IA y datos
IA transparente. Sus datos siguen siendo suyos.
Las funciones de IA son opcionales, están desactivadas por defecto y nunca usan su audio para entrenar modelos compartidos. Control humano total en cada paso.
Procesamiento mínimo de audio
La clasificación AMD está diseñada para procesar un breve segmento inicial del audio de la llamada. No se analiza el audio completo de la llamada sin una activación explícita. La política detallada de datos de IA está disponible a solicitud.
Sin almacenamiento de transcripciones a largo plazo
Las transcripciones generadas para la clasificación AMD se usan en tiempo real y no se almacenan a largo plazo. Se conservan los resultados de la clasificación, no las transcripciones originales.
Entrenamiento de modelos por tenant
La retroalimentación del AMD puede limitarse a cada tenant y regirse por la configuración de retención y de IA del cliente. Por defecto, no hay cruce de datos entre tenants.
Sin entrenamiento de modelos compartidos
Por defecto, los datos de llamadas de los clientes no se usan para entrenar modelos compartidos entre tenants. La retroalimentación del AMD puede limitarse a cada tenant y regirse por la configuración de retención y de IA del cliente.
Desactivado por defecto
Las funciones de IA pueden controlarse con indicadores de funciones a nivel de tenant y configuraciones de activación voluntaria. Nada se activa sin una configuración explícita del tenant.
Intervención humana siempre disponible
Los agentes pueden anular cualquier clasificación de la IA en cualquier momento. La IA asiste; las personas deciden. Las decisiones automatizadas siempre pueden revisarse.
Exclusión total disponible
Los tenants pueden desactivar por completo todas las funciones de IA con un solo cambio de configuración. La plataforma funciona con todas sus capacidades sin IA.
Rastro de auditoría de decisiones de IA
Las clasificaciones de la IA pueden registrarse con la puntuación de confianza, la versión del modelo y el estado de anulación humana donde el registro de auditoría está configurado.
Residencia y almacenamiento de datos
Sepa exactamente dónde están sus datos
Todos los datos están aislados por tenant en cada capa. Las ubicaciones de almacenamiento y las políticas de retención se configuran por tenant para cumplir los requisitos de cada jurisdicción.
Almacenamiento de grabaciones en nube privada
Las grabaciones de llamadas se almacenan en MinIO sobre infraestructura de nube privada. Sin almacenamiento de objetos de terceros. Control total sobre la ubicación de los datos y las políticas de acceso.
PostgreSQL para datos estructurados
Todos los datos estructurados —contactos, campañas, decisiones de cumplimiento, registros de auditoría— se almacenan en PostgreSQL 16 con Row-Level Security aplicada en cada tabla de tenant.
Redis para datos efímeros
Los datos de sesión, el estado de los agentes en tiempo real y la caché usan Redis. Efímero por diseño. No se almacenan datos persistentes de clientes en las capas de caché.
Aislamiento total entre tenants
Los controles están diseñados para impedir el acceso a datos entre tenants, con seguridad a nivel de fila, tokens con alcance limitado y pruebas de seguridad automatizadas.
Retención configurable
La retención de grabaciones, la retención de registros de auditoría y las políticas de ciclo de vida de los datos se configuran por tenant. Los periodos de retención se aplican automáticamente.
Cifrado en cada capa
Datos cifrados en tránsito entre todos los servicios (mTLS). Cifrados en reposo en PostgreSQL, MinIO y el almacenamiento de copias de seguridad. La gestión de claves sigue las buenas prácticas del sector.
Aviso sobre cumplimiento
DialerBee ofrece herramientas que apoyan el cumplimiento, controles configurables, registros de auditoría y flujos de aplicación diseñados para ayudar a las organizaciones a cumplir los requisitos regulatorios. Los clientes siguen siendo responsables de su propio cumplimiento legal y deben consultar a un asesor calificado sobre los requisitos de cada jurisdicción. Los marcos regulatorios mencionados (TDRA, TCPA, CST, NTRA, TRC) están sujetos a cambios.
Postura de seguridad
Estado actual de implementación de nuestro programa de seguridad
La disponibilidad es la otra mitad. Los medios se ejecutan en dos nodos con conmutación por error de los agentes, y la base de datos se respalda cada noche y se guarda fuera del sitio, según se detalla en la fiabilidad de la plataforma page.
Recursos de seguridad
Documentos y políticas
Descargue o solicite documentación de seguridad para su revisión.
Visión general de seguridad
Arquitectura, cifrado, controles de acceso y detalles de infraestructura.
Solicitar PDFAcuerdo de tratamiento de datos
DPA estándar para responsables del tratamiento. Términos alineados con el RGPD.
Solicitar el DPALista de subencargados
Servicios de terceros que tratan datos en nuestro nombre.
Ver listaPolítica de datos de IA
Cómo procesa el audio el AMD, el alcance del entrenamiento y las opciones de exclusión.
Ver políticaDivulgación de vulnerabilidades
Informe problemas de seguridad de forma responsable. Respondemos en un plazo de 48 horas.
Informar un problemaResumen de prueba de penetración
Está prevista una prueba de penetración externa independiente. Compartiremos un resumen con los clientes bajo acuerdo de confidencialidad (NDA) una vez que se complete.
Solicitar resumenPolítica de privacidad
Cómo recopilamos, usamos, almacenamos y protegemos los datos personales.
Leer la políticaTérminos del servicio
Condiciones de uso, uso aceptable, responsabilidad y acuerdos.
Leer las condicionesPolítica de respuesta a incidentes
Cómo detectamos, respondemos y comunicamos los incidentes de seguridad.
Solicitar detallesPara paquetes de seguridad empresarial, DPA personalizados o cuestionarios de cumplimiento, escriba a security@dialerbee.com
Última actualización: octubre de 2026 · SOC 2 Tipo II: planificado
Aislamiento que usted puede inspeccionar
No nos crea solo por nuestra palabra: pídanos que lo demostremos
Todas las plataformas dicen que sus datos están separados de los de todos los demás. Un banco, un operador de telecomunicaciones o un comprador gubernamental no quiere esa frase; quiere saber cómo se aplica y cómo podría comprobarlo. Este es el mecanismo.
Aplicado por la base de datos, no por el código de la aplicación
La separación se implementa como seguridad a nivel de fila en PostgreSQL. Cada consulta se filtra por tenant en la base de datos, así que un error en el código de la aplicación no puede devolver filas de otro tenant: el límite no depende de que cada desarrollador recuerde agregar una cláusula WHERE.
FORCE, no solo ENABLE
La seguridad a nivel de fila está habilitada Y forzada en las tablas de tenants. Forzarla significa que el propietario de la tabla también queda sujeto a la política, lo que cierra la brecha habitual por la que el propio rol de base de datos de la aplicación puede leer saltándose las reglas.
Denegar por defecto, no permitir por defecto
Cuando falta el contexto de tenant, la política deniega en lugar de recurrir a devolverlo todo. Una variable de sesión sin definir no devuelve nada, que es el fallo seguro y lo contrario de lo que ocurre con un enfoque de cláusula WHERE cuando se olvida un filtro.
El cumplimiento también falla de forma segura (cerrado)
El mismo principio se aplica a las llamadas: si no se puede contactar con el servicio de cumplimiento, las llamadas se bloquean en lugar de dejarse pasar sin verificar. Un sistema que marca cuando no puede verificar el consentimiento es peor que uno que se detiene.
La separación va más allá de la base de datos
Los grupos de identificadores de llamada, el conocimiento y la recuperación, las grabaciones, los informes y las identidades de remitente de mensajería están todos limitados por tenant, así que nada cruza un límite tampoco en los bordes, que es lo que importa cuando usted opera marcas de terceros.
Qué pedirnos. Traiga a su equipo de seguridad y pídanos que recorramos con ellos el modelo de aislamiento: qué tablas tienen la política, qué pasa con una consulta sin contexto de tenant y cómo se limita una grabación o un grupo de identificadores de llamada. Preferimos responder eso en una revisión antes que dejar que se convierta en un hallazgo durante un piloto.
¿Preguntas sobre seguridad o cumplimiento?
Nuestro equipo está listo para analizar sus requisitos, compartir documentación y explicarle nuestras prácticas de seguridad.