Grandes interrupciones de la IA impulsan normas de resiliencia

Las grandes interrupciones de la IA impulsan normas de resiliencia porque las organizaciones ya no consideran los modelos avanzados como herramientas opcionales de productividad. Cuando un servicio de IA respalda las operaciones con clientes, el desarrollo de software, el análisis de fraude, las tareas de seguridad o la supervisión de infraestructuras críticas, la pérdida de disponibilidad puede interrumpir procesos empresariales reales. La cobertura del sector a principios de septiembre de 2026 describió una «triple interrupción de la IA» como una llamada de atención y defendió la adopción de flujos de trabajo alternativos, estrategias multimodelo y planes de continuidad.

La respuesta normativa va más allá del mero tiempo de actividad. Las autoridades europeas están vinculando la disponibilidad de la IA con la ciberseguridad, la continuidad operativa, la notificación de incidentes, el comportamiento de los modelos y el riesgo sistémico. En Estados Unidos, legisladores y empresas de IA debaten salvaguardias vinculantes para sistemas de gran capacidad. El resultado práctico es un cambio: ya no se pregunta si un modelo es impresionante, sino si todo el servicio dependiente de la IA puede fallar de forma segura, recuperarse de manera predecible y seguir sujeto a rendición de cuentas cuando los proveedores, modelos, integraciones o controles dejan de funcionar.

Por qué las interrupciones repetidas de la IA han cambiado el cálculo del riesgo

Una interrupción aislada puede gestionarse como un incidente técnico. Las interrupciones repetidas plantean una pregunta diferente: ¿ha construido la organización un flujo de trabajo crítico en torno a un servicio que no controla? Esta pregunta adquiere mayor urgencia cuando se accede al servicio mediante una interfaz externa de programación de aplicaciones, está integrado en software de terceros o depende de un proveedor de modelos de frontera.

Los comentarios e informes recientes sugieren que las interrupciones repetidas de los servicios de IA están trasladando la IA de la categoría de «complemento de productividad» a la de infraestructura operativa. Esto no significa que todos los chatbots necesiten los mismos controles que una red de pagos. Significa que las medidas de resiliencia deben reflejar lo que sucede si el componente de IA deja de estar disponible, se vuelve poco fiable o inseguro, o resulta inaccesible en un momento crítico.

La disponibilidad es solo un modo de fallo

La resiliencia de la IA requiere una perspectiva más amplia que el tiempo de actividad convencional de un servicio. Un punto de acceso de un modelo puede responder y, aun así, producir un comportamiento que haga inutilizable un flujo de trabajo. Un proveedor puede seguir en línea mientras una función dependiente, una capa de seguridad, un servicio de recuperación de información, un sistema de autenticación o una integración regional están afectados.

La divulgación realizada por OpenAI el 17 de septiembre de 2026 de seis informes relacionados con un comportamiento «inesperado o preocupante» de los modelos refuerza esta distinción. Estos informes respaldan la necesidad de supervisar los incidentes relacionados con el comportamiento de los modelos, además de las interrupciones completas del servicio. Por tanto, una organización puede enfrentarse a varias formas de interrupción:

• Falta de disponibilidad del proveedor: No se puede acceder al servicio externo del modelo o este no puede procesar solicitudes de forma fiable.
• Fallo de la aplicación: El modelo sigue disponible, pero fallan la aplicación empresarial, la integración, la capa de identidad o la conexión de datos.
• Degradación del comportamiento: El modelo responde, pero sus resultados ya no cumplen los requisitos de seguridad, calidad o previsibilidad del flujo de trabajo.
• Interrupción de seguridad: Las capacidades o integraciones del modelo contribuyen a un incidente de seguridad operativa.
• Fallo de los controles: El registro, el filtrado, la revisión, el escalamiento u otras salvaguardias dejan de funcionar aunque el servicio principal parezca operativo.

Esta definición ampliada es importante para la gobernanza. Un equipo que solo supervise la disponibilidad del punto de acceso puede pasar por alto un incidente en el que los resultados dejan de ser aptos para su uso. Por otra parte, una empresa no debería calificar cada respuesta inexacta como una interrupción sistémica. Necesita umbrales documentados que distingan un defecto habitual de calidad de un incidente grave de servicio, seguridad o protección.

