Skip to content

Puntos clave

  • Es probable que Mythos acelere la detección de vulnerabilidades a una escala y velocidad que superen a los flujos de trabajo tradicionales de corrección, que dependen del trabajo humano.
  • Los aspectos fundamentales de la seguridad, como la aplicación de parches, las copias de seguridad en sistemas aislados y una gestión rigurosa de las vulnerabilidades, siguen siendo clave, pero puede que ya no basten por sí solos.
  • El principal reto es pasar de la detección a la capacidad de actuar, ahora que el volumen de vulnerabilidades está aumentando hasta superar los límites operativos actuales.
  • La resiliencia de la IA depende de la capacidad de recuperar sistemas coherentes —no solo datos— en todos los modelos, flujos de trabajo y permisos.
  • Las organizaciones que se adapten de forma proactiva durante esta fase inicial probablemente estarán en una posición mucho mejor que las que tarden en actuar.

Hace unas semanas, estaba en una sala con un grupo de CIO y CISO cuando la conversación derivó hacia Mythos y el Proyecto Glasswing. La energía se notó al instante: se trata de gente que ha vivido muchos ciclos de expectación, y esto les llamó la atención. Las reacciones se dividieron en dos bandos. Uno: las categorías de amenazas no son nuevas; las organizaciones con una gestión sólida de vulnerabilidades y copias de seguridad aisladas de confianza estarán mejor posicionadas que aquellas que carecen de ellas. Dos: la velocidad es diferente —no solo lo que Mythos puede detectar, sino la rapidez con la que los atacantes podrían aprovechar la IA para lanzar ataques a la velocidad de una máquina, y cómo eso afecta a los cálculos en los que se basan la mayoría de los programas de gestión de vulnerabilidades—. Los dos tenían razón. Por eso merecía la pena escribir sobre esa conversación.

Qué cambia Mythos… y qué no

Mythos es el modelo de IA de Anthropic para la detección autónoma de vulnerabilidades. Es capaz de encontrar y encadenar exploits críticos en los principales sistemas operativos con una tasa de éxito que, según se cree, no tiene precedentes reales en este ámbito.

El Proyecto Glasswing —el consorcio de empresas creado para probar y reforzar sus sistemas antes de que Mythos o tecnologías similares lleguen a manos de los adversarios— es la señal de que esto es real, ya está aquí y que el margen de tiempo para adelantarnos es escaso. La visión que da prioridad a los fundamentos se mantiene: los parches son importantes, las copias de seguridad prácticamente aisladas son importantes, la disciplina en la gestión de vulnerabilidades es importante. Nada de eso cambia con Mythos. Lo que cambia es la tasa de producción al otro lado de esos programas. La pregunta que surge tras el caso Glasswing no es si tienes un programa de gestión de vulnerabilidades. Es si está diseñado para hacer frente a hallazgos que llegan poco a poco… o como un tsunami. La mayoría de los programas se diseñaron para el goteo. Evaluaciones periódicas, colas de priorización basadas en CVSS, ciclos de parches y pruebas que se miden en semanas. Esa cadencia tenía sentido cuando el ritmo de los hallazgos se ajustaba al ritmo de los procesos dirigidos por personas. La capacidad de la clase Mythos rompe esa suposición: el volumen de hallazgos explotables puede superar lo que la mayoría de las organizaciones pueden procesar a través de los flujos de trabajo con los que cuentan hoy en día. El problema no es la detección. Es la capacidad de actuar, y lo que pasa cuando la brecha entre el descubrimiento y la corrección se amplía más rápido de lo que puedes cerrarla.

Cuando la prevención se ve limitada, la resiliencia sale a relucir

Cuando los plazos de prevención se acortan, la cuestión de la resiliencia pasa a ser prioritaria. Si no puedes garantizar que vas a aplicar todos los parches antes de que se produzca un ataque —y cada vez es más difícil hacerlo—, las preguntas importantes cambian: ¿Con qué rapidez detectas el problema? ¿Cómo lo contienes? Y, cuando te recuperas, ¿a qué estado concreto vuelves exactamente?

Esta última pregunta es más difícil de lo que parece, especialmente para las organizaciones con interacciones progresivas entre agentes. Un sistema de IA no es solo datos. Es una versión del modelo, un proceso de entrenamiento, una base de datos vectorial, un conjunto de identidades y permisos de los agentes; todo ello debe reflejar el mismo estado operativo para constituir algo en lo que realmente se pueda confiar. La mayoría de las organizaciones pueden restaurar componentes individuales. Muy pocas pueden demostrar que lo que han restaurado tiene sentido.

Recuperar un sistema de IA no es un problema de restauración de datos. Es un problema de coherencia, y la brecha entre ambas cosas es precisamente donde la mayoría de las empresas están actualmente en riesgo. Este es el hilo conductor que vincula a Mythos con el debate más amplio sobre la resiliencia de la IA. No es que Mythos plantee un nuevo tipo de riesgo que requiera un nuevo marco.

Lo que pasa es que Mythos comprime la línea temporal de tal forma que las brechas existentes salen a la luz más rápido, dejando menos margen para solucionarlas antes de que algo salga mal, lo que aumenta la probabilidad de que algo salga mal antes de que una organización pueda corregir adecuadamente las vulnerabilidades.

La ventana está abierta. Pero no va a quedarse así.

Glasswing se diseñó para dar ventaja a los defensores. Las organizaciones que aprovechen este margen de maniobra de forma deliberada —poniendo a prueba la capacidad de sus programas de vulnerabilidad ante grandes volúmenes, llevando su infraestructura de resiliencia basada en IA a un nivel en el que puedan defenderse y considerando la recuperación como algo que debe poder demostrarse antes de que se produzca un incidente, y no como algo que haya que improvisar durante el mismo— estarán en una posición mucho mejor que las que se limiten a esperar. Los principios básicos siguen siendo los mismos. Lo que es nuevo es la urgencia.

«La empresa agentiva: por qué la resiliencia de la IA exige un sistema de registro» —el último informe de preparación de Commvault— analiza las carencias en la infraestructura de resiliencia de la IA que determinan si las organizaciones pueden dar respuesta a las difíciles cuestiones relacionadas con la recuperación cuando el ritmo de las amenazas lo exige.

Preguntas frecuentes

P: ¿Qué es Mythos y por qué es importante?

R: Mythos es un modelo de IA diseñado para la detección autónoma de vulnerabilidades, capaz de identificar y encadenar exploits entre sistemas a una velocidad sin precedentes. Su importancia radica en cómo acorta el tiempo que transcurre entre el descubrimiento de una vulnerabilidad y su posible explotación, lo que aumenta la presión sobre los defensores.

P: ¿Mythos cambia los fundamentos de la ciberseguridad?

R: No, las prácticas básicas como la aplicación de parches, las copias de seguridad y la gestión de vulnerabilidades siguen siendo importantes. Lo que está cambiando es el volumen y la velocidad de las amenazas, lo que ejerce presión sobre los procesos actuales, que se diseñaron para flujos de trabajo más lentos y predecibles.

P: ¿Por qué pueden tener dificultades los programas actuales de gestión de vulnerabilidades?

R: Muchos programas se diseñaron pensando en un flujo constante de hallazgos, no en el aumento repentino que permite el descubrimiento basado en la IA. Por eso, las organizaciones se enfrentan a una brecha cada vez mayor entre la identificación de vulnerabilidades y su corrección efectiva.

P: ¿Qué significa «resiliencia» en el contexto de los sistemas de IA?

R: La resiliencia va más allá de la restauración de datos: implica recuperar todo un sistema de IA en un estado coherente y fiable. Esto incluye que los modelos, los procesos de entrenamiento, las bases de datos vectoriales y los controles de acceso estén todos correctamente alineados.

P: ¿Por qué la recuperación está cobrando más importancia que la prevención?

R: A medida que los plazos de prevención se acortan debido a que los ataques se producen cada vez más rápido, se está volviendo poco realista aplicar todos los parches a tiempo. Esto hace que la atención se centre ahora en la rapidez con la que las organizaciones pueden detectar, contener y recuperarse de los incidentes.

P: ¿Cómo pueden empezar a prepararse las organizaciones?

R: Las organizaciones pueden someter a pruebas de estrés sus procesos de gestión de vulnerabilidades, modernizar su infraestructura de resiliencia y validar sus capacidades de recuperación. Actuar en esta fase temprana supone una ventaja estratégica significativa.

Tim Zonca es vicepresidente de gestión de carteras en Commvault.

More related posts

Thumbnail_Blog-Anthropic-Project-ResOps-2026

Anthropic’s Project Glasswing Makes the Case for ResOps

Read more

Puntos clave

  • La IA agentiva plantea nuevos riesgos de seguridad porque planifica, recuerda y actúa en distintos sistemas, en lugar de limitarse a un único ciclo de pregunta-respuesta.
  • Los datos de entrenamiento «envenenados» pueden influir de forma imperceptible en el comportamiento del modelo a gran escala, incluso cuando el modelo parece seguir funcionando con normalidad en las pruebas estándar.
  • Las bases de datos de vectores comprometidas pueden influir en las decisiones de los agentes al alterar el contexto en el que se basa el modelo, haciendo que un comportamiento incorrecto parezca legítimo.
  • La identidad de los agentes no controlados plantea un problema de control de acceso a la velocidad de las máquinas que los sistemas de identidad tradicionales, centrados en las personas, no están diseñados para gestionar.
  • Las decisiones en cadena basadas en un estado erróneo pueden propagar errores por varios agentes y flujos de trabajo, lo que complica mucho más la reversión y la recuperación.

Las herramientas, los controles y las políticas de gobernanza con las que cuentan la mayoría de las empresas se diseñaron para sistemas que responden a preguntas: herramientas de recuperación, copilotos, asistentes generativos. Sistemas que responden a una solicitud y se detienen. Cuando algo fallaba, el fallo era aislado. Se corregía la solicitud, se ajustaba la configuración y se seguía adelante.

La IA agentiva no funciona así. Estos sistemas planifican, recuerdan y ejecutan acciones en toda la empresa sin necesidad de instrucciones humanas paso a paso. Mantienen el estado. Se coordinan con otros agentes. Actúan en los sistemas de producción: escriben en bases de datos, activan flujos de trabajo y toman decisiones a la velocidad de una máquina. Ese cambio arquitectónico introduce cuatro vectores de amenaza para los que los marcos de seguridad actuales nunca se diseñaron. Si tu estrategia de gobernanza de la IA no los tiene en cuenta, es probable que tengas una vulnerabilidad que quizá ni siquiera puedas detectar.

1. Datos de entrenamiento contaminados

Un sistema de IA es tan fiable como los datos con los que se ha entrenado. Esa afirmación siempre ha sido cierta. Lo que ha cambiado es la superficie de ataque.

En las implementaciones de IA con agentes, los flujos de entrenamiento son más amplios, más complejos y, con frecuencia, se ensamblan a partir de múltiples fuentes: datos internos, fuentes de terceros, conjuntos de datos proporcionados por proveedores. Cada dependencia de esa cadena es un punto de inyección potencial. Un actor malintencionado que pueda influir en los datos de entrenamiento —mediante el compromiso de la cadena de suministro, el acceso de personas internas o la contaminación de una fuente de datos compartida— puede moldear el comportamiento del modelo a gran escala. Lo que hace que esto sea especialmente peligroso es que los modelos manipulados suelen funcionar con normalidad en las pruebas de rendimiento estándar. La manipulación puede ser muy precisa: diseñada para generar resultados específicos en contextos concretos, mientras que en el resto de casos se comporta correctamente.

Para cuando el problema sale a la luz en producción, el modelo ya lleva semanas o meses en uso, y rastrear el origen de la contaminación requiere precisamente ese tipo de trazabilidad relacional de los datos que la mayoría de las organizaciones no tienen. La pregunta que hay que hacerse es: ¿puedes presentar un registro completo y verificable de los datos con los que se entrenaron tus modelos, en un momento concreto?

2. Bases de datos vectoriales comprometidas

Las bases de datos vectoriales son la capa de memoria de los sistemas basados en agentes. Antes de actuar, un agente consulta un almacén vectorial para recuperar el contexto relevante —interacciones pasadas, conocimientos del dominio, datos de referencia— que determina cuál será su siguiente paso. La mayoría de los equipos de seguridad no se plantean las bases de datos vectoriales de la misma forma que lo hacen con otros almacenes de datos confidenciales. Y deberían hacerlo. Una base de datos vectorial comprometida no solo devuelve respuestas erróneas. También influye en las decisiones posteriores. Las incrustaciones inyectadas —contenido malicioso insertado en el almacén de vectores— pueden redirigir el comportamiento del agente de formas que parecen totalmente legítimas desde fuera.

Un agente al que se le pide que apruebe una transacción recupera un contexto que replantea sutilmente los criterios de aprobación. Un agente que gestiona las comunicaciones con los clientes extrae un contexto que orienta las respuestas en la dirección preferida por el atacante. La acción parece correcta. El razonamiento parece sólido. Pero el contexto subyacente ha sido manipulado.

Este vector de ataque es especialmente difícil de detectar porque opera por debajo de la capa del modelo. La supervisión estándar del modelo no lo detectará. El modelo se comporta exactamente como se le ha entrenado; es el contexto a partir del cual razona el que ha sido corrompido. La pregunta que debes hacerte es: ¿Se trata tu base de datos vectorial como un activo de datos sensible y regulado, con controles de acceso, supervisión de la integridad y registros de auditoría comparables a los de tus bases de datos de producción más críticas?

3. Identidad de agente no regulado

En una arquitectura multiagente, los agentes no solo interactúan con los datos, sino que también interactúan entre sí. Generan subagentes, delegan tareas, solicitan resultados y sintetizan los resultados de agentes con los que nunca han estado conectados explícitamente. Para ello, se autentifican, presentan sus credenciales y establecen una relación de confianza.

La identidad de agente es la capa de control de acceso para la empresa autónoma, y es una laguna que ni los proveedores de seguridad de identidad ni los proveedores de identidad (IDP) logran cubrir. Sus marcos de gobernanza están diseñados para la identidad humana.

Las identidades de los agentes creadas siguiendo esas mismas reglas parecen totalmente legítimas: se han configurado correctamente y cumplen con la política. El IDP no falla; simplemente no tiene un marco para determinar si un agente está actuando fuera del contexto para el que fue creado, si se le ha concedido un nivel superior sin que se note o si está coordinando acciones donde no debería.

Esta vulnerabilidad es cualitativamente diferente del robo tradicional de credenciales. Cuando a un usuario humano le roban las credenciales, el atacante actúa dentro de los permisos de ese usuario, a la velocidad de una persona. Cuando se compromete la identidad de un agente, el atacante consigue acceso a la capa de toma de decisiones autónoma: la capacidad de activar flujos de trabajo, aprobar acciones, coordinarse con otros agentes y extraer datos a la velocidad de una máquina, a gran escala, a través de canales que parecen totalmente normales.

Los fallos en la capa de identidad también se encuentran entre los más difíciles de detectar a posteriori. Las acciones de los agentes realizadas bajo una identidad comprometida no parecen anómalas: parecen un comportamiento legítimo de los agentes. Y, dado que son generadas por un sistema en lugar de por un humano, el volumen puede ser enorme antes de que nadie se dé cuenta.

Recovery agrava el problema. La mayoría de los manuales de Recovery de IA se centran en restaurar datos: conjuntos de entrenamiento, pesos de modelos, configuraciones de flujos de trabajo. La identidad rara vez figura en la lista. Un sistema recuperado con datos limpios pero con configuraciones de identidad desalineadas no está realmente recuperado. Es un sistema limpio con una capa de acceso contaminada. La pregunta que hay que hacerse es: ¿Se gestiona la identidad de los agentes con el mismo rigor que la identidad de las personas —con gestión del ciclo de vida, acceso con privilegios mínimos e inclusión en los planes de recuperación?

4. Decisiones en cadena basadas en una situación errónea

Los tres primeros vectores de ataque son puntuales. Este es sistémico y, en muchos sentidos, puede ser el más difícil de contener. Las arquitecturas multiagente están diseñadas para la coordinación. Los agentes comparten contexto, se pasan resultados entre sí y se basan en el trabajo de los demás. Esa coordinación es lo que los hace poderosos. También es lo que hace que los fallos se propaguen.

Un agente que opera con memoria corrupta no falla de forma aislada. Genera resultados —decisiones, acciones, datos— que otros agentes consumen. Esos agentes, a su vez, generan sus propios resultados. Para cuando la corrupción original se manifiesta como algo observable, el estado defectuoso puede haber afectado a docenas de procesos posteriores, a través de múltiples agentes, sin que exista una ruta clara para revertir los cambios.

Esto es lo que hace que la brecha de contexto sea tan importante. En cualquier momento dado, tu sistema de IA está formado por una versión del modelo, un conjunto de datos de entrenamiento, un almacén de artefactos, una configuración del proceso y un conjunto de interacciones de agentes activos; todos estos elementos deben reflejar el mismo estado operativo para constituir un sistema fiable y recuperable. Cuando no es así, no se trata simplemente de un error. Tienes un sistema que es coherente en sus partes, pero incoherente en su conjunto. Cada herramienta puntual puede confirmar su propio fragmento. Ninguna puede confirmar que las piezas encajen entre sí. Ese no es un problema de monitorización que se pueda resolver añadiendo otra herramienta. Es una laguna estructural, y la única forma de subsanarla es con un sistema que registre el estado de la IA de forma relacional: qué se estaba ejecutando, con qué datos, con qué configuración y en qué momento.

La pregunta que debes hacerte es: si tu infraestructura de IA se viera comprometida hoy mismo, ¿serías capaz de identificar exactamente en qué estado se encontraba cada componente antes del incidente y demostrarlo?

Qué significa esto para tu estrategia de seguridad

Cada uno de estos cuatro vectores requiere una respuesta defensiva diferente. Pero todos tienen una consecuencia en común: los marcos de gobernanza y resiliencia diseñados para la era anterior de la IA no cubren los modos de fallo de la era de los agentes. Para conseguir una IA con capacidad de acción, tienes que ampliar tu marco de trabajo en tres direcciones:

  • Más a fondo, en las capas de datos e identidad que se encuentran debajo del modelo.
  • Más amplio, para abarcar las interacciones entre agentes que el sistema de supervisión actual no detecta.
  • Desde el punto de vista relacional, para reflejar no solo el estado de cada componente, sino también cómo encajan entre sí en cualquier momento dado.

Ese último requisito es el que la mayoría de las organizaciones aún no han abordado. Y es el que determinará si, cuando algo vaya mal, tienes un sistema que se pueda recuperar o un montón de informes que parecen precisos pero que describen algo que ya no existe. Lee «El punto ciego agencial: por qué la resiliencia de la IA exige un sistema de registro» para descubrir por qué necesitas un SOR que te ayude a proteger la coherencia y la precisión de tus datos de IA.

Preguntas frecuentes

P: ¿Por qué los sistemas de IA con capacidad de acción son más arriesgados que las herramientas tradicionales de IA generativa?

R: Los sistemas basados en agentes hacen mucho más que responder a indicaciones. Mantienen el estado, se coordinan con otros agentes y llevan a cabo acciones en entornos de producción, lo que amplía la superficie de ataque mucho más allá de la simple manipulación de indicaciones.

P: ¿Por qué es tan difícil detectar los datos de entrenamiento «envenenados»?

R: La manipulación puede ser muy selectiva, afectando solo a situaciones concretas y dejando intactos los puntos de referencia normales. Eso significa que un modelo puede parecer que funciona bien hasta que el comportamiento malicioso se manifiesta en el uso real.

P: ¿Cómo puede una base de datos vectorial convertirse en un problema de seguridad?

R: Una base de datos vectorial define el contexto que utiliza un agente antes de actuar. Si ese contexto se altera, el agente puede tomar decisiones que, a primera vista, parezcan razonables, pero que en realidad están guiadas por datos maliciosos.

P: ¿Por qué la identidad de un agente es diferente de la identidad de una persona?

R: La identidad de un agente está ligada a las acciones autónomas, la delegación y la ejecución a la velocidad de una máquina. La gestión tradicional de identidades está pensada para las personas, por lo que a menudo no detecta si un agente está actuando fuera del contexto previsto.

P: ¿Por qué la propagación en cascada de estados erróneos es un problema tan grave en los sistemas multiagente?

R: En cuanto un agente procesa datos erróneos, ese error puede propagarse a los agentes y flujos de trabajo posteriores. El resultado no es solo una mala decisión, sino una cadena de fallos encadenados.

P: ¿Cómo pueden las organizaciones mejorar la seguridad de la IA?

R: Ampliar la gobernanza hasta las capas de datos e identidad, supervisar las interacciones entre agentes y realizar un seguimiento relacional del estado de la IA para que puedan reconstruir lo que ocurrió durante un incidente.

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

Blogs relacionados

More related posts

Thumbnail_Blog-Data-Access-Governance-2026

Securing AI with Unified Data Access Governance

Read more
Thumbnail_Blog-Environmental-Footprint-AI-2026

Smarter Data, Greener AI

Read more
Thumbnail_Blog-Anthropic-Project-ResOps-2026

Anthropic’s Project Glasswing Makes the Case for ResOps

