Puntos clave

• ResOps no es un producto tecnológico. Se trata de una disciplina operativa multifuncional que contribuye a impulsar la ciberresiliencia de la organización.
• Complementa las funciones de copia de seguridad, recuperación ante desastres, ciberseguridad, continuidad del negocio y respuesta ante incidentes, alineándolas en torno a los resultados de Recovery de extremo a extremo.
• ResOps se centra en los servicios críticos y en los niveles de tolerancia al impacto definidos por la empresa, más que en componentes aislados de la infraestructura.
• Se basa en la generación continua de pruebas, incluidos resultados de Recovery contrastados, indicadores de resiliencia de los servicios y un registro propio de deficiencias.
• ResOps es un proceso continuo. Ni elaborar un plan ni llevar a cabo un ejercicio puntual con éxito son suficientes para establecer una capacidad de Recovery duradera.

El nuevo reto de la resiliencia

La mayoría de las organizaciones invierten en ciberseguridad, copias de seguridad, Recovery ante desastres y continuidad del negocio. Sin embargo, muchos ejecutivos siguen enfrentándose a tres preguntas fundamentales: ¿Podemos recuperarnos? ¿Cuánto tiempo tardará la recuperación? ¿Y podemos demostrarlo? Parte del reto radica en que la responsabilidad de la resiliencia se distribuye entre equipos que a menudo operan de forma aislada. El departamento de seguridad gestiona las amenazas. El departamento de TI mantiene los sistemas. Los equipos de Backup and Recovery restauran los datos y la infraestructura. Los equipos de continuidad del negocio se centran en mantener la organización en funcionamiento. Cada uno desempeña un papel importante, pero la responsabilidad de la recuperación puede seguir estando fragmentada.

ResOps aúna estas funciones en torno a prioridades compartidas, objetivos de Recovery y pruebas. El resultado es una forma más práctica de abordar la resiliencia: saber qué es lo más importante, comprender qué se necesita para recuperarlo, comprobar si Recovery funciona y actuar sobre las deficiencias que se detecten.

P: ¿Qué es ResOps?

ResOps es la disciplina operativa que aúna seguridad, infraestructura, operaciones de TI, continuidad del negocio y responsables de negocio en torno a los servicios críticos, el diseño resiliente y la validación continua. En pocas palabras, ResOps ayuda a los equipos a prepararse para las interrupciones, a recuperar los servicios críticos dentro de los límites de tolerancia al impacto definidos por la empresa y a demostrar, basándose en datos, que Recovery funciona.

Cuatro características definen a ResOps. Es:

1. Multifuncional por diseño. ResOps conecta responsabilidades distribuidas a través de un modelo operativo compartido, la asignación de responsabilidades y la gobernanza ejecutiva.
2. Centrado en los servicios críticos. Da prioridad a los servicios que la organización debe restablecer para aportar valor fundamental, atender a los clientes y generar ingresos; además de ayudar a cumplir con las obligaciones urgentes de carácter legal, normativo, de seguridad y de misión.
3. Validación continua. La resiliencia es una actitud que los equipos deben ejercer y mejorar, no un estado establecido mediante una prueba anual.
4. Se mide a través de pruebas. ResOps genera una puntuación de postura de resiliencia (RPS): una puntuación por servicio, respaldada por pruebas, que mide el grado de recuperabilidad de un servicio crítico concreto basándose en los resultados de la validación, el estado de las dependencias y la confianza en una recuperación sin incidencias.

¿Qué no es ResOps?

No es una categoría de productos.

Ninguna plataforma puede crear ResOps por sí sola. Las tecnologías de protección de datos, Recovery cibernético, automatización, observabilidad y pruebas pueden respaldar esta disciplina, pero ResOps es una cuestión organizativa. Depende de la gobernanza, la responsabilidad compartida, las prioridades empresariales, las prácticas operativas y un estándar común de evidencia.

No sustituye a Backup and Recovery, ni a la recuperación ante desastres.

ResOps no sustituye a unas sólidas capacidades de Backup and Recovery: depende de ellas. La copia de seguridad determina si existen copias recuperables. Recovery proporciona los procedimientos y las capacidades técnicas para ayudar a restaurar los sistemas y la infraestructura.

Pero ResOps plantea una pregunta más amplia: ¿Puede el servicio crítico volver a funcionar por completo, de forma limpia y dentro de los límites de tolerancia, incluyendo sus identidades, aplicaciones, datos, infraestructura, servicios en la nube, terceros, personas y procesos de toma de decisiones?

No es otro nombre para la continuidad del negocio ni para la respuesta a incidentes.

La continuidad del negocio define cómo opera la empresa ante una interrupción. La respuesta a incidentes detecta, contiene y gestiona el suceso. ResOps conecta esas disciplinas con el resultado de Recovery. Crea un ritmo operativo para que los equipos se pongan de acuerdo sobre lo que importa, validen Recovery en condiciones realistas, midan los resultados y aborden las deficiencias que revelan las pruebas.

No se trata de un ejercicio de cumplimiento normativo ni de un proyecto puntual.

Un programa maduro de ResOps puede ayudar a generar pruebas para consejos de administración, organismos reguladores, aseguradoras, clientes y auditores. Pero la documentación es un subproducto, no el objetivo. El objetivo es demostrar la capacidad de recuperación.

Y dado que los sistemas, las dependencias, las amenazas y las prioridades empresariales cambian constantemente, ResOps nunca está «terminado». Funciona de forma continua, al igual que la planificación financiera o las operaciones de seguridad.

¿Qué cambia con ResOps?

ResOps desplaza el enfoque de si los sistemas y procesos individuales funcionan a si el servicio crítico en su conjunto puede recuperarse. Eso cambia las preguntas que pueden plantearse los responsables.

Es importante que una copia de seguridad se realice con éxito. También lo es contar con un plan de recuperación. Pero ninguno de los dos te indica si un servicio crítico puede restaurarse realmente cuando lo necesites. ResOps analiza el panorama general:

• ¿Nos hemos recuperado a partir de un punto de recuperación limpio y verificado?
• ¿Cuánto tiempo ha tardado?
• ¿Nos hemos recuperado dentro de los límites establecidos por la empresa?
• ¿Y qué aspectos siguen requiriendo atención?

Por eso ResOps es importante. Ofrece a las organizaciones una forma de ir más allá de las suposiciones sobre la resiliencia para pasar a demostraciones programáticas y fiables de su capacidad de recuperación. Y lo hace mediante la generación continua de pruebas y la trazabilidad. Así, cuando se produce una interrupción, la cuestión no es si cada equipo hizo su parte o quién falló en qué tarea. Se trata de si la empresa puede restablecer los servicios críticos de los que dependen sus clientes.

