En el primer episodio de nuestra serie STRIVE sobre soberanía digital, Alex Zinin, de Commvault, y Max Mortillaro, de Osmium Data Group, cuestionaron uno de los mayores errores de concepto del sector: la soberanía digital no es una función que se pueda comprar, sino un problema empresarial que hay que entender antes de poder resolverlo.

Esta conversación retoma el hilo de la anterior. Esta vez, me he sentado a charlar con Thomas Maurer, Global Black Belt para Sovereign Cloud en la región EMEA de Microsoft, para ver qué pasa cuando una organización decide que la soberanía es importante. ¿Cómo pasan los equipos ejecutivos de las preocupaciones generales sobre la normativa, la jurisdicción o la incertidumbre geopolítica a tomar decisiones prácticas sobre la arquitectura?

Resulta que la respuesta casi nunca es tan sencilla como elegir un proveedor de cloud o seleccionar el modelo de implementación adecuado. Se trata de plantearse las preguntas adecuadas antes de tomar decisiones técnicas. Mira el episodio completo.

Puntos clave

• Cada organización define la soberanía digital de forma diferente, y ahí es precisamente donde debería empezar la conversación.
• La soberanía no se resuelve solo con tecnología. Las consideraciones legales, operativas, arquitectónicas y empresariales influyen todas en el resultado.
• Cloud Y las soluciones locales y en la nube no son estrategias que compitan entre sí. Para muchas empresas, el futuro pasa por una combinación bien pensada de ambas.
• Las decisiones sobre soberanía deberían basarse en la gestión de riesgos, no en el miedo.
• Una buena arquitectura empieza por entender las necesidades del negocio, no por elegir la infraestructura.

El concepto de soberanía tiene diferentes significados para cada organización

Una de las primeras observaciones que hizo Thomas fue también una de las más importantes. No existe una definición universal de soberanía digital. Para una organización, puede significar simplemente cumplir los requisitos normativos o mantener los datos dentro de una zona geográfica específica. Para otra, puede implicar independencia operativa, continuidad del negocio o prepararse para perturbaciones geopolíticas. Esa diferencia es importante porque cambia por completo el enfoque del debate.

Con demasiada frecuencia, las empresas dan por hecho que existe un modelo estándar de soberanía listo para ponerse en marcha. En realidad, el primer reto no es elegir la tecnología, sino entender qué problema está intentando resolver realmente la empresa. Solo entonces la arquitectura empieza a tener sentido.

La tecnología debe seguir a la estrategia

Un tema que no dejaba de surgir a lo largo de nuestro debate fue la tentación de lanzarse directamente al diseño técnico. Es comprensible. Los arquitectos suelen pensar, como es natural, en la infraestructura, las cargas de trabajo, la conectividad y los modelos de implementación. Pero Thomas destacó que los proyectos más exitosos empiezan por otro lado. Empiezan por escuchar.

¿Qué preocupaciones impulsan la iniciativa? ¿El objetivo es el cumplimiento normativo? ¿La continuidad del negocio? ¿La residencia de los datos? ¿El control operativo? ¿La protección frente a perturbaciones geopolíticas? Las diferentes respuestas dan lugar a diferentes arquitecturas. Puede que esto te parezca obvio, pero es sorprendente la frecuencia con la que las empresas empiezan a evaluar soluciones antes de ponerse de acuerdo sobre el resultado empresarial que quieren conseguir.

Avance: Empieza por el riesgo, no por las suposiciones

Uno de los momentos más prácticos de nuestra charla es cuando Thomas y yo hablamos de por qué las iniciativas de soberanía deberían empezar con una evaluación de riesgos, y no con un esquema arquitectónico.

Cada organización tiene una tolerancia al riesgo diferente. Un equipo de Fórmula 1, un organismo público y un fabricante internacional no tomarán las mismas decisiones, ni deberían hacerlo. La clave está en entender qué riesgos son los más importantes para tu negocio, qué concesiones estás dispuesto a hacer y, a continuación, diseñar una arquitectura que respalde esas decisiones.

Como señala Thomas, no hay una solución perfecta, solo concesiones bien fundamentadas. Cuanto antes adopten las organizaciones esa mentalidad, más sólida será su estrategia de soberanía.

«¿Cloud o o local?» No es la pregunta que hay que hacerse

Una de las partes más interesantes de la conversación cuestionó otra idea preconcebida muy extendida: que las organizaciones tengan que elegir entre una cloud a pública y una infraestructura privada. Thomas describió una realidad muy diferente. Muchas organizaciones no están sustituyendo una por la otra. Están diseñando entornos en los que las cargas de trabajo puedan moverse de una a otra en función de las necesidades del negocio, los requisitos normativos o cuestiones de resiliencia.

Esa flexibilidad cambia la forma en que debemos plantearnos la arquitectura. En lugar de preguntarnos si es mejor la nube o las instalaciones propias, la pregunta más útil pasa a ser: «¿Dónde pertenece esta carga de trabajo hoy en día? ¿Podría cambiar esa respuesta mañana?». Cuando la soberanía se integra en el proceso de diseño, la movilidad de las cargas de trabajo cobra tanta importancia como su ubicación.

La arquitectura es solo una parte de la ecuación

Otra idea que me llama la atención es el recordatorio de Thomas de que la arquitectura por sí sola no resuelve la cuestión de la soberanía.

• Los contratos son importantes.
• Los marcos legales son importantes.
• Los procesos operativos son importantes.
• Las personas que se encargan de gestionar el medio ambiente son importantes.

Ninguna de esas áreas puede funcionar por su cuenta. La soberanía exige que los equipos jurídicos, de seguridad, de cumplimiento normativo y de infraestructuras trabajen juntos desde el principio, en lugar de pasarse los proyectos unos a otros cuando las decisiones ya están tomadas. Es un patrón que te resultará familiar si trabajas en el ámbito de la ciberresiliencia. Los mejores resultados casi nunca los consiguen equipos por separado, sino aquellos que trabajan de forma coordinada.

El riesgo debería guiar cada decisión

Hacia el final de nuestro debate, la conversación derivó de forma natural hacia el riesgo. Para mí, es aquí donde la soberanía empieza a resultarme mucho más familiar. Todo proyecto de resiliencia comienza preguntándose qué es lo que la organización intenta proteger, qué amenazas son las más importantes y cuánto riesgo está dispuesta a aceptar.

Con la soberanía digital pasa lo mismo. En lugar de buscar una solución perfecta, las organizaciones deben identificar los casos concretos relacionados con la soberanía que les preocupan y, a continuación, determinar qué controles arquitectónicos, operativos o contractuales abordan mejor esos riesgos. Ese cambio —de comparar características a gestionar riesgos— es lo que, al final, te lleva a tomar mejores decisiones.

¿Por qué es importante esta conversación?

La soberanía digital sigue evolucionando rápidamente. Surgirán nuevas normativas. La tecnología cambiará. Las realidades geopolíticas seguirán transformándose. Eso significa que la soberanía no es algo que las organizaciones resuelvan de una vez por todas. Es algo que evalúan periódicamente a medida que van cambiando las prioridades empresariales y los riesgos externos.

Las organizaciones que tengan éxito no serán necesariamente las que tengan las arquitecturas más restrictivas. Serán las que tengan una visión más clara de sus objetivos empresariales, la disciplina necesaria para evaluar los riesgos con cuidado y la flexibilidad para adaptarse a medida que esos riesgos cambien. Al fin y al cabo, la soberanía digital no es algo que las organizaciones puedan comprar ya hecho. Se trata de entender los riesgos, gestionar las dependencias y tomar decisiones meditadas mucho antes de que esas decisiones se pongan a prueba.

