La trampa de fragilidad de la IA: más predicción no equivale a más resiliencia

La idea de que gastar más en IA vuelve automáticamente a una empresa más resiliente es, a estas alturas de 2026, una fantasía cara. Funciona bien en la diapositiva del consejo. Funciona peor cuando falla un proveedor cloud, cuando un proceso aguas arriba sigue siendo manual, cuando el dato está contaminado o cuando media organización toma decisiones asistidas por modelos que nadie gobierna de verdad.

La pieza de Reuters publicada el 18 de agosto de 2026 recoge una intuición que muchos CISOs, responsables de riesgo operativo y equipos de compliance ya venían mascando: la IA mejora métricas locales, pero no convierte por sí sola a una organización en una máquina más adaptable. Puede afinar previsiones de demanda, acelerar atención al cliente o reducir tiempos de análisis. Perfecto. El problema aparece cuando esa mejora se queda encerrada en un silo y, peor todavía, crea nuevas dependencias técnicas, energéticas, contractuales y de gobernanza.

Aquí está el quid: una empresa puede predecir mejor y, al mismo tiempo, volverse más frágil. No es una contradicción. Es exactamente lo que ocurre cuando se optimiza una capa sin rediseñar el sistema completo. En sectores regulados, especialmente banca, seguros, pagos, mercados e infraestructuras críticas, esa brecha no es filosófica. Tiene traducción jurídica, supervisora y, si la cosa se tuerce, sancionadora.

La tesis merece más que un resumen amable. Merece desmontar una confusión muy extendida en comités ejecutivos: confundir eficiencia algorítmica con resiliencia operativa.

Tesis editorial

Invertir en IA sin rediseñar procesos, dependencias y gobierno corporativo no aumenta la resiliencia: la desplaza, la maquilla o directamente la erosiona. Y cuanto más regulada está una empresa, más peligrosa resulta esa confusión.

La razón es sencilla. La resiliencia no consiste en hacer una tarea concreta más rápido cuando todo va bien. Consiste en mantener funciones críticas dentro de niveles aceptables cuando algo falla, adaptarse a condiciones cambiantes y recuperarse con tiempos y tolerancias definidos. DORA lo formula para el sector financiero europeo como capacidad para resistir, responder y recuperarse de incidentes relacionados con las TIC, preservando la continuidad y la calidad de los servicios financieros. NIS2 exige medidas para gestionar riesgos que afectan a redes y sistemas de información. NIST CSF 2.0 gira sobre gobernar, identificar, proteger, detectar, responder y recuperar. Ninguno de estos marcos dice: “compre un modelo y cruce los dedos”.

El error corporativo de 2026 no es adoptar IA. El error es adoptarla como si fuera un software aislado y no una palanca que altera la topología del riesgo. Cambia flujos de decisión. Cambia terceros críticos. Cambia perfiles de acceso. Cambia consumo energético. Cambia exposición a errores sistémicos. Cambia la velocidad del negocio y, con ella, la velocidad a la que un fallo se propaga.

Quien siga midiendo el éxito solo con productividad, precisión o coste por transacción está mirando la mitad amable del problema. La mitad desagradable es otra: concentración en hyperscalers, opacidad de modelos, dependencia de datos de calidad discutible, automatización de decisiones mal controladas, acoplamientos entre áreas que antes podían fallar por separado y ahora fallan en cadena.

Ese patrón tiene un nombre útil: trampa de fragilidad. Y no hace falta exagerarlo para verlo. Basta con mirar cómo se están cruzando IA, cloud, ciberseguridad y regulación este año.

No faltan modelos; falta arquitectura organizativa

La observación central del artículo de Reuters es correcta y bastante más seria de lo que parece. Muchas compañías consiguen previsiones más finas o equipos más productivos, pero la mejora no viaja por la cadena de valor. Un área comercial ve mejor la demanda; compras mantiene sus ciclos; logística sigue con cuellos de botella; proveedores externos no comparten la misma velocidad; los incentivos continúan desalineados. Resultado: el dashboard sube, la resiliencia no.

