Seguridad y cumplimiento

Con BYOK, las claves de API viven solo en la memoria del gateway y nunca se persisten ni se transmiten.

Las solicitudes pasan por el gateway directamente a las API de los proveedores; los datos permanecen dentro de su red privada de extremo a extremo.

GateLLM no almacena, no entrena con ni pone en caché el contenido de las solicitudes.

TLS 1.3 de extremo a extremo.

Claves solo en memoria; al reiniciar, se inyectan desde sus secretos y nunca desde el disco.

Control de admisión de clientes: filtre por User-Agent con políticas diferenciadas.

Listo para RGPD / CCPA / DPA.

Controles alineados con SOC 2 Type II / ISO 27001 (certificación en preparación).

SSO (OIDC: Azure AD / Okta / genérico, más SAML 2.0 + SCIM 2.0).

Registros de auditoría a nivel de solicitud, exportables a los sistemas internos de operaciones y facturación.

Facturación tolerante a fallos: reservar → liquidar → reembolsar; la facturación sigue siendo correcta ante caídas del proceso gracias a un libro de movimientos en curso y a la auditoría por solicitud.

API de gestión para administrar programáticamente cuotas, presupuestos, uso y costo.

Capa de red: el proceso del gateway se despliega dentro de su VPC o centro de datos local; el tráfico entrante y saliente lo controlan los grupos de seguridad o las políticas de red que usted configure; las solicitudes van directamente a las API oficiales de los proveedores de modelos downstream, sin pasar por ningún servidor de relé del Procesador.

Capa del proceso del gateway: diseño sin estado; las claves se cargan desde la configuración cifrada en memoria y nunca se persisten; cualquier réplica puede atender cualquier solicitud, lo que permite escalado horizontal y conmutación por error instantánea; al reiniciar, las claves se vuelven a inyectar desde sus secretos.

Capa de claves: las claves BYOK de los proveedores de modelos viven solo en la memoria del proceso del gateway, nunca se escriben en almacenamiento persistente y el personal de operaciones no puede leerlas en texto claro; el control de admisión de clientes filtra por User-Agent con políticas diferenciadas.

Capa de datos: los prompts y las finalizaciones en tiempo de ejecución no se persisten en los sistemas del Procesador (se reenvían en memoria, no se persisten); los datos de cuenta y licencia en reposo están cifrados con AES-256; la política de retención de los registros de auditoría la determina su equipo de operaciones.

Capa de facturación: facturación tolerante a fallos (reservar → liquidar → reembolsar), que sigue siendo correcta ante caídas del proceso gracias a un libro de movimientos en curso y a la auditoría por solicitud.

Preocupación por un acceso excesivo a la IA: GateLLM la aborda con un despliegue totalmente autoalojado + BYOK; las claves y los prompts nunca salen del límite de su red; usted controla por completo qué modelos usar y a qué proveedor enrutar, sin IA oculta ni subencargados invisibles (consulte la Lista de subencargados).

Datos usados para entrenamiento: el Procesador no entra en contacto con los datos de los prompts; si un proveedor de modelos downstream entrena o no lo determina su política, que puede revisar en la matriz de uso de datos de la Lista de subencargados antes de contratar: totalmente opcional.

Transferencias internacionales: los datos de cuenta del Procesador se transfieren a terceros países mediante SCC / IDTA; las transferencias a proveedores downstream las realiza usted directamente con las garantías adecuadas (Sección 11 del DPA).

Fuga de claves: las claves viven solo en memoria y nunca se persisten ni se transmiten; el SSO delega el MFA y la gestión de sesiones a su IdP existente, de modo que las credenciales no se fragmentan.

Las pruebas de penetración independientes por terceros de GateLLM están en preparación (el alcance y las reglas del ejercicio ya están listos), cubren el proceso del gateway, la autenticación y autorización, las Edge Functions, el gateway de API y las rutas de gestión de claves; se publicará un resumen en la Sección 7 de la Política de divulgación de vulnerabilidades una vez completadas.

Política de divulgación responsable de vulnerabilidades: reporte a security@gatellm.io (con soporte PGP), acuse de recibo en 24 horas y remediación según la severidad CVSS (Crítica 7 días / Alta 30 días / Media 60 días / Baja 90 días).

Se proporciona una lista de materiales de software (SBOM); las dependencias se analizan con regularidad en busca de vulnerabilidades conocidas y los parches de seguridad se anotan con sus ID de CVE en el registro de cambios.