Cumplir únicamente con el AI Act no te hace resiliente. Esa es la tesis de un nuevo paper de Oxford que separa dos preguntas que solemos mezclar: ¿es mi IA confiable? y ¿Sobrevive mi negocio si esa IA falla? Son cosas distintas, y la regulación de «IA ética» no responde a la segunda. 

Dos lógicas regulatorias que no se hablan entre sí 

El artículo distingue dos marcos regulatorios que persiguen objetivos distintos: 

  1.  El stack de IA confiable (EU AI Act, ISO/IEC 42001, NIST AI RMF y los principios de la FCA/PRA) se pregunta: ¿Es este sistema seguro, justo y explicable? Su unidad de análisis es el modelo o sistema de IA, y su noción de fallo es el daño, el sesgo o la opacidad. Traducido a preguntas concretas sobre el proceso: ¿hay supervisión humana sobre las decisiones automáticas? ¿Está todo documentado? ¿Cómo se construyó el modelo, qué pruebas se le hicieron, quién es responsable de él? Si quieres profundizar en qué significa construir IA responsable, hablamos de ello a raíz del MWC.
  1. El stack de resiliencia operacional (régimen de resiliencia operacional del Reino Unido, DORA en la UE y el régimen de Terceros Críticos) pregunta algo completamente distinto: Si algo falla, ¿el servicio sobrevive o se recupera a tiempo? Su unidad de análisis es el servicio esencial del negocio, y su noción de fallo es la indisponibilidad o la disrupción intolerable. Traducido a preguntas concretas sobre el proceso: si algo se rompe, ¿el cliente sigue pudiendo pagar con su tarjeta? Y si no puede, ¿cuánto tiempo tarda el servicio en volver a funcionar? 

El problema central que plantea el autor es que estos dos marcos casi nunca se conectan dentro de las organizaciones. Los equipos de AI governance y de riesgo de modelo suelen operar en silos separados de los equipos de resiliencia operacional y de los responsables bajo regímenes como el SMCR. El resultado: una dependencia de IA puede estar perfectamente gobernada desde el punto de vista ético y normativo, sin haber sido nunca mapeada a un servicio importante, sin una tolerancia de impacto asignada y sin evaluación de sustituibilidad. 

Los fallos «silenciosos» que la resiliencia tradicional no detecta 

Uno de los aportes más interesantes del paper es identificar por qué los controles de resiliencia clásicos no bastan para la IA. Los sistemas tradicionales fallan de forma binaria: están disponibles o no lo están. La IA, en cambio, introduce la degradación silenciosa: un modelo puede seguir respondiendo con normalidad, dentro de los tiempos esperados, mientras sus decisiones se vuelven progresivamente menos correctas.  

La monitorización orientada a detectar caídas de servicio reportará que todo está en orden mientras el sistema se deteriora por dentro. Se trata de un fallo de resiliencia que se presenta como disponibilidad total y que resulta invisible para los controles calibrados para detectar interrupciones.  

La concentración de proveedores como riesgo sistémico 

  • Desde el enfoque de «IA confiable», un proveedor externo es básicamente alguien que debe entregar papeleo: documentación, certificados, pruebas de que cumple las normas. Se le trata como una fuente de garantías por escrito. 
  • Desde el enfoque de «resiliencia», ese mismo proveedor se ve de otra manera: como un posible punto débil del sistema. La pregunta ya no es «¿tiene los papeles en regla?», sino «¿qué pasa si este proveedor falla, y cuántas empresas dependen de él al mismo tiempo?» 

El AI Resilience Framework como propuesta central 

Para cerrar esta brecha, el autor propone un marco de cinco pasos, pensado para incorporarse a la gestión de resiliencia que las empresas ya tienen, en lugar de crear un proceso paralelo solo para IA: 

  1. Mapeo de dependencias: identificar qué componentes de IA sostienen cada servicio de negocio importante. 
  2.  Matriz de Criticidad-Sustituibilidad: clasificar cada dependencia según su criticidad para el servicio y su sustituibilidad (sustituible, degradable o irreducible), generando cuatro niveles de tratamiento, desde la «zona de peligro» donde no hay alternativa viable (Tier 1) hasta el tratamiento ligero (Tier 4).
  3.  Tolerancias de impacto extendidas: ir más allá de la disponibilidad e incorporar umbrales de corrección/degradación, con monitorización de data drift y validación continua de resultados.
  4. Doctrina de fallback real: el argumento más contundente del paper: Cuando un sistema de IA ha sustituido a un proceso manual, y ese proceso ha sido dado de baja o se ha dejado atrofiar, el plan de contingencia es ficticio: existe en el papel, pero no cuenta con los recursos —personas, práctica, capacidad— para ejecutarse de verdad. Detectar estos casos debería tratarse como un hallazgo de resiliencia de primer orden.
  5.  Gestión de concentración a nivel de proveedores No basta con evaluar si un proveedor de IA es confiable o cumple normas. También hay que preguntarse: «¿Qué tan fácil sería para nosotros dejar de depender de él si algo sale mal?» Esto implica tratar a los proveedores de modelos fundacionales como proveedores críticos, evaluando no solo sus garantías (seguridad, certificaciones, compliance) sino la propia capacidad de la empresa para sustituirlos si fuera necesario. 

Lo único que falta: mapear la IA como cualquier otra dependencia  

Las empresas ya tienen registros de servicios importantes, tolerancias de impacto y equipos de resiliencia operacional. Lo único que falta es dejar de tratar a la IA como un tema exclusivo de «ética y AI governance » y empezar a mapearla dentro de esa misma estructura, como una dependencia más (igual que una base de datos o un proveedor de nube.) 

En definitiva: ser confiable responde a si el sistema merece la confianza. Ser resiliente responde a si el negocio sobrevive cuando esa confianza no es suficiente. Son preguntas distintas, y solo una de ellas te salva cuando el proveedor cae a las tres de la mañana. 

*La imagen de portada está generada con Inteligencia Artificial*