Un sistema de IA no se gobierna solo mientras está en producción: se gobierna desde la primera idea hasta el día en que se apaga. El Reglamento de Inteligencia Artificial (RIA) vincula obligaciones concretas a cada etapa, de la finalidad prevista a la conservación de la documentación durante diez años. Aquí recorremos el ciclo de vida de la IA desde la gobernanza: fases, deberes, puertas de decisión, control de cambios y retirada.
Lo esencial
- La gestión del ciclo de vida de la IA es gobernanza: decide quién pasa un sistema a la fase siguiente, con qué evidencias y qué se conserva. El MLOps automatiza; no decide.
- El texto inglés del RIA usa «lifecycle» solo 11 veces, pero casi todas las obligaciones de alto riesgo se activan en una fase concreta.
- Una modificación sustancial reabre la evaluación de la conformidad y puede convertir al responsable del despliegue en proveedor.
- Desde el Reglamento (UE) 2026/1744, los sistemas de alto riesgo heredados solo entran en el ámbito por cambios significativos de diseño.
- La retirada, la fase que nadie planifica, concentra la salida del mercado, la base de datos de la UE, diez años de archivo y el borrado de datos.
Gestión del ciclo de vida de la IA: qué es y qué deja fuera el MLOps
Las páginas que copan esta búsqueda (IBM, AWS, la guía de la GSA estadounidense y varios proveedores de MLOps, CRM y seguridad) describen el ciclo de vida de la IA como una cadena de ingeniería: problema, datos, entrenamiento, evaluación, despliegue y monitorización. El resumen de IA de Google acaba preguntando si el lector busca herramientas de MLOps o gobernanza y cumplimiento: esa segunda mitad es el hueco. De las diez páginas legibles mejor posicionadas que hemos revisado, ninguna cita ISO/IEC 42001, 5338 o 22989 ni a la OCDE, ninguna menciona la notificación de incidentes graves, una sola cita un artículo del RIA y dos hablan de la retirada.
Nuestra definición: la gestión del ciclo de vida de la IA consiste en gobernar un sistema en todas sus fases, con responsables, decisiones, evidencias, control de cambios y una retirada planificada. Empieza por el inventario de sistemas de IA: lo que no está inventariado no tiene fase.
El MLOps automatiza canalizaciones: reentrena, versiona, despliega y vigila métricas. La gestión del ciclo de vida de la IA decide quién autoriza el paso siguiente, con qué pruebas y qué se archiva. Una canalización puede desplegar un modelo de madrugada; no puede firmar que ese modelo sigue sirviendo a su finalidad prevista.
El RIA no define el ciclo de vida de la IA, pero lo presupone. El artículo 9.2 concibe la gestión de riesgos como «un proceso iterativo continuo planificado y ejecutado durante todo el ciclo de vida de un sistema de IA de alto riesgo, que requerirá revisiones y actualizaciones sistemáticas periódicas». El artículo 15.1 exige precisión, solidez y ciberseguridad uniformes «durante todo su ciclo de vida»; el anexo IV, punto 6, una descripción de los cambios pertinentes a lo largo de ese ciclo; el artículo 12.1, registros durante toda la vida del sistema, y el artículo 72.2, datos poscomercialización durante toda su vida útil. En la versión inglesa del Reglamento (UE) 2024/1689 contamos 11 apariciones de «lifecycle»: 7 en los considerandos y 4 en el articulado y los anexos (artículos 9.2, 15.1 y 40.2, y anexo IV, punto 6).
Las fases: cuatro modelos de referencia comparados
No existe un único ciclo de vida de la IA. Cruzamos nuestro modelo de ocho fases con las referencias que citará un auditor: ISO/IEC 22989, retomada por el Supervisor Europeo de Protección de Datos (SEPD) en su guía de 11 de noviembre de 2025, el NIST AI RMF, los principios de la OCDE y el anexo A.6.2 de ISO/IEC 42001.
| Fase (nuestro modelo) | ISO/IEC 22989 / SEPD | NIST AI RMF | OCDE | ISO/IEC 42001, anexo A.6.2 |
|---|---|---|---|---|
| Concepción y finalidad prevista | Concepción y análisis | Planificar y diseñar | Diseño, datos y modelos | Requisitos y especificación (A.6.2.2) |
| Adquisición y preparación de datos | Adquisición y preparación de datos | Recopilar y procesar datos | Diseño, datos y modelos | (controles de datos en A.7) |
| Diseño y desarrollo | Desarrollo | Construir y usar el modelo | Diseño, datos y modelos | Documentación de diseño y desarrollo (A.6.2.3) |
| Verificación y validación | Verificación y validación | Verificar y validar | Verificación y validación | Verificación y validación (A.6.2.4) |
| Despliegue | Despliegue | Desplegar y usar | Despliegue | Despliegue (A.6.2.5) |
| Operación y seguimiento | Operación y seguimiento; validación continua | Operar y supervisar | Operación y seguimiento | Operación y seguimiento (A.6.2.6); registros de eventos (A.6.2.8) |
| Reevaluación y cambio | Reevaluación | (TEVV durante todo el ciclo) | (iterativo, no secuencial) | Documentación técnica al día (A.6.2.7) |
| Retirada | Retirada | (no es una fase propia) | Se decide durante la operación y el seguimiento | (sin control específico) |
Los nombres del NIST son traducción nuestra; su figura en el NIST AI 100-1 (enero de 2023) está adaptada del marco de clasificación de la OCDE. Falta una norma que ordena procesos, no fases: ISO/IEC 5338:2023, publicada en diciembre de 2023 por el JTC 1/SC 42. Se apoya en ISO/IEC/IEEE 15288 y 12207, añade procesos propios de la IA tomados de ISO/IEC 22989 e ISO/IEC 23053 y se aplica tanto si usted desarrolla el sistema como si lo adquiere. Nuestra recomendación: elija un único modelo de trabajo, mapee los demás sobre él y no mantenga nunca tres en paralelo, porque tres modelos son tres juegos de evidencias. Lo explicamos en la pila de normas de ISO 42001.
Deberes del RIA en cada fase del ciclo de vida de la IA
Cruzadas con el RIA, las ocho fases del ciclo de vida de la IA dan un sitio a casi todas las obligaciones de un sistema de IA de alto riesgo. La última columna es lo que pedirá una autoridad o un organismo notificado.
| Fase | Qué exige el RIA | Artículos | Evidencias que conservar |
|---|---|---|---|
| Concepción y finalidad prevista | Definir la finalidad prevista, clasificar e iniciar la gestión de riesgos | Arts. 3.12, 6, 9.1 y 9.2 | Declaración de finalidad, nota de clasificación, registro de riesgos abierto |
| Adquisición y preparación de datos | Gobernanza de los datos de entrenamiento, validación y prueba | Art. 10; anexo IV, punto 2.d) | Fichas de datos, procedencia, examen de sesgos |
| Diseño y desarrollo | Documentación técnica previa; transparencia e instrucciones; supervisión humana desde el diseño; precisión, solidez y ciberseguridad | Arts. 11, 13, 14, 15 y 17.1.b)-c) | Expediente del anexo IV, instrucciones de uso, model card, diseño de la supervisión |
| Verificación y validación | Pruebas con métricas definidas antes de comercializar; evaluación de la conformidad, declaración UE y marcado CE | Arts. 9.6-9.8, 17.1.d), 43, 47 y 48 | Informes de prueba, expediente de conformidad, declaración UE |
| Despliegue | Registro previo en la base de datos de la UE (anexo III); deberes del responsable del despliegue; evaluación de impacto en derechos fundamentales para ciertos responsables | Arts. 49, 26 y 27 | Justificante de registro, lista de comprobación, evaluación de impacto si procede |
| Operación y seguimiento | Registros durante toda la vida del sistema; vigilancia poscomercialización; seguimiento y suspensión por quien despliega; incidentes graves | Arts. 12, 19, 26.5, 26.6, 72 y 73 | Conservación de registros, plan e informes de vigilancia, registro de incidentes |
| Cambio | La modificación sustancial exige nueva evaluación, no así los cambios predeterminados (anexo IV, punto 2.f); el responsable del despliegue que la introduce pasa a ser proveedor | Arts. 3.23, 43.4 y 25.1; anexo IV, punto 6 | Registro de cambios con decisión de triaje, documentación actualizada |
| Retirada | Medidas correctoras, retirada, desactivación o recuperación; archivo de diez años; estado en la base de datos | Arts. 20 y 18; anexo VIII, sección A, punto 7 | Acta de desmantelamiento, calendario de conservación, prueba de borrado |
Con el Reglamento (UE) 2026/1744, el Ómnibus digital sobre IA, las obligaciones de alto riesgo del anexo III del Reglamento de IA se aplican desde el 2 de diciembre de 2027 y las del anexo I (productos) desde el 2 de agosto de 2028. El Ómnibus integró el plan de vigilancia poscomercialización en la documentación técnica del anexo IV, encargó a la Comisión orientaciones con plantilla antes del 2 de septiembre de 2027 (nuevo artículo 72.3) e hizo proporcional el sistema de gestión de la calidad al tamaño de las pymes y de las pequeñas empresas de mediana capitalización (artículo 17.2).
Puertas de fase del ciclo de vida de la IA: quién decide y con qué evidencias
Una puerta de fase es el punto en que alguien con autoridad decide, sobre evidencias, si el sistema avanza. El ciclo de vida de la IA solo es gobernable si cada puerta deja rastro. Proponemos seis.
- <b>Alta.</b> El sistema entra en el inventario con un responsable designado y una finalidad prevista por escrito. Sin esos dos datos no hay nada que clasificar ni nadie a quien pedir cuentas.
- <b>Aprobación del diseño.</b> Con la clasificación, la evaluación de impacto y el registro de riesgos sobre la mesa, el comité de gobernanza decide si el proyecto sigue o se detiene. Es la decisión más barata de revertir.
- <b>Puesta en producción.</b> La validación supera métricas fijadas de antemano, la documentación está completa y la supervisión humana tiene titulares con nombre. Si es de alto riesgo, la evaluación de la conformidad y el registro están hechos.
- <b>Triaje de cambios.</b> Todo cambio de modelo, datos o finalidad se registra y se clasifica como rutinario, predeterminado o sustancial, con motivo y firma.
- <b>Reevaluación periódica.</b> Al menos una vez al año, y siempre tras un incidente, se comparan los resultados reales con los riesgos identificados. Si divergen, se actualiza el registro de riesgos y se abre la puerta 4.
- <b>Retirada.</b> Decisión motivada, notificación, archivo y borrado de lo que no deba conservarse. El sistema se cierra como se abrió: con una firma.
El responsable de negocio responde de la finalidad prevista; el comité de gobernanza de la IA decide en las puertas 2, 3 y 6; la asesoría jurídica y el delegado de protección de datos validan la clasificación y la base jurídica; la validación de modelos o segunda línea revisa las métricas, como ya hace la gestión del riesgo de modelos en banca, y seguridad aprueba accesos y registros. En AI Sigil, el registro de sistemas de IA modela cada proceso como una sucesión de fases, con formularios y aprobaciones por fase.
Control de cambios: cuándo una actualización se convierte en modificación sustancial
El cambio es el momento en que el ciclo de vida de la IA se convierte en derecho. El artículo 3.23 define la modificación sustancial como un cambio posterior a la comercialización o puesta en servicio, no previsto ni planificado en la evaluación de la conformidad inicial, que afecta a los requisitos del capítulo III, sección 2, o modifica la finalidad prevista.
Según el artículo 43.4, hay que repetir la evaluación de la conformidad, se siga distribuyendo el sistema o lo siga usando el responsable del despliegue actual. Para los sistemas que siguen aprendiendo, los cambios predeterminados en la evaluación inicial y descritos en el anexo IV, punto 2, letra f), no cuentan como modificación sustancial. Según el artículo 25.1, letras b) y c), quien modifica sustancialmente un sistema de alto riesgo, o cambia la finalidad prevista de otro hasta hacerlo de alto riesgo, pasa a ser proveedor.
El artículo 111.2 modificado por el Ómnibus solo atrae al ámbito a los sistemas de alto riesgo comercializados antes de la fecha de aplicación del capítulo III si, desde esa fecha, sufren cambios significativos en su diseño. Un considerando aclara que «cambio significativo» equivale en sustancia a modificación sustancial. Para el parque heredado, el control de cambios es el detonante.
La Comisión publicó el 19 de mayo de 2026 un proyecto de directrices sobre la clasificación de alto riesgo, con consulta prorrogada hasta el 23 de julio de 2026 y versión final prevista para finales de año, y cuenta las directrices sobre modificación sustancial entre las que la Oficina de IA aún prepara. El documento de CERRE de junio de 2026 defiende que los cambios rutinarios del ciclo de vida de la IA queden, por regla general, fuera de ese régimen, en coherencia con la excepción del artículo 43.4, y pone el ejemplo de un suministrador que sustituye el modelo de uso general subyacente por una versión más reciente.
Fuera de la UE, la guía final de la FDA sobre planes de control de cambios predeterminados para software de dispositivos con IA (4 de diciembre de 2024, resumen jurídico) divide el plan en tres partes: descripción de las modificaciones, protocolo de modificación y evaluación de impacto. Sirve de plantilla para el plan del anexo IV, punto 2, letra f).
Preguntas de triaje
- ¿Altera el cambio la finalidad prevista?
- ¿Afecta a un requisito del capítulo III: precisión, solidez, supervisión humana o datos?
- ¿Estaba predeterminado en la documentación técnica?
- ¿Quién lo introduce: proveedor, responsable del despliegue o suministrador?
- ¿Afecta a un sistema heredado después de la fecha de aplicación?
Operación y seguimiento: registros, deriva e incidentes
Una vez desplegado, el sistema entra en la fase más larga del ciclo de vida de la IA y, a menudo, en la peor documentada. El proveedor de un sistema de alto riesgo mantiene un sistema de vigilancia poscomercialización que recopila y analiza datos durante toda su vida útil (artículo 72, apartados 1 y 2). El responsable del despliegue vigila el funcionamiento conforme a las instrucciones de uso, informa al proveedor y suspende el uso cuando aprecia un riesgo (artículo 26.5).
Los registros son la memoria de esta fase. Proveedores (artículo 19.1) y responsables del despliegue (artículo 26.6) los conservan al menos seis meses, salvo que otra norma de la Unión o nacional disponga otra cosa. El artículo 12 exige que el sistema permita técnicamente ese registro automático, e ISO/IEC 42001 deja a la organización decidir en qué fases lo activa (control A.6.2.8).
Para los incidentes graves, el artículo 73 fija plazos: notificación inmediata y, en todo caso, no más tarde de 15 días desde que se tiene conocimiento; 2 días en caso de infracción generalizada o de incidente grave del artículo 3, punto 49, letra b) (infraestructuras críticas); 10 días en caso de fallecimiento. Se admite un informe inicial incompleto seguido del completo (artículo 73.5). La Comisión ha publicado una plantilla de notificación de incidentes graves, y nuestra guía sobre notificación de incidentes de IA detalla el circuito interno.
La otra amenaza es silenciosa: la deriva del modelo, cuando los datos reales se alejan de los de entrenamiento y el rendimiento cae sin que nada falle a la vista. Por eso el SEPD trata la «validación continua» como una fase propia para los sistemas que siguen aprendiendo. Nuestra recomendación: fijar umbrales de deriva en la puerta 3 y conectar cada alerta con el triaje de la puerta 4.
La retirada: la fase que nadie planifica
La retirada es la fase menos pensada del ciclo de vida de la IA. La guía del SEPD incluye en su anexo 3 una lista de riesgos por fase que no asigna ninguno al despliegue ni a la retirada; de esta última solo dice que el sistema debe desmantelarse de forma responsable y eficiente. El ciclo de la OCDE ni siquiera tiene una fase de retirada separada: la decisión puede tomarse durante la operación y el seguimiento. En nuestra revisión, solo dos de las diez primeras páginas la mencionan.
Pero las obligaciones aterrizan justo ahí. El artículo 20 obliga al proveedor a retirar del mercado, desactivar o recuperar el sistema que no sea conforme, e informar a distribuidores y responsables del despliegue. El artículo 18 exige conservar durante diez años desde la introducción en el mercado la documentación técnica, la del sistema de gestión de la calidad y la declaración UE de conformidad: el archivo sobrevive al sistema. El anexo VIII, sección A, punto 7, prevé que la base de datos de la UE indique si el sistema ya no se comercializa, ya no está en servicio o ha sido recuperado. A ello se suman la conservación de los registros y, para los datos personales de entrenamiento e inferencia, la limitación del plazo de conservación y el derecho de supresión del RGPD.
Lista de comprobación para la retirada:
- Decisión y motivo registrados, con fecha efectiva.
- Responsables del despliegue y usuarios informados.
- Accesos revocados y artefactos del modelo archivados o borrados.
- Datos personales borrados o anonimizados conforme al calendario de conservación.
- Documentación archivada durante todo el plazo legal, accesible para una auditoría de IA.
- Inventario y estado en la base de datos de la UE actualizados; si hay sistema sustituto, entra por la puerta de alta.
Comprado, no desarrollado: el ciclo de vida de la IA del responsable del despliegue
La mayoría de las organizaciones no desarrolla su IA: la compra. El SEPD describe, para las instituciones de la UE sujetas al Reglamento 2024/2509, un proceso de contratación en cuatro pasos: publicación y transparencia, licitación, selección y adjudicación, y ejecución. Dentro de la ejecución se repiten la verificación y la validación, el despliegue, la operación y el seguimiento, la validación continua, la reevaluación y la retirada. El ciclo de vida de la IA no desaparece al comprar: se traslada al contrato.
Cinco cláusulas lo hacen gobernable:
- Aviso previo de todo cambio de modelo o versión.
- Acceso a los registros que genera el sistema.
- Cooperación ante incidentes y en su notificación.
- Documentación e instrucciones de uso completas y al día.
- Fin de vida pactado, con devolución o borrado de los datos.
Nuestra guía de due diligence de proveedores de IA desarrolla cada una. Tenga presente el riesgo del artículo 25: si comercializa el sistema con su nombre o marca, o lo modifica sustancialmente, asume las obligaciones del proveedor.
En España, la AESIA (Agencia Española de Supervisión de la Inteligencia Artificial) es la autoridad de supervisión de referencia, y la AEPD sigue siendo competente para cualquier tratamiento de datos personales a lo largo del ciclo. La experiencia del entorno controlado de pruebas nacional de 2025 es una primera referencia práctica para documentar cada fase ante un supervisor. En Alemania, la ley KI-MIG, en vigor desde el 29 de julio de 2026, designa a la Bundesnetzagentur como autoridad de vigilancia del mercado; en Italia, la legge 132/2025 confía ese papel a AgID y ACN.
Preguntas frecuentes
<b>¿Qué es la gestión del ciclo de vida de la IA?</b>
Es la disciplina que gobierna un sistema de IA desde la primera idea hasta su retirada: asigna un responsable, fija puertas de decisión entre fases, define sus evidencias, controla los cambios y planifica el final. Las herramientas de ingeniería automatizan entrenamiento y despliegue; la gestión del ciclo de vida de la IA decide quién autoriza cada paso y qué se archiva. En alto riesgo, es la vía más directa para demostrar el cumplimiento del RIA.
<b>¿Cuáles son las fases del ciclo de vida de la IA?</b>
Depende del marco. ISO/IEC 22989 y el SEPD distinguen nueve fases, de la concepción a la retirada; el NIST AI RMF, seis; la OCDE agrupa diseño, datos y modelos y no separa la retirada. Nuestro modelo de trabajo usa ocho, de la concepción y la finalidad prevista a la retirada, con una fase propia para la reevaluación y el cambio. Lo importante no es el número, sino elegir un modelo y mapear los demás sobre él.
<b>¿Exige el Reglamento de IA de la UE gestionar el ciclo de vida de la IA?</b>
No con ese nombre, pero sí en la práctica. El artículo 9.2 exige una gestión de riesgos continua durante todo el ciclo de vida de los sistemas de alto riesgo, el artículo 15.1 un rendimiento uniforme durante ese ciclo y el anexo IV, punto 6, documentar los cambios. El resto de obligaciones se activa en fases concretas: datos, documentación, conformidad, registro, vigilancia, incidentes y archivo. Sin fases gestionadas, es difícil aportar las evidencias que pedirá una autoridad.
<b>¿Qué diferencia hay entre la gestión del ciclo de vida de la IA y el MLOps?</b>
El MLOps automatiza la cadena técnica: versionado de datos y modelos, entrenamiento, pruebas, despliegue y monitorización. La gestión del ciclo de vida de la IA es gobernanza: decide quién pasa un sistema a la fase siguiente, con qué evidencias, quién valida un cambio y cuándo se retira. Se complementan: el MLOps produce buena parte de las evidencias (métricas, registros, versiones), pero no firma decisiones. Una organización madura conecta sus canalizaciones con sus puertas de fase.
<b>¿Cuándo un cambio se considera una modificación sustancial?</b>
Cuando, tras la comercialización o la puesta en servicio, el cambio no estaba previsto en la evaluación de la conformidad inicial y afecta a los requisitos del capítulo III, sección 2, o modifica la finalidad prevista (artículo 3.23). Entonces hay que repetir la evaluación (artículo 43.4), salvo los cambios predeterminados de sistemas que siguen aprendiendo, descritos en el anexo IV, punto 2, letra f). Si el cambio lo introduce el responsable del despliegue, este pasa a ser proveedor (artículo 25.1).
<b>¿Qué ocurre cuando se retira un sistema de IA?</b>
El proveedor que retira, desactiva o recupera un sistema no conforme informa a distribuidores y responsables del despliegue (artículo 20). La documentación técnica, la del sistema de gestión de la calidad y la declaración UE de conformidad se conservan diez años (artículo 18), y el estado se actualiza en la base de datos de la UE. Los datos personales se borran o anonimizan según el RGPD. Es la última puerta del ciclo de vida de la IA: se cierra con una decisión documentada.
Conclusión
El ciclo de vida de la IA no es un diagrama de ingeniería: es una cadena de decisiones con nombre, fecha y evidencias. El RIA apenas usa la palabra, pero cuelga de cada fase una obligación, y el Ómnibus ha hecho del control de cambios la puerta por la que entran los sistemas heredados. Llegarán tranquilas al 2 de diciembre de 2027 las organizaciones que hayan hecho tres cosas: inventariar sus sistemas con responsable y finalidad prevista, fijar puertas con evidencias definidas y planificar la retirada antes de necesitarla. Le proponemos empezar por lo sencillo: tome un sistema real, recórralo con nuestras ocho fases y anote la evidencia que falta en cada una. Esa lista es su primer plan de gestión del ciclo de vida de la IA y el orden del día de su próximo comité de gobernanza.