Saber Más

Commvault ha publicado «ResOps: Una guía para ejecutivos» con el fin de ofrecer a los CISO, CIO y responsables de TI, seguridad, resiliencia y Risk un marco práctico para implementar ResOps en sus organizaciones.

Los responsables aprenderán a identificar los servicios más importantes, a validar la Readiness para la Recovery con pruebas reales y a poner a prueba la resiliencia de forma continua. Como resultado, las organizaciones pueden establecer un modelo operativo único que aúne a los responsables de seguridad, infraestructura, operaciones de TI y del negocio en torno a una capacidad de recuperación basada en pruebas.

Consigue la guía aquí. 

Preguntas frecuentes

P: ¿Es ResOps simplemente un nuevo nombre para la recuperación ante desastres?

R: No. La recuperación ante desastres es una parte esencial de ResOps, pero ResOps analiza el servicio crítico en su totalidad —incluidas las dependencias técnicas, de terceros, humanas y de toma de decisiones— y evalúa si puede recuperarse dentro de una tolerancia al impacto definida por la empresa.

P: ¿ResOps requiere la adquisición de una nueva plataforma?

R: No. La tecnología puede facilitar la cartografía, las pruebas, Recovery y la recopilación de pruebas, pero ResOps parte de la responsabilidad, la gobernanza, las prioridades empresariales y las prácticas operativas.

P: ¿Quién es el responsable de ResOps?

R: ResOps necesita un responsable designado con autoridad interfuncional y el respaldo de la dirección. Los responsables de cada servicio siguen siendo responsables de sus respectivos servicios, mientras que los equipos de seguridad, TI, continuidad del negocio y los equipos de negocio contribuyen al resultado común de la Recovery.

P: ¿Cómo se mide el éxito de ResOps?

R: El éxito se deriva de la evidencia actual de que los servicios críticos pueden recuperarse sin problemas dentro de sus tolerancias de impacto definidas, y no simplemente de completar un plan o ejecutar con éxito una tarea de copia de seguridad.

La puntuación de resiliencia (RPS) también es una herramienta de medición útil. Al tratarse de una puntuación por servicio respaldada por pruebas, la RPS ayuda a demostrar el grado de recuperabilidad de un servicio crítico concreto basándose en los resultados de validación, el estado de las dependencias y la confianza en una recuperación sin incidencias.

P: ¿Cómo pueden las organizaciones dar los primeros pasos con ResOps?

R: Empiece por identificar los servicios críticos de los que depende la empresa, quién es el responsable de cada uno, de qué dependen y con qué rapidez deben recuperarse. A partir de ahí, los equipos pueden validar Recovery, identificar las deficiencias y priorizar el trabajo necesario para reforzar la resiliencia.

Michael Thelander es director sénior de marketing de productos en Commvault.

Puntos clave

• La resiliencia depende de la rapidez y la seguridad con las que la empresa pueda recuperarse, y no solo de mantener a raya todas las amenazas.
• Convierta los planes de recuperación en pruebas: los resultados contrastados resultan más creíbles para los consejos de administración, los organismos reguladores y las aseguradoras que los objetivos o las suposiciones.
• Convierte ResOps en un modelo operativo compartido para los responsables de seguridad, infraestructura, continuidad del negocio y servicios.
• Mide lo que importa: los equipos deben saber si los servicios críticos pueden restablecerse, cuánto tiempo lleva realmente la Recovery y si pueden demostrarlo.
• Selecciona uno o dos servicios críticos, define qué se considera una Recovery satisfactoria, lleva a cabo un ejercicio realista y documenta los resultados.
• Veinte años al frente de la seguridad te enseñan una cosa desde el principio: el ataque que detuviste nunca llega a la reunión de la junta directiva. El que no detuviste es la única historia que todo el mundo recuerda. En algún momento dejé de evaluar a mi equipo por el número de ataques que absorbíamos por nuestra cuenta y empecé a evaluarnos también por la rapidez con la que nos recuperábamos.
• Por eso quiero que todos los CISO, CIO y miembros de la junta directiva que conozco lean este nuevo libro, *ResOps: An Executive Guide*. Lo ha patrocinado Commvault, pero lo recomendaría de todos modos.

El muro nunca fue el plan completo

Durante la mayor parte de mi carrera, mi trabajo consistió en construir muros más altos: mejor detección, controles más estrictos, respuesta más rápida. Ese trabajo sigue siendo importante, y siempre lo será. Pero un muro solo responde a una pregunta, y ya no es la que se plantea tu consejo de administración.

El pasado mes de septiembre, un ataque de ransomware obligó a Jaguar Land Rover a detener su producción a nivel mundial. Las líneas de montaje se pararon. Las cadenas de suministro se paralizaron. El Centro de Vigilancia Cibernética del Reino Unido estimó que el coste para la economía en general ascendió a aproximadamente 1.900 millones de libras, y JLR registró su producción mensual más baja en 73 años. JLR contaba con defensas. Lo que puso a prueba el incidente no fue si el muro aguantaba, sino si la empresa podía recuperarse una vez que este fallara.

Ya lo he dicho antes y seguiré diciéndolo: la interrupción no es una cuestión de «si», sino de «cuándo». Los CISO que duermen tranquilos por las noches no son aquellos que creen que pueden mantenerlo todo a raya; son aquellos que han practicado la recuperación tantas veces que la propia práctica es la que les da confianza.

Tres preguntas que le hago a mi propio equipo

El libro estructura todo el problema en tres preguntas, y he empezado a abrir cada revisión de resiliencia con ellas:

• Si nos atacaran esta noche, ¿podríamos recuperarnos?
• ¿Cuánto tiempo nos llevaría realmente?
• ¿Podemos demostrárselo, con pruebas, al consejo de administración?

La mayoría de las organizaciones responden a las dos primeras con un plan y a la tercera con silencio. Ese silencio es la brecha de resiliencia, y es mayor y más costosa de lo que la mayoría de los ejecutivos creen.

Pruebas, no promesas

He aquí una distinción que el libro plantea mejor de lo que la he oído en ningún otro sitio: un objetivo de tiempo de recuperación es una meta. Te indica a qué aspiras, pero no te dice si lo alcanzarás.

