ACL powered by DataArt - Fecha de actualización: Septiembre de 2026. Revisión técnica: Leonel Hernández, Deputy CTO, ACL powered by DataArt
Desarrollo de software con IA: agentes, SDLC y gobernanza
La inteligencia artificial ya está presente en el trabajo cotidiano de muchos equipos de desarrollo. Copilotos para escribir código, prompts para documentación, generación de pruebas o automatizaciones puntuales son cada vez más habituales.
El problema es que usar más IA no significa necesariamente haberla integrado al proceso de desarrollo.
Cuando esas capacidades empiezan a intervenir en requisitos, arquitectura, código, QA, seguridad o despliegue, aparecen preguntas bastante más importantes: ¿qué información utilizó la IA?, ¿qué cambió?, ¿cómo se validó?, ¿quién aprobó el resultado?, ¿qué evidencia quedó disponible?
La investigación de DORA muestra bien esa tensión. En 2025, 90% de los profesionales tecnológicos encuestados ya utilizaba IA en el trabajo y más de 80% percibía mejoras de productividad. Pero DORA también ha documentado que parte del tiempo ahorrado durante la generación vuelve a invertirse en revisión y verificación, y que alrededor de 30% de los desarrolladores confía poco o nada en los outputs generados por IA.
Esto ayuda a entender por qué la conversación está cambiando.
El desafío ya no es solamente conseguir que un modelo escriba código más rápido. Es incorporar esa capacidad dentro de un SDLC gobernado, trazable, medible y conectado con la forma real en que trabaja la organización.
DORA resume esta evolución describiendo a la IA como un amplificador: puede potenciar las capacidades de una organización, pero también amplificar sus fricciones si el sistema de delivery que la rodea es débil. Dora
En esta guía veremos dónde puede intervenir la IA a lo largo del SDLC, qué cambia al pasar de copilotos a agentes, por qué el contexto y la gobernanza se vuelven críticos y cómo medir si esa aceleración realmente está mejorando el desarrollo.
En síntesis
La IA ya puede participar en requisitos, arquitectura, desarrollo, testing, seguridad, despliegue y operación.
El reto aparece cuando pasa de ayudar a una persona en una tarea a participar del proceso. En ese punto, una organización necesita responder cinco preguntas:
- Qué puede hacer la IA;
- Qué conocimiento utiliza;
- Sobre qué sistemas puede actuar;
- Cómo queda registrada su ejecución;
- Y qué decisiones siguen requiriendo criterio humano.
Esa es la diferencia entre experimentar con IA y convertirla en una capacidad operativa del desarrollo.
¿Qué es el desarrollo de software con IA?
Antes de avanzar conviene hacer una distinción.
Desarrollar software con IA no es necesariamente lo mismo que desarrollar una aplicación que contiene inteligencia artificial.
AWS ya plantea esta evolución a lo largo de prácticamente todo el SDLC: gestión de proyectos, requisitos, diseño, código, testing, deployment y mantenimiento.
Una definición útil sería:
El desarrollo de software con IA consiste en incorporar modelos, agentes y automatización inteligente en distintas etapas del SDLC para apoyar o ejecutar tareas de ingeniería bajo contexto, reglas y mecanismos de validación definidos por la organización.
Pero hay una diferencia importante entre usar IA y operarla como parte del SDLC.
Leonel Hernández, Deputy CTO de ACL powered by DataArt, lo resume así:
“Usar IA puede significar apoyar una tarea específica. Gobernar IA dentro del SDLC implica integrarla al flujo completo.”
- En el primer escenario, la IA ayuda a redactar, generar o analizar algo.
- En el segundo aparecen otros elementos: agentes especializados, información de contexto, herramientas, trazabilidad, evidencia, métricas y aprobaciones.
El salto importante, por tanto, no es solamente de trabajo manual a trabajo asistido por IA. Es de asistencia puntual a capacidad operativa.
¿En qué etapas del SDLC puede intervenir la IA?
Reducir la conversación a generación de código deja fuera una parte importante de su potencial.
AWS documenta aplicaciones a lo largo de todo el ciclo: planificación, requisitos, diseño, implementación, testing, DevSecOps, despliegue y mantenimiento.
Requerimientos y planificación
La IA puede ayudar a transformar necesidades de negocio en requerimientos más estructurados, proponer historias de usuario, detectar ambigüedades o apoyar criterios de aceptación.
El valor no está solo en redactarlos más rápido. Un requerimiento incompleto puede convertirse después en retrabajo de arquitectura, desarrollo y QA. Detectarlo antes cambia mucho más que el tiempo de escritura.
Esta relación entre calidad temprana y desarrollo también aparece en nuestra guía sobre STLC/SDLC aplicado: dónde entra QA con IA, donde se plantea que incorporar IA sobre un proceso mal definido puede acelerar el problema en lugar de resolverlo.
Arquitectura y diseño
Con suficiente contexto, la IA puede ayudar a revisar dependencias, identificar componentes afectados por un cambio, analizar alternativas o apoyar documentación técnica.
Aquí aparece una condición decisiva: conocer el sistema.
Una propuesta puede ser técnicamente válida y seguir siendo incorrecta para una organización si desconoce sus integraciones, arquitectura, reglas de seguridad o convenciones internas.
Desarrollo y revisión de código
Esta sigue siendo la aplicación más visible. La IA puede generar código, refactorizarlo, explicarlo, documentarlo o participar de un code review.
Pero código plausible no significa código listo para producción. Todavía debe encajar con la arquitectura, pasar controles de seguridad, respetar estándares internos y demostrar que funciona dentro del sistema real.
QA y testing
La IA puede apoyar generación de casos, análisis de criterios, priorización, mantenimiento de pruebas, triage y regresión.
En escenarios más avanzados también puede ejecutar pruebas y producir evidencia.
Para profundizar específicamente en esta dimensión, ACL powered by DataArt cuenta con su servicio de QA con IA, orientado a integrar inteligencia artificial a calidad y testing sin separar esas capacidades del ciclo de desarrollo.
Seguridad y DevSecOps
La diferencia se vuelve especialmente importante cuando la IA deja de sugerir y empieza a actuar.
AWS documenta casos de IA aplicada a revisión de código, vulnerabilidades, dependencias, políticas, testing de seguridad y pipelines DevSecOps.
A mayor capacidad para modificar repositorios, consultar sistemas o ejecutar herramientas, mayor necesidad de definir permisos, límites y evidencia.
Deploy, operación y mantenimiento
La IA tampoco termina necesariamente en el merge.
Puede apoyar análisis de logs, monitoreo, root cause analysis, detección de anomalías y mantenimiento después del despliegue. AWS incluye explícitamente estas capacidades dentro de sus casos de uso para operación.
La conversación entonces cambia, en lugar de preguntar ¿En qué parte del SDLC podemos poner IA?, sería más útil conocer ¿qué grado de autonomía queremos permitir en cada etapa y qué controles necesita esa autonomía?
IA dentro del SDLC: capacidad, riesgo y control
.webp)
Copilotos vs. agentes de IA: no resuelven el mismo problema
Un copiloto y un agente pueden utilizar modelos similares, pero trabajan de manera distinta.
- El copiloto generalmente asiste a una persona en una tarea determinada. El usuario solicita algo, revisa el resultado y decide cómo utilizarlo.
- Un agente puede recibir un objetivo, recuperar contexto, utilizar herramientas y ejecutar una secuencia de acciones.
Pero el cambio relevante no termina ahí. Cuando arquitectura, desarrollo, QA y seguridad comienzan a trabajar mediante distintos agentes, el problema ya no es cada agente por separado.
Hay que decidir:
- Quién hace qué;
- Qué información utiliza;
- Qué herramientas puede invocar;
- Qué ocurre en paralelo;
- Qué paso depende de otro;
- Y dónde se requiere aprobación.
Ahí aparece la orquestación y por eso también importa distinguir un conjunto de agentes de un framework de trabajo.
Según la definición técnica validada, SPIREX® no resuelve únicamente una tarea: organiza requerimientos, contexto de proyecto, Skills, agentes, pipeline, revisión de código, evidencia, métricas e integración con herramientas dentro de una arquitectura común.
El salto, por tanto, no es solo:
Copiloto → Agente
También es:
Agentes individuales → Sistema capaz de coordinarlos dentro del SDLC.
El verdadero desafío: gobernar la IA dentro del SDLC
En un entorno enterprise, escribir código más rápido no resuelve todo el problema.
También hay que poder confiar en lo que se construyó.
Ese es uno de los puntos que Leonel identifica como centrales: sin trazabilidad, pruebas, validación humana y evidencia, la velocidad puede convertirse en riesgo. Para llevar resultados a producción hay que saber qué se hizo, cómo se validó, quién lo aprobó y qué evidencia respalda la entrega.
DORA llega a una conclusión compatible desde otro ángulo: el impacto de la IA en software no es lineal. Puede acelerar la creación inicial y, al mismo tiempo, trasladar esfuerzo hacia auditoría y verificación. Además, una mayor adopción aparece asociada con aumentos tanto en throughput como en inestabilidad.
Por eso la gobernanza no debería agregarse después de la experimentación, tendría que formar parte del diseño.
Trazabilidad
Si un agente interviene en una entrega, debería ser posible reconstruir:
- Qué agente actuó;
- Qué información utilizó;
- Qué produjo;
- Qué cambió;
- Quién revisó;
- Y quién autorizó continuar.
Sin esa información, una organización puede terminar generando más outputs, pero entendiendo menos cómo llegaron a producción.
Profundizamos los permisos, las aprobaciones y la evidencia necesaria en nuestra guía sobre gobernanza de agentes de IA en el SDLC.
Evidencia
También conviene separar resultado de evidencia.
Que un agente indique que una prueba pasó no es igual a disponer del resultado de la ejecución, logs, capturas, hallazgos o historial de aprobación.
En sistemas críticos, esa diferencia importa.
Control humano
Gobernar IA tampoco significa revisar manualmente cada output.
Significa mantener a una persona en las decisiones donde existe responsabilidad, contexto o riesgo que no conviene delegar por completo.
Leonel lo resume así:
“La IA puede ejecutar, proponer y acelerar, pero las decisiones críticas siguen pasando por una persona.”
Seguridad y gestión de riesgo
El NIST AI Risk Management Framework: Generative AI Profile es un marco voluntario orientado a incorporar consideraciones de confiabilidad y riesgo en el diseño, desarrollo, uso y evaluación de sistemas de IA.
En un SDLC con agentes, estos principios pueden materializarse mediante permisos acotados, aislamiento, gestión de secretos, observabilidad, trazabilidad y validación humana según el riesgo de cada acción.
Contexto: un agente necesita conocer cómo trabaja tu organización
Un modelo más potente no resuelve por sí solo el problema del contexto.
Un agente puede escribir código correcto en términos generales y aun así proponer algo incompatible con la arquitectura, el dominio o los estándares de una empresa.
Por eso una operación agéntica necesita al menos cuatro dimensiones: especialización, conocimiento, capacidad de acción y observabilidad.
Agentes: quién hace qué
Los agentes permiten separar responsabilidades.
Arquitectura puede analizar dependencias, QA revisar criterios y evidencia, desarrollo implementar cambios y seguridad evaluar riesgos.
Esta especialización reduce el problema de intentar resolver todo mediante un único prompt o agente generalista.
Skills: con qué conocimiento trabaja
Los Skills incorporan conocimiento reusable: estándares técnicos, patrones, contexto del negocio, convenciones o criterios de seguridad.
Leonel plantea que su función es entregar a los agentes conocimiento técnico y contexto del cliente para que trabajen con mayor precisión.
Con SPIREX®, las Skills están versionadas como código, revisadas por pares y son reproducibles por proyecto.
MCP: sobre qué herramientas puede actuar
La segunda capa es la acción.
SPIREX® utiliza MCP Servers para conectar agentes con herramientas como Jira, repositorios, Figma o SonarQube. Las credenciales están acotadas al proyecto, se resuelven en runtime y no se exponen al modelo.
La distinción es simple:
- Skills = qué sabe el agente.
- MCP = qué puede hacer.
Observabilidad: qué ocurrió
La cuarta capa es poder observar la operación.
No basta con conocer el output final. Importa saber qué agente intervino, qué contexto recibió, qué entregó y qué validación obtuvo.
DORA también identifica el acceso a información interna confiable y contextualizada como una capacidad relevante para obtener mejores resultados con IA.
Cómo funciona un SDLC orquestado con agentes de IA
Un SDLC agéntico no necesita inventar una nueva metodología. Puede representar el proceso que ya utiliza una organización.
La implementación pública de SPIREX® organiza actualmente el ciclo en cinco fases:
Discover → Define → Build & Test → Deploy → Operación.
Los pipelines son declarativos, por lo que pueden construirse con las etapas, roles y aprobaciones que ya existen en el equipo.
En las transiciones críticas aparece Human-in-the-Middle.
La versión pública actual establece 3+ puntos obligatorios de validación humana por pipeline, registra las aprobaciones y mantiene la decisión final del equipo sobre diseño, código y despliegue.
Cómo medir si la IA realmente mejora el desarrollo
Este punto es crítico porque es fácil confundir actividad con resultado.
Cantidad de prompts, líneas de código o tokens utilizados pueden mostrar adopción. No necesariamente demuestran valor.
DORA ha advertido precisamente sobre el riesgo de utilizar métricas de actividad aisladas para evaluar productividad en desarrollo asistido por IA.
AWS recomienda establecer una línea base antes de implementar, fijar objetivos, monitorear continuamente y medir categorías como velocidad de despliegue, calidad, eficiencia operacional, productividad del equipo e impacto empresarial.
Qué mirar
Leonel plantea un criterio particularmente útil:
“La pregunta no es solo si la IA produjo más, sino si ayudó a desarrollar mejor.”
Resultados observados con SPIREX®
En ACL powered by DataArt publicamos actualmente resultados validados en implementaciones activas de SPIREX®:
- 3–5× más rápido el ciclo desde épica hasta historias listas para desarrollo.
- 5–8 días → 4–6 horas en ese recorrido.
- Aproximadamente 12 → 7 defectos post-merge por sprint.
- Aproximadamente 15% → 70%+ de código nuevo que hereda estándares del cliente.
- 10–15 días → 2–3 días en time-to-first-commit para una persona nueva.
- Hasta 4 semanas desde POC hasta resultados medibles en operación real.
La metodología publicada también entrega contexto: se utiliza como baseline el sprint anterior al piloto, se selecciona un dolor concreto y un agente y se revisan los resultados al cierre de cada sprint.
Por eso estas cifras deben interpretarse como resultados observados en implementaciones específicas, no como una promesa universal.
Qué beneficios puede generar la IA cuando se integra al SDLC
La velocidad es probablemente el beneficio más visible, pero no es el único. Una integración más madura puede ayudar a:
- Reducir tiempo entre requerimiento y ejecución;
- Disminuir retrabajo;
- Reutilizar conocimiento técnico;
- Mejorar onboarding;
- Aplicar estándares con mayor consistencia;
- Aumentar trazabilidad;
- Y conectar mejor planificación, desarrollo, calidad y operación.
DataArt ofrece un ejemplo interesante en su práctica de AI-Accelerated Engineering.
En uno de sus casos publicados, DataArt reporta el uso de agentes para planificación, implementación, QA y deployment, reduciendo el tiempo de procesamiento de solicitudes de cambio de 7 semanas a 10 días, una reducción reportada de 74%, manteniendo los requisitos normativos y de gobernanza del caso.
Lo interesante del ejemplo no es únicamente el porcentaje. El resultado aparece al intervenir distintas etapas del delivery, no solamente la generación de código.
Qué riesgos aparecen cuando aceleramos el SDLC sin suficiente control
Uno de los riesgos menos visibles de acelerar con IA es crear nuevos puntos ciegos.
Leonel advierte que una organización puede generar más outputs y, al mismo tiempo, perder visibilidad sobre qué modelo intervino, qué cambió, quién aprobó o qué evidencia respalda la entrega.
Código plausible, pero incorrecto
Un modelo puede entregar código bien estructurado que no respete una dependencia, una regla de negocio o una restricción del sistema.
IBM también señala que la IA puede acelerar el SDLC, pero que sus outputs todavía requieren supervisión y validación humana para evitar errores o problemas de calidad.
Permisos excesivos
Un copiloto que propone código y un agente con acceso a repositorios o pipelines no tienen el mismo nivel de riesgo.
A medida que aumenta la capacidad de acción, los permisos deberían ser más explícitos.
Pérdida de trazabilidad
Si nadie puede reconstruir qué agente hizo qué, el problema aparece cuando algo falla.
Credenciales y datos
Los secretos, credenciales y datos sensibles requieren controles propios. Dar acceso indiscriminado al modelo contradice cualquier estrategia seria de gobierno.
Automatizar decisiones que todavía necesitan contexto
Un agente puede detectar una señal o recomendar una acción.
Eso no significa que deba decidir unilateralmente sobre un riesgo técnico, operativo o regulatorio.
La misma lógica aparece en el análisis de ACL sobre la evolución de RPA hacia IA agéntica: mayor autonomía exige una arquitectura de control distinta.
Cómo implementar IA en un equipo de desarrollo
El punto de partida no debería ser: “Necesitamos implementar IA.”
Una pregunta más útil es: “¿Dónde estamos perdiendo tiempo, calidad o capacidad dentro del SDLC?”
Leonel recomienda comenzar con un caso acotado, medible y conectado con un dolor real: requerimientos a historias, retrabajo en QA, documentación técnica, modernización legacy o validaciones repetitivas.
A partir de ahí, el recorrido puede organizarse en ocho pasos.
1. Elegir un problema concreto
No automatizar todo el ciclo.
2. Establecer una línea base
¿Cuánto demora hoy? ¿Cuántos errores aparecen? ¿Cuánto retrabajo existe?
3. Elegir una parte del SDLC
Acotar permite medir.
4. Definir límites
¿Qué puede consultar la IA? ¿Qué puede ejecutar? ¿Qué decisión necesita a una persona?
5. Incorporar contexto
Repositorio, arquitectura, estándares, documentación y conocimiento del dominio.
6. Integrar herramientas reales
Un agente desconectado del workflow puede ser útil, pero difícilmente mejora el proceso end-to-end.
AWS recomienda precisamente una toolchain integrada para reducir handoffs y context switching a través del SDLC.
7. Medir antes y después
Comparar percepción no basta.
8. Escalar solo con evidencia
La prueba de valor debe ocurrir antes de ampliar autonomía y alcance.
Para organizaciones que todavía están estructurando esta capacidad, ACL también cuenta con su enfoque de Inteligencia Artificial y Automatización Empresarial, que aborda estrategia, agentes en producción, gobierno y monitoreo.
SPIREX®: de agentes aislados a un SDLC gobernado
Esta es precisamente la problemática que busca resolver SPIREX®.
SPIREX® es un framework de orquestación agéntica desarrollado por ACL powered by DataArt para llevar agentes desde usos aislados hacia un proceso operacional gobernado.
En términos simples, funciona como un equipo de agentes que trabaja sobre el flujo real de desarrollo: recibe un requerimiento, incorpora contexto, participa en definición, diseño, pruebas y código y conserva evidencia del proceso bajo validación humana. Esa lógica está alineada con la definición técnica validada por Leonel.
No reemplaza a los copilotos
Un desarrollador puede seguir utilizando su asistente dentro del IDE.
SPIREX® incorpora el proceso alrededor: agentes, contexto, herramientas, pipelines, evidencia, seguridad y puntos de decisión.
Skills: el conocimiento del equipo
Los agentes necesitan saber cómo trabaja la organización.
Las Skills permiten incorporar estándares, patrones arquitectónicos, reglas y contexto de negocio de manera versionada y reproducible.
MCP: conexión con herramientas reales
Los agentes pueden interactuar con Jira, repositorios, Figma o SonarQube mediante MCP Servers.
Human-in-the-Middle
SPIREX® establece validación humana obligatoria en las transiciones críticas y registra cada aprobación.
Actualmente la implementación pública informa 3+ puntos de validación humana obligatorios por pipeline.
Seguridad y aislamiento
Cada agente corre en un contenedor efímero con red y filesystem restringidos. Las credenciales se resuelven en runtime desde un gestor de secretos y no aparecen en el contexto del modelo. Las ejecuciones registran información suficiente para reconstruir decisiones y aprobaciones.
La propuesta puede entrar de dos maneras:
- Gobernanza, cuando una organización necesita operar agentes sin perder trazabilidad ni control.
- Aceleración, cuando ya existe un proyecto y se busca ganar velocidad manteniendo el stack, estándares y proceso del equipo.
Para proyectos más amplios de construcción y modernización, ACL también cuenta con su capacidad de Ingeniería de Software / Software Factory. ACL TI
Cómo empezar: un POC medible antes de escalar
No todas las organizaciones necesitan comenzar transformando todo su SDLC.
Una forma más controlada es elegir un dolor concreto, establecer una línea base y evaluar la operación sobre una parte real del proceso.
SPIREX® plantea una Prueba de Concepto de hasta cuatro semanas, desde kick-off hasta agentes operando con métricas medibles.
La pregunta que debería responder ese POC no es ¿la IA funciona? sino ¿esta implementación mejora una parte relevante de nuestro SDLC con suficiente evidencia, control y consistencia como para justificar escalarla?
Ahí está la diferencia entre experimentar con IA y convertirla en una capacidad de ingeniería.
Conoce SPIREX® y evalúa un POC para tu operación
Preguntas frecuentes sobre desarrollo de software con IA
¿Qué es el desarrollo de software con IA?
Es la incorporación de modelos, asistentes, agentes y automatización inteligente a distintas actividades del ciclo de desarrollo. Puede abarcar desde requisitos y arquitectura hasta código, testing, deployment y operación.
¿En qué etapas del SDLC puede utilizarse IA?
Puede utilizarse en planificación, requisitos, arquitectura, diseño, implementación, QA, DevSecOps, deployment, operación y mantenimiento. AWS documenta aplicaciones en todas estas etapas.
¿Cuál es la diferencia entre un copiloto y un agente de IA?
Un copiloto normalmente asiste a una persona durante una tarea. Un agente puede recibir un objetivo, recuperar contexto, utilizar herramientas y ejecutar acciones. Cuando varios agentes participan de un mismo proceso, además se necesita una capa de orquestación y gobierno.
¿La IA puede reemplazar a los desarrolladores?
El enfoque descrito aquí no busca sustituir el criterio de ingeniería. La IA puede ejecutar y acelerar determinadas tareas, mientras las personas mantienen responsabilidad sobre decisiones críticas de alcance, arquitectura, riesgo, calidad y entrega.
¿Cómo se controla el código generado por IA?
No existe un único mecanismo. Puede combinarse contexto técnico, estándares, code review, testing, análisis de seguridad, evidencia de ejecución, permisos y puntos de validación humana.
¿Cómo se mide el impacto de la IA en desarrollo de software?
El punto de partida debería ser una línea base. Después pueden utilizarse métricas como lead time, time-to-market, defectos, retrabajo, cobertura, change failure rate, MTTR, onboarding, costo por operación y throughput. AWS recomienda medir velocidad de despliegue, calidad, eficiencia operacional, productividad e impacto de negocio.
¿Te ha interesado este contenido? No te pierdas nuestros otros artículos
- ¿Tus datos están preparados para IA? 7 señales antes de llevarla a producción
- Qué procesos automatizar en retail y cómo priorizarlos
- Automatización con IA: qué cambia frente al RPA
- Cómo escalar el gobierno de datos cuando faltan capacidades internas
- KPIs de gobierno de datos: cómo medir su impacto
- Gobierno de datos para IA: cómo escalar modelos y agentes sin perder control
- Roles del gobierno de datos: quién decide, quién valida y quién opera
- Cómo implementar un gobierno de datos: fases, prioridades y errores frecuentes
- Gobierno de datos: qué es y cómo implementarlo