Read more
Thumbnail_Blog-Data-Rooms-2025-Linkedin

Data Activate: Unlocking the Power of Trusted Data for AI Innovation

Read more
Thumbnail_Blog-AI-Agents-2026

AI Agents Are Everywhere. Do You Know What They’re Doing?

Read more
Thumbnail_Blog-Building-AI-Agents-2026

From Experimentation to Operation: Building AI Agents You Can Actually Trust

Read more

Puntos clave

  • Los sistemas de IA agentiva tienen estado y funcionan de forma continua, lo que hace que los modelos de recuperación tradicionales resulten insuficientes.
  • La capa de memoria (bases de datos vectoriales y almacenamiento de contexto) es una superficie de ataque clave, pero a la que no se le presta suficiente atención.
  • Los flujos de trabajo de toma de decisiones en tiempo de ejecución se pueden modificar sin que se activen las alertas de seguridad habituales.
  • Las lagunas en la observabilidad de las interacciones entre agentes hacen que la mayoría de las organizaciones no tengan una visión completa de los riesgos.
  • Para que la recuperación sea efectiva, hace falta un registro unificado y sincronizado de todas las capas del sistema para volver a un estado fiable.

La mayoría de las empresas que se adentran en la era de la IA agente están gestionando la resiliencia con un modelo mental erróneo, y los datos lo confirman: solo 1 de cada 5 empresas cuenta con un modelo maduro para gestionar los agentes de IA autónomos. Se plantean la IA igual que se plantean las aplicaciones: como algo discreto, sin estado y recuperable restaurando datos limpios en un entorno limpio.

La IA agentiva no funciona así. Estos sistemas tienen estado, operan de forma continua y presentan una arquitectura en capas que genera modos de fallo para los que la mayoría de los marcos de seguridad y resiliencia no fueron diseñados. La brecha no está en las herramientas. Está en comprender qué es lo que realmente se está ejecutando —y qué debe significar «Recovery» para los sistemas construidos de esta manera—.

Hay cuatro capas arquitectónicas que definen el problema. Cada una es distinta. Cada una está insuficientemente protegida. Y, en conjunto, explican por qué un sistema de IA agentiva puede parecer recuperable sin dejar de estar fundamentalmente comprometido.

Capa 1: Memoria del agente – La superficie de ataque que no estás vigilando

Las aplicaciones empresariales tradicionales no recuerdan nada entre sesiones. La IA de Agentic sí lo hace. La capa de memoria —compuesta principalmente por bases de datos vectoriales que almacenan representaciones, pero también el estado de la sesión y el contexto recuperado— es lo que aporta continuidad a los agentes a lo largo de las interacciones. Es lo que permite a un agente retomar el hilo donde lo dejó, basarse en el contexto anterior y construir una visión coherente de un flujo de trabajo complejo a lo largo del tiempo.

Además, es una de las superficies de ataque más importantes en la infraestructura empresarial moderna, y una de las menos supervisadas. El vector de ataque es lo suficientemente sutil como para eludir la mayoría de las herramientas de seguridad convencionales. Un adversario capaz de influir en lo que se escribe en una base de datos vectorial puede moldear lo que el agente considera cierto. Las representaciones inyectadas o manipuladas no tienen por qué parecer maliciosas: deben parecer fidedignas.

Si se compromete el almacenamiento de memoria, se puede alterar el comportamiento del agente, filtrar datos a través de sus acciones o hacer que el agente tome decisiones que parezcan legítimas, pero que en realidad sirvan a los objetivos del atacante. Para nada de esto hace falta tocar el modelo en sí. El problema de la detección se ve agravado por el volumen y la velocidad de las escrituras en las bases de datos vectoriales en implementaciones activas de agentes. Las herramientas de detección de anomalías diseñadas para datos estructurados no se adaptan bien al espacio de las representaciones vectoriales. La señal está ahí, pero la mayoría de las organizaciones no están preparadas para interpretarla.

Lo que requiere la resiliencia en este caso: una supervisión continua de la integridad de las bases de datos vectoriales, no solo copias de seguridad. Incrustaciones con control de versiones y una cadena de custodia demostrable. La capacidad de identificar, en cualquier momento, exactamente qué contenía la capa de memoria, y de restaurarla a un estado limpio y verificado, no solo a uno reciente.

Nivel 2: Control en tiempo de ejecución: cuando el flujo de trabajo es la amenaza

La IA agencial no ejecuta guiones fijos. Planifica. Durante la ejecución, un agente recibe un objetivo, determina los pasos necesarios para alcanzarlo, selecciona las herramientas que necesita y lo lleva a cabo, a menudo creando subagentes para gestionar flujos de trabajo paralelos. El flujo de trabajo es dinámico, se construye sobre la marcha y suele ser de larga duración.

Esto es lo que hace que la IA con capacidad de acción sea realmente útil. Y también es lo que hace que sea realmente difícil protegerla. En un entorno de automatización convencional, un flujo de trabajo predefinido tiene límites. Hace lo que se le ha configurado y se detiene. Un flujo de trabajo «agente» es diferente: se adapta.

Si un atacante consigue influir en la capa de planificación —ya sea mediante una indicación maliciosa, una respuesta manipulada de una herramienta o un modelo de planificación corrompido—, el agente perseguirá el objetivo del atacante utilizando cualquier herramienta y acceso legítimos de los que disponga. Parecerá un funcionamiento normal. Los registros, en la medida en que existan, mostrarán llamadas autorizadas a las herramientas. Pensemos en un agente de compras encargado de validar las facturas de los proveedores según los términos del contrato. En condiciones normales, comprueba los importes de las facturas, cruza los datos con los umbrales de aprobación y señala las excepciones para su revisión humana. Un atacante que pueda influir en la capa de planificación —mediante una respuesta manipulada de una herramienta procedente de la base de datos de contratos— no necesita intervenir directamente en la lógica de aprobación. Basta con que le pase al agente un registro de contrato con los umbrales modificados. El agente planifica correctamente a partir de datos corruptos. Cada llamada a una herramienta que realiza es legítima. Cada decisión a la que llega es errónea. Para cuando la anomalía sale a la luz en una conciliación financiera, el flujo de trabajo ya ha procesado semanas de facturas y el registro de auditoría no muestra más que acciones autorizadas.

El intervalo entre la compromisión y la detección en estos escenarios no se mide en segundos. Los flujos de trabajo basados en agentes operan de forma continua. Para cuando surgen resultados anómalos, es posible que el flujo de trabajo haya afectado a docenas de sistemas, tomado cientos de decisiones y dejado cambios en los entornos de producción que son difíciles de enumerar y aún más difíciles de revertir.

Lo que requiere la resiliencia en este caso: una supervisión en tiempo de ejecución que observe lo que los agentes están decidiendo, no solo lo que están haciendo. Mecanismos de intervención capaces de detener limpiamente un flujo de trabajo en ejecución sin provocar fallos en cadena. Guiones de Recovery diseñados para procesos basados en agentes de larga duración, no solo para transacciones discretas.

Capa 3: Observabilidad agencial – La brecha en el registro de datos a la velocidad de las máquinas

La infraestructura de registro de las empresas se diseñó para operaciones a escala humana. Registra lo que hacen los sistemas, con un nivel de detalle y una latencia pensados para que los humanos puedan revisarlo. La IA basada en agentes funciona a una velocidad totalmente diferente.

En una implementación activa con múltiples agentes, estos generan subagentes, se pasan información entre sí, realizan llamadas a herramientas y sintetizan resultados —de forma continua, en paralelo y a una velocidad superior a la que las cadenas de registro convencionales fueron diseñadas para capturar—. Las interacciones que más importan para la seguridad —las comunicaciones entre agentes, los traspasos de contexto y las invocaciones de herramientas que cruzan los límites de confianza— son precisamente las que los marcos de monitorización actuales dejan más desatendidas.

Hoy en día, solo el 17 % supervisa de forma continua las interacciones entre agentes. El 83 % restante gestiona la IA basada en agentes a partir de una visión parcial: una que capta lo que hacen los agentes de forma aislada, pero que pasa por alto el nivel de interacción, donde se producen los incidentes de seguridad más graves.

Esta no es una brecha que se pueda resolver simplemente aumentando el volumen de registro. El problema no es la cantidad de datos que se recopilan, sino que las estructuras de datos y los requisitos de latencia de las interacciones de los agentes no encajan bien en los marcos de observabilidad diseñados para sistemas más lentos y estructurados. Para cerrar esta brecha se necesitan herramientas de observabilidad de agentes diseñadas específicamente para ello, o una adaptación significativa de la infraestructura existente.

Lo que requiere la resiliencia en este caso: visibilidad de extremo a extremo de las interacciones entre agentes, no solo de los resultados de cada agente individual. Arquitecturas de registro capaces de funcionar a la velocidad de los agentes sin perder eventos. La capacidad de reconstruir, a posteriori, la secuencia completa de decisiones e interacciones de los agentes para cualquier flujo de trabajo dado.

Capa 4: Coordinación entre múltiples agentes: dónde se esconden los fallos emergentes

El riesgo arquitectónicamente más novedoso de la IA agentiva no viene de un único agente comprometido. Viene de cómo los agentes dependen unos de otros, y de cómo los fallos se propagan a través de esas dependencias antes de que nadie se dé cuenta de que algo va mal. En una arquitectura multiagente, los agentes comparten contexto. Un agente coordinador le pasa las instrucciones de una tarea a un subagente; el subagente devuelve un resultado que el coordinador incorpora a su siguiente decisión.

Si la salida del subagente está corrompida —ya sea por una capa de memoria comprometida, una respuesta manipulada de una herramienta o un modelo de planificación viciado—, el orquestador no tiene ninguna forma nativa de detectarlo. Considera que esa salida es fiable. La incorpora. Actúa en función de ella. Y transmite su propia salida, ahora comprometida, a las etapas siguientes.

Este es el modo de fallo emergente: una corrupción que se origina en una capa, se propaga a través de las interacciones entre agentes y se manifiesta como un resultado anómalo en un sistema situado a varios pasos de distancia de la vulneración original. Para cuando se hace visible, la cadena causal ya es larga y el alcance del impacto es considerable.

Imagina un proceso de inteligencia sobre amenazas en el que un agente de recopilación de datos recoge información de fuentes externas, un agente de clasificación la categoriza y le asigna una puntuación, y un coordinador integra esa inteligencia puntuada en recomendaciones sobre el estado de seguridad que se envían a los equipos de niveles inferiores. Si la capa de memoria del agente de recopilación de datos se ve comprometida —de forma sutil, mediante incrustaciones inyectadas que hacen que considere a ciertos actores maliciosos como de bajo riesgo—, el agente de clasificación recibe información que no tiene motivos para cuestionar. Clasifica con precisión en función de lo que se le proporciona. Clasifica con precisión en función de lo que se le proporciona.

El coordinador incorpora los resultados con confianza. Los equipos de seguridad de las fases posteriores restan prioridad a la categoría de amenaza relevante basándose en lo que parece un consenso coherente y procedente de múltiples fuentes. El fallo se originó en la capa 1. Se manifestó en la capa 4. Nada entre medias señaló una anomalía porque nada entre medias tenía visibilidad de toda la cadena.

Los marcos de gobernanza que la mayoría de las empresas aplican a la IA se diseñaron pensando en los resultados de los modelos, es decir, lo que dice la IA. Los fallos de coordinación entre múltiples agentes no son fallos en los resultados de los modelos. Son fallos del sistema, que surgen de la capa de interacción entre los modelos, y requieren un tipo diferente de gobernanza: una que supervise y controle no solo el comportamiento de cada agente, sino también las relaciones de confianza entre ellos, la integridad del contexto a medida que pasa de uno a otro, y los derechos de acceso que regulan lo que cualquier agente puede pedir a cualquier otro.

Lo que la resiliencia exige en este caso es una gestión de la identidad de los agentes que trate la confianza entre agentes como una cuestión de seguridad de primer orden. La verificación de la integridad del contexto a medida que traspasa los límites de los agentes. Políticas de gobernanza que abarquen el comportamiento de los agentes autónomos, y no solo los resultados de los modelos individuales.

El problema relacional que une a los cuatro

Estas cuatro capas tienen modos de fallo distintos, pero comparten una vulnerabilidad común: ninguna de ellas cuenta con un registro compartido de cómo se relacionan entre sí en un momento concreto.

El registro de modelos sabe qué versión se está ejecutando. La base de datos vectorial sabe qué hay en la memoria. La capa de orquestación sabe qué flujo de trabajo está activo. El sistema de identidad sabe qué agentes tienen qué acceso. Cada uno puede confirmar su propia parte del panorama. Ninguno puede confirmar si esas partes encajan entre sí —si reflejan el mismo estado operativo, el mismo momento, la misma configuración fiable—.

Esa es la brecha de contexto. Y por eso la recuperación tras un ataque a una IA agentiva no es un problema de restauración de datos. Es un problema de coherencia, uno que requiere un registro unificado de las relaciones entre las capas, no solo de los propios componentes. Soluciona este problema antes de que se produzca un incidente, o tendrás que dedicar todo el tiempo que dure el incidente a intentar solucionarlo.

Los retos arquitectónicos que se tratan aquí son solo una parte de lo que los responsables de seguridad y resiliencia deben entender sobre el riesgo de la IA agentiva. El artículo «El punto ciego agentivo: por qué la resiliencia de la IA exige un sistema de registro» va más allá y analiza cuál es la situación real de la mayoría de las empresas en cuanto a su preparación para la resiliencia de la IA, cómo se manifiestan en la práctica las lagunas de gobernanza y qué hace falta para que la afirmación «nuestra IA es fiable» sea algo demostrable, y no solo una simple afirmación.

Preguntas frecuentes

P: ¿Por qué la recuperación ante desastres tradicional no funciona con la IA agentiva?

R: La recuperación tradicional parte de la base de que los sistemas no tienen estado y se pueden restaurar a partir de copias de seguridad limpias. Los sistemas de IA basados en agentes conservan la memoria, evolucionan con el tiempo y dependen de interacciones en capas, por lo que una simple restauración no basta para recuperar la confianza.

P: ¿Qué hace que la capa de memoria de la IA agentiva sea vulnerable?

R: La capa de memoria almacena representaciones y datos contextuales que influyen en las decisiones del agente. Si se ve comprometida, los atacantes pueden manipular sutilmente lo que el agente «cree», lo que lleva a acciones incorrectas pero que parecen legítimas.

P: ¿Cómo pueden los atacantes aprovechar los flujos de trabajo en tiempo de ejecución de la IA basada en agentes?

R: Los atacantes pueden manipular los datos de planificación, las indicaciones o las respuestas de las herramientas, lo que hace que los agentes ejecuten acciones maliciosas utilizando procesos legítimos. Estas acciones suelen parecer normales en los registros, lo que dificulta su detección.

P: ¿Por qué la observabilidad supone un reto en los sistemas multiagente?

R: Los sistemas basados en agentes funcionan a la velocidad de la máquina, con interacciones continuas entre los agentes. Los sistemas de registro tradicionales no están diseñados para capturar ni procesar este nivel de actividad dinámica y de alta frecuencia.

P: ¿Qué son los fallos emergentes en entornos multiagente?

R: Los fallos emergentes se producen cuando una pequeña vulnerabilidad en un agente o capa se propaga por los agentes interconectados, lo que da lugar a problemas a gran escala cuyo origen es difícil de rastrear.

P: ¿Cómo sería una recuperación efectiva para una IA agentiva?

R: Una recuperación eficaz requiere algo más que restaurar los datos: exige una instantánea coherente de todas las capas del sistema, incluyendo la memoria, los flujos de trabajo, las identidades y las interacciones, alineada con un estado verificado y fiable.

Tim Zonca es vicepresidente de gestión de carteras en Commvault.

More related posts

Thumbnail_Blog-Clumio-Chat-2026

Meet Clumio Chat: An AI Assistant to Help Evaluate Cloud-Native Data Protection

Read more
Thumbnail_Blog-Clumio-Fedramp-2026

Clumio Advances Cloud-Native Cyber Resilience with FedRAMP® Milestone

Read more
Thumbnail_Blog_Agentic-Ransomware-Attack

Cyber Resiliency for AI and Ransomware Recovery

Read more

Hacer crecer una empresa basada en datos ya es complicado. ¿Y hacerlo cumpliendo con los requisitos del RGPD, gestionando miles de clientes, dando herramientas a los equipos de análisis y poniendo en marcha una nueva infraestructura en menos de dos semanas? Eso ya es otro nivel de complejidad.

En un episodio reciente de STRIVE, me reuní con Asif Dromi, de monday.com, y Ben Herzberg, de Commvault, para desentrañar lo que realmente se necesita para poner en práctica la seguridad de los datos a gran escala, no en teoría, sino en la práctica. No se trata de una conversación general sobre buenas prácticas, sino de una visión realista de cómo se entrecruzan las decisiones sobre seguridad, cumplimiento normativo, automatización e infraestructura cuando el tiempo apremia.

Mira el episodio completo. Si eres CISO, responsable de datos, arquitecto o responsable de cumplimiento normativo, este episodio te ofrece algo más valioso que la teoría. Te muestra cómo:

  • Una empresa en rápido crecimiento supo hacer frente a las exigencias del RGPD sin frenar la innovación.
  • La infraestructura como código puede simplificar las auditorías.
  • La automatización reduce el riesgo en lugar de aumentar la complejidad.
  • La seguridad y la agilidad empresarial no tienen por qué estar reñidas.

No es habitual escuchar directamente a los operadores que han llevado esto a cabo en condiciones reales. Eso es lo que hace que esta conversación de STRIVE sea diferente.

Puntos clave: Cómo poner en práctica la seguridad de los datos a gran escala

  • El cumplimiento normativo y el crecimiento no tienen por qué estar reñidos. Monday.com demuestra cómo los requisitos del RGPD y la rápida expansión pueden coexistir cuando la seguridad se integra en la arquitectura desde el principio.
  • Los permisos manuales no son escalables. La automatización sí lo es. La infraestructura como código y los controles de acceso basados en API pueden convertir la gobernanza de un cuello de botella en un multiplicador de fuerzas.
  • El acceso basado en roles debe adaptarse a cómo se usan los datos. A medida que más equipos dependen de los análisis, la visibilidad y los controles detallados cobran importancia para evitar que los permisos se descontrolen.
  • La seguridad operativa significa visibilidad. No se trata solo de establecer políticas, sino de supervisar, auditar y adaptar los controles de forma dinámica a medida que cambian los entornos.
  • La rapidez es posible cuando la arquitectura está bien pensada. Se puso en marcha un almacén de datos que cumple con la normativa europea en menos de dos semanas porque la gobernanza, la automatización y las herramientas se diseñaron para poder escalar.
  • La madurez en materia de seguridad permite la innovación. Cuando los permisos, la infraestructura y el cumplimiento normativo se pueden programar, las organizaciones pueden avanzar más rápido.

El verdadero reto: crecimiento + cumplimiento normativo + rapidez

Para monday.com, el reto no era solo almacenar los datos europeos en Europa. Era:

  • Garantizar el cumplimiento del RGPD y la residencia de datos a nivel regional.
  • Asegurarse de que los empleados solo accedieran a los datos relevantes.
  • Mantener la transparencia y la auditabilidad.
  • Ayudábamos a los analistas y desarrolladores que necesitaban un acceso rápido.
  • Y todo ello bajo unos plazos de trabajo muy ajustados.

Como explica Asif en el episodio, convertirse en una organización basada en datos implica que el acceso interno se amplía rápidamente. Cuanto más recurren los equipos al análisis de datos, más complejos se vuelven los permisos. Y ahí es donde muchas organizaciones se topan con un obstáculo. La seguridad pasa a ser un proceso manual, los permisos se vuelven frágiles y el cumplimiento normativo se convierte en algo reactivo. Eso no es seguridad operativa. Es un castillo de naipes.

Incorporar la seguridad en la arquitectura desde el primer día 

Una de las partes más interesantes del episodio es cómo abordó monday.com el problema desde el punto de vista arquitectónico. En lugar de adaptar el sistema a posteriori para cumplir con la normativa, creó:

  • Un almacén de datos europeo específico.
  • Controles de acceso claros basados en roles.
  • Modelos de permisos muy detallados.
  • Capas de gobernanza automatizadas.

Ben describe lo que ocurre en muchas grandes organizaciones: con el tiempo, los permisos se acumulan en capas, a menudo sin una visibilidad centralizada. Al final, nadie sabe con certeza quién puede acceder a qué. Poner en práctica la seguridad significa evitar esa deriva. Significa crear sistemas en los que el control se adapte automáticamente a medida que crece el uso.

La automatización es el multiplicador de fuerzas

Si hay un tema que recorre todo este episodio, ese es la automatización. En lugar de tratar los permisos como «tickets» y actualizaciones manuales, monday.com envolvió su infraestructura en código. Las bases de datos, los roles y las políticas de acceso podían crearse y modificarse mediante programación.

¿El resultado? Se puso en marcha un entorno conforme a la normativa y escalable en menos de dos semanas. Eso no es suerte. Es arquitectura. Y es un poderoso recordatorio de que la seguridad no te frena cuando está bien implementada. De hecho, potencia la velocidad.

Qué significa realmente poner en práctica la seguridad de los datos

