Verica ya está abierto. Empieza gratis →

// Centro de confianza

Seguridad por arquitectura, no por políticas.

Cómo protege Verica tus prompts, datasets y claves de proveedor. Esta página describe lo que la plataforma hace hoy — la mantenemos honesta y sincronizada con el código, no con aspiraciones. Escrita para quienes nos evalúan: líderes de ingeniería, revisores de seguridad y compras.

De un vistazo

Claves de API de proveedores (BYOK)

Protección en reposo
Cifradas — AES-256-GCM, con la clave de datos envuelta con RSA-OAEP (3072 bits).
Aislamiento
Por workspace (RLS)
Si la capa web fuera comprometida
Las claves permanecen cifradas: la capa web solo tiene la clave pública y no puede descifrarlas.

Prompts y datasets

Protección en reposo
Almacenados como datos en la base, protegidos por aislamiento de tenants.
Aislamiento
Por workspace (RLS), aplicado en la base de datos
Si la capa web fuera comprometida
Legibles solo dentro del workspace de la sesión comprometida.

Trazas de producción (observabilidad)

Protección en reposo
Contenido cifrado — el mismo sobre AES-256-GCM + RSA-OAEP que las credenciales, con PII redactada antes de sellar.
Aislamiento
Por workspace (RLS)
Si la capa web fuera comprometida
El contenido permanece cifrado: la capa web puede sellar trazas, pero no abrirlas.

Secretos y cadenas de conexión

Protección en reposo
Solo variables de entorno del lado del servidor.
Aislamiento
Por servicio (web vs. worker)
Si la capa web fuera comprometida
Nunca llegan al navegador; la clave de descifrado ni siquiera existe en el servicio web.

La aplicación expuesta a internet físicamente no puede leer tus claves de proveedor de modelos. Esa propiedad la garantiza la arquitectura — no una política.

01Protección de credenciales (BYOK)

Cuando agregas una clave de API de OpenAI, Anthropic, Google o un proveedor compatible con OpenAI, se sella con cifrado de sobre antes de tocar la base de datos: una clave de datos de 256 bits recién generada cifra tu clave con AES-256-GCM, y esa clave de datos se envuelve con RSA-OAEP (SHA-256, 3072 bits) usando una clave pública.

El par de claves RSA está dividido deliberadamente entre servicios — esa división es la parte importante:

expuesta a internet Aplicación web solo clave pública

Puede sellar credenciales nuevas, pero no tiene forma de abrirlas.

base de datos Postgres solo texto cifrado

Almacena el texto cifrado, el nonce y el tag de autenticación, la clave de datos envuelta y una huella para mostrar (sk-…AB12).

sin tráfico entrante Worker clave privada

Descifra una credencial solo en el momento de llamar al proveedor.

  • Tu clave en texto plano nunca se almacena ni se registra en logs; en la interfaz solo se muestra una huella no sensible.
  • El servicio web de producción se niega a arrancar si detecta la clave privada en su entorno.
  • Los mensajes de error de los proveedores se limpian de cadenas con forma de clave antes de persistirse.

02 Aislamiento de tenants

Verica es multi-tenant y el aislamiento se aplica en la capa de base de datos — no solo en el código de la aplicación:

  • Cada tabla de tenant tiene Row-Level Security de PostgreSQL con FORCE ROW LEVEL SECURITY, ligada al workspace activo. Una consulta sin contexto de workspace ve cero filas y las escrituras se rechazan — falla cerrado.
  • La aplicación se conecta con un rol sin privilegios de superusuario que no puede eludir RLS. Las migraciones de esquema usan un rol separado de mayor privilegio que la aplicación nunca usa en tiempo de ejecución.
  • Además de RLS, cada ruta de acceso a datos también se limita al workspace del solicitante en el código, y los trabajos en segundo plano llevan y aplican su identidad de workspace — defensa en profundidad.

03 Tus datos y tus modelos

  • Qué almacenamos: tus prompts, datasets (golden sets), resultados de evaluación, las trazas de producción que decides enviar (con el contenido redactado y cifrado, ver abajo) y las credenciales de proveedor cifradas que decides agregar.
  • A dónde van las llamadas al modelo: a tu proveedor, con tu clave. Verica es la capa de orquestación — nunca pasamos tu tráfico por una clave compartida.
  • Tus prompts y salidas nunca se usan para entrenar ningún modelo.
  • En tránsito: el tráfico hacia la aplicación y las llamadas a los proveedores de modelos viajan por HTTPS/TLS.

04 Trazas de producción (observabilidad)

