# Inteligencia artificial aplicada a pipelines CI/CD

**Categoría:** DevOps y cloud · **Nivel:** Intermedio · **Lectura:** 13 min
**Publicada:** 2026-07-27 · **Actualizada:** 2026-07-27 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/devops-cloud/inteligencia-artificial-en-pipelines-ci-cd/

## Respuesta rápida

Meter **inteligencia artificial** en un pipeline de integración y entrega continua rinde en un conjunto acotado de tareas: **triaje de fallas**, clasificación de **pruebas inestables**, resúmenes de cambios y de incidentes, revisión asistida y borradores de configuración. El informe de **DORA** de 2025 aporta el marco para decidir: «el papel principal de la IA es el de **amplificador**, magnificando las fortalezas y las debilidades existentes de una organización». La regla de implementación que evita el desastre es una **escala de confianza**: primero el modelo *informa*, después *sugiere*, y las condiciones que **bloquean** el pipeline siguen siendo deterministas. Y una restricción de seguridad no negociable: el paso que lee contenido no confiable **no tiene permisos de escritura**.

## La IA como amplificador

> «El papel principal de la IA es el de amplificador, magnificando las fortalezas y las debilidades existentes de una organización.» — DORA, *State of AI-assisted Software Development 2025*

Si el pipeline tarda cuarenta minutos, un tercio de las pruebas falla al azar y desplegar requiere coordinar tres personas, agregar IA no arregla nada: aumenta la cantidad de cambios que entran a un sistema que ya no los podía absorber.

Dicho al revés: **las condiciones que hacen que la IA rinda son las mismas que hacen que un pipeline sea bueno sin ella** —pruebas confiables, retroalimentación rápida, despliegue reversible—.

## Dónde aporta de verdad

| Uso | Qué reemplaza | Si se equivoca… |
|---|---|---|
| **Triaje de fallas** | Leer el registro para decidir si es el cambio, la infraestructura o una prueba inestable | Ruido en un comentario |
| **Clasificar pruebas inestables** | Revisar a mano el historial de fallas intermitentes | Se marca mal una prueba |
| **Resumir cambios e incidentes** | Escribir notas de versión y cronologías a mano | Un resumen impreciso que alguien corrige |
| **Revisión asistida** | La primera pasada de la revisión de código | El peligro real es la falsa sensación de revisado |
| **Seleccionar qué pruebas correr** | Ejecutar siempre la suite completa | Se saltea una prueba que importaba |
| **Borradores de configuración** | Escribir el primer manifiesto desde cero | Configuración plausible y equivocada |

Los dos últimos merecen advertencia. La **selección de pruebas** solo tiene sentido si la suite completa corre igual en algún momento. Y una **configuración de infraestructura** equivocada no falla al compilar: falla en producción.

## La escala de confianza

1. **Informar.** El modelo agrega un comentario, una etiqueta o un resumen. No cambia el resultado del pipeline. Si se equivoca, el costo es ruido.
2. **Sugerir.** Propone un cambio o una acción que una persona acepta o descarta. Si se equivoca, el costo es tiempo perdido.
3. **Bloquear.** Decide si el pipeline pasa o falla. Reservado a condiciones **deterministas**: pruebas, análisis estático, umbrales medidos.

**Un modelo puede dar respuestas distintas ante la misma entrada**, y un control de calidad que cambia de opinión sin que cambie el código es peor que no tener control. Después de la tercera vez que un pipeline falla y al reintentarlo pasa, el equipo aprende a reintentar sin leer.

Y una consecuencia de costo: conviene ejecutar esos pasos **solo cuando aportan** —el triaje, únicamente si la compilación falló— y no en cada empujón.

## El caso más rentable

```yaml
# Forma de un paso de triaje, sea cual sea la plataforma de integración continua
triaje:
  if: falló-el-trabajo-anterior       # solo cuando aporta: no en cada ejecución
  permisos:
    contenido: lectura                # ← sin escritura: lee entrada no confiable
    comentarios: escritura            # el único permiso que necesita para informar
  pasos:
    - recortar-registro               # las últimas N líneas relevantes, no todo
    - filtrar-secretos                # ANTES de armar el contexto, nunca después
    - clasificar                      # cambio · infraestructura · prueba inestable
    - comentar-resultado              # informar; el pipeline ya falló por su cuenta
```

Dos detalles vuelven seguro ese esquema: el paso **no tiene permiso de escritura sobre el contenido** del repositorio, y el **filtrado de secretos ocurre antes** de armar el contexto.

El detalle de cómo se detectan y se arreglan las pruebas inestables está en [cómo detectar y solucionar flaky tests](../../testing/como-detectar-y-solucionar-flaky-tests/index.md), y el uso de IA para generar pruebas, en [testing de aplicaciones con inteligencia artificial](../../testing/testing-de-aplicaciones-con-inteligencia-artificial/index.md).

## Los riesgos propios

Cuatro de los diez riesgos de la lista de **OWASP para aplicaciones con modelos de lenguaje**, edición 2025, aparecen con forma propia:

