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.
Ver índice de contenidos
La IA como amplificador
El informe de DORA de 2025, titulado «State of AI-assisted Software Development», deja una conclusión que sirve como criterio de decisión antes de tocar un solo archivo de configuración:
«El papel principal de la IA es el de amplificador, magnificando las fortalezas y las debilidades existentes de una organización.»
Esa frase tiene una consecuencia práctica incómoda. 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. El resultado previsible es más trabajo de rehacer, no menos.
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—. Conviene entonces mirar el estado del pipeline antes de mirar el catálogo de herramientas. Si hay pruebas inestables, ese es el primer trabajo, con o sin modelo de por medio.
Dónde aporta de verdad
No todos los usos valen lo mismo. Esta tabla los ordena por lo que importa al decidir: qué trabajo humano reemplaza y qué pasa si el modelo se equivoca.
| 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. El pipeline ya falló por su cuenta |
| Clasificar pruebas inestables | Revisar a mano el historial de fallas intermitentes | Se marca mal una prueba; se revisa después |
| 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 | Comentarios inútiles; 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. Requiere red de seguridad |
| Borradores de configuración | Escribir el primer manifiesto o pipeline desde cero | Configuración plausible y equivocada. Se revisa como cualquier código |
Los dos últimos merecen advertencia. La selección de pruebas es tentadora porque acorta el pipeline, pero convierte una decisión de cobertura en una apuesta: solo tiene sentido si la suite completa corre igual en algún momento —de noche, antes de liberar— para que el error se detecte tarde y no nunca. Y los borradores de configuración tienen el problema de siempre: una configuración de infraestructura equivocada no falla al compilar, falla en producción.
La escala de confianza
Acá está la decisión de diseño que separa una integración útil de un dolor de cabeza permanente. Hay tres peldaños posibles y conviene subirlos en orden:
- InformarEl modelo agrega un comentario, una etiqueta o un resumen. No cambia el resultado del pipeline. Si se equivoca, el costo es ruido.
- SugerirPropone un cambio o una acción que una persona acepta o descarta. Si se equivoca, el costo es tiempo perdido.
- BloquearDecide si el pipeline pasa o falla. Reservado a condiciones deterministas: pruebas, análisis estático, umbrales medidos.
La razón para no dejar que un modelo ocupe el tercer peldaño no es desconfianza genérica: es una propiedad concreta. 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 ahí se perdió también la confianza en las comprobaciones que sí eran confiables.
Hay una consecuencia práctica más, de costo y de tiempo: una llamada a un modelo en cada ejecución del pipeline se paga en dinero y en segundos. 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
Si hay que elegir uno solo, el triaje de fallas es el que tiene mejor relación entre valor y riesgo. El trabajo que reemplaza es concreto y molesto: cuando el pipeline falla, alguien abre un registro de miles de líneas para responder tres preguntas —¿es el cambio?, ¿es la infraestructura?, ¿es una prueba inestable?— y avisarle a quien corresponda.
# 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 cuentaFijate en dos detalles de ese esquema, porque son los que lo vuelven seguro. El paso no tiene permiso de escritura sobre el contenido del repositorio, y el filtrado de secretos ocurre antes de armar el contexto que se envía. Los dos son consecuencia directa de los riesgos de la sección siguiente.
La otra mitad del valor está en la clasificación de pruebas inestables: identificar las que fallan de forma intermitente y proponer una causa a partir del patrón de fallas. Eso ataca el problema que, según la lógica del amplificador, hay que resolver primero.
Los riesgos propios
Un pipeline es un entorno con credenciales, acceso al repositorio y capacidad de publicar artefactos. Poner un modelo ahí adentro suma riesgos que no existen cuando el mismo modelo se usa desde una terminal. Cuatro de los diez riesgos de la lista de OWASP para aplicaciones con modelos de lenguaje, en su 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, un comentario 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 de compilación arrastra variables de entorno o configuración 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 | Un informe que dice «no encontré problemas» se lee como garantía de que no hay | Redactar salidas como indicios, nunca como veredicto |
La inyección de prompts merece detalle porque es la que más sorprende. Un pipeline que se dispara con propuestas de cambio de cualquier origen está ejecutando pasos sobre texto que escribió un desconocido. Si ese texto llega a un modelo que tiene permiso de escribir en el repositorio, el ataque no necesita ninguna vulnerabilidad técnica: alcanza con pedirle amablemente que haga otra cosa. La defensa estructural no es filtrar palabras —eso se elude— sino quitarle los permisos al paso, de modo que aunque el modelo obedezca, no pueda ejecutar nada.
Y hay un riesgo que cruza con la cadena de suministro: un modelo puede sugerir con total seguridad una dependencia que no existe, y si alguien registra ese nombre inventado con contenido malicioso, la sugerencia se convierte en una vía de entrada. Es la razón por la que cada dependencia nueva se verifica antes de llegar al archivo de bloqueo, tema que desarrolla la guía de seguridad de la cadena de suministro. El blog de Underc0de documentó además casos donde el propio entorno de desarrollo asistido es el objetivo: extensiones maliciosas que amenazan a los IDE con IA basados en VS Code.
Qué no delegar
Tres decisiones conviene mantener fuera del alcance del modelo, y no por prudencia abstracta: cada una tiene un motivo específico.
- La aprobación de un despliegue a producción. Es una decisión con responsable, y un modelo no puede serlo. Puede armar el resumen del cambio, listar los riesgos y señalar qué se despliega; la aprobación queda del lado humano.
- El juicio final de seguridad. Un informe que no encontró problemas se lee como garantía de que no hay, y esa lectura es falsa. El análisis asistido suma indicios; no reemplaza el análisis determinista ni la revisión.
- La condición que decide si el pipeline pasa o falla. Tiene que ser reproducible: la misma entrada, el mismo resultado, siempre. Ese es territorio de pruebas, análisis estático y umbrales medidos.
El patrón común es claro: el modelo prepara material y la decisión queda del lado humano o del lado determinista. Con ese reparto, un error del modelo cuesta atención; sin él, cuesta un despliegue.
Cómo adoptarlo
- Arreglar el pipeline primeroSi hay pruebas inestables o la retroalimentación tarda, ese es el trabajo. La IA amplifica lo que hay.
- Elegir una sola tareaEl triaje de fallas. Una, medible, en el peldaño de informar.
- Ejecutarla sin permisosLectura sobre lo que necesita, escritura solo donde publica el comentario.
- Medir si sirve¿Bajó el tiempo hasta identificar la causa de una falla? Si nadie lee los comentarios, no sirve.
- Recién entonces subir un peldañoDe informar a sugerir, con la misma medición. El tercer peldaño queda para lo determinista.
El cuarto paso es el que se saltea siempre. Un paso de IA que agrega comentarios que nadie lee no es neutral: consume tiempo de pipeline, cuesta dinero y suma ruido a la conversación de cada propuesta de cambio.
Errores frecuentes
- Empezar por la herramienta y no por el problema. Se instala la integración y después se busca qué hacer con ella.
- Dejar que el modelo bloquee el pipeline. Fallas que se arreglan reintentando enseñan a reintentar sin leer.
- Darle al paso más permisos de los que necesita. Es lo que convierte la inyección de prompts en un problema real.
- Mandar el registro completo como contexto. Caro, lento y con secretos adentro.
- Llamar al modelo en cada ejecución. El triaje solo tiene sentido cuando algo falló.
- Tratar el análisis asistido como aprobación de seguridad. Suma indicios, no otorga garantías.
- No medir la adopción. Si nadie lee la salida, el paso está gastando recursos.
Preguntas frecuentes
¿La IA mejora la entrega de software?
Depende de lo que ya tengas. El informe de DORA de 2025 lo resume así: «el papel principal de la IA es el de amplificador, magnificando las fortalezas y las debilidades existentes de una organización». Traducido a decisiones: si el pipeline es rápido, las pruebas son confiables y la reversión funciona, agregar IA acelera. Si el pipeline es lento, las pruebas fallan al azar y desplegar da miedo, la IA produce más cambios por unidad de tiempo sobre un sistema que no los puede absorber.
¿Dónde conviene empezar a usar IA en un pipeline?
Por el triaje de fallas, que es donde la relación entre valor y riesgo es mejor. Cuando un pipeline falla, alguien tiene que leer el registro, decidir si es un problema real del cambio, una falla de infraestructura o una prueba inestable, y avisar a quien corresponda. Ese trabajo es repetitivo, consume atención en el peor momento y una respuesta equivocada no rompe nada, porque el resultado es una sugerencia y el pipeline ya falló por su cuenta.
¿Qué es la inyección de prompts en un pipeline?
Es el riesgo número uno de la lista de OWASP para aplicaciones con modelos de lenguaje —LLM01:2025 Prompt Injection— y en un pipeline tiene una forma concreta: el contenido de una propuesta de cambio es texto que viene de afuera. Si el paso que analiza ese contenido tiene permisos, alguien puede escribir instrucciones dentro del título, la descripción, un comentario o el propio código para que el modelo haga algo distinto de lo que se le pidió. La defensa es no darle permisos de escritura al paso que lee contenido no confiable.
¿Puede un modelo aprobar o bloquear un despliegue?
Puede informar, y conviene que no decida. La razón no es desconfianza genérica sino una propiedad concreta: 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, porque destruye la confianza en todo el pipeline. Las condiciones de bloqueo tienen que ser deterministas —pruebas, análisis estático, umbrales— y el aporte del modelo debe quedar como comentario o resumen.
¿Los secretos del pipeline corren riesgo?
Sí, y por dos vías. La primera es la más obvia: todo lo que se le pasa al modelo como contexto sale del entorno, así que si el registro de compilación incluye variables de entorno o el contenido de un archivo de configuración, eso viaja. La segunda es la divulgación de información sensible, el segundo riesgo de la lista de OWASP. El principio práctico: el paso que llama al modelo se ejecuta con los mismos permisos mínimos que cualquier otro, y el contexto se filtra antes de enviarlo, nunca después.
¿Qué no hay que delegarle a un modelo en el pipeline?
Tres cosas. La aprobación de un despliegue a producción, porque es una decisión con responsable y el modelo no puede serlo. El juicio final de seguridad, porque un informe que dice «no encontré problemas» se lee como garantía y no lo es. Y la generación de la condición que decide si el pipeline pasa o falla, porque eso tiene que ser reproducible. En los tres casos el modelo puede preparar el material, resumir el contexto y sugerir, y la decisión queda del lado humano o del lado determinista.
Fuentes
Documentación oficial, investigación y material de la comunidad consultados para esta guía. Fecha de consulta: 27 de julio de 2026.
Aportes de la comunidad Underc0de
- Underc0de, blog. Extensiones maliciosas amenazan IDEs con IA basados en VS Code, 7 de enero de 2026. El entorno de desarrollo asistido como objetivo.
- Underc0de, blog. Google descubre exploit zero-day creado con IA, 12 de mayo de 2026. El contexto de por qué conviene tratar estas herramientas con criterio de seguridad.
Investigación y documentación oficial
- DORA, Google Cloud. State of AI-assisted Software Development 2025. La conclusión sobre la IA como amplificador, citada textualmente.
- OWASP. OWASP Top 10 for LLM Applications 2025. Los riesgos LLM01 inyección de prompts, LLM02 divulgación de información sensible, LLM06 agencia excesiva y LLM09 desinformación.
- DORA. DevOps Research and Assessment. Investigación sobre capacidades y rendimiento en entrega de software.