Compara «creemos que podemos recuperar el servicio de pagos en cuatro horas» con «lo restablecimos en 3,2 horas el último trimestre, a partir de un punto de recuperación limpio y verificado, con una tolerancia de cuatro horas». La primera frase es un plan. La segunda es una prueba. Solo una de ellas se sostiene cuando tu consejo de administración, tu organismo regulador o tu aseguradora cibernética empiecen a hacer preguntas más difíciles, cosa que sin duda harán.

A esta disciplina la llamamos ResOps, abreviatura de «operaciones de resiliencia». No es un producto que se compre ni una carpeta que se archive. Es un modelo operativo que conecta la seguridad, la infraestructura, la continuidad del negocio y a los responsables de negocio que dependen de estos servicios, y en el que todos trabajan a partir de la misma evidencia en lugar de planes separados.

Lo que debería preocupar a todo CISO

El libro también pone nombre a algo que llevaba tiempo intuyendo y para lo que por fin tengo palabras: la paradoja de la IA. La misma capacidad de IA que nos ayuda a encontrar vulnerabilidades más rápido está ayudando a los atacantes a acortar la brecha entre el descubrimiento y la explotación con la misma rapidez, quizá incluso más. Encontrar más problemas no te hace más seguro si no puedes recuperarte de los que logran colarse. La velocidad de detección nunca fue la meta. La capacidad de Recovery sí lo es.

Empieza por un servicio

Nada de esto requiere hacer algo imposible, y mentiría si dijera que mi propio equipo lo hizo bien a la primera. El libro propone una ruta de 90 días: elige uno o dos de tus servicios más críticos, define qué significa realmente «recuperado» para cada uno, lleva a cabo un ejercicio de Recovery honesto y obtén tu primera prueba real. Ese es un proyecto que cualquier equipo puede poner en marcha este trimestre, incluido el mío.

Pruebas antes que promesas. Readiness antes que perfección. Ese es el criterio que exijo a mi equipo, y es el criterio hacia el que este libro te ofrece un camino real.

Consigue aquí tu ejemplar de «ResOps: An Executive Guide».

Preguntas frecuentes

P: ¿Qué es ResOps?

R: ResOps, abreviatura de «operaciones de resiliencia», es un modelo operativo que conecta a los responsables de seguridad, infraestructura, continuidad del negocio y servicios en torno a prácticas de Recovery compartidas y basadas en pruebas.

P: ¿En qué se diferencia ResOps de la recuperación ante desastres tradicional?

R: La recuperación ante desastres tradicional suele centrarse en planes y objetivos técnicos. ResOps hace hincapié en la validación continua, la responsabilidad interfuncional y la prueba cuantificable de que los servicios críticos pueden restablecerse dentro de los límites de tolerancia del negocio.

P: ¿Por qué son importantes las pruebas de Recovery?

R: La evidencia de Recovery muestra lo que una organización ha probado y logrado realmente. Ayuda a que los consejos de administración, los organismos reguladores, las aseguradoras y los líderes empresariales tengan mayor confianza que si solo se basaran en planes u objetivos de recuperación.

P: ¿Qué deben medir las organizaciones en un programa de ResOps?

R: Las organizaciones deben medir si los servicios críticos pueden restablecerse, cuánto tiempo tarda realmente la Recovery, si los puntos de Recovery están limpios y verificados, y si los resultados cumplen con los límites de tolerancia definidos por la empresa.

P: ¿Quién debería participar en ResOps?

R: ResOps debe reunir a los responsables de seguridad, infraestructura, continuidad del negocio, aplicaciones y servicios, así como a los directivos implicados, para que las prioridades y las pruebas de Recovery reflejen las necesidades de la empresa.

P: ¿Cómo puede una organización ponerse en marcha con ResOps?

R: Empieza con uno o dos servicios críticos. Define qué significa una recuperación satisfactoria, lleva a cabo un ejercicio de Recovery realista, documenta los resultados y utiliza esa evidencia para mejorar la siguiente prueba.

Bill O’Connell es director de seguridad de Commvault.

Puntos clave 

• El aviso federal actualizado recoge las nuevas tácticas y técnicas de Medusa, así como más de 500 víctimas en sectores de infraestructuras críticas. 
• Los atacantes no solo se centran en los datos de producción, sino que también alteran las copias de seguridad, la gestión de identidades, la virtualización y otros sistemas de los que dependen las organizaciones para su Recovery. 
• El aviso insta a las organizaciones a demostrar su resiliencia mediante pruebas y validaciones frente a los comportamientos observados de los atacantes, y no a darla por sentada basándose únicamente en planes o en que las copias de seguridad se hayan realizado con éxito.  

El último aviso federal sobre el ransomware Medusa se actualizó por una razón: el adversario ha cambiado. 

El aviso federal actualizado, publicado el 18 de agosto de 2026 por el FBI, la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA) y el Departamento de Salud y Servicios Humanos de EE. UU. (HHS), describe a un adversario que recluta a nuevos intermediarios de acceso, actúa con mayor rapidez una vez dentro y se ha vuelto más hábil a la hora de asegurarse de que el daño que causa sea irreversible.  

El ataque no se dirige únicamente contra tus datos

Los autores de Medusa actúan con rapidez. Los investigadores informan de que han aprovechado vulnerabilidades recién anunciadas en menos de 24 horas y, en algunos casos, han utilizado exploits hasta una semana antes de que se hicieran públicas las vulnerabilidades.

Una vez dentro, se camuflan utilizando herramientas legítimas de gestión remota, el robo de credenciales y técnicas de «living-off-the-land». 

Pero el hallazgo más significativo del aviso es que Medusa ataca la propia ruta de recuperación.

El aviso asocia esta actividad a la técnica T1490 de MITRE ATT&CK, «Inhibir la recuperación del sistema». Documenta cómo el ransomware termina los servicios asociados a las copias de seguridad, la seguridad, las bases de datos, las comunicaciones, el intercambio de archivos y los sitios web. También elimina las copias de sombra y apaga y cifra de forma remota las máquinas virtuales. 

Si un atacante se centra deliberadamente en los sistemas, las identidades y la infraestructura que una organización podría necesitar para recuperarse, el problema va más allá de la protección de datos y se extiende a la ciberresiliencia y la ciberrecuperación. 

De ahí surge ResOps (Operaciones de Resiliencia)

ResOps no es otro nombre para las copias de seguridad. Es una disciplina operativa que aúna seguridad, TI, infraestructura, aplicaciones, operaciones y el negocio en torno a un único objetivo: mantener en funcionamiento los servicios críticos y recuperarlos en el plazo que la empresa pueda tolerar.

