Las vulnerabilidades críticas en LangGraph no son un problema de laboratorio: abren una puerta directa a los agentes de IA en producción

Un fallo en un framework de agentes no es un bug cualquiera. Si ese framework orquesta llamadas a herramientas, memoria, prompts encadenados y acceso a servicios externos, el problema deja de ser de desarrollo y pasa a ser de gobernanza, seguridad y control operativo. Eso es lo que vuelve relevante la reciente atención sobre LangGraph: no porque haya que entrar en pánico, sino porque obliga a mirar una capa que demasiadas organizaciones todavía tratan como si fuera solo experimentación.

La cuestión no es si LangGraph es popular o si media industria lo usa para procesos críticos; esa afirmación, sin datos sólidos delante, sería literatura. La cuestión seria es otra: frameworks de este tipo están diseñados precisamente para coordinar flujos de decisión automatizada entre modelos, herramientas y datos. Y cuando aparece una debilidad en esa capa de orquestación, lo que se pone en juego no es una pantalla bonita, sino la lógica que decide qué se invoca, con qué contexto y con qué permisos.

Ahí está el ángulo que sí merece atención regulatoria y operativa. Si tu organización despliega agentes con acceso a sistemas corporativos, repositorios documentales, bases de conocimiento internas o herramientas conectadas por API, el riesgo ya no se puede despachar con un “es un piloto”. Un piloto con credenciales de producción deja de ser un piloto bastante rápido, aunque a más de uno le guste llamarlo innovación para evitar llamarlo deuda de control.

El problema real no es el nombre del framework, sino la función que cumple

LangGraph forma parte de una familia de herramientas pensadas para construir flujos agentic: secuencias en las que un modelo no solo responde, sino que ejecuta pasos, consulta memoria, llama herramientas y toma decisiones condicionales dentro de un grafo. No hace falta inflar el argumento con afirmaciones grandilocuentes sobre su adopción. Basta entender su arquitectura funcional para ver por qué un incidente en esta clase de software merece escrutinio.

Cuando una organización despliega un agente conectado a herramientas, suele introducir varios elementos sensibles a la vez: instrucciones del sistema, lógica de enrutado, contexto de usuario, conectores a servicios externos, almacenamiento de estado y, en algunos casos, credenciales o tokens con permisos operativos. No hace falta demostrar que cada despliegue incluye todos esos componentes para sostener una conclusión bastante sobria: la superficie de riesgo crece porque el agente ya no es solo un modelo, sino una capa de coordinación entre recursos distintos.

Ese matiz importa mucho más de lo que parece. En seguridad clásica, una vulnerabilidad en una librería concreta podía afectar a una función acotada del software. En sistemas agentic, la capa vulnerable puede influir en cómo se encadenan acciones, qué datos se incorporan al contexto y qué herramienta se llama después. La diferencia entre una incidencia menor y un incidente serio puede depender de algo tan pedestre como el alcance de un token, el aislamiento entre entornos o la validación previa de entradas y salidas. Nada de eso suena glamuroso. Todo eso decide el impacto.

Lo que sí puede decirse sin vender humo

Hay una tentación bastante extendida en la cobertura tecnológica: cuando aparece una debilidad en un componente asociado a IA, se exagera el caso hasta convertirlo en una amenaza casi metafísica. Conviene hacer lo contrario. Sin un detalle técnico completo de la cadena de explotación concreta, no se puede afirmar de forma tajante que un fallo determinado en LangGraph comprometa por sí mismo credenciales, historial de conversación, grafos de ejecución y acceso lateral a sistemas internos. Eso puede ser posible en determinados despliegues; no es una conclusión universal que deba darse por probada sin más.

Lo que sí es razonable afirmar es esto: en un framework que orquesta decisiones, memoria y herramientas, la severidad práctica de una vulnerabilidad depende del diseño del despliegue. Si el agente tiene acceso a datos internos, herramientas con permisos elevados o conexiones mal segmentadas, el impacto potencial sube. Si el entorno está aislado, las credenciales están limitadas, las herramientas están encapsuladas y el agente no puede salir de un perímetro controlado, el mismo fallo puede quedarse en algo mucho más manejable.

Dicho de otra manera: el problema no se agota en la existencia del bug. Lo decisivo es qué libertades operativas le has dado al sistema vulnerable. Y esa parte ya no pertenece al proveedor del framework. Pertenece a tu arquitectura, a tu modelo de control y, si hablamos de entidades reguladas, a tu capacidad de demostrar que sabías qué habías conectado y bajo qué condiciones.

Por qué esto encaja de lleno en DORA, aunque nadie pronuncie la palabra “LangGraph” en el reglamento

