Revisión de código con IA local en entornos air-gapped

En pocas palabras: Un contratista de defensa con 200.000 líneas de código anuales y 12 ingenieros desplegó un LLM local en un entorno completamente aislado, sin internet. El modelo analiza pull requests y sugiere cambios sin exponer una sola línea fuera de la red, y superó la auditoría de compliance.

Un contratista de defensa con 200.000 líneas de código por año y doce ingenieros que ya no daban abasto. El oficial de seguridad dijo que no —y cuando un tipo con ese cargo dice que no, es no—. Nada de APIs cloud, nada de SaaS, nada de que los datos salgan del edificio. La solución que armó el equipo fue desplegar un modelo de código abierto completamente local, en una red aislada, sin conexión a internet. Y pasó la auditoría de compliance.

La revisión de código con IA local es el proceso de ejecutar un modelo de lenguaje de gran tamaño en hardware propio y dentro de una red sin salida a internet, para analizar, comentar y sugerir mejoras en pull requests sin que una sola línea de código abandone la infraestructura de la organización. Es la alternativa para entornos donde la nube no es una opción —no por capricho, sino por regulación, secreto industrial o requisitos militares—.

¿Por qué desplegar IA local en vez de usar la nube?

Porque a veces no podés. Así de simple. El caso que describe la guía es el ejemplo perfecto: un contratista de defensa manejando código clasificado. El oficial de seguridad evaluó las opciones cloud y las descartó todas. No era “quizás con algunas modificaciones”, no era “revisemos la política de manejo de datos”. Era un no rotundo.

En entornos air-gapped —redes físicamente desconectadas de internet— la promesa de “tu código está seguro en nuestra nube” no aplica. No hay forma de enviar datos a una API externa sin violar la política de seguridad más básica. Si alguna vez trabajaste en banca, defensa, farmacéutica o infraestructura crítica, sabés de lo que hablo: ciertos datos no cruzan cierto perímetro, y punto.

El equipo tenía doce ingenieros revisando manualmente más de 200.000 líneas por año. La calidad de revisión se resentía —es lo que pasa cuando el volumen crece y la cantidad de ojos no—, justo el problema que la revisión de código con IA resuelve. Pero no podían usar ninguna herramienta cloud. La única salida era traer el modelo adentro.

¿Qué hardware necesitás para ejecutar un modelo de IA localmente?

La guía recomienda, para equipos de menos de 25 ingenieros, un servidor con 2 GPUs NVIDIA A100 de 80 GB corriendo un modelo de 70B parámetros cuantizado a 4 bits. Esto maneja de 15 a 25 PRs por día con una latencia aceptable (30–60 segundos). Para equipos de 25–75 ingenieros se necesitan dos servidores de inferencia con 4x A100 cada uno, detrás de un balanceador de carga. A mayor escala, se requiere un clúster dedicado con escalado horizontal. Para más detalles técnicos, mirá los riesgos de exponer secretos de CI/CD.

Ojo con esto: la VRAM es el cuello de botella número uno. Si el modelo no entra completo en la memoria de la GPU, la inferencia se va a CPU y los tiempos de revisión se disparan. Nadie quiere esperar cinco minutos por cada comentario en un PR (y menos cuando tenés doce ingenieros mandando código todo el día).

¿Cómo elegir el modelo de IA adecuado para code review local?

No todos los modelos sirven para revisar código, y no todos los que sirven corren en hardware razonable. La decisión se reduce a tres variables: calidad de revisión, latencia y tamaño del modelo. Y se eligen dos (sí, es un trilema clásico de ingeniería).

El equipo optó por un modelo de 70B parámetros cuantizado. Este tipo de modelos ha demostrado muy buen rendimiento en tareas de análisis de código, detección de bugs sutiles y sugerencias contextuales. En un entorno air-gapped, donde no podés hacer A/B testing contra APIs cloud cada cinco minutos, la consistencia del modelo importa más que el puntaje bruto en un benchmark.

Los modelos de código abierto con pesos disponibles —como los basados en Llama, CodeLlama o DeepSeek-Coder— también son viables y tienen la ventaja de que se pueden afinar con reglas propias. La contra es que requieren más trabajo de puesta a punto. La elección final dependerá del presupuesto de hardware, la calidad deseada y las horas de ingeniería que el equipo pueda dedicar.

¿Cómo configurar el servidor de inferencia sin conexión a internet?