El informe de Medusa nunca utiliza el término ResOps, pero el concepto está presente. Recomienda a las organizaciones que pongan en práctica, prueben y validen sus programas de seguridad frente a los comportamientos observados de los atacantes, que adapten las tecnologías de seguridad a las técnicas de ataque, que las prueben a gran escala, que midan el rendimiento y que ajusten el personal, los procesos y las tecnologías basándose en las pruebas.

Una copia de seguridad no demuestra que esté libre de amenazas. Un objetivo de tiempo de recuperación en una hoja de cálculo no garantiza que la empresa vaya a estar operativa dentro de ese plazo. La resiliencia debe pasar de ser una suposición a basarse en pruebas. 

Empieza por el negocio, no por el servidor

La inclusión del HHS en el aviso hace que esto sea especialmente relevante para la sanidad, un sector que, según el FBI, ha sido un objetivo frecuente de Medusa. El debate sobre Recovery comienza con tres preguntas: 

• ¿Qué debe seguir funcionando y cómo es el funcionamiento mínimo viable? 

• ¿Qué identidades, aplicaciones, infraestructura y datos dan soporte a esos servicios? 

• ¿En qué puntos de recuperación podemos confiar y qué es lo primero que se restablece? 

En un hospital, dejar sin respuesta cualquiera de estas preguntas puede suponer un retraso en una intervención quirúrgica, que un farmacéutico no pueda verificar una dosis o que un médico no pueda confiar en un sistema de diagnóstico. Ningún equipo puede responder a todas estas preguntas por sí solo, y esa es precisamente la brecha que ResOps está diseñado para cerrar. 

Utiliza Medusa para poner a prueba tus hipótesis

Utiliza Medusa como caso de prueba para tus hipótesis de Recovery. ¿Puede un atacante acceder a los sistemas que respaldan la Recovery? ¿Qué ocurre si se ve comprometido Active Directory? ¿Puedes identificar un punto de Recovery limpio, restaurar los servicios críticos en el orden correcto y demostrar cuánto tiempo llevará? 

Los actores maliciosos se adaptan cuando los defensores se adaptan. Los programas de resiliencia deben funcionar de la misma manera: sometidos a pruebas continuas, validados continuamente y mejorados constantemente.

Porque en pleno incidente es un momento terrible para descubrir que el plan de Recovery parecía mejor sobre el papel de lo que funciona en la vida real. 

Preguntas frecuentes

P: ¿Qué es el ransomware Medusa? 

R: Medusa es una operación de «ransomware como servicio» identificada por primera vez en 2021. Sus desarrolladores y afiliados utilizan un modelo de doble extorsión: cifran los sistemas y amenazan con publicar los datos robados si no se paga el rescate. 

P: ¿Por qué se ha actualizado el aviso federal sobre Medusa? 

R: La actualización de agosto de 2026 incorpora hallazgos de investigaciones del FBI tan recientes como abril de 2026. Amplía las tácticas, técnicas y procedimientos documentados, las vulnerabilidades explotadas, la actividad de los afiliados y los indicadores de compromiso, al tiempo que añade información del HHS sobre ataques contra el sector sanitario. 

P: ¿Cómo amenaza Medusa las capacidades de Recovery de una organización? 

R: Medusa puede interrumpir los servicios relacionados con las copias de seguridad, la seguridad, las bases de datos, las comunicaciones y otras funciones críticas. También puede eliminar copias de sombra, alterar políticas relacionadas con la identidad y apagar o cifrar máquinas virtuales, lo que pone en riesgo el propio proceso de Recovery. 

P: ¿Qué deben hacer las organizaciones para reducir el riesgo que supone Medusa? 

R: Las organizaciones deben aplicar parches a las vulnerabilidades conocidas sin demora, segmentar las redes, restringir el acceso a los servicios remotos, reforzar la autenticación, supervisar los movimientos laterales y aplicar el principio del privilegio mínimo. Asimismo, deben mantener copias de recuperación independientes, fuera de línea, cifradas e inmutables, y probar periódicamente los flujos de trabajo de recuperación. 

P: ¿Qué es ResOps y en qué se diferencia de las copias de seguridad? 

R: ResOps, u operaciones de resiliencia, es una disciplina operativa multifuncional, no un producto de copia de seguridad. Coordina la seguridad, las TI, la infraestructura, las aplicaciones, las operaciones, la continuidad del negocio y los responsables de negocio en torno a la restauración de servicios críticos dentro del nivel de interrupción que la empresa puede tolerar. 

P: ¿Cómo puede una organización demostrar que está preparada para recuperarse? 

R: Empiece por los servicios críticos de la empresa, identifique las identidades, aplicaciones, infraestructura, datos, personas y terceros de los que dependen, y defina qué se considera una recuperación satisfactoria. A continuación, realice ejercicios realistas que identifiquen puntos de recuperación claros, restauren los servicios en el orden correcto, midan el tiempo de recuperación real y conviertan cualquier deficiencia en una lista de mejoras pendientes de su responsabilidad. Chris Bevil es director de marketing de cartera en Commvault. 

Key Takeaways 

• Roughly 1,200 supposedly isolated agents communicated through an unauthorized message board, and about 700 participated in Hugging Face-related activity. 
• Agents exchanged over 70,000 messages and files, combining discoveries across sessions meant to remain separate. 
• Investigators found agents spoofing tool calls and researching ways to alter evaluation transcripts to avoid detection by the grader.  
• Immutable, isolated backups alone are insufficient: Organizations need a validated, trustworthy recovery point before restoring to production. 

The forensic reports are finally here, and they changed the way I think about this incident. 

About a month ago, I wrote about the OpenAI and Hugging Face security incident because I thought it was something anyone responsible for cybersecurity, AI or business resilience should be watching.  

At the time, the story sounded fairly straightforward: An AI agent found a way outside the environment designed to contain it and ultimately reached Hugging Face. 

That is not really what happened. 

The Story Is Bigger Than One Rogue Agent 

The forensic reports reveal that about 1,200 agents, supposed to be operating in isolation, discovered a way to communicate through an unauthorized message board. They exchanged more than 70,000 messages and files, and roughly 700 agents participated in activity associated with Hugging Face. 

None of that was prompted or intended. The agents were persistent, they could share what they found, and they could combine effort across sessions that were supposed to have no contact with each other.  

Among the new details: GPT-5.6 Sol agents reproduced an exploit and copied private evaluation data into a public Hugging Face dataset, a concrete escalation beyond what initial reports described. 

The Reward-Hacking Problem 

