Gobierno del ciclo de vida

Por qué el ciclo de vida es donde se pierde el control

La mayoría de los incidentes que acabo analizando no vienen de una fase concreta, sino de una transición sin control. Un piloto que se quedó en producción sin que nadie lo aprobara formalmente. Un modelo que se entrenó con unos datos y acabó usándose para otra cosa. Un sistema que lleva dos años funcionando y del que ya nadie sabe quién responde. Todo eso son saltos de fase que ocurrieron sin una puerta.

Con la IA esto se agrava porque los sistemas cambian solos: se reentrenan, se conectan a nuevas fuentes de datos, se les añaden herramientas. Un sistema aprobado hace un año puede ser, hoy, un sistema distinto que nadie ha vuelto a mirar. Por eso no basta con aprobar una vez: hay que gobernar toda la vida del sistema, desde que es una idea hasta que se apaga.

Las fases y sus puertas de aprobación

El gobierno del ciclo de vida se concreta en gates: en cada fase, un criterio claro, un aprobador con nombre y una evidencia que lo respalde. Esta es la estructura que uso; se adapta a cada organización, pero la lógica de "no se pasa de fase sin cerrar la puerta" no cambia.

El mapa oficial: controles A.6 de ISO/IEC 42001

Mis puertas no me las invento: se apoyan en los controles A.6 del Anexo A de la ISO/IEC 42001, que son el núcleo técnico de la gobernanza de IA. La norma exige que todo el ciclo de vida esté gobernado, y lo estructura en cinco bloques. Este es el mapa que tengo siempre delante cuando diseño los gates:

Fíjate en la lógica: cada bloque no es una etiqueta, es una exigencia con dos patas concretas. Desarrollo responsable con procesos formales; requisitos claros con defensas contra amenazas; metodologías de prueba con plan de despliegue; monitorización con planes de reparación; y documentación técnica con registros de eventos. Cuando mis gates piden "evidencia", esa evidencia es exactamente lo que cuelga de estas ramas.

Qué miro en cada fase

Las puertas no son burocracia si cada una pregunta lo justo. Esto es lo que compruebo, fase a fase:

Idea

Aquí solo quiero saber dos cosas: ¿esto aporta valor real y encaja con nuestra política? No entro en el cómo; filtro para no gastar esfuerzo en casos que no deberían existir. Un "no" en esta puerta es barato; un "no" en producción es carísimo.

Diseño

Es la fase donde de verdad se gestiona el riesgo. Exijo la evaluación de impacto hecha, los datos que va a usar definidos y clasificados, y los controles pensados antes de escribir código. Si el riesgo se piensa después, se parchea; si se piensa aquí, se diseña.

Desarrollo y prueba

Que se haya probado de verdad, no solo que "funciona". Según el riesgo, eso incluye pruebas adversarias —red teaming— para ver cómo se rompe antes de que lo rompa otro.

Despliegue

La puerta más formal. No sale a producción sin controles operativos y monitorización listos, y sin una aprobación explícita del comité que asuma el riesgo residual. Aquí es donde muchas organizaciones fallan: despliegan y "luego lo aprobamos".

Operación

El sistema vivo no es un sistema terminado. Reviso que los indicadores siguen dentro de umbral y que las revisiones periódicas ocurren de verdad. Un modelo se degrada, los datos cambian, el contexto cambia.

Retirada

La fase que todos olvidan y de la que hablo aparte, porque es donde se acumulan los riesgos silenciosos.

Lo que más se olvida: la retirada

Nadie planifica apagar un sistema de IA, y por eso los sistemas viejos se convierten en los más peligrosos. Siguen consumiendo datos, siguen tomando decisiones, y ya nadie los mira. Una retirada como es debido tiene su propia puerta: plan de baja, migración de lo que dependa de él, y —esto es lo importante— borrado o retención controlada de los datos y del modelo. Un sistema que se "deja de usar" pero sigue encendido y accesible no está retirado; es una superficie de ataque olvidada.

Los errores que veo una y otra vez

