CISA añade dos nuevas vulnerabilidades al catálogo KEV y deja una advertencia incómoda: la deuda de parcheo ya incluye la capa de IA

No hace falta que una herramienta sea omnipresente para convertirse en un problema regulatorio. Basta con que esté metida en un punto delicado de la cadena: acceso a modelos, secretos de API, routing de peticiones, registros, prompts, conectores. Si además esa pieza actúa como intermediaria entre aplicaciones internas y varios proveedores de IA, el incidente deja de ser un asunto de desarrollo y pasa a sentarse en la mesa de riesgo operativo.

Eso es lo que vuelve relevante cualquier vulnerabilidad seria en una capa de proxy o pasarela para modelos generativos. No porque el nombre del producto, por sí solo, cambie el mapa de amenazas. Lo que cambia el mapa es su función. Una pieza de este tipo puede concentrar credenciales, tráfico sensible y decisiones de enrutado. Y cuando una sola pieza concentra tanto, DORA deja de ser teoría amable de regulador y vuelve a ser lo que siempre fue: disciplina sobre dependencias tecnológicas que demasiadas entidades siguen tratando como simple plumbing.

La tentación aquí es correr al titular fácil: “fallo en herramienta de IA, nuevo dolor de cabeza para banca y seguros”. Suena bien, pero se queda corto. El punto interesante no es la vulnerabilidad en abstracto. El punto es qué revela sobre cómo muchas organizaciones están desplegando IA: deprisa, con capas intermedias poco gobernadas y con una peligrosa tendencia a considerar “experimental” todo lo que todavía no ha entrado formalmente en el inventario de activos. Ya sabes cómo termina esa película.

La lección regulatoria no está en el hype de la IA, sino en la arquitectura

Si una entidad financiera incorpora una pasarela para centralizar el acceso a modelos, gestionar claves, aplicar políticas o registrar uso, esa decisión técnica tiene una consecuencia regulatoria inmediata: deja de ser una simple comodidad para desarrolladores y pasa a encajar en el marco de gestión del riesgo TIC de DORA. No hace falta forzar la lectura. El Reglamento (UE) 2022/2554 lo deja bastante claro desde su núcleo.

El artículo 6 de DORA obliga a las entidades financieras a contar con un marco interno sólido, integral y bien documentado de gestión del riesgo relacionado con las TIC que permita abordar el riesgo de forma rápida, eficiente y exhaustiva y garantice un alto nivel de resiliencia operativa digital. Esa es la base. No el artículo 8. El artículo 8 entra en materia de identificación, pero la obligación general del marco está en el 6 y en las disposiciones que lo desarrollan.

Luego viene la parte que muchas organizaciones prefieren no mirar demasiado de cerca. El artículo 8 de DORA exige mantener y actualizar inventarios y registros pertinentes de activos TIC, incluidos aquellos activos cuyo fallo pueda afectar a funciones críticas o importantes. También pide identificar, clasificar y documentar adecuadamente funciones empresariales respaldadas por TIC, los roles y responsabilidades, y las dependencias en TIC. No es un ejercicio cosmético para complacer a auditoría. Es la condición previa para saber qué demonios estás protegiendo.

Ahí está el primer choque con muchas implantaciones de IA generativa. La herramienta de acceso a LLM suele entrar por la puerta lateral: primero como librería, luego como proxy interno, después como servicio compartido por varios equipos. Cuando nadie actualiza el inventario porque “todavía estamos probando”, el problema no es semántico. El problema es regulatorio y operativo.

Una vulnerabilidad en la pasarela no es solo un bug; es una concentración de riesgo

Sin entrar en afirmaciones técnicas que no estén respaldadas por la información disponible sobre un caso concreto, sí hay una conclusión prudente que se sostiene por arquitectura: una vulnerabilidad grave en una capa intermediaria de acceso a modelos puede afectar a varios tipos de activos y procesos a la vez. Puede comprometer la confidencialidad de solicitudes y respuestas, exponer credenciales si estas pasan o se almacenan allí, alterar la integridad del enrutado entre proveedores o degradar la disponibilidad de servicios que dependan de ese punto común.