El término «poner en práctica» se usa mucho. En este episodio, se define como:

  • Visibilidad constante de los datos confidenciales.
  • Gestión centralizada y automatizada de permisos.
  • Seguimiento de accesos.
  • Integración con herramientas de colaboración.
  • Políticas que se adaptan a medida que crecen los usuarios y los datos.

Los controles estáticos no son escalables. Los flujos de trabajo manuales no son escalables. La seguridad debe volverse dinámica, formar parte del tejido operativo de la organización. Y ese cambio es precisamente lo que hoy en día supone un reto para muchas empresas.

Mira el episodio completo de STRIVE

En el debate, te contarán más sobre:

  • Cómo estructuró monday.com su almacén de datos europeo.
  • Las principales lecciones aprendidas durante la implementación rápida.
  • Por qué la automatización era imprescindible.
  • Lo que las empresas suelen subestimar sobre la proliferación de permisos.
  • Cómo plantearse la puesta en práctica de la gobernanza antes de que se amplíen las iniciativas de IA.

Ver ahora.

Preguntas frecuentes 

P: ¿Cómo pueden los equipos pequeños implementar una seguridad de datos escalable?

R: Empieza con un modelo de permisos claro y herramientas de «infraestructura como código». Automatiza la gestión de permisos desde el principio para evitar cuellos de botella manuales a medida que crezcas.

P: ¿Qué papel juega la automatización en el cumplimiento normativo?

R: La automatización ayuda a garantizar la coherencia, reducir los errores y simplificar las auditorías. Mediante el uso de API y scripts, puedes supervisar y ajustar los permisos de forma dinámica.

P: ¿Cuánto tiempo suele llevar crear un entorno de datos que cumpla con la normativa y sea escalable?

R: Con una buena planificación y las herramientas adecuadas, empresas como monday.com lo han conseguido en menos de dos semanas. La rapidez depende del alcance del proyecto y de la infraestructura existente.

P: ¿Cuáles son las mejores prácticas para poner en práctica la seguridad de los datos?

R: Implementa controles de acceso basados en roles, automatiza la gestión de permisos, supervisa los registros de acceso con regularidad e integra herramientas de seguridad con las plataformas de colaboración para tener una supervisión en tiempo real.

Chris Mierzwa es director sénior de marketing de cartera en Commvault.

More related posts

Thumbnail_Blog-GoogleWorkspace-2026

Expanding Google Workspace Protection with Commvault eDiscovery

Read more
Thumbnail_Blog-Data-Leakage-Loops-2026

Are You Ready for Data Leakage Loops?

Read more
Thumbnail_Blog-Tornado-2025-Linkedin

The Trust Tightrope: Why New Yorkers Demand More from Businesses Than They Do from Themselves

Read more
Thumbnail_Blog_FinServ-Cybersecurity-2025

Modernizing Financial Cybersecurity: From Reactive to Resilient

Read more

Puntos clave

  • Los marcos de cumplimiento recogen las lecciones aprendidas de los fallos que se han producido en la vida real y ayudan a las organizaciones a reforzar su resiliencia, su gobernanza y su estabilidad operativa.
  • Las organizaciones que abordan el cumplimiento normativo como una iniciativa para fomentar la confianza pueden contribuir a reforzar la confianza de los clientes, las relaciones con los socios y la credibilidad de la marca.
  • La armonización normativa y unos controles de riesgo sólidos pueden ayudar a mejorar los resultados de las aseguradoras, al demostrar una postura de seguridad madura y resistente.
  • Relacionar los requisitos de cumplimiento con resultados empresariales cuantificables permite a las organizaciones vincular directamente las inversiones en resiliencia con la protección de los ingresos y la continuidad del negocio.
  • Las capacidades de ciberresiliencia, como las copias de seguridad inmutables, la recuperación rápida y los marcos de gobernanza, ayudan a las organizaciones a convertir el cumplimiento normativo en una ventaja competitiva.

En las salas de juntas de toda Europa y más allá, el término «cumplimiento normativo» se ha convertido en una palabra con mucha carga. Evoca imágenes de papeleo interminable, una presión regulatoria cada vez mayor y la amenaza constante de multas.

RGPD. NIS2. DORA. Las siglas no dejan de aparecer y, para muchas organizaciones, puede parecer que se están ahogando entre tanta normativa. Pero, ¿y si nos hemos estado planteando el cumplimiento normativo de forma equivocada? ¿Y si el cumplimiento normativo no se trata solo de evitar sanciones, sino de construir una empresa mejor, más sólida y más resistente?

La analogía del seguro: las normas existen por algo

Hay un paralelismo muy útil entre el cumplimiento normativo y los seguros. Cuando aseguras tu coche, la aseguradora establece ciertas condiciones. Los frenos deben funcionar. Los neumáticos no deben estar lisos. Puede que se exija un sistema de alarma. Puedes quejarte de las molestias o del coste, pero, en el fondo, esas normas existen porque ayudan a reducir el riesgo. Contribuyen a que los accidentes sean menos probables. Ayudan a protegerte tanto a ti como a los demás.

Y aquí está lo importante: esos requisitos suelen ser una buena idea, tanto si contratas el seguro como si no. La regulación funciona de manera muy similar. Los gobiernos y los reguladores no crean marcos normativos porque les guste hacerlo. Las regulaciones son respuestas a fallos del mundo real: filtraciones de datos, interrupciones operativas, riesgo sistémico. Codifican lecciones aprendidas a base de errores.

Puede que te parezca una carga. Puede que te resulte frustrante. Pero cuando analizas con detenimiento lo que exigen estos marcos, es difícil argumentar que los principios fundamentales no sean sólidos.

  • Protege los datos de los clientes.
  • Fomenta la resiliencia operativa.
  • Conoce los riesgos de tu cadena de suministro.
  • Ser capaz de recuperarse de los incidentes cibernéticos.
  • Demostrar buena gestión y responsabilidad.

Nada de eso es mala idea.

De evitar multas a generar confianza

Con demasiada frecuencia, el cumplimiento normativo se plantea desde un punto de vista defensivo: «Haz esto para que no te multen». «Haz esto para que no te metan en la cárcel». Eso es muy poco. Y es una oportunidad perdida. Cuando cambiamos de perspectiva, el cumplimiento normativo se convierte en algo mucho más potente. Se convierte en un motor de confianza.

Tomemos como ejemplo el RGPD. En esencia, se trata de proteger los datos personales. Si tu organización implementa prácticas sólidas de protección de datos —no solo para cumplir con los requisitos, sino porque tus sistemas protegen de verdad la información de los clientes—, eso genera confianza. Los clientes se sienten más seguros al hacer negocios contigo. Los socios están más dispuestos a integrarse contigo. Los reguladores te consideran un riesgo menor. La confianza no es un resultado de la normativa. Es una ventaja comercial.

Lo mismo se aplica a la Ley de Resiliencia Operativa Digital. No se trata solo de notificar incidentes, sino de ser capaz de resistir las interrupciones y recuperarse de ellas. En un mundo en el que los ciberataques son inevitables, la resiliencia no es opcional. Es fundamental para la continuidad, la reputación y el valor a largo plazo. Cuando el cumplimiento normativo impulsa la resiliencia, la resiliencia impulsa la estabilidad empresarial, y la estabilidad impulsa el crecimiento.

Regulación y seguros: un círculo vicioso

También existe una alineación natural entre la regulación y los mercados de seguros. Cuando los reguladores imponen ciertas normas, las aseguradoras las siguen rápidamente. Las organizaciones que demuestran cumplimiento normativo y sólidos controles de riesgo resultan más atractivas para las aseguradoras. Pueden beneficiarse de mejores condiciones, una cobertura más amplia o primas más favorables. Esto crea un círculo vicioso:

  • La normativa establece unos requisitos mínimos.
  • Las organizaciones refuerzan sus controles.
  • Las aseguradoras premian las estrategias de gestión de riesgos más sólidas.
  • Los mercados se vuelven más estables y resistentes.

El cumplimiento normativo, en este contexto, se convierte en una señal para el mercado: nos tomamos el riesgo muy en serio.

El eslabón perdido: cómo relacionar el cumplimiento normativo con los resultados empresariales

Una de las oportunidades más importantes para las organizaciones —sobre todo para los proveedores de tecnología— es dejar claro el vínculo entre el cumplimiento normativo y el valor empresarial. Por ejemplo:

  • Si un producto crea copias de seguridad inmutables, eso ayuda a cumplir los requisitos normativos en materia de integridad de los datos.
  • Si permite una recuperación rápida tras los incidentes cibernéticos, eso ayuda a cumplir con los requisitos de resiliencia operativa.
  • Si ofrece registros de auditoría y informes claros, eso ayuda a cumplir con los requisitos de gobernanza y supervisión.

Pero no debería quedarse ahí. El siguiente paso es explicar las ventajas para la empresa:

  • Las copias de seguridad inmutables ayudan a reducir el impacto del ransomware y a proteger los ingresos.
  • Una recuperación más rápida ayuda a reducir al mínimo el tiempo de inactividad y a mantener la confianza de los clientes.
  • Una buena gestión ayuda a reducir el escrutinio regulatorio y refuerza la credibilidad de la marca.

Esta correspondencia es fundamental. El cumplimiento normativo no es el objetivo final, sino el mecanismo que permite alcanzar los resultados que importan a las empresas: la continuidad, la reputación, la confianza de los clientes y la diferenciación competitiva.

El cumplimiento normativo como innovación, no como obligación

Se tiende a ver el cumplimiento normativo como algo que hay que «sacar adelante». Un centro de costes. Un mal necesario. Pero si echamos un vistazo a la historia, muchas de las buenas prácticas que ahora se consideran fundamentales para la informática y la seguridad modernas surgieron a raíz de requisitos normativos o de seguros. Con el tiempo, se han ido integrando en el funcionamiento de las organizaciones bien gestionadas. Cifrado. Control de accesos. Planificación de la respuesta ante incidentes. Pruebas de continuidad del negocio. Gestión de riesgos de terceros. En su momento, puede que se consideraran una carga normativa. Hoy en día, son requisitos imprescindibles para cualquier empresa que se precie. Las organizaciones que tratan el cumplimiento normativo como un catalizador de la innovación —en lugar de como un mero trámite burocrático— suelen ser las que se sitúan a la cabeza. Incorporan la resiliencia en su arquitectura. Diseñan teniendo en cuenta la gobernanza. Convierten los requisitos normativos en capacidades de producto y propuestas de valor para el cliente.

Ciberresiliencia: donde el cumplimiento normativo y la estrategia se unen

Aquí es donde la ciberresiliencia cobra un papel fundamental. Las normativas modernas reconocen cada vez más una simple verdad: la prevención no basta. Los incidentes ocurrirán. Lo que marca la diferencia es la capacidad de una organización para responder y recuperarse.

La ciberresiliencia —la capacidad de resistir, recuperarse y adaptarse a las perturbaciones cibernéticas— ya no es solo una cuestión de seguridad. Es un imperativo estratégico. Favorece el cumplimiento normativo, sí. Pero, lo que es más importante, sustenta la continuidad operativa y la confianza empresarial. Cuando las organizaciones invierten en arquitecturas resilientes, datos inmutables, capacidades de recuperación rápida y marcos de gobernanza sólidos, no solo cumplen con los requisitos de los organismos reguladores. Están construyendo empresas duraderas.

Una conversación diferente sobre el cumplimiento normativo

Quizá sea hora de cambiar la forma de ver las cosas. En lugar de preguntarnos: «¿Qué es lo mínimo que tenemos que hacer para cumplir con la normativa?», deberíamos preguntarnos:

  • ¿Cómo nos hace más fuertes esta normativa?
  • ¿Qué buena práctica se está codificando aquí?
  • ¿Cómo podemos aprovechar esto para reforzar la confianza de los clientes y socios?
  • ¿En qué sentido supone esto una ventaja competitiva?

Hacer bien el cumplimiento normativo no tiene que ver con el miedo. Tiene que ver con la previsión. Refleja las lecciones aprendidas en distintos sectores. Incorpora las mejores prácticas a las operaciones diarias. Y cuando se vincula claramente con las capacidades del producto y los resultados empresariales, se convierte en un argumento comercial muy convincente.

Sí, la normativa puede parecer una carga. Sí, no paran de aparecer acrónimos. Pero detrás de todo ese papeleo hay algo mucho más valioso: un marco para gestionar mejor tu negocio. El cumplimiento normativo no consiste solo en evitar sanciones. Se trata de fomentar la resiliencia. Y la resiliencia, en última instancia, es lo que impulsa el éxito sostenible. Descubre aquí cómo Commvault facilita la protección de datos para ayudar a tu organización a cumplir con los requisitos normativos.

Preguntas frecuentes

P: ¿Por qué las organizaciones deberían considerar el cumplimiento normativo como algo más que una simple obligación legal?

R: Los marcos de cumplimiento suelen reflejar las mejores prácticas desarrolladas en respuesta a incidentes cibernéticos reales, fallos operativos y retos de gobernanza. Las organizaciones que adoptan el cumplimiento de forma estratégica pueden contribuir a reforzar la resiliencia, mejorar la confianza y generar valor empresarial a largo plazo.

P: ¿Cómo contribuye el cumplimiento normativo a la confianza de los clientes?

R: Unas prácticas sólidas en materia de cumplimiento normativo demuestran que una organización se toma en serio la protección de datos, la gobernanza y la continuidad operativa. Esto puede ayudar a aumentar la confianza de los clientes, reforzar las relaciones con los socios y posicionar a la organización como una empresa de menor riesgo.

P: ¿Qué relación hay entre el cumplimiento normativo y la resiliencia cibernética?

R: La normativa actual se centra cada vez más en la capacidad de una organización para recuperarse de las interrupciones, en lugar de limitarse únicamente a prevenirlas. Las inversiones en infraestructuras resilientes, copias de seguridad inmutables y capacidades de recuperación rápida pueden ayudar a las organizaciones a mantener la continuidad durante los ciberincidentes.

P: ¿Cómo puede el cumplimiento normativo influir positivamente en los seguros y la gestión de riesgos?

R: Las aseguradoras suelen valorar mejor a las organizaciones que cuentan con programas de cumplimiento bien consolidados y controles de seguridad sólidos. Esto puede traducirse en mejores opciones de cobertura, condiciones de póliza más favorables y, posiblemente, primas más bajas.

P: ¿Por qué es importante vincular las iniciativas de cumplimiento normativo con los resultados empresariales?

R: Las iniciativas de cumplimiento normativo son más eficaces cuando las organizaciones demuestran claramente cómo los controles contribuyen a objetivos más amplios, como proteger los ingresos, reducir el tiempo de inactividad y mantener la confianza de los clientes. Esto ayuda a los directivos a ver el cumplimiento normativo como una inversión estratégica en lugar de como un centro de costes.

P6: ¿Cómo pueden las organizaciones convertir el cumplimiento normativo en una ventaja competitiva?

R: Las empresas que integran la resiliencia, la gobernanza y la seguridad en sus productos y operaciones pueden diferenciarse en el mercado. Al adaptarse de forma proactiva a las expectativas normativas, las organizaciones pueden reforzar su reputación y generar mayor confianza entre los clientes y las partes interesadas.

Darren Thomson es director técnico de campo en Commvault.

More related posts

Thumbnail_Blog-Clumio-Chat-2026

Meet Clumio Chat: An AI Assistant to Help Evaluate Cloud-Native Data Protection

Read more
Thumbnail_Blog-Clumio-Fedramp-2026

Clumio Advances Cloud-Native Cyber Resilience with FedRAMP® Milestone

Read more
Thumbnail_Blog_Agentic-Ransomware-Attack

Cyber Resiliency for AI and Ransomware Recovery

Read more

Puntos clave

  • La soberanía operativa se centra en quién puede acceder a los sistemas y bajo qué jurisdicciones operan.
  • El acceso de los proveedores, los flujos de telemetría y las vías de asistencia pueden generar lagunas ocultas en materia de soberanía.
  • La soberanía operativa es más difícil de certificar porque requiere una visibilidad y una auditoría continuas.
  • Las organizaciones deben poder demostrar y documentar todas las vías de acceso a los entornos soberanos.

Si se pregunta a la mayoría de las organizaciones en qué aspecto es más sólido su programa de soberanía, la respuesta suele ser una variante de los mismos dos aspectos: la localización de los datos y el cifrado. Saben dónde se almacenan sus datos principales. Han implementado acuerdos de «trae tu propia clave» o «conserva tu propia clave». Pueden presentar certificaciones.

Pregúntales quién ha accedido a su entorno soberano en los últimos noventa días, desde qué países y bajo qué jurisdicciones legales… y la confianza suele esfumarse. La soberanía operativa es el pilar más difícil de auditar, el que más se tiende a subestimar y el ámbito más habitual en el que una postura de soberanía que parece sólida sobre el papel se desmorona en la práctica. El Informe sobre la Readiness para la soberanía digital lo señala como uno de los cuatro pilares; este artículo va más allá. La pregunta que la mayoría de las organizaciones no saben responder: «¿Quién ha accedido a tu entorno soberano en los últimos 90 días, desde qué países y bajo qué jurisdicciones legales?»

Qué significa realmente la soberanía operativa

La soberanía operativa no tiene que ver con dónde se almacenan los datos. Se trata de quién gestiona el entorno y quién tiene acceso a él. Abarca tres aspectos que la mayoría de los programas de soberanía tratan como detalles de implementación en lugar de considerarlos cuestiones prioritarias:

  • Acceso del personal y jurisdicción. Toda persona que pueda acceder a su entorno soberano —ya sea para ofrecer soporte, realizar tareas de mantenimiento, llevar a cabo la supervisión o responder a incidentes— opera bajo una jurisdicción legal definida. Si un ingeniero de soporte de un país sujeto a una ley extranjera de acceso a datos puede acceder a sus sistemas, la soberanía de su infraestructura dependerá en gran medida de la exposición legal de ese ingeniero.

La mayoría de las organizaciones, cuando hacen esta auditoría por primera vez, se encuentran con al menos una vía de asistencia que cruza un límite jurisdiccional que no habían tenido en cuenta.

  • Acceso de terceros y proveedores. Tu límite de soberanía se extiende a todos los proveedores, proveedores de servicios gestionados y platform de software platform acceso a tu entorno soberano. Plataformas de ITSM, herramientas de monitorización, sistemas SIEM… Si estos se encuentran fuera de tu límite de soberanía pero tienen acceso a datos o metadatos dentro de él, tienes una brecha que los controles de localidad de datos no pueden cerrar.
  • Tráfico de telemetría, facturación y plano de control. Los programas de soberanía de datos se centran en los datos primarios. La soberanía operativa requiere identificar adónde va todo lo demás: la telemetría que genera tu infraestructura, los metadatos que recopilan tus sistemas de monitorización, los datos de facturación que procesa tu proveedor. Estos flujos pueden cruzar las fronteras jurisdiccionales incluso cuando los datos primarios no lo hacen, y rara vez se mapean.

Por qué este pilar es más difícil de certificar… y por qué eso importa

La localidad de los datos es relativamente sencilla de documentar. Se puede hacer referencia a una región de almacenamiento, a un acuerdo de residencia de datos o a una auditoría de terceros. La soberanía operativa no cuenta con el mismo rastro documental. No existe ninguna certificación que garantice la situación jurisdiccional de cada ingeniero de soporte que pueda acceder a tu entorno.

Esto es precisamente lo que lo convierte tanto en el pilar más difícil de auditar como en el más importante a la hora de hacerlo bien. Además, está directamente relacionado con el reto de la soberanía mínima viable: aplicar los controles operativos adecuados a las cargas de trabajo adecuadas requiere saber cuáles son esos controles, y es precisamente en la soberanía operativa donde ese conocimiento suele faltar.

La dimensión de la cadena de suministro

La NIS2, que amplía las obligaciones en materia de ciberseguridad a los sectores de la energía, el transporte, la sanidad y las infraestructuras digitales, exige ahora a las organizaciones que evalúen las prácticas de ciberseguridad de sus proveedores de tecnología. Para los programas de soberanía, esto tiene una consecuencia directa: la postura de soberanía de los proveedores ya no es un simple detalle en la contratación pública. Es un requisito que se puede auditar.

Esto implica plantear nuevas preguntas a cada proveedor que se encuentre dentro de su perímetro de soberanía: ¿Dónde se encuentra su personal de soporte? ¿Bajo qué jurisdicción legal operan? ¿Qué ocurre con el acceso que tienen a mi entorno si su empresa es adquirida por una entidad no perteneciente a la UE?

Cómo es lo bueno

Un entorno operativamente soberano tiene cuatro características que se pueden demostrar, no solo documentar:

  • Se ha realizado un mapa de todas las vías de acceso al entorno soberano: no solo el acceso principal, sino también el de los proveedores, el de soporte técnico y el de los sistemas de monitorización.
  • El estatus jurisdiccional de cada persona o sistema que tiene ese acceso se documenta y se audita con una periodicidad definida.
  • Se hace un inventario de los flujos de tráfico de telemetría, metadatos y del plano de control, y estos se mantienen dentro de los límites de soberanía o se evalúan y aceptan explícitamente como fuera del ámbito de aplicación.
  • La organización puede responder a la pregunta sobre el acceso en un plazo de noventa días —y lo hace con precisión, aportando pruebas—.