La continuidad de la IA no consiste simplemente en poder enviar otra instrucción. Consiste en mantener un resultado empresarial esencial dentro de unos límites operativos y de seguridad aceptables cuando el modelo preferido o sus controles no están disponibles.

Este principio conduce a un enfoque de diseño más fundamentado. Las organizaciones deberían mapear toda la cadena del servicio, determinar qué dependencias pueden detener el flujo de trabajo y decidir de antemano si la respuesta segura consiste en cambiar de proveedor, reducir la funcionalidad, volver a un proceso manual, poner el trabajo en cola o suspender la actividad.

La UE está pasando de la seguridad de los modelos a la resiliencia de los sistemas

El Plan de Acción sobre Ciberseguridad e IA de la Comisión Europea de julio de 2026 marca una clara evolución normativa. El plan afirma que su objetivo es ayudar a los Estados miembros, las empresas y las autoridades públicas a abordar los desafíos de ciberseguridad y resiliencia que plantean los modelos de IA más avanzados. Su enfoque sitúa los riesgos de los modelos de frontera dentro de una agenda más amplia de resiliencia digital, en lugar de tratarlos únicamente como cuestiones propias de los laboratorios de prueba de modelos.

La Comisión afirma que el plan complementa el Reglamento de IA, el Reglamento de Ciberresiliencia, la Directiva NIS2, el Reglamento de Resiliencia Operativa Digital y el Reglamento de Cibersolidaridad. Este conjunto normativo es significativo porque las organizaciones rara vez experimentan un incidente de IA como un «problema de IA» perfectamente aislado. Un mismo evento puede implicar la gestión de proveedores, la seguridad del software, la continuidad del servicio, operaciones críticas, la notificación reglamentaria y la coordinación con las autoridades públicas.

Qué significa en la práctica este conjunto normativo

Las empresas deberían resistir la tentación de crear un programa de gobernanza de la IA que funcione por separado de la ciberseguridad y la continuidad de negocio. La asignación separada de responsabilidades puede generar evaluaciones duplicadas, clasificaciones de incidentes contradictorias y brechas entre la supervisión de los modelos y la respuesta operativa.

Una estructura más resiliente conecta las disciplinas pertinentes:

• La gobernanza de la IA identifica los casos de uso, las limitaciones de los modelos, los usos prohibidos, las condiciones de aprobación y los requisitos de supervisión humana.
• La ciberseguridad examina el acceso, las integraciones, la exposición de datos, el uso malicioso, las dependencias de software y la detección de amenazas.
• Los equipos de resiliencia operativa evalúan la criticidad de los servicios, los objetivos de recuperación, los procesos alternativos, el riesgo de concentración y las comunicaciones de crisis.
• Los equipos de compras y asuntos jurídicos examinan los compromisos de los proveedores, la información de auditoría, el tratamiento de datos, los avisos de incidentes, los subcontratistas y las opciones de salida.
• Los responsables de negocio determinan si un flujo de trabajo degradado o manual aún puede ofrecer un resultado aceptable.

El enfoque de la UE también destaca la diferencia entre la resiliencia de un modelo y la resiliencia de una organización que utiliza ese modelo. Un proveedor puede mejorar las salvaguardias del modelo, la respuesta a incidentes y la redundancia de la infraestructura. El cliente aún debe decidir cómo funcionará su propio servicio si el proveedor no está disponible o si el acceso debe suspenderse debido a un problema de seguridad o de comportamiento.

Este problema de responsabilidad compartida se acentúa con los modelos de frontera. Es posible que el cliente no tenga visibilidad sobre la infraestructura subyacente del proveedor, el proceso de entrenamiento, las evaluaciones internas o la respuesta ante una capacidad recién descubierta. Mientras tanto, el proveedor puede desconocer cómo ha integrado un cliente el modelo en un flujo de trabajo crítico. Los controles de resiliencia deben tener en cuenta esta brecha de información en lugar de asumir que una sola parte puede gestionar todo el riesgo.

La seguridad y la continuidad están convergiendo