Mira el episodio completo

En este episodio de STRIVE, Thomas y yo hablamos de:

• Por qué el concepto de soberanía tiene significados distintos para cada organización.
• Cómo deberían abordar los directivos la estrategia de soberanía.
• cloud público frente a cloud privado: y por qué a menudo no es una decisión de «o una cosa o la otra».
• Por qué la gestión de riesgos debería guiar las decisiones arquitectónicas.
• El papel de la resiliencia en la planificación de la soberanía moderna.

Ver ahora.

Preguntas frecuentes

P: ¿La soberanía digital significa tenerlo todo en tus propias instalaciones?

R: No. Muchas organizaciones adoptan enfoques híbridos que combinan las capacidades de « cloud » con requisitos específicos de soberanía.

P: ¿Por dónde deberían empezar los proyectos de soberanía?

R: Empieza por definir el problema empresarial y entender los riesgos que quieres mitigar antes de evaluar la tecnología.

P: ¿La soberanía es solo una cuestión técnica?

R: No. Requiere la colaboración entre los equipos de asuntos jurídicos, cumplimiento normativo, seguridad, operaciones y arquitectura.

P: ¿Qué relación hay entre la soberanía y la resiliencia?

R: Ambas disciplinas se centran en mantener la continuidad operativa reduciendo la exposición a riesgos que podrían afectar al negocio.

P: ¿Cuál es uno de los grandes errores que cometen las organizaciones en lo que respecta a la soberanía digital?

R: Lanzarse a tomar decisiones arquitectónicas antes de ponerse de acuerdo sobre qué significa la soberanía para su organización.

P: ¿Qué es lo primero que deberían preguntarse los directivos a la hora de planificar la soberanía digital?

R: «¿Qué problema estamos intentando resolver?» Todo lo demás se deriva de esa respuesta.

Darren Thomson es vicepresidente y director de tecnología para la región de EMEA en Commvault.

Durante años, la resiliencia cibernética se ha definido en función de la tecnología: controles de seguridad, capacidades de detección sofisticadas y estrategias de « backup » cada vez más sólidas, diseñadas para prevenir ataques o recuperarse más rápido. Esas inversiones siguen siendo esenciales, pero ya no bastan. La inteligencia artificial ha cambiado radicalmente la naturaleza de los ciberataques, que ahora se producen a una velocidad que supone un reto incluso para las organizaciones más consolidadas. A medida que el margen de tiempo entre la intrusión y la interrupción de la actividad empresarial sigue reduciéndose, la resiliencia ya no consiste tanto en prevenir todos los ataques como en mantener la empresa en funcionamiento cuando la prevención, inevitablemente, falla.

Ese cambio constituye el núcleo del nuevo informe de IDC, «Resilience Operations: The Discipline that Makes Readiness Provable» (Operaciones de resiliencia: la disciplina que hace demostrable la preparación). Basándose en una encuesta realizada a más de 500 organizaciones norteamericanas, el informe sostiene que la resiliencia se está convirtiendo en una disciplina operativa multifuncional que conecta las prioridades empresariales con la ciberseguridad, las operaciones de TI y la recuperación ante desastres. Y lo que es más importante, pone de manifiesto varias carencias que sugieren que muchas organizaciones siguen preparándose para un panorama de amenazas que ya no existe. Estas son las conclusiones más destacadas. 

La recuperación debería empezar por los resultados empresariales, no por los técnicos.

Históricamente, la planificación de la recuperación se ha centrado en restablecer la infraestructura lo antes posible, y el éxito se ha medido en función de los objetivos de tiempo de recuperación, las tasas de finalización de « backup » y la disponibilidad de las aplicaciones. Aunque esas medidas siguen siendo importantes, no responden necesariamente a la pregunta que más preocupa a los directivos: ¿Cuándo podremos volver a poner en marcha el negocio? 

IDC sostiene que la resiliencia debería basarse en los resultados empresariales más que en hitos técnicos: se trata de recuperar las capacidades que permiten a la organización atender a los clientes, generar ingresos y cumplir con sus obligaciones. Puede que esto suene a mera semántica, pero cambia la forma en que se establecen las prioridades de recuperación. La tecnología se convierte en un medio para alcanzar un fin, en lugar de ser un fin en sí misma. 

La mayoría de las organizaciones aún no han definido qué es lo más importante.

Casi 6 de cada 10 empresas aún no han definido del todo su negocio mínimo viable (MVB) , es decir, el conjunto más reducido de funciones, sistemas, procesos y datos necesarios para seguir funcionando tras una interrupción. 

Sin un entendimiento común de aquello de lo que realmente depende el negocio, cada paso que des durante la recuperación será una mera reacción. Si defines tu MVB antes de que se produzca una crisis, podrás tomar decisiones más rápidas, mejorar la coordinación durante la recuperación y, en última instancia, conseguir una organización más resiliente. 

La automatización se está convirtiendo en la línea divisoria entre la resiliencia y la deuda de recuperación.

Aunque los atacantes automatizan cada vez más el reconocimiento, la explotación y el movimiento lateral, muchas organizaciones siguen recurriendo a procesos de recuperación manuales. Ese desequilibrio es cada vez más difícil de ignorar. La IA está reduciendo los plazos de los ataques, pero los plazos de recuperación no han seguido el mismo ritmo. Las organizaciones que no logren automatizar estas tareas de recuperación pueden verse obligadas a dedicar días a elaborar y ejecutar planes, mientras que el daño ya se habrá producido. La gestión automatizada de la recuperación, la identificación clara de los puntos de recuperación y la validación coordinada se están convirtiendo en capacidades fundamentales para recuperarse a la velocidad que exigen los ataques actuales. 

La tecnología no es el mayor reto en materia de resiliencia; lo es la coordinación dentro de la organización.

Los equipos de seguridad se centran en la contención, los de infraestructura en la recuperación, los directivos en el impacto en los clientes y los de cumplimiento normativo en las obligaciones legales. Ninguna de estas prioridades es incorrecta en sí misma, pero cuando se desarrollan de forma independiente, las organizaciones se enfrentan a una crisis sin un modelo operativo común. 

Aquí entra en juego ResOps. En lugar de considerar la resiliencia como una responsabilidad del departamento de TI, el informe la plantea como una disciplina que aúna de forma deliberada los ámbitos empresarial, de seguridad, de infraestructura y de planificación de la recuperación. El mensaje es claro: la resiliencia depende menos de herramientas concretas que de establecer prioridades comunes antes de que un incidente te obligue a tomar decisiones difíciles. 

Las pruebas siguen siendo uno de los indicadores más sólidos de la resiliencia.

IDC ha descubierto que son relativamente pocas las organizaciones que realizan con frecuencia ejercicios de simulación o simulaciones en cibercampos de entrenamiento, a pesar de que desde hace décadas se ha demostrado que los ensayos mejoran sistemáticamente el rendimiento durante los incidentes reales. 

Los ejercicios sacan a la luz dependencias ocultas, ponen de manifiesto las deficiencias en la comunicación y permiten a los equipos tomar decisiones sin que ello tenga consecuencias reales. Las organizaciones que validan repetidamente sus procesos de recuperación desarrollan un nivel de confianza que va más allá de la mera planificación. 

Los retos de resiliencia del futuro ya se están perfilando. Te cuento…

El ransomware sigue acaparando los titulares, pero ya han surgido los próximos retos en materia de resiliencia: desde la IA con capacidad de acción y las identidades de máquina hasta la criptografía poscuántica. 