The independent investigation conducted by METR and Redwood Research, published alongside OpenAI’s own report on August 26, found that agents researched ways to spoof, edit or delete portions of their own evaluation transcripts because they incorrectly believed the grader would inspect how they completed the task. Researchers found successful tool-call spoofing in about 7% of the transcripts they evaluated, though the manipulation they observed was small-scale. 

The finding is not that agents are “deceptive” in a human sense. It is that a sufficiently capable agent can search for ways around controls when those controls stand between it and the outcome it has been optimized to achieve. 

OpenAI calls the incident a “warning shot.” I think that is a fair description. 

What Happens When Containment Fails 

Most of the conversation about this incident will rightly focus on alignment, sandboxing and monitoring. But there’s a resilience question underneath it: If 700 agents can find a side door around containment, what’s the plan for when a single compromised workload does the same in your environment? 

OpenAI’s own conclusion points at the answer: Security architecture should assume an individual workload or compute node eventually can be compromised. That means air-gapped, immutable recovery data, and a way to validate what you’re restoring before it touches production again. 

But immutability alone does not prove the data was clean when it was captured. If the data was already compromised at the time of capture, immutability preserves the compromise just as faithfully as it preserves anything else. 

The practical version of that question is simple to ask and hard to answer: If this happened to us, could we prove which recovery point predates the compromise? 

We cover this operating model under ResOps (resilience operations) on the Readiverse. 

The Lesson for Every Organization 

OpenAI has since tightened workload and network isolation, expanded monitoring, and revised its model-development practices. The lesson applies beyond OpenAI: Contain the impact, preserve what you can trust, and prove you can recover before you need to. 

FAQs 

Q: What was the OpenAI-Hugging Face incident? 

During internal cybersecurity evaluations, OpenAI agents bypassed controls intended to isolate them, accessed the internet and reached third-party systems, including Hugging Face. The activity was driven primarily by an internal research model operating with reduced safeguards. 

Q: How did supposedly isolated agents communicate? 

A: They discovered an unauthorized message board in shared infrastructure. About 1,200 agents used it to exchange more than 70,000 messages and files, allowing information and tactics to carry across sessions that were designed to remain independent. 

Q: Were the agents instructed to attack Hugging Face? 

A: No. They were attempting to complete a difficult cybersecurity benchmark. When the intended route appeared blocked, some agents searched for alternative ways to achieve the evaluated outcome, and that activity expanded beyond the environment’s intended boundaries. 

Q: What does “reward hacking” mean in this context? 

A: Reward hacking occurs when an agent finds an unintended way to satisfy a metric or obtain a desired result without completing the task as intended. Investigators found agents researching ways to spoof tool calls and alter or delete portions of evaluation transcripts because they believed the grader might inspect their process. 

Q: Why are immutable backups not enough on their own? 

A: Immutability prevents stored data from being altered, but it does not prove the data was clean when it was captured. If a backup already contains compromised data, immutability preserves that compromise. Organizations therefore need isolated copies, trustworthy recovery points and validation before restoration. 

Q: What should organizations do differently after this incident? 

A: Strengthen workload and network isolation, restrict unnecessary internet and credential access, monitor agent behavior and escalation signals, and assume that prevention may fail. Pair those controls with air-gapped, immutable recovery data and a tested process for identifying and validating a clean recovery point. 

Chris Bevil is Principal Portfolio Marketing Manager at Commvault. 

Puntos clave

• La vigencia de los certificados se reducirá de 398 a 47 días para marzo de 2029, y la «reutilización de la validación de dominio» se reducirá a tan solo 10 días, lo que hará que la renovación manual quede obsoleta y que sea necesaria la gestión automática del ciclo de vida de los certificados (CLM).
• Ya se están llevando a cabo operaciones del tipo «Harvest Now, Decrypt Later» (recoger ahora, descifrar más tarde) para almacenar datos con una vida útil prolongada con vistas a su futuro descifrado mediante ordenadores cuánticos, lo que supone una amenaza inmediata para los datos confidenciales cifrados que se conservan a largo plazo.
• El inventario de certificados y claves criptográficas es lo más crucial que las empresas deben empezar a crear ahora mismo, ya que un inventario continuo y automatizado es el primer paso hacia la ciberresiliencia y la agilidad criptográfica a largo plazo.

El problema que se esconde tras bambalinas

La mayoría de las redes empresariales modernas se basan en una capa oculta compuesta por certificados digitales y criptografía que la mayoría de la gente nunca ve. Esta capa verifica la confianza de las máquinas y protege los flujos de datos, pero dado que las identidades de las máquinas superan ahora a las identidades humanas en una proporción de más de 80 a 1 en la empresa media, según el estudio de CyberArk sobre identidades de máquinas, puede resultar fácil subestimar la importancia de la capa criptográfica y de certificados.

Una forma útil de concebir un certificado digital es como una tarjeta de identificación para una máquina. Si la tarjeta es válida, las puertas se abren automáticamente y nadie le da importancia, pero en el momento en que la tarjeta caduca o está mal configurada, la puerta deja de abrirse, independientemente de lo legítima que sea la máquina que hay detrás. Un solo certificado caducado puede dejar inoperativos sitios web, interrumpir las API que permiten que las aplicaciones se comuniquen entre sí, interrumpir transacciones y provocar incumplimientos normativos, todo ello mientras se erosiona la confianza de los usuarios.

Durante años, las organizaciones han gestionado los certificados manualmente, pero dos cambios van a hacer que sea imposible seguir el ritmo de forma manual. En primer lugar, la vigencia máxima de los certificados públicos de Seguridad de la Capa de Transporte (TLS), el protocolo que protege tu navegador, se reducirá a tan solo 47 días para 2029. En segundo lugar, la llegada eventual de ordenadores cuánticos lo suficientemente potentes como para descifrar el cifrado actual está obligando a una transición hacia la criptografía poscuántica. Ambas cuestiones apuntan a la misma solución: un enfoque de la gestión del ciclo de vida de los certificados (CLM) regulado, automatizado y criptográficamente ágil.

La hoja de ruta detrás de la reducción de la vigencia de los certificados

El plazo de vigencia de los certificados TLS públicos lleva una década reduciéndose. A principios de 2023, Google publicó por primera vez su hoja de ruta «Moving Forward, Together», que proponía reducir la validez de los certificados de 398 días a 90 días con la esperanza de impulsar la automatización en el sector. Apple aceleró ese plazo en octubre de 2024 al presentar un borrador de votación al CA/Browser Forum, el organismo del sector en el que las autoridades de certificación y los fabricantes de navegadores establecen normas comunes. La propuesta de Apple, respaldada por Sectigo, Google Chrome y Mozilla, se aprobó en abril de 2025 como la votación SC-081v3.