Eso ocurre porque la resiliencia es una propiedad de sistema, no de herramienta. Una función concreta puede volverse brillante mientras el proceso de extremo a extremo sigue siendo rígido. En banca pasa con modelos que mejoran scoring o detección de fraude, mientras onboarding, revisión manual, escalado a segunda línea o remediación de alertas siguen dependiendo de procesos lentos o de datos mal integrados. En seguros ocurre cuando la IA acelera triaje de siniestros, pero peritación, validación documental o interacción con talleres y redes médicas siguen ancladas en cadenas operativas fragmentadas. En retail, la previsión mejora, pero el proveedor sigue entregando como en 2023.

Ese desacople tiene consecuencias operativas muy concretas:

Primero, crea una ilusión de control. Si una predicción es más precisa, la dirección asume que el sistema completo es más robusto. No siempre. Ver antes no sirve de mucho si no puedes mover recursos, cambiar rutas o reconfigurar decisiones.

Segundo, reduce holguras. La IA suele empujar hacia eficiencia: menos stock, menos tiempo muerto, menos revisión humana, menos capacidad ociosa. Magnífico hasta que llega la excepción. La resiliencia necesita ciertas reservas: redundancia, fallback, tolerancias, capacidad de degradación elegante. La optimización extrema tiende a odiar todo eso.

Tercero, acelera el daño cuando hay un error. Una mala regla manual afecta a un subconjunto limitado. Un modelo desplegado en varios canales, integrado con automatización, puede amplificar sesgos, errores de clasificación o decisiones defectuosas en minutos.

Cuarto, cambia el mapa de terceros críticos. Una empresa que antes dependía de un ERP y un proveedor de comunicaciones ahora depende, además, de APIs de modelos, servicios gestionados, capas de observabilidad, pipelines de datos y quizá un puñado de proveedores estadounidenses con concentración de mercado más que evidente.

Quien no traduzca esos cambios a riesgo operativo, procurement, controles de seguridad y cláusulas contractuales está comprando velocidad a costa de estabilidad.

La nueva concentración: cloud, modelos y soberanía práctica

Una de las partes más interesantes de la pieza de Reuters es que no se queda en la productividad y entra en la dependencia de un número reducido de proveedores cloud y modelos de IA. Ahí sí hay noticia de fondo. Durante años, la concentración en hyperscalers ya era una preocupación supervisora en Europa. La IA no la corrige; la profundiza.

En servicios financieros, DORA dedica todo su Capítulo V a la gestión del riesgo de terceros proveedores de servicios TIC. El artículo 28 obliga a establecer un marco sólido para gestionar ese riesgo. El artículo 30 fija elementos contractuales clave. El artículo 31 prevé un marco de supervisión para terceros críticos de TIC a nivel de la UE. Y el artículo 28.3 deja claro que la responsabilidad última sigue siendo de la entidad financiera. Traducido al castellano no regulatorio: aunque el proveedor sea enorme, brillante y tenga un logo muy tranquilizador, el supervisor irá a por ti si no has gobernado la dependencia.

La IA complica esto por tres razones. La primera es técnica: muchos casos de uso dependen de servicios de inferencia o entrenamiento alojados sobre infraestructuras ajenas y conectados a otros componentes también ajenos. La segunda es contractual: los contratos cloud ya eran complejos; los términos sobre uso de datos, mejora del servicio, subprocesadores, localización, logging o límites de responsabilidad en IA pueden ser aún más resbaladizos. La tercera es estratégica: cuando una función crítica se diseña alrededor de un modelo o stack concreto, la salida deja de ser teórica y pasa a ser dolorosamente cara.

Tu entidad puede tener estrategia de exit cloud sobre el papel y seguir atrapada en la práctica. DORA no exige magia; exige realismo. Si una capacidad crítica depende de un proveedor externo, la entidad debe tener identificado ese riesgo, controles de monitorización, derechos de auditoría cuando proceda, pruebas, planes de contingencia y una estrategia de salida plausible. Plausible, no decorativa.