No hace falta adornarlo con escenarios de película. Basta con mirar cómo funcionan estas piezas en entornos empresariales. Suelen tocar autenticación hacia APIs externas, políticas internas de consumo, logging, telemetría y, en algunos casos, integraciones con otras herramientas. Cuanta más centralización aportan, más eficiente parece el diseño. Y más elegante resulta hasta el día en que falla. Entonces descubrimos la letra pequeña: centralización también significa superficie de impacto concentrada.

Desde la óptica de DORA, eso encaja mejor en las obligaciones de protección y prevención del artículo 9, en los requisitos de detección del artículo 10, y en las capacidades de respuesta y recuperación de los artículos 11 y 12. No porque el reglamento mencione una tecnología concreta —no lo hace—, sino porque regula funciones: proteger activos TIC, detectar anomalías e incidentes, responder, restaurar y aprender. Cambia el nombre del proveedor si quieres. La lógica regulatoria no cambia un milímetro.

Ese es, por cierto, uno de los puntos donde más se nota la distancia entre el discurso de innovación y la realidad del control interno. Muchas entidades han entendido muy bien la parte sexy de la IA —casos de uso, productividad, automatización, experiencia de cliente—, pero siguen tratando las capas de orquestación y proxy como si fueran piezas neutras. No lo son. Son puntos de control. Y todo punto de control merece gobierno, pruebas y trazabilidad.

Lo que DORA sí exige, sin necesidad de inventar artículos milagrosos

Conviene poner orden, porque con DORA circula bastante folclore de PowerPoint. El reglamento no dice “si usas una pasarela de LLM, haz exactamente esta lista cerrada de controles”. Tampoco necesita decirlo. Lo que hace es imponer obligaciones funcionales y organizativas suficientemente claras como para que una entidad no pueda esconder una pieza relevante en el cajón de “herramientas de desarrollo”.

Si esa capa soporta procesos de negocio o interviene en servicios internos con relevancia operativa, la lectura prudente y defendible es esta:

• Debe ser visible dentro del marco de gestión del riesgo TIC exigido por el artículo 6.
• Debe quedar contemplada en la identificación y documentación de activos y dependencias TIC del artículo 8, en la medida en que su indisponibilidad o compromiso afecte a funciones de negocio o a controles.
• Debe quedar sujeta a medidas de protección, prevención, detección, respuesta y recuperación bajo los artículos 9 a 12.
• Si interviene un tercero proveedor, entran en juego los requisitos de gestión del riesgo de terceros TIC de DORA artículos 28 a 30, incluida la estrategia sobre riesgo derivado de terceros, el registro de acuerdos contractuales y la supervisión asociada.

La formulación importa. No estamos afirmando que DORA enumere “capa tipo LiteLLM” como categoría jurídica. Estamos diciendo algo más útil: si una pieza técnica cumple una función relevante en la prestación, soporte o control de servicios, DORA ya tiene dónde colocarla. Y si tu organización todavía no la ha colocado en ninguna parte, el problema no es del reglamento.

El error habitual: confundir experimento con excepción de control

La mayoría de despliegues de IA dentro de entidades reguladas no empiezan con una gran arquitectura aprobada por tres comités y un acta impecable. Empiezan con un piloto. Un equipo de atención al cliente prueba asistencia a agentes. Riesgos quiere resumir documentación. Cumplimiento experimenta con búsqueda semántica. Seguridad monta un asistente para triage. Operaciones automatiza redacción de tickets o consultas repetitivas. Todo parece pequeño. Todo parece reversible. Hasta que deja de serlo.

Ese patrón genera un ángulo muerto muy concreto: como el caso de uso nació como prueba, la infraestructura que lo sostiene hereda una especie de indulgencia operativa. No se documenta del todo. No se clasifica con rigor. No pasa por la misma disciplina de cambios que otros componentes. Y, sin embargo, puede acabar agregando tráfico de varias áreas, secretos de distintos proveedores y datos de naturaleza diversa.

