El GitLab AI Gateway se ha convertido en una pieza relevante de la arquitectura de GitLab Duo: conecta las funciones de inteligencia artificial con los servicios y modelos que utilizan los equipos de desarrollo. En octubre de 2026, una actualización de seguridad crítica ha vuelto especialmente interesante una pregunta muy concreta: ¿qué diferencias hay entre usar el gateway alojado por GitLab y desplegarlo por cuenta propia?
La respuesta no consiste en decir que una opción sea siempre mejor. La diferencia principal está en el reparto de responsabilidades. El servicio alojado reduce el trabajo de operación y parcheo del gateway; el modelo self-hosted proporciona más control, pero exige que el equipo gestione directamente versiones, infraestructura, claves, conectividad y respuesta ante vulnerabilidades.
Qué ha cambiado con la actualización de octubre de 2026
GitLab ha publicado versiones corregidas del AI Gateway tras identificar CVE-2026-90970, un fallo crítico relacionado con el procesamiento de configuraciones de flujos de Duo Agent Platform. GitLab asigna al problema una puntuación CVSS 3.1 de 9,9 y recomienda actualizar inmediatamente las instalaciones self-hosted afectadas.
Las versiones corregidas publicadas por GitLab son 19.2.4, 19.3.2 y 19.4.1. El aviso afecta a versiones anteriores dentro de las ramas indicadas por el fabricante.
Hay una diferencia importante para los clientes que utilizan el servicio gestionado: GitLab afirma que la corrección ya se ha desplegado en los AI Gateways alojados. Por eso, el incidente sirve también para entender una ventaja operativa del modelo gestionado: el proveedor puede aplicar la corrección sin que cada cliente tenga que ejecutar su propio despliegue.
Consulta el aviso oficial de GitLab sobre CVE-2026-90970 y la ficha del CVE en NVD para comprobar las versiones afectadas y corregidas.
GitLab AI Gateway self-hosted vs alojado: comparación rápida
| Criterio | Alojado por GitLab | Self-hosted |
|---|---|---|
| Parcheo del gateway | Lo gestiona GitLab | Lo gestiona el equipo interno |
| Control de infraestructura | Menor | Mayor |
| Trabajo operativo | Más reducido | Más elevado |
| Personalización | Más limitada | Más flexible |
| Control sobre el entorno | Delegado en buena parte al proveedor | Directamente bajo control de la organización |
| Respuesta ante vulnerabilidades | El proveedor aplica la corrección del servicio | Hay que identificar, actualizar y validar |
| Gestión de claves | Menos infraestructura propia | Responsabilidad del administrador |
| Modelos e infraestructura propios | Menos libertad | Mayor libertad de integración |
Qué es exactamente el AI Gateway de GitLab
GitLab describe el AI Gateway como un servicio independiente que da acceso a funciones de IA nativas de GitLab Duo. En una arquitectura self-hosted, el servicio se puede instalar como parte de la infraestructura de la propia organización.
La documentación de instalación indica que el gateway puede desplegarse mediante Docker o Helm y que intervienen servicios específicos para las funciones de Duo Agent Platform. También utiliza mecanismos de autenticación basados en tokens y claves de firma y validación.
Esto es importante desde el punto de vista de seguridad: un gateway propio no es simplemente una casilla que se marca en GitLab. Se convierte en un componente más de la infraestructura que hay que inventariar, actualizar, monitorizar y proteger.
GitLab mantiene la documentación oficial de instalación del AI Gateway, incluidos los requisitos de Docker, Helm, conectividad y configuración.
Ventajas del AI Gateway alojado
Menos componentes que mantener
La primera ventaja es operativa. El equipo no necesita encargarse de todo el ciclo de vida del servicio de gateway. Esto reduce el número de elementos que deben entrar en los procesos internos de parcheo y mantenimiento.
Respuesta más sencilla ante una actualización crítica
CVE-2026-90970 es un ejemplo claro. GitLab indica que el arreglo ya estaba desplegado en los AI Gateways alojados. Un cliente que utilice ese servicio no tiene que descargar una imagen, coordinar el despliegue del gateway y comprobar posteriormente su versión para aplicar esta corrección concreta.
Menor carga para equipos pequeños
Para una organización que quiere utilizar agentes de IA pero no dispone de un equipo dedicado a mantener toda la infraestructura de IA, delegar parte de esa operación puede ser una ventaja real.
Desventajas del AI Gateway alojado
El principal intercambio es el control. Al utilizar una infraestructura gestionada por GitLab, la organización acepta las decisiones del proveedor sobre arquitectura, disponibilidad, regiones y evolución del servicio.
Esto puede ser perfectamente válido para muchas empresas, pero no siempre encaja con entornos que tienen requisitos estrictos de residencia, aislamiento, modelos autorizados o políticas internas sobre procesamiento de información.
La documentación de GitLab explica además que la infraestructura del AI Gateway se gestiona de forma diferente según el tipo de despliegue y que el enrutamiento y los proveedores de modelos forman parte de la arquitectura del servicio.
Ventajas del AI Gateway self-hosted
Mayor control sobre la infraestructura
La organización decide dónde ejecuta el servicio, cómo lo integra con su red y qué componentes forman parte de la arquitectura. Esto resulta especialmente interesante para entornos con requisitos de segmentación o políticas internas estrictas.
Más opciones para modelos y configuraciones propias
GitLab contempla configuraciones self-hosted y escenarios híbridos para organizaciones que necesitan utilizar modelos propios o mantener un mayor control sobre el tratamiento de los datos.
Integración con políticas internas
Un gateway propio puede encajar mejor con sistemas de identidad, redes privadas, controles de salida, registros internos y procedimientos de cambio que ya utiliza una empresa.
Desventajas del AI Gateway self-hosted
El precio del control es la responsabilidad operativa. Una organización que ejecuta su propio gateway debe mantener inventarios de versiones, procesos de actualización, copias de seguridad cuando correspondan, monitorización, certificados, secretos y controles de acceso.
Además, una vulnerabilidad crítica obliga a coordinar varias tareas: confirmar si la versión instalada está afectada, preparar la actualización, desplegarla, comprobar que el servicio funciona y conservar evidencias del cambio.
Por eso, self-hosted solo aporta una ventaja real si la organización dispone de capacidad para ejercer ese control. Tener el servicio dentro de la red no es, por sí mismo, una garantía de seguridad.
Qué deben hacer los administradores de una instalación self-hosted
- Identificar el tipo de gateway. Comprueba si la instalación utiliza un AI Gateway alojado por GitLab o uno administrado internamente.
- Comprobar la versión del AI Gateway. No confundas la versión general de GitLab con la versión específica del gateway.
- Comparar con las versiones corregidas. Para CVE-2026-90970, GitLab publicó 19.2.4, 19.3.2 y 19.4.1 como versiones corregidas según la rama.
- Actualizar si la instalación está afectada. GitLab recomienda hacerlo de forma inmediata.
- Validar los flujos de Duo. Después del cambio, comprueba autenticación, conectividad y funcionamiento de las funciones que dependan del gateway.
- Revisar secretos y claves. Si una investigación interna detecta exposición, sigue el procedimiento de rotación de credenciales de la organización.
Por qué este CVE es relevante para los agentes de IA
El interés de CVE-2026-90970 no está solo en una versión concreta del software. También muestra cómo cambia el modelo de amenaza cuando una plataforma de desarrollo permite que agentes de IA trabajen con contexto y herramientas.
GitLab Duo Agent Platform está diseñado para ejecutar agentes y flujos que interactúan con proyectos, incidencias, código, pipelines y otros recursos del ciclo de vida. Cuanto mayor es la autonomía de esos agentes, más importante es separar claramente identidad, permisos, herramientas, datos y mecanismos de aislamiento.
En este contexto, el gateway debe considerarse una pieza de seguridad además de una pieza de infraestructura. Una vulnerabilidad en una capa de control puede tener consecuencias distintas a las de un fallo aislado en una interfaz de usuario.
En Bitzeta ya hemos tratado otro aspecto del mismo problema en la guía del sandbox local de GitHub Copilot y en el análisis sobre IA aplicada a ciberseguridad. El principio es común: los agentes deben operar con permisos mínimos y límites verificables.
¿Qué opción es mejor para una empresa?
Empresa pequeña o equipo con pocos recursos de infraestructura
El AI Gateway alojado suele ser más sencillo de operar. La organización puede concentrarse en las políticas de uso de los agentes sin asumir todo el ciclo de vida de una infraestructura adicional.
Empresa con requisitos fuertes de control y cumplimiento
Self-hosted puede tener más sentido cuando existen requisitos concretos sobre ubicación de datos, modelos aprobados, conectividad, segmentación o integración con infraestructura interna.
Empresa regulada
La decisión debería basarse en evidencias. No basta con preguntar si el gateway está dentro o fuera de la red corporativa. Hay que documentar quién aplica los parches, quién controla las claves, qué registros existen y cuánto tarda el equipo en responder ante una vulnerabilidad crítica.
Checklist para decidir entre alojado y self-hosted
| Pregunta | Si respondes “sí” | Opción que gana peso |
|---|---|---|
| ¿Necesitas controlar directamente la infraestructura? | La operación propia es importante | Self-hosted |
| ¿Quieres minimizar el mantenimiento? | El equipo debe centrarse en desarrollo | Alojado |
| ¿Necesitas modelos o componentes internos? | Hay requisitos específicos | Self-hosted o híbrido |
| ¿Tienes un proceso sólido de parcheo 24/7? | Puedes responder rápido ante CVE críticos | Self-hosted es más viable |
| ¿No quieres operar otra infraestructura? | Prefieres delegar el gateway | Alojado |
Conclusión
La comparación GitLab AI Gateway self-hosted vs alojado se entiende mejor como una comparación entre control y responsabilidad. El servicio alojado reduce la carga operativa y, en el caso de CVE-2026-90970, GitLab indica que la corrección ya estaba desplegada. Self-hosted ofrece más control sobre infraestructura, datos y configuración, pero exige que la organización asuma el mantenimiento y la respuesta ante vulnerabilidades.
Para una empresa sin una necesidad concreta de operar el gateway internamente, el servicio alojado simplifica la gestión. Para una organización con requisitos específicos de aislamiento, modelos propios o integración de infraestructura, self-hosted puede ser la opción adecuada si existe capacidad real para mantenerlo actualizado.
La decisión debería quedar documentada con un criterio sencillo: elige self-hosted por una necesidad de control concreta, no simplemente por la sensación de que “dentro de la red” significa más seguridad.
Preguntas frecuentes
¿Qué versiones corrigen CVE-2026-90970?
GitLab publicó las versiones 19.2.4, 19.3.2 y 19.4.1 como versiones corregidas, según la rama del AI Gateway.
¿Los usuarios de GitLab.com tienen que instalar el parche?
GitLab indica que la corrección ya se ha desplegado en sus AI Gateways alojados. Por tanto, los usuarios de ese servicio no tienen que instalar manualmente el parche del gateway.
¿Self-hosted es menos seguro que el AI Gateway alojado?
No necesariamente. Self-hosted ofrece más control, pero también traslada la responsabilidad de mantenimiento y respuesta ante vulnerabilidades al equipo que opera la instalación.
¿Qué debo revisar además de la versión?
Conviene comprobar el tipo de despliegue, la configuración de autenticación, las claves utilizadas por los servicios, la conectividad y los registros disponibles para investigar incidencias.
¿Dónde está la documentación oficial del AI Gateway?
GitLab mantiene la documentación del AI Gateway y la guía de instalación para despliegues propios.
Deja una respuesta