Cómo protegemos los datos de tu gente.

Cifrado AES-256-GCM aplicado a los campos sensibles en la base de datos: emails de usuarios y empleados, secret TOTP del 2FA, tokens de API de tus integraciones HRIS, client secret de OIDC y el RUT en datos de facturación.

Las claves se gestionan vía AWS KMS en producción, con soporte de rotación incremental. Para los lookups que no requieren descifrar (autenticación, búsqueda de personas), usamos hashes SHA-256 determinísticos en índices compuestos.

Todo el tráfico entre el navegador, CloudFront, nginx, la API y la base de datos viaja sobre TLS 1.3 con ciphers modernos. HSTS preload con max-age de 2 años y includeSubDomains para garantizar que ningún navegador descienda jamás a HTTP.

Tu base de datos (Neon PostgreSQL serverless), Redis, S3 y la infraestructura de cómputo viven en AWS sa-east-1. Los datos no salen de la región sin tu autorización explícita.

Única excepción: las llamadas a Claude (Anthropic) y Voyage AI (embeddings) viajan fuera de la región, pero con PII redactada y bajo contrato enterprise que prohíbe entrenamiento.

Para buscar usuarios por email sin necesidad de descifrar (login, password reset, invitación), almacenamos un emailHash SHA-256 en un índice compuesto (companyId, emailHash). Esto evita descifrar el campo en cada request y elimina el riesgo de side-channel attacks por timing en queries.

Mismo patrón para RefreshToken.tokenHash, ApiKey.keyHash, InviteToken.token y PasswordResetToken.token.

Los JWT viajan en cookies HttpOnly, SameSite=None, Secure, inaccesibles desde JavaScript del cliente (evita robo vía XSS).

Las cookies se dividen por path: el access_token (15 min) en path / y el refresh_token (7 días) en path /api/v1/auth/refresh. Así el refresh solo se envía cuando realmente hace falta y se reduce su exposición.

Cada refresh token es de un solo uso. Si un mismo token llega dos veces (usedAt ya marcado), asumimos posible robo: invalidamos automáticamente TODOS los tokens del usuario incrementando tokenVersion y forzamos un re-login.

Los tokens se almacenan como hash SHA-256, nunca en claro. La rotación reduce drásticamente el window de ataque si un token se filtra.

El logout no requiere consultar una blacklist en la base de datos en cada request. Incrementamos un campo tokenVersion en User, y nuestro JWT strategy compara payload.tv === user.tokenVersion. Cualquier JWT emitido antes del logout deja de validar al instante.

Ventaja: cero latencia por request (no hay query extra) y permite invalidar TODAS las sesiones de un usuario en un solo cambio atómico.

Soporte completo de 2FA por TOTP (Google Authenticator, Authy, 1Password). El secret se almacena cifrado AES-256-GCM con una key dedicada (TOTP_ENCRYPTION_KEY), separada de la key principal.

Al activar 2FA generamos 10 backup codes hashed con bcrypt para recuperación. Adicionalmente soportamos WebAuthn / passkeys, permitiendo login sin contraseña con Face ID, Touch ID, Windows Hello o llaves de hardware (YubiKey).

Modelo SsoConfig activo para clientes Enterprise: almacena entryPoint SAML, issuer y certificado del IdP, además de las credenciales OIDC cifradas en reposo con AES-256-GCM. El client secret de OIDC nunca se expone en claro fuera del momento de creación.

Provisioning vía SCIM 2.0 disponible en preview: endpoint /scim/v2/Users con token Bearer (SHA-256 hash en DB, mostrado en claro una sola vez al generarlo) que permite a tu IdP crear y deshabilitar usuarios. El flujo completo de login SSO (validación de assertions SAML firmadas y exchange de tokens OIDC) está en roadmap Enterprise — disponible bajo solicitud para evaluación temprana.

Validamos cada contraseña contra HIBP (Have I Been Pwned) usando k-anonymity: solo enviamos los primeros 5 caracteres del hash SHA1, nunca la contraseña completa. Si está en breaches públicos, la rechazamos.

Lockout automático tras 5 intentos fallidos (15 min de bloqueo). El login y el forgot-password devuelven siempre el mismo mensaje genérico, para prevenir email enumeration.

Defensa en profundidad real a nivel de base de datos. Cada tabla tenant-scoped tiene políticas ROW LEVEL SECURITY que filtran por company_id automáticamente — incluso si una query de la app olvidara el filtro, PostgreSQL devuelve 0 filas sin error.

El PrismaService (REQUEST-scoped) ejecuta SET LOCAL app.company_id = '<uuid>' al inicio de cada transacción, leyendo el id desde un AsyncLocalStorage poblado por el TenantContextMiddleware. Las políticas usan current_setting('app.company_id')::uuid para comparar. Los background jobs y schedulers se ejecutan dentro de runWithCompany(companyId, fn), asegurando que ninguna operación toque datos fuera de su tenant.

El companyId jamás viaja en el body de un request. Siempre se lee del header X-Company-ID y se valida que el usuario autenticado tenga una Membership en esa empresa antes de continuar.

Esto significa que ni siquiera con un token JWT robado puedes acceder a data de otra empresa: el JwtAuthGuard rechaza el request si no encuentra membership matching.