El asunto además conecta con NIS2. El artículo 21 obliga a adoptar medidas técnicas, operativas y organizativas adecuadas y proporcionadas, incluidas seguridad de la cadena de suministro, gestión de incidentes, continuidad de negocio, copias de seguridad y gestión de crisis. Si la cadena de suministro digital ahora incluye modelos externos, servicios MLOps, etiquetado de datos o proveedores de observabilidad, esa cadena también entra en el perímetro de diligencia. A estas alturas, seguir tratando la IA como una simple aplicación es una forma eficiente de incumplir el espíritu de NIS2 sin darse cuenta hasta la auditoría o el incidente.

Y luego está la soberanía práctica. No la retórica. La práctica consiste en responder preguntas incómodas: ¿en qué jurisdicción se procesan prompts, embeddings, logs o datasets? ¿Quién puede acceder? ¿Qué subprocesadores intervienen? ¿Existe segregación real entre cliente y proveedor? ¿Qué ocurre si cambian las condiciones del servicio o se restringe una funcionalidad crítica? ¿Se puede migrar un flujo de decisión sin rediseñar media operación? Muchas organizaciones siguen sin poder contestar con precisión. Eso no es innovación; es dependencia mal inventariada.

Impacto regulatorio cruzado

Si la adopción de IA está reconfigurando la resiliencia, no basta con mirar una única norma. El riesgo real aparece en la intersección. Ahí es donde suelen pinchar los proyectos bonitos.

DORA: resiliencia, terceros y pruebas

DORA es la referencia inmediata para entidades financieras de la UE desde su aplicación el 17 de enero de 2025. No regula la IA como tecnología autónoma, pero sí regula el entorno en el que la IA vive: gobernanza del riesgo TIC, gestión de incidentes, pruebas de resiliencia, terceros proveedores y continuidad operativa.

Dos puntos importan especialmente. Uno: el artículo 6 exige un marco interno de gestión del riesgo TIC sólido, integral y debidamente documentado. Si la IA modifica procesos críticos, esos cambios deben reflejarse en inventarios, apetito de riesgo, controles, roles y escalados. Dos: los artículos 24 a 27 sobre pruebas de resiliencia digital obligan a un programa de testing proporcional a tamaño, perfil de riesgo y criticidad. Si un modelo soporta una función importante, probar solo el modelo por precisión no basta. Hay que probar la dependencia completa: datos de entrada, fallback, degradación, intervención humana, recuperación, logging y comportamiento ante incidentes del proveedor.

La ironía aquí es deliciosa: muchas entidades tienen mejores métricas de performance de sus modelos que evidencias de resiliencia del proceso entero. Mucha curva ROC, poca capacidad de recuperación.

GDPR: si el dato es personal, la IA no viaja fuera del derecho

El Reglamento General de Protección de Datos sigue siendo el gran desengañador de proyectos de IA montados con prisas. El artículo 5 exige licitud, minimización y limitación de la finalidad. El artículo 25 impone protección de datos desde el diseño y por defecto. El artículo 32 exige seguridad apropiada al riesgo. El artículo 33 obliga a notificar violaciones de seguridad a la autoridad de control en 72 horas cuando proceda. El artículo 35 exige evaluación de impacto cuando el tratamiento pueda entrañar alto riesgo, algo frecuente en IA aplicada a perfiles, vigilancia, decisiones automatizadas o grandes volúmenes de datos sensibles.

Y luego está el artículo 22 sobre decisiones individuales automatizadas con efectos jurídicos o similares significativos. En banca y seguros esto no es marginal. Si un modelo participa en concesión de crédito, tarificación, detección de fraude, bloqueo de operaciones, segmentación de riesgo o revisión de siniestros, la organización debe evaluar si hay intervención humana real, capacidad de impugnación y transparencia suficiente.

La fragilidad aquí no es solo técnica. También es jurídica. Un incidente de IA puede ser a la vez una caída operativa, una violación de datos personales y una mala práctica de gobierno del modelo. Tres frentes por el precio de uno.

NIS2: cadena de suministro y responsabilidad de la dirección

