La Inteligencia Artificial ya no está limitada a proyectos experimentales o laboratorios de innovación. En muchas organizaciones, empieza a intervenir directamente en procesos críticos: analiza solicitudes, prioriza alertas, clasifica operaciones, atiende clientes, recomienda decisiones y ejecuta tareas que antes dependían exclusivamente de personas.

El avance es evidente, pero también lo es la oportunidad y potenciales amenazas

Durante años, los planes de continuidad del negocio fueron diseñados para responder a escenarios conocidos: caída de servidores, indisponibilidad de oficinas, fallas de telecomunicaciones, ciberataques, pérdida de personal crítico o interrupciones de proveedores.

Esos escenarios siguen siendo válidos. Pero ya no alcanzan en un entorno de tecnologias emergentes. Cuando una organización incorpora modelos o agentes de Inteligencia Artificial en procesos sensibles, aparece un nuevo tipo de exposición: la posibilidad de que la tecnología continúe funcionando, pero deje de tomar decisiones confiables.

Y ese escenario puede ser más difícil de detectar que una caída tradicional.

La IA puede fallar sin dejar de funcionar

Cuando una aplicación se cae, el problema suele ser evidente. El sistema no responde, las transacciones se detienen y las alertas se activan.

Con la Inteligencia Artificial, el fallo puede ser mucho más silencioso. El modelo sigue operando. La plataforma permanece disponible. Las integraciones continúan activas. Sin embargo, los resultados empiezan a deteriorarse.

Puede ocurrir que la IA utilice información desactualizada, interprete mal una instrucción, aumente los falsos positivos, deje pasar alertas relevantes o empiece a clasificar incorrectamente operaciones y clientes.

Desde la perspectiva tecnológica, el servicio sigue en línea. Desde la perspectiva del negocio, el proceso ya se está degradando. Ese cambio es importante porque obliga a replantear la forma en que entendemos la continuidad. Ya no basta con preguntar si la tecnología está disponible. También hay que preguntarse si continúa siendo confiable.

El BIA necesita mirar más allá de aplicaciones e infraestructura

El Business Impact Analysis ha sido, durante años, uno de los pilares de la continuidad del negocio. Su función es identificar procesos críticos, dependencias, impactos y tiempos máximos tolerables de interrupción.

Sin embargo, en una organización que utiliza IA, el BIA debe incorporar nuevas preguntas.

-¿De qué modelos depende el proceso?

-¿Qué decisiones toma la Inteligencia Artificial?

-¿Qué datos necesita para operar?

-¿Qué nivel de autonomía tiene?

-¿Qué proveedores participan?

-¿Qué ocurre si el modelo deja de estar disponible?

-¿Y qué ocurre si sigue disponible, pero empieza a equivocarse?

Estas preguntas son necesarias porque la dependencia ya no es únicamente tecnológica. Ahora, también es decisional.

Recuperar la tecnología no siempre significa recuperar el servicio

Los objetivos tradicionales de recuperación, como el RTO y el RPO, siguen siendo indispensables. Pero en procesos soportados por IA, no explican toda la realidad. Puede restablecerse la infraestructura dentro del tiempo esperado y aun así persistir un problema relevante.

Por ejemplo, el modelo puede haber perdido precisión, estar utilizando datos incompletos o haber cambiado su comportamiento después de una actualización. En esos casos, la recuperación no termina cuando vuelve el sistema. Termina cuando la organización puede demostrar que las decisiones vuelven a ser confiables.

Por eso, además del tiempo de recuperación tecnológica, deberían evaluarse aspectos como:

• Cuánto tiempo puede operar el proceso con resultados degradados.
• Qué porcentaje de errores puede tolerarse.
• Cuántas decisiones requieren revisión manual.
• Cuánto demora la organización en cambiar a un proceso alternativo.
• Qué volumen puede atenderse durante la contingencia.
• Cuándo puede autorizarse el retorno a la operación normal.

Estas variables reflejan mejor el impacto real sobre el negocio.

La posibilidad de perder la capacidad manual

Uno de los efectos menos visibles de la automatización es la pérdida progresiva de conocimiento operativo. Cuando una tarea pasa a ser ejecutada por un modelo o un agente durante meses, el personal deja de practicarla. Los procedimientos manuales se desactualizan. Los accesos alternativos se eliminan. Las plantillas dejan de utilizarse. El conocimiento se concentra en pocas personas.

Todo parece eficiente hasta que la IA falla. En ese momento, la organización descubre que el proceso manual existía en el documento, pero no en la práctica. Por eso, una estrategia de continuidad no debería limitarse a señalar que “la operación continuará manualmente”. Esa afirmación necesita ser probada.