• Aprobar en producción. El sistema ya está funcionando cuando llega la "aprobación".
• Puertas que se saltan con prisa. El gate existe salvo cuando corre prisa, que es justo cuando más falta hace.
• Aprobar una vez y olvidarse. El sistema cambia y nadie vuelve a mirarlo.
• No planificar la retirada. Sistemas zombis encendidos que nadie gobierna.
• Gates sin evidencia. "Se aprobó" sin nada que lo respalde no resiste una auditoría.

Cómo sé que el ciclo de vida está gobernado

Miro si cada sistema en producción pasó realmente por sus puertas, con evidencia; cuántos despliegues se hicieron sin aprobación formal (deberían ser cero); cuánto hace que no se revisa cada sistema en operación; y si hay sistemas encendidos que ya nadie usa ni gobierna. Si las puertas dejan rastro y no hay zombis, el ciclo está vivo. Si todo se aprobó "de palabra", no lo está.

Checklist práctica

• Cada fase tiene un gate con criterio, aprobador y evidencia.
• Ningún sistema llega a producción sin aprobación formal.
• Los gates se respetan también cuando hay prisa.
• Los sistemas en operación se revisan periódicamente.
• Existe un plan de retirada con borrado o retención controlada.
• No hay sistemas encendidos sin dueño ni uso.

Cómo lo llevaría a un entorno real

Cuando aterrizo gobierno del ciclo de vida en una organización, no empiezo por comprar una herramienta ni por redactar veinte páginas. Empiezo por dibujar qué ocurre hoy: quién solicita el cambio, quién lo aprueba, qué sistemas intervienen, qué datos cruzan el proceso y quién se entera cuando algo falla. Ese dibujo suele descubrir más problemas que cualquier checklist. En gobernanza, lo peligroso no es solo carecer de controles; también lo es creer que existen porque alguien los escribió una vez.

Después separo lo imprescindible de lo deseable. Lo imprescindible debe poder comprobarse: un responsable identificado, una regla clara, una evidencia fechada y un mecanismo para reaccionar. En este caso revisaría especialmente Gobierno, ciclo y vida. No me vale una respuesta del tipo «lo gestiona el proveedor» o «eso lo mira seguridad». Necesito saber qué persona toma la decisión, con qué información y dentro de qué plazo.

La implantación debe crecer con el riesgo. Un piloto interno puede funcionar con una ficha breve y una revisión manual. Un sistema que afecta a clientes, empleados, dinero o información sensible necesita segregación de funciones, pruebas independientes, monitorización y un expediente mantenido. Mi criterio es sencillo: cuanto más difícil sea deshacer el daño, más fuerte debe ser la barrera antes de producción.

Decisiones que deben quedar por escrito

Hay decisiones que no deberían vivir en una reunión ni en un mensaje de chat. Para gobierno del ciclo de vida dejaría documentados el alcance, los supuestos, los límites de uso, las excepciones aceptadas y las condiciones que obligan a detener o reevaluar. El documento no tiene que ser enorme, pero sí debe permitir que otra persona entienda por qué se hizo lo que se hizo.

También registraría quién puede cambiar responsable, quién valida control y quién recibe las alertas relacionadas con evidencia. Cuando esas tres responsabilidades se mezclan, aparece el clásico problema: el mismo equipo construye, aprueba y declara que todo funciona. No siempre se puede separar por completo, sobre todo en organizaciones pequeñas, pero al menos debe existir una revisión por alguien que no dependa del éxito inmediato del despliegue.

Las excepciones merecen un tratamiento propio. Una excepción sin fecha de caducidad acaba convirtiéndose en la arquitectura real. Por eso exigiría motivo, riesgo aceptado, responsable, compensaciones, fecha de revisión y criterio de cierre. Si falta uno de esos elementos, no es una excepción gestionada; es una deuda invisible.

Un ejemplo práctico

Imaginemos que un equipo quiere incorporar gobierno del ciclo de vida a un servicio que ya está en producción. La propuesta promete reducir tiempos y automatizar tareas, pero utiliza componentes que cambian con frecuencia. Antes de aprobarlo, pediría una prueba limitada, un inventario de dependencias, un flujo de datos y una definición clara de qué acciones quedan fuera del alcance.