DORA no regula herramientas concretas. Regula capacidades, procesos y responsabilidades. Por eso un fallo en un framework de agentes puede ser jurídicamente relevante aunque el texto nunca mencione agentes, LLMs ni orquestadores. El punto de entrada está en cómo la entidad gestiona el riesgo asociado a activos y servicios TIC que soportan funciones de negocio.

El reglamento exige un marco interno de gestión del riesgo de las TIC que cubra identificación, protección, detección, respuesta y recuperación. Eso está en el artículo 6 de DORA, que fija la obligación general de contar con un marco sólido, integral y bien documentado. Si una entidad utiliza componentes para automatizar decisiones o ejecutar tareas mediante herramientas conectadas, esos componentes entran de lleno en el perímetro que debe evaluarse, documentarse y controlarse.

El artículo 8 obliga a identificar, clasificar y documentar adecuadamente todas las funciones, roles, responsabilidades, activos TIC y dependencias. Aquí aparece la primera pregunta incómoda: ¿tu organización tiene inventariados los agentes, frameworks, conectores, memorias y herramientas asociadas como activos TIC relevantes, o siguen viviendo en la cómoda penumbra del “esto lo montó un equipo de innovación”? Si no están identificados, no están gobernados. Y si no están gobernados, DORA no tiene un problema teórico; lo tiene tu entidad.

El artículo 9 se centra en protección y prevención. Ahí encajan medidas como control de accesos, gestión de vulnerabilidades, endurecimiento de configuraciones, segmentación y gestión segura de credenciales. Si el framework vulnerable se desplegó con permisos excesivos, conectores sin restricciones o secretos mal gestionados, la discusión deja de ser solo técnica. Se convierte en una discusión sobre si la entidad ha aplicado medidas proporcionadas al riesgo real del sistema.

El artículo 10 aborda detección. No basta con desplegar el agente y confiar en que “si hace algo raro ya lo veremos”. DORA pide mecanismos que permitan identificar anomalías, incidentes y comportamientos inusuales. En sistemas agentic, eso debería traducirse en trazabilidad de invocaciones, registro de herramientas llamadas, eventos de error, patrones anómalos en uso de contexto y alertas sobre acciones fuera de perfil. Si no puedes reconstruir qué hizo el agente, con qué inputs y sobre qué sistemas, tampoco podrás explicar a auditoría ni a supervisión qué pasó exactamente.

El ángulo que más se subestima: terceros TIC y cadena de suministro

Buena parte del riesgo en IA aplicada no está solo en el modelo, sino en la cadena de componentes. Framework de orquestación, proveedor de modelo, base de datos vectorial, herramienta de observabilidad, hosting, API externa, repositorio documental, plugin de búsqueda interna. La arquitectura moderna parece una caja de piezas. Regulación en mano, eso no reduce responsabilidad; la multiplica.

DORA dedica los artículos 28 a 30 a la gestión del riesgo de terceros proveedores de servicios TIC. El artículo 28 exige que las entidades gestionen ese riesgo como parte integrante de su marco de riesgo TIC. El 30 entra en el contenido contractual mínimo. Si un agente depende de servicios externos o de componentes de terceros, la entidad debe saber quién presta qué, con qué garantías, qué niveles de servicio existen, qué derechos de acceso, auditoría y terminación conserva, y qué ocurre si el componente falla o introduce un riesgo no tolerable.

Aquí suele aparecer una vieja costumbre del sector: tratar ciertas piezas open source o de desarrollo rápido como si estuvieran fuera del mapa de terceros porque “no hay un vendor enterprise al uso”. Mala idea. Aunque el tratamiento jurídico de software open source no encaje exactamente igual que un outsourcing tradicional, desde la óptica de riesgo operativo y seguridad la dependencia sigue existiendo. Si una función relevante depende de un componente mantenido externamente, ese componente debe entrar en el análisis de dependencia, criticidad, parcheo, monitorización y contingencia. El reglamento no premia la ingenuidad arquitectónica.

Si además el despliegue incluye proveedores cloud o APIs de modelos fundacionales, el cruce con terceros críticos se vuelve todavía más delicado. No porque todo proveedor vaya a ser designado crítico bajo el marco de supervisión de DORA, sino porque la entidad sigue obligada a entender la concentración de riesgo, las dependencias técnicas y las limitaciones contractuales reales. Tener cinco servicios encadenados no equivale a tener resiliencia. A veces equivale a tener cinco formas distintas de quedarse sin servicio.

NIS2 tampoco mira hacia otro lado