Una cosa más: la soberanía operativa no se limita al control de acceso. Si la recuperación requiere personal que trabaje fuera de tus límites de soberanía, la estrategia falla en el momento en que se produce un incidente. Ese es el tema de la cuarta entrada de esta serie. El Informe sobre la preparación para la soberanía digital incluye una pregunta de evaluación directa sobre la soberanía operativa.

Preguntas frecuentes

P: ¿Qué es la soberanía operativa?

R: La soberanía operativa se refiere a quién gestiona y tiene acceso a un entorno, incluyendo al personal, a los proveedores y a los sistemas de soporte. Va más allá del lugar donde se almacenan los datos.

P: ¿Por qué se suele pasar por alto la soberanía operativa?

R: Muchas organizaciones se centran principalmente en la ubicación y el cifrado de los datos. A menudo, las vías de acceso, el personal de soporte y los flujos de telemetría no se auditan a fondo.

P: ¿Cómo influyen los proveedores en la postura de soberanía?

R: Los proveedores y los proveedores de servicios gestionados pueden tener acceso a sistemas sensibles o a metadatos. Sus jurisdicciones legales y prácticas operativas pueden afectar al cumplimiento general de las normas de soberanía.

P: ¿Por qué son importantes la telemetría y los metadatos?

R: Aunque los datos primarios se queden en el ámbito local, la telemetría y los metadatos pueden traspasar las fronteras jurisdiccionales. Estos flujos pueden suponer riesgos de cumplimiento normativo si no se gestionan adecuadamente.

P: ¿Qué incluye un modelo sólido de soberanía operativa?

R: Incluye rutas de acceso definidas, controles jurisdiccionales documentados, acceso de proveedores auditado y visibilidad de todos los flujos de telemetría y metadatos.

Alex Zinin es vicepresidente y director general del área de proveedores de servicios gestionados en Commvault.

More related posts

Thumbnail-Digital-Sovereignty-4

Sovereign Data You Can’t Recover Isn’t Actually Sovereign

Read more
Thumbnail-Digital-Sovereignty-2

Minimum Viable Sovereignty: Why the Right Posture Isn’t the Same for Every Organization

Read more
Thumbnail-Digital-Sovereignty-1

You Don’t Have a Sovereignty Strategy. You Have a Residency Policy.

Read more

Puntos clave

  • Las arquitecturas soberanas suelen dar prioridad a las auditorías y los controles de acceso frente a la preparación para la recuperación.
  • El personal de recuperación, backup y los modelos de custodia clave pueden generar lagunas en la soberanía durante los incidentes.
  • Es fundamental que los controles sean uniformes tanto en el entorno principal como en el de recuperación.
  • Para lograr una resiliencia preparada para la soberanía, se necesitan procedimientos de recuperación probados en condiciones reales.

Imagina la situación. El ataque ya se ha producido. El equipo de respuesta a incidentes se está reuniendo. Alguien debe decidir qué sistemas se restablecen primero, en qué orden y utilizando los puntos de Recovery correctos.

Y entonces alguien se da cuenta de que: el personal con acceso al sistema de recuperación está ubicado en otro país. Y lo que es peor, el propio entorno de recuperación (alojado en una cloud , en un centro de datos de un socio o en una sede secundaria) nunca ha estado sujeto a los mismos controles de soberanía que los datos principales. Esta práctica no estaba sujeta a los mismos controles de soberanía que los datos primarios. El regulador quiere saber en qué punto estamos. El tiempo corre.

Este es el escenario para el que no se diseñaron la mayoría de las arquitecturas soberanas, y para el que el Informe sobre la Preparación para la Soberanía Digital señala directamente: la mayoría de las aplicaciones soberanas están pensadas para la auditoría, no para los incidentes. La mayoría de las aplicaciones soberanas están diseñadas para la auditoría, no para los incidentes. La diferencia se nota justo en el peor momento posible.

El punto ciego de la recuperación en la arquitectura soberana

Los programas de soberanía se basan en el control de acceso: quién puede acceder a los datos, bajo qué autoridad y a través de qué vía. Esa arquitectura es necesaria. Pero no es suficiente. Y está directamente relacionada con las lagunas de soberanía operativa analizadas en la tercera entrada de esta serie: si las personas que gestionan tu entorno operan fuera de los límites de tu soberanía, ese problema no desaparece durante un incidente. Se convierte en el problema.

Lo que el control de acceso deja sin respuesta es la pregunta más difícil: ¿qué pasa después de un incidente, cuando la recuperación no es solo una operación técnica, sino que también está sujeta a restricciones legales?

Un ataque de ransomware contra una organización europea sujeta a regulación no solo supone un problema de recuperación. Supone un problema de recuperación que hay que resolver dentro de una jurisdicción, con personal que cuente con las autorizaciones adecuadas y utilizando puntos de recuperación de los que se pueda demostrar que están limpios y no se han visto comprometidos. La arquitectura soberana diseñada para proteger los datos puede complicar la recuperación si no se ha incorporado la resiliencia en el diseño original.

Los modos de fallo específicos

Las formas en que fallan las arquitecturas de recuperación soberana son predecibles… y habituales:

  • Personal de recuperación fuera de los límites de la soberanía. Los ingenieros que conocen los sistemas de Recovery pueden operar en una jurisdicción diferente. Bajo presión, recurrir a ellos es la vía más fácil. Además, supone una violación de la soberanía justo en el momento menos oportuno.
  • Infraestructura de copia de seguridad sin los controles adecuados. Los entornos soberanos principales se controlan minuciosamente. La infraestructura de copia de seguridad —sobre todo los entornos más antiguos o secundarios— no suele estar sujeta a los mismos requisitos de soberanía. Si los puntos de recuperación se almacenan o procesan fuera de los límites establecidos, no es posible realizar una recuperación conforme a la normativa desde una infraestructura que cumpla con los requisitos.
  • La custodia de las claves en situaciones de crisis. Los acuerdos de «cada uno con su propia clave» están pensados para el funcionamiento normal. En situaciones de crisis —cuando los sistemas principales están comprometidos y la presión del tiempo es enorme—, el modelo de custodia de claves que funciona en una ventana de mantenimiento rutinario puede convertirse en un obstáculo para la recuperación. Si no se ha probado, es solo una suposición, no un control.
  • Lagunas de gobernanza entre entornos. Las organizaciones que operan en varios niveles soberanos —que son la mayoría— suelen tener controles sólidos en los entornos principales y controles más débiles en los entornos secundarios, que también forman parte de la ruta de recuperación. Lo que buscarán los auditores es la coherencia en todo el conjunto de entornos. Las lagunas en los entornos secundarios se hacen evidentes justo cuando la coherencia es más importante.

Por qué los controles de soberanía pueden complicar la recuperación

Los mismos controles que hacen que un entorno soberano sea defendible ante un auditor pueden dificultar la recuperación. Las restricciones al movimiento de datos que impiden la filtración no autorizada también limitan la coordinación de la recuperación. Los acuerdos clave de custodia que garantizan que ningún proveedor pueda acceder a tus datos sin autorización también suponen un obstáculo cuando necesitas restaurarlos rápidamente.

Nada de esto quiere decir que estos controles estén mal. Lo que significa es que hay que diseñarlos pensando en la recuperación desde el principio, y no añadirlos a una arquitectura en la que la recuperación se haya tenido en cuenta a posteriori. Este es el núcleo del principio de soberanía mínima viable: ajustar los controles a las necesidades reales incluye los requisitos de recuperación, no solo los de control de acceso.

Lo que requiere una resiliencia preparada para la soberanía

  • Validación de la recuperación limpia. Demostrar que los puntos de recuperación no han sido comprometidos antes de restaurarlos en el entorno de producción —no solo que sean recientes, sino que no hayan sido comprometidos—. En un escenario de ransomware, una copia de seguridad reciente puede estar ella misma comprometida. La capacidad de identificar y restaurar desde un punto de recuperación que se sabe que está limpio, validado antes de que sea necesario, es un requisito de soberanía, no solo un requisito de recuperación ante desastres.
  • Gestión entre entornos. Controles de soberanía y pruebas de auditoría coherentes en todo el conjunto de entornos, no solo en el entorno soberano principal. Cada entorno de la ruta de recuperación debe cumplir los mismos requisitos que el entorno principal.
  • Probado en condiciones reales. Ejercicios periódicos que comprueban la recuperación en las condiciones que realmente se darán durante un incidente: las restricciones legales aplicables, el personal disponible y los puntos de recuperación que están operativos. Una prueba anual de recuperación ante desastres que no tenga en cuenta las restricciones de soberanía no es un ejercicio preparado para la soberanía.

La pregunta que debes añadir a tu análisis sobre la soberanía

Hay una forma directa de comprobar si tu arquitectura de recuperación cumple los mismos requisitos de soberanía que tu entorno de datos principal: haz la pregunta y exige una respuesta sincera. ¿Eres capaz de recuperar tus datos soberanos, de forma limpia y dentro de los límites de tolerancia establecidos, utilizando personal que opere dentro de tus fronteras soberanas, ahora mismo —en condiciones reales, no en un ejercicio controlado—?

Para la mayoría de las organizaciones, la respuesta sincera pone de manifiesto una carencia. Las que la detecten ahora —antes de que se produzca el incidente— estarán mejor preparadas para presentar pruebas cuando el organismo regulador se las pida. Las que no lo hagan tendrán que prepararlas bajo presión, delante de las personas a las que menos quieren decepcionar. El Informe sobre la preparación para la soberanía digital incluye una pregunta sobre la evaluación de la arquitectura de recuperación directa.

Preguntas frecuentes

P: ¿Por qué es importante la recuperación para la soberanía digital?

R: La soberanía no es plena si las organizaciones no pueden recuperar los datos dentro de los mismos límites legales y operativos que se utilizan para protegerlos.

P: ¿Cuáles son los fallos más comunes en la Recovery soberana?

R: Entre los fallos más habituales se encuentran que el personal de recuperación trabaje fuera de los límites de la soberanía, que backup carezca de los controles adecuados y que la gobernanza no sea coherente en todos los entornos.

P: ¿Cómo puede la custodia de claves complicar Recovery?

R: Los modelos en los que tú mismo gestionas tu clave refuerzan la seguridad durante el funcionamiento normal, pero pueden ralentizar las tareas de recuperación en caso de incidentes si no se prueban adecuadamente.

P: ¿Qué es la validación de Recovery limpia?

R: La validación de la recuperación limpia confirma que los puntos de recuperación no se han visto comprometidos antes de restaurar los sistemas. Esto es especialmente importante en casos de ransomware.

P: ¿Cómo deberían las organizaciones poner a prueba su resiliencia de cara a la soberanía?

R: Deberían hacer simulacros realistas que tengan en cuenta las restricciones legales, la disponibilidad operativa y los puntos de recuperación validados, y no limitarse a las pruebas estándar de recuperación ante desastres.

Alex Zinin es vicepresidente y director general del área de proveedores de servicios gestionados en Commvault.

More related posts

Thumbnail-Digital-Sovereignty-2

Minimum Viable Sovereignty: Why the Right Posture Isn’t the Same for Every Organization

Read more
Thumbnail-Digital-Sovereignty-3

The Pillar Most Sovereignty Strategies Forget

Read more
Thumbnail-Digital-Sovereignty-1

You Don’t Have a Sovereignty Strategy. You Have a Residency Policy.

Read more

Puntos clave

  • La soberanía mínima viable (MVS) se centra en aplicar el nivel adecuado de control a las cargas de trabajo adecuadas.
  • Tratar todas las cargas de trabajo por igual puede generar una complejidad y unos costes innecesarios, o una protección insuficiente.
  • Las organizaciones suelen encajar en tres perfiles de soberanía: soberanía plena, empresa regulada y multicloud híbrido.
  • La gobernanza coherente en entornos mixtos es uno de los mayores retos operativos.

Existe una versión del debate sobre la soberanía digital que lleva a las organizaciones a una situación costosa, operativamente onerosa y —si somos sinceros— que va más allá de lo que exigen sus obligaciones reales. La soberanía máxima suena responsable. En la práctica, a menudo se trata de un error de calibración.

Existe una versión igualmente común que conduce a una situación peligrosamente precaria: controles que cumplen una lista de requisitos, pero que no resistirían una auditoría, un incidente o un regulador que haya dejado de aceptar la intención documentada como prueba de un control demostrado.

Las organizaciones que gestionan correctamente la soberanía tienden a adoptar un enfoque más riguroso y práctico que cualquiera de los dos extremos: se preguntan qué deben realmente, a quién y para qué. A continuación, se estructuran según ese estándar: ni más ni menos.

Esta es la disciplina del MVS, presentada en el Informe sobre la Readiness para la soberanía digital y desarrollada en detalle aquí.

El MVS no es un atajo. Es el reconocimiento de que el objetivo es el nivel adecuado de control, aplicado de forma coherente en todas las cargas de trabajo que lo requieran.

No todas las cargas de trabajo son iguales

El punto de partida de un enfoque MVS es la clasificación de las cargas de trabajo, y la mayoría de las organizaciones se saltan este paso por completo.

Un sistema de negociación que procesa datos financieros regulados conlleva obligaciones de soberanía fundamentalmente diferentes a las de una herramienta interna de colaboración de RR. HH. Una base de datos que contiene datos personales de ciudadanos de la UE está sujeta a un régimen legal y normativo diferente al de un entorno de desarrollo que ejecuta datos de prueba anonimizados.

Tratar todos estos casos de forma idéntica —ya sea aplicando los máximos controles de soberanía de forma generalizada o asumiendo que un único modelo de implementación lo abarca todo— es lo que lleva a las organizaciones a acabar con soluciones excesivamente complejas o con una protección insuficiente.

La pregunta adecuada antes de cualquier decisión de implementación es: «¿Qué requiere esta carga de trabajo en cada uno de los cuatro pilares de soberanía?». El Informe de Readiness incluye una autoevaluación estructurada precisamente en torno a esa pregunta.

Los tres perfiles —y lo que realmente necesitan—

Las empresas reguladas se clasifican en tres perfiles reconocibles, cada uno con diferentes motivaciones principales y prioridades de inversión.

  • El verdadero soberano. Organismos públicos, contratistas de defensa y operadores de infraestructuras nacionales críticas. Para estas organizaciones, la soberanía no es un requisito de cumplimiento, sino un mandato operativo. A menudo, la ley exige el máximo control sobre todas las dimensiones de la pila tecnológica, y se aceptan las compensaciones en términos de costes porque la alternativa no es viable.
  • La organización regulada. Empresas de servicios financieros, organizaciones sanitarias y empresas energéticas. Estas organizaciones se enfrentan a requisitos vinculantes derivados de la DORA, la NIS2, el RGPD y marcos específicos de cada sector. Las obligaciones de cumplimiento también pueden corresponderse con esquemas de certificación de la UE —incluidos EUCS, EUCC, BSI C5 y SecNumCloud— en función del sector y del contexto de implementación.

En determinados ámbitos, esto no es negociable —especialmente en lo que se refiere a la residencia de datos, los controles de acceso operativo y la Recovery dentro de los límites jurisdiccionales—. Pero no todas las cargas de trabajo conllevan la misma obligación.

  • La organización híbrida multicloud. Organizaciones con inversiones existentes en hiperescaladores que se enfrentan a una presión cada vez mayor en materia de soberanía por parte de clientes, reguladores o requisitos de contratación pública. Su reto no es la migración total, sino la incorporación de controles de soberanía en un entorno mixto y el mantenimiento de una gobernanza coherente en todo él.

El coste de un mal ajuste

Una sobredimensionación de la soberanía genera sus propios riesgos operativos. Las organizaciones que aplican controles de soberanía máximos a cargas de trabajo que no los requieren asumen costes y complejidad que no sirven a ningún propósito normativo ni empresarial.

La falta de ingeniería es el modo de fallo más habitual y el más peligroso. Por lo general, no se detecta hasta que llega la auditoría o, lo que es peor, hasta que se produce un incidente y la recuperación se convierte en un problema con implicaciones legales. (Ese modo de fallo es el tema de la cuarta entrada de esta serie).

Un punto de partida práctico

Un enfoque MVS sigue tres pasos:

  1. Clasificar las cargas de trabajo según sus requisitos reales de soberanía en cada pilar; no empezar por los modelos de implementación.
  2. Asignar cada clase de carga de trabajo al nivel de implementación que cumpla dichos requisitos, abarcando todo el espectro, desde las regiones de hiperescaladores públicos hasta la nube pública soberana y los entornos gestionados en las propias instalaciones.
  3. Gobernar el entorno mixto resultante de forma coherente: los controles, las pruebas de auditoría y las capacidades de Recovery deben poder demostrarse en todo el entorno, no solo en el nivel más soberano.

El tercer paso es donde la mayoría de los programas encuentran dificultades. Mantener controles de soberanía coherentes en un entorno mixto supone un reto de gobernanza operativa —y, concretamente, el ámbito de la soberanía operativa—, tema del tercer artículo de esta serie, el pilar que la mayoría de las estrategias tratan como algo secundario.

Utiliza la autoevaluación del Informe de Readiness para la soberanía digital para determinar tu situación actual en los cuatro pilares.

Preguntas frecuentes

P: ¿Qué es la soberanía mínima viable (MVS)?

R: La MVS es la práctica de aplicar controles de soberanía basados en las necesidades reales del negocio y en los requisitos normativos. Su objetivo es ayudar a evitar tanto el exceso de ingeniería como la falta de protección.

P: ¿Por qué es importante la clasificación de las cargas de trabajo?

R: Las diferentes cargas de trabajo conllevan distintas obligaciones normativas y operativas. Clasificar las cargas de trabajo ayuda a las organizaciones a aplicar el nivel adecuado de controles de soberanía.

P: ¿Cuáles son los tres perfiles de soberanía más comunes?

R: Los tres perfiles son: organizaciones verdaderamente soberanas, organizaciones reguladas y organizaciones híbridas multinube. Cada uno de ellos tiene requisitos operativos y de cumplimiento específicos.

P: ¿Qué riesgos conlleva un exceso de complejidad en la soberanía?

R: Un exceso de controles puede aumentar la complejidad operativa y los costes sin aportar un valor significativo en materia de cumplimiento normativo o empresarial.

P: ¿Por qué los entornos mixtos plantean retos de gobernanza?

R: Las organizaciones suelen operar en múltiples modelos de nube e infraestructura. Resulta difícil mantener controles, pruebas de auditoría y estándares de Recovery coherentes en todos los entornos.

Ruben Renders es director de soluciones para MSP en Commvault.

More related posts

Thumbnail-Digital-Sovereignty-4

Sovereign Data You Can’t Recover Isn’t Actually Sovereign

Read more
Thumbnail-Digital-Sovereignty-3

The Pillar Most Sovereignty Strategies Forget

Read more
Thumbnail-Digital-Sovereignty-1

You Don’t Have a Sovereignty Strategy. You Have a Residency Policy.

Read more

Puntos clave

  • La residencia de los datos se refiere al lugar donde se almacenan, pero la soberanía digital también exige tener control sobre el acceso y las operaciones, además de comprender bien las implicaciones jurisdiccionales.
  • La soberanía operativa suele ser la parte más débil y menos supervisada de la mayoría de los programas de soberanía.
  • Una estrategia de soberanía completa se basa en cuatro pilares: la localidad de los datos, la soberanía tecnológica, la soberanía operativa y la soberanía jurisdiccional. La información…
  • La soberanía no es algo binario; las organizaciones deben definir una postura que se ajuste a sus obligaciones normativas y operativas.

Aquí va una pregunta sobre la que vale la pena reflexionar: cuando tu organización tomó esa decisión sobre la soberanía, ¿qué fue exactamente lo que decidió? Para la mayoría, la respuesta es una variante de lo mismo. Elegir una región. Trasladar las cargas de trabajo. Elegir un proveedor de nube con centros de datos en el país. Marcar la casilla. Se respondió a la pregunta de dónde residen los datos y se dio por zanjado el debate sobre la soberanía.

Pero no estaba cerrado. Apenas había empezado. La residencia de datos responde a una pregunta: ¿dónde? La soberanía digital plantea tres más: ¿quién, cómo y en qué condiciones? La confusión entre residencia y soberanía es comprensible. Los hiperescaladores han hecho que la selección de la región parezca una decisión de soberanía. Las listas de verificación de cumplimiento preguntan dónde se almacenan los datos. Las directrices normativas, al menos en sus primeras versiones, se centraban en gran medida en la geografía.

Elegir una cloud soberana es algo importante: tiene su importancia, conlleva implicaciones operativas y es un primer paso necesario. Pero solo es un primer paso. Y la mayoría de las organizaciones se han quedado ahí.

Lo que «Residency» no aclara

Piénsalo de esta manera: elegir una región de nube soberana es como comprar una caja fuerte. Te indica dónde se almacenan tus objetos de valor. No dice nada sobre quién tiene una copia de la combinación, quién fabricó la caja fuerte, qué legislación rige al fabricante ni si puedes abrirla si te ves obligado a ello.

