Nuestra seguridad

Todas las transferencias de datos están cifradas con TLS (al menos TLS 1.2, preferiblemente TLS 1.3) entre el navegador, la aplicación, la base de datos y el motor de transcripción. HSTS está activo en todos los endpoints públicos; las solicitudes HTTP se redirigen a HTTPS y las suites de cifrado se configuran según el perfil "Modern" de Mozilla.

Los datos están cifrados en reposo: las copias de seguridad se protegen con AES-256 y los volúmenes de la base de datos están totalmente cifrados a nivel de disco. Las contraseñas se almacenan exclusivamente con bcrypt (coste ≥ 10). Las claves API se almacenan con hash y se muestran en texto plano una sola vez, en el momento de su creación.

El acceso administrativo a los sistemas de producción se realiza exclusivamente mediante SSH con autenticación de clave asimétrica – el inicio de sesión con contraseña está desactivado. Todas las cuentas del personal en las consolas de plataforma y nube están protegidas con autenticación de dos factores basada en TOTP.

• Control de acceso basado en roles (RBAC) según el principio de privilegio mínimo
• Revisión trimestral de todos los permisos de acceso
• Registro de auditoría completo de todos los accesos administrativos (quién, cuándo, qué, desde dónde)
• En operación normal, el personal de Aliru no tiene acceso de lectura al contenido de las transcripciones
• Del lado del cliente: 2FA TOTP opcional, códigos de respaldo, un registro de auditoría propio por cuenta

Cada espacio de trabajo (internamente un "Directory") está lógicamente separado de todos los demás mediante un UUID. Cada consulta a la base de datos verifica el contexto Directory de la solicitud actual – el acceso de lectura entre inquilinos es técnicamente imposible, porque la capa de aplicación nunca permite una consulta no verificada contra la base de datos. Las copias de seguridad, los registros de auditoría y las cachés siguen la misma separación.

• Copias de seguridad automatizadas diarias; retención rotativa de 14 días
• Copias de seguridad cifradas (AES-256) y alojadas en hardware separado en un segundo centro de datos
• Pruebas de restauración documentadas cada seis meses
• RTO (Recovery Time Objective): 4 horas en caso de fallo total
• RPO (Recovery Point Objective): un máximo de 24 horas de pérdida de datos
• Página de estado en deepscript.com/status con sondeo por minuto e historial de incidentes de 90 días

Operamos un proceso de respuesta a incidentes documentado con una cadena de escalado clara: detección → contención → análisis → remediación → notificación al cliente → post-mortem.

• Notificación de las violaciones de datos a los clientes en un plazo de 24 horas desde su conocimiento
• Contenido de la notificación: naturaleza de la violación, categorías y número aproximado de datos afectados, medidas adoptadas, persona de contacto
• La notificación a la autoridad conforme al art. 33 RGPD (plazo de 72 horas) corresponde al responsable del tratamiento – prestamos apoyo con toda la información necesaria
• Un post-mortem para cada incidente con análisis de causa raíz y medidas para evitar que se repita

Cada año contratamos a un proveedor de seguridad externo e independiente para realizar una prueba de penetración contra la aplicación web y la API REST pública. Los hallazgos se priorizan por ponderación de riesgo; los hallazgos críticos se resuelven en un plazo de 14 días. Ponemos un resumen ejecutivo a disposición de los clientes empresariales bajo petición y bajo NDA.

Internamente realizamos cada trimestre una verificación de la eficacia de las MTO – la versión actual está documentada en el anexo 1 del contrato de encargo de tratamiento (DPA).

• Revisión de código obligatoria para todos los cambios en el código de producción
• Análisis de dependencias en cada build (pnpm audit) – sin CVE críticas conocidas en producción
• CI automatizada con comprobación de tipos, pruebas unitarias y pruebas E2E antes de cada despliegue
• Separación estricta de los entornos de desarrollo, staging y producción – sin datos reales en sistemas no productivos
• Secretos en las configuraciones de producción mediante variables de entorno cifradas; sin secretos en el repositorio de código

Nuestro motor de voz a texto se incluye en la categoría de "riesgo limitado" del Reglamento de IA de la UE (Reglamento (UE) 2024/1689). No hay identificación biométrica, ni puntuación social, ni decisiones automatizadas con efectos jurídicos. Los detalles figuran en la declaración de conformidad de IA (anexo 4 del DPA).

• Compromiso de confidencialidad de todo el personal conforme al art. 28, apdo. 3, letra b) RGPD
• Formación anual obligatoria sobre protección de datos y seguridad de la información
• Formación de incorporación para cada nuevo empleado con acceso a los sistemas de producción
• Proceso de salida con revocación inmediata de todos los accesos al finalizar el contrato