Auditar el ciclo de vida de la IA: de la idea al retiro
Un sistema de IA puede superar todas las pruebas antes de su lanzamiento y, seis meses después, operar en un contexto distinto al aprobado. Puede cambiar la población de usuarios, degradarse la calidad de los datos, aparecer una nueva obligación legal, actualizarse un modelo de un proveedor o descubrirse que las personas están utilizando la herramienta para decisiones que nunca estuvieron dentro de su propósito original.
Por eso, auditar IA no es revisar un modelo en un momento determinado. Es evaluar si la organización mantiene control sobre las decisiones que permiten que ese sistema nazca, cambie, permanezca en producción y, cuando corresponda, deje de utilizarse.
La tesis práctica es sencilla: una auditoría del ciclo de vida debe seguir la cadena de decisiones y evidencias entre etapas, no tratar cada etapa como una isla. ISO/IEC 42001 aporta criterios de sistema de gestión y controles de referencia; el NIST AI Risk Management Framework aporta una lógica continua de gobierno, contextualización, medición y gestión del riesgo. Juntos ayudan a convertir el ciclo de vida en algo auditable.
El riesgo aparece en los traspasos, no solo dentro del modelo
Muchas organizaciones concentran su control en desarrollo y validación, pero varios fallos relevantes nacen en los traspasos de responsabilidad: una idea avanza sin propietario claro, una excepción de prueba no bloquea el despliegue, un proveedor cambia un componente sin reevaluación o un sistema sigue activo porque nadie definió criterios de retiro.
ISO/IEC 42001:2023 exige que la organización gestione riesgos de IA, evalúe impactos cuando corresponda y planifique los cambios de su sistema de gestión. Su Anexo A incluye controles de referencia sobre requisitos, diseño y desarrollo, verificación y validación, despliegue, operación y monitoreo, documentación técnica, registros, datos y relaciones con terceros. Es importante una precisión: esos controles no son una lista que deba aplicarse idénticamente a todos los sistemas. La propia norma requiere determinar los controles necesarios mediante el tratamiento del riesgo y justificar inclusiones y exclusiones en la declaración de aplicabilidad.
NIST adopta otra perspectiva: Govern, Map, Measure y Manage no son fases consecutivas, sino funciones iterativas a lo largo del ciclo de vida. Para auditoría, cada etapa debe mantener visibles la responsabilidad, el contexto y riesgo aceptado, la evidencia de desempeño e impacto y la respuesta prevista.
Un buen control de ciclo de vida no solo demuestra que el sistema funciona. Demuestra por qué la organización decidió permitir que siguiera avanzando.
Siete puertas de aseguramiento, de la idea al retiro
No existe una única secuencia obligatoria para todas las organizaciones. Sin embargo, siete puertas de decisión ofrecen una estructura práctica para diseñar un trabajo de auditoría.
| Etapa | Pregunta de auditoría | Evidencia esperada | Procedimientos útiles |
|---|---|---|---|
| Aprobación | ¿Debe utilizarse IA para este propósito y bajo qué nivel de riesgo? | Caso de negocio, propietario, propósito previsto, clasificación de riesgo, evaluación inicial de impacto, requisitos legales, decisión go/no-go | Rastrear la aprobación hasta criterios definidos; comprobar segregación de responsabilidades; desafiar alternativas no basadas en IA y supuestos críticos |
| Diseño | ¿Los requisitos convierten los objetivos y riesgos en criterios verificables? | Requisitos funcionales y de control, usuarios previstos, límites de uso, necesidades de datos, supervisión humana, criterios de aceptación | Comparar requisitos con riesgos e impactos; revisar escenarios de uso indebido; verificar que métricas y umbrales puedan probarse |
| Desarrollo | ¿La solución se construye con trazabilidad y controles adecuados? | Versiones, procedencia y calidad de datos, decisiones de diseño, registros de experimentos, controles de acceso, pruebas y excepciones | Seleccionar cambios y versiones; rastrear datos a sus fuentes; evaluar excepciones; integrar especialistas cuando el objetivo requiera validación técnica profunda |
| Despliegue | ¿La evidencia justifica liberar el sistema al entorno real? | Resultados de verificación y validación, criterios de liberación, aprobaciones, configuración de producción, instrucciones de uso, plan de monitoreo y reversión | Reejecutar una muestra de criterios de liberación; reconciliar versión aprobada con versión desplegada; comprobar que controles y monitoreo están activos antes del lanzamiento |
| Monitoreo | ¿El sistema sigue operando dentro de límites aceptables? | Métricas de desempeño y riesgo, alertas, incidentes, quejas, anulaciones humanas, deriva, soporte y revisiones periódicas | Analizar tendencias; inspeccionar excepciones e incidentes; probar alertas; evaluar si cambios en contexto, datos o uso activan una reevaluación |
| Cambio | ¿La modificación reabre los riesgos y aprobaciones correctos? | Solicitud de cambio, clasificación de materialidad, análisis de impacto, revalidación, nueva aprobación, documentación e inventario actualizados | Muestrear cambios de modelos, datos, prompts, proveedores o finalidad; comprobar criterios de materialidad; verificar que los cambios relevantes regresan a etapas anteriores |
| Retiro | ¿Puede desactivarse el sistema sin crear nuevos riesgos? | Decisión de retiro, dependencias, migración, conservación de registros, tratamiento de datos, revocación de accesos, actualización del inventario | Verificar dependencias aguas arriba y abajo; revisar retención legal y forense; comprobar desactivación de interfaces y credenciales; confirmar transición a procesos sustitutos |
La tabla crea puntos de decisión auditables, no una lista mecánica. La profundidad debe aumentar con el impacto, la complejidad y la exposición del sistema.
La evidencia más valiosa es la trazabilidad entre decisiones
El auditor debería poder tomar una afirmación aprobada al inicio y seguirla hasta la operación real. Por ejemplo: si el caso de uso declara que una persona siempre revisará una recomendación antes de actuar, esa expectativa debería aparecer en los requisitos, en el diseño de la interfaz, en las pruebas, en los procedimientos de operación y, finalmente, en registros que permitan comprobar que la supervisión ocurre realmente.
Ese principio puede expresarse como una cadena:
propósito → requisitos → riesgos e impactos → controles → pruebas → aprobación → monitoreo → cambios → retiro.
Una métrica sin riesgo asociado, una aprobación sin umbral de aceptación, una actualización del proveedor sin revalidación o un sistema retirado con accesos activos son señales de que la cadena se rompió.
Para sistemas de terceros, la trazabilidad es especialmente importante. ISO/IEC 42001 incluye controles de referencia para asignar responsabilidades entre la organización, proveedores y otras partes. El auditor no necesita exigir acceso irrestricto al modelo para obtener aseguramiento útil, pero sí debe entender qué responsabilidad conserva la organización, qué evidencia obtiene del proveedor y qué ocurre cuando el servicio cambia.
ISO/IEC 42001 y NIST cumplen papeles distintos
Los dos marcos son complementarios, pero no deben presentarse como equivalentes.
| Marco | Qué aporta | Cómo utilizarlo en auditoría |
|---|---|---|
| ISO/IEC 42001:2023 | Requisitos para un sistema de gestión de IA y controles de referencia que abarcan riesgo, impacto, recursos, ciclo de vida, datos, uso y terceros | Utilizar requisitos aplicables, políticas internas y controles seleccionados en la declaración de aplicabilidad como criterios de evaluación; distinguir requisitos de orientación de implementación |
| NIST AI RMF 1.0 | Marco voluntario y basado en resultados para gestionar riesgos y características de confianza mediante Govern, Map, Measure y Manage | Utilizarlo para estructurar preguntas de riesgo, expectativas de gobernanza y procedimientos; no tratar sus funciones como fases ni convertir el Playbook en checklist obligatorio |
Una diferencia resulta especialmente útil al final del ciclo. El NIST AI RMF es explícito en Govern 1.7 sobre contar con procesos para retirar o desmantelar sistemas de IA de forma segura. ISO/IEC 42001 aborda el ciclo de vida desde requisitos y desarrollo hasta operación y monitoreo, e incorpora el desmantelamiento en consideraciones de recursos y riesgo. Para un programa de auditoría, el resultado práctico es el mismo: el retiro merece criterios, responsables y evidencia, no una simple eliminación técnica.
Cuatro fallos frecuentes en una auditoría del ciclo de vida. Cuatro patrones debilitan el aseguramiento: auditar solo el lanzamiento; aplicar la misma profundidad a todos los sistemas; tratar cambios materiales como mantenimiento rutinario; e ignorar el retiro. La respuesta es un enfoque basado en riesgos que ajuste pruebas y monitoreo, obligue a reevaluar cambios relevantes y establezca criterios de desmantelamiento, dependencias y conservación de evidencia.
Un programa de auditoría que prueba decisiones, no documentos
Un objetivo de trabajo podría formularse así: determinar si los sistemas de IA son gobernados durante su ciclo de vida mediante criterios de etapa, responsabilidades, evidencia, monitoreo y controles de cambio y retiro proporcionales al riesgo.
A partir de ese objetivo, un programa práctico puede seleccionar una muestra de sistemas y:
- reconstruir la decisión original de aprobación y comprobar que el propósito previsto coincide con el uso actual;
- rastrear riesgos e impactos hacia requisitos, controles y criterios de prueba;
- reconciliar la versión aprobada con la versión efectivamente desplegada;
- evaluar si las métricas operativas tienen umbrales, responsables y respuestas definidas;
- seleccionar cambios recientes y comprobar si activaron revalidación, nuevas aprobaciones o actualización del inventario;
- revisar un sistema retirado o próximo a retirarse para verificar dependencias, conservación de evidencia, accesos y transición.
La pregunta final no es si la organización tiene documentos para cada fase. Es si puede demostrar, con evidencia coherente, por qué un sistema debía avanzar, por qué podía permanecer en operación, cuándo debía volver a evaluarse y cómo se decidió detenerlo.
Ese es el valor de auditar el ciclo de vida: convertir la gobernanza de IA en una secuencia de decisiones verificables, desde la primera idea hasta el último registro conservado después del retiro.