La elección de la región responde a una pregunta. Quedan otras tres totalmente sin resolver, y son precisamente estas las que los reguladores, los comités de contratación y los auditores se están planteando ahora con cada vez más precisión:

  • ¿Quién puede gestionar su entorno y desde dónde? El hecho de que el personal de soporte de su proveedor de nube esté sujeto a una jurisdicción extranjera es una cuestión de soberanía que la residencia de datos no puede resolver. Una ventana de mantenimiento rutinario realizada por un ingeniero de soporte en una jurisdicción jurídica diferente es una vía de acceso que su política de residencia no cubre. Este es el ámbito de la soberanía operativa: el pilar más difícil de auditar y el que más se suele pasar por alto.
  • ¿Bajo qué régimen jurídico se puede acceder a sus datos? El hecho de que un proveedor de tecnología extranjero opere su infraestructura en el país no significa que quede automáticamente fuera del ámbito de aplicación de la legislación de su país de origen. El alcance extraterritorial de los regímenes jurídicos extranjeros es un riesgo que la geografía por sí sola no puede eliminar.
  • ¿Puede recuperar sus datos si algo sale mal? La mayoría de los programas de soberanía se basan en el control de acceso. Muy pocos abordan la recuperación: si sus datos pueden restaurarse correctamente, dentro de unos límites definidos, por personal que opere dentro de sus límites de soberanía. Esa laguna es donde las estrategias de soberanía suelen fallar en condiciones reales.

El marco que cubre esa carencia

Una estrategia de soberanía completa se basa en cuatro pilares interdependientes. El Informe sobre la preparación para la soberanía digital —disponible en readiverse.com— los analiza en detalle. En resumen:

  • La localidad de los datos se refiere a los lugares por donde se desplazan realmente los datos y los metadatos.
  • La soberanía tecnológica abarca el control sobre el cifrado, la custodia de las claves y la portabilidad de la arquitectura.
  • La soberanía operativa se refiere a quién controla el entorno y desde dónde.
  • La soberanía jurisdiccional establece el marco jurídico que rige y afecta a todo lo anterior.

Ningún pilar por sí solo es suficiente. Una estrategia sólida de localidad de datos con controles operativos débiles no es soberanía: es residencia con riesgos no evaluados.

Lo que hace que este marco sea útil no es su complejidad, sino las preguntas que suscita. Cuando una organización analiza por primera vez su situación actual en relación con los cuatro pilares, casi siempre descubre lagunas que no sabía que existían, no porque falten controles, sino porque nunca se habían planteado esas preguntas.

La soberanía es una escala variable

Hay algo más que merece la pena mencionar: la soberanía no es un estado binario. No existe ninguna certificación que la otorgue ni ningún modelo de implementación único que la garantice. Es una postura: un conjunto de decisiones deliberadas y auditables. Y el nivel adecuado de esa postura varía según la organización, la carga de trabajo y lo que realmente se debe a los reguladores y a los clientes.

Esa calibración es precisamente en lo que consiste la soberanía mínima viable, el tema de la segunda entrada de esta serie. La confianza en la normativa se forja mucho antes de la propia auditoría, a través de requisitos claramente definidos, no de suposiciones ligadas a la ubicación geográfica. Descarga el Informe sobre la preparación para la soberanía digital para conocer el marco de cuatro pilares y una herramienta práctica de autoevaluación.

Preguntas frecuentes

P: ¿Cuál es la diferencia entre la residencia de datos y la soberanía digital?

R: La residencia de datos se centra en el lugar donde se almacenan físicamente los datos. La soberanía digital va más allá, ya que aborda quién puede acceder a los datos, cómo se gestionan los sistemas y qué jurisdicciones pueden suponer un riesgo legal.

P: ¿Por qué la selección de una región no basta para garantizar la soberanía?

R: Elegir una cloud solo tiene que ver con la ubicación geográfica. No resuelve los problemas relacionados con el acceso operativo, la exposición a riesgos legales ni las capacidades de recuperación.

P: ¿Cuáles son los cuatro pilares de la soberanía digital?

R: Los cuatro pilares son la localidad de los datos, la soberanía tecnológica, la soberanía operativa y la soberanía jurisdiccional. Juntos, conforman lo que creemos que es un marco más completo para evaluar el grado de preparación soberana.

P: ¿Por qué es tan difícil gestionar la soberanía operativa?

R: La soberanía operativa implica controlar quién puede acceder a los sistemas, desde dónde operan y bajo qué régimen jurídico. Estos controles son más difíciles de auditar que los simples requisitos sobre la ubicación de los datos.

P: ¿Es la soberanía digital una certificación fija?

R: No. La soberanía es una postura continua basada en decisiones deliberadas y verificables que varían según la organización, la carga de trabajo y el marco normativo.

Ruben Renders es director de soluciones para MSP en Commvault.

More related posts

Thumbnail-Digital-Sovereignty-3

The Pillar Most Sovereignty Strategies Forget

Read more
Thumbnail-Digital-Sovereignty-4

Sovereign Data You Can’t Recover Isn’t Actually Sovereign

Read more
Thumbnail-Digital-Sovereignty-2

Minimum Viable Sovereignty: Why the Right Posture Isn’t the Same for Every Organization

Read more

Puntos clave

  • Los ataques de vishing han aumentado drásticamente, y hay grupos organizados que están industrializando la ingeniería social para obtener acceso inicial a través de los servicios de asistencia técnica.
  • Los atacantes pasan rápidamente de las cuentas de usuarios comprometidas a identidades de máquina persistentes, como los tokens OAuth y las cuentas de servicio.
  • La mayoría de las organizaciones carecen de gobernanza y visibilidad sobre las identidades no humanas (NHI), lo que crea un importante punto ciego de seguridad.
  • Readiness eficaz depende de la correlación de las señales de identidad y de tratar las identidades de máquina como activos de alto riesgo.
  • La verdadera resiliencia requiere la capacidad de detectar y revertir los cambios no autorizados en los privilegios antes de que los atacantes logren establecerse de forma persistente.

El personal de tu servicio de asistencia técnica acaba de recibir una llamada. La persona que llamaba sabía el nombre del empleado, quién era su jefe y los cuatro últimos dígitos de su número de identificación. Solicitó un restablecimiento de contraseña. Procedimiento estándar. El técnico de TI accedió.

Esa llamada era un fraude. Y el atacante ya está dentro.

El phishing por voz —vishing— se disparó un 449 % en 2025. Los grupos de atacantes han convertido la ingeniería social en una operación escalable: reclutan a personas para realizar llamadas, redactan guiones y pagan entre 500 y 1.000 dólares por cada suplantación de identidad exitosa en el servicio de asistencia técnica. No buscan tus datos. Buscan un punto de apoyo.

Una vez dentro, los atacantes no se detienen en la cuenta de un usuario. Se mueven lateralmente: roban tokens de OAuth, crean nuevas cuentas de servicio administrativas e incorporan el acceso en credenciales del nivel de máquina que nadie supervisa. A diferencia de las contraseñas de los usuarios, esas credenciales rara vez se renuevan. No activan alertas de inicio de sesión. Pueden sobrevivir a una corrección completa del usuario original comprometido.

Para cuando tu equipo de seguridad cierre el ticket del incidente del servicio de asistencia técnica, es posible que el atacante lleve semanas actuando de forma silenciosa y persistente en tu entorno. La falta de gobernanza empeora la situación.

Menos del 25 % de las organizaciones cuentan con políticas formales para la creación o la desactivación de las NHI —las cuentas de servicio, las claves API y los tokens OAuth que ahora superan en número a los usuarios humanos en una proporción de 144 a 1—. Casi todas ellas cuentan con permisos que superan con creces lo que requiere su función.

La mayoría de las organizaciones no confían prácticamente en su capacidad para detectar un ataque dirigido a esta capa. No se trata de un fallo de prevención, sino de un fallo en la planificación de la Recovery.

Cómo se manifiesta la Readiness

La prevención en el servicio de asistencia técnica es importante —formación, verificación de devolución de llamada, confirmación fuera de banda—. Pero por sí sola no es suficiente. Los atacantes se están industrializando más rápido de lo que los programas de concienciación pueden seguirles el ritmo.

Readiness significa correlacionar las señales: una interacción con el servicio de asistencia técnica seguida inmediatamente de un restablecimiento de la autenticación multifactorial (MFA) o de la creación de un nuevo token es un indicador de alta probabilidad de compromiso.

Significa tratar las identidades de las máquinas como activos de nivel 0: regular su creación, delimitar sus permisos y supervisar cualquier escalada no autorizada. Y significa tener la capacidad de detectar y revertir rápidamente los cambios maliciosos en los privilegios, antes de que se conviertan en la nueva normalidad.

Descubre cómo la resiliencia de identidades de Commvault permite la detección rápida, la reversión y la Recovery de tu entorno de identidades.

Preguntas frecuentes

P: ¿Qué es un ataque de «vishing» en el contexto de la seguridad empresarial?

R: El vishing (phishing por voz) utiliza llamadas telefónicas para suplantar la identidad de empleados y manipular a los servicios de asistencia de TI para que concedan acceso, normalmente mediante restablecimientos de contraseñas o de la autenticación multifactorial (MFA). Se trata de una práctica cada vez más industrializada, en la que grupos organizados reclutan a personas para realizar las llamadas y utilizan guiones preescritos para maximizar las tasas de éxito.

P: ¿Por qué los atacantes se centran en las identidades de máquina tras un acceso inicial mediante vishing?

R: Las cuentas de usuarios se corrigen. Las identidades de máquina (NHI) —tokens de OAuth, cuentas de servicio, claves de API— son más persistentes y rara vez se rotan, por lo que a menudo pasan desapercibidas para la supervisión tradicional. Migrar el acceso a la capa de las máquinas permite a los atacantes mantener esa persistencia mucho después de que se haya detectado y solucionado la filtración original de las credenciales de los usuarios.

P: ¿Qué significa en la práctica la «resiliencia de la identidad»?

R: Significa que su organización puede ayudar a detectar cambios no autorizados en los privilegios casi en tiempo real y contribuir a restaurar rápidamente el entorno de identidades a un estado fiable. La detección por sí sola no es suficiente: la capacidad de revertir la actividad maliciosa y verificar que las identidades de máquina no hayan sido manipuladas (o, si lo han sido, revertirlas a un punto anterior en el que estuvieran en buen estado) es lo que distingue la Readiness de la exposición.

Vidya Shankaran es directora técnica de operaciones de Commvault.

More related posts

Thumbnail_Blog-Identity-Resilience-MachineID-2026-Linkedin

The Machine Identity Blind Spot Is Now a Primary Attack Surface

Read more
Thumbnail_Blog-Help-Desk-2026-Linkedin

When the Help Desk Becomes the Front Door to Your Entire Network

Read more
Thumbnail_Blog-SHIFT-Identity-Resilience-2026-Linkedin

Your Identity Infrastructure Is a Target. Here’s What Commvault Is Doing About It.

Read more
Thumbnail_Blog-Rise-of-AI-Agents-in-Resops-2026

Commvault and Microsoft: The Rise of AI Agents in ResOps

Read more
Thumbnail_Blog_Resilient-Against-the-AI-Machine

Resilient Against the AI Machine

Read more

Puntos clave

  • La ingeniería social a través del servicio de asistencia técnica se ha convertido en uno de los principales puntos de entrada, ya que los ataques de «vishing» (phishing por voz) están aumentando rápidamente y provocan el robo de credenciales.
  • Las identidades no humanas, como las cuentas de servicio y los tokens, son un importante punto ciego en materia de seguridad; a menudo no se gestionan y se aprovechan mucho para el movimiento lateral.
  • Active Directory (AD) es un objetivo muy atractivo debido a su control centralizado y a las posibles configuraciones erróneas.
  • La prevención por sí sola no basta; las organizaciones necesitan sistemas sólidos de detección y una capacidad de recuperación rápida para limitar los daños.
  • Las medidas operativas inmediatas —como auditar las cuentas y relacionar la actividad del servicio de asistencia con los cambios de identidad— pueden reducir considerablemente el riesgo.

AD sigue siendo uno de los principales objetivos de los atacantes porque es el núcleo de la identidad corporativa. Estudios recientes muestran que el 67 % de los incidentes implican ahora una violación de la identidad, y que los atacantes van a por sistemas críticos como AD a las pocas horas de conseguir el acceso inicial. Una vez comprometido, la recuperación puede llevar días o semanas, lo que provoca importantes trastornos en la actividad empresarial.

La pregunta que hay que hacerse no es si AD es un objetivo. Es cómo llegan los atacantes hasta allí, y por qué el camino es mucho más corto de lo que los equipos de seguridad podrían esperar.

3 pasos para llegar a un acuerdo total

Grupos de ciberdelincuentes como ShinyHunters y Scattered Spider han convertido la ingeniería social en una operación a gran escala. El phishing por voz —vishing— se disparó un 449 % en 2025. Se recluta a personas para realizar las llamadas, se les proporciona un guion y se les paga hasta 1 000 dólares en función del éxito y la tasa de acierto.

Eso significa que basta con un solo paso para lanzar un ataque: conseguir que te restablezcan la contraseña o que cambien la autenticación multifactorial (MFA). Y ya está.

A partir de esa única credencial, el atacante se desplaza lateralmente hacia entornos en la nube y virtualizados. Recogen tokens OAuth, crean nuevas cuentas de servicio administrativas e integran el acceso en credenciales a nivel de máquina. Estas identidades no humanas —cuentas de servicio, claves API, tokens— superan ahora en número a los usuarios humanos en una proporción de 144 a 1. La expansión y la sobrecarga operativa dificultan la rotación y la auditoría. Ese movimiento lateral tiene un destino: Active Directory.

La publicidad es el objetivo

AD es el sistema nervioso central de la identidad empresarial. Si lo controlas, lo controlas todo: cuentas de usuario, políticas de grupo y acceso a todos los sistemas de la red unidos al dominio. La razón por la que resulta tan atractivo para los atacantes —y tan difícil de defender— es estructural. Cualquier usuario autenticado puede leer todo el directorio. Todos los sistemas unidos al dominio heredan la confianza de este.

Los objetos de política de grupo vinculados al nodo raíz del dominio pueden utilizarse como arma para desactivar por completo los controles de seguridad. Los protocolos heredados que se mantienen habilitados por motivos de compatibilidad con las aplicaciones proporcionan un acceso directo. La propia documentación de Microsoft afirma que «la mayoría de los ataques a la identidad aprovechan errores comunes de configuración en Active Directory». Cuando un atacante llega al AD, no tiene que forzar la entrada. La puerta suele estar abierta.

La prevención es necesaria, pero no suficiente

La estructura de seguridad estándar —autenticación multifactorial (MFA), detección de endpoints y filtrado de correo electrónico— se basa en el comportamiento humano. No se diseñó para controlar la capa de identidades de máquina ni para detectar ese tipo de escalada de privilegios lenta y aparentemente legítima que caracteriza a los ataques modernos a Active Directory. Un atacante que pase de una cuenta de usuario comprometida a una cuenta de servicio y, de ahí, a una de administrador de dominio a lo largo de 72 horas puede que nunca active ni una sola alerta.

Por eso hay que cambiar el enfoque de «primero la prevención» a «primero la recuperación». La prevención sigue siendo importante. El acceso con privilegios mínimos, la auditoría de los cambios en Active Directory, el refuerzo de las configuraciones predeterminadas y la desactivación de cuentas inactivas: todas estas medidas pueden ayudar a reducir la superficie de ataque. Pero, teniendo en cuenta que la mitad de las organizaciones ya han sufrido un ataque a Active Directory, diseñar pensando solo en la prevención es sinónimo de diseñar para fracasar.

La verdadera resiliencia de las identidades requiere la capacidad de detectar escaladas de privilegios no autorizadas casi en tiempo real, revertir los cambios maliciosos antes de que se propaguen y restaurar rápidamente el entorno de identidades a un estado conocido y de confianza —no en días o semanas, sino lo suficientemente rápido como para contener el alcance del impacto—. Eso significa tratar Active Directory y la capa de identidades no humanas como activos de Nivel 0, con la misma inversión en gobernanza y recuperación que aplicarías a cualquier otro sistema crítico para la misión.

Qué hacer ahora mismo para reforzar tu identidad

La brecha entre la situación actual de la mayoría de las organizaciones y el nivel que deben alcanzar en materia de resiliencia de identidades es real. Pero se puede cerrar. Las prioridades inmediatas son poco glamurosas y de carácter operativo:

  1. Revisa qué hay en tu AD.
  2. Busca las cuentas que ya no deberían existir.
  3. Cambia las credenciales que lleven años sin usarse.
  4. Relaciona la actividad del servicio de asistencia con los eventos de creación de tokens y cuentas.

Una consulta al servicio de asistencia técnica seguida de un restablecimiento de la autenticación multifactorial (MFA) y, a continuación, la creación de una nueva cuenta de servicio es una señal de ataque muy fiable, y se puede detectar si estás atento.

El trabajo a largo plazo es de carácter estratégico: incorpora capacidad de recuperación en tu programa de identidad para que, cuando se produzca un ataque —y normalmente es cuestión de «cuándo», no de «si»—, puedas contenerlo, revertirlo e intentar restablecer la confianza antes de que el atacante consiga afianzar su posición.

Los atacantes cuentan con que tu AD no esté regulado, que tus identidades de máquina sean invisibles y que tu plan de recuperación sea meramente teórico. Cubre una de esas brechas este trimestre. Cubre las tres y habrás cambiado radicalmente la ecuación. Descubre cómo Commvault Cloud una protección integral para Active Directory: desde la evaluación de vulnerabilidades hasta la reversión con un solo clic y la recuperación completa del bosque.

Hace poco participé junto a Vidya Shankaran en el podcast STRIVE para hablar sobre la brecha de gobernanza en las identidades no humanas. Echa un vistazo a nuestro episodio aquí. Y no te pierdas el blog de Vidya: «El punto ciego de las identidades de máquina es ahora una superficie de ataque principal».

Preguntas frecuentes

P: ¿Por qué los servicios de asistencia técnica se están convirtiendo en un riesgo importante para la seguridad? R: A menudo se confía en los servicios de asistencia técnica para restablecer contraseñas y modificar la configuración de la autenticación multifactorial (MFA), lo que los convierte en objetivos atractivos para la ingeniería social. Los atacantes se aprovechan de esta confianza para conseguir acceso inicial con muy poca resistencia. P: ¿Qué papel desempeñan las identidades no humanas en los ataques?

R: La expansión desordenada y los gastos generales operativos dificultan la rotación y la auditoría de las identidades no humanas, como las cuentas de servicio y las claves API. Los atacantes las utilizan para mantener la persistencia y moverse sin ser detectados por los sistemas. P: ¿Por qué es AD un objetivo tan crítico? R: AD controla la autenticación y el acceso en toda la red. Si los atacantes logran hacerse con el control de este sistema, pueden gestionar usuarios, políticas y sistemas a gran escala. P: ¿No bastan la autenticación multifactorial (MFA) y la seguridad de los terminales para detener estos ataques? R: Estas herramientas se centran en el comportamiento humano y es posible que no detecten una escalada de privilegios lenta y que parezca legítima. Los atacantes pueden actuar siguiendo patrones normales y evitar así que se activen las alertas. P: ¿Qué significa un enfoque de seguridad que da prioridad a la recuperación? R: Significa prepararse para la realidad de que se producirán brechas de seguridad y dar prioridad a la capacidad de detectarlas, contenerlas y revertirlas rápidamente. Este enfoque ayuda a reducir el tiempo de inactividad y puede contribuir a limitar el impacto general. P: ¿Cuáles son las medidas más importantes que hay que tomar de inmediato? R: Empieza por hacer una auditoría de tu AD, eliminando las cuentas que no necesites, renovando las credenciales antiguas y vigilando si hay patrones sospechosos en las actividades relacionadas con el servicio de asistencia técnica y la gestión de identidades. Dan Conrad es tecnólogo principal y director técnico de operaciones en Commvault.

More related posts

Thumbnail_Blog-Okta-Early-Access-2026

Commvault® Extends Identity Resilience to Okta

Read more
Thumbnail_Blog-Lateral-Access-2026

Staying Resilient Against Lateral Access Exploits

Read more
Thumbnail_3_AD_Blogs_2025

Active Directory Forest Recovery: Why Manual Methods Are No Longer Viable

Read more
Thumbnail_6_AD_Blogs_2025

AD Recovery Testing: How to Know Your Recovery Plan Will Actually Work

Read more

Puntos clave

  • Las identidades no humanas (NHI) ya superan con creces en número a los usuarios humanos y están creciendo a un ritmo mucho más rápido, lo que crea una superficie de ataque importante y poco regulada.
  • Los atacantes recurren cada vez más a la ingeniería social, como el phishing por voz (vishing), para burlar las defensas humanas y acceder a las credenciales a nivel de sistema.
  • La mayoría de los NHI funcionan con permisos excesivos y carecen de una gestión adecuada del ciclo de vida, lo que contribuye a la acumulación de «deuda de identidad».
  • Las herramientas de seguridad tradicionales no detectan las amenazas en el nivel de máquina porque los NHI se comportan de forma diferente a los usuarios humanos.
  • Las organizaciones deben pasar de estrategias centradas en la prevención a enfoques centrados en la recuperación, dando prioridad a la detección rápida y la contención de los ataques basados en la identidad.

