¿Qué es CI/CD?
Entrega, operaciones e infraestructura de IA
CI/CD significa Integración Continua y Entrega Continua o Despliegue Continuo. En la práctica, es una forma disciplinada de llevar los cambios de software desde la idea hasta el servicio en producción con menos incertidumbre y mayor control. Los equipos registran cambios en el control de versiones, ejecutan verificaciones automatizadas, generan artefactos desplegables y promueven versiones a través de entornos mediante reglas definidas. La Integración Continua consiste en fusionar y probar cambios con frecuencia. La Entrega Continua mantiene el software en un estado listo para publicar, con una persona que decide cuándo se produce el lanzamiento a producción. El Despliegue Continuo automatiza ese lanzamiento a producción una vez que las verificaciones requeridas se superan.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
Una forma útil de entender CI/CD es como un sistema operativo para el cambio de software. No es una herramienta única, ni simplemente un botón de publicación más rápido. Es un flujo de trabajo repetible que responde preguntas básicas pero importantes cada vez que algo cambia: quién cambió qué, qué pruebas se ejecutaron, qué se construyó, qué entorno se utilizó, quién aprobó el lanzamiento, qué ocurrió tras el despliegue y cómo se revierte si algo sale mal.
Para una organización pequeña o mediana, esa disciplina importa más que la etiqueta de moda. Un pipeline modesto que extrae código de un repositorio, ejecuta pruebas unitarias y de integración, analiza dependencias, empaqueta una imagen de contenedor, registra los logs de despliegue y requiere aprobación antes de producción puede ser más valioso que una plataforma sobrediseñada. El objetivo no es imitar la cultura de ingeniería de las grandes tecnológicas. El objetivo es hacer que el cambio rutinario sea más seguro, más fácil de revisar y menos dependiente de que una sola persona recuerde la secuencia correcta.
Esto también es relevante para los sistemas habilitados con IA. Un asistente de documentos interno, una API de modelo orientada al cliente, un flujo de recuperación de información o un panel de informes siguen funcionando sobre componentes de software ordinarios: entornos, identidades, secretos, pasarelas y registros. La capa de inteligencia no elimina la necesidad de una entrega disciplinada; si acaso, la aumenta.
Por qué importa
Los líderes suelen escuchar que CI/CD es una práctica de productividad, pero el valor más profundo es la fiabilidad operativa. Si su organización modifica software que gestiona transacciones, flujos de trabajo del personal, integraciones, datos personales, enrutamiento de modelos o lógica de facturación, cada lanzamiento es un evento de riesgo empresarial además de uno técnico. CI/CD reduce ese riesgo cuando ofrece cambios más pequeños, retroalimentación más temprana, trazas de auditoría más claras y un comportamiento de lanzamiento más predecible.
La integración frecuente ayuda a los equipos a detectar conflictos antes. Las pruebas automatizadas detectan algunos defectos antes de que se conviertan en incidentes. Las compilaciones reproducibles reducen los argumentos del tipo "en mi máquina funciona". La separación de entornos reduce la probabilidad de que un atajo de un desarrollador se convierta en un problema en producción. Los logs de despliegue y la procedencia de los artefactos facilitan la investigación si algo falla.
CI/CD también importa porque el riesgo en la cadena de suministro de software está ahora muy cerca de la entrega cotidiana. Los equipos modernos descargan paquetes, construyen contenedores, llaman a APIs externas, usan plugins, ejecutan acciones reutilizables y despliegan mediante automatización con credenciales de alto privilegio. Incluso una empresa pequeña que usa un repositorio gestionado y un servicio de compilación en la nube opera una cadena de suministro. Para los productos habilitados con IA, el punto se vuelve aún más práctico: los cambios en los prompts, la lógica de recuperación, las versiones del SDK, los límites de tasa o los modelos de respaldo pueden afectar silenciosamente a la calidad, la confidencialidad, el coste y la confianza del cliente.
Cómo funciona
Un pipeline de CI/CD suele comenzar en el control de versiones. Un desarrollador o ingeniero de plataforma abre una rama, realiza un cambio y lo envía para revisión. Las ramas protegidas, las reglas de revisión y la propiedad clara son los primeros controles. Una vez que se envía un cambio, el pipeline ejecuta tareas automatizadas como linting, pruebas unitarias, pruebas de integración, verificación de dependencias, análisis estático y pasos de compilación. Si estas superan, el pipeline produce un artefacto, como un paquete, una imagen de contenedor o un paquete de despliegue.
El siguiente paso es la promoción. En la Entrega Continua, el artefacto avanza por los entornos, pero una persona sigue aprobando el lanzamiento a producción. En el Despliegue Continuo, el lanzamiento a producción se automatiza una vez que las verificaciones requeridas se superan. Esto puede funcionar bien para servicios de bajo riesgo y bien probados, pero solo si las pruebas, la observabilidad y la reversión son significativas.
Los buenos pipelines hacen más que "ejecutar pruebas y publicar". Los workers de compilación deben estar reforzados. Los secretos deben provenir de almacenes gestionados o variables de pipeline estrictamente controladas, no del código fuente ni de scripts aleatorios. Los permisos deben ser restrictivos. Los artefactos deben ser identificables e idealmente firmados o certificados, para que los equipos puedan verificar qué se construyó y mediante qué proceso. Los entornos sensibles no deberían depender del acceso ad hoc a la consola si la organización espera lanzamientos predecibles.
La separación de entornos es importante aquí. Desarrollo, pruebas, preproducción y producción no deben mezclarse solo porque la consola en la nube lo facilite. Los logs también importan. Si un despliegue falló a las 14:07, los equipos deben saber qué commit, ejecución del pipeline, resumen del artefacto, versión de configuración y aprobación estuvieron implicados. En la entrega adyacente a la IA, las verificaciones también pueden incluir evaluación de prompts, umbrales de calidad de recuperación, pruebas de enrutamiento de modelos o comportamiento de respaldo.
Ejemplos
Imagine una empresa SaaS que expone una API utilizada por equipos de finanzas. Un desarrollador cambia la lógica que valida las cargas de facturas. Con un buen proceso de CI/CD, el cambio se revisa en una solicitud de extracción, se fusiona en la rama principal, se prueba automáticamente, se construye en una imagen de contenedor, se analiza en busca de problemas de dependencias y se despliega primero en preproducción. El personal de producto y operaciones prueba archivos de muestra conocidos. Solo entonces se aprueba el lanzamiento a producción. Si aparece un defecto, el equipo puede rastrear la compilación exacta y revertir rápidamente.
Ahora imagine un asistente de IA interno que ayuda al personal a recuperar documentos de política y redactar respuestas. El equipo actualiza la biblioteca de recuperación, cambia la configuración de fragmentación y añade un proveedor de modelo de respaldo. Ninguno de esos cambios parece dramático por sí solo. Juntos podrían afectar a la calidad, la confidencialidad, el coste o la resiliencia. Un pipeline disciplinado permite al equipo probar prompts conocidos, verificar el comportamiento de redacción y decidir si se necesita aprobación humana antes del lanzamiento.
Un tercer ejemplo es un cambio de aplicación que también actualiza la Infraestructura como Código y la política de pasarela. CI/CD se convierte en la capa de coordinación que mueve los cambios relacionados juntos, en lugar de depender de clics desconectados en la consola y de la memoria.
Otro patrón es el lanzamiento progresivo. Un equipo que despliega un nuevo servicio de clasificación de búsqueda puede lanzarlo primero a usuarios internos o a un pequeño grupo de clientes, observar las tasas de error y los tickets de soporte, y luego ampliar la exposición. Eso sigue siendo CI/CD. Reconoce que el lanzamiento no es un evento binario único. El pipeline puede ayudar a escalonar el cambio, pero los operadores siguen necesitando métricas, responsabilidad y una condición de parada clara.
Malentendidos frecuentes
Un malentendido habitual es que CI/CD simplemente significa velocidad. La velocidad puede ser un resultado, pero la idea central es la repetibilidad con controles. Un equipo que publica cada hora sin pruebas significativas, registro, lógica de aprobación o reversión no está haciendo bien CI/CD; simplemente está automatizando el riesgo.
Otro malentendido es que la Entrega Continua y el Despliegue Continuo son lo mismo. Están relacionados, pero la decisión de lanzamiento es la diferencia importante. La Entrega Continua mantiene el software listo para publicar y normalmente espera una aprobación humana antes de producción. El Despliegue Continuo automatiza el propio lanzamiento a producción. Para algunos servicios de bajo riesgo eso tiene sentido. Para software que cambia cálculos financieros, flujos de identidad o lógica de seguridad, el lanzamiento automático puede no ser el comportamiento predeterminado adecuado.
También existe el hábito de tratar CI/CD como una preocupación exclusiva de los desarrolladores. En realidad, una buena entrega implica a ingeniería, operaciones de plataforma, seguridad, responsables de servicio y, en ocasiones, a colegas de gobernanza cuando los cambios afectan a datos personales o al comportamiento orientado al cliente.
Riesgos y límites
CI/CD puede fallar de formas muy ordinarias. Las pruebas débiles generan una falsa confianza. Los planes de reversión frágiles convierten un defecto menor en una interrupción del servicio. La falta de responsabilidad clara hace que todos asuman que otra persona aprobó el lanzamiento arriesgado. Los pipelines que dependen de credenciales amplias pueden exponer cuentas en la nube, claves de firma o servicios de producción si un runner se ve comprometido. Las acciones, plugins y paquetes reutilizables de terceros pueden ampliar la superficie de ataque.
Los secretos merecen atención especial. Los pipelines suelen manejar credenciales de alto privilegio porque necesitan compilar, analizar y desplegar en distintos entornos. Si están codificados de forma fija, se comparten en exceso o se filtran en los logs, el pipeline se convierte en una vía de ataque privilegiada. La integridad de la compilación importa por la misma razón. Si las solicitudes de extracción no confiables pueden activar trabajos de despliegue potentes, o si los runners autoalojados están mal aislados, los controles existen sobre el papel pero no en la práctica.
La sobreautomatización es otro riesgo. Los equipos pueden encariñarse con la idea de que cada prueba superada debe producir un lanzamiento. Eso está bien para algunos cambios de bajo riesgo, pero no todos los servicios tienen el mismo radio de impacto. CI/CD debe apoyar el juicio, no eliminarlo. Para los sistemas habilitados con IA, superar las verificaciones del pipeline no demuestra que una funcionalidad sea segura o adecuada en todos los contextos; solo demuestra que las verificaciones definidas se superaron.
Qué hacer a continuación
Los líderes no necesitan diseñar pipelines línea por línea, pero sí deben pedir un modelo de lanzamiento claro. Comience por identificar qué servicios son más importantes, qué incluye realmente un lanzamiento y dónde sigue siendo necesaria la aprobación humana. Asegúrese de que el control de versiones, las reglas de revisión, las pruebas automatizadas, la separación de entornos, el registro de despliegues y la reversión existen para esos servicios antes de perseguir una automatización más sofisticada.
Luego examine el pipeline como un sistema privilegiado por derecho propio. Pregunte quién puede modificarlo, quién puede aprobar lanzamientos, dónde se almacenan los secretos, cómo se identifican los artefactos y si la organización puede reconstruir lo que ocurrió tras un incidente. Si su equipo está publicando funcionalidades habilitadas con IA, pregunte qué verificaciones existen para los cambios de prompts, las actualizaciones de recuperación, el enrutamiento de modelos, la política de pasarela y el comportamiento de respaldo.
Apunte a una fiabilidad sólida antes que a una sofisticación aparente. Una configuración de CI/CD pequeña y bien comprendida, con responsabilidad clara, es mejor que una plataforma extensa que nadie sabe explicar.
Relacionado: MLOps.
Relacionado: AIOps.
Relacionado: inferencia de IA.
Relacionado: IA en el borde.
¿Tiene alguna pregunta o sugerencia, o desea saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿CI/CD significa que cada cambio se publica automáticamente?
No. La Entrega Continua y el Despliegue Continuo no son idénticos. En la Entrega Continua, el software se mantiene listo para publicar, pero normalmente una persona o un paso de aprobación formal decide cuándo se produce el lanzamiento a producción. En el Despliegue Continuo, el propio lanzamiento se automatiza una vez que las verificaciones se superan. Muchas organizaciones utilizan una combinación: más automatización para los servicios de bajo riesgo y aprobaciones más estrictas para los cambios de mayor impacto.
¿CI/CD solo es relevante para los equipos de ingeniería de software?
No. Ingeniería gestiona las herramientas, pero las consecuencias afectan a operaciones, seguridad, producto, atención al cliente y dirección. La frecuencia de lanzamiento, la calidad de la reversión, la auditabilidad y la respuesta a incidentes afectan a toda la organización. Si su empresa publica portales para clientes, sistemas de flujo de trabajo internos o asistentes habilitados con IA, CI/CD forma parte de la gobernanza del servicio, no solo de la comodidad del desarrollador.
¿Un pipeline de CI/CD hace que el software sea seguro o conforme?
No por sí solo. Un pipeline puede aplicar controles útiles como revisiones, pruebas, firma, separación de entornos y logs de despliegue, pero no puede garantizar un diseño seguro, un tratamiento lícito de los datos ni decisiones empresariales adecuadas. Ayuda a las organizaciones a aplicar controles de forma coherente. Si esos controles son suficientes depende del software, los datos, los usuarios y el riesgo implicados.
¿Cómo se relaciona CI/CD con MLOps y LLMOps?
MLOps y LLMOps extienden la disciplina de entrega a los flujos de trabajo de modelos, datos, evaluación y servicio, pero no reemplazan la práctica ordinaria de entrega de software. El servicio sigue necesitando revisiones de código, lanzamientos probados, configuración controlada, gestión de secretos, registro de despliegues, monitorización y reversión. En muchas organizaciones, CI/CD es la columna vertebral que sostiene esos flujos operativos más amplios.
Fuentes
SP 800-218, Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities (NIST). Core secure software development practices, SDLC integration, and governance language for CI/CD.
SP 800-204D, Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines (NIST). Pipeline stages, DevSecOps context, software supply chain controls, provenance, and attestations.
Secure the build and deployment pipeline (UK NCSC). Build and deployment pipeline discipline, reducing manual processes, trust, and pipeline security.
CI CD Security Cheat Sheet (OWASP). Definition of CI/CD, distinctions between CI and CD, common pipeline risks, IAM, integrity, and monitoring.
Secrets Management Cheat Sheet (OWASP). Secrets handling, least privilege, logging, and hardening for CI/CD tooling.
Guidelines for secure AI system development (UK NCSC). Why AI-enabled systems still need secure infrastructure, access controls, incident management, and responsible release.