Cuando el que revisa el código también es una IA

Llevo tiempo estudiando un máster en Inteligencia Artificial mientras trabajo como Platform Engineer. En algún punto del camino, las dos cosas colisionaron de una forma que no esperaba.

Y de esa colisión nació OpsGuard-AI. Mi TFM.

El problema que nadie quería nombrar

Empecé el máster con una idea vaga de lo que quería investigar. Pero cuanto más trabajaba con LLMs en mi día a día, más incómodo me sentía con algo que nadie estaba diciendo en voz alta:

¿Quién revisa el código que genera la IA?

No hablo de Copilot completando una función. Hablo de agentes autónomos que abren pull requests, que comiten cambios, que modifican infraestructura. Cosas que ya están pasando en producción. Hoy.

El problema no es que la IA genere código malo. El problema es que genera código plausible. Código que compila, que pasa los tests unitarios, que tiene buena pinta. Y escondido dentro, una SQL injection. Un secret hardcodeado. O algo más sutil: una imagen Docker descargada de ghrc.io en lugar de ghcr.io. Una letra de diferencia. Un ataque de typosquatting que ningún SAST del mercado va a pillar porque la sintaxis es perfectamente válida.

Eso fue el detonante.

La idea: una puerta antes de producción

La propuesta de OpsGuard-AI es simple en concepto y compleja en ejecución: un sistema de revisión de seguridad que se sienta en el pipeline de CI/CD y analiza cada pull request antes de que el código llegue a producción.

No otro escáner de dependencias. No otra herramienta de SAST con 500 reglas que nadie mantiene. Algo diferente.

El núcleo del sistema son dos puertas en serie:

Gate 1 — Motor de Regex: Detección estructural. Patrones de credenciales, tokens de AWS, API keys. Determinista, sin latencia, sin llamadas externas. Si el patrón está, se bloquea en milisegundos.

Gate 2 — Motor Semántico con LLM: Aquí es donde cambia todo. El diff del PR se le pasa a un modelo de lenguaje con un prompt de análisis de seguridad muy trabajado. El modelo no busca patrones. Entiende el contexto. Puede ver que una query construida con concatenación de strings en ese contexto específico es una SQL injection aunque no haya ningún regex que la defina.

La puntuación de riesgo va de 0 a 10. Por encima de 7, el sistema bloquea y abre automáticamente un GitHub Issue con el label security-block y la justificación detallada.

Lo que más me costó entender

Diseñar el sistema fue complicado. Pero lo que más tiempo me llevó no fue el código. Fue tomar decisiones de arquitectura que importan de verdad.

La más importante: el dato sensible nunca sale del entorno local.

Suena obvio. Pero tiene consecuencias enormes. Si mandas el diff de un PR a una API externa, estás mandando tu código, tus secretos, tu arquitectura, a un tercero. Eso es inaceptable en cualquier entorno serio.

La solución fue usar OpenRouter con modelos configurables, permitiendo apuntar a modelos locales si la organización lo requiere. El Gate 1, el de regex, funciona completamente offline. Y el Gate 2 solo recibe lo estrictamente necesario para el análisis.

Otra decisión que defendí con fuerza en los ADRs del proyecto: política de fallo cerrado. Si el sistema no puede determinar si algo es seguro, bloquea. No aprueba. No deja pasar “por si acaso”. El riesgo desconocido es riesgo.

En un mundo donde los agentes de IA pueden cometer código a las 3 de la madrugada sin que nadie mire, esa decisión no es filosófica. Es práctica.

El momento en que supe que funcionaba

Preparé un conjunto de pruebas que internamente llamo el shooting range: código intencionalmente vulnerable, diseñado para ver si el sistema lo detecta.

El caso que más me gustó fue el del typosquatting. Una imagen Docker apuntando a ghrc.io en lugar de ghcr.io. Un solo carácter. El Gate 1 no lo detecta, porque no hay ningún patrón de credencial. Semgrep tampoco. Trivy tampoco.

El Gate 2 lo bloqueó con un score de 9/10 y una explicación que describía exactamente el vector de ataque: un dominio que imita al registro oficial de GitHub para inyectar imágenes maliciosas en el pipeline.

Ahí entendí que el enfoque tenía sentido real.

Lo que aprendí construyendo esto

Primero: el prompt engineering es ingeniería, no magia. Pasé semanas refinando el prompt del Gate 2. Pequeños cambios en la instrucción cambian drásticamente la calidad del análisis. Externalicé los prompts a su propio directorio para poder versionarlos y mejorarlos sin tocar código. Eso fue una de las mejores decisiones del proyecto.

Segundo: la arquitectura modular no es un lujo. Separar la ingesta del diff, la detección de patrones, el cliente LLM y el CLI en módulos independientes me permitió testear cada pieza por separado. Puedo ejecutar todo el test suite sin una sola llamada a la API. En CI/CD eso es fundamental.

Tercero, y esto es lo que me llevo más allá del TFM: el problema de la seguridad en pipelines con IA va a ser un campo crítico en los próximos años. No porque la IA sea mala. Sino porque estamos dándole capacidad de acción a sistemas que no tienen criterio propio sobre las consecuencias. Alguien tiene que tenerlo.

Por qué lo hice open source

Porque si el problema es real, la solución tiene que poder revisarse. No tiene sentido construir una herramienta de seguridad que sea una caja negra.

Todo el código, los ADRs, el diseño de los prompts, el razonamiento detrás de cada decisión está en el repositorio: OpsGuard-AI . Si trabajas en DevOps, en seguridad, o simplemente te preocupa lo que pasa cuando los agentes de IA llegan a tu pipeline, échale un vistazo.

Y si ves algo que mejorarías, abre un issue. O mejor, un PR.

Aunque ahora ya sabes que OpsGuard lo va a revisar antes que yo.