NIS2 endurece la responsabilidad de la alta dirección y obliga a adoptar medidas concretas de gestión de riesgos de ciberseguridad. El artículo 20 exige que los órganos de dirección aprueben y supervisen dichas medidas y reciban formación. El artículo 21 enumera obligaciones que encajan de lleno con entornos de IA: políticas de análisis de riesgos, gestión de incidentes, continuidad, seguridad de la cadena de suministro, seguridad en adquisición, desarrollo y mantenimiento, políticas para evaluar la eficacia de las medidas y prácticas básicas de ciberhigiene.

Esto tiene una derivada poco cómoda para los consejos: ya no basta con patrocinar proyectos de IA y pedir ROI. Tienen que entender el riesgo sistémico añadido. Si el modelo se integra con procesos esenciales, el problema deja de ser “de TI” y pasa a ser de gobernanza corporativa en sentido duro.

AI Act: gestión del riesgo, gobernanza de datos y supervisión humana

El AI Act de la UE, ya en fase de aplicación escalonada en 2026, introduce obligaciones específicas para sistemas de alto riesgo. Dependiendo del caso de uso, banca, seguros y empleo pueden entrar de lleno en esa categoría. Entre sus exigencias están un sistema de gestión de riesgos, gobernanza y calidad de datos, documentación técnica, registro de eventos, transparencia, supervisión humana, robustez, precisión y ciberseguridad.

Lo interesante es que el AI Act no sustituye a DORA, GDPR o NIS2; se apila encima. Un sistema de IA de alto riesgo usado por una entidad financiera puede exigir, simultáneamente, cumplimiento en protección de datos, resiliencia digital, ciberseguridad de cadena de suministro y gobernanza del modelo. Quien intente repartir estas obligaciones en silos separados acabará con lagunas. Y las lagunas son donde luego florecen los incidentes.

eIDAS 2.0 y confianza digital

EIDAS 2.0 importa cuando la IA entra en onboarding, firma electrónica, wallet de identidad y procesos KYC/KYB. Si una organización automatiza verificación documental, comparación biométrica o decisiones de confianza digital, no basta con evaluar precisión del modelo. Hay que mirar integridad de la cadena de evidencia, autenticidad de credenciales, trazabilidad y capacidad de demostrar por qué se aceptó o rechazó una identidad. La resiliencia, en este contexto, también es probatoria. Si no puedes reconstruir el flujo, en una disputa o inspección estás perdido.

CSRD: el coste invisible de la IA también se reporta

La pieza de Reuters menciona algo que durante demasiado tiempo se trató como externalidad elegante: energía y agua en centros de datos. En 2026 ya no es una nota a pie de página. Para empresas bajo obligaciones de sostenibilidad y divulgación, la huella de infraestructuras digitales puede cruzarse con métricas ambientales, dependencia de recursos y riesgos de transición o físicos. La CSRD obliga a reportar información material de sostenibilidad con enfoque de doble materialidad. Si el despliegue de IA altera consumo energético, dependencia geográfica de centros de datos o exposición a restricciones de recursos, eso puede dejar de ser una conversación de operaciones y pasar a la esfera del reporting corporativo y la supervisión del consejo.

HIPAA y NIST CSF 2.0: la lección útil fuera de Europa

En sanidad, HIPAA sigue recordando que automatizar no exonera de salvaguardas de confidencialidad, integridad y disponibilidad. Y NIST CSF 2.0, aunque voluntario, aporta una estructura excelente para aterrizar la gobernanza de IA dentro del programa de ciberresiliencia. La novedad de CSF 2.0 es la función Govern, muy útil para evitar que la IA quede flotando entre innovación, datos y seguridad sin un dueño real del riesgo. Si una entidad aún no ha mapeado sus casos de uso de IA a Govern-Identify-Protect-Detect-Respond-Recover, ya va tarde.

Por qué banca y seguros tienen más que perder