| Riesgo | Cómo se ve en un pipeline | Defensa |
|---|---|---|
| **LLM01 · Inyección de prompts** | El título, la descripción o el código de una propuesta de cambio son texto de afuera con instrucciones dentro | Sin permisos de escritura en el paso que lee entrada no confiable |
| **LLM02 · Divulgación de información sensible** | El registro arrastra variables de entorno al contexto que se envía | Filtrar y recortar antes de armar el contexto |
| **LLM06 · Agencia excesiva** | El paso puede confirmar cambios, cerrar propuestas o desplegar | Permisos mínimos y acciones acotadas a informar |
| **LLM09 · Desinformación** | «No encontré problemas» se lee como garantía | Redactar salidas como indicios, nunca como veredicto |

La defensa estructural contra la inyección de prompts no es filtrar palabras —eso se elude— sino **quitarle los permisos al paso**, de modo que aunque el modelo obedezca, no pueda ejecutar nada.

Un riesgo que cruza con la cadena de suministro: un modelo puede sugerir una dependencia **que no existe**, y si alguien registra ese nombre inventado con contenido malicioso, la sugerencia se vuelve una vía de entrada. Ver [seguridad de la cadena de suministro](../seguridad-de-la-cadena-de-suministro-de-software/index.md) y el caso de [extensiones maliciosas en IDE con IA basados en VS Code](https://blog.underc0de.org/extensiones-maliciosas-amenazan-ides-con-ia-basados-en-vs-code/).

## Qué no delegar

- **La aprobación de un despliegue a producción.** Es una decisión con responsable, y un modelo no puede serlo.
- **El juicio final de seguridad.** Un informe que no encontró problemas se lee como garantía, y esa lectura es falsa.
- **La condición que decide si el pipeline pasa o falla.** Tiene que ser reproducible.

**El modelo prepara material y la decisión queda del lado humano o del lado determinista.**

## Cómo adoptarlo

1. **Arreglar el pipeline primero.** Si hay pruebas inestables o la retroalimentación tarda, ese es el trabajo.
2. **Elegir una sola tarea.** El triaje de fallas, en el peldaño de informar.
3. **Ejecutarla sin permisos.** Lectura sobre lo que necesita, escritura solo donde publica el comentario.
4. **Medir si sirve.** ¿Bajó el tiempo hasta identificar la causa? Si nadie lee los comentarios, no sirve.
5. **Recién entonces subir un peldaño.** El tercero queda para lo determinista.

## Errores frecuentes

- **Empezar por la herramienta y no por el problema.**
- **Dejar que el modelo bloquee el pipeline.**
- **Darle al paso más permisos de los que necesita.**
- **Mandar el registro completo como contexto.** Caro, lento y con secretos adentro.
- **Llamar al modelo en cada ejecución.**
- **Tratar el análisis asistido como aprobación de seguridad.**
- **No medir la adopción.**

## Preguntas frecuentes

**¿La IA mejora la entrega de software?**
Depende de lo que ya tengas. DORA lo resume: la IA es un amplificador. Sobre un pipeline sano acelera; sobre uno frágil produce más cambios de los que el sistema puede absorber.

**¿Dónde conviene empezar a usar IA en un pipeline?**
Por el triaje de fallas: trabajo repetitivo, que consume atención en el peor momento, y donde una respuesta equivocada no rompe nada porque el pipeline ya falló por su cuenta.

**¿Qué es la inyección de prompts en un pipeline?**
El riesgo LLM01:2025 de OWASP. El contenido de una propuesta de cambio es texto que viene de afuera; si el paso que lo analiza tiene permisos, alguien puede escribir instrucciones dentro.

**¿Puede un modelo aprobar o bloquear un despliegue?**
Puede informar, y conviene que no decida. Un control que cambia de opinión sin que cambie el código destruye la confianza en todo el pipeline.

**¿Los secretos del pipeline corren riesgo?**
Sí. Todo lo que se le pasa como contexto sale del entorno. El paso corre con permisos mínimos y el contexto se filtra antes de enviarlo, nunca después.

**¿Qué no hay que delegarle a un modelo?**
La aprobación de un despliegue, el juicio final de seguridad y la condición que decide si el pipeline pasa o falla.

## Fuentes

Fecha de consulta: 27 de julio de 2026.

**Aportes de la comunidad Underc0de**

1. Underc0de, blog. [Extensiones maliciosas amenazan IDEs con IA basados en VS Code](https://blog.underc0de.org/extensiones-maliciosas-amenazan-ides-con-ia-basados-en-vs-code/), 7 de enero de 2026.
2. Underc0de, blog. [Google descubre exploit zero-day creado con IA](https://blog.underc0de.org/google-descubre-exploit-zero-day-creado-con-ia/), 12 de mayo de 2026.

**Investigación y documentación oficial**

3. DORA, Google Cloud. [State of AI-assisted Software Development 2025](https://dora.dev/dora-report-2025/).
4. OWASP. [OWASP Top 10 for LLM Applications 2025](https://genai.owasp.org/llm-top-10/).
5. DORA. [DevOps Research and Assessment](https://dora.dev/).

## Guías relacionadas

- [Seguridad de la cadena de suministro de software](../seguridad-de-la-cadena-de-suministro-de-software/index.md)
- [Cómo detectar y solucionar flaky tests](../../testing/como-detectar-y-solucionar-flaky-tests/index.md)
- [Programación asistida por agentes de inteligencia artificial](../../programacion/programacion-asistida-por-agentes-de-ia/index.md)
- [Índice de DevOps y cloud](../index.md)