Durante la prueba recogería resultados normales y casos límite. No solo miraría si funciona; comprobaría qué ocurre cuando faltan datos, cambia una versión, se pierde conectividad, llega una entrada manipulada o un usuario intenta superar sus permisos. Ahí es donde se ve si el diseño aguanta. En muchas pruebas felices todo parece seguro porque nadie ha intentado romper la hipótesis de partida.

Si los resultados son aceptables, la salida a producción tendría condiciones: versión fijada, configuración aprobada, logs disponibles, responsables de guardia, procedimiento de rollback y revisión tras las primeras semanas. Si alguno de esos elementos no existe, prefiero retrasar el despliegue. Un día de demora suele ser más barato que investigar después un comportamiento que nadie puede reconstruir.

Qué evidencias guardaría

Para demostrar que el control funciona conservaría evidencias que cuenten una historia completa, no capturas sueltas. La historia debe enlazar necesidad, decisión, implementación, prueba y operación. En gobierno del ciclo de vida eso incluye como mínimo la ficha del activo, el diagrama vigente, la configuración aprobada, el resultado de las pruebas y el registro de cambios.

No guardaría información por acumular. Si los logs contienen prompts, documentos, datos personales o secretos, aplicaría minimización, control de acceso y retención. La evidencia debe ayudar a investigar y auditar sin crear una segunda fuga de información. Es frecuente endurecer el sistema principal y dejar un repositorio de evidencias abierto a demasiadas personas.

• Propietario y finalidad de gobierno del ciclo de vida, con fecha de revisión.
• Inventario de Gobierno, ciclo y dependencias asociadas.
• Criterios de aceptación y resultados sobre vida y responsable.
• Configuración efectiva, versión y aprobación del cambio.
• Alertas, incidentes, excepciones y acciones correctivas cerradas.

Señales de que el control no está funcionando

El primer síntoma es que nadie sabe responder con rapidez quién es el responsable. El segundo es que la documentación describe una versión distinta de la que está operando. El tercero es que las alertas existen, pero llegan a un buzón que nadie revisa. Cuando aparecen esos tres síntomas, el problema no es tecnológico: el control se ha desconectado de la operación.

También desconfío de las métricas demasiado perfectas. Cero incidentes, cero excepciones y cien por cien de cumplimiento pueden significar excelencia, pero con frecuencia significan que no estamos mirando. Prefiero indicadores que enseñen tendencia: tiempo de corrección, antigüedad de excepciones, cobertura de pruebas, cambios sin revisión y reincidencias.

Por último, revisaría el comportamiento después de cada cambio significativo. En IA, una actualización de modelo, dataset, prompt, herramienta, permiso o proveedor puede alterar el riesgo sin cambiar el nombre del servicio. Si el proceso solo reevalúa cuando se crea un proyecto nuevo, se quedará ciego durante la mayor parte de la vida útil.

Mi criterio de cierre

Considero que gobierno del ciclo de vida está razonablemente controlado cuando el equipo puede explicar el proceso sin depender de una sola persona, reconstruir una decisión con evidencias y detener el servicio sin improvisar. No busco perfección documental; busco que la organización pueda tomar decisiones repetibles bajo presión.

El cierre no consiste en marcar todas las casillas. Consiste en demostrar que los riesgos relevantes tienen propietario, que los controles se prueban y que las desviaciones producen una acción. Si la evidencia no cambia ninguna decisión, probablemente estamos generando burocracia. Si una decisión importante no deja evidencia, estamos creando fragilidad.

Este enfoque es el que intento mantener en toda CyberLibrary AI: explicar el control de forma que lo entienda negocio, pero con suficiente profundidad para que arquitectura, seguridad, auditoría y operaciones puedan aplicarlo de verdad.

Referencias y marcos relacionados

Contenido educativo y técnico. No sustituye asesoramiento jurídico ni una auditoría formal.