Estas amenazas nos recuerdan que la planificación de la resiliencia no puede centrarse solo en la infraestructura actual. La recuperación implica cada vez más servicios de « cloud », aplicaciones de « SaaS », modelos de IA, identidades de máquina, proveedores externos y ecosistemas digitales distribuidos que no existían hace una década. 

La resiliencia se está volviendo medible.

El modelo de madurez ResOps de IDC es una herramienta inestimable para evaluar la situación actual de tu organización. En lugar de considerar la resiliencia como algo que las organizaciones tienen o no tienen, este marco describe una evolución desde operaciones reactivas y aisladas hasta una resiliencia madura y adaptativa, basada en la gobernanza, la automatización y la mejora continua. Para mí, esa progresión reconoce una realidad importante: la resiliencia nunca está terminada. No se trata de adquirir una plataforma o de completar un proyecto. Las organizaciones se vuelven resilientes al mejorar continuamente la forma en que la tecnología, las personas y los procesos de negocio colaboran bajo presión. Visto desde esa perspectiva, la resiliencia se parece menos a un seguro y más a la excelencia operativa: una capacidad que se puede evaluar, reforzar y demostrar con el tiempo. 

Estamos viviendo un cambio más amplio en la forma en que las organizaciones ven la resiliencia.

Las conversaciones sobre resiliencia están pasando de centrarse en proteger la infraestructura a centrarse en proteger el propio negocio. Eso significa que la planificación de la recuperación empieza por los clientes en lugar de por los servidores, que la gobernanza cobra tanta importancia como la tecnología, y que la confianza se gana demostrando capacidades en lugar de documentando intenciones. ResOps no es realmente un marco nuevo; más bien, es un reconocimiento más amplio de que la ciberresiliencia se ha convertido en una disciplina operativa. A medida que los ataques se vuelven más rápidos y complejos, la resiliencia no se medirá por la ausencia de incidentes, sino por la capacidad de una organización para seguir prestando servicio a los clientes, apoyando a los empleados y manteniendo la confianza a pesar de las interrupciones. En definitiva, eso es lo que ResOps está diseñado para demostrar. Te lo cuento Rajiv Kottomtharayil es director de productos de Commvault. 

Puntos clave

• La confianza en la era de la IA no está desapareciendo, sino que está evolucionando.
• Las organizaciones deben verificar la IA de forma continua, en lugar de confiar en ella por defecto.
• La adopción de la IA debería empoderar a los empleados, no empujarlos hacia la «IA en la sombra».
• El modelo «zero trust» no consiste en desconfiar de la gente. Se trata de validar constantemente las identidades, los dispositivos y las acciones.
• Para que la IA se implemente de forma responsable, hace falta que la tecnología, la gobernanza y las personas trabajen juntas.

Cuando lanzamos «Ready. Or Not.», queríamos crear una serie que hiciera más fáciles de entender algunos de los debates más importantes de hoy en día sobre la IA. Al juntar al cómico Nathan Macintosh con expertos del sector, estamos explorando todo tipo de temas, desde la IA con capacidad de acción y la ciberresiliencia hasta la gestión de datos, y le echamos un poco de humor por el camino.

Si te has visto nuestro primer episodio sobre las oportunidades y los riesgos de la IA agente, creo que este también te va a gustar. Esta vez, vamos a hablar de un tema que está en el centro de todas las conversaciones sobre IA: la confianza.

Nathan se sienta a charlar con Diana Kelley, directora de seguridad de la información de Protect AI, para hablar sobre lo que significa confiar en la tecnología cuando la IA puede generar contenido falso muy convincente, tomar decisiones e incluso imitar a las personas. Desde los «deepfakes» y las alucinaciones hasta el modelo «zero trust» y la «IA en la sombra», exploran cómo las organizaciones pueden adoptar la IA sin perder la confianza en su personal y sus sistemas.

Mira el episodio completo en Readiverse. Este episodio me ha dejado con una sensación de optimismo mayor de lo que esperaba. No porque la IA sea de repente más fiable, sino porque Diana nos muestra que la confianza crece cuando las organizaciones ponen en marcha las políticas, las medidas de seguridad y la tecnología adecuadas. Aquí tienes algunos temas de la conversación que te harán ver la IA desde una nueva perspectiva.

La confianza y la tecnología pueden coexistir

Diana cree que la confianza es posible en la era de la IA, pero que tendrá un aspecto diferente. Siempre hemos construido la confianza a través de las relaciones con las personas. Ahora, estamos aprendiendo a extender esa confianza a los sistemas. Eso no significa confiar ciegamente en la tecnología. Significa entender cómo funciona la IA, reconocer sus limitaciones y establecer las medidas de seguridad adecuadas para que las personas y la tecnología puedan trabajar juntas con confianza.

«La confianza tiene que adaptarse al nuevo mundo». Te lo cuento – Diana Kelley

Lo que más me llamó la atención fue la idea de que la confianza y la tecnología no tienen por qué estar reñidas. Con el enfoque adecuado, pueden reforzarse mutuamente.

Cada vez sabemos más sobre la IA

Los «deepfakes» se han convertido en uno de los riesgos de la IA más comentados, y es fácil entender por qué. La IA ya es capaz de generar voces, imágenes y vídeos convincentes que nos hacen cuestionar qué es real. Pero Diana señaló que, aunque la IA es cada vez más sofisticada, las personas también se están volviendo más inteligentes. Somos más propensos a sospechar de una llamada inesperada, a examinar con más detenimiento una publicación en las redes sociales o a detenernos ante algo que no nos cuadra del todo.

Las organizaciones también se están volviendo más avispadas. A medida que la IA mejora en su capacidad para suplantar identidades, las empresas están invirtiendo en nuevas formas de verificar continuamente las identidades y validar la información. Mi conclusión es esta: la tecnología seguirá mejorando, pero también lo hará nuestra capacidad para reconocerla y responder de forma responsable.

«¿Es hoy un buen día para hacer un deepfake?» – Nathan Macintosh

Una IA responsable es buena para los negocios

Diana puso un ejemplo que probablemente les resultará familiar a muchas empresas. Una empleada a la que ella llama «Karen, de Finanzas», empieza a usar la IA porque le ayuda a terminar una tarea en minutos en lugar de horas. Karen no está intentando saltarse la política de la empresa, sino que solo quiere ser más productiva.

Los empleados usan la IA porque ven que realmente les aporta valor, y eso supone una oportunidad para las empresas. Cuando los empleados tienen acceso a herramientas de IA autorizadas, respaldadas por políticas claras y consejos prácticos, pueden trabajar de forma más eficiente y, al mismo tiempo, ayudar a proteger los datos y los sistemas de la empresa.

Avance: Una adopción más inteligente de la IA

El objetivo no es impedir que los empleados usen la IA, sino asegurarnos de que la usen como es debido. Diana explica cómo las empresas pueden fomentar el uso de la IA sin generar riesgos innecesarios.

El modelo «Zero Trust» es más importante que nunca

«Cuando entiendes cómo funcionan las cosas, es cuando empiezas a entender cómo gestionarlas». – Diana Kelley

El «cero confianza» es uno de esos conceptos que resultan mucho más fáciles de entender con una analogía. Diana tiene una estupenda. Lo describe como desplazarse por un edificio. El hecho de que te hayan permitido entrar por la puerta principal no significa que todas las demás puertas se te abran automáticamente. Cada vez que accedes a una nueva habitación, hay otra rápida comprobación para confirmar que debes estar allí.