Los debates tradicionales sobre la seguridad de la IA suelen hacer hincapié en las capacidades perjudiciales, el uso indebido, la pérdida de control o los resultados inseguros. La planificación ante interrupciones se centra en la disponibilidad, la recuperación y la continuidad. La orientación normativa de 2026 muestra por qué estas preocupaciones se solapan cada vez más.

Puede ser necesario restringir o desconectar un modelo después de un incidente de seguridad o protección. Un modelo alternativo puede comportarse de forma distinta al sistema principal. Los cambios de emergencia pueden debilitar los controles de revisión o crear nuevos riesgos relacionados con el tratamiento de datos. Por tanto, un plan de continuidad que restablezca los resultados sin restablecer las salvaguardias está incompleto.

El estándar práctico debería ser una continuidad segura, no la continuidad a cualquier precio. Si un caso de uso no puede funcionar dentro de los límites aprobados durante una degradación, la suspensión puede ser más apropiada que una alternativa sin control.

El calendario del Reglamento de IA crea un periodo para planificar la resiliencia

La mayoría de las normas del Reglamento de IA de la UE comenzaron a aplicarse el 2 de agosto de 2026. El paquete de simplificación de la UE mantuvo fechas de aplicación aplazadas para las normas de alto riesgo: el 2 de diciembre de 2027 y el 2 de agosto de 2028. Estas fechas proporcionan a las empresas afectadas más tiempo para crear controles de resiliencia, pero no deberían interpretarse como un motivo para posponer las tareas básicas de continuidad.

La implementación requiere tiempo porque el trabajo necesario va más allá de redactar una política. Una organización puede necesitar inventariar sus sistemas de IA, clasificar su impacto empresarial, renegociar las condiciones de los proveedores, mejorar los registros, definir umbrales de incidentes, crear vías alternativas, formar a los empleados y realizar simulacros operativos. Las dependencias ocultas dentro de productos de software pueden dificultar especialmente ese inventario.

Una secuencia práctica de preparación

1. Identificar los servicios respaldados por IA. Documentar tanto las integraciones directas de modelos como las funciones de IA suministradas mediante software empresarial. Registrar el proveedor, el modelo, las conexiones de datos, el responsable de negocio, los usuarios y los clientes u operaciones afectados.
2. Evaluar la criticidad. Determinar el efecto operativo de perder el componente de IA durante minutos, horas o más tiempo. Considerar si el flujo de trabajo afecta a la salud, la seguridad, el acceso financiero, las infraestructuras, los derechos legales u otros resultados importantes.
3. Mapear los requisitos aplicables. Determinar si el sistema puede estar sujeto a un examen de alto riesgo e identificar otras obligaciones pertinentes de resiliencia, ciberseguridad o específicas del sector. Las conclusiones jurídicas deberían basarse en el uso y el contexto reales, no únicamente en la etiqueta comercial de un proveedor.
4. Definir las condiciones de fallo. Incluir la falta de disponibilidad, las respuestas lentas, los resultados inutilizables, los fallos de los controles de seguridad, las credenciales comprometidas, los problemas de conexión de datos y las restricciones impuestas por el proveedor.
5. Diseñar modos alternativos. Seleccionar procedimientos manuales, procesamiento aplazado, funcionalidad reducida o servicios técnicos alternativos de acuerdo con el riesgo de la actividad.
6. Probar y documentar. Realizar simulacros, conservar pruebas, asignar autoridad para la toma de decisiones y registrar las medidas correctivas derivadas de cada prueba o incidente real.

Esta secuencia también ayuda a separar las afirmaciones de cumplimiento de las pruebas operativas. Una declaración escrita de que un servicio dispone de una copia de respaldo ofrece pocas garantías, salvo que dicha alternativa se haya probado con datos representativos, una demanda realista, controles de seguridad aprobados y personal capacitado.

Las fechas aplazadas para los sistemas de alto riesgo pueden aprovecharse para generar deliberadamente esas pruebas. Las empresas pueden comenzar por sus usos más importantes, probar un flujo de trabajo integral y después extender el patrón de control a otros sistemas. Este enfoque es más creíble que intentar crear una política amplia poco antes de una fecha límite de aplicación sin verificar si los equipos pueden ejecutarla.