El servidor de inferencia es la pieza que carga el modelo en memoria y expone una API —interna, obvio— para que otras herramientas le manden código y reciban la revisión. En entornos air-gapped, esto implica un paso extra que en setups normales no existe: conseguir todas las dependencias, pesos del modelo, tokenizadores y configuraciones sin acceso a internet, empaquetarlas en un medio físico o un repositorio espejo autorizado, y recién ahí desplegar.

Se pueden usar servidores de inferencia como vLLM u Ollama. Ollama es más simple para empezar —básicamente un binario que cargás con el modelo y expone una API REST—. vLLM te da mejor rendimiento bajo carga concurrente gracias a PagedAttention, pero tiene más complejidad de configuración. Relacionado: nuestra comparativa de pipelines CI/CD para 2026.

Los pasos generales son: preparar el hardware con GPU y drivers (otro dolor de cabeza sin internet, porque los drivers de NVIDIA no se bajan solos), transferir los artefactos del modelo vía medios aprobados, instalar el servidor de inferencia desde un paquete offline, cargar el modelo en VRAM, validar que responda correctamente con un conjunto de prueba interno, y exponer la API solo en la red aislada.

¿Cómo integrar la revisión de código con IA en pipelines CI/CD locales?

Una vez que el modelo está sirviendo, lo que querés es que cada pull request dispare una revisión automática. Sin que nadie tenga que acordarse de pedirla.

En entornos air-gapped, GitLab CI/CD autogestionado o Jenkins son las opciones más comunes. Se puede configurar un job en el pipeline que, al abrirse o actualizarse un merge request, tome el diff del PR, lo envíe al endpoint de inferencia local, reciba los comentarios y los publique como notas en el PR.

¿Qué arquitectura de seguridad implementaron para pasar la auditoría?

Pasaron la revisión de compliance. En un entorno clasificado, eso no es un detalle —es la diferencia entre que el proyecto exista o se archive en un cajón—.

La arquitectura se apoya en la red air-gapped donde corre el servidor de inferencia, más medidas de protección de datos que garantizan que el código y los resultados nunca salgan del perímetro controlado. Este nivel de control fue suficiente para cumplir con los requisitos de la auditoría.

Comparado con una solución cloud —donde confiás en la política de privacidad del proveedor y en que el vendor no va a entrenar con tus datos—, acá el control es total. Nadie fuera de la organización tiene acceso al modelo, a los prompts ni a las respuestas. Para ciertos sectores, eso es el único camino viable. Te puede servir nuestra cobertura de el análisis detallado entre Jenkins y GitHub Actions.

Modelos locales para code review

En un entorno air-gapped, las opciones se limitan a modelos de peso abierto que se puedan descargar, transferir por medios físicos y ejecutar sin depender de servicios externos. Los modelos de código abierto ofrecen flexibilidad y no requieren licencias, aunque demandan más trabajo de configuración y ajuste fino. Servicios como Copilot quedan directamente descartados porque necesitan conectividad permanente.

Caso real: 200.000 líneas, 12 ingenieros y una red que no toca internet

El caso que disparó la guía vale la pena repasarlo en detalle. Un contratista de defensa —el nombre no se menciona, por razones obvias— tenía un equipo de doce desarrolladores produciendo más de 200.000 líneas de código por año. La revisión manual no daba abasto: la calidad de los code reviews bajaba, los PRs se acumulaban, y la deuda técnica empezaba a ser un problema real.

El equipo evaluó herramientas de revisión con IA. Las opciones cloud prometían resolver el problema técnico pero creaban uno de seguridad mucho más grande. La decisión de ir por una solución on-premise no fue un lujo —fue la única que pasó el filtro del oficial de seguridad—. Desplegaron el modelo localmente, integraron la revisión automática en sus pipelines de CI/CD autogestionados y lograron que cada merge request recibiera comentarios automáticos en minutos, sin que una sola línea de código abandonara el edificio.

¿El resultado? La auditoría de compliance aprobada y un equipo que recuperó horas de revisión manual para dedicarlas a lo que importa. El artículo que documenta esta experiencia es básicamente la guía que ellos hubieran querido tener cuando arrancaron el proyecto.

Errores comunes al desplegar revisión de código con IA local

Habiendo visto varios equipos pasar por esto (y habiendo metido la pata yo mismo en más de uno), estos son los errores que te conviene esquivar:

Subestimar la VRAM necesaria. El modelo ocupa lo que ocupa, y si no entra en GPU, la latencia te mata la experiencia. Medí dos veces, comprá una vez. Y acordate de que necesitás margen para el contexto: si revisás PRs de 500 líneas, el prompt pesa más que si revisás cambios de 20 líneas.