DORA está diseñado precisamente para atacar ese tipo de autoengaño corporativo. El artículo 5 atribuye al órgano de dirección la responsabilidad última de definir, aprobar, supervisar y responder por la aplicación del marco de gestión del riesgo TIC. Traducido al castellano no regulatorio: la entidad no puede refugiarse en que “esto lo montó innovación” o “era una prueba del equipo de datos”. Si la pieza afecta a la resiliencia, alguien arriba responde.

Y aquí aparece una ironía regulatoria bastante cruel. Cuanto más “ágil” fue el despliegue inicial, más caro suele salir regularizarlo después. Lo que en una startup se llamaría iteración, en una entidad financiera puede convertirse en una maratón de inventariado, validación de dependencias, revisión contractual, endurecimiento de accesos, logging, retención, segregación de entornos y rediseño de flujos. La innovación rápida existe. La innovación rápida y sin deuda de control, bastante menos.

Inventario y criticidad: el debate no es si la herramienta es famosa, sino si impacta una función

Una de las afirmaciones más fáciles de inflar en este terreno es la de adopción de mercado. Si una herramienta se usa mucho o poco puede ser relevante comercialmente, pero regulatoriamente no decide casi nada. Lo que sí decide mucho es si soporta una función empresarial, un proceso interno sensible o una cadena de control.

Por eso el debate correcto no es “¿esta solución está ampliamente implantada?”. El debate correcto es otro: si fallara o se comprometiera, ¿qué función de negocio, proceso operativo o control se vería afectado y durante cuánto tiempo? Esa pregunta sí conecta con DORA y con una gestión seria del riesgo.

El artículo 8 obliga a las entidades a identificar y documentar las funciones empresariales respaldadas por TIC, así como sus dependencias. A partir de ahí, la clasificación de criticidad no debería depender del marketing del proveedor ni del entusiasmo del equipo que impulsó el caso de uso. Debería depender del impacto real: interrupción del servicio, degradación de un control, exposición de información, errores en decisiones asistidas o dependencia excesiva de un componente sin alternativas razonables.

Si la capa intermediaria solo sirve para un laboratorio aislado sin datos reales ni conexión con procesos productivos, su tratamiento será uno. Si enruta solicitudes de empleados, clientes o funciones de soporte con implicaciones operativas, será otro. Parece obvio. No siempre se practica como si lo fuera.

Cuando la IA toca datos personales, DORA no va sola

Hay otro error común: leer estos incidentes solo con gafas de resiliencia operativa. Si por esa capa pasan datos personales, el GDPR se sienta automáticamente en la misma mesa.

El artículo 32 del GDPR exige aplicar medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo, incluyendo confidencialidad, integridad, disponibilidad y resiliencia continuas de los sistemas y servicios de tratamiento. Es una formulación deliberadamente abierta, pero su lógica encaja de lleno con arquitecturas de IA intermediadas por proxies, SDKs o gateways.

Si un incidente de seguridad en esa capa derivara en una violación de seguridad de los datos personales, entrarían además el artículo 33 sobre notificación a la autoridad de control sin dilación indebida y, cuando sea posible, a más tardar en 72 horas, y el artículo 34 si hubiera que comunicarlo a los interesados por alto riesgo. No afirmamos que cualquier vulnerabilidad conduzca a una brecha notificable. Afirmamos algo menos espectacular y bastante más útil: si tu diseño concentra datos y secretos en un punto intermedio, el análisis de impacto de un incidente debe hacerse también con lente de protección de datos, no solo de continuidad o ciberseguridad.

Y eso complica —para bien— las preguntas que debe hacerse la entidad. ¿Qué logs retiene esa pasarela? ¿Incluyen prompts con datos personales o información sensible? ¿Se minimiza el contenido? ¿Quién accede a los registros? ¿Hay transferencias internacionales por el proveedor subyacente? ¿Se han delimitado finalidades? Si el proyecto de IA evitó todas esas conversaciones porque “solo era una capa técnica”, malas noticias: acabas de describir una mala capa técnica.

