Diseñado para el revisor de InfoSec empresarial.

Row-Level Security (RLS) en cada tabla de todos los esquemas de tenant. Las políticas de RLS comparan organization_id con el claim del JWT del usuario vía current_user_org_id(); en las rutas que se ejecutan bajo el rol restringido de base de datos, las lecturas y escrituras cross-tenant se bloquean en la propia base de datos, y toda consulta del lado del servidor se filtra además por organization_id — verificado por un CI lint de org-scoping en todos los esquemas de tenant. El cliente del navegador con clave anónima devuelve cero filas de cualquier esquema multi-tenant. Las nuevas tablas requieren RLS en la misma migración (guardrail de CI).

PRUEBA →RLS respaldado por JWT vía current_user_org_id() · SELECT anónimo revocado · CI lint de org-scoping

Múltiples salvaguardas independientes. Wrapper de cliente con scope a nivel de aplicación (orgId es invariante del constructor). Grep en CI (check-learning-scope.ts) que falla la build si cualquier archivo fuera de lib/learning/ toca el esquema. RLS estricto a nivel de BD con FORCE ROW LEVEL SECURITY y política basada en variable de sesión. El código de aplicación llega al SDK de Anthropic por un único punto de paso (lib/intelligence/llm/anthropic.ts, con lib/anthropic.ts como shim de retrocompatibilidad), y check-anthropic-choke.ts falla la build ante cualquier import fuera de una lista breve y comentada; check-no-training.ts garantiza que no haya headers de fine-tuning. Sin entrenamiento agrupado. Sin consultas entre tenants. Nunca.

PRUEBA →lib/learning/client.ts · scripts/ci/check-learning-scope.ts · learning schema FORCE RLS

Todos los datos en reposo cifrados por Supabase (AES-256). Todo el transporte con TLS 1.2+, HSTS preload. CSP con nonce por solicitud (sin scripts unsafe-inline). Los campos financieros sensibles (coste de BOM, sourcing, lead times) y los refresh tokens OAuth de integraciones externas llevan una capa adicional de cifrado AES-256-GCM a nivel de aplicación en reposo. Las claves se gestionan mediante cifrado de sobre en GCP KMS con rotación cada 90 días; cada escritura nueva pasa por KMS y las filas anteriores al corte se están reenvolviendo con un proceso de backfill. Sin datos de cliente en el edge de Vercel más allá de las páginas públicas de marketing en caché del CDN.

PRUEBA →Vercel (US primario) · Supabase (US East) · TLS 1.2+ en todo

Todos los datos de cliente se procesan y almacenan en una única región de EE. UU. — Supabase y Vercel, ambos en us-east-2. No se ofrece actualmente residencia de datos en la UE ni en otras regiones.

PRUEBA →Solo US hoy · Supabase + Vercel us-east-2