Seguridad

La seguridad se basa en buena ingeniería.

Tus datos del SII, bancos y Previred son de los más sensibles que maneja una empresa. Los ciframos en reposo y en tránsito, aislamos cada tenant con Row Level Security en la base de datos, y acotamos cada agente a los scopes que autorizas explícitamente.

Tus datos nunca entrenan modelos de IAÚltima revisión · julio 2026

Sección 01

Cómo protegemos tus datos

Los datos del SII, bancarios y previsionales son de los más sensibles que maneja una empresa. Los ciframos en tránsito y en reposo, y añadimos una capa propia de cifrado autenticado sobre los secretos más críticos.

Cifrado en tránsito (TLS): Todo el tráfico entre tu navegador, nuestra aplicación, la API y la base de datos viaja sobre TLS por defecto, tanto en Vercel (frontend) como en Supabase (base de datos, API y Edge Functions). No se acepta tráfico en texto plano.
Cifrado en reposo gestionado: La base de datos y el almacenamiento se cifran en reposo a nivel de plataforma a través de Supabase y Vercel. Es un control administrado por estos proveedores de infraestructura, no una afirmación de marketing nuestra.
Cifrado adicional de secretos críticos: Sobre los tokens OAuth de integraciones aplicamos cifrado autenticado AES-256-GCM a nivel de aplicación: clave de 256 bits, IV (nonce) único de 96 bits por operación y auth tag de 128 bits para verificar integridad. Estos secretos nunca se almacenan en claro.
Respaldos gestionados: La persistencia y los respaldos de la base de datos están gestionados por Supabase como proveedor de infraestructura, con migraciones versionadas y revisables del lado de Emisso para que ningún cambio de esquema llegue a producción sin revisión.

Sección 02

Control de acceso y aislamiento por tenant

Ninguna empresa puede ver los datos de otra. El aislamiento no depende de que el código se acuerde de filtrar: está enforced a nivel de base de datos.

Aislamiento por tenant con Row Level Security: PostgreSQL aplica Row Level Security (RLS) sobre las tablas con datos de cliente. Las policies filtran cada fila por la membresía del usuario (tenant_members vía auth.uid() del JWT), de modo que la base de datos misma impide leer filas de otro tenant. El RLS está habilitado y con policies en decenas de migraciones versionadas.
Autenticación con Supabase Auth (JWT): El acceso de usuarios se basa en Supabase Auth con JWT. Cada endpoint valida la sesión en su boundary y resuelve el contexto de tenant y de miembro antes de ejecutar cualquier lógica, rechazando con 401 si no hay sesión y con 403 si no hay membresía válida del tenant.
Contexto de tenant exigido en cada operación: No hay rutas que operen sin resolver primero a qué tenant pertenece la solicitud. Esta verificación es el guard transversal del producto: la combinación de JWT y RLS asegura que la autorización se valide en dos capas independientes.

Sección 03 · Gobernanza de agentes

Los agentes operan bajo tu control

Un agente que actúa sobre tu SII y tus bancos solo es seguro si sus credenciales están acotadas, son revocables y no pueden escalar privilegios — y si su gobernanza mantiene a tu equipo al mando. Así diseñamos la superficie agéntica.

Credenciales acotadas por scope: El acceso programático usa Personal Access Tokens con formato emi_<env>_ y cerca de 190 bits de entropía. Cada token lleva scopes granulares (por ejemplo read:crm o write:findings), fecha de expiración y revocación, de modo que un agente solo puede hacer aquello que autorizaste explícitamente.
Tokens hasheados, nunca en claro: Los tokens se almacenan como un prefijo indexado más un hash argon2id del token completo; el valor en claro se muestra una sola vez al crearlo y nunca se persiste ni se vuelve a devolver. Verificarlos cuesta un hash argon2id, no una comparación de texto.
Sin escalamiento de privilegios: Los endpoints de gestión de llaves no son invocables con un PAT, así un token no puede crear otros tokens. El acceso entre clientes solo es posible si el partner es dueño de la fila y está activo, y las IP de cabeceras como X-Forwarded-For se tratan solo como telemetría: la autorización nunca confía en ellas.
Autorización explícita en cada función: Las Edge Functions validan los permisos dentro de su propio código antes de operar sobre cualquier dato, en lugar de delegar la decisión a una capa implícita. La autorización es una verificación explícita, no un efecto colateral de la infraestructura.
Tu equipo aprueba y manda: El modelo de operación mantiene a las personas al mando: los despliegues se configuran para que las acciones sensibles del agente pasen por la aprobación de quienes tú designas. El agente propone y ejecuta dentro de sus scopes; tu equipo decide.
Bitácora auditable de cada acción: Cada llamada del agente a un sistema queda registrada con su resultado — incluidos los intentos rechazados por permisos (403). Lo que el agente hizo, cuándo y con qué autorización es consultable en la bitácora, no algo que haya que reconstruir.