NIS2 añade una presión incómoda: gobernanza real, no compliance teatral

Aunque DORA es la norma sectorial central para entidades financieras, NIS2 refuerza la dirección general del viaje regulatorio europeo: los órganos de dirección tienen que tomarse en serio la ciberseguridad de la cadena tecnológica, no delegarla a una presentación trimestral.

El artículo 21 de la Directiva (UE) 2022/2555 obliga a las entidades esenciales e importantes a adoptar medidas técnicas, operativas y organizativas apropiadas y proporcionadas para gestionar los riesgos de seguridad de las redes y sistemas de información. Entre esas medidas, el propio artículo menciona gestión de incidentes, continuidad de negocio, seguridad de la cadena de suministro, seguridad en adquisición, desarrollo y mantenimiento, políticas y procedimientos para evaluar la eficacia de las medidas de gestión del riesgo y prácticas básicas de ciberhigiene, entre otras.

La resonancia con una capa intermediaria de IA es evidente. No porque NIS2 regule LLMs. No porque DORA mencione proxies de modelos. Sino porque ambas normas castigan el mismo vicio corporativo: depender de componentes relevantes que no han sido suficientemente gobernados, probados o integrados en el control interno.

Si quieres la versión sin diplomacia, aquí va: Europa no está pidiendo a las entidades que sepan pronunciar “orquestación de modelos”. Les está pidiendo que dejen de introducir dependencias opacas en procesos sensibles y luego fingir sorpresa cuando aparece una vulnerabilidad.

Qué debería revisar ahora una entidad financiera si usa una capa de acceso a LLM

La reacción útil no es dramatizar cada CVE ni fingir que todo se arregla con un parche. La reacción útil es revisar de forma concreta dónde está esa pieza y qué peso real tiene en la arquitectura.

Una entidad debería poder responder, como mínimo, a estas preguntas sin improvisar:

• Ubicación y función: ¿La solución actúa como librería local, servicio interno, proxy centralizado o componente gestionado por un tercero?
• Dependencias: ¿Qué aplicaciones, equipos o procesos dependen de ella? ¿Existe dependencia de un único punto de fallo?
• Credenciales y secretos: ¿Gestiona claves de proveedores, tokens internos o credenciales de servicios adyacentes?
• Datos tratados: ¿Pasan por ella prompts, respuestas, datos personales, información confidencial o registros con contenido sensible?
• Controles: ¿Está sujeta a gestión formal de cambios, hardening, control de accesos, monitorización, registro y respuesta a incidentes?
• Terceros: ¿Hay acuerdos contractuales, evaluación de riesgos y visibilidad suficiente si interviene un proveedor externo?

No es una checklist ornamental. Cada una conecta con obligaciones concretas. DORA artículo 8 para activos, funciones y dependencias; artículos 9 a 12 para protección, detección, respuesta y recuperación; artículos 28 a 30 para riesgo de terceros TIC; GDPR artículo 32 para seguridad del tratamiento cuando existan datos personales.

Si la entidad no puede contestar con precisión, ya tiene identificado el problema principal. No es la vulnerabilidad publicada. Es la falta de conocimiento operativo sobre una dependencia que probablemente ya es más importante de lo que parecía en la demo inicial.

La cuestión contractual tampoco es un detalle

Cuando la pieza se despliega como servicio de un tercero o se integra con proveedores externos, el análisis deja de ser puramente técnico. DORA artículo 28 exige una estrategia sobre el riesgo derivado de terceros proveedores de servicios TIC. El artículo 30 entra en los elementos contractuales clave para esos acuerdos. Y el reglamento no se conforma con saber que existe contrato: quiere que la entidad pueda gestionar, supervisar y, si hace falta, salir ordenadamente de la dependencia.

Aquí es donde muchas arquitecturas de IA enseñan costuras. El equipo contrata una solución para acelerar pruebas. Más tarde esa solución se convierte en punto común de acceso a varios modelos, quizá incluso a herramientas internas. Pero el contrato original no estaba pensado para una función con peso operacional creciente. Resultado: derechos de auditoría difusos, poca claridad sobre subcontratación, salidas poco realistas y escasa visibilidad de cómo se gestionan vulnerabilidades o registros.