Las funciones críticas reciben mayor atención

El servicio de asistencia del Reglamento de IA identifica la supervisión de la red eléctrica, la prevención de interrupciones y otras funciones críticas como ejemplos en los que los sistemas de IA pueden estar sujetos a un examen de alto riesgo. Las orientaciones de la UE sobre resiliencia publicadas en 2026 también señalan que las entidades críticas que utilizan IA en sus medidas de resiliencia deben recordar que los sistemas de IA de alto riesgo tienen que cumplir los requisitos de seguridad del Reglamento de IA.

Esto crea un principio de control importante: la IA introducida para mejorar la resiliencia puede convertirse a su vez en una dependencia para dicha resiliencia. Un modelo utilizado para detectar anomalías, priorizar el mantenimiento o prevenir una interrupción puede aportar valor operativo, pero los operadores aún deben prepararse para resultados incorrectos, respuestas tardías, pérdida de acceso y cambios en el comportamiento del modelo.

Para las funciones críticas, una degradación gradual suele ser más creíble que una sustitución instantánea. Un modo de funcionamiento menos automatizado y con una autoridad humana claramente definida puede ser más seguro que cambiar automáticamente a un modelo cuyo rendimiento, integraciones o limitaciones difieran de los del sistema principal.

Los reguladores financieros se centran en la concentración de modelos de frontera y el riesgo de las TIC

El 7 de julio de 2026, la Junta Europea de Riesgo Sistémico advirtió que los modelos de IA de frontera están cambiando el panorama de las ciberamenazas para el sistema financiero de la UE. La JERS pidió una mitigación coordinada entre proveedores, empresas de software, equipos de seguridad y autoridades. El énfasis en la coordinación refleja cómo el riesgo de los modelos puede atravesar los límites de las organizaciones.

La Autoridad Bancaria Europea, la Autoridad Europea de Seguros y Pensiones de Jubilación y la Autoridad Europea de Valores y Mercados también han pedido una gobernanza reforzada y una supervisión coherente para reducir los riesgos relacionados con las tecnologías de la información y las comunicaciones derivados de los modelos de IA de frontera en el sector financiero de la UE.

Por qué es importante la coordinación

Una institución financiera puede gestionar los controles de sus propias aplicaciones sin controlar el modelo de frontera subyacente. Un proveedor de software puede integrar el mismo modelo en productos utilizados por muchas instituciones. Los equipos de seguridad pueden observar actividades sospechosas, mientras que los supervisores pueden detectar patrones más amplios que ninguna empresa podría identificar únicamente a partir de sus propios incidentes.

Esta estructura plantea varias preguntas operativas que las empresas reguladas deberían estar preparadas para responder:

• ¿Qué servicios importantes dependen directa o indirectamente del mismo proveedor de modelos?
• ¿Podrían dos proveedores aparentemente independientes depender de un mismo modelo o una misma capa de infraestructura subyacentes?
• ¿Qué información recibiría la institución si un proveedor observara un comportamiento preocupante del modelo?
• ¿Puede la institución desactivar una función de IA sin desactivar toda la aplicación empresarial?
• ¿Quién puede autorizar el cambio al procesamiento manual o a un modo de servicio restringido?
• ¿Cómo conservará la empresa los registros necesarios para la revisión interna, la interacción con los supervisores o la notificación de incidentes?

Estas preguntas no quedan respondidas por una afirmación genérica de que un proveedor dispone de centros de datos redundantes. La redundancia de infraestructura puede ayudar ante determinadas interrupciones técnicas, pero no aborda necesariamente la concentración en un modelo común, las restricciones de seguridad, los incidentes de comportamiento, los defectos del software o la retirada de emergencia de una capacidad.

El diseño multimodelo es útil, pero no proporciona resiliencia automáticamente

La cobertura del sector a principios de septiembre de 2026 recomendó estrategias multimodelo como una respuesta a las grandes interrupciones de la IA. Este enfoque puede reducir la dependencia de un solo servicio, pero únicamente cuando las alternativas son suficientemente independientes y están preparadas para funcionar.