Si la organización está dentro del ámbito de NIS2, la conversación se amplía. La Directiva (UE) 2022/2555 impone a entidades esenciales e importantes medidas de gestión de riesgos de ciberseguridad en su artículo 21. Entre ellas figuran políticas de análisis de riesgos y seguridad de los sistemas de información, gestión de incidentes, continuidad de negocio, seguridad de la cadena de suministro, seguridad en la adquisición, desarrollo y mantenimiento de redes y sistemas, y evaluación de la eficacia de las medidas.

Traducido al caso que nos ocupa: si un framework de agentes se incorpora a procesos corporativos relevantes, la organización debe ser capaz de demostrar que ha evaluado el riesgo técnico y operativo de ese componente, su papel en la cadena de suministro digital, los controles de desarrollo seguro aplicados y los mecanismos de respuesta si aparece una vulnerabilidad o una explotación efectiva.

NIS2 añade además un punto que a menudo se pasa por alto cuando se habla de IA corporativa: la alta dirección asume responsabilidades claras de aprobación y supervisión de las medidas de gestión de riesgos de ciberseguridad, según el artículo 20. Eso reduce bastante el espacio para la excusa favorita de media empresa: “era un experimento del equipo técnico”. Si el experimento toca procesos materiales o sistemas relevantes, deja de ser un capricho del laboratorio y entra en la esfera de supervisión directiva.

GDPR: el problema no es solo la seguridad, también el uso de datos y la trazabilidad

Cuando estos sistemas procesan datos personales, el ángulo de protección de datos aparece de inmediato. GDPR no necesita pronunciarse sobre LangGraph para ser aplicable. Le basta con que exista tratamiento de datos personales y riesgo asociado al diseño del sistema.

El artículo 5 exige principios como minimización de datos, limitación de la finalidad e integridad y confidencialidad. Si un agente incorpora al contexto más datos de los necesarios, conserva memoria conversacional sin criterio claro o envía información personal a herramientas externas sin base adecuada, el problema no es futurista. Es regulatorio y bastante clásico.

El artículo 25 sobre protección de datos desde el diseño y por defecto es particularmente incómodo para despliegues agentic mal domesticados. Si una organización decide montar flujos con herramientas conectadas, debe poder justificar por qué ese diseño limita el acceso, restringe datos, controla salidas y reduce exposición innecesaria. No basta con pegar un aviso legal al final del proceso y esperar clemencia.

El artículo 32 exige medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo. Eso incluye, entre otras, seudonimización y cifrado cuando proceda, capacidad de garantizar confidencialidad, integridad, disponibilidad y resiliencia, y procesos para verificar la eficacia de las medidas. Si una vulnerabilidad en la capa de orquestación puede afectar al tratamiento de datos personales, la entidad tiene que evaluar ese riesgo dentro de su modelo de seguridad, no fuera de él.

Y si el incidente deriva en una violación de seguridad de datos personales, entran en juego el artículo 33, sobre notificación a la autoridad de control sin dilación indebida y, cuando sea posible, en un plazo no superior a 72 horas, y el artículo 34 sobre comunicación a los interesados cuando proceda. Aquí desaparece cualquier tentación semántica de llamarlo “incidencia técnica menor” si el efecto real ha sido exposición o acceso no autorizado a datos personales.

El error de gobierno más común: tratar los agentes como interfaz, no como sistema

Hay una mala lectura bastante habitual en organizaciones que empiezan a desplegar IA aplicada: ver el agente como una simple capa conversacional encima de sistemas ya gobernados. Es un espejismo útil para presentar demos. Es una pésima base para diseñar controles.

Un agente no es solo una interfaz si decide qué herramienta invoca, qué datos usa como contexto, cómo interpreta instrucciones, cuándo reintenta una acción y cómo encadena pasos posteriores. En términos de riesgo, se parece más a un sistema de ejecución condicionado por lenguaje que a un mero chatbot ornamental. Eso exige una gobernanza distinta.

La implicación práctica es directa. No basta con pasar el escáner de vulnerabilidades sobre la aplicación front-end o revisar el proveedor del modelo. También hay que mapear la lógica de herramientas, la memoria persistente o transitoria, los puntos de entrada de prompt o datos no confiables, los límites de permisos y los logs necesarios para investigar comportamientos anómalos. Si esa cartografía no existe, la organización está gestionando una caja negra con modales de asistente simpático.

Y aquí asoma la ironía regulatoria de turno: muchas compañías tienen controles exhaustivos para una API interna aburridísima que mueve un CSV al día, pero conceden bastante más laxitud a un agente que puede consultar documentos, redactar respuestas, accionar herramientas y operar sobre varios sistemas porque “todavía está en pruebas”. El software de siempre pasa por todos los comités. Lo nuevo entra por la puerta lateral con una presentación de PowerPoint y un presupuesto de innovación. Luego llegan las sorpresas.