Esta reducción se lleva a cabo por fases. El máximo anterior de 398 días ya se ha reducido a 200 días a partir de marzo de 2026, pasando a 100 días en marzo de 2027 y, finalmente, a 47 días en marzo de 2029. En la práctica, una organización que actualmente renueva cada certificado aproximadamente una vez al año pronto tendrá que renovarlos cada mes y medio, más o menos; en la fase final, cualquier proceso que dependa de que una persona solicite e instale manualmente los certificados fallará.

Los fabricantes de navegadores están impulsando estos plazos de validez más cortos para forzar la automatización, lo que elimina el error humano que, en primer lugar, provoca la mayoría de las interrupciones en los certificados. Además, permiten que toda la web adopte nuevos estándares criptográficos en cuestión de semanas en lugar de años, ya que los certificados antiguos quedan obsoletos rápidamente. Asimismo, contribuyen a reducir la dependencia de los sistemas de revocación heredados, que adolecen de problemas de rendimiento y privacidad. Por último, si alguna vez se descalifica un registro de transparencia de certificados (un registro público de los certificados emitidos), los certificados de corta duración reducen drásticamente el número de registros que deben sustituirse con poca antelación.

La crisis de la validación

Aunque el límite de 47 días acapara titulares y atención, el cambio más disruptivo puede ser lo que ocurra con la validación del control de dominio (DCV). La DCV es el proceso de demostrar a una autoridad de certificación (CA) que controlas el dominio para el que solicitas un certificado. Históricamente, una vez que una organización demostraba la propiedad, la CA podía reutilizar esa prueba durante un máximo de 398 días, pero según la norma SC-081v3, el plazo de reutilización se reduce a 200 días en 2026 y a tan solo 10 días en marzo de 2029.

Esto genera un verdadero desequilibrio, ya que incluso una organización que automatice por completo la instalación de certificados se verá paralizada si no puede volver a demostrar la titularidad del dominio cada 10 días. Cualquier retraso en la validación detiene todo el proceso de emisión y conduce directamente a interrupciones del servicio.

La solución práctica a este problema es adoptar el protocolo ACME (Automatic Certificate Management Environment) con validación automatizada mediante la API DNS-01, de modo que la demostración de la titularidad se realice mediante programación, en lugar de depender de una persona.

La amenaza cuántica y su cronología

Mientras que la vigencia de los certificados se reduce, los algoritmos que contienen se enfrentan a una amenaza cuántica. La infraestructura de clave pública (PKI) tradicional se basa en la criptografía asimétrica para proteger las firmas digitales, los intercambios de claves y las conexiones TLS. Un ordenador cuántico lo suficientemente potente que ejecute el algoritmo de Shor podría romper estos sistemas por completo. Esperar a que la computación cuántica sea lo suficientemente potente como para descifrar no es una opción viable; tal y como ha escrito Vidya Shankaran, directora técnica de campo de Commvault: «La fecha exacta del Q-Day puede seguir siendo incierta. La dirección en la que nos movemos, no lo es».

Las estimaciones sitúan el Q-Day —el momento en el que un ordenador cuántico podrá romper el cifrado de clave pública— en algún momento de los próximos 5 a 10 años. Sin embargo, sería un error considerar esto como un problema futuro. Los actores maliciosos ya están llevando a cabo operaciones del tipo «Recoger ahora, descifrar después» (HNDL), interceptando y almacenando tráfico cifrado hoy mismo con la intención de descifrarlo una vez que la computación cuántica haya madurado. Los datos que deben permanecer confidenciales durante años, como los historiales médicos, la propiedad intelectual y la información financiera, quedan efectivamente expuestos en el momento en que se recopilan.

El Gobierno federal de EE. UU. ha respondido en consecuencia: en junio de 2026, la Casa Blanca emitió la Orden Ejecutiva 14412, «Protección de la nación frente a ataques criptográficos avanzados», que establece plazos muy por delante del objetivo original del NIST para 2035: los sistemas federales de alto valor deben adoptar el establecimiento de claves poscuánticas antes de finales de 2030 y las firmas digitales poscuánticas antes de finales de 2031.

A pesar de esta urgencia, el progreso real hacia la criptoagilidad a nivel empresarial ha sido lento. El informe «DigiCert Quantum Readiness Outlook» reveló que más de la mitad de las organizaciones encuestadas prevén que el cifrado asimétrico clásico se vea vulnerado en un plazo de cinco años; sin embargo, solo el 7 % ha implantado criptografía a prueba de cuántica o híbrida en su parque de certificados, y el nivel de Readiness general solo mejoró en 2 puntos porcentuales durante el último año.

¿Por qué es importante la «criptoagilidad»?

El puente más práctico entre la criptografía clásica y la poscuántica es el certificado compuesto híbrido, que combina un algoritmo clásico (RSA o ECC) con un algoritmo poscuántico (ML-DSA, el esquema de firma estandarizado basado en retículas) dentro de un único certificado X.509. La combinación de ambos en un único certificado está diseñada para que este sea válido mientras lo sea cualquiera de los algoritmos, lo cual es esencial, ya que los algoritmos poscuánticos son nuevos y aún no han sobrevivido a innumerables intentos de ataque como lo ha hecho el RSA.

Sin embargo, las claves y firmas poscuánticas ocupan varios kilobytes en lugar de unos pocos cientos de bytes, lo que aumenta la latencia de la red, conlleva el riesgo de fragmentación de paquetes durante el protocolo de enlace TLS y añade una sobrecarga computacional que puede requerir actualizaciones de hardware en dispositivos con recursos limitados. Precisamente por eso es importante la «criptoagilidad»: las organizaciones necesitan poder probar, implementar y rotar algoritmos sin tener que reconfigurar su infraestructura subyacente cada vez que evolucionan los estándares.

Gestión automatizada del ciclo de vida de los certificados

La gestión manual de certificados no solo es ineficaz, sino que supone un auténtico riesgo operativo. Cuando los certificados se almacenan en hojas de cálculo fuera del campo de visión, las organizaciones pierden visibilidad, y el resultado son credenciales caducadas, tamaños de clave insuficientes, algoritmos de firma obsoletos y configuraciones no conformes que nadie detecta hasta que algo falla. Las interrupciones del servicio resultantes pueden confundir a los usuarios, interrumpir los ingresos y recaer sobre el equipo menos preparado para explicarlas.

Una plataforma completa de gestión del ciclo de vida de los certificados (CLM) aborda este problema a lo largo de toda la vida útil de un certificado:

• Detección: análisis continuo de entornos en la nube, centros de datos, contenedores y dominios externos para localizar todos los certificados en uso.
• Supervisión: seguimiento en tiempo real de las fechas de caducidad, los algoritmos, la solidez de las claves y el cumplimiento de la política de seguridad.
• Validación: utiliza la integración directa mediante API con autoridades de certificación (CA) públicas y privadas, al tiempo que automatiza la validación y las aprobaciones de dominios.
• Instalación: implementación de certificados y claves renovados de forma programada a través de ACME o API seguras, sin traspasos manuales.
• Revocación: es necesario llevar a cabo una revocación rápida y basada en políticas, de modo que un certificado comprometido pueda rotarse o revocarse en todas partes a la vez, en lugar de tener que buscarlo máquina por máquina.

La fase de detección también esconde una ventaja: el inventario de certificados que mantiene una plataforma CLM es, en efecto, el punto de partida del inventario criptográfico que requiere la planificación de la migración poscuántica, lo que puede convertir una tarea de cumplimiento normativo en una ventaja inicial.

Identidades no humanas e IA agentiva

El problema de la escala se ve agravado por la forma en que se construyen las aplicaciones modernas. Los contenedores, los pods de Kubernetes, las máquinas virtuales, los dispositivos del Internet de las cosas (IoT) y las API necesitan sus propias credenciales, y muchas de estas cargas de trabajo solo existen durante minutos u horas antes de terminarse. Ningún equipo humano puede emitir y retirar certificados a esa velocidad.

Para seguir este ritmo vertiginoso, se pueden utilizar agentes de IA que descubran, emitan, renueven y gestionen certificados de forma autónoma, sin salirse de los límites establecidos, como las políticas de seguridad, el control de acceso basado en roles (RBAC) y los registros de auditoría centralizados. El resultado es una automatización a la velocidad de las máquinas sin renunciar a la gobernanza empresarial.

Por dónde empezar

1. El primer paso hacia la «criptoagilidad» y la resiliencia en toda la empresa es de carácter organizativo, más que técnico. Siguiendo las directrices del NIST, las empresas deben crear un equipo central de servicios de identidad de máquinas que se encargue de la plataforma CLM, estandarice las plantillas de certificados y mantenga las integraciones con las autoridades de certificación (CA) públicas y privadas. A su vez, los responsables de aplicaciones individuales y los equipos de DevOps deben encargarse de integrar las renovaciones automatizadas en sus propios flujos de implementación, utilizando la plataforma central como un servicio compartido. Esta división mantiene la coherencia en la gobernanza al tiempo que elimina los traspasos manuales que provocan interrupciones del servicio.
2. Las organizaciones deberían sustituir ya las técnicas y los flujos de trabajo de validación manuales por ACME y la validación automatizada DNS-01, mucho antes de que llegue el plazo de 10 días para la validación de dominio (DCV), al tiempo que van eliminando progresivamente todos los procesos manuales de renovación y validación.
3. 1. 1. Paralelamente, las organizaciones deben realizar un inventario completo de sus activos criptográficos para detectar claves codificadas de forma fija, algoritmos obsoletos y rutas de confianza de larga duración que protejan los datos sensibles.
      2. La preparación poscuántica debe comenzar en un entorno controlado, en lugar de en producción. Debe crearse un laboratorio de pruebas dedicado que permita a los equipos probar certificados compuestos híbridos y actualizaciones «criptoágiles» en un entorno de pruebas. Al desarrollar aplicaciones sobre bibliotecas criptográficas modulares conectadas a una plataforma CLM dinámica, las empresas pueden alcanzar una verdadera «criptoagilidad»: la capacidad de rotar claves, cifrados y algoritmos en toda su infraestructura a medida que cambian los estándares, sin necesidad de reconstruir el sistema.

El hilo conductor que une todas las recomendaciones es el inventario. La fase de detección de una plataforma CLM no es una tarea rutinaria previa a la solución real; es la misma disciplina que las organizaciones necesitarán en todas las capas de la Readiness cuántica. Los certificados son identidades no humanas, y las mismas preguntas se aplican a las cuentas de servicio, los agentes de IA, las dependencias de código abierto y los algoritmos ocultos en el código de las aplicaciones: ¿qué tenemos, qué protege y qué parte de ello es más importante para el negocio?

Las organizaciones que desarrollen ahora esa capacidad de inventario, empezando por los certificados, encontrarán que el resto de la transición resulta mucho menos abrumadora, ya que la priorización se convierte en un cálculo en lugar de una suposición. Considerar los próximos años como un periodo de planificación en lugar de un periodo de gracia ayudará a las organizaciones a realizar esta transición según sus propios términos, en lugar de dejar que una interrupción del servicio tome la decisión por ellas.

Caitlin Dodson es becaria de verano de 2026 en FCTO – Américas, en Commvault.

Puntos clave

• Sustituir las afirmaciones subjetivas sobre la «facilidad de uso» por un ratio de protección de datos cuantificable: la capacidad protegida dividida por el número de administradores a tiempo completo.
• Medir la capacidad protegida por ETC ofrece una visión más significativa de la eficiencia operativa que las métricas tradicionales, como los trabajos de copia de seguridad por administrador.
• El índice de protección de datos debe utilizarse como referencia antes de una migración de plataforma y medirse de nuevo después para validar las mejoras operativas.
• Factores como los entornos multinube, los requisitos de Recovery tras ciberataques y las obligaciones de cumplimiento normativo pueden influir en el índice, por lo que debe evaluarse en el contexto de cada entorno.
• Las organizaciones deberían pedir a los proveedores que se comprometan a alcanzar resultados operativos cuantificables, en lugar de basarse en afirmaciones cualitativas sobre la simplicidad.

Todas las evaluaciones de proveedores en las que he participado acaban llegando al mismo callejón sin salida. Unos afirman que su plataforma es fácil de gestionar. Otros sostienen que la suya es aún más sencilla.

Nadie puede demostrar ninguna de las dos afirmaciones, por lo que la conversación deriva hacia la demostración, las llamadas de referencia o la intuición que se respira en la sala. Esa no es la forma en que se debe tomar una decisión que determinará cómo va a trabajar tu equipo durante los próximos cinco años.

He gestionado entornos de protección de datos en producción. He visto cómo los equipos se veían abrumados por herramientas fragmentadas que prometían automatización y, en cambio, solo generaban incidencias.

La «complejidad reducida» no es una sensación en la que debas confiar a ciegas. Es algo que deberías poder calcular.