Dos interfaces de modelos pueden depender, en última instancia, del mismo componente en la nube, mecanismo de autenticación, almacén de datos, capa de orquestación o proveedor de software. Incluso los modelos realmente independientes pueden tener requisitos diferentes para las instrucciones, formatos de salida, límites de contexto, comportamientos de seguridad y características de integración. Un cambio que funcione desde el punto de vista técnico puede seguir produciendo un resultado empresarial inaceptable.

Antes de considerar un modelo secundario como alternativa, los equipos deberían validar su uso para la tarea específica. Deberían comprobar el tratamiento de los resultados, los controles de acceso, las condiciones de privacidad, los registros, la revisión humana y las condiciones en las que puede redirigirse el tráfico. Si esos controles no pueden mantenerse, un modo manual o de funcionalidad reducida puede ser una opción de continuidad más segura.

La notificación de incidentes se está convirtiendo en un control esencial de resiliencia

El Reglamento de IA de la UE exige prestar atención a los incidentes graves relacionados con modelos de IA de uso general que presenten un riesgo sistémico. Si un modelo de este tipo causa un incidente grave, el proveedor debería realizar un seguimiento y notificar sin demora indebida la información pertinente y las medidas correctivas. Esto convierte la gestión de incidentes en algo más que una práctica interna de fiabilidad.

La notificación eficaz depende de la detección. Un proveedor no puede hacer un seguimiento de un incidente grave que nunca se reconoce y un cliente no puede escalar un problema si los empleados no tienen forma de distinguir un acontecimiento grave de la variabilidad habitual del modelo. Por tanto, la supervisión debe conectar las señales técnicas, los informes de los usuarios, las alertas de seguridad y el impacto empresarial.

Crear un único rastro de pruebas desde la detección hasta la corrección

Un registro sólido de incidentes debería ayudar a los revisores a entender lo ocurrido sin exagerar el grado de certeza. El registro puede incluir el modelo o servicio afectado, el comportamiento observado, el momento, el flujo de trabajo afectado, los registros disponibles, la contención inmediata, el efecto empresarial, las notificaciones y las medidas correctivas. Cuando se desconozca la causa, el registro debería indicarlo en lugar de sustituir la incertidumbre por suposiciones.

Las organizaciones pueden estructurar su respuesta en torno a las siguientes etapas:

1. Detectar: Capturar errores del servicio, patrones de resultados inusuales, fallos de los controles, inquietudes de los usuarios, señales de seguridad y avisos de los proveedores.
2. Clasificar: Evaluar la gravedad, el alcance, las decisiones afectadas, la exposición de datos, las implicaciones para la seguridad y si el sistema debería seguir disponible.
3. Contener: Restringir funciones, revocar el acceso, aislar integraciones, cambiar a una alternativa aprobada o suspender el flujo de trabajo.
4. Escalar: Notificar a los responsables de negocio, seguridad, asuntos jurídicos, cumplimiento normativo, comunicaciones y dirección ejecutiva de acuerdo con los umbrales documentados.
5. Conservar: Retener las instrucciones, los resultados, los eventos del sistema, los detalles de configuración y los registros de decisiones pertinentes, de acuerdo con los requisitos de tratamiento aplicables.
6. Corregir: Implementar cambios técnicos, procedimentales, contractuales o de gobernanza y verificar que funcionen.
7. Aprender: Actualizar los escenarios, la formación, los umbrales, las evaluaciones de los proveedores y los planes de continuidad.

La divulgación de OpenAI de seis informes sobre comportamientos preocupantes el 17 de septiembre de 2026 demuestra por qué son importantes los canales para informar sobre comportamientos inesperados de los modelos. No establece que cada comportamiento notificado constituyera una interrupción ni elimina la necesidad de evaluar cada evento en su contexto. Sí demuestra que los programas de gestión de incidentes deben ser capaces de recibir y evaluar inquietudes sobre el comportamiento, no solo alarmas de infraestructura.

La notificación de proveedores y clientes debe estar conectada

Los clientes empresariales deberían saber cómo informar a un proveedor sobre un posible incidente relacionado con un modelo y qué información puede proporcionarles dicho proveedor. Los contratos y procedimientos operativos pueden abordar las vías de notificación, los contactos de escalamiento, la conservación de pruebas, la información sobre el estado del servicio y la cooperación después de un incidente grave.