El middleware Prisma tiene dos listas explícitas: SCOPED_MODELS (54 modelos que requieren filtro por companyId) y ALLOWED_MODELS (modelos globales sin tenant: enums, plan catalog, etc.).

Cualquier modelo no incluido en ambas listas dispara una exception inmediata. Es imposible introducir accidentalmente un nuevo modelo sin pasar por code review explícito de seguridad.

El modelo trabaja con representaciones simbólicas, no con datos personales reales. Cada redacción queda registrada en PromptGuardrailEvent para auditoría.

Reconocemos y bloqueamos 18 patrones distintos de prompt injection: 'ignore previous instructions', 'DAN mode', 'jailbreak', 'pretend you are', 'forget your rules', 'override your instructions', 'role play as', 'developer mode', 'simulate being', entre otros.

Cada intento queda registrado con hash SHA-256 del input (no el contenido) en PromptGuardrailEvent, junto con el userId y companyId, para detectar abuso sistemático.

Cuando inyectamos datos de tu empresa en un prompt RAG, los envolvemos en marcadores claros: <<<COMPANY_DATA>>>...<<<END_COMPANY_DATA>>> y <<<USER_QUESTION>>>...<<<END_USER_QUESTION>>>.

Esto evita prompt confusion: el modelo distingue qué es contexto factual de tu empresa, qué es la pregunta del usuario, y qué son sus propias instrucciones del system prompt. Pattern recomendado en literatura de LLM safety.

Usamos Anthropic Claude en tier enterprise: por contrato, ningún input ni output se utiliza para entrenar modelos públicos. Lo mismo con Voyage AI (embeddings): no almacena queries.

No hay model fine-tuning con datos de un cliente que beneficie a otro. Tu información se queda contigo.

Cada recomendación tiene dos capas: Layer 1 (reglas determinísticas) que siempre se ejecuta y garantiza una respuesta, y Layer 2 (Claude) que enriquece con criterio cualitativo.

Si la IA falla por cualquier motivo (rate limit, timeout, error de red, output inválido), la capa de reglas responde. El cliente nunca ve pantalla vacía y tampoco ve degradación en seguridad.

Operamos bajo los estándares de la Ley 19.628 sobre Protección de la Vida Privada de Chile. Los datos personales de tus colaboradores son tratados con consentimiento, finalidad específica y derecho de acceso/rectificación/cancelación.

Documento DPA (Data Processing Agreement) disponible para todos los clientes que lo requieran.

Cumplimos con la LGPD brasileña: bases legales claras para cada tratamiento, derechos del titular (acceso, corrección, eliminación, portabilidad), y notificación de incidentes en plazos razonables.

Para clientes brasileños, el DPA específico de LGPD y el contacto del Encarregado de Dados están disponibles a pedido.

Aunque nuestro foco es LATAM, implementamos los derechos GDPR como baseline: portabilidad (export ZIP con todos tus datos en JSON), derecho al olvido (soft/hard delete con anonymization), minimización (solo recolectamos lo necesario) y transparencia (esta página).

Operamos con los controles equivalentes a ISO 27001 (cifrado AES-256-GCM, segregación por tenant fail-closed con RLS DB-level, audit log inmutable, 2FA obligatorio en planes Enterprise, hard-delete GDPR, prompt-injection guardrails, etc.) y con un Sistema de Gestión de Seguridad de la Información (SGSI) establecido — 16 políticas formales ratificadas por la dirección el 2026-05-15. El certificado externo es el siguiente paso.

Mientras tanto, ofrecemos DPA bilateral bajo solicitud (support@mail.talyzr.com), lista actualizada de sub-procesadores y respondemos cuestionarios de seguridad pre-rellenados (CAIQ Lite, SIG Lite, custom).

Toda acción crítica queda registrada en una tabla AuditLog que jamás se borra: USER_LOGIN, USER_LOGOUT, creación/modificación/eliminación de cargos, sucesores, decisiones de talent review, cambios de criticidad, impersonaciones de platform-admin, cambios de subscription.

Cada entry guarda before/after JSON, userId, companyId, entityType, entityId y timestamp. Si un usuario se borra (GDPR), su userId se anonimiza pero el log permanece para cumplimiento legal.

Si cancelas tu suscripción, los datos quedan disponibles 90 días antes del cleanup automático.

Para empresas chilenas que requieran factura electrónica para deducir IVA, emitimos DTE (Documento Tributario Electrónico) automáticamente al confirmar cada pago. Integración con Bsale y Nubox.

Recibes PDF + XML por email con folio asignado por el SII. El RUT en CompanyBillingInfo se almacena cifrado AES-256 en reposo.

CloudFront protegido con AWS WAFv2 aplicando AWSManagedRulesCommonRuleSet (OWASP Top 10), AWSManagedRulesSQLiRuleSet y reglas custom de rate limiting. Logs de violaciones revisados periódicamente para detectar patrones de abuso.

Los webhooks externos (Paddle, Talana, Resend) usan firma HMAC + idempotency en Redis por 24h.

Monitoreo de errores con Sentry, configurado con sendDefaultPii: false y un hook beforeSend que reemplaza emails en breadcrumbs por [email] antes de enviar.

tracesSampleRate: 0.2 en producción para mantener costo controlado. Cada request lleva un requestId único (ULID) propagado en headers y logs JSON estructurados para correlación entre frontend, backend, queue y Sentry.