¿Puede una entidad convivir temporalmente con ese desajuste? A veces sí, en fase temprana y con compensaciones internas robustas. ¿Es una posición cómoda bajo DORA? En absoluto. La norma empuja en dirección contraria: visibilidad, control y capacidad de supervisión proporcionada al riesgo. Todo lo demás suena muy innovador hasta que llega el primer incidente serio.

Lo que no conviene hacer: sobrerreaccionar con teatro o minimizar con jerga

Hay dos respuestas malas y bastante habituales. La primera es la teatral: congelar todos los proyectos de IA, mandar una circular grandilocuente y presentar la medida como prueba de prudencia. Eso puede tranquilizar durante 48 horas, pero no arregla nada. Si la dependencia está mal gobernada, seguirá mal gobernada cuando se reanude el proyecto.

La segunda es la respuesta de jerga técnica: asegurar que todo está bajo control porque la herramienta corre en contenedor, porque hay un WAF, porque los datos “no persisten” o porque el caso de uso “no es core”. Ninguna de esas frases sustituye un análisis de activos, dependencias, exposición, contratos, logging, privilegios y planes de respuesta. A veces son ciertas. Casi nunca bastan.

La salida razonable está en medio: validar alcance, revisar exposición real, aplicar remediaciones o mitigaciones según proceda, y actualizar inventarios y clasificación si la relevancia operativa de la pieza era mayor de la reconocida. Suena menos heroico que una suspensión total. También es mucho más útil.

El ángulo que muchos comités todavía no han entendido

La discusión sobre IA en entidades reguladas sigue atrapada, demasiadas veces, entre dos caricaturas. Una dice que el gran riesgo es que el modelo alucine. La otra dice que todo se resolverá con políticas de uso responsable y formación. Las dos contienen algo de verdad y bastante insuficiencia.

El riesgo más subestimado hoy no siempre está en la salida del modelo. A menudo está en la infraestructura intermedia que hace posible usarlo a escala: gateways, capas de abstracción, sistemas de logging, conectores, plugins, brokers de credenciales, pipelines de recuperación y orquestadores. Es menos glamuroso, sí. También es donde se concentran muchos de los problemas que DORA sabe reconocer mejor: dependencia, opacidad, falta de inventario, controles desiguales, terceros mal supervisados y respuesta inmadura ante incidentes.

Si tu comité sigue discutiendo IA como si solo fuera una cuestión de ética del modelo o productividad de usuarios, llega tarde a la mitad del problema. Y la mitad arquitectónica suele ser la que acaba generando hallazgos de auditoría serios, no solo debates filosóficos en salas con café decente.

Conclusión: menos obsesión por la herramienta, más atención a su función

El nombre comercial de la solución importa menos de lo que parece. Lo decisivo es si la entidad la usa como punto relevante de paso, control o integración entre procesos internos y servicios de IA. Si la respuesta es sí, no debería vivir en tierra de nadie.

DORA no exige adivinar el futuro de cada tecnología. Exige algo más incómodo y más sensato: saber qué dependencias tienes, qué funciones soportan, qué pasa si fallan, qué controles las rodean y cómo gobiernas a los terceros implicados. Eso está en el corazón del artículo 6, se concreta en el artículo 8, y se vuelve operativo en los artículos 9 a 12 y 28 a 30. El resto son excusas con vocabulario nuevo.

Si una vulnerabilidad reciente en una capa de acceso a LLM te obliga a revisar inventario, clasificación, monitorización, contratos y respuesta, no lo leas solo como un susto técnico. Léelo como un diagnóstico bastante preciso: la gobernanza de IA de muchas entidades todavía depende demasiado de cómo empezó el proyecto y demasiado poco de en qué se ha convertido realmente.

Y esa, para un regulador europeo, es casi la definición de riesgo operativo digital mal gestionado.