Durante la última década, la inversión en seguridad empresarial se ha centrado en el ser humano. Mejor autenticación. Autenticación multifactorial (MFA) más sólida. Simulación de phishing. Arquitectura centrada en la identidad. Estas inversiones fueron la respuesta adecuada al panorama de amenazas de aquel momento. El panorama de las amenazas ha cambiado.

Los adversarios más sofisticados de hoy en día no intentan burlar tu MFA. La están utilizando como puerta de entrada. Una llamada telefónica convincente al servicio de asistencia de TI, un restablecimiento de la MFA y una cuenta humana comprometida: esa es la vía de acceso. Lo que realmente buscan es lo que hay detrás: la capa extensa y con escaso control de los NHI que conecta todos los sistemas de tu entorno.

La magnitud del problema es abrumadora

Cuentas de servicio, claves API, tokens OAuth, agentes de IA: las NHI superan ahora en número a los usuarios humanos en una proporción de 144 a 1, y crecen entre 4 y 10 veces más rápido que las cuentas humanas. Sin embargo, menos del 25 % de las organizaciones cuentan con políticas formales que regulen su creación o baja. Casi todas ellas cuentan con permisos excesivos, derechos que superan con creces lo que requiere su función.

No se trata de un riesgo nuevo que haya surgido de repente. Es una deuda de identidad acumulada: años de provisión sin control, automatización sin rendición de cuentas, cloud sin visibilidad. Y los atacantes se han dado cuenta.

El vishing es el punto de entrada

Grupos como ShinyHunters y Scattered Spider —que operan bajo lo que los investigadores denominan el clúster Scattered LAPSUS$ Hunters (SLH)— han industrializado la ingeniería social para explotar precisamente esta brecha. El phishing por voz aumentó un 449 % en 2025. No se trata de llamadas oportunistas. Son operaciones coordinadas: guiones diseñados específicamente, personas reclutadas para realizar las llamadas e incentivos económicos de hasta 1.000 dólares por cada suplantación de identidad exitosa en el servicio de asistencia técnica.

La llamada no es el ataque. La llamada es el restablecimiento de credenciales que permite al atacante traspasar el perímetro humano. El ataque empieza cuando pasan a la capa de la máquina: robando tokens de OAuth, creando cuentas de servicio administrativas e incorporando acceso en credenciales que casi nunca se supervisan y que casi nunca se renuevan. La cuenta humana se repara. El acceso a la capa de máquinas persiste. El atacante ya ha pasado a otra cosa.

Tres vulnerabilidades que los controles tradicionales no detectan

Las herramientas de seguridad estándar se diseñan en torno al comportamiento humano. Señalan inicios de sesión anómalos, geolocalizaciones inusuales y tráfico de correo electrónico sospechoso. Los NHI funcionan de manera diferente, y esa diferencia es el punto ciego.

El uso indebido de OAuth, por ejemplo, parece tráfico normal de API, incluso tras un restablecimiento de contraseña. Miles de cuentas de servicio no documentadas operan en grandes empresas con privilegios administrativos, a menudo mucho después de que los proyectos que las crearon hayan finalizado. Las claves de API de larga duración integradas en los flujos de trabajo de DevOps conllevan un amplio acceso sin contexto de dispositivo y sin alertas de inicio de sesión. El MFA no los detecta. La detección en los dispositivos finales no los detecta. El filtrado de correo electrónico no les afecta.

El cambio de enfoque: de «la prevención ante todo» a «la recuperación ante todo»

La respuesta lógica ante una amenaza que a menudo escapa a los métodos de detección tradicionales es dejar de dar por sentado que puedes evitar todas las intrusiones y empezar a planificar una recuperación rápida ante aquellas que logren colarse. Eso significa tratar los NHI como activos de nivel 0, aplicándoles los mismos controles de gobernanza que se aplican a los administradores de dominio o a los planos cloud gestionados con identidades humanas. Significa sustituir los secretos estáticos por tokens de corta duración y rotación automática.

También significa relacionar señales de distintos ámbitos: una interacción con el servicio de asistencia técnica seguida de un restablecimiento de la autenticación multifactorial (MFA) y, a continuación, la creación de un nuevo token es un indicador de compromiso de alta fiabilidad, y detectarlo a tiempo marca la diferencia entre contener el problema y sufrir una brecha de seguridad prolongada. Significa asociar los identificadores de red (NHI) a identidades humanas para garantizar la rendición de cuentas.

Lo más importante es que significa tener la capacidad de detectar aumentos de privilegios no autorizados y revertir cambios maliciosos en las identidades en tiempo real, devolviendo el entorno a un estado conocido y de confianza antes de que el daño se extienda.

La prevención sigue siendo importante. Pero, dada la brecha de gobernanza que tienen muchas organizaciones, la velocidad de recuperación se está convirtiendo en un indicador clave de resiliencia. Las organizaciones deberían desarrollar programas de identidad pensados para los ataques que ya se están produciendo, no para los que eran habituales hace cinco años. Visita Readiverse y echa un vistazo a nuestro libro electrónico «The Non-Human Identity Crisis», que analiza en profundidad la superficie de ataque de las máquinas y el marco para la resiliencia de la identidad.

Preguntas frecuentes

P1: ¿Qué son las identidades no humanas (NHI)?

R: Los NHI incluyen cuentas de servicio, claves API, tokens OAuth y agentes de IA que permiten que los sistemas y las aplicaciones interactúen entre sí. A diferencia de los usuarios humanos, suelen funcionar de forma automática y a gran escala, lo que hace que sean más difíciles de supervisar y controlar.

Pregunta 2: ¿Por qué se considera que los NHI suponen un riesgo para la seguridad?

R: Los NHI suelen tener permisos excesivos y carecen de una gestión adecuada, lo que los convierte en objetivos atractivos para los atacantes. Como casi nunca se supervisan ni se renuevan, las credenciales comprometidas pueden permanecer sin detectar durante largos periodos de tiempo.

Pregunta 3: ¿Cómo aprovechan los atacantes los NHI?

R: Los atacantes suelen conseguir el acceso inicial mediante técnicas de ingeniería social, como el phishing por voz, y luego pasan a la capa del sistema. Roban tokens, crean nuevas cuentas de servicio o incorporan acceso persistente en credenciales que no se supervisan de cerca.

Pregunta 4: ¿Por qué las herramientas de seguridad tradicionales no detectan estas amenazas?

R: La mayoría de las herramientas de seguridad están diseñadas para detectar comportamientos humanos, como anomalías en el inicio de sesión o intentos de phishing. Los NHI generan tráfico de sistema que parece normal, lo que permite que la actividad maliciosa pase desapercibida entre las operaciones legítimas.

P5: ¿Qué se entiende por un enfoque de seguridad «centrado en la recuperación»?

R: Un enfoque centrado en la recuperación se centra en detectar rápidamente las brechas de seguridad y restablecer los sistemas a un estado seguro, en lugar de dar por hecho que todos los ataques se pueden prevenir. Esto incluye identificar los cambios no autorizados y revertirlos en tiempo real.

Pregunta 6: ¿Cómo pueden las organizaciones mejorar la seguridad del NHI?

R: Las organizaciones pueden considerar los NHI como activos críticos, aplicar políticas de gobernanza estrictas, sustituir las credenciales estáticas por tokens de corta duración y correlacionar las señales entre los distintos sistemas. Además, asociar los NHI a personas concretas mejora la rendición de cuentas y la supervisión.

Vidya Shankaran es directora técnica de operaciones de Commvault.

More related posts

Thumbnail_Blog-SHIFT-Identity-Resilience-2026-Linkedin

Your Identity Infrastructure Is a Target. Here’s What Commvault Is Doing About It.

Read more
Thumbnail_Blog-Rise-of-AI-Agents-in-Resops-2026

Commvault and Microsoft: The Rise of AI Agents in ResOps

Read more
Thumbnail_Blog-Unified-Resilience-2026

Why AI Is Breaking Your Resilience Strategy (And What to Do About It)

Read more
Thumbnail_Blog-SHIFT-Sanjay-2025-Linkedin

Re-envisioning Resilience for the Age of AI

Read more
Thumbnail_Blog_Resilient-Against-the-AI-Machine

Resilient Against the AI Machine

Read more

Hoy en día, las empresas crean aplicaciones más rápido, automatizan flujos de trabajo a gran escala y convierten los datos en información útil, todo ello gracias a plataformas como Microsoft Power Platform. Lo que empezó como una capa de productividad «low-code» se ha convertido rápidamente en algo fundamental para el negocio, integrado en los procesos que sustentan la generación de ingresos, las operaciones diarias y la toma de decisiones estratégicas.

Pero a medida que crece la dependencia de estos recursos de inteligencia empresarial, también lo hace el riesgo asociado. La misma platform la innovación también puede amplificar el impacto de los errores operativos, las configuraciones erróneas y las acciones malintencionadas. Un flujo de trabajo mal configurado, un informe borrado o una aplicación que no funciona bien pueden interrumpir los procesos empresariales, afectar a la toma de decisiones y minar la confianza en los sistemas de los que depende la empresa. Y cuando algo sale mal, la recuperación rara vez es sencilla.

Commvault te ayuda a hacer frente a estos retos con soluciones de protección y recuperación de datos de nivel empresarial para Microsoft Power Platform, empezando por Power BI, lo que permite a las organizaciones proteger los análisis, los flujos de trabajo y las aplicaciones que crean, y recuperarlos rápidamente. 

Power BI: La brecha entre el análisis y la recuperación

En el centro de muchas Platform de Power Platform se encuentra Microsoft Power BI, que ofrece análisis e inteligencia empresarial, transformando los datos en informes, previsiones y visibilidad operativa. Cuando se pierden o se ven comprometidos los recursos de Power BI, los equipos pueden perder rápidamente el acceso a información fiable, lo que interrumpe los ciclos de elaboración de informes y retrasa la toma de decisiones empresariales.

Sin embargo, en la práctica, las estrategias de protección no están a la altura de la importancia de estos activos. Muchas organizaciones dependen de exportaciones manuales de archivos o de capacidades nativas limitadas que no fueron diseñadas para una recuperación integral. Cuando algo falla, los equipos se ven a menudo obligados a reconstruir manualmente, sin poder restaurar exactamente lo que se necesita. Esto hace que la recuperación sea lenta, propensa a errores y difícil de escalar.

Commvault Cloud Backup & Recovery Microsoft Power Platform

Ya disponible para todos, Commvault Cloud Backup & Recovery Microsoft Power Platform las empresas Platform proteger y recuperar sus activos críticos para el negocio, como los informes, frente a eliminaciones accidentales, daños y actividades maliciosas.

  • Protección automatizada basada en políticas: aplica copias de seguridad basadas en políticas a todos los activos del espacio de trabajo de Power BI, lo que permite una cobertura uniforme y escalable sin necesidad de intervención manual.
  • Recuperación rápida y detallada: restaura informes y carpetas concretos a un momento específico, lo que evita tener que volver a crearlos manualmente y ayuda a minimizar el tiempo de inactividad y las interrupciones.
  • Copias de seguridad aisladas e inmutables: ayuda a proteger los datos frente al ransomware y a los cambios no autorizados con copias de seguridad diseñadas para evitar modificaciones o eliminaciones no autorizadas.
  • Cumplimiento normativo simplificado: Mantén la conservación a largo plazo (hasta 10 años), los registros de auditoría centralizados y la elaboración de informes para cumplir con los requisitos normativos e internos.

Platform unificada Platform la resiliencia

Commvault Cloud una platform unificada platform proteger cargas de trabajo SaaS, cloud y locales, como Microsoft 365, Dynamics 365, Salesforce, máquinas virtuales, bases de datos y dispositivos finales. Gracias a Platform Microsoft Power Platform , los clientes pueden optimizar la protección, la recuperación y la resiliencia de más cargas de trabajo, lo que ayuda a reducir la proliferación de herramientas y a simplificar las operaciones.

Cómo empezar

Commvault Cloud Backup and Recovery for Power Platform se ofrece como una solución SaaS, diseñada para una rápida implementación y unos gastos operativos mínimos. Las organizaciones pueden conectar su entorno de Power BI, aplicar una protección basada en políticas y comenzar a realizar copias de seguridad de los datos críticos en tan solo unos pasos.

La detección automatizada protege los nuevos informes y carpetas a medida que evolucionan los entornos, mientras que la gestión centralizada proporciona un único lugar desde el que supervisar, gestionar y recuperar datos a gran escala.

Próximos pasos: Expandirse por toda Platform Power Platform

Tenemos la intención de ampliar la protección y la resiliencia en toda Platform Microsoft Power Platform incluir Power Apps y Power Automate, ampliando así la cobertura a las aplicaciones y los flujos de trabajo que impulsan tu negocio. Los planes, los plazos y las características están sujetos a cambios y no debes basarte en ellos a la hora de tomar decisiones de compra.

Protege lo que hace funcionar tu negocio

A medida que Platform la dependencia de Microsoft Power Platform , también lo hace la necesidad de una protección robusta y de nivel empresarial. Con Commvault Cloud, puedes:

  • Protege los activos críticos contra la eliminación, la corrupción y los ataques
  • Recupera rápidamente justo lo que necesitas, sin tener que volver a montarlo todo desde cero
  • Mantén la confianza en los datos, las decisiones y la automatización
¿Estás listo para que tu inversión en Microsoft Power BI sea más resistente?

Descubre más y echa un vistazo a Commvault Cloud acción en commvault.platform.

More related posts

Thumbnail_Blog-Clumio-Chat-2026

Meet Clumio Chat: An AI Assistant to Help Evaluate Cloud-Native Data Protection

Read more
Thumbnail_Blog-Clumio-Fedramp-2026

Clumio Advances Cloud-Native Cyber Resilience with FedRAMP® Milestone

Read more
Thumbnail_Blog_Agentic-Ransomware-Attack

Cyber Resiliency for AI and Ransomware Recovery

Read more

Puntos clave

  • La migración de máquinas virtuales a Red Hat OpenShift Virtualization es un proceso por fases que requiere una protección constante en todos los entornos híbridos.
  • Una platform de protección de datos unificada y nativa de Kubernetes platform reducir la complejidad y platform eliminar la necesidad de herramientas o procesos independientes.
  • Contar con una resiliencia fiable —que incluya copias de seguridad inmutables y detección de amenazas— es fundamental durante la migración, cuando los riesgos son mayores.
  • Las opciones de recuperación flexibles permiten a las organizaciones adaptarse rápidamente si fallan los pasos de la migración o cambian los plazos.
  • Consolidar la protección de las máquinas virtuales y los contenedores ayuda a reducir la proliferación de herramientas y a mantener una gobernanza coherente.

Si hoy en día eres un responsable de TI, lo más probable es que tu estrategia de virtualización esté siendo objeto de una revisión exhaustiva. El aumento de los costes, la incertidumbre en materia de licencias y la dependencia a largo plazo de un único proveedor están haciendo que muchas organizaciones se replanteen su dependencia de los hipervisores tradicionales. Al mismo tiempo, Kubernetes ha madurado hasta convertirse en la base operativa de las aplicaciones modernas.

Estas dos realidades están convergiendo, y para muchas empresas, Red Hat OpenShift Virtualization se está convirtiendo en la opción preferida para ejecutar máquinas virtuales dentro de un modelo operativo nativo de Kubernetes. Esta transición se está acelerando en todos los sectores. A medida que las organizaciones modernizan su infraestructura a su propio ritmo, Red Hat OpenShift Virtualization se ve cada vez más como una forma de modernizar la platform necesidad de refactorizar las aplicaciones. Con ese impulso surge una pregunta clave:

¿Cómo se migran las máquinas virtuales manteniendo una protección, una resiliencia y una capacidad de recuperación constantes durante todo el proceso? Para responder a esta pregunta, tienes que analizar cómo se desarrollan realmente la mayoría de las migraciones empresariales, y en qué momentos la protección y la resiliencia se vuelven fundamentales.

La migración es un viaje, no algo que ocurre una sola vez

Los líderes con experiencia en TI saben que las transiciones de infraestructura casi nunca se producen de golpe. Para las empresas que deciden pasar de hipervisores como VMware a Red Hat OpenShift Virtualization, la transición suele desarrollarse por fases. Durante este tiempo, las organizaciones se ven inevitablemente obligadas a operar en un entorno mixto:

  • Las máquinas virtuales basadas en VMware siguen respaldando las operaciones clave de la empresa.
  • Máquinas virtuales que se acaban de poner en marcha en Red Hat OpenShift Virtualization.
  • Aplicaciones en contenedores que comparten los mismos clústeres de Red Hat OpenShift.

Este periodo de coexistencia conlleva complejidad y riesgos. Los datos están en constante movimiento, los entornos cambian y pueden surgir brechas de seguridad si las herramientas y los procesos no evolucionan al mismo ritmo que las cargas de trabajo.

Es fundamental mantener una protección fiable

Commvault lleva mucho tiempo ofreciendo soluciones de protección y recuperación de datos tanto para entornos VMware como para cargas de trabajo de Kubernetes que se ejecutan en Red Hat OpenShift. Ese mismo modelo de protección nativo de Kubernetes y basado en políticas se extiende ahora a las máquinas virtuales que se ejecutan en Red Hat OpenShift Virtualization. Lo que realmente les gusta a los clientes es la coherencia:

  • Una única platform la protección y la recuperación.
  • Operaciones basadas en políticas que se aplican de manera uniforme en todas las cargas de trabajo.
  • Diseñado para funcionar con tus herramientas y procesos actuales a medida que los entornos van cambiando.

Las máquinas virtuales que se ejecutan en Red Hat OpenShift Virtualization están protegidas mediante los mismos flujos de trabajo y mecanismos de gobernanza que las aplicaciones en contenedores. Este enfoque unificado está siendo adoptado por las organizaciones que están estandarizando sus sistemas con Red Hat OpenShift y que buscan una forma más sencilla y coherente de gestionar los datos en todos los entornos.

Esta función ya está disponible. Commvault Cloud ofrece protección para entornos de Red Hat OpenShift Virtualization compatibles con la versión de soporte a largo plazo 11.40 y la versión de innovación 11.42, lo que significa que los clientes ya pueden poner estas funciones en producción.

No deberías tener que gestionar la protección de forma diferente

Una vez que las máquinas virtuales se trasladen a Red Hat OpenShift Virtualization, no deberían necesitar ningún tratamiento especial en lo que respecta a la protección. Commvault Cloud y protege las máquinas virtuales de Red Hat OpenShift Virtualization junto con las aplicaciones en contenedores, lo que ayuda a los equipos a tener una visibilidad centralizada, una aplicación coherente de las políticas y operaciones de recuperación simplificadas. Las cargas de trabajo virtualizadas y en contenedores se gestionan de forma conjunta, sin crear silos operativos.

Para las organizaciones que gestionan carteras de aplicaciones diversas, esta forma de gestionar las máquinas virtuales dentro de Kubernetes ayuda a reducir las dificultades operativas sin dejar de mantener controles de nivel empresarial.

La ciberresiliencia es clave cuando la migración aumenta el riesgo.

Los periodos de migración son un momento especialmente vulnerable. Los cambios generan complejidad, y la complejidad aumenta el riesgo de perder datos y de sufrir ataques de ransomware. Commvault Cloud mantener la resiliencia durante toda esta fase gracias a:

  • Copias de seguridad aisladas físicamente e inmutables para cargas de trabajo de Red Hat OpenShift Virtualization.
  • Datos de copia de seguridad que facilitan la detección de amenazas y el análisis forense, lo que ayuda a los equipos a comprobar que todo está listo para la recuperación antes de restaurar las cargas de trabajo.
  • Funciones avanzadas de recuperación diseñadas para ayudar a las organizaciones a minimizar las interrupciones operativas.

Tanto si las cargas de trabajo están en fase previa a la migración, en plena transición o ya funcionando a pleno rendimiento en Red Hat OpenShift Virtualization, la resiliencia se mantiene intacta.

La flexibilidad en la recuperación te da confianza

Cualquier iniciativa de modernización necesita margen para hacer ajustes. Commvault admite tanto la recuperación in situ como fuera de sitio para las máquinas virtuales de Red Hat OpenShift Virtualization, incluyendo todo el contexto y la configuración de la máquina virtual. Si algún paso de la migración no sale como estaba previsto —o hay que ajustar los plazos—, los equipos pueden recuperarse rápidamente y seguir adelante sin comprometer la disponibilidad ni la integridad de los datos.

Protección nativa de Kubernetes más allá de las máquinas virtuales

Para muchas empresas, la virtualización es solo una parte de una estrategia más amplia de modernización de aplicaciones. Commvault Cloud ofrece protección centrada en las aplicaciones y nativa de Kubernetes para cargas de trabajo en contenedores, incluidos los volúmenes persistentes y los metadatos de las aplicaciones, en todas las distribuciones de Kubernetes certificadas por la CNCF. Esto permite la movilidad y la recuperación de las aplicaciones cloud, al tiempo que ayuda a mantener la coherencia operativa en todos los entornos.

Reducir la proliferación de herramientas a medida que evoluciona la infraestructura

Platform suelen traer consigo nuevas herramientas, nuevos procesos… y más complejidad. Al utilizar Commvault Cloud platform de protección unificada platform :

  • Máquinas virtuales de VMware.
  • Máquinas virtuales de Red Hat OpenShift Virtualization.
  • Aplicaciones en contenedores.