Si envías trazas de producción (con los SDKs, OTLP, el proxy o n8n), el contenido sensible está protegido de extremo a extremo:

  • El receptor de trazas se autentica con tokens de API con alcance de ingesta, almacenados solo como hash SHA-256 — nunca el secreto. El payload crudo se sella con la clave pública antes de encolarse: no pasa por la cola en texto claro.
  • El worker redacta PII (correos, teléfonos, números de tarjeta) antes de persistir nada; el contenido nunca se almacena sin redactar.
  • Las celdas de entrada, salida y spans se cifran con el mismo sobre asimétrico que las credenciales: la capa web puede sellarlas, pero no abrirlas. Para mostrar una traza, la interfaz se la pide al worker por un canal interno — la clave privada nunca llega al servicio expuesto a internet.
  • En claro solo quedan metadatos operativos (modelo, proveedor, tokens, costo, latencia, tags) y previews cortos ya redactados, que alimentan los listados y la búsqueda sin descifrar nada.
  • La retención se aplica de forma automática: un barrido programado purga los cuerpos de trazas y los outputs de ejecuciones más antiguos que la ventana de retención de tu plan; las trazas fijadas quedan exentas.

05 Autenticación y acceso

  • El inicio de sesión es con código de un solo uso por correo (OTP) — no hay contraseñas que robar, reutilizar o filtrar. Las sesiones se firman del lado del servidor.
  • Cada usuario pertenece a un workspace mediante una membresía explícita con un rol (admin / editor / viewer); el rol y el workspace se resuelven en cada solicitud.
  • Todos los secretos viven como variables de entorno del lado del servidor; lo único expuesto al navegador es la URL pública de la aplicación. Cada servicio valida su entorno al arrancar y falla rápido ante una mala configuración — incluida la verificación de que los secretos exclusivos del worker nunca aparezcan en la capa web.

06 Subprocesadores

Estos son los proveedores que procesan datos en nombre de Verica hoy. Actualizamos esta lista cuando incorporamos o cambiamos un proveedor.

  • Railway (EE. UU.) — alojamiento en la nube e infraestructura gestionada, incluida la base de datos y este sitio web.
  • Cloudflare R2 (EE. UU.) — almacenamiento de imágenes de datasets y de los backups de base de datos fuera de la plataforma; los backups se cifran con AES-256 antes de subirse.
  • Google Analytics (EE. UU.) — analítica de tráfico del sitio de marketing verica.app; no se usa dentro de la aplicación.
  • Calendly (EE. UU.) — agenda de demos y sesiones, solo si eliges reservar una.
  • Proveedores de modelos (OpenAI, Anthropic, Google u otros compatibles) — reciben las entradas y salidas de las evaluaciones que ejecutas, mediante tu propia clave (BYOK); tú eliges cuáles conectar.

07 Ubicación de datos, backups e incidentes

  • Los datos se alojan en Railway, una plataforma de nube gestionada, en la región US West (California, Estados Unidos). Aún no ofrecemos opciones de residencia regional de datos.
  • Los backups operan en tres capas: recuperación a un punto en el tiempo (PITR) continua sobre la base de datos, que permite restaurar a cualquier momento dentro de una ventana de aproximadamente un mes; backups diarios programados del volumen en la plataforma de alojamiento; y un backup completo semanal, cifrado con AES-256 antes de salir de nuestra infraestructura, almacenado en un object storage independiente (Cloudflare R2, Estados Unidos) y conservado por 90 días.
  • La copia semanal fuera de la plataforma es deliberadamente independiente: sobrevive a una falla a nivel de cuenta de la plataforma de alojamiento, y su clave de descifrado se custodia separada de ambas plataformas. Los simulacros de restauración se ejercitan trimestralmente: en el último (agosto de 2026), un dump completo se descifró, se verificó su integridad y se restauró en segundos con el volumen de datos actual.
  • Objetivos de recuperación a la escala actual: pérdida de datos cercana a cero (RPO) vía PITR mientras la plataforma está disponible, y de como máximo siete días si solo sobrevive la copia externa; tiempo de recuperación (RTO) de horas para una reconstrucción completa de la plataforma.
  • Si un incidente de seguridad afecta materialmente tus datos, te lo notificaremos sin demoras indebidas, conforme a la ley aplicable, y compartiremos lo que sepamos a medida que investigamos.

08 Lo que (todavía) no afirmamos

Preferimos que lo sepas aquí y no en una llamada posterior:

  • El contenido de prompts y datasets no está cifrado a nivel de columna (el de las trazas de producción sí — ver arriba). Está protegido por el aislamiento de tenants y por el cifrado en reposo de la base de datos y los discos gestionados — el cifrado del contenido a nivel de aplicación con claves gestionadas por el cliente está en el roadmap, no publicado.
  • El cifrado de discos y volúmenes en reposo lo provee la plataforma de alojamiento gestionada; no es algo que Verica implemente por sí misma.
  • Aún no contamos con certificación SOC 2 ni ISO 27001, y no tenemos un programa formal de recompensas por errores. Con gusto guiamos a cualquier revisor de seguridad por la arquitectura directamente.

09 Divulgación responsable

Si crees que encontraste un problema de seguridad, escribe a [email protected] con los detalles y los pasos para reproducirlo. No publiques issues públicos por vulnerabilidades sospechadas y danos un plazo razonable para responder antes de cualquier divulgación. Confirmaremos tu reporte y te mantendremos al tanto de la corrección.