Los clientes también necesitan una vía interna de notificación que permanezca disponible cuando el servicio de IA no funcione. Si los empleados suelen enviar solicitudes de asistencia a través de una herramienta con IA que depende del proveedor afectado, el proceso de notificación puede fallar justo cuando más se necesita. Los canales independientes de comunicación y gestión de incidentes reducen esta dependencia circular.

Los cambios bruscos de capacidad conectan la seguridad de la IA con la seguridad operativa

Las normas sobre interrupciones están surgiendo junto con la preocupación por el rápido avance de las capacidades de los modelos. Axios informó el 18 de agosto de 2026 de que OpenAI estaba reescribiendo su Marco de Preparación porque los modelos se acercaban a los umbrales previstos en el documento creado en la época de 2023. Un marco diseñado sobre la base de expectativas anteriores puede necesitar una revisión a medida que las capacidades se aproximan a sus desencadenantes originales.

Axios también informó a finales de julio de 2026 de que varios modelos de OpenAI estaban relacionados con otro ataque informático que implicaba a una empresa externa. El episodio ilustra cómo los cambios de capacidad pueden contribuir a incidentes de seguridad fuera de un entorno de laboratorio controlado. Para los equipos empresariales de resiliencia, la lección es no asumir que el riesgo de los modelos permanece confinado al entorno de evaluación del proveedor.

La preparación debe cubrir los cambios repentinos

Las organizaciones suelen gestionar el software mediante ciclos de lanzamiento planificados. La IA de frontera puede complicar este patrón cuando los proveedores actualizan modelos, revisan salvaguardias, retiran versiones, introducen funciones agénticas o descubren una capacidad que cambia la evaluación de las amenazas. El flujo de trabajo del cliente puede verse afectado aunque el código de su propia aplicación no cambie.

Un proceso práctico de gestión de cambios debería considerar:

• si una actualización del modelo modifica el uso aprobado, la clasificación del riesgo o el nivel necesario de supervisión humana;
• si las nuevas capacidades de uso de herramientas o de agentes modifican el acceso a datos, software o sistemas externos;
• si la retirada de una versión del modelo obliga a realizar una migración acelerada;
• si un comportamiento recién observado requiere restricciones temporales;
• si la supervisión de seguridad sigue siendo adecuada después de un cambio de capacidad; y
• si los modelos alternativos crean riesgos sustancialmente diferentes.

En este punto convergen la gobernanza de la seguridad y la ciberresiliencia. Un modelo más potente puede mejorar la detección, el análisis y la respuesta, pero esa misma capacidad puede modificar el potencial de uso indebido o ampliar las consecuencias de unos permisos excesivos. Por tanto, la planificación de la resiliencia debería incluir la posibilidad de que una organización desactive voluntariamente una función de IA operativa porque el riesgo ha cambiado.

Un servicio puede estar disponible desde el punto de vista técnico y, aun así, no estarlo desde el punto de vista operativo si no puede utilizarse dentro de los límites aprobados de seguridad, protección o gobernanza.

Esta distinción ayuda a los directivos a tomar mejores decisiones de suspensión. Los equipos no deberían sentirse obligados a seguir utilizando un modelo únicamente porque el punto de acceso responde. Si la supervisión, las salvaguardias o las garantías ya no respaldan el caso de uso, la retirada controlada constituye una medida legítima de resiliencia.

Las propuestas de Estados Unidos muestran un apoyo creciente a salvaguardias vinculantes para la IA de frontera

Las normas europeas están actualmente más desarrolladas como estructura reguladora transversal, pero Estados Unidos también está considerando requisitos más estrictos. La cobertura de Reuters de septiembre de 2026 señaló que OpenAI instó a Estados Unidos a adoptar normas nacionales obligatorias de seguridad de la IA basadas en las capacidades después de que varios agentes experimentales se comportaran de forma impredecible durante las pruebas.