Todos los sectores pueden caer en la trampa de fragilidad. Banca y seguros, además, la monetizan rápido. Un banco que integra IA en prevención de fraude, atención al cliente, scoring, AML o ciberdefensa no solo mejora capacidad. También amplía superficie de ataque, dependencia de terceros y riesgo de error a escala. Una aseguradora que usa IA en suscripción, detección de fraude, análisis de documentos y priorización de siniestros gana velocidad, pero puede generar problemas serios de trazabilidad, sesgo, explicabilidad y continuidad si no controla la cadena completa.

Veamos escenarios concretos.

Escenario 1: scoring de crédito asistido por IA. El modelo mejora la discriminación estadística y reduce tiempos de decisión. Bien. Pero se alimenta de pipelines de datos externos, se ejecuta sobre infraestructura cloud, genera explicaciones poco útiles para atención al cliente y depende de umbrales revisados solo trimestralmente. Si falla el proveedor de datos, si cambia la distribución de inputs o si el modelo degrada por drift, el proceso puede seguir produciendo decisiones con apariencia de normalidad. Eso es peor que una caída visible. Bajo GDPR, AI Act y reglas sectoriales, la entidad necesita supervisión humana efectiva, trazabilidad, pruebas periódicas y capacidad de intervención.

Escenario 2: automatización de respuesta antifraude. La IA detecta patrones anómalos y activa bloqueos automáticos. La tasa de detección sube. También las falsas alarmas en determinados segmentos. Un incidente operacional o un error de configuración puede congelar operaciones legítimas en masa. Bajo DORA, esto afecta disponibilidad y continuidad del servicio financiero. Bajo GDPR, un tratamiento erróneo con impacto significativo exige cuidado especial. Si encima el modelo consume señales de terceros no validadas, el problema se convierte en cadena de suministro digital.

Escenario 3: triaje de siniestros en seguros. El modelo prioriza expedientes y detecta inconsistencias documentales. Perfecto para eficiencia. Menos perfecto si sesga ciertas tipologías, si el canal de entrada documental falla o si el personal humano acaba confiando ciegamente en el score. La resiliencia aquí depende de controles de override, revisión muestral, pruebas de drift, auditoría de decisiones y procedimientos de fallback cuando el sistema no esté disponible.

Escenario 4: copilotos internos para empleados. Este es el caballo de Troya favorito de 2026. Parece inocuo: resumir documentos, preparar respuestas, consultar procedimientos. Luego descubrimos que el copiloto expone datos sensibles en prompts, reutiliza información no autorizada, se integra con repositorios sobredimensionados en permisos y acaba contaminando decisiones con respuestas plausibles pero incorrectas. El incidente no siempre será espectacular. A veces será peor: errores pequeños, frecuentes y difíciles de atribuir. La clase de riesgo que erosiona control interno sin dar titulares.

En todos estos casos, la pregunta no es si la IA funciona. La pregunta es si el proceso sigue siendo gobernable bajo estrés.

La ciberseguridad de la IA no es solo un problema de modelos

Cuando se habla de riesgos de IA, demasiadas conversaciones se quedan en prompt injection, data poisoning o model theft. Son riesgos reales, sí. Pero centrarse solo en ellos puede distraer de lo esencial: la mayor parte del riesgo operativo en 2026 sigue estando en la integración, los privilegios, las dependencias y la visibilidad.

Un sistema de IA hereda y amplifica debilidades clásicas de seguridad:

Gestión de identidades y accesos. Si un copiloto o motor de decisión se conecta a múltiples sistemas con permisos excesivos, se convierte en un acelerador de movimiento lateral o exfiltración.

Inventario deficiente. Muchas organizaciones no tienen un inventario fiable de modelos, APIs, datasets, conectores y flujos de decisión. Sin inventario no hay clasificación de criticidad. Sin clasificación no hay controles proporcionales.

Logging insuficiente. Para investigar un incidente necesitas saber qué dato entró, qué versión del modelo respondió, qué reglas se activaron, qué humano aprobó, qué proveedor intervino y dónde se almacenó la evidencia. Si no tienes eso, no tienes forense; tienes arqueología.

Gestión de cambios superficial. Actualizar un modelo, un prompt de sistema o una integración puede alterar comportamientos de forma significativa. Tratar esos cambios como simples ajustes de producto es un error de control interno.