Las organizaciones pueden ayudar a reducir la proliferación de herramientas, simplificar la administración y mantener una gobernanza coherente, incluso a medida que evolucionan las estrategias de infraestructura.

Cómo encaja todo

En cualquier migración, es útil entender cómo encajan todas las piezas. El kit de herramientas de migración para virtualización de Red Hat se encarga de trasladar las máquinas virtuales de VMware a Red Hat OpenShift Virtualization. Commvault Cloud garantizar la protección y la resiliencia que acompañan a tus cargas de trabajo durante todo el proceso, para que los datos estén protegidos antes, durante y después de la migración. Esto puede ayudar a que la capacidad de recuperación no se quede atrás a medida que se trasladan las cargas de trabajo.

Seguimos con la conversación en la Red Hat Summit

Ya estamos trabajando con clientes que están trasladando activamente sus máquinas virtuales a OpenShift Virtualization, y vamos a seguir hablando de esto en el Red Hat Summit, del 11 al 14 de mayo en Atlanta. En el stand de Commvault, vamos a:

  • Hablando con los responsables de TI sobre los retos reales en materia de resiliencia.
  • Compartimos consejos prácticos para que puedas hacer la migración con confianza.
  • Demostración de Cloud de Commvault Cloud para Red Hat OpenShift Virtualization.

Si mantener la resiliencia y la capacidad de recuperación en toda tu estrategia de virtualización es una prioridad, nos encantaría poder hablar contigo.

Avanzando con confianza

Red Hat OpenShift Virtualization se está convirtiendo en un componente fundamental de la infraestructura empresarial moderna. Pero no puedes precipitarte con la migración a cualquier precio; tienes que integrar la protección, la resiliencia y la recuperación en el proceso desde el principio.

Con Commvault Cloud, proteger las cargas de trabajo de Red Hat OpenShift Virtualization no es una meta para el futuro. Es algo que los clientes ya están haciendo: utilizan una platform unificada platform modernizarse con confianza sin dejar de ser resilientes y de poder recuperarse.

«Red Hat OpenShift Virtualization ofrece una base fiable y consistente para que las organizaciones puedan gestionar todo su entorno virtualizado», afirma Steve Gordon, director sénior de Gestión de Productos de Cloud Híbrida en Red Hat. «Al aprovechar una integración optimizada como la de Commvault Cloud Red Hat OpenShift Virtualization, nuestros clientes pueden avanzar con mayor confianza, sabiendo que sus cargas de trabajo están protegidas de forma constante antes, durante y después de la migración».

Preguntas frecuentes

P: ¿Por qué se considera que la migración de máquinas virtuales es un proceso en varias fases?

R: La mayoría de las empresas no pueden migrar todas las cargas de trabajo de una sola vez, así que operan en un entorno híbrido en el que conviven simultáneamente los entornos antiguos y los nuevos. Este enfoque por fases añade complejidad, por lo que es fundamental contar con una protección y una visibilidad constantes durante toda la transición.

P: ¿Qué papel juega la resiliencia durante la migración de máquinas virtuales?

R: La resiliencia permite a las organizaciones mantener la protección de los datos, recuperarse rápidamente de los fallos y defenderse de amenazas como el ransomware. Durante la migración, cuando los sistemas están en constante cambio, unas medidas sólidas de resiliencia pueden ayudar a evitar la pérdida de datos y las interrupciones operativas.

P: ¿Cómo Cloud Commvault Cloud la protección en distintos entornos?

R: Commvault Cloud una platform única platform protección basada en políticas para máquinas virtuales de VMware, máquinas virtuales de OpenShift Virtualization y aplicaciones en contenedores. Este enfoque unificado permite llevar a cabo operaciones de forma coherente sin tener que introducir nuevas herramientas ni flujos de trabajo.

P: ¿Por qué es importante la protección nativa de Kubernetes?

R: La protección nativa de Kubernetes se adapta a la forma en que se implementan y gestionan las aplicaciones modernas, y abarca tanto los contenedores como las máquinas virtuales. Permite una gestión sencilla de los datos, la movilidad y la recuperación en entornos cloud.

P: ¿Cómo mejora la flexibilidad en la recuperación la confianza en la migración?

R: Las opciones de recuperación flexibles, como las restauraciones in situ y fuera de sitio, pueden ayudar a los equipos a recuperar rápidamente las cargas de trabajo si surge algún problema. Esta adaptabilidad ayuda a reducir el tiempo de inactividad y permite a las organizaciones ajustar sus planes de migración sin poner en riesgo la integridad de los datos.

P: ¿Cómo pueden las organizaciones reducir la complejidad durante las transiciones de infraestructura?

R: Al adoptar una platform unificada de protección de datos, las organizaciones pueden gestionar todas las cargas de trabajo —tanto virtualizadas como en contenedores— a través de una única interfaz. Este enfoque ayuda a reducir la proliferación de herramientas, simplificar la administración y mantener una gobernanza coherente en entornos en constante evolución.

Jason Giza es director sénior de marketing de socios de contenido global en Commvault.

More related posts

Thumbnail_Blog-Clumio-Chat-2026

Meet Clumio Chat: An AI Assistant to Help Evaluate Cloud-Native Data Protection

Read more
Thumbnail_Blog-Clumio-Fedramp-2026

Clumio Advances Cloud-Native Cyber Resilience with FedRAMP® Milestone

Read more
Thumbnail_Blog_Agentic-Ransomware-Attack

Cyber Resiliency for AI and Ransomware Recovery

Read more

Puntos clave

  • La Readiverse Academy ha puesto en marcha un programa de certificación estructurado y por niveles, que abarca desde los conocimientos básicos hasta la especialización avanzada cloud .
  • Las certificaciones se ajustan a puestos reales, lo que ayuda a los alumnos a desarrollar habilidades relevantes para sus responsabilidades en Cloud de Commvault Cloud .
  • El programa cuenta con cuatro niveles —Practicante, Especialista, Profesional y Experto— que van aumentando en profundidad y capacidad operativa.
  • El aprendizaje se basa en tres pilares fundamentales: platform , resiliencia cibernética y conocimientos sobre cargas de trabajo.
  • Las opciones de aprendizaje flexibles, que incluyen formatos a tu propio ritmo y con profesor, permiten a los profesionales avanzar según sus horarios y objetivos.

Los entornos que proteges con Commvault Cloud cada vez más complejos, y las expectativas que se tienen de tus equipos, que se encargan de gestionarlos, son más altas que nunca. Ya no basta con conocer la platform. Se trata de ser capaz de gestionarla, protegerla y recuperarla, a menudo bajo presión.

Si ya has empezado tu viaje de aprendizaje en la Readiverse Academy, bienvenido de nuevo. Y si eres nuevo por aquí, te unes en el momento perfecto. Hoy presentamos un enfoque de certificación estructurado y por niveles que ofrece a los alumnos un itinerario claro y basado en competencias, desde platform básicos platform hasta la especialización avanzada cloud.

Creamos contenido para ti

Cloud de Commvault Cloud exigen conocimientos especializados en múltiples áreas, a menudo dentro de un mismo puesto. Los administradores, los especialistas en seguridad, cloud y los responsables de cargas de trabajo necesitan conocimientos de diferente profundidad y alcance. Y no todo el mundo tiene que aprender lo mismo, en el mismo orden, para ser eficaz.

Los nuevos niveles de certificación de Readiverse Academy reflejan esa realidad. Los alumnos avanzan a través de niveles claramente definidos que se complementan entre sí, de modo que tu certificación se ajuste a lo que realmente haces y valide esas capacidades ante los equipos con los que trabajas.

  • Commvault Cloud : conocimientos básicos sobre platform la resiliencia.
  • Cloud en Commvault Cloud: mayor profundidad en materia de operaciones y seguridad.
  • Commvault Cloud : experiencia avanzada en recuperación y cargas de trabajo.
  • Commvault Cloud : liderazgo total en cloud y resiliencia.

Cada nivel se consigue mediante una combinación de trabajo en el curso, actividades prácticas de laboratorio y evaluaciones validadas. A medida que los alumnos avanzan, el alcance y la profundidad de la capacidad operativa que demuestran aumentan en consecuencia.

Un camino claro: de principiante a experto

El programa de certificación se basa en tres pilares fundamentales de competencias que están presentes en todos los niveles:

  • platform básicas platform
  • Conceptos de resiliencia cibernética
  • Carga de trabajo y experiencia en funcionalidades

Cada nivel añade requisitos específicos relacionados con esos pilares. Los alumnos pueden hacer cursos sueltos o combinar los requisitos indicados para conseguir los objetivos de certificación.

¿Ya estás en Readiverse Academy? Esto es lo que significa para ti.

Con una nueva estructura como esta, la pregunta más importante es qué significa para el progreso que ya has logrado. Si ya has completado cursos u obtenido certificaciones en Readiverse Academy, ¡enhorabuena! Tu inversión es importante y queremos dejar claro qué va a pasar a partir de ahora.

Esas certificaciones reflejan tu trayectoria y tus logros con Commvault. El nuevo programa se adapta a nuestra amplia gama de funciones de ciberresiliencia para Commvault Software, Commvault SaaS y entornos híbridos. A medida que tus necesidades crezcan y requieran más de Commvault, estos cursos y certificaciones te ayudarán a configurar, gestionar y optimizar Commvault para satisfacer las necesidades específicas de tu organización.

No existe una progresión directa desde las vías de certificación anteriores al nuevo programa, pero vuestras certificaciones actuales avalan vuestra experiencia con las versiones anteriores del producto. A medida que esas versiones se retiren, dichas certificaciones también dejarán de tener validez. Los alumnos que ya hayan invertido en la Readiverse Academy están en una posición ideal para avanzar rápidamente.

¿Quién debería hacer los cursos y las certificaciones de Readiverse Academy?

Las certificaciones de Readiverse Academy están pensadas para profesionales que trabajan con Commvault SaaS, el software de Commvault y entornos híbridos.

  • Platform que se encargan de las operaciones diarias.
  • Especialistas en seguridad dedicados a proteger datos y reforzar la seguridad de los entornos.
  • Cloud encargados de la configuración del plano de control y de la resiliencia avanzada.
  • Los responsables de las tareas que necesiten tener conocimientos especializados en ámbitos específicos de datos.

Toda la formación está disponible para que la realices a tu propio ritmo, y algunos cursos también se ofrecen en formato presencial con formador, para que puedas avanzar de la forma que mejor se adapte a tu puesto y a tu horario.

Cómo empezar o seguir con tu proceso de aprendizaje

Tanto si empiezas de cero como si sigues con tu camino, el siguiente paso es sencillo y está pensado para adaptarse a tu situación actual.

  • Inicia sesión o regístrate en commvault.com.
  • ¿Eres nuevo en Commvault? Empieza con el curso «Commvault Cloud ».
  • ¿Te encargas de la gestión de la carga de trabajo? Echa un vistazo a nuestro catálogo de cursos, que abarca prácticamente todo.
  • ¿Buscas estrategias para facilitar la recuperación tras un ciberataque? El curso sobre ciberresiliencia es tu primer paso.

¿Qué nos espera ahora?

Nuestro objetivo es que la progresión sea predecible, transparente y se ajuste a los puestos de trabajo reales, para que los alumnos sepan qué les espera a continuación y cómo prepararse para ello. Nos comprometemos a proporcionar a todos Cloud de Commvault Cloud los conocimientos necesarios para gestionar, proteger y recuperar su entorno con confianza. Porque, cuando más importa, la certificación no se reduce a unas simples credenciales. Se trata de ser resiliente y estar preparado para recuperarse.

Preguntas frecuentes

P: ¿Cuál es el objetivo del programa de certificación de Readiverse Academy?

R: El programa ofrece un itinerario de aprendizaje estructurado y basado en competencias que ayuda a los profesionales a pasar de platform básicos platform a una especialización avanzada cloud . Adapta la formación a las responsabilidades del mundo real para que los alumnos puedan aplicar sus conocimientos de forma eficaz en entornos complejos.

P: ¿Cuáles son los distintos niveles de certificación que hay?

R: Hay cuatro niveles: Commvault Cloud , Specialist, Professional y Expert. Cada nivel se basa en el anterior, aumentando en profundidad técnica, alcance operativo y capacidad de liderazgo.

P: ¿Quién debería apuntarse a los cursos de Readiverse Academy?

R: Los cursos están pensados para platform , especialistas en seguridad, cloud y responsables de cargas de trabajo que trabajen en entornos SaaS, de software e híbridos. Cada perfil puede seguir un itinerario de aprendizaje a medida según sus responsabilidades.

P: ¿Cómo se obtienen las certificaciones?

R: Las certificaciones se obtienen mediante una combinación de cursos, prácticas de laboratorio y evaluaciones validadas. A medida que los alumnos avanzan, van demostrando un nivel cada vez mayor de conocimientos especializados en los ámbitos platform, la seguridad y las cargas de trabajo.

P: ¿Qué pasa con las certificaciones actuales de Readiverse Academy?

R: Las certificaciones actuales siguen siendo válidas como prueba de la experiencia adquirida, pero están vinculadas a versiones anteriores del producto. A medida que esas versiones se retiren, las certificaciones dejarán de ser válidas, lo que animará a los alumnos a pasarse al nuevo programa.

P: ¿Cómo se puede empezar con el nuevo programa?

R: Los nuevos alumnos pueden empezar con el curso «Commvault Cloud Administrator», mientras que los usuarios que ya lo conocen pueden iniciar sesión para seguir avanzando. Hay cursos adicionales disponibles en función de objetivos específicos, como la gestión de cargas de trabajo o las estrategias de ciberresiliencia.

Suzanne Klausner es directora de Estrategia de Capacitación de Clientes en Commvault.

More related posts

Thumbnail_Blog-Ready-or-Not-2026

Why Every CIO Needs a ‘Ready. Or Not.’ Mindset

Read more
Thumbnail_Blog_Readiness-Update-2024

Boost Your Cyber Resilience and Readiness

Read more
Social_Readiverse_Blog_LinkedIn-1

The Readiverse: Your Go-To Learning Resource for Cyber Resilience and Readiness

Read more

Puntos clave

  • Los flujos de trabajo de restauración tradicionales pueden provocar desviaciones en la infraestructura de los entornos gestionados por Terraform al aprovisionar nuevos recursos fuera del estado.
  • Clumio Backtrack está diseñado para restaurar datos directamente en los buckets de S3 y las tablas de DynamoDB ya existentes, lo que ayuda a mantener la identidad de los recursos.
  • La recuperación in situ ayuda a reducir la necesidad de realizar importaciones manuales de Terraform, reconfigurar los puntos finales y conciliar el estado durante los incidentes.
  • Alinear los flujos de trabajo de recuperación con los principios de «Infraestructura como código» (IaC) ayuda a mantener la integridad de la configuración y la previsibilidad operativa.
  • El diseño de la recuperación es tan importante como backup para los equipos que gestionan entornos de producción mediante Terraform.

IaC aporta coherencia, repetibilidad y control de versiones a cloud . Terraform se convierte en la fuente de referencia sobre lo que existe, cómo está configurado y cómo debería funcionar. La recuperación plantea un nuevo reto.

Las operaciones de restauración tradicionales suelen crear nuevos recursos: nuevos buckets de S3, nuevas tablas de DynamoDB, nuevos endpoints. Desde el punto de vista de Terraform, esos recursos no se han definido en el código. No existen en el estado. Esto genera desviación. En las operaciones rutinarias, la desviación es manejable. Durante un incidente, se agrava. Aquí es donde el diseño de la recuperación es tan importante como el diseño de las copias de seguridad.

El problema de la deriva en IaC

En un modelo de restauración típico:

  • Un recurso protegido se restaura como un nuevo recurso.
  • El recurso original sigue estando dañado, sobrescrito o no funciona.
  • El estado de Terraform no reconoce el nuevo recurso.
  • Los equipos deben importar manualmente los recursos a State.
  • Puede que haya que actualizar las configuraciones de las aplicaciones.

Para platform que gestionan la infraestructura de producción a través de Terraform, esto supone un obstáculo justo en el momento menos oportuno. El reto no es backup en sí, sino cómo se integran los flujos de trabajo de restauración con las prácticas de «infraestructura como código».

Te presentamos la recuperación in situ con Clumio Backtrack

Clumio Backtrack es una función de recuperación que te ayuda a restaurar datos directamente en los recursos existentes de AWS, en lugar de tener que aprovisionar una infraestructura de sustitución. Cuando se configura a través del proveedor de Clumio para Terraform, Backtrack te permite crear flujos de trabajo de recuperación que se ajustan a la infraestructura definida en código.

Clumio Backtrack es compatible tanto con Amazon S3 como con Amazon DynamoDB. Si quieres conocer más detalles técnicos sobre los flujos de trabajo de recuperación específicos de DynamoDB, echa un vistazo a nuestra entrada del blog sobre Clumio Backtrack para DynamoDB.

En lugar de tener que buscar recursos de sustitución, Backtrack te ayuda a recuperar:

  • Objetos S3 directamente en el bucket original.
  • Datos de DynamoDB directamente en la tabla original.

Desde el punto de vista de Terraform, la idea es que la infraestructura se mantenga sin cambios, de modo que los recursos definidos sigan coincidiendo con la configuración declarada. Esto ayuda a reducir la necesidad de importar recursos manualmente, crear tablas de restauración temporales, reconfigurar los puntos de conexión y realizar la conciliación del estado en situaciones de presión.

Un ejemplo práctico

Imagina un entorno de producción gestionado íntegramente a través de Terraform. Una tabla de DynamoDB lleva el control del inventario; un bucket de S3 almacena los recursos de la aplicación; los roles y las políticas de gestión de identidades y accesos están codificados; y las políticas de protección se definen mediante Terraform. Si se produce un error antes de un pico de tráfico importante, los métodos tradicionales de restauración pueden crear nuevos recursos que habrá que volver a integrar en Terraform.

Con Backtrack, la recuperación está diseñada para realizarse dentro de los límites de los recursos existentes, lo que ayuda a mantener intacta la infraestructura definida y a conservar la identidad de los recursos. Este enfoque tiene como objetivo eliminar la necesidad de actualizar Terraform para adaptarlo a un bucket o una tabla recién creados, tratando la recuperación como una operación a nivel de datos en lugar de como un proceso de sustitución de la infraestructura.

Por qué es importante para Platform

Para los equipos que apuestan por la infraestructura como código (IaC), los flujos de trabajo de recuperación deben preservar la identidad de los recursos, la alineación de estados, la integridad de la configuración y la previsibilidad operativa. La restauración in situ contribuye a alcanzar esos objetivos al limitar los cambios en la infraestructura durante los procesos de recuperación.

Recuperación a Cloud

Backtrack está diseñado para funcionar a cloud , tanto si se trata de restaurar un pequeño número de objetos como grandes conjuntos de datos. El rendimiento de la recuperación varía en función del tamaño de la carga de trabajo y la configuración del entorno, pero el objetivo arquitectónico sigue siendo el mismo: restaurar los datos sin provocar nuevas desviaciones en la infraestructura. En los entornos gestionados con Terraform, esa distinción es importante.

Dónde encaja este enfoque

La recuperación in situ es especialmente relevante para:

  • Cargas de trabajo de DynamoDB de alto rendimiento
  • Depósitos de S3 con un gran número de objetos
  • Sistemas de producción gestionados íntegramente a través de Terraform
  • Entornos complejos en los que resulta difícil redirigir las dependencias de las aplicaciones hacia nuevos recursos

Cuando la infraestructura se define de forma declarativa, los flujos de trabajo de recuperación deberían ajustarse a esa misma disciplina.

Cómo empezar

Para conocer Clumio Backtrack y su integración con Terraform:

Definir la protección como código es solo una parte de la historia. Diseñar flujos de trabajo de recuperación que mantengan la integridad de la infraestructura es lo que completa el modelo.

Preguntas frecuentes

P: ¿Qué problema plantean las restauraciones tradicionales en los entornos gestionados por Terraform?

R: Las restauraciones tradicionales suelen crear nuevos recursos, como buckets de S3 de sustitución o tablas de DynamoDB, que no están definidos en el estado de Terraform. Esto puede provocar desviaciones en la infraestructura y obligar a los equipos a importar recursos manualmente y conciliar configuraciones durante incidentes de gran presión.

P: ¿En qué se diferencia Clumio Backtrack de los métodos de restauración habituales?

R: En lugar de aprovisionar nueva infraestructura, Clumio Backtrack está diseñado para restaurar los datos directamente en el recurso de AWS ya existente. Este enfoque ayuda a conservar la identidad del recurso y a mantener el estado de Terraform alineado con la configuración declarada.

P: ¿Qué servicios de AWS son compatibles con Clumio Backtrack?

R: Clumio Backtrack es compatible con Amazon S3 y Amazon DynamoDB. Está diseñado para restaurar los objetos de S3 en el bucket original y los datos de DynamoDB en la tabla original, lo que ayuda a mantener la coherencia con la infraestructura definida en código.

P: ¿Por qué es importante la recuperación in situ para platform ?