La cobertura de Reuters de los días 11 y 14 de septiembre de 2026 también indicó que los negociadores del Senado estaban considerando exigir a las empresas de IA que mitigaran los principales riesgos conocidos y se comprometieran a prevenir catástrofes. Estos debates deberían describirse con precisión como propuestas y negociaciones, no como obligaciones ya promulgadas.

Las normas basadas en las capacidades podrían afectar a la planificación operativa

Un enfoque basado en las capacidades centra la atención en lo que un sistema puede hacer, en lugar de basarse únicamente en su marca, familia de modelos o finalidad declarada. Desde el punto de vista de la resiliencia, esto podría hacer importante una nueva evaluación cuando un modelo actualizado cruce un umbral de capacidad relevante u obtenga acceso a nuevas herramientas.

Las organizaciones que utilizan sistemas de frontera no tienen que esperar a que se definan todos los detalles normativos para mejorar sus controles. Muchas medidas útiles son independientes de la regulación: mantener un inventario, limitar los permisos, probar los procedimientos alternativos, registrar los incidentes, supervisar los cambios de los proveedores y asignar responsables para la toma de decisiones.

Al mismo tiempo, las empresas deberían evitar presentar las prácticas voluntarias como prueba del cumplimiento de normas que aún se están debatiendo. Una gobernanza fiable distingue entre la legislación vinculante, las orientaciones regulatorias, los marcos de los proveedores, las propuestas legislativas y las políticas internas. Todos estos elementos pueden influir en la gestión del riesgo, pero no tienen la misma condición jurídica.

Se observa una orientación transatlántica pese a las diferencias jurídicas

Los avances de la UE y el debate estadounidense comparten una preocupación práctica: los modelos de gran capacidad pueden generar consecuencias que van más allá de un único usuario o aplicación. Ambos debates hacen cada vez más hincapié en los principales riesgos conocidos, la respuesta a incidentes, la gobernanza y la preparación ante consecuencias graves.

Para las organizaciones multinacionales, una base operativa común puede ser más manejable que unos planes regionales desconectados. Esa base puede respaldar requisitos locales más estrictos sin afirmar que las leyes son idénticas. Puede incluir un inventario centralizado de modelos, una revisión jurídica local, la coordinación global de incidentes, modos alternativos probados y una autoridad clara para restringir un sistema.

Cómo pueden las empresas crear ahora un programa de continuidad de la IA

Un programa creíble de continuidad de la IA comienza por los resultados empresariales, no por los nombres de los proveedores. La primera pregunta es qué servicio debe continuar, en qué nivel y bajo qué restricciones de seguridad. Solo entonces debería decidir la organización si son apropiados la redundancia, el procesamiento manual, el aplazamiento del trabajo o la suspensión.

Priorizar según las consecuencias

No todos los casos de uso necesitan una redundancia técnica costosa. Un asistente de redacción para material interno no urgente puede tolerar una interrupción prolongada. Un componente de IA que intervenga en una decisión operativa crítica puede requerir una detección rápida, una autoridad humana documentada y un modo degradado probado.

La priorización debería considerar tanto el daño causado por la ausencia como el provocado por una respuesta incorrecta o insegura. Esto evita un error común: optimizar la disponibilidad para un flujo de trabajo en el que una sustitución sin control sería más peligrosa que esperar.

Establecer condiciones alternativas explícitas

Las decisiones sobre alternativas no deberían depender por completo de la improvisación durante un incidente. Los equipos pueden definir desencadenantes para cambiar de proveedor, recurrir a la revisión manual, reducir la automatización, poner solicitudes en cola o suspender por completo el servicio. Entre los desencadenantes pueden figurar una falta de disponibilidad prolongada, el fallo de un control de seguridad, un aviso de seguridad, una degradación inexplicable de los resultados o la pérdida de los registros obligatorios.

Para cada modo, se debe documentar quién puede activarlo, cómo se informa a los usuarios, qué datos pueden procesarse, qué aprobaciones siguen siendo necesarias y cómo se restablece el servicio normal. Una alternativa también debería tener una condición de salida; los procesos temporales de emergencia pueden crear riesgos duraderos si permanecen activos sin revisión.

Probar escenarios realistas