Qué puede decir de verdad un equipo de compliance sin fingir que es ingeniería

No le corresponde a compliance explicar una cadena de explotación si no tiene detalles técnicos suficientes. Fingirlo suele producir documentos muy extensos y bastante inútiles. Lo que sí puede y debe hacer es formular las preguntas correctas, ancladas a obligaciones concretas.

Primera: ¿está el sistema identificado como activo TIC dentro del inventario exigible por DORA art. 8 o dentro del alcance de análisis de riesgos aplicable bajo NIS2 art. 21? Si la respuesta es difusa, ya tienes un problema de base.

Segunda: ¿existe clasificación de criticidad en función de datos tratados, herramientas accesibles, procesos soportados y grado de autonomía operativa? No hace falta inventar taxonomías barrocas. Hace falta decidir si el sistema puede afectar a disponibilidad, integridad, confidencialidad o cumplimiento normativo de forma material.

Tercera: ¿qué terceros intervienen realmente? Framework, hosting, proveedor del modelo, observabilidad, bases de datos, conectores documentales, herramientas SaaS. Si la dependencia existe, debe reflejarse en el análisis de terceros bajo DORA art. 28 y, cuando aplique, en requisitos contractuales del art. 30.

Cuarta: ¿hay trazabilidad suficiente? DORA art. 10 pide capacidades de detección; GDPR art. 5 y 32 exigen control proporcional del tratamiento y seguridad. Si no hay registros adecuados sobre llamadas a herramientas, contexto utilizado, errores, escalados o acciones ejecutadas, cualquier revisión post-incidente será una reconstrucción casi literaria.

Quinta: ¿el diseño limita de verdad el acceso? Si el agente puede usar credenciales amplias o invocar herramientas sin una política granular, no hay control compensatorio elegante que tape ese agujero conceptual. La arquitectura manda.

La respuesta sensata no es parar la IA, sino dejar de desplegarla como si fuera una maqueta

Cuando aparece una vulnerabilidad en un componente de este tipo, suele haber dos reacciones igual de malas. La primera: minimizarlo porque “es solo un framework”. La segunda: sobreactuar y pedir congelar cualquier proyecto de agentes como si el problema fuera la existencia misma de la automatización. Ninguna de las dos sirve.

La respuesta seria consiste en tratar estos despliegues con el mismo rigor que ya se exige a otros sistemas con capacidad operativa. Eso implica, como mínimo, gestión de parches, revisión de configuraciones, pruebas sobre permisos y aislamiento, inventario de herramientas conectadas, limitación de secretos, logging útil y un procedimiento claro de rollback o desactivación. Nada revolucionario. Lo revolucionario, por lo visto, sigue siendo aplicar higiene básica a productos de IA antes de presumir de transformación.

También implica revisar si la organización está mezclando entornos de prueba y producción de forma imprudente. Un agente experimental puede ser perfectamente compatible con un programa de innovación serio si corre en un entorno segregado, con datos sintéticos o minimizados, herramientas simuladas y credenciales de alcance mínimo. El problema llega cuando el término “piloto” se utiliza como permiso cultural para conectar demasiado, documentar poco y gobernar menos.

Si estás bajo AI Act, todavía hay otra capa

No todo uso de agentes caerá en la categoría de alto riesgo del AI Act, y conviene no forzar ese encaje. Pero si el sistema se integra en un caso de uso que sí entre en el ámbito de sistemas de IA de alto riesgo, la conversación cambia de tono. Ya no se trata solo de ciberseguridad general o continuidad operativa, sino también de requisitos específicos de gestión de riesgos, gobernanza de datos, documentación técnica, registro de logs, transparencia, supervisión humana, robustez y ciberseguridad.

En ese terreno, la lógica de orquestación importa porque forma parte del comportamiento efectivo del sistema. No basta con evaluar el modelo aislado si la toma de decisiones o la producción de resultados depende de herramientas, memoria y reglas de ejecución. Aunque los detalles finales de implementación y guía práctica seguirán aterrizándose con estándares, la dirección de viaje es clara: si el sistema actúa de forma compuesta, la evaluación de control también debe ser compuesta.

Eso conecta con una idea que las organizaciones siguen intentando esquivar: la gobernanza de IA no puede separarse artificialmente de la gobernanza TIC, de terceros, de privacidad y de continuidad. Tener cuatro comités distintos que no se hablan entre sí es un método excelente para que nadie vea el riesgo completo hasta que lo publica otro.

