Seguridad

1. Cifrado

• En tránsito: TLS 1.3 en todo el tráfico entre el navegador y los servidores. HTTP se redirige a HTTPS con un 301 permanente y el sitio declara HSTS con un año de vigencia.
• En reposo: AES-256 sobre el almacenamiento de la base de datos y de los respaldos.
• Claves y secretos: ninguna clave de API sensible llega al navegador. Las llamadas a servicios externos salen desde funciones de servidor, y las credenciales viven en variables de entorno de la plataforma de despliegue, no en el código ni en el repositorio.

2. Aislamiento entre empresas

Cada empresa cliente ve exclusivamente sus datos. El aislamiento se aplica en el motor de base de datos mediante políticas Row-Level Security de PostgreSQL, no solo en la capa de aplicación.

La diferencia importa: si una consulta de la aplicación tuviera un fallo y pidiera filas de otra empresa, la base de datos las niega igualmente. Un error de programación no se convierte en una fuga entre clientes.

3. Control de accesos

• RBAC con roles granulares — cada usuario ve y hace únicamente lo que su rol permite. Los módulos con exigencias regulatorias (actuarial, cumplimiento AML) tienen roles separados de la administración general.
• MFA obligatoria en roles críticos — en LegalTech Compliance (cumplimiento y auditoría externa) y en Estados Financieros IA, esos roles no pueden operar sin segundo factor. En RiskGuard todavía no está: se hará tras la integración definitiva con Oracle, y hasta entonces no se afirma.
• Principio de mínimo privilegio — los permisos se conceden por necesidad demostrada, no por comodidad.
• Revocación inmediata — al desactivar un usuario, sus sesiones activas caducan.

4. Registros de auditoría

Las operaciones sobre datos financieros, de riesgo y de cumplimiento quedan registradas con usuario, momento y valor anterior. Los registros son inmutables —no se pueden editar ni borrar desde la aplicación— y se conservan un mínimo de 5 años, en línea con lo que exigen SUDEBAN y SUDEASEG para la trazabilidad de la información.

5. Dónde vive todo

Componente	Proveedor	Detalle
Base de datos	Supabase sobre AWS	PostgreSQL 15, región us-east-1, réplicas en varias zonas de disponibilidad
Aplicaciones y sitio	Netlify	Red de distribución global, certificados TLS gestionados
Lógica de servidor	Funciones sin servidor	Aíslan las claves de API del navegador
Correo transaccional	Resend	Remitente propio verificado en avisos.hermesaitech.com

Para clientes con requisitos de residencia de datos en la Unión Europea o en LATAM existe la opción de despliegue en región dedicada, que se acuerda por contrato.

6. Respaldos y continuidad

• Respaldo automático diario con 7 días de retención, gestionado por Supabase sobre AWS. Restauración a cualquiera de esos puntos bajo solicitud.
• Recuperación punto-en-tiempo (PITR) — reduce la pérdida máxima de un día a minutos. Es un complemento contratable aparte y se presupuesta por proyecto; no viene incluido de serie.
• Objetivo de disponibilidad mensual: 99,5 %.
• Ventana de cierre — durante los tres últimos días hábiles del mes y los cinco primeros del siguiente no se ejecuta ningún mantenimiento programado, y las incidencias críticas se atienden en una hora hábil. El detalle está en la sección de implantación y compromiso de servicio.

7. Cómo se construye

• Todo el código vive en repositorios con historial completo; ningún secreto se versiona.
• Las claves comprometidas se rotan, no se ocultan.
• Las dependencias de terceros se mantienen al día; las que no aportan valor se eliminan en lugar de arrastrarse.
• Los cambios sobre datos de producción se hacen mediante migraciones registradas, nunca a mano sobre la base.
• Ninguna credencial de envío viaja al navegador. Desde el 10 de agosto de 2026 el formulario de contacto de esta web se envía desde una función de servidor con la clave en variables de entorno; antes usaba una integración de correo cuya clave era visible en el código de la página.

8. Marcos de referencia y normativa

Marco	Situación real
ISO/IEC 27001	Marco aplicado al diseño de los controles. No es una certificación obtenida: HermesAI no está certificada por AENOR ni por ningún otro organismo acreditado.
SOC 2	No disponible. No existe informe SOC 2 Tipo I ni Tipo II.
RGPD / GDPR	La arquitectura y los procesos se diseñaron conforme a sus principios: minimización, limitación de finalidad, derechos del interesado y acuerdos de tratamiento con los proveedores.
SUDEASEG (Venezuela)	RiskGuard implementa los requisitos aplicables al sector asegurador, incluida la Providencia SAA-01-0536-2024, publicada en Gaceta Oficial Extraordinaria 6.835 del 3 de septiembre de 2024, en materia de prevención de legitimación de capitales. Su artículo 89 derogó la anterior Providencia SAA-08-004-2021.
SUDEBAN (Venezuela)	Los módulos financieros contemplan los requisitos de trazabilidad y conservación de información aplicables al sector bancario.

Cumplir los requisitos de un marco y estar certificado en él son cosas distintas. Esta tabla dice cuál es cuál, para que nadie descubra la diferencia en mitad de una auditoría.

9. Cómo reportar un problema de seguridad

Si encuentras una vulnerabilidad en hermesaitech.com o en cualquier producto de HermesAI, escríbenos antes de hacerla pública:

• Correo: hermes@hermesaitech.com, asunto [SEGURIDAD]
• Acuse de recibo en 2 días hábiles.
• Valoración inicial y plan de corrección en 10 días hábiles.

Te pedimos que no accedas a datos de terceros, no degrades el servicio y no publiques los detalles hasta que el fallo esté corregido. A cambio, no emprenderemos acciones legales contra quien investigue de buena fe siguiendo estas condiciones, y reconoceremos públicamente tu aportación si lo deseas.

No hay programa de recompensas económicas. Preferimos decirlo a que lo descubras después.

10. Lo que estamos construyendo

Publicamos también lo que falta, porque un proveedor que solo enseña la lista de lo que ya tiene no está diciendo la verdad completa:

• Certificación externa. Sin fecha comprometida. Depende del volumen de negocio: una auditoría ISO 27001 tiene un coste que hoy no se justifica para el tamaño de la operación.
• Consentimiento de cookies por categorías. Desde el 9 de agosto de 2026 ninguna etiqueta de medición se carga sin permiso: al entrar aparece un aviso y hasta que se acepta no se descarga nada de Google ni de LinkedIn. Lo que aún no hay es elección por categorías —hoy es aceptar todo o rechazar todo, sin separar estadística de publicidad— ni registro fechado del consentimiento, que es lo que pide una auditoría formal.
• Prueba de penetración externa. Prevista antes de la primera implantación en un cliente regulado.
• MFA en RiskGuard Insurance. El segundo factor está implantado en LegalTech y en Estados Financieros, pero no en RiskGuard. Se hará después de la integración definitiva en línea con Oracle, porque el modo de autenticación depende de cómo quede esa integración.