No validar el modelo antes de integrarlo al pipeline. Mandarle código clasificado a un modelo que no probaste bien es jugar con fuego. Armate un conjunto de pruebas interno con código representativo, ejecutalo contra el modelo, revisá los resultados a mano. Si el modelo alucina imports que no existen o sugiere patrones inseguros, mejor enterarse en testing que en producción.

Olvidar los costos de mantenimiento. Un modelo local no se actualiza solo. Las dependencias, los parches de seguridad, la rotación de logs, el monitoreo de la GPU —todo eso requiere tiempo de alguien del equipo—. Si pensás que es “instalar y olvidarse”, el primer incidente te va a bajar de un hondazo.

No segmentar la red correctamente. Poner el servidor de inferencia en la misma VLAN que las estaciones de trabajo es un error. Si la red está air-gapped por compliance, la segmentación interna también importa. El servidor de inferencia debería estar en un segmento separado, con acceso solo desde los runners de CI/CD y nada más.

Preguntas Frecuentes

¿Cómo instalar un modelo de IA en un entorno sin internet?

Necesitás obtener los artefactos del modelo (pesos, tokenizador, configuración) y las dependencias del servidor de inferencia desde un entorno con conectividad, empaquetarlos en un medio físico o repositorio espejo autorizado, y transferirlos al entorno air-gapped siguiendo los procedimientos de seguridad de la organización. Una vez adentro, instalás el servidor de inferencia (por ejemplo vLLM u Ollama), cargás el modelo en GPU y exponés la API exclusivamente en la red interna aislada. Tema relacionado: la comparativa entre GPT-5 y Claude Code.

¿Es posible usar IA para revisar código clasificado?

Sí, ejecutándola on-premise en una red air-gapped. El modelo corre en hardware que controlás, sin conectividad externa. Cada consulta, respuesta y log queda dentro de tu infraestructura. La guía muestra exactamente cómo un contratista de defensa logró pasar la auditoría de compliance con este enfoque.

¿Qué modelos de IA funcionan sin conexión a la nube para revisar código?

Modelos de código abierto con pesos disponibles, como los basados en Llama, CodeLlama, DeepSeek-Coder y StarCoder2, pueden ejecutarse 100% local después de la descarga inicial. La diferencia está en la calidad de revisión, el esfuerzo de puesta a punto y el hardware requerido. Los modelos más grandes (70B parámetros) ofrecen mejor rendimiento pero exigen GPUs más potentes.

¿Cómo integrar un modelo local con GitLab CI/CD on-premise?

Creás un job en el pipeline que se dispare en merge requests, extrae el diff del PR, lo envía al endpoint de inferencia local, recibe la revisión en JSON y publica los comentarios como notas ancladas a las líneas del diff usando la API de GitLab. Todo dentro de la red aislada.

¿Cuáles son las limitaciones de seguridad al usar IA local?

La principal es que el modelo, aunque corra local, sigue siendo software que procesa datos sensibles. Errores de configuración —una API expuesta en un puerto incorrecto, falta de cifrado, logs sin restricción de acceso— pueden filtrar información tanto como un endpoint cloud mal asegurado. La red air-gapped no es una solución mágica: requiere segmentación interna, rotación de credenciales, monitoreo de acceso y registro de auditoría como cualquier sistema crítico.

Conclusión

La revisión de código con IA local ya no es un experimento de laboratorio ni un lujo de FAANG. El caso documentado demuestra que un equipo de defensa con restricciones reales —red air-gapped, código clasificado, auditoría de compliance— puede desplegar un modelo on-premise, integrarlo a sus pipelines y obtener revisiones automáticas de calidad sin comprometer la seguridad.

Lo que cambió es que las herramientas y las guías están madurando. Ya no estás solo armando un Frankenstein de modelos y scripts. Hay servidores de inferencia estables como vLLM, y equipos compartiendo setups que pasaron auditorías reales. Si tu código no puede —ni debe— salir del edificio, hoy tenés un camino trazado. No es fácil, pero es posible. Y para ciertos sectores, es la única forma de aprovechar la IA sin regalar los datos.

Fuentes

• On-Premise AI Code Review: How We Deployed Claude Locally in an Air-Gapped Environment (Setup Guide) — fuente primaria de este artículo.
• Ollama — servidor de inferencia ligero para ejecutar modelos de lenguaje localmente.
• vLLM — servidor de inferencia de alto rendimiento con PagedAttention, recomendado para cargas concurrentes.