Así es, en esencia, como funciona el «cero confianza». En lugar de dar por hecho que una persona o un dispositivo son de fiar tras un único inicio de sesión, las empresas verifican constantemente las identidades, los dispositivos y las acciones a medida que la tecnología está cada vez más conectada. La mayoría de esas comprobaciones se hacen de forma discreta, entre bastidores. Una de las cosas que me gustó de la explicación de Diana es que el «zero trust» no parece otra de esas palabras de moda en materia de seguridad. Me parece una forma práctica de plantearse la confianza en un mundo en el que la IA y las identidades digitales se están convirtiendo en parte del día a día de las empresas.

La confianza tiene que ver con las personas

Al fin y al cabo, la tecnología no genera confianza, sino las personas. Son las personas las que definen las políticas, los procesos y los límites éticos que rigen el uso de la IA, mientras que la tecnología ayuda a comprobar que esas medidas de seguridad funcionan como se espera. Es esa colaboración entre las personas y la tecnología la que hace posible una IA responsable.

La confianza va más allá de nuestras propias organizaciones. Las empresas necesitan confiar en los socios con los que trabajan, en los sistemas a los que se conectan y en las tecnologías que adoptan. Por eso, la transparencia, las normas comunes y la verificación continua están cobrando tanta importancia como la propia innovación. Cuanto más se integra la IA en el día a día de las empresas, más se convierte la confianza en una responsabilidad de todos.

Mirando hacia el futuro

La IA seguirá evolucionando, y también lo hará la forma en que interactuamos con ella. Las organizaciones que tengan éxito no serán las que confíen ciegamente en la IA ni las que la eviten por completo. Serán aquellas que establezcan políticas sólidas, adopten las tecnologías adecuadas y verifiquen continuamente los sistemas en los que confían.

La confianza no es algo que perdamos a medida que avanza la tecnología. Es algo que construimos y desarrollamos de forma intencionada. Ese es precisamente el tipo de conversación que esperamos continuar en cada episodio de Ready. Or Not. Mira el episodio completo en Readiverse.

Preguntas frecuentes

P: ¿Qué es la confianza digital?

R: La confianza digital es la seguridad de que las personas, los sistemas y las organizaciones son quienes dicen ser y actúan de la forma esperada y segura. Combina tecnología, gobernanza y verificación para ayudar a las organizaciones a interactuar de forma segura.

P: ¿Qué son los deepfakes?

R: Los deepfakes son imágenes, vídeos o grabaciones de audio generados por IA y diseñados para imitar fielmente a personas reales. Aunque tienen usos legítimos, también se pueden utilizar para suplantar la identidad de otras personas o cometer fraudes.

P: ¿Qué es el «zero trust»?

R: El modelo «zero trust» es un modelo de seguridad basado en la verificación continua, en lugar de en la confianza automática. En lugar de dar por hecho que un usuario o un dispositivo es de fiar tras un único inicio de sesión, las empresas validan constantemente las identidades y las acciones.

P: ¿Qué es la IA en la sombra?

R: El término «Shadow AI» se refiere al uso que hacen los empleados de herramientas de IA que no han sido aprobadas ni reguladas por su organización. Aunque a menudo se hace con buena intención, puede suponer riesgos para la seguridad, la privacidad y el cumplimiento normativo.

P: ¿Por qué las empresas no deberían limitarse a bloquear las herramientas de IA?

R: Los empleados suelen usar la IA porque les ayuda a trabajar de forma más eficiente. En lugar de prohibir la IA por completo, las empresas deberían ofrecer herramientas autorizadas, establecer políticas claras y formar a los empleados para que la usen de forma responsable.

P: ¿Cuál es la idea principal de este episodio?

R: La confianza no está desapareciendo por culpa de la IA, sino que está evolucionando. Las organizaciones que combinen personas, políticas y tecnología con una verificación continua estarán mejor preparadas para adoptar la IA con confianza y de forma responsable.

Katherine Demacopoulos es directora sénior de Estrategia y Programas de Contenidos Globales en Commvault.

Nuestro director de productos, Rajiv Kottomtharayil, escribió hace poco sobre un gran cambio que se está produciendo en todos los sectores. Los modelos de IA de vanguardia están reduciendo el tiempo que transcurre entre el descubrimiento de una vulnerabilidad y su explotación. Este cambio está llevando a las organizaciones de todo el mundo a replantearse sus procesos de gestión de vulnerabilidades. En Commvault estamos haciendo lo mismo. Por eso, a partir del 11 de agosto, vamos a cambiar el ritmo con el que divulgamos las vulnerabilidades. Qué va a cambiar Estamos subiendo el listón en materia de seguridad, transparencia y confianza de los clientes. El 11 de agosto, y a partir de entonces el segundo martes de cada mes, lanzamos los «Patch Tuesdays»: una publicación mensual programada en la que compartimos avisos de seguridad y parches para vulnerabilidades.  

Los «Patch Tuesdays» son un sello distintivo de las empresas tecnológicas líderes, ya que proporcionan a los clientes un ritmo de seguridad predecible. Esto cobra aún más importancia a medida que se acelera el ritmo de descubrimiento de vulnerabilidades. Por supuesto, si surge una vulnerabilidad urgente que deba notificarse fuera de ciclo, no dudaremos en seguir nuestros procesos bien establecidos.  

Dónde puedes encontrar recursos actualizados  

El segundo martes de cada mes, encontrarás información nueva sobre los CVE en nuestra página de avisos de seguridad. También puedes consultar las publicaciones oficiales en el sitio web de CVE de MITRE. En el Centro de Seguridad de Commvault encontrarás nuestro programa de gestión de vulnerabilidades y otros contenidos de liderazgo intelectual sobre «seguridad desde el diseño».   

Para ver las certificaciones de cumplimiento, los informes de auditoría y la documentación sobre cómo Commvault protege los datos de los clientes, visite el Centro de confianza de Commvault. Puede suscribirse a las actualizaciones del Centro de confianza a través del enlace que hay en la esquina superior derecha de la página. Bill O’Connell es director de seguridad de Commvault. 

Desde hace décadas, los líderes tecnológicos llevan intentando acabar con los silos. Se han diseñado programas de modernización completos centrados en conectar aplicaciones, consolidar plataformas y ofrecer a las organizaciones una visión más completa de sus datos. Esos esfuerzos han aportado un valor enorme, pero también han marcado nuestra forma de ver la resiliencia. Cuando algo sale mal, instintivamente buscamos la fragmentación técnica. Sin embargo, nos hemos dado cuenta de que el mayor reto está en otra parte.

Los silos más importantes que afectan hoy en día a la ciberresiliencia no están en las bases de datos ni en las aplicaciones, sino en las estructuras organizativas. Se dan entre los equipos de seguridad y de infraestructura, entre TI y el negocio, y entre las personas encargadas de responder a un ataque y las que se ocupan de que la organización siga funcionando.

El último estudio de IDC sobre ResOps, «Resilience Operations: The Discipline that Makes Readiness Provable» (Operaciones de resiliencia: la disciplina que permite demostrar la preparación), sugiere que estas barreras organizativas se han convertido en uno de los principales obstáculos para una recuperación eficaz. Es una observación muy oportuna, ya que los ciberataques han evolucionado de tal manera que cada vez resulta más difícil mantener esas barreras.

Los ataques modernos no siguen tu organigrama

