⬡
Modelo de Gobierno y Adopción de Agentes IA en el SDLC
Arquitectura holística · De la estrategia C-Level a la industrialización de agentes en desarrollo, CI/CD y operación
Antonio Herrera
6
Capas del modelo
8
Pilares de gobierno
16+
Agentes especializados
2
Metodologías
Mapa del modelo — haz clic en cualquier capa para ir al detalle
Principio diferencial
SDD — Cómo lo cambia todo
- La especificación es la fuente de verdad
- El código se genera, no se escribe
- Trazabilidad nativa end-to-end
- Los copilotos son accesorios, no el núcleo
- El agente de spec reemplaza al de copiloto
Tradicional — Para qué vale
- Proyectos con deuda técnica alta
- Equipos con baja madurez de especificación
- Integraciones donde la IA asiste sin transformar
- Contextos donde el copiloto ya genera ROI
- Transición gradual hacia SDD
Gobierno Global de IA
Ámbito C-Level y Comité IA · Define las reglas, riesgos y controles corporativos para todo el portfolio de inteligencia artificial
CIO/CTO
CDO
CISO
Riesgos
Legal/Compliance
Arquitectura
Negocio
8 Pilares de gobierno
Pilar 1
Estrategia IA
- Objetivos y roadmap corporativo
- Priorización de casos de uso
- OKRs de adopción IA
→ Dirección clara
Pilar 2
Riesgo y Control
- Autonomía máxima por agente
- Mecanismos de intervención humana
- Clasificación de riesgo IA
→ Exposición controlada
Pilar 3
Compliance
- DORA · EU AI Act
- Regulación Banco de España
- Solvencia II · GDPR
→ Cumplimiento activo
Pilar 4
Seguridad
- Datos que puede procesar la IA
- Acceso y control de identidad
- Privacidad y trazabilidad
→ Confianza técnica
Pilar 5
Arquitectura
- LLMs y plataformas autorizadas
- Patrones y frameworks aprobados
- Integraciones permitidas
→ Coherencia técnica
Pilar 6
KPIs y Métricas
- Productividad del equipo
- Calidad del código generado
- Ahorro, ROI y riesgo residual
→ Evidencia de valor
Pilar 7
FinOps IA
- Coste de modelos y tokens
- Licencias y GPU/cloud
- Presupuesto por equipo/proyecto
→ Sostenibilidad económica
Pilar 8
Formación y Cultura
- Capacitación de equipos
- Change management IA
- Adopción responsable
→ Madurez organizativa
› Qué decisiones toma el Comité IA
El Comité IA no opera en el día a día de los proyectos. Define el marco en el que todos los equipos operan:
Decide
- Qué LLMs están aprobados para producción
- Qué datos puede ingerir un agente
- Límite de autonomía sin supervisión humana
- Clasificación de riesgo por tipo de agente
- Budget máximo de tokens/mes por equipo
No decide
- Qué framework concreto usa un equipo (dentro de los aprobados)
- Arquitectura interna de cada agente
- Cómo se integra el agente en el SDLC
- Velocidad de adopción de cada equipo
Principio del modelo
"La IA no se gobierna agente a agente — se gobierna como una capacidad corporativa transversal a toda la organización"
Proceso de Incorporación y Control
Marco común para aprobar, validar e industrializar cualquier nuevo componente IA · LLMs, agentes, frameworks, herramientas y patrones
Entradas al proceso — qué se somete a validación
Nuevo LLM
Nuevo Agente
Nuevo Framework
Nueva Herramienta
Nuevo Patrón de automatización
→ Todos pasan por el mismo proceso, independientemente del equipo que los solicite
Los 7 pasos del proceso
1
Demanda
Equipo solicita el componente
2
Evaluación de encaje
¿Resuelve el problema declarado?
3
Riesgo y Seguridad
Datos, autonomía y exposición
4
Piloto controlado
Entorno aislado, equipo reducido
5
Validación técnica
Calidad, integración y compliance
6
Industrialización
Guardrails, docs y aprobación
7
Monitorización
Observabilidad continua en producción
› Detalle de cada paso — inputs, outputs y responsables
- 1DemandaEquipo envía solicitud documentada: problema a resolver, caso de uso, componente propuesto, equipo solicitante y urgencia estimada
- 2Evaluación de encajeArquitectura evalúa si el componente resuelve el problema y si existe una alternativa ya aprobada. Duración: 2-5 días hábiles
- 3Riesgo y SeguridadCISO y Riesgos evalúan: clasificación de datos que procesa, nivel de autonomía, superficie de ataque, regulación aplicable y plan de remediación
- 4Piloto controladoDespliegue en entorno sandbox con equipo reducido (2-3 personas). Duración: 2-4 semanas. Métricas obligatorias: calidad, coste y riesgo residual
- 5Validación técnicaRevisión formal de resultados del piloto: cumplimiento de SLAs, integración con el stack autorizado, cobertura de tests y evidencia de compliance
- 6IndustrializaciónConfiguración de guardrails automáticos, documentación de uso, aprobación formal del Comité IA y publicación en catálogo corporativo de activos IA
- 7MonitorizaciónObservabilidad continua: logs de uso, coste de tokens, anomalías de comportamiento, alertas automáticas y revisión trimestral por el Comité IA
Salidas y mecanismos de control
Guardrails automáticos
Monitorización continua
Registro corporativo de activos IA
Comité de validación IA
Revisión periódica obligatoria
Proceso de retirada y descatalogación
Principio del proceso
"Cualquier nuevo componente IA debe pasar por un proceso común de evaluación, validación y aprobación antes de llegar a producción"
SDD — Specification-Driven Development
La especificación estructurada es la fuente de verdad · El código se genera desde ella, no se escribe manualmente línea a línea
Los 3 principios del modelo SDD
Código desde especificación
La spec estructurada define qué debe hacer el sistema. Los agentes generan el código, los tests y la documentación a partir de ella. No hay improvisación.
Trazabilidad nativa E2E
De negocio a código, prueba y documentación sin gaps ni interpretaciones ad hoc. Cada línea de código tiene su origen trazado en la especificación.
Inteligencia en la spec
Los copilotos de código pierden centralidad. La especificación es el agente principal: quienes la escriben bien tienen el control total del output.
› El flujo completo en SDD
- 1Historia de usuarioNecesidad de negocio con criterios de aceptación verificables y no ambiguos
- 2Especificación estructuradaproposal.md · design.md · spec.md · tasks.md — el sistema completo documentado antes de escribir una línea de código
- 3Diseño técnicoArquitectura, impacto en APIs, modelo de datos, seguridad y dependencias — todo derivado de la spec
- 4Generación de códigoLos agentes generan código, tests y documentación a partir de las specs. Sin improvisación ni código "de agente sin contexto"
- 5Validación contra specLos tests verifican que el código implementa lo que la spec dice. Si hay divergencia, la spec manda.
- 6Archivo y conocimiento vivoLa spec archivada pasa a ser documentación oficial del sistema. El conocimiento no vive en conversaciones de chat sino en ficheros versionados.
Por qué SDD reduce la dependencia de copilotos
Modelo copiloto — el problema
- El developer improvisa con ayuda del copiloto
- El contexto vive en la cabeza del developer
- Cada sesión empieza de cero
- Difícil auditar qué generó el agente y por qué
- Alta variabilidad entre desarrolladores
Modelo SDD — la solución
- El agente trabaja siempre desde la spec
- El contexto vive en ficheros versionados
- Cualquier agente puede retomar desde donde dejó otro
- Total trazabilidad: spec → código → test
- Consistencia independiente del developer
Diferencial SDD
"En SDD el agente principal no es el copiloto de desarrollo, sino el agente que transforma especificaciones en artefactos trazables verificables"
Desarrollo Tradicional — Developer-Assisted
El developer sigue siendo el centro del proceso · La IA amplifica su productividad y la de todo el equipo sin transformar el modelo operativo
Los 3 principios del modelo tradicional
Copilotos potencian al developer
El developer sigue siendo el actor central. Los copilotos de código sugieren, completan y revisan. La calidad depende del criterio humano.
Asistencia puntual por fase
La IA ayuda en momentos específicos: escribir código, revisar una PR, generar tests para una función, buscar un bug. No transforma el flujo completo.
Modelo operativo familiar
Los equipos no necesitan aprender un nuevo paradigma. La IA se integra en el IDE, en la PR y en el pipeline sin cambiar la forma de trabajar.
Copilotos y herramientas más utilizados
GitHub Copilot
Autocompletado inline en VS Code, JetBrains y más. Chat integrado en el IDE para preguntas de código.
Cursor
IDE completo con IA integrada. Permite edición de múltiples ficheros con contexto de toda la base de código.
Amazon Q Developer
Especializado en ecosistema AWS. Fuerte en refactoring, detección de vulnerabilidades y migración de código legacy.
JetBrains AI
Integrado nativo en IntelliJ, PyCharm, etc. Contexto profundo del proyecto y sugerencias específicas del lenguaje.
Gemini Code Assist
Integración con Google Cloud y Workspace. Contexto de repositorio completo y generación de tests automática.
ChatGPT Enterprise
Asistente técnico conversacional. Útil para análisis de código, diseño de arquitecturas y búsqueda de soluciones.
¿Cuándo usar el modelo tradicional?
Encaja bien cuando
- El equipo tiene alta deuda técnica
- Los proyectos son de mantenimiento / refactoring
- La organización está empezando con IA
- El contexto cambia muy rápidamente
- Los requisitos son inestables o poco formalizados
Considerar SDD cuando
- Se necesita trazabilidad auditada
- El equipo es grande o distribuido
- Los proyectos son nuevos (greenfield)
- Compliance requiere documentación formal
- La base de código necesita ser transferible
Agentes SDLC en Modelo SDD
Orientados a especificación, trazabilidad y generación controlada de artefactos · El agente de spec es el actor central del modelo
Catálogo de agentes SDD
-
Agente de requisitos y elicitación funcional Transforma historias de usuario e inputs de negocio en requisitos estructurados y verificables. Genera criterios de aceptación formales y detecta ambigüedades antes de que lleguen a código.
› Ver detalle
- Input: historia de usuario, notas de reunión, emails
- Output: requisitos formales, criterios de aceptación, lista de ambigüedades
- Herramientas: Jira, Azure DevOps, Linear, Notion
- KPI: % de historias que llegan a spec sin iteraciones adicionales
-
Agente de especificación estructurada core El agente más importante del modelo SDD. Genera el paquete completo de spec: proposal.md, design.md, spec.md y tasks.md. Todo el equipo trabaja desde este output.
› Ver detalle
- Output: proposal.md (qué), design.md (cómo), spec.md (verificable), tasks.md (atómico)
- Integración: OpenSpec (/opsx:propose), Claude Code, Cursor
- KPI: tiempo medio de spec → piloto funcional
- Criterio de calidad: 0 ambigüedades detectadas en revisión humana
-
Agente de arquitectura y diseño técnico Propone la arquitectura de la solución basándose en la spec. Valida compatibilidad con el stack autorizado, diseña el modelo de datos y detecta impactos en APIs existentes.
› Ver detalle
- Input: spec.md, design.md, catálogo de APIs existente
- Output: diagrama de arquitectura, modelo de datos, lista de cambios en APIs
- Validación contra: catálogo de plataformas y patrones autorizados por Gobierno
-
Agente QA desde specs y criterios de aceptación Genera la estrategia de tests completa a partir de la spec, no del código. Tests unitarios, de integración, E2E y de contrato. Los criterios de aceptación se convierten directamente en casos de test.
› Ver detalle
- Input: spec.md (criterios de aceptación), design.md (APIs)
- Output: plan de tests, test cases, scripts de automatización
- Frameworks: JUnit, Playwright, REST Assured, Pact
- KPI: % de criterios de aceptación cubiertos por tests automáticos
-
Agente de documentación y trazabilidad Genera y mantiene la documentación técnica sincronizada con el código. Todo cambio en la spec actualiza automáticamente la documentación. La trazabilidad es nativa, no un proceso adicional.
-
Agente de validación de estándares y gobernanza Verifica que el código generado cumple los estándares corporativos: naming conventions, seguridad, arquitectura autorizada, cobertura mínima y compliance. Puerta de entrada al pipeline CI/CD.
Nota sobre copilotos de código en SDD
→
Los copilotos tienen rol secundario en SDD→
La spec genera el artefacto, no el autocompletado→
GitHub Copilot / Cursor: útiles en tareas pequeñas y aisladas→
Nunca como fuente de verdad del comportamiento del sistemaAgentes SDLC en Modelo Tradicional
Orientados a productividad individual y asistencia en cada fase · El copiloto de desarrollo es el actor central del modelo
Catálogo de agentes tradicional
-
Agente de requisitos y asistente BA/POAsiste al Business Analyst en la clarificación de requisitos, generación de criterios de aceptación y detección de conflictos o inconsistencias en la especificación funcional.
-
Copiloto de desarrollo core El actor central del modelo. Sugerencias en tiempo real, autocompletado, generación de funciones completas, explicación de código, refactoring inline y conversación en el IDE.
› Ver herramientas principales
- GitHub Copilot — integración nativa en VS Code y JetBrains
- Cursor — contexto de todo el repositorio
- Amazon Q Developer — especializado en AWS y Java
- JetBrains AI — deep integration con IDEs JetBrains
- Gemini Code Assist — Google Cloud y Workspace
- Agente de code review automáticoRevisa PRs automáticamente: patrones problemáticos, complejidad ciclomática, violaciones de estilo, dependencias vulnerables, bugs potenciales y mejoras de legibilidad.
- Agente de refactoring y mejora de códigoSugiere y ejecuta refactorings: extracción de métodos, eliminación de duplicados, simplificación de condiciones, modernización de patrones y mejora de performance.
- Agente de testing y cobertura asistidaGenera tests unitarios para funciones existentes, sugiere casos edge, analiza la cobertura actual e identifica las rutas críticas sin tests. Integración con JUnit, Jest, Pytest, Playwright.
- Agente de documentación asistidaGenera Javadoc, docstrings, README, guías de uso y documentación de APIs a partir del código existente. Mantiene sincronía entre código y docs.
Agentes CI/CD, Release y Operación
Capa de industrialización compartida por SDD y Desarrollo Tradicional · Define el estándar de calidad, seguridad y entrega del software
Pipeline de agentes — flujo completo
CI Agent
Pipelines, builds, packaging
QA Gate
Cobertura, evidencias, criterios
Security
SAST/SCA, secrets, CVEs
Release
Notes, checklist, plan
Deploy
Controlado, rollback
Observability
Logs, métricas, trazas
Incident
Diagnóstico, RCA
Feedback
Al backlog y la spec
Detalle de cada agente
CI Agent
Integración Continua
- Gestión de pipelines compleja
- Builds inteligentes e incrementales
- Packaging y artefactos
- Jenkins · GitHub Actions · Azure DevOps
→ Build siempre limpio
QA Gate Agent
Control de Calidad
- Cobertura mínima obligatoria
- Evidencias de pruebas almacenadas
- Criterios de aceptación verificados
- SonarQube · JaCoCo · Allure
→ Calidad certificada
Security Agent
Seguridad Automática
- SAST en cada commit
- SCA de dependencias y licencias
- Detección de secrets expuestos
- Trivy · Snyk · OWASP · Checkmarx
→ 0 vuln críticas en prod
Release Agent
Gestión de Releases
- Release notes automáticas
- Checklist de despliegue
- Plan de comunicación
- Versionado semántico automático
→ Releases predecibles
Deployment Agent
Despliegue Controlado
- Blue/green y canary deployments
- Rollback automático por thresholds
- Feature flags y dark launches
- ArgoCD · FluxCD · Spinnaker
→ 0 downtimes no planificados
Observability Agent
Visibilidad en Producción
- Correlación de logs distribuidos
- Métricas de SLA en tiempo real
- Trazas distribuidas end-to-end
- Prometheus · Grafana · Jaeger · ELK
→ Visibilidad total
Incident Agent
Gestión de Incidencias
- Diagnóstico automático de causa raíz
- Correlación de síntomas y señales
- Runbooks asistidos por IA
- MTTR objetivo: < 30 minutos
→ Recuperación rápida
Feedback Agent
Cierre del Ciclo
- Aprendizajes al backlog y la spec
- Anomalías al Gobierno de IA
- Patrones de fallo al proceso de incorporación
- Retroalimenta la Mejora Continua
→ El ciclo se cierra
Principio CI/CD
"La IA no acaba cuando se genera código — debe integrarse en la cadena CI/CD, calidad, seguridad, despliegue y operación continua"
Mejora Continua
Cierra el ciclo · Evidencias, métricas y aprendizajes de producción que retroalimentan Gobierno, Proceso y Metodología
Los 4 motores de mejora
Métricas de calidad
Cobertura de tests, defect rate, tiempo de ciclo, lead time, DORA metrics y NPS técnico. Se miden por proyecto, equipo y metodología (SDD vs Tradicional).
Evidencias de producción
Incidencias en producción, SLAs reales vs comprometidos, comportamiento real de agentes IA, coste de tokens por feature y deuda técnica generada.
Feedback loop activo
Los aprendizajes no quedan en un informe: actualizan specs, modifican agentes, mejoran el proceso de incorporación y elevan al Comité IA los cambios de governance necesarios.
Optimización continua
Fine-tuning de modelos, ajuste de guardrails, reducción de coste de tokens, eliminación de agentes de bajo valor y aceleración del proceso de incorporación de nuevos componentes.
Qué retroalimenta — el ciclo completo
→ Capa 1 · Gobierno Global IA
Evidencias reales de riesgo, coste real de FinOps, KPIs actualizados, compliance activo y necesidades de nuevas políticas
→ Capa 2 · Proceso de Incorporación
Patrones de fallo en la validación, componentes que no superan el piloto, tiempos reales del proceso y criterios de aprobación que deben refinarse
→ Capas 3A/3B · Metodología
Proyectos donde SDD genera más valor, contextos donde el modelo tradicional es más eficiente y datos para guiar la evolución de los equipos hacia mayor madurez
Cierre del modelo
"Un modelo de adopción de IA sin mejora continua es un proyecto, no una capacidad. La diferencia está en si el ciclo se cierra sobre sí mismo o muere en un informe"
≡
Comparativa SDD vs Desarrollo Tradicional
Qué aplica, quién actúa y qué produce cada modelo en cada fase del SDLC
Tabla comparativa por fase del SDLC
| Fase SDLC | SDD — Agente principal | SDD — Output | Tradicional — Agente principal | Tradicional — Output |
|---|---|---|---|---|
| Requisitos | Agente de requisitos estructurados | Criterios verificables formalizados | Asistente BA/PO + developer | Historia de usuario + AC informales |
| Especificación | Agente de especificación (core) | spec.md · design.md | No existe como fase formal | Código y decisiones en la cabeza del developer |
| Arquitectura | Agente de arquitectura desde spec | Diseño técnico trazado a spec | Architect + copiloto asistente | Diagrama + decisiones en documentos sueltos |
| Desarrollo | Generación desde spec (agente) | Código verificable contra spec | Copiloto de desarrollo (core) | Código generado interactivamente |
| Testing | Agente QA desde criterios de spec | Tests derivados de spec, cobertura total | Agente testing + developer | Tests para código existente, cobertura parcial |
| Documentación | Generada automáticamente desde spec | Siempre sincronizada | Agente documental + developer | Generada a posteriori, puede desync |
| Revisión | Validación contra especificación | Divergencias código/spec detectadas | Code review asistido | Revisión de calidad y estilo |
| Trazabilidad | Nativa · end-to-end | Req → Spec → Código → Test | Parcial · requiere esfuerzo manual | Depende de la madurez del equipo |
| Transferibilidad | Cualquier agente puede retomar la spec | Sin dependencia del desarrollador original | Depende del contexto del developer | Riesgo de knowledge loss en rotaciones |
¿Cuándo elegir cada modelo?
Elige SDD cuando
- Proyectos nuevos (greenfield)
- Compliance requiere trazabilidad auditada
- Equipos grandes o distribuidos
- Alta rotación o equipos variables
- APIs críticas o reguladas
- El código debe sobrevivir a los autores
Elige Tradicional cuando
- Proyectos de mantenimiento o refactoring
- Alta deuda técnica preexistente
- Equipo comenzando con IA (curva de entrada)
- Contexto cambiante o requisitos inestables
- Tareas pequeñas y aisladas
- Transición gradual hacia SDD
◈
Modelo de Madurez IA
Escala de adopción de 5 niveles · Sitúa a tu organización y define el siguiente paso hacia la industrialización de IA en el SDLC
¿En qué nivel está tu organización? — haz clic en cada nivel
L0
Ad hoc — Sin gobierno IA
Cada equipo usa IA como quiere, sin proceso ni control
›
Qué existe
- Uso informal de ChatGPT
- GitHub Copilot en algunos IDEs
- Sin política de uso
- Sin control de costes
Qué falta
- Gobierno mínimo de IA
- Proceso de aprobación
- Control de qué datos se envían a los LLMs
- Visibilidad de costes
Siguiente paso
- Inventario de herramientas IA en uso
- Política básica de uso aceptable
- Comité IA provisional
- Clasificación de riesgo inicial
L1
Experimental — Pilotos aislados
Primeros experimentos con agentes, sin proceso común de incorporación
›
Qué existe
- Copilotos aprobados informalmente
- 1-2 pilotos de agentes en marcha
- Alguna política de uso básica
- Entusiasmo sin estructura
Qué falta
- Proceso formal de incorporación
- Guardrails automáticos
- Métricas de valor y riesgo
- Registro de activos IA
Siguiente paso
- Definir proceso de Capa 2
- Crear catálogo de componentes IA aprobados
- Medir ROI de pilotos actuales
- Formalizar el Comité IA
L2
Gestionado — Gobierno básico activo
Proceso de incorporación definido, primeros guardrails y métricas
›
Qué existe
- Proceso de aprobación de componentes IA
- Catálogo de activos IA aprobados
- Guardrails básicos en producción
- Agentes en CI/CD (QA Gate, Security)
- Medición de coste de tokens
Qué falta
- SDD en proyectos clave
- Agentes de especificación
- Pipeline CI/CD completo con agentes
- Modelo de madurez por equipo
Siguiente paso
- Piloto SDD en 1 proyecto nuevo
- Completar pipeline CI/CD con 8 agentes
- Definir KPIs de calidad por equipo
- Feedback loop básico activo
L3
Definido — Gobierno completo y SDD en proyectos clave
El modelo holístico de las 6 capas está operativo en la mayoría de proyectos
›
Qué existe
- Las 6 capas del modelo operativas
- SDD en proyectos nuevos y críticos
- Pipeline CI/CD con los 8 agentes
- Gobierno activo con KPIs
- Mejora continua con datos reales
Qué falta
- SDD como estándar para todos los proyectos
- Optimización automática de agentes
- Feedback loop totalmente cerrado
- IA en todas las fases sin excepción
Siguiente paso
- Extender SDD a todos los proyectos
- Automatizar el ciclo de Mejora Continua
- Desarrollar agentes propietarios
- Preparar IA de nivel L4
L4
Optimizado — IA como capacidad corporativa diferencial
El ciclo completo está cerrado, SDD es el estándar y la organización genera ventaja competitiva
›
Qué existe
- SDD como estándar de facto
- Agentes propietarios entrenados
- Ciclo de mejora completamente automático
- Gobierno predictivo basado en datos
- Trazabilidad auditada 100%
Diferencial competitivo
- Speed-to-market 3-4x superior
- Calidad de código auditada sin esfuerzo
- Incorporación de tecnología sin fricción
- Compliance regulatorio nativo
- Transferibilidad total del conocimiento
Mantener y evolucionar
- Revisión anual del modelo de gobierno
- Exploración de agentes multimodales
- Contribución a frameworks del sector
- Expansión a otras unidades de negocio
Autoevaluación rápida
?
¿Tienes un Comité IA con poder real de decisión??
¿Todo componente IA pasa por un proceso de aprobación??
¿Tienes guardrails automáticos en producción??
¿Usas agentes en tu pipeline CI/CD??
¿Has hecho algún piloto SDD??
¿Mides el ROI real de la adopción IA?