Los simulacros deberían abarcar algo más que una interrupción clara anunciada en una página pública de estado. Los incidentes reales pueden ser ambiguos. Las respuestas pueden ser lentas en lugar de estar ausentes, puede fallar solo una función o los usuarios pueden informar de un comportamiento preocupante antes de que el proveedor confirme el problema.

• Simular la pérdida del modelo principal durante un periodo de máxima actividad empresarial.
• Comprobar si el servicio alternativo puede gestionar la tarea requerida y los datos aprobados.
• Practicar el funcionamiento sin IA conservando los registros y las aprobaciones esenciales.
• Simular un escenario en el que el modelo funcione, pero falle un control de seguridad o de registro.
• Realizar un simulacro de un aviso de seguridad del proveedor que exija restringir inmediatamente una función.
• Verificar que las comunicaciones con clientes, empleados, reguladores y directivos puedan continuar sin la herramienta de IA afectada.

Los simulacros deberían generar medidas correctivas, responsables y pruebas de finalización. Una prueba que revela una debilidad es útil; una prueba cuyos hallazgos nunca reciben seguimiento solo crea una apariencia de preparación.

Exigir a los proveedores información útil para la toma de decisiones

Las evaluaciones de compras deberían centrarse en información que respalde las decisiones de continuidad. Entre los temas relevantes figuran las dependencias del servicio, los procesos de notificación de incidentes, las prácticas de cambio de modelos, la retirada de versiones, el acceso a información sobre el estado, la portabilidad de los datos, los registros, la cooperación en materia de seguridad y la asistencia para la rescisión.

Ningún contrato puede eliminar una interrupción grave de un proveedor ni un comportamiento inesperado de un modelo. Sin embargo, las disposiciones contractuales pueden aclarar la comunicación y las responsabilidades. También pueden revelar cuándo el cliente carece de la información o los derechos necesarios para utilizar de forma segura un sistema con consecuencias importantes.

Mantener a las personas preparadas para operaciones degradadas

Una alternativa manual solo existe si las personas conservan los conocimientos, el acceso, la capacidad y la autoridad necesarios para ejecutarla. A medida que los equipos automatizan más tareas, esas capacidades pueden debilitarse. La práctica periódica ayuda a determinar si el supuesto proceso manual sigue siendo viable.

La supervisión humana también debería ser específica. Decirle a un empleado que «revise el resultado» no basta para un flujo de trabajo con consecuencias importantes, salvo que el revisor sepa qué debe comprobar, cuente con los conocimientos necesarios, pueda acceder a la información justificativa y tenga autoridad para rechazar o detener el proceso.

Por último, los informes para la dirección deberían combinar la fiabilidad con el riesgo. Los informes útiles pueden describir las dependencias críticas de la IA, los puntos únicos de fallo sin resolver, los incidentes recientes, los resultados de los simulacros, las medidas correctivas pendientes y los próximos cambios de modelos o normativos. Esto proporciona a los directivos una base de inversión más clara que una única cifra de tiempo de actividad.

Las grandes interrupciones de la IA impulsan normas de resiliencia porque las consecuencias operativas se han hecho visibles. El plan de la UE sobre ciberseguridad e IA de julio de 2026, el calendario del Reglamento de IA, las orientaciones para entidades críticas, las advertencias del sector financiero y los requisitos relativos a incidentes graves apuntan hacia una supervisión integrada de los modelos, la ciberseguridad y la continuidad. Los debates en Estados Unidos sobre salvaguardias obligatorias basadas en las capacidades y la mitigación de riesgos catastróficos refuerzan el movimiento más amplio hacia una rendición de cuentas más formal, aunque esas propuestas no deberían confundirse con legislación ya promulgada.

Las organizaciones pueden responder sin exagerar ni la tecnología ni la regulación. Deberían identificar las dependencias importantes, definir modos degradados seguros, probar alternativas independientes, supervisar los incidentes de comportamiento y seguridad, conservar pruebas y conectar la gobernanza de la IA con las funciones de resiliencia existentes. El objetivo no es disponer de una IA ininterrumpida a cualquier precio, sino de un servicio empresarial fiable que pueda fallar de forma segura, recuperarse de manera controlada y demostrar qué se hizo antes, durante y después de un incidente.