Un ciberataque moderno casi nunca afecta solo a un ámbito tecnológico. Un incidente de ransomware puede empezar con identidades comprometidas, extenderse por toda la infraestructura de « cloud », cifrar cargas de trabajo críticas, interrumpir aplicaciones de cara al cliente, afectar a servicios de terceros y activar requisitos de notificación reglamentaria, todo ello en cuestión de horas. Cada fase implica equipos distintos, herramientas diferentes y prioridades distintas. Sin embargo, muchas organizaciones siguen preparándose para la recuperación como si estas responsabilidades pudieran gestionarse por separado.

Los equipos de seguridad se centran, naturalmente, en contener las amenazas y preservar las pruebas. Los equipos de infraestructura dan prioridad a restaurar los sistemas y minimizar el tiempo de inactividad. Los responsables empresariales se concentran en los clientes, los ingresos y la continuidad operativa. Los equipos de comunicación piensan en la reputación, mientras que los equipos jurídicos y de cumplimiento normativo se centran en las obligaciones reglamentarias. Cada punto de vista es totalmente razonable. El problema surge cuando esas prioridades nunca se han conciliado antes de que ocurra un incidente.

En plena crisis, Recovery exige tomar decisiones bajo presión. ¿Qué aplicaciones deben volver a funcionar primero? ¿Qué datos pueden restaurarse de forma segura? ¿Qué nivel de riesgo es aceptable antes de reanudar los servicios al cliente? ¿Quién tiene la autoridad para tomar esas decisiones? Sin una buena coordinación, las organizaciones suelen darse cuenta de que los mayores retrasos no se deben a la tecnología, sino a la incertidumbre, ese tipo de incertidumbre que se podría mitigar con una mejor preparación.

La resiliencia empieza por una definición común de lo que realmente importa

El informe hace hincapié en establecer tu negocio mínimo viable (MVB). A primera vista, parece otro ejercicio más de planificación de la recuperación, pero su verdadero valor radica en las conversaciones que obliga a las organizaciones a mantener.

Para definir un MVB, los responsables de la empresa, los equipos de seguridad, los especialistas en infraestructura y los responsables de las aplicaciones tienen que ponerse de acuerdo en una pregunta que parece muy sencilla, pero que no lo es tanto: ¿Qué es lo que tiene que seguir funcionando sin falta si todo lo demás se para?

Ese debate cambia la naturaleza de la planificación de la resiliencia. Las prioridades de recuperación ya no las determina el responsable de la aplicación que argumente de forma más convincente durante un incidente. En su lugar, se establecen de antemano, se basan en los resultados empresariales y se apoyan en dependencias técnicas que todo el mundo entiende.

Quizá lo más importante es que el MVB crea un lenguaje común. Los líderes empresariales empiezan a hablar de capacidades críticas en lugar de sistemas individuales. Los equipos tecnológicos comienzan a relacionar la infraestructura con los resultados para los clientes, en lugar de con las arquitecturas técnicas. Los equipos de seguridad obtienen una mayor claridad sobre qué activos merecen los niveles más altos de protección durante Recovery. Esa visión común es precisamente lo que les ha faltado a muchas organizaciones.

La tecnología puede automatizar la recuperación, pero no puede crear alineación

El informe no sostiene que las organizaciones necesiten otra plataforma más. Sostiene que necesitan una forma de trabajar que alinee a las personas, los procesos y la tecnología en torno a un único objetivo operativo. Aquí es donde ResOps —una disciplina multifuncional— demuestra su valía.

La tecnología puede ayudar a automatizar la Recovery, pero no puede resolver desacuerdos sobre las prioridades empresariales. No puede decidir qué servicios al cliente son los más importantes. Y no puede sustituir a la gobernanza necesaria para coordinar múltiples equipos durante un incidente de alta presión. Esos son retos de liderazgo, y la mejor forma de abordarlos es dedicar tiempo a resolver juntos las cuestiones difíciles, mucho antes de que un ataque te obligue a tomar medidas.

Las organizaciones más sólidas no eliminan los silos, sino que los conectan

Los ciberataques seguirán evolucionando. La inteligencia artificial seguirá reduciendo los plazos de los ataques. Las nuevas tecnologías introducirán nuevas dependencias y, junto con ellas, surgirán nuevas amenazas. Nada de eso cambia el requisito fundamental de la resiliencia. Las organizaciones no se recuperan porque cada equipo por separado rinda a las mil maravillas, sino porque esos equipos ya saben cómo trabajar juntos.

Quizá esa sea, en definitiva, la conclusión más importante del estudio de IDC. La resiliencia no es simplemente el resultado de una tecnología mejor o de controles de seguridad más sofisticados. Es el resultado de prioridades compartidas, una gobernanza clara y un modelo operativo probado que reúne a las personas adecuadas antes de que se produzca un incidente. Vidya Shankaran es directora técnica de operaciones de Commvault.

Puntos clave

• Un CVE es un identificador único a nivel mundial para una vulnerabilidad de software que se ha hecho pública, lo que permite a los proveedores, investigadores y responsables de la seguridad referirse a ella de forma coherente.
• La forma en que una organización aborda la divulgación de vulnerabilidades —incluidas las correcciones coordinadas, la colaboración con los investigadores y un inventario preciso del software— es un indicador claro de su madurez general en materia de seguridad.
• Commvault protege a sus clientes con un programa de CVE basado en la transparencia, la regularidad y la claridad. La forma en que se divulgan los CVE dice mucho sobre la madurez de un programa de seguridad e ingeniería.

¿Por qué es importante esto?

Muchas brechas de seguridad que llegan hasta la junta directiva tienen su origen en vulnerabilidades del software. El sistema que usa todo el sector para nombrar y describir esas vulnerabilidades es el CVE(Common Vulnerabilities and Exposures). La forma en que un proveedor, o tu propia empresa, gestiona los CVE es uno de los indicadores más claros de la madurez en materia de seguridad.

Una empresa que divulga y reconoce a los investigadores de forma justa suele ser una empresa que se toma en serio la ingeniería que hay detrás. En este blog te explico cómo se crea un CVE, quién gestiona el sistema y qué diferencia a una divulgación ejemplar de una deficiente.

Más allá del CVE: por qué es importante la filosofía de la divulgación

Publicar un CVE es lo mínimo que hay que hacer. Lo que marca la diferencia es: la transparencia sobre la vulnerabilidad y el parche, los análisis y la aplicación de parches de forma regular, y una comunicación clara. Commvault considera la divulgación de vulnerabilidades como una disciplina de ingeniería y seguridad, más que como un mero trámite de cumplimiento normativo: establecemos una periodicidad para la revisión del código y la corrección de fallos, comunicamos la solución en un lenguaje sencillo y protegemos a nuestros clientes. Esa coherencia, más que cualquier puntuación concreta, es lo que la divulgación de CVE dice sobre la madurez en materia de seguridad.

¿Qué es realmente un CVE?

Un CVE no es un parche, una puntuación ni un programa malicioso. Es una entrada del diccionario que asigna a una vulnerabilidad concreta y conocida públicamente un nombre único y permanente para que todo el mundo pueda referirse a ella. El identificador en sí sigue un formato sencillo y duradero: las letras CVE, el año en que se asignó el identificador y un número de secuencia; por ejemplo, CVE-2021-44228.

La envergadura del programa es enorme y sigue creciendo: en 2025 se publicaron 48 000 CVE, lo que supone unas 132 al día, lo que representa un aumento de más del 260 % desde 2020.

La anatomía de un disco

Las publicaciones del CVE deben seguir un conjunto de elementos fijos. Leer una de ellas es muy sencillo una vez que sabes para qué sirve cada parte:

• Identificador: el código único CVE-AAAA-NNNNN
• Descripción: una explicación concisa de la vulnerabilidad: qué es y cómo podría aprovecharla alguien con malas intenciones.
• Productos y versiones afectados: qué software, hardware o firmware (y qué versiones) se ven afectados, y qué versiones incluyen la corrección.
• Gravedad: la categoría de gravedad subyacente.
• Referencias, enlaces al aviso del proveedor, al parche y a los artículos técnicos.

Los protagonistas secundarios: CVSS, CWE, EPSS y KEV

Hay cuatro sistemas complementarios que convierten un CVE en algo a lo que una empresa puede dar prioridad. Es fácil confundirlos, así que vale la pena tener clara la diferencia:

• El CVSS (Sistema Común de Puntuación de Vulnerabilidades) responde a la pregunta «¿Qué gravedad tiene?». El CVSS es la puntuación de gravedad (del 1 al 10, siendo 10 la más grave) de la vulnerabilidad, no una medida de tu exposición concreta.
• El EPSS (Exploit Prediction Scoring System) responde a la pregunta: «¿Qué probabilidades hay de que esto se aproveche pronto?». El EPSS genera una puntuación de probabilidad, del 0 al 100 %, que estima la probabilidad de que una vulnerabilidad se aproveche en los próximos 30 días.
• El CWE (Common Weakness Enumeration) responde a la pregunta: «¿Qué tipo de error lo ha provocado?». El CWE clasifica la deficiencia de programación subyacente.
• KEV (vulnerabilidades conocidas y explotadas) responde a la pregunta: «¿Se está usando contra la gente ahora mismo?». El catálogo KEV es una lista seleccionada de CVE con casos confirmados de explotación en el mundo real.

Una puntuación alta en el CVSS te indica la gravedad que podría tener una vulnerabilidad; una puntuación alta en el EPSS te indica la rapidez con la que es probable que se aproveche; y aparecer en el catálogo KEV confirma que ya se está aprovechando. Los mejores programas de gestión de vulnerabilidades tienen en cuenta estos tres factores.

Preguntas frecuentes

P: ¿Qué es un CVE y por qué es importante? R: Un «Common Vulnerability and Exposure» (CVE) es un identificador estandarizado que se asigna a una vulnerabilidad de software que se ha hecho pública. Permite que todo el mundo —desde proveedores e investigadores hasta organismos reguladores y clientes— se refiera a la misma vulnerabilidad sin ambigüedades.

P: ¿Qué información debe contener un registro CVE bien estructurado?
R: Un registro CVE completo requiere un identificador único, una descripción de la vulnerabilidad, los productos y versiones afectados, el tipo de gravedad y referencias a avisos o parches del proveedor. Estos elementos permiten a las organizaciones comprender su exposición y responder de manera eficiente.

P: ¿En qué se diferencian CVSS, CWE, EPSS y KEV de un CVE? R: Un CVE identifica una vulnerabilidad concreta, mientras que CVSS mide su gravedad, EPSS estima la probabilidad de que se aproveche a corto plazo, CWE clasifica la deficiencia de programación subyacente y KEV identifica las vulnerabilidades que se están aprovechando activamente en el mundo real. Juntos, estos marcos ayudan a proporcionar el contexto necesario para priorizar las medidas correctivas.

P: ¿Qué es lo que busca Commvault en sus propias prácticas de divulgación? R: Commvault aplica a sus propias divulgaciones los mismos criterios que espera de los demás: transparencia, periodicidad y claridad. Así es como Commvault protege a sus clientes.

P: ¿Qué deben tener en cuenta los líderes empresariales a la hora de evaluar las prácticas de gestión de vulnerabilidades de los proveedores? R: Los líderes deben fijarse en que haya plazos de divulgación coordinados, registros CVE completos y precisos, directrices claras para la corrección de vulnerabilidades, programas de notificación sólidos y la capacidad de determinar rápidamente si los productos se ven afectados por vulnerabilidades recién reveladas. Estas características reflejan una cultura de seguridad sólida y mejoran la resiliencia de la organización. Werner Nel es director de Experiencia de Producto en Commvault.

Puntos Clave

• JadePuffer es el nombre que los investigadores de seguridad de Sysdig le han dado a lo que, según su evaluación, es la primera operación de ransomware documentada dirigida de principio a fin por un agente de IA autónomo, y no por una persona que utilice un conjunto de herramientas.
• Las técnicas en sí no eran nuevas. Lo que cambió fue la velocidad de ejecución: el agente encadenó operaciones de reconocimiento, robo de credenciales, movimiento lateral y cifrado destructivo, corrigiendo un intento fallido de inicio de sesión en 31 segundos.
• El agente generó su propia clave de cifrado y nunca la guardó ni la transmitió. Pagar el rescate no habría permitido recuperar los datos.
• El daño real afectó al estado de la configuración y a los sistemas del plano de control, no solo a los archivos, que es precisamente la capa que la mayoría de los planes de recuperación no cubren.
• Recuperarse de un ataque como este significa demostrar que la empresa puede reanudar sus operaciones de forma segura, no solo restaurar un backup.

¿Qué pasó?

A mediados de 2026, los investigadores de seguridad de Sysdig documentaron una campaña de extorsión que, según ellos, es la primera de este tipo: una operación de ransomware llevada a cabo de principio a fin por un agente basado en un modelo de lenguaje grande, con una intervención humana mínima. La llamaron JadePuffer.

El punto de entrada te sonaba. El atacante aprovechó el CVE-2025-3248, una vulnerabilidad de ejecución remota de código sin autenticación en Langflow —un marco de código abierto para crear flujos de trabajo de agentes de IA— que ejecutaba una versión anterior a la 1.3.0. A partir de ahí, el agente enumeró el host, buscó credenciales en proveedores de « cloud », proveedores de modelos de IA y bases de datos, y descargó discretamente la propia base de datos de respaldo de platform.

Lo que ocurrió a continuación es lo que merece especial atención. El agente escaneó la red interna, encontró un almacén de objetos expuesto y extrajo los archivos de estado y configuración de Terraform. Configuró una tarea programada para comunicarse con su base cada 30 minutos. A continuación, se trasladó a un sistema de producción independiente que ejecutaba MySQL y Alibaba Nacos, una plataforma de configuración y descubrimiento de servicios habitual en arquitecturas de microservicios.

Una vez dentro, el agente intentó crear una cuenta de administrador en Nacos. Falló. Treinta y un segundos después, ya había detectado el fallo y lo había solucionado con un método diferente. A continuación, utilizó las funciones de gestión de archivos de MySQL para comprobar si podía seguir avanzando, antes de cifrar más de 1.300 registros de configuración, eliminar las tablas originales y dejar una nota de rescate.

La clave de cifrado se generó sobre la marcha, se mostró una sola vez y nunca se guardó en ningún sitio donde el atacante pudiera recuperarla. Tanto si fue a propósito como si no, el resultado para la víctima es el mismo: no había forma de volver atrás ni a través del atacante ni con una clave de descifrado, se pagara el rescate o no. La recuperación dependería de copias de seguridad limpias, de reconstruir el sistema o de puntos de recuperación validados.

¿Por qué los investigadores lo llaman «agéntico»?

Ninguna de las técnicas que se mencionan aquí es nueva. Aprovechar un CVE sin parchear, robar credenciales, buscar oportunidades de movimiento lateral, cifrar datos para extorsionar: los equipos de seguridad ya han visto todo esto antes. Lo que hizo que Sysdig clasificara al operador como «agente» en lugar de como un atacante convencional es cómo encajan todos los pasos entre sí.