Qué hacer ahora si tu equipo usa frameworks de agentes

Sin conocer el detalle técnico exacto del caso que originó la alerta, la reacción prudente no es inventar impacto, sino revisar exposición. Hay una secuencia razonable y bastante defendible ante auditoría o supervisión.

• Localiza despliegues reales. No solo repositorios o pruebas de laboratorio. Identifica qué aplicaciones en ejecución usan frameworks de agentes, qué entorno ocupan y qué conectores tienen activos.
• Revisa permisos. Comprueba qué credenciales utiliza cada herramienta conectada y si el alcance es estrictamente necesario. Si una tool puede leer o escribir más de lo imprescindible, recorta.
• Mapea datos. Determina si el agente procesa datos personales, datos confidenciales de negocio o información regulada. Si la respuesta es sí, enlaza la revisión con GDPR art. 25 y 32, y con tus controles internos de clasificación.
• Valida segmentación y aislamiento. Un fallo en la capa de orquestación no debería abrir acceso irrestricto a otros sistemas por simple proximidad de red o reutilización de secretos.
• Fortalece trazabilidad. Registra llamadas a herramientas, errores, cambios de estado y acciones relevantes de forma que permita investigación posterior sin invadir más datos de los necesarios.
• Confirma dependencia de terceros. Si el despliegue depende de cloud, APIs de modelo u otros servicios TIC, verifica que esa dependencia está recogida en tu marco de terceros y en tus evaluaciones de resiliencia.
• Prepara respuesta operativa. Si el componente requiere parche, actualización, mitigación o desactivación temporal, el equipo debe saber quién decide, con qué criterio y cómo se ejecuta sin improvisar.

Nada de esto exige inflar el riesgo con frases de apocalypse now. Exige disciplina. Y, sobre todo, exige aceptar que los sistemas agentic ya no pueden gestionarse como si fueran una extensión inocente del laboratorio de prompts.

La objeción habitual: “todavía no sabemos si el impacto es tan grave”

Correcto. Y precisamente por eso conviene hablar con precisión. Si no hay base técnica pública suficiente para afirmar una cadena de compromiso amplia, no debe afirmarse. Pero esa prudencia no rebaja la importancia del hallazgo. La eleva, porque obliga a mirar el diseño de control en lugar de refugiarse en una narrativa fácil.

En seguridad y cumplimiento, el error frecuente consiste en creer que solo deben revisarse a fondo los incidentes cuyo impacto ya se ha demostrado. Es al revés. Los hallazgos valiosos son los que revelan una clase de dependencia o de debilidad arquitectónica que la organización no estaba gobernando bien. Aunque el caso concreto termine teniendo impacto limitado, la pregunta útil es si el mismo patrón podría producir consecuencias mayores en un despliegue peor diseñado. Si la respuesta es sí, ya tienes trabajo por delante.

La regulación, por cierto, suele pensar igual. DORA no te pide reaccionar solo cuando el daño ya se ha materializado. Te pide construir resiliencia, documentar dependencias, detectar anomalías y corregir vulnerabilidades. NIS2 no espera a que el incidente te humille públicamente para exigir gestión de riesgos. GDPR tampoco premia la ignorancia voluntaria sobre cómo viajan los datos por tus herramientas conectadas.

La lección incómoda

La lección de fondo no va sobre LangGraph y ni siquiera va solo sobre IA. Va sobre una costumbre empresarial bastante resistente: introducir capas tecnológicas nuevas en procesos reales sin redibujar al mismo ritmo el perímetro de control. Luego, cuando aparece una vulnerabilidad, se descubre que nadie había decidido con claridad si aquello era un experimento, una aplicación interna, un servicio TIC relevante o un sistema con impacto regulatorio. Y mientras se discute la etiqueta, el riesgo ya está desplegado.

Lo sensato no es demonizar frameworks de agentes ni vender tranquilidad prefabricada. Lo sensato es reconocer que, cuando una herramienta coordina decisiones automatizadas, datos y acciones sobre otros sistemas, merece el mismo nivel de seriedad que cualquier otro componente operativo con capacidad de causar problemas reales.

Si tu entidad usa este tipo de frameworks, la pregunta no es si el titular de hoy será olvidado mañana. La pregunta es bastante menos periodística y mucho más útil: ¿sabes exactamente qué puede hacer tu agente, con qué permisos, sobre qué datos, apoyado en qué terceros y bajo qué controles? Si no puedes responder en una reunión de riesgo sin mirar tres chats, ya sabes por dónde empezar.