La métrica que le faltaba al sector

Hemos empezado a utilizar un sencillo ratio tanto a nivel interno como con los clientes: la capacidad total protegida dividida por el número de empleados a tiempo completo necesarios para gestionarla. Lo llamamos el ratio de apalancamiento de la protección de datos.

Capacidad protegida (PB) / ETC = Ratio de apalancamiento de la protección de datos

Eso es todo. Sin preguntas de encuestas sobre satisfacción. Sin adjetivos. Una cifra, calculada a partir de datos de los que ya dispones.

He aquí por qué es más importante que las métricas a las que sustituye. Calcular el número de tareas de copia de seguridad por persona tenía sentido hace una década, cuando una tarea representaba una unidad discreta de esfuerzo manual. No refleja cómo funcionan hoy en día las plataformas modernas, en las que la automatización absorbe el trabajo rutinario y un solo administrador puede ser responsable de petabytes, no del recuento de tareas.

Medir las tareas por persona en un entorno automatizado no te dice nada sobre si la automatización está funcionando realmente.

Cómo se aplica en la práctica

Una aclaración antes de pasar a las cifras, ya que suele confundir a la gente. La «capacidad protegida» se refiere al tamaño total, sin comprimir ni deduplicar, de las aplicaciones que se protegen, no al disco físico en el que se almacenan.

Esa distinción es importante porque es la clave del asunto. El propio entorno de producción de Commvault protege 42,39 PB de datos de aplicaciones en 9,26 PB de disco físico, lo que supone un ahorro de espacio del 81,91 % gracias a la deduplicación y la compresión.

Esta relación no es solo una medida de cuántos petabytes puede supervisar una persona. Es una medida de cuánto trabajo realiza la arquitectura antes de que el personal entre en escena.

Teniendo esto en cuenta: Commvault gestiona su propio entorno de copias de seguridad en producción con 42,39 PB de capacidad protegida y solo dos empleados a tiempo completo (FTE). Esto supone una relación de 21,20 PB por FTE. Los valores de referencia del sector para las plataformas modernas suelen situarse entre 5 y 25 PB por FTE, dependiendo de la complejidad del entorno, por lo que esa cifra se sitúa en el extremo superior de lo que se puede alcanzar hoy en día.

Ratio de protección de datos = 42,39 PB / 2 ETC = 21,20 PB por ETC

Quiero ser claro sobre lo que esta cifra no refleja. No tiene en cuenta la presencia en múltiples nubes, los requisitos de Recovery tras ciberataques ni una combinación de aplicaciones con elevados requisitos de cumplimiento normativo, factores que reducirán el ratio por razones que no tienen nada que ver con la calidad de la plataforma.

Un ratio por sí solo no es un veredicto. Lo es, en cambio, un ratio medido antes y después de una migración.

Ese es el caso de uso real. Establece una referencia de tu entorno actual con tus herramientas actuales. Fija un ratio objetivo basado en tus previsiones de crecimiento y en la capacidad de tu equipo. A continuación, exige a tu proveedor que lo cumpla una vez finalizada la implementación, no solo durante el ciclo de ventas.

Las implicaciones a nivel de la junta directiva

Si eres tú quien da el visto bueno a la migración a una nueva plataforma, no solo se te pide que confíes en que la nueva plataforma sea más fácil de gestionar. Se te pide que financies un resultado operativo específico. Un objetivo de ratio de protección de datos te ofrece una forma de incluir ese resultado en el análisis de viabilidad y comprobarlo 12 meses después.

Esta es la misma disciplina que aplicamos al tiempo medio de recuperación tras una limpieza (MTCR). La capacidad de recuperación no es algo que se afirme, sino algo que se mide y se vuelve a medir hasta que la cifra refleje la realidad. La eficiencia operativa merece el mismo nivel de exigencia.

El reto

Pregunta a tu proveedor actual cuál es el ratio de apalancamiento de tu propio entorno hoy mismo. Si no pueden facilitarlo, eso te dice algo sobre hasta qué punto entienden lo que significa «fácil de gestionar» para tu equipo.

Y si estás evaluando una nueva plataforma, no aceptes «más fácil de usar» como respuesta. Pregunta a qué ratio se comprometen y vuelve a preguntar al cabo de un año.

Preguntas frecuentes

P: ¿Qué es el ratio de protección de datos?

R: La relación de protección de datos mide la capacidad de datos protegidos gestionada por cada administrador a tiempo completo. Ofrece una forma objetiva de evaluar la eficiencia operativa, en lugar de basarse en impresiones subjetivas sobre la facilidad de uso de la plataforma.

P: ¿Por qué es esta métrica más útil que el número de tareas de copia de seguridad por administrador?

R: Las plataformas modernas de protección de datos automatizan gran parte del trabajo rutinario que antes requería un esfuerzo manual. Como resultado, contar las tareas de copia de seguridad ya no refleja la verdadera carga de trabajo ni la eficiencia de un equipo de operaciones.

P: ¿Qué significa «capacidad protegida» en este cálculo?

R: La capacidad protegida se refiere al tamaño total, sin comprimir y sin deduplicar, de los datos de las aplicaciones que se protegen. Esta medida refleja la carga de trabajo real gestionada por la plataforma, en lugar del almacenamiento físico consumido tras la optimización.

P: ¿Un ratio de aprovechamiento más alto indica siempre que la plataforma es mejor?

R: No necesariamente. La complejidad del entorno, incluidas las implementaciones multicloud, los requisitos de ciberresiliencia y las obligaciones normativas, puede reducir la relación incluso cuando la plataforma funciona bien. La métrica resulta más valiosa al comparar el mismo entorno antes y después de una migración.

P: ¿Cómo deberían las organizaciones utilizar la relación de gearing de protección de datos durante las evaluaciones de proveedores?

R: Las organizaciones deben establecer una referencia basándose en su entorno actual, definir un ratio objetivo alineado con el crecimiento futuro y pedir a los proveedores que se comprometan a lograr mejoras cuantificables tras la implementación. Este enfoque desplaza el debate de las afirmaciones de marketing hacia resultados empresariales verificables.

P: ¿Cuál es el valor empresarial más amplio de esta métrica?

R: El ratio de protección de datos permite a los ejecutivos cuantificar las mejoras esperadas en la eficiencia operativa e incluirlas en el análisis de viabilidad de una inversión en una plataforma. También proporciona un punto de referencia que puede revisarse tras la implementación para confirmar que se han alcanzado los resultados prometidos.

Rajiv Kottomtharayil es director de productos de Commvault.