Por qué los sistemas de IA cambian
Un sistema puede evolucionar aunque la organización no lo haya desarrollado. Puede haber nuevas versiones, modelos, retraining, configuraciones, fuentes de datos, integraciones, usuarios, mercados, proveedores o funcionalidades.
En sistemas externos, algunos cambios pueden venir directamente del proveedor. Por eso la gobernanza no termina cuando el sistema entra en producción: también debe controlar su evolución.
Qué significa gestionar el cambio en IA
Gestionar el cambio significa disponer de un proceso para detectar modificaciones, evaluar su impacto, decidir qué revisar, aprobarlas, documentarlas y monitorizarlas.
El objetivo es mantener coherencia entre lo que se evaluó inicialmente y lo que el sistema es hoy. Un producto puede conservar el mismo nombre y haber cambiado sustancialmente.
Qué cambios deberían activar una revisión
Merecen especial atención los cambios en finalidad prevista, población afectada, contexto, modelo, datos, autonomía, proveedor, integración, supervisión humana, arquitectura, rendimiento y controles.
También los incidentes relevantes, desviaciones y cambios regulatorios. No todos obligan a repetir el proceso completo, pero sí deberían activar la pregunta: ¿qué ha cambiado realmente?
Cambios de modelo y versión
Una nueva versión puede contener mejoras menores o modificar comportamiento, precisión, sesgos, robustez, explicación, límites y funcionalidades.
Conviene registrar versión anterior y nueva, fecha, proveedor, cambios declarados y pruebas realizadas.
La pregunta no es solo “¿es una nueva versión?”, sino “¿cambia algo relevante para riesgo o cumplimiento?”
Cambios en datos
Nuevas fuentes, datasets, categorías, poblaciones, problemas de calidad, representatividad o data drift pueden alterar significativamente el comportamiento.
Aunque el modelo sea el mismo, puede ser necesario revisar riesgos, sesgo, rendimiento, impacto y controles dentro de la gestión de riesgos.
Cambios de finalidad y contexto de uso
Este es uno de los cambios más importantes. Una herramienta de asistencia o borradores puede empezar a utilizarse para selección, evaluación, priorización o recomendaciones con impacto sobre personas.
Cuando cambia la finalidad prevista pueden cambiar riesgo, clasificación y obligaciones. Por eso la finalidad debería estar claramente registrada.
Cambios de proveedor o componentes
Una aplicación puede mantener su interfaz y cambiar el modelo base, API, proveedor cloud, servicio externo o herramienta de monitorización.
Esto introduce dependencias y exige revisar datos, seguridad, rendimiento, documentación, contratos, trazabilidad y responsabilidades mediante la gestión de proveedores.
Cambios en autonomía y supervisión humana
La autonomía puede aumentar gradualmente: primero se revisan todos los outputs, después solo las excepciones y finalmente algunas decisiones se ejecutan automáticamente.
Aunque el sistema técnico parezca igual, el riesgo operativo cambia. Deben revisarse autoridad, escalado, controles, evidencias y supervisión humana.
Cómo evaluar un cambio paso a paso
Paso 1. Registrar y comparar
Documentar qué cambia, cuándo y qué diferencias existen respecto a la situación anterior.
Paso 2. Analizar impacto
Comprobar finalidad, personas afectadas, datos, autonomía, rendimiento, proveedor y riesgos.
Paso 3. Reevaluar riesgos y clasificación
Identificar riesgos nuevos o cambios de severidad y comprobar si la clasificación sigue siendo válida.
Paso 4. Revisar controles y documentación
Adaptar medidas y mantener la trazabilidad.
Paso 5. Aprobar y monitorizar
Definir quién autoriza el cambio y observar el comportamiento después de implantarlo.
El proceso debe ser proporcional.
Cuándo reevaluar riesgos
La evaluación de riesgos no debería ser estática. Puede requerir revisión cuando aparece un riesgo, cambia la probabilidad o el impacto, cambian usuarios, autonomía o datos, ocurre un incidente, cambia el proveedor o se modifica el contexto.
También cuando los controles dejan de ser eficaces.
Un cambio puede no alterar la clasificación regulatoria y, sin embargo, cambiar significativamente el riesgo. Clasificación y gestión de riesgos no son lo mismo.
Cuándo revisar la clasificación del AI Act
La clasificación debería revisarse cuando el cambio pueda modificar los criterios utilizados inicialmente, especialmente finalidad prevista, contexto, población afectada, función, integración o rol de la organización.
El artículo 6 establece las reglas para determinar qué sistemas son de alto riesgo.
El proyecto de directrices de clasificación publicado por la Comisión en 2026 ofrece orientación interpretativa y ejemplos, pero no es vinculante ni sustituye el Reglamento.
Una clasificación anterior no debería darse por válida automáticamente después de un cambio significativo.
Qué es una modificación sustancial
El AI Act define la modificación sustancial como un cambio posterior a la introducción en el mercado o puesta en servicio que no estaba previsto o proyectado en la evaluación inicial de conformidad y que afecta al cumplimiento de los requisitos aplicables a sistemas de alto riesgo o modifica la finalidad prevista para la que se evaluó el sistema.
No todo cambio es una modificación sustancial.
En sistemas de alto riesgo que continúan aprendiendo, determinados cambios previamente definidos por el proveedor y ya evaluados en la evaluación inicial pueden no considerarse sustanciales.
En cambio, un cambio capaz de afectar a la conformidad o finalidad prevista exige un análisis mucho más profundo.
Nueva evaluación de conformidad
El artículo 43 establece que un sistema de alto riesgo ya evaluado debe someterse a una nueva evaluación de conformidad cuando exista una modificación sustancial, tanto si vuelve a distribuirse como si continúa utilizándolo el responsable del despliegue actual.
La gestión del cambio puede conducir a una nueva evaluación de conformidad, pero solo cuando la modificación alcance ese nivel.
Qué documentación y evidencias actualizar
Cada cambio relevante debería dejar evidencia: descripción, fecha, versión, responsable, motivo, análisis de impacto, riesgo previo y posterior, clasificación revisada, controles, pruebas, aprobación y monitorización.
También pueden actualizarse el inventario, el registro práctico, la evaluación de riesgos e impacto, documentación técnica, instrucciones, contratos y evidencias de supervisión.
El objetivo es reconstruir qué cambió, por qué, qué se revisó y qué decisión se tomó.
Cómo integrar el cambio en el gobierno de IA
La gestión del cambio debe conectarse con inventario, riesgo, clasificación, proveedores, evidencias, supervisión humana, monitorización y auditoría.
No debería existir como un procedimiento aislado, sino formar parte del ciclo de vida y del framework de gobierno de IA.
Errores habituales
Revisar solo cuando cambia el modelo
También pueden cambiar datos, finalidad o proveedor.
Confundir actualización con modificación sustancial
No son equivalentes.
Mantener la clasificación sin revisarla
El contexto puede haber cambiado.
No registrar la versión
Dificulta la trazabilidad.
Depender solo de información del proveedor
La organización también debe evaluar su propio uso.
No reevaluar supervisión
Un cambio de autonomía puede modificar significativamente el riesgo.
No actualizar evidencias
Después resulta difícil explicar qué ocurrió.
El riesgo no termina cuando el sistema entra en producción
Un sistema puede empezar siendo adecuado para un contexto y dejar de serlo después de varios cambios.
La gestión del cambio conecta:
cambio → impacto → riesgo → clasificación → controles → evidencias.
El objetivo no es paralizar cada actualización. Es saber cuándo una actualización cambia algo importante.
Cuando el proceso funciona, la organización deja de gobernar únicamente la IA que aprobó en el pasado y gobierna la IA que realmente utiliza hoy.
Referencias
- Regulation (EU) 2024/1689 — Artificial Intelligence Act.
- Article 3(23) — Substantial modification.
- Article 6 — Classification rules for high-risk AI systems.
- Article 43 — Conformity assessment.
- Annex IV — Technical documentation.
- European Commission — Draft Guidelines on the classification of high-risk AI systems.
- ISO/IEC 42001:2023 — Artificial intelligence management system.
- ISO/IEC 23894:2023 — Guidance on AI-related risk management.
¿Sabes qué cambios deberían activar una nueva revisión de tu IA?
Cambiar un modelo, un proveedor, los datos o la finalidad puede alterar riesgos, controles y clasificación.
Realizar diagnóstico →
El diagnóstico de Céntrika puede ayudarte a identificar qué elementos del gobierno ya existen y dónde siguen existiendo brechas.