Sección 04

Infraestructura y operación

Construimos sobre proveedores de primer nivel y desplegamos con cambios revisables, errores tipados y pruebas contra una base de datos real.

Proveedores de primer nivel: Frontend en Vercel (Next.js), con base de datos PostgreSQL, autenticación y Edge Functions (sobre Deno) en Supabase. Apoyarnos en estos proveedores nos da su superficie de seguridad de plataforma y nos deja concentrar el esfuerzo en la lógica de aislamiento y permisos.
Migraciones versionadas y revisables: El esquema se gestiona con Drizzle ORM y migraciones versionadas. Podemos previsualizar el SQL de cada despliegue antes de aplicarlo a producción, de modo que ningún cambio estructural ocurre sin revisión y sin trazabilidad en el repositorio.
Errores tipados y trazabilidad: La capa de API usa errores tipados mapeados a códigos HTTP estables (401, 403, 404, 429, 500) que no filtran detalles internos, y logging estructurado que anota tenantId, userId y requestId para correlacionar y auditar cada solicitud.
Validación y pruebas con base de datos real: Cada boundary valida la entrada con Zod antes de ejecutar lógica, y la suite de pruebas corre contra PostgreSQL real (no mocks), ejercitando constraints, foreign keys y el propio aislamiento por tenant.

Sección 05

Privacidad y cumplimiento legal chileno

Tratamos datos tributarios, bancarios y previsionales, que en Chile tienen deberes de reserva sectoriales y un estándar diferenciado. Nuestro marco de referencia es la ley chilena de protección de datos, en su versión reformada.

Tus datos no entrenan modelos de IA: Los modelos de lenguaje procesan únicamente el contenido que el agente necesita para razonar en cada tarea. Ni Emisso ni nuestros proveedores de inferencia usan tus datos para entrenar modelos: la política de datos de API de OpenAI lo excluye y los acuerdos de tratamiento con cada subencargado lo refuerzan.
Marco legal: Ley 19.628 reformada por la Ley 21.719: Operamos bajo la Ley 19.628 reformada por la Ley 21.719, que crea la Agencia de Protección de Datos Personales (APDP) como autoridad y mueve el estándar de declarar a demostrar (accountability). Trabajamos para tener cumplimiento pleno antes de su vigencia total, el 1 de diciembre de 2026.
Consentimiento y datos sensibles: Buscamos un consentimiento libre, específico, informado e inequívoco, sin casillas premarcadas, y consentimiento explícito para datos sensibles. Lo tratamos con especial cuidado porque la situación socioeconómica y los datos bancarios, tributarios y previsionales caen en categorías protegidas o de estándar diferenciado.
Derechos ARCOP: Habilitamos un canal para que los titulares ejerzan sus derechos de Acceso, Rectificación, Cancelación, Oposición, Portabilidad y Bloqueo, incluida la portabilidad de datos en un formato estructurado e interoperable. Estos derechos son irrenunciables y no los limitamos por contrato.
Transferencia internacional y subencargados: Chile no exige que los datos se alojen localmente. Cuando se procesan en proveedores en el extranjero (por ejemplo Supabase, Vercel u OpenAI), la transferencia se ampara en las Cláusulas Contractuales Modelo aprobadas por el Ministerio de Economía y en acuerdos de tratamiento de datos (DPA) con cada encargado.

Sección 06

Respuesta a incidentes y gobernanza

La seguridad no es solo prevención: es cómo respondemos cuando algo ocurre y cómo formalizamos la gobernanza del programa de datos.

Notificación de brechas: Ante una vulneración de seguridad, notificamos a la APDP sin dilaciones indebidas (Art. 14 sexies, Ley 19.628 reformada) y avisamos a los titulares afectados cuando el riesgo sea alto.
Gobernanza de datos en marcha: Como parte de nuestro camino hacia la vigencia plena de la Ley 21.719, estamos formalizando la designación de un Delegado de Protección de Datos (DPO), el Registro de Actividades de Tratamiento (Art. 14 ter), los DPA con cada subencargado y un Modelo de Prevención de Infracciones (MPI), que opera como atenuante explícito ante la APDP.
Reporte responsable de vulnerabilidades: Mantenemos un canal directo para que investigadores, clientes y equipos de due diligence reporten hallazgos o soliciten documentación. Respondemos a reportes de vulnerabilidades y a cuestionarios de seguridad.