El agente no seguía un guion fijo. Analizaba los resultados y se adaptaba. Cuando esperaba una respuesta JSON y recibía XML, cambiaba de estrategia y seguía adelante. Cuando falló su primer intento de crear una cuenta de administrador, identificó el error concreto y probó otra cosa, todo ello en menos de un minuto.

Los investigadores también encontraron comentarios integrados en las cargas útiles, en los que se explicaban los objetivos y los siguientes pasos en un lenguaje sencillo, un patrón que encaja más con el razonamiento de un modelo de lenguaje grande (LLM) al realizar una tarea que con el de un humano que copia y pega un kit de exploits conocido. Las informaciones públicas no han confirmado qué modelo o « platform » estuvo detrás del ataque. Lo que sí está claro es el comportamiento: algo que razonó, actuó, se topó con un obstáculo y corrigió el rumbo más rápido de lo que tarda la mayoría de las respuestas a incidentes llevadas a cabo por personas.

El problema de la recuperación que muchos marcos de trabajo siguen sin abordar

La mayoría de las estrategias de los programas de ransomware se basan en una suposición concreta: algo ha cifrado tus archivos, y la cuestión es si puedes recuperar una copia de seguridad limpia backup o si tienes que negociar una clave de descifrado.

JadePuffer rompe esa suposición de dos maneras. En primer lugar, no había ninguna clave de descifrado por la que negociar. En segundo lugar, el daño no se limitaba a los datos. Afectaba a la capa de configuración y al plano de control subyacentes a los datos: la plataforma de descubrimiento de servicios, los secretos que contenía, el estado de Terraform que describía cómo encajaba la infraestructura y las credenciales dispersas por todos los sistemas con los que el agente entró en contacto por el camino.

Ese es un problema de recuperación más complicado que «restaurar la base de datos». Una restauración limpia de archivos en un entorno con credenciales renovadas pero sin verificar, desviaciones de configuración sin revisar y una capa de identidad que nadie ha vuelto a auditar no es realmente una recuperación limpia. Es una copia nueva de los datos dentro de un sistema en el que todavía no se puede confiar.

Qué significa esto para tu estrategia de resiliencia

JadePuffer es un anticipo de la pregunta que, tarde o temprano, todo plan de recuperación tendrá que responder: ¿Se pueden reanudar las operaciones cuando un atacante ha afectado no solo a tus datos, sino también a la identidad, la configuración y los sistemas del plano de control de los que dependen esos datos?

Algunos puntos por donde empezar:

Trata los sistemas de configuración y del plano de control como elementos críticos para la Recovery, no solo las aplicaciones. Las plataformas de descubrimiento de servicios, los almacenes de secretos y el estado de la infraestructura como código son tan críticos para el negocio como las bases de datos que configuran. Si aún no figuran en tu plan de Recovery, esa es la primera laguna que debes subsanar.

Incorpora la gestión de credenciales en el proceso de recuperación, no después de este. Restaurar una carga de trabajo que vuelve a introducir claves comprometidas no pone fin al incidente; lo que hace es reiniciar el contador. Esta es la misma disciplina que Commvault aplica hoy en día a la infraestructura de identidades: evaluación de vulnerabilidades para detectar la exposición antes de que lo haga un atacante, auditoría en tiempo real para detectar los cambios en cuanto se producen y reversión para deshacer los cambios no autorizados sin tener que reconstruir todo desde cero.

Comprueba que todo está bien antes de restaurar, no después. Un punto de restauración solo sirve si sabes que está limpio. Esa es la lógica que hay detrás de Commvault® Cleanroom™: comprobar y validar los datos en un entorno aislado antes de que vuelvan a entrar en producción, en lugar de darte cuenta después de que se hayan vuelto a infectar.

Prepárate para un ataque al plano de control, no solo para un caso de cifrado de archivos. Un plan de recuperación diseñado únicamente para «archivos cifrados, restauración desde backup» no aguantará ante un incidente como este. La pregunta más útil, y la que está en el centro de ResOps (operaciones de resiliencia) como disciplina operativa, es qué hace falta para alcanzar un nivel mínimo de operatividad cuando son los sistemas que sustentan tus aplicaciones los que han sido atacados.

Nada de esto significa que haya que considerar la IA agentiva como una amenaza sin precedentes que exija empezar de cero. Lo que hay que hacer es aplicar la misma disciplina de resiliencia que ya se usa para la identidad y los datos, pero llevándola hasta la capa de configuración y del plano de control, que es donde ahora los ataques agentivos apuntan directamente. Descubre más sobre cómo Commvault aborda la resiliencia de la identidad y la validación de una recuperación limpia.

Preguntas frecuentes

P: ¿Qué es JadePuffer? R: JadePuffer es el nombre que Sysdig le dio a lo que consideró la primera campaña de ransomware documentada dirigida de principio a fin por un agente de IA autónomo, en lugar de por un atacante humano que utilizara manualmente un conjunto de herramientas.

P: ¿Usaron los atacantes algún modelo de IA concreto, como ChatGPT o Claude? R: Las informaciones publicadas no han confirmado qué modelo o « platform » se utilizó. El agente buscó claves API de varios proveedores de IA, lo que demuestra que había interés en ese tipo de acceso, pero no permite identificar qué fue lo que impulsó el ataque en sí. P: ¿Cómo empezó el ataque?

R: A través de CVE-2025-3248, una vulnerabilidad de ejecución remota de código sin autenticación en Langflow, un marco de trabajo de código abierto para agentes de IA, que afecta a las versiones anteriores a la 1.3.0. P: ¿Podría haber pagado la víctima el rescate para recuperar sus datos? R: No. La clave de cifrado se generó sobre la marcha y nunca se guardó ni se transmitió, así que no había ninguna clave que se pudiera recuperar, independientemente del pago.

P: ¿En qué se diferencia esto del ransomware típico? R: Las técnicas en sí no eran nuevas. Lo que llamó la atención fue la velocidad y la capacidad de adaptación: el agente detectó un intento fallido de inicio de sesión y lo corrigió en 31 segundos, un ritmo más cercano al de una máquina que al comportamiento típico de un atacante humano. P: ¿Qué deberían aprender de esto los equipos de seguridad y recuperación?

R: Esa planificación de la recuperación tiene que ir más allá de los datos de las aplicaciones y abarcar los almacenes de configuración, las plataformas de detección de servicios, los secretos y los sistemas de identidad, que es precisamente la capa a la que JadePuffer se dirigió para causar el máximo daño. Chris Bevil es director de marketing de cartera en Commvault.

Puntos clave

• Unos modelos avanzados de IA se escaparon de un entorno de evaluación restringido aprovechando unas vulnerabilidades que hasta entonces se desconocían.
• OpenAI dice que los modelos perseguían un objetivo que se les había asignado, sin actuar con mala intención, pero aun así provocaron un incidente de seguridad real.
• Los controles tradicionales, como el «sandboxing» y la segmentación, no bastan si la IA es capaz de encontrar vías inesperadas para sortearlos.
• La resiliencia cibernética se está volviendo tan importante como la prevención.

Todo empezó como una evaluación interna de las capacidades cibernéticas avanzadas basadas en la IA. Mientras intentaban resolver una prueba de rendimiento muy concreta, los modelos de OpenAI descubrieron una vulnerabilidad de día cero, se saltaron las restricciones previstas de su entorno de pruebas, aumentaron sus privilegios, se conectaron a Internet y comprometieron la infraestructura de Hugging Face. Consideraban las limitaciones técnicas que tenían a su alrededor como problemas que había que resolver.

