)
Última actualización: 21 de octubre, 2026
¿Cómo se despliega un self-hosted AI gateway? Ejecutas el data plane del gateway dentro de tu propio clúster de Kubernetes, apuntas tus aplicaciones hacia él y mantienes prompts, claves de proveedor y logs en una infraestructura que controlas. Esta guía recorre esa configuración para Agent Gateway (TrustGate), paso a paso, con la documentación pública de despliegue de NeuralTrust de octubre de 2026.
Cada comando procede de la documentación.
TL;DR: Puntos clave
- Según la documentación de despliegue de NeuralTrust (2026), hay 3 modelos de self-hosting, desde un data plane Private hasta una instalación totalmente autoalojada.
- Un data plane Private independiente necesita Redis y PostgreSQL, y 2 puntos de entrada: el puerto 8081 para tráfico LLM y el 8082 para MCP (requisitos).
- La instalación requiere 2 Secrets de Kubernetes y 1 comando de Helm (Deploy TrustGate).
- Los workloads de proxy y MCP arrancan con 2 réplicas y el autoescalado viene desactivado por defecto (alta disponibilidad).
- OWASP sitúa la prompt injection en primer lugar entre 10 riesgos de LLM, así que una red privada no basta (OWASP, 2025).
| Modelo | Quién ejecuta qué | Ideal para |
|---|---|---|
| SaaS | NeuralTrust ejecuta ambos planos | Empezar rápido, plan gratuito, sin infraestructura |
| Private (hybrid) | Tú ejecutas el data plane y NeuralTrust el control plane | Los prompts deben quedarse en tu red |
| External (self-hosted) | Tú ejecutas todo | Entornos aislados o residencia estricta |
¿Qué modelo de self-hosted AI gateway te conviene?
Un self-hosted AI gateway se divide en un data plane, que transporta las peticiones, y un control plane, que guarda la configuración y la consola. Los modelos se distinguen por dónde se ejecuta cada plano.
En el modelo Private, el data plane corre en tu clúster y recibe su configuración del control plane de NeuralTrust. Tu clúster abre la conexión, así que nada se empuja desde fuera. Los prompts y respuestas en bruto se quedan en tu PostgreSQL y solo se exportan metadatos, según la guía Hybrid (2026).
En el modelo External, ejecutas ambos planos, la consola y la pila de analítica. La documentación lo plantea para entornos aislados o de residencia de datos estricta, y requiere al menos 4 nodos de 8 vCPU y 32 GiB.
Esta guía cubre el modelo Private, la forma más rápida de mantener los prompts dentro de tu red. Hemos construido los pasos a partir de la documentación pública de octubre de 2026, y los marcadores como <VERSION> se quedan como marcadores.
Requisitos previos y dimensionado
| Requisito | Detalle |
|---|---|
| Clúster de Kubernetes | Al menos 2 nodos de 8 vCPU y 16 GiB cada uno |
| Redis | Obligatorio. Se usa para limitación de tasa y caché semántica. Redis OSS es suficiente |
| PostgreSQL | Obligatorio. Mínimo de producción: 2 vCPU, 4 GiB de RAM y 20 GiB de almacenamiento |
| Ingress controller y DNS | Entrada pública por el 443, con nombres de host que controles |
| Clave de registro | Necesaria para descargar la imagen. Se emite con una oferta enterprise (support@neuraltrust.ai) |
| Acceso saliente | HTTPS hacia los hosts de config sync y telemetría de NeuralTrust, tus proveedores de LLM y tu registro |
| Acceso entrante | HTTPS a tus puntos de entrada desde la IP de origen de la consola |
Kafka, una base de datos vectorial, un service mesh y nodos con GPU no son necesarios, según la página de requisitos.
La clave de registro importa si contabas con una vía gratuita. El plan gratuito de la AI Gateway funciona como SaaS, mientras que un data plane Private necesita la clave, así que contacta antes con el equipo.
)
Paso a paso: despliega el gateway en Kubernetes
Este recorrido sigue la página Deploy TrustGate, desde un namespace vacío hasta una petición enrutada.
Paso 1: prepara el namespace y el pull secret
Crea el namespace y el Secret de descarga de imágenes con la clave de registro que recibiste.
Descarga también las fuentes del chart para tener a mano el archivo de valores de ejemplo: helm pull <chart-ref> --version <VERSION> --untar.
Paso 2: crea el gateway en la consola
En la consola, abre TrustGate, elige New Gateway, ponle nombre y selecciona Private y Kubernetes. Copia CONFIG_SYNC_TOKEN y el JWT de enrolamiento del DataAgent desde el asistente, y guarda en secreto el archivo de valores generado.
Paso 3: crea los dos Secrets
No crees CONFIG_SYNC_LKG_KEY. El chart la genera.
Paso 4: define los valores del clúster
Escribe un archivo de valores pequeño con tu plataforma y tu dominio.
En producción, define global.postgresql.deploy: false y global.redis.deploy: false, y indica el host de cada uno. La documentación describe los almacenes dentro del clúster como una opción por defecto pensada para pruebas de concepto (configuración).
Paso 5: instala con Helm
El archivo de ejemplo activa TrustGate y conecta ambos Secrets. Fija <VERSION> para una instalación reproducible.
Paso 6: expón los puntos de entrada LLM y MCP con TLS
Usa nombres de host distintos. La URL LLM apunta al puerto 8081 y la URL MCP al 8082.
| Servicio | Nombre de host | Puerto |
|---|---|---|
| Tráfico LLM | gateway.<domain> | 8081 |
| Tráfico MCP | mcp.<domain> | 8082 |
Apunta el DNS a tu ingress y luego introduce ambas URL completas, con https://, en Settings, Agent Gateway, General de la consola. No inicialices las dos desde una sola URL. La guía Hybrid advierte de que eso rompe MCP en silencio: las llamadas a herramientas nunca se resuelven y no aparece ningún error.
Termina el TLS en el ingress. Un gestor de certificados como cert-manager puede emitirlos mediante una anotación del Ingress. Si hay un proxy que intercepta TLS en tu salida a internet, aporta su CA con configSync.tlsCa. No uses nunca configSync.tlsInsecure, que los entornos desplegados rechazan.
Paso 7: crea una aplicación y envía la primera petición
En la consola, añade un proveedor de modelos y prueba la conexión; después crea una aplicación y emite su clave. La clave se muestra una sola vez, así que cópiala. La credencial del proveedor se queda en el gateway y quien llama solo tiene su propia clave. Envía una petición con el snippet de Connect:
Los clientes que solo aceptan una URL base y una API key pueden enviar la clave como cabecera Authorization: Bearer, según el quickstart. Para tráfico de herramientas, añade un servidor MCP en el registro y asígnalo a una aplicación. Para usar tokens de un proveedor de identidad en lugar de claves estáticas, abre los ajustes Auth de la aplicación. Nuestra guía de autenticación MCP cubre las opciones.
Verifica, observa y resuelve problemas del gateway
Empieza con kubectl get pods -n neuraltrust y kubectl get ingress -n neuraltrust. Deberías ver listos los workloads agentgateway-proxy, agentgateway-mcp y dataagent.
Un pod que está en Running pero nunca llega a Ready suele indicar que falla el config sync. La guía Hybrid enumera tres causas, por orden: un token incorrecto o con espacios al final, la salida bloqueada hacia *.neuraltrust.ai por el puerto 443, o un proxy que intercepta TLS cuya CA no es de confianza. Un data plane que no alcanza esos hosts puede arrancar con normalidad y aun así dejar de recibir actualizaciones, así que prueba la conectividad desde dentro del clúster.
Después prueba el comportamiento. Envía una petición permitida y otra bloqueada, y confirma que ambas decisiones aparecen en la consola. La vista Activity muestra estado, modelo, latencia, tokens y un ID de traza por petición.
Revisa también el reparto de telemetría. En el modelo Private, los prompts y respuestas en bruto van a tu PostgreSQL mediante TELEMETRY_EXPORTERS_RAW=postgres, y los metadatos van a NeuralTrust por OTLP mediante TELEMETRY_EXPORTERS_METADATA=otlp. Si falta un exporter, falla en silencio, así que confirma ambos.
Escala y mantén disponible el gateway
Escala la ruta de peticiones añadiendo réplicas. Los recuentos de nodos documentados son mínimos de planificación, no cifras de rendimiento, así que mide con tu propia carga.
| Ajuste | Valor por defecto | Recomendación |
|---|---|---|
agentgateway.dataPlane.replicas | 2 | Súbelo según el tráfico |
agentgateway.mcp.replicas | 2 | Súbelo según el tráfico de herramientas |
dataagent.replicas | 1 | Mantenlo en 1 |
autoscaling.enabled | false | Déjalo desactivado salvo que necesites capacidad |
Los DataAgent duplicados registran flujos duplicados, por eso se queda en 1. Activa los pod disruption budgets con global.highAvailability.podDisruptionBudget.enabled: true para que el vaciado de nodos no elimine todas las réplicas a la vez. La guía de alta disponibilidad define cuatro niveles, y el primero requiere pools de nodos en tres zonas con PostgreSQL y Redis gestionados.
Prevé también una caída del control plane. Según la documentación de config sync (2026), un pod en marcha sigue sirviendo su última configuración válida y registra un aviso de obsolescencia pasadas 24 horas. La caché vive en un emptyDir, así que un pod que se reinicia sin conexión con el control plane no carga su snapshot y no llega a Ready.
Seguridad y gobernanza de un self-hosted AI gateway
El self-hosting te da el control de los datos. No elimina los riesgos que llegan a un gateway a través de prompts, herramientas y claves. Según OWASP (2025), entre los principales riesgos de los LLM están la prompt injection (LLM01), la divulgación de información sensible (LLM02), la agencia excesiva (LLM06) y el consumo sin límites (LLM10). Una red privada no resuelve ninguno por sí sola.
Refuerza cuatro puntos. Secrets: la documentación de Kubernetes recomienda cifrado en reposo y RBAC de mínimo privilegio (docs de Kubernetes). Para GitOps, crea previamente todos los Secrets y define global.autoGenerateSecrets: false con global.preserveExistingSecrets: true. Red: permite solo los hosts de salida documentados y limita quién alcanza los puntos de entrada, recordando que la IP de origen de la consola debe estar entre ellos. Claves: mantén las credenciales de proveedor en el gateway y da a cada aplicación su propia clave. Acceso: usa un proveedor de identidad siempre que puedas.
Después añade políticas. Agent Gateway (TrustGate) aplica límites de tasa, presupuestos y guardrails, y el modo Enforce rechaza las llamadas que incumplen una política. Los presupuestos y los límites de tasa responden directamente al consumo sin límites. En una instalación Hybrid completa, el gateway también llama a Agent Runtime Security (TrustGuard), que a su vez llama a un firewall de ML, dentro del Runtime Security Mesh de NeuralTrust. Para más contexto, lee qué es un AI gateway y en qué se diferencia de un MCP gateway.
¿Self-hosted o gestionado? Cómo elegir
Elige según tus reglas de datos y tu capacidad operativa. La tabla asocia situaciones habituales con un modelo.
| Tu situación | Elige |
|---|---|
| Quieres probar el gateway esta semana | SaaS, con el plan gratuito |
| Los prompts no pueden salir de tu red, pero una consola gestionada es aceptable | Data plane Private |
| Entorno aislado, o sin permiso para depender de un servicio del proveedor | External (totalmente autoalojado) |
| Los datos deben quedarse en la UE o en EE. UU., sin equipo de infraestructura | Servicio gestionado, alojado en la UE o en EE. UU. |
| Residencia solo en el Reino Unido, metadatos incluidos | External, ejecutado en tu propio entorno en el Reino Unido |
El servicio gestionado puede alojarse en la UE o en EE. UU. Para residencia solo en el Reino Unido, ejecuta la plataforma en tu propio entorno británico. En el modelo Private, los metadatos siguen llegando a los hosts de telemetría de NeuralTrust en la UE o en EE. UU., mientras que el modelo External no tiene ningún requisito de red hacia NeuralTrust.
El self-hosting te cuesta operación: actualizaciones, certificados, copias de seguridad y guardias. La documentación no describe los pasos de actualización de una instalación independiente de TrustGate, así que confirma ese proceso con el soporte de NeuralTrust.
Conclusión
Un self-hosted AI gateway se reduce a tres decisiones: qué modelo encaja con tus reglas de datos, si tu clúster cumple los requisitos y quién se encarga de la operación. Para los equipos que necesitan los prompts dentro de su red, un data plane Private lo consigue en siete pasos y un comando de Helm. Añade almacenes gestionados, políticas y un plan de recuperación probado antes de que llegue el tráfico de producción.
Protege tu AI gateway en producción con NeuralTrust
Empieza con el plan gratuito en SaaS para ver el gateway en marcha y después lleva el data plane a tu clúster.
)
Guías relacionadas
Preguntas frecuentes sobre self-hosted AI gateway
1. ¿Qué es un self-hosted AI gateway?
Un self-hosted AI gateway enruta y gobierna el tráfico LLM y MCP desde una infraestructura que ejecutas tú. Las aplicaciones lo llaman en lugar de llamar directamente a los proveedores de modelos, y las claves de proveedor, los prompts y los logs se quedan en tu entorno.
2. ¿Necesito Kubernetes para alojar un AI gateway?
Para la instalación documentada de NeuralTrust, sí. El data plane Private y la instalación External se despliegan con un chart de Helm en Kubernetes. El quickstart menciona opciones con Docker y manuales, pero esta guía solo cubre la vía de Kubernetes.
3. ¿Qué infraestructura necesita un self-hosted AI gateway?
Un data plane independiente necesita al menos 2 nodos de 8 vCPU y 16 GiB cada uno, Redis, PostgreSQL, un ingress controller y DNS. Kafka, una base de datos vectorial y las GPU no son necesarios.
4. ¿Es gratis un self-hosted AI gateway?
El plan gratuito de la AI Gateway de NeuralTrust funciona como SaaS. Un data plane Private necesita una clave de registro que NeuralTrust emite con una oferta enterprise. Presupuesta también nodos, almacenes gestionados y tiempo de operación.
5. ¿El self-hosting mantiene mis prompts en privado?
En el modelo Private, los prompts y respuestas en bruto se quedan en tu PostgreSQL y a NeuralTrust solo llegan metadatos. En el modelo External, nada sale de tu entorno.
6. ¿Qué pasa si el control plane se cae?
Un data plane en marcha sigue sirviendo su última configuración válida y registra un aviso pasadas 24 horas. Un pod que se reinicia sin acceso al control plane no llega a Ready, así que evita reinicios durante una caída.
Sobre el autor
Roger Howroyd es Head of Global SEO and AI en NeuralTrust, donde lidera la estrategia de búsqueda de la compañía en SEO, AEO, GEO y optimización para LLM. Se especializa en búsqueda con IA, estrategia de contenidos y SEM. Conecta en LinkedIn.
NeuralTrust es la plataforma líder para proteger y escalar agentes de IA. Reconocida como Pioneer en el Gartner Emerging Market Quadrant for AI Application Security 2026, presente en cuatro informes Gartner Hype Cycle en 2026 y destacada en el Gartner Market Guide for Guardian Agents 2026, el Gartner Market Guide for AI Gateways 2025 y el KuppingerCole Leadership Compass for Generative AI Defense 2025. Sede en Barcelona con oficinas en Londres y Nueva York. Certificada ISO 27001.
Fuentes
- NeuralTrust Docs: Deployment overview (consultado en octubre de 2026)
- NeuralTrust Docs: Hybrid deployment (consultado en octubre de 2026)
- NeuralTrust Docs: Deploy TrustGate (consultado en octubre de 2026)
- NeuralTrust Docs: Requirements and dependencies (consultado en octubre de 2026)
- NeuralTrust Docs: Config sync (consultado en octubre de 2026)
- NeuralTrust Docs: High availability (consultado en octubre de 2026)
- NeuralTrust Docs: Configuration (consultado en octubre de 2026)
- NeuralTrust Docs: TrustGate quickstart (consultado en octubre de 2026)
- OWASP Top 10 for LLM Applications 2025 (consultado en octubre de 2026)
- Kubernetes Docs: Good practices for Kubernetes Secrets (consultado en octubre de 2026)