R: Platform recurren a la infraestructura como código para garantizar la coherencia y el control. La recuperación in situ ayuda a mantener la alineación de estados, la integridad de la configuración y la previsibilidad operativa sin introducir cambios adicionales en la infraestructura durante los procesos de recuperación.

P: ¿Cuándo resulta especialmente útil la recuperación in situ?

R: Es especialmente útil para cargas de trabajo de DynamoDB de alto rendimiento, buckets de S3 con un gran número de objetos y sistemas de producción gestionados íntegramente a través de Terraform. También puede resultar beneficioso en entornos en los que redirigir las dependencias de las aplicaciones a recursos recién creados resultaría complejo o arriesgado.

P: ¿Cómo pueden los equipos empezar a utilizar la integración entre Clumio Backtrack y Terraform?

R: Los equipos pueden consultar la documentación del proveedor de Clumio para Terraform, echar un vistazo al código fuente del proveedor en GitHub y ver el vídeo de demostración de Backtrack al que se hace referencia en el blog para entender los detalles de la implementación y el flujo de trabajo.

Lawrence Chang es el director de ingeniería de Clumio y Vir Choksi es director principal de marketing de producto en Commvault.

More related posts

Thumbnail_Blog-AWS-Data-Protection-Terraform-Clumio-2026

Automating AWS Data Protection with Terraform and Clumio

Read more
Thumbnail_Blog_Clumio-Tech-2025

Restore only what matters: Clumio Backtrack for DynamoDB

Read more
Thumbnail_Blog-GoogleWorkspace-2026

How the Move to Clumio Delivered 66.7% Savings on AWS Backups

Read more
Thumbnail_Blog_AWS-Marketplace-AI

Commvault Featured in New AI Agent Solutions in AWS Marketplace

Read more
Man-and-woman-working-on-laptops-profile-Crocus-Thumbnail

Protecting Your Amazon S3 Data with Clumio: A Comprehensive Solution

Read more

Clumio

Read more

Puntos clave

  • La mayoría de los ejercicios de simulación solo sirven para comprobar el rendimiento, en lugar de poner de manifiesto las deficiencias reales en la respuesta ante incidentes.
  • Para que los ejercicios sean eficaces, deben incluir elementos de fricción, ambigüedad y presión que reflejen situaciones reales.
  • Limitar el alcance del ejercicio a unos pocos escenarios críticos y definir el éxito como la detección de problemas, en lugar de quedar bien, puede dar lugar a conclusiones más significativas y aplicables.
  • La participación de distintos departamentos, y no solo de los equipos técnicos, es fundamental para evaluar con precisión la respuesta de la organización.
  • La verdadera resiliencia se demuestra mediante pruebas reales de recuperación, no solo con simulaciones basadas en debates.

Hay un momento que la mayoría de los responsables de seguridad reconocen, aunque no lo digan en voz alta. El ejercicio de simulación acaba de terminar. El equipo se va retirando. Todo el mundo parece razonablemente satisfecho. Y, en algún rincón de tu mente, surge una pregunta silenciosa: ¿Hemos aprendido realmente algo?

Si eres sincero, la respuesta suele ser no.

Esto no se debe a que los ejercicios de simulación sean una mala idea. Son una de las herramientas más valiosas con las que cuenta un responsable de seguridad. El problema radica en cómo los llevan a cabo la mayoría de las organizaciones, y en qué miden realmente al hacerlo.

La trampa del rendimiento

El error más común en los ejercicios de simulación no tiene nada que ver con el escenario. Tiene que ver con el objetivo. La mayoría de los equipos, de forma consciente o no, diseñan ejercicios destinados a demostrar competencia en lugar de a descubrir carencias.

El escenario suele seguir un arco narrativo claro. La información llega en una secuencia lógica. Las personas adecuadas dicen lo que deben decir. Todo el mundo se siente preparado. Y esa sensación —de confianza, de haber ensayado bien, casi de camaradería— es precisamente el problema. Los incidentes reales no siguen un guion perfecto. Se presentan con información incompleta, señales contradictorias, personas ilocalizables y una empresa que exige respuestas más rápido de lo que permiten los hechos. Si tu simulacro no genera ese tipo de fricción, es que no has puesto a prueba la respuesta ante incidentes. Solo has ensayado una conversación.

Cuando el ejercicio está diseñado para validar en lugar de poner a prueba bajo presión, surge un segundo problema: la gente deja de ser sincera. Nadie dice: «No sé a quién corresponde esa decisión» o «en realidad nunca hemos probado esa ruta de Recovery». Dicen lo que suena bien. Y las lagunas que deberían salir a la luz en un entorno controlado permanecen ocultas hasta que salen a la luz en uno real.

Lo que realmente evalúa un buen ejercicio

Antes de crear un escenario, tienes que responder a una pregunta más sencilla: ¿qué es lo que realmente quieres aprender? No 20 cosas. Tres o cuatro.

¿Es capaz tu equipo de tomar una decisión de cierre con la suficiente rapidez, y sabe todo el mundo quién tiene la autoridad para tomarla? Cuando los departamentos de seguridad, TI, jurídico y de comunicaciones se reúnen en una misma sala con prioridades contradictorias, ¿son realmente capaces de llegar a decisiones de forma conjunta? ¿Puedes explicar el impacto empresarial de un incidente con la claridad suficiente para que la dirección actúe —y no solo lo comprenda? Y si tuvieras que restaurar un sistema crítico en las próximas cuatro horas, ¿serías realmente capaz de hacerlo?

Una vez que sepas qué estás poniendo a prueba, crea un escenario con fricciones reales. Haz que una persona clave no esté disponible en mitad del ejercicio. Introduce una escalada por parte de un cliente. Haz que un regulador plantee una pregunta que el equipo no pueda responder basándose en el manual de procedimientos.

Proporciona a los participantes información incompleta y observa cómo toman decisiones a pesar de ello. El valor no reside en ver cómo la gente tiene éxito bajo presión, sino en descubrir los puntos en los que el proceso falla mientras el riesgo aún es lo suficientemente bajo como para solucionarlo.

Di esto en voz alta al principio: hoy en día, el éxito consiste en detectar problemas, no en quedar bien. Esa sola frase cambia lo que la gente se atreve a decir en la sala.

El problema de la gente

Una simulación en la que solo participen los equipos de seguridad y de TI es una conversación técnica, no un ejercicio de respuesta ante incidentes. Si el departamento jurídico no está presente, si el de comunicaciones tampoco está, y si faltan los responsables de negocio y la dirección ejecutiva, no estás poniendo a prueba cómo responde realmente tu organización ante una crisis. Lo que estás haciendo es ver cómo un grupo de gente inteligente analiza una situación hipotética. Los incidentes reales se gestionan en toda la empresa. El simulacro debería reflejar eso.

Hablar del tema no es suficiente

Aquí es donde la mayoría de las organizaciones se quedan a medio camino. Hacerlo sobre el papel es importante, pero eso no es lo mismo que tener confianza. Analizar un escenario de Recovery te aporta cierta información. Restaurar realmente un sistema te aporta otra información diferente. ¿Puedes restablecer la identidad a un momento concreto en el que el sistema estuviera limpio? ¿Puedes validar que lo que estás recuperando es fiable? ¿Puedes restaurar una aplicación de nivel 1 y confirmar que vuelve a funcionar correctamente, sin arrastrar la infección?

Esas no son preguntas que se puedan responder en una sala de reuniones. Llega un momento en el que el plan tiene que enfrentarse al entorno, y tienes que saber si encajan.

Una vez finalizado el ejercicio

La sesión de análisis te indica si el ejercicio ha servido de algo. Si la sesión de análisis inmediato es tranquila, vaga o está llena de «buenos recordatorios», el ejercicio no ha ido lo suficientemente lejos. Un ejercicio de simulación bien llevado debería dejarte con una breve lista de conclusiones reales, responsables claros y plazos concretos. Si no puedes responder a qué ha fallado, quién lo va a solucionar y para cuándo, has organizado un evento, no un ejercicio.

El objetivo nunca fue aprobar el ejercicio. Era aprender algo importante mientras el precio de equivocarse fuera solo tiempo. Echa un vistazo a nuestro último episodio del podcast STRIVE, en el que me uno a mi compañero Chris Mierzwa, director sénior de Marketing de Cartera, para charlar a fondo sobre los ejercicios de simulación.

Preguntas frecuentes

P: ¿Por qué la mayoría de los ejercicios de simulación no aportan un valor real?

R: Muchos ejercicios están pensados para que los equipos parezcan preparados, en lugar de para detectar puntos débiles. Esto da lugar a debates preestablecidos que no reflejan la imprevisibilidad ni la presión de los incidentes reales.

P: ¿Qué objetivo debería perseguir un ejercicio de simulación?

R: Debería centrarse en responder a unas pocas preguntas clave, como la rapidez en la toma de decisiones, la claridad en la responsabilidad y la capacidad de recuperación. Este enfoque ayuda a los equipos a descubrir carencias importantes, en lugar de quedarse en observaciones superficiales.

P: ¿Cómo pueden las organizaciones hacer que los simulacros sean más realistas?

R: Introduce incertidumbre, información que falta y contratiempos inesperados durante el escenario. Estos elementos obligan a los equipos a pensar de forma crítica y a actuar bajo presión, en condiciones más parecidas a las de un incidente real.

P: ¿Quién debería participar en un ejercicio de simulación?

R: Además de los equipos de seguridad y TI, deberían participar equipos como el jurídico y el de comunicación, así como los responsables de negocio y los ejecutivos. Así, el simulacro reflejará cómo se gestionan los incidentes reales en toda la organización.

P: ¿Por qué no basta con hablar sobre la recuperación?

R: Las conversaciones pueden poner de relieve los planes, pero solo las pruebas reales demuestran si los sistemas se pueden restaurar de verdad de forma limpia y rápida. La validación práctica es necesaria para confirmar que todo está listo para la recuperación.

P: ¿Qué define un resultado satisfactorio en un ejercicio de simulación?

R: Un ejercicio bien hecho da lugar a conclusiones claras, responsables asignados y plazos definidos para la corrección. Si faltan estos elementos, es probable que el ejercicio no haya supuesto un reto suficiente para el equipo.

Chris Bevil es director del área de Ciberresiliencia Global e Inteligencia Artificial en Commvault.

More related posts

Thumbnail_Blog-Commvault-Enhancements-Cyber-Recovery-2026

Commvault Enhancements in Cyber Recovery

Read more
Readiverse-Featured-Image-888-x-500

Ready Is Good. Resilient Is Better.

Read more
Thumbnail_5_MV_Blogs_2025

Recovery Testing: The Missing Piece in Most Cyber Resilience Programs

Read more
Urgent-Need-for-Cyber-Resilience

The Urgent Need for Cyber Resilience

Read more
Thumbnail_Blog_Modern-Playbook-2025

Your Modern Playbook for Rapid Response and Clean Recovery

Read more

Puntos clave

  • La gestión del acceso a los datos de Commvault, con tecnología de Satori, unifica la visibilidad, el control de acceso y la auditabilidad en datos estructurados, archivos no estructurados, SaaS y cargas de trabajo de IA.
  • Una política de acceso única y coherente puede regir tanto a los usuarios humanos como a los modelos de IA, lo que ayuda a reducir los silos y a limitar la sobreexposición de los datos sensibles.
  • La detección, clasificación y evaluación continua de riesgos ayudan a ofrecer información priorizada sobre dónde se encuentran los datos confidenciales y dónde es mayor el riesgo de exposición.
  • El enmascaramiento y la ocultación dinámicos basados en políticas ayudan a garantizar el acceso con el mínimo privilegio, lo que permite el uso autorizado de los datos y, al mismo tiempo, contribuye a proteger los campos confidenciales.
  • Los registros de auditoría centralizados y casi en tiempo real ofrecen una visibilidad completa de las consultas de los usuarios, las indicaciones de la IA y los eventos de acceso regulado, lo que ayuda a garantizar el cumplimiento normativo y la rendición de cuentas.

Ahora que la IA está integrada en todos los flujos de trabajo, desde copilotos y asistentes de chat hasta herramientas de análisis, todos estos dispositivos consumen datos sin parar. Las funciones de gobernanza del acceso a los datos de Commvault, con tecnología de Satori, están diseñadas para sacar más partido a esa IA tan ávida de datos, unificando la visibilidad, el control de acceso y la auditabilidad en todo tu entorno de datos.

Una base unificada para la gestión de datos en la era de la IA

Las funciones de gobernanza del acceso a los datos de Commvault agrupan las bases de datos estructuradas, los archivos no estructurados de SaaS y las cargas de trabajo de IA bajo un único modelo de gobernanza, en lugar de tratarlas como silos independientes. Ahora, las organizaciones pueden aplicar una única política de acceso tanto a los usuarios humanos como a los modelos de IA, de modo que las mismas reglas determinen quién o qué puede ver la información confidencial, independientemente de dónde se encuentre.

Al integrar Satori en el Commvault Command Center, estas capacidades amplían la protección tradicional de Commvault a los datos en tiempo real y al uso de la IA, y no solo a las copias de seguridad y las instantáneas. Esto ayuda a los equipos de seguridad y protección de datos a pasar de una respuesta reactiva ante incidentes a un control proactivo sobre cómo se detectan, se accede a ellos y se utilizan los datos en tiempo real.

Detección, clasificación y evaluación de riesgos continuas

Uno de los pilares fundamentales de nuestras capacidades de gobernanza de datos es la detección y clasificación unificadas de los datos en todas las nubes y SaaS. A medida que las organizaciones se conectan a entornos como AWS, Azure, Google Cloud, Snowflake, Databricks y otros, Commvault mapea automáticamente los almacenes de datos y los clasifica de forma continua, tanto si los datos son estructurados como no estructurados.

A cada activo se le asigna una puntuación de riesgo, lo que ofrece a los equipos una visión priorizada de dónde se encuentra la información sensible y dónde es más probable que haya exposición. En lugar de depender de análisis periódicos, la platform al movimiento de datos, a los nuevos almacenes y a los cambios de clasificación, lo que ayuda a los equipos a detectar problemas antes y a centrarse primero en las áreas de mayor riesgo.

Acceso con privilegios mínimos mediante enmascaramiento dinámico y censura

La protección de datos tradicional suele limitarse a saber dónde están los datos confidenciales; las funciones de Commvault se centran en controlar cómo se revelan esos datos. Mediante el enmascaramiento y la censura basados en políticas, las organizaciones pueden aplicar el principio del «privilegio mínimo», de modo que los usuarios, los servicios y los modelos de IA solo vean la información específica a la que tienen acceso, con los campos confidenciales anonimizados u ocultos según sea necesario.

Como se aplican las mismas políticas de enmascaramiento y ocultación en todos los entornos conectados, las organizaciones pueden proteger el acceso de forma coherente, en lugar de aplicar reglas fragmentadas, aplicación por aplicación. Esto ayuda a reducir el riesgo de sobreexposición de datos, es decir, cuando demasiadas personas o sistemas tienen acceso a más datos de los que realmente necesitan.

Seguridad y gestión rápida y segura

Una de sus capacidades más destacadas es la seguridad basada en IA y en políticas, que funciona a nivel de solicitud y respuesta. Antes incluso de que los datos se envíen a un modelo de IA, Commvault, con tecnología de Satori, puede interceptar la interacción, detectar campos sensibles (como datos personales sujetos a normativa) y aplicar el enmascaramiento o la censura en línea según las políticas de acceso a los datos existentes.

A diferencia de las soluciones que simplemente bloquean las indicaciones al completo o se basan únicamente en la prevención de pérdida de datos en las fases posteriores (con lo que la seguridad pasa a ser problema de otros), este enfoque permite a los empleados seguir utilizando los asistentes de IA de forma productiva, al tiempo que mantiene los datos confidenciales bajo control. Como la censura se produce antes de que el modelo procese los datos, también ayuda a evitar que la información confidencial influya o contamine los conjuntos de datos de entrenamiento de la IA, protegiendo tanto a los usuarios como al entorno de IA en general.

Los registros de auditoría centralizados facilitan el cumplimiento normativo

El último elemento de nuestras capacidades de gobernanza del acceso a los datos es un registro de auditoría completo y centralizado. Cada interacción —ya sea una consulta de un usuario, una solicitud de IA o un evento de acceso regulado— se registra con detalles como quién accedió a qué, qué política se aplicó y qué datos se ocultaron, casi en tiempo real.

Esta visibilidad unificada de las auditorías abarca datos en tiempo real, indicaciones de IA y eventos de gobernanza del acceso, lo que ofrece a los responsables de seguridad, TI y cumplimiento normativo un único registro fiable, en lugar de registros dispares procedentes de herramientas puntuales. Para los CISO y los CIO, esto se traduce en revisiones de cumplimiento más rápidas y una prueba clara de que la gobernanza no solo está documentada sobre el papel, sino que se aplica de forma activa en todo el entorno.

Ayudamos a las organizaciones a implementar la IA de forma segura

En conjunto, estas nuevas funciones ofrecen a las organizaciones una forma coherente de gestionar los datos en un mundo impulsado por la IA: visibilidad unificada en la nube, SaaS e IA; una única política para usuarios y modelos; enmascaramiento y censura dinámicos para un acceso con privilegios mínimos; y protección de las indicaciones de la IA basada en políticas y respaldada por registros de auditoría completos. El resultado es un cambio de los controles reactivos a una gobernanza proactiva del acceso a los datos preparada para la IA, lo que ayuda a los equipos a adoptar la innovación en IA sin perder el control sobre su información más sensible.

Preguntas frecuentes

P: ¿En qué se diferencia el enfoque de Commvault sobre la gobernanza de datos basada en la IA de la protección de datos tradicional?

R: La protección de datos tradicional suele centrarse en las copias de seguridad y la respuesta a incidentes una vez que se ha producido la exposición. Commvault amplía la gobernanza a los entornos en producción y a las interacciones con la IA, lo que permite un control proactivo sobre cómo se detectan, se accede a ellos y se utilizan los datos en tiempo real. Este cambio ayuda a las organizaciones a gestionar el riesgo antes de que se convierta en una violación de seguridad.

P: ¿Cómo mejora la seguridad el proceso unificado de detección y clasificación?

R: El descubrimiento y la clasificación continuos mapean y etiquetan automáticamente los datos estructurados y no estructurados en las nubes y las plataformas SaaS. Al asignar puntuaciones de riesgo a cada activo, los equipos obtienen una visión priorizada de la exposición de los datos sensibles. Esto permite identificar más rápidamente las áreas de alto riesgo y centrar mejor los esfuerzos de corrección.

P: ¿Qué es el enmascaramiento dinámico y por qué es importante para las cargas de trabajo de IA?

R: El enmascaramiento y la redacción dinámicos limitan lo que los usuarios, los servicios y los modelos de IA pueden ver en función de políticas predefinidas. Los campos sensibles pueden anonimizarse u ocultarse sin impedir el acceso legítimo a los datos relevantes. Este enfoque favorece la productividad al tiempo que ayuda a reducir el riesgo de sobreexposición.

P: ¿Cómo funciona la protección de las indicaciones de IA basada en políticas?

R: La seguridad de IA basada en políticas intercepta las solicitudes y las respuestas antes de que los datos lleguen al modelo de IA. Ayuda a detectar información confidencial y a aplicar el enmascaramiento o la supresión en línea de acuerdo con las políticas existentes. Esto permite a los empleados seguir utilizando herramientas de IA, al tiempo que contribuye a mantener los datos regulados bajo control y fuera de los conjuntos de datos de entrenamiento.

P: ¿Cómo ayudan los registros de auditoría centralizados a cumplir con la normativa?

R: El registro de auditoría exhaustivo recoge detalles sobre quién ha accedido a qué datos, qué políticas se han aplicado y qué censuras se han producido. Esta visibilidad unificada abarca tanto los datos en tiempo real como las interacciones con la IA, lo que ayuda a proporcionar a los responsables de seguridad y cumplimiento normativo un registro claro y fidedigno. Contribuye a agilizar las revisiones y a demostrar que los controles de gobernanza se aplican de forma activa.

P: ¿Cómo ayudan estas capacidades a las organizaciones a adoptar la IA de forma segura?

R: Al combinar una visibilidad unificada, una aplicación coherente de las políticas, el enmascaramiento dinámico y registros de auditoría completos, las capacidades de gobernanza de datos de Commvault ayudan a proporcionar a las organizaciones un marco coherente para gestionar los datos en la era de la IA. Estos controles fomentan la innovación al tiempo que ayudan a mantener el control sobre la información confidencial. El resultado es un camino más seguro y con mayor confianza hacia la adopción de la IA.

Nico Guerrera es director técnico sénior de marketing en Commvault.

More related posts

Social_Blog_Satori_GigaOm_Leader_2026_Linkedin

Satori Named Leader in GigaOm’s Data Access Governance Radar Report

Read more
Thumbnail_Blog-Conversational-Resilience-2025-Linkedin

Conversational Resilience: The New Way to Manage and Protect Enterprise Data

Read more
Thumbnail_Blog_Satori-Acquisition-2025

Commvault Closes Acquisition of Satori, Strengthening Data and AI Security Platform

Read more
Thumbnail_Blog-Data-Rooms-2025-Linkedin

Data Activate: Unlocking the Power of Trusted Data for AI Innovation

Read more