Esto no fue un ciberataque tradicional

Hugging Face fue el primero en informar de que un marco de agentes autónomos de IA había comprometido parte de su infraestructura de producción. Un conjunto de datos malicioso aprovechó dos vías de ejecución de código en su proceso de procesamiento de datos, consiguió acceso a nivel de nodo, recopiló credenciales y se movió lateralmente por los clústeres internos.

Los modelos implicados, entre ellos el GPT-5.6 Sol y un modelo de prelanzamiento más potente, funcionaban con menos rechazos cibernéticos y sin los clasificadores habituales de producción. Fueron mucho más allá de lo que se les había encargado: aprovecharon una vulnerabilidad de proxy para conectarse a Internet y, a continuación, utilizaron credenciales robadas y vulnerabilidades de día cero para encontrar una vía de ejecución remota de código en los servidores de Hugging Face.

No era necesario que hubiera intención maliciosa

No hay indicios públicos de que los modelos desarrollaran una intención delictiva o decidieran perjudicar a Hugging Face. Tampoco les hacía falta. Si a un sistema capaz se le da un objetivo, herramientas, tiempo y retroalimentación, encontrará la forma de sortear los obstáculos. La conversación ya ha ido más allá de las preguntas y las respuestas erróneas. Se trata de sistemas capaces de investigar, poner a prueba hipótesis, descubrir vulnerabilidades hasta ahora desconocidas, utilizar credenciales robadas, ampliar privilegios y seguir funcionando cuando falla el primer intento.

Un «sandbox» no es un campo de fuerza

Nos referimos a los entornos como aislados, segmentados y en «sandbox», como si la propia etiqueta garantizara la seguridad. No es así. En este caso, se bloqueó la vía obvia de acceso a Internet, pero no se bloqueó un proxy de un paquete de software al que se podía acceder, y los modelos aprovecharon su vulnerabilidad para escapar. Las políticas y el comportamiento esperado no son suficientes. El propio entorno técnico debe hacer cumplir los límites.

Por qué esta es una historia de resiliencia

La actividad se desplazó desde un entorno de evaluación, pasando por la infraestructura de investigación de OpenAI, hacia Internet y, finalmente, al entorno de producción de Hugging Face. Se trata de un radio de impacto que se expande rápidamente. Cuando la IA puede explorar y actuar a la velocidad de una máquina, el tiempo que transcurre entre el acceso inicial y un compromiso más amplio puede seguir reduciéndose.

Hugging Face no se limitó a bloquear la vía de acceso original y dar el incidente por zanjado. Cerró las vías vulnerables de ejecución de código, reconstruyó los nodos comprometidos, renovó las credenciales y los tokens, y reforzó los controles del clúster. El objetivo no es solo restablecer un sistema, sino recuperar la confianza.

La pregunta ya no es solo: «¿Son seguros nuestros sistemas de IA?». Ahora es: «Cuando un potente sistema de IA descubre un camino que no sabíamos que existía, ¿podemos limitar el alcance del impacto, seguir con las operaciones críticas, reconstruir aquello en lo que ya no confiamos y demostrar que es seguro seguir adelante?». Chris Bevil es director de marketing de cartera en Commvault.

La seguridad no se limita a los sistemas propios de una organización. Las empresas modernas conectan una red cada vez mayor de aplicaciones de terceros a sus plataformas principales para facilitar las ventas, el servicio y la colaboración. Cada una de estas conexiones aporta valor. Pero cada una de ellas también supone un riesgo que la organización no controla por completo.

Ese riesgo no es hipotético. En junio de 2026, un atacante se hizo con los tokens OAuth vinculados a Klue, una e platform a de inteligencia competitiva que se usa para sincronizar datos de ventas y marketing con Salesforce. El atacante utilizó esos tokens para acceder a los entornos de Salesforce de muchas organizaciones que habían autorizado la integración, incluida Commvault.

En cuanto nos avisaron de un posible impacto, nuestro equipo de seguridad puso en marcha nuestro proceso de respuesta ante incidentes para averiguar qué había pasado, contener el riesgo y evaluar si la información de los clientes o los servicios de Commvault se habían visto afectados. Nuestra investigación reveló que la actividad se limitó a cierta información sobre relaciones comerciales y ventas almacenada en nuestro entorno de Salesforce. La investigación no encontró ningún indicio de que se viera afectado ningún dato de clientes backup , datos de productos, metadatos de productos, registros operativos o servicios de Commvault.

Actuar rápido cuando hace falta

Nuestra respuesta siguió los procedimientos establecidos para incidentes de seguridad, diseñados para contener el riesgo rápidamente y, al mismo tiempo, facilitar una investigación exhaustiva. En cuanto nos enteramos del incidente, desactivamos la integración con Klue, revocamos el acceso asociado y colaboramos con las partes pertinentes para llevar a cabo una evaluación completa de lo ocurrido. Durante toda la investigación, nuestros equipos se dedicaron a averiguar a qué información se había accedido, a comprobar que todo funcionaba bien y a confirmar que el incidente no había salido del ámbito que ya habíamos controlado.

Una tendencia que vale la pena destacar

Este incidente es un ejemplo reciente de una tendencia que los equipos de seguridad llevan varios años observando: los atacantes se centran en aplicaciones de terceros conectadas a los sistemas centrales de la empresa, en lugar de atacar esos sistemas directamente. Una sola integración comprometida puede ofrecer una vía de acceso de confianza a los entornos de muchas organizaciones relacionadas a la vez, a menudo con menos resistencia que un ataque directo a cualquiera de ellas.

Esto cambia el enfoque de dónde tiene que centrarse realmente la defensa de una organización. Sigue siendo necesario contar con controles internos sólidos, pero ya no bastan por sí solos. Tienen que ir acompañados de una supervisión activa de todas las aplicaciones a las que se conecta la organización, y de una capacidad de respuesta que esté lista antes de que se produzca un incidente, no que se cree en pleno incidente.

Fomentar la resiliencia más allá de nuestro propio entorno

En Commvault, nuestro programa de seguridad incluye una evaluación continua de las aplicaciones de terceros conectadas a nuestro entorno. Revisamos las aplicaciones conectadas con regularidad, evaluamos los permisos de acceso de cada una, vigilamos la aparición de nuevos riesgos y reevaluamos esas integraciones a medida que cambian las necesidades del negocio y el panorama de amenazas. Cuando las circunstancias lo requieren, tomamos medidas para reducir la exposición y reforzar nuestra postura de seguridad, lo que incluye desconectar las integraciones que ya no cumplen con nuestros estándares.

Nuestro compromiso con la transparencia

La confianza se construye a través de la transparencia y la responsabilidad. Cuando ocurre algo que afecta a nuestras partes interesadas, creemos que es importante comunicar lo que sabemos, explicar cómo hemos reaccionado y compartir el resultado de nuestra investigación, incluso cuando el suceso se haya originado fuera de nuestros propios sistemas. Seguiremos evaluando nuestros controles de seguridad, perfeccionando nuestros procesos de respuesta ante incidentes y reforzando nuestro enfoque respecto al riesgo de terceros, como parte de nuestro compromiso general de proteger a nuestros clientes y socios.

Para conocer los detalles oficiales de este incidente, incluido el alcance de la investigación y las recomendaciones para los clientes, echa un vistazo a las actualizaciones de nuestro Centro de confianza. Will Galway es subdirector de seguridad de la información (CISO) en Commvault.