Marcos de referencia

Estándares y cumplimiento

Seamos precisos con el lenguaje: alineamos nuestros controles a estos estándares y avanzamos un roadmap de certificación. Hoy no contamos con certificaciones SOC 2 ni ISO; donde decimos «alineado» o «en roadmap» queremos decir exactamente eso, no una auditoría de un tercero.

SOC 2: Diseñamos nuestros controles en línea con los Trust Services Criteria de AICPA (seguridad, disponibilidad, integridad de procesamiento, confidencialidad y privacidad). Hoy no contamos con un reporte SOC 2; la certificación está en nuestro roadmap.
ISO/IEC 27001:2022: Diseñamos nuestras medidas técnicas y organizativas (cifrado, control de acceso, gestión de riesgo) siguiendo el estándar, que es la referencia natural de seguridad razonable bajo la ley chilena. No estamos certificados ni auditados por un tercero.
ISO/IEC 42001:2023 (gobernanza de IA): El estándar de gestión de sistemas de IA encaja directamente con nuestra tesis de infraestructura agéntica y lo usamos como guía para gobernar nuestros agentes. No estamos certificados; es un objetivo declarado.
Ley 21.719 / Ley 19.628 (Chile): Operamos bajo la Ley 19.628 reformada por la Ley 21.719, con la APDP como autoridad. Estamos ejecutando el trabajo de cumplimiento (DPO, Registro de Actividades, DPA, MPI) para llegar a la vigencia plena del 1 de diciembre de 2026.
GDPR: Usamos el GDPR como estándar internacional de referencia para los derechos de los titulares y las transferencias internacionales, y alineamos nuestras prácticas a sus principios. No afirmamos una certificación ni una auditoría de cumplimiento GDPR.

Data room

Due diligence y documentación

Si estás evaluando Emisso, esto es lo que entregamos bajo NDA — material real de nuestro stack y nuestros procesos, sin vueltas.

Detalle de arquitectura y controles: La profundización técnica de todo lo que esta página resume: aislamiento por tenant, cifrado, gestión de credenciales y la superficie agéntica, con referencias al stack real.
Flujo y retención de datos: Qué datos entran al sistema, dónde viven, cuánto se conservan y cómo se eliminan — sistema por sistema, incluidas las regiones de procesamiento de cada proveedor.
DPAs y transferencia internacional: Los acuerdos de tratamiento de datos con cada subencargado y las cláusulas que amparan la transferencia internacional bajo la ley chilena.
Tu cuestionario de seguridad: Respondemos el cuestionario de seguridad de tu equipo — en tu formato o en uno estándar — con evidencia de los controles descritos, no con casillas marcadas.
Canal de vulnerabilidades: Canal directo para investigadores y equipos de seguridad, con compromiso de respuesta. Si encontraste algo, queremos saberlo.

Solicitar acceso bajo NDA

Encargados de tratamiento

Subencargados

Estos son los proveedores que procesan datos como parte del servicio. Cada uno opera bajo su propio acuerdo de tratamiento de datos (DPA) y las garantías de transferencia internacional descritas arriba.

SupabaseInfraestructura AWS · DPA →: Base de datos PostgreSQL (con Row Level Security por tenant), autenticación de usuarios (JWT) y Edge Functions. Es el núcleo de almacenamiento y aislamiento de datos de cliente.
VercelEstados Unidos · DPA →: Hosting y entrega del frontend (Next.js) y de la capa de API, con TLS y cifrado en reposo gestionados a nivel de plataforma.
OpenAIEstados Unidos · DPA →: Inferencia de modelos de lenguaje para las capacidades de los agentes. Procesa únicamente el contenido que el agente necesita para razonar; no se usa para entrenar modelos.

Transparencia

Seamos claros: Emisso no cuenta hoy con certificaciones SOC 2 ni ISO 27001, y nada en esta página debe leerse como tal. Lo que describimos son controles reales del producto, verificables en nuestro stack, y un roadmap de cumplimiento que avanzamos con transparencia. Para reportar una vulnerabilidad, solicitar documentación bajo NDA o llevar adelante un proceso de due diligence de seguridad, escríbenos a contacto@tryemisso.com y te respondemos.

Escribir a contacto@tryemisso.com