La organización debe saber quién puede ejecutar el proceso, con qué accesos, qué volumen puede absorber, qué actividades se priorizarán y cuánto tiempo puede sostenerse ese esquema.

También debe reconocer una realidad incómoda: la capacidad manual casi siempre será menor que la capacidad automatizada. La contingencia, por tanto, requiere priorización. No todo podrá mantenerse al mismo nivel.

La dependencia de terceros se vuelve más compleja

Buena parte de las soluciones de IA actuales dependen de proveedores externos, plataformas cloud, APIs, modelos fundacionales, servicios de datos y herramientas de automatización. Esto crea cadenas de dependencia difíciles de visualizar.

Una organización puede contratar a un proveedor y creer que comprende su exposición. Sin embargo, ese proveedor puede depender de otros servicios que la entidad no conoce ni controla directamente.

El riesgo no siempre aparece como una caída total. También puede manifestarse a través de cambios en el modelo, modificaciones en las condiciones del servicio, restricciones de acceso, degradación del desempeño o alteraciones en la forma en que se procesan los datos.

Por eso, la continuidad debe mirar más allá del proveedor principal. Debe entender toda la cadena, conocer las alternativas disponibles y definir qué ocurrirá si alguno de esos componentes deja de responder o cambia su comportamiento.

El Kill Switch debe existir, pero también debe funcionar

Toda solución crítica de IA debería contar con un mecanismo para limitar, suspender o aislar su operación. El concepto de Kill Switch suele asociarse a un botón de apagado. En la práctica, debería entenderse como un conjunto de medidas de contención.

Puede incluir la revocación de credenciales, el bloqueo de APIs, la reducción de autonomía, el paso a un modo de recomendación, la activación de revisión humana o la suspensión de determinadas operaciones.

Pero contar con ese mecanismo no es suficiente. La organización debe definir quién puede activarlo, bajo qué criterios, qué ocurre con las operaciones en curso y cómo se recupera el proceso después de la suspensión.

Un Kill Switch que nunca ha sido probado, es solo una promesa de control. No es un control. Es una estrategia.

Los ejercicios de continuidad también deben cambiar

Los simulacros tradicionales suelen enfocarse en caídas de infraestructura o indisponibilidad de instalaciones. En procesos con IA, los ejercicios deben incorporar escenarios diferentes.

Por ejemplo:

• El modelo deja de responder.
• La plataforma continúa disponible, pero genera resultados inconsistentes.
• Una fuente de datos deja de estar accesible.
• El proveedor cambia el comportamiento del modelo.
• Un agente ejecuta acciones fuera de su alcance.
• La revisión humana queda desbordada.
• Un error se propaga entre varios agentes o sistemas.

Estos ejercicios ayudan a evaluar algo que los planes tradicionales no siempre consideran: la capacidad de detectar que una solución sigue funcionando, pero ya no debería seguir operando.

Qué debería conocer el Comité de Riesgos

La incorporación de IA en procesos críticos no debería quedar únicamente en manos de Tecnología o Innovación.

El Comité de Riesgos necesita conocer, como mínimo:

• Qué procesos críticos dependen de IA.
• Qué nivel de autonomía tienen los modelos o agentes.
• Qué alternativas existen si fallan.
• Qué capacidad manual permanece disponible.
• Qué proveedores concentran la dependencia.
• Qué mecanismos de suspensión han sido probados.
• Qué incidentes o degradaciones se han registrado.
• Cuánto tiempo tomaría recuperar decisiones confiables.

La conversación no debe centrarse solo en eficiencia o innovación. También debe incluir continuidad, recuperabilidad y control.

Reflexión final

La Inteligencia Artificial está modificando silenciosamente la arquitectura de operación de muchas organizaciones. Los procesos ya no dependen únicamente de personas, sistemas y proveedores. También dependen de decisiones generadas por modelos que pueden fallar sin dejar de funcionar.

Por eso, la continuidad del negocio necesita evolucionar. No basta con recuperar servidores, aplicaciones o conectividad. También es necesario recuperar la capacidad de tomar decisiones correctas, confiables y controladas.

La pregunta ya no debería ser solamente: ¿Cuánto tiempo tardamos en restablecer la tecnología?

También debería ser: ¿Cuánto tiempo tardamos en recuperar la confianza en las decisiones que esa tecnología produce?

Una organización resiliente no es aquella cuya Inteligencia Artificial nunca falla. Es aquella que puede seguir operando cuando falla, se degrada o debe ser desconectada.

---

En ALGERisk Corporation acompañamos a las organizaciones en la actualización de su BIA, sus planes de continuidad, sus escenarios de prueba y sus estrategias de resiliencia operacional para procesos soportados por Inteligencia Artificial.