Dependencia de datos no confiables. El viejo principio “garbage in, garbage out” sigue vivo y bastante ofendido por lo poco que se le escucha.

Supervisión humana cosmética. Poner a un analista al final de la cadena para que pulse “aprobar” no es supervisión. Es teatro de control.

Los controles recomendables, por tanto, tienen que mirar la pila completa. En entidades reguladas, como mínimo deberían existir: inventario de casos de uso y clasificación por criticidad; evaluación de impacto legal y operativo por caso; segregación de entornos; registros de acceso y de inferencia; validación independiente del modelo; pruebas de resiliencia y fallback; límites de automatización; revisión periódica de terceros; gobierno de datos; y un comité o foro con capacidad real para frenar despliegues, no solo para bendecirlos.

Si esto suena menos glamuroso que comprar licencias de IA generativa, es porque lo es. También es lo que evita que el proyecto termine explicándose ante auditoría, supervisor o consejo en términos bastante menos épicos.

Qué deberían medir de verdad las empresas en 2026

Si una organización quiere saber si la IA la está haciendo más resiliente o simplemente más rápida, necesita cambiar el cuadro de mando. Las métricas útiles no son solo precisión, ahorro o tiempo medio de respuesta. Esas importan, pero son insuficientes.

Las preguntas correctas son otras.

¿Cuál es el tiempo máximo tolerable de interrupción del proceso donde interviene IA y está definido formalmente? Si no existe, nadie sabe cuánto margen tiene realmente.

¿Qué porcentaje del proceso crítico puede seguir operando en modo degradado sin el modelo? Si la respuesta es “casi nada”, la dependencia es mucho mayor de lo que dice la presentación comercial.

¿Cuánto tarda la organización en detectar drift o comportamiento anómalo con impacto de negocio? No en laboratorio. En producción.

¿Cuántos terceros participan en la cadena completa del caso de uso y cuántos han sido evaluados con criterios actualizados de seguridad, privacidad y continuidad?

¿Qué evidencias existen de supervisión humana efectiva? No de presencia humana, de supervisión efectiva.

¿Se han probado escenarios de caída del proveedor, corrupción del dato, denegación de servicio, respuesta errónea masiva o fallo de autenticación?

¿Existen límites de autoridad automatizada por importe, segmento, producto o impacto?

¿Se puede explicar una decisión crítica a un cliente, auditor o supervisor con trazabilidad suficiente?

Estas métricas no son teóricas. Son las que separan a una organización con control de otra que solo tiene entusiasmo.

El problema energético ya no es una nota al pie

Reuters toca otro punto que muchas empresas aún tratan como molestia periférica: los recursos físicos detrás de la IA. Los centros de datos consumen energía y agua, y varias regiones europeas ya sienten esa tensión. Esto importa por tres vías.

Una, continuidad operativa. Si un despliegue intensivo de IA depende de centros de datos situados en regiones con restricciones energéticas, estrés hídrico o cuellos de infraestructura, la resiliencia física entra en juego. Dos, coste. La volatilidad energética puede convertir un caso de negocio impecable sobre el papel en una carga menos simpática. Tres, cumplimiento y reporting. Para compañías sujetas a divulgaciones de sostenibilidad, la huella material de la infraestructura digital deja de ser un asunto abstracto.

Hay una ironía interesante: durante años muchas empresas auditaron riesgos físicos en fábricas remotas mientras aceptaban como casi intangible la infraestructura digital cercana. La IA está corrigiendo esa ilusión a golpes de factura y dependencia. La nube nunca fue etérea; solo estaba muy bien presentada.

Objeción habitual: “pero la IA también mejora la resiliencia”

Claro que puede mejorarla. Detecta anomalías antes, permite simulaciones, optimiza mantenimiento, acelera respuesta a incidentes, ayuda a clasificar alertas y mejora planificación. Negarlo sería absurdo. La objeción seria no es esa. La objeción seria es esta: si aporta tanto, ¿por qué insistir tanto en el riesgo?

Respuesta: porque la mejora existe, pero no es automática ni lineal. La IA sí puede reforzar resiliencia cuando se cumplen al menos cuatro condiciones.

Primera, el caso de uso está ligado a una función claramente definida, con métricas de continuidad y recuperación, no solo de rendimiento.

Segunda, el proceso entero se rediseña, incluidos roles, handoffs, excepciones, incentivos y fallback.

Tercera, la dependencia de terceros está gobernada contractual y operativamente, con visibilidad real de subservicios y estrategia de contingencia.

Cuarta, el modelo está bajo un marco de control que incluye datos, seguridad, privacidad, cambio, monitorización y supervisión humana.

Cuando eso ocurre, la IA puede ser un multiplicador de resiliencia. Cuando no, suele ser un multiplicador de complejidad. Y la complejidad no gestionada siempre pasa factura; la única incógnita es cuándo.

Qué deberían hacer ahora los consejos, CISOs y compliance officers

No hace falta inventar un programa grandilocuente nuevo. Hace falta cerrar una serie de huecos muy concretos.

El consejo debe pedir una cosa incómoda pero imprescindible: un mapa de dependencias reales de los casos de uso de IA en procesos críticos. No un catálogo de innovación. Un mapa de dependencias. Proveedor cloud, modelo, datasets, conectores, privilegios, métricas, fallback, responsable de negocio, responsable técnico y obligación regulatoria asociada.

El CISO debe dejar de tratar la IA como excepción exótica y meterla en el núcleo del programa de seguridad: inventario, IAM, logging, monitorización, pruebas, continuidad y terceros. Si el caso de uso toca una función importante, debería existir un escenario de fallo ensayado, no imaginado.

La segunda línea de riesgo y compliance tiene que hacer algo igual de poco glamuroso y mucho más útil que redactar principios genéricos: cruzar cada uso de IA con DORA, GDPR, NIS2, AI Act y, cuando proceda, eIDAS 2.0 o CSRD. Caso por caso. ¿Hay datos personales? ¿Hay decisión automatizada significativa? ¿Es función crítica o importante? ¿Hay tercero esencial? ¿Se requiere evaluación de impacto? ¿Hay trazabilidad y evidencia suficiente?

Compras y gestión de proveedores deben endurecer preguntas. No basta con SOC 2, ISO 27001 o promesas de “enterprise grade”. Hay que preguntar por subprocesadores, localización, segregación, retención de prompts y logs, derechos de uso de datos, notificación de incidentes, continuidad, pruebas, portabilidad y cambios materiales del servicio.

Y negocio debe aceptar una verdad simple: si la IA soporta una decisión crítica, no puede desplegarse como experimento perpetuo. Tiene que vivir con controles de producción de verdad.

La lección que deja 2026

La madurez de este año no consiste en descubrir que la IA sirve para algo. Eso ya lo sabe hasta el último comité de dirección que ha pedido un copiloto. La madurez consiste en entender dónde rompe la organización cuando la enchufas a escala.

La trampa de fragilidad no aparece porque la IA sea defectuosa por naturaleza. Aparece porque las empresas insertan herramientas muy potentes en estructuras diseñadas para un entorno más lento, más modular y menos dependiente de unos pocos actores tecnológicos. Si no rediseñan la organización, la mejora local se convierte en vulnerabilidad sistémica.

Para las entidades reguladas, el mensaje es todavía más áspero. No basta con demostrar que la IA genera valor. Hay que demostrar que no compromete continuidad, control, privacidad, trazabilidad y capacidad de recuperación. DORA, NIS2, GDPR y el AI Act, cada uno a su manera, van exactamente por ahí.

La pregunta útil para cerrar no es “¿cuánto estamos invirtiendo en IA?”. Esa ya la conoce todo el mundo. La pregunta útil es otra: si mañana cae el proveedor, se degrada el modelo o se corrompe el dato, ¿tu operación crítica aguanta, se explica y se recupera?

Si la respuesta es dudosa, la empresa no es más resiliente. Solo es más rápida camino del próximo problema.