Cohesity Agent Resilience aborda la brecha de recuperación que crean los agentes de IA
Cohesity presentó Cohesity Agent Resilience el 16 de septiembre, ampliando la protección de recuperación a los agentes de IA y a los sistemas que pueden modificar. La nueva capacidad llega con una promesa más exigente: automatizar una mayor parte de la respuesta cibernética sin eliminar la aprobación humana.
Esta distinción importa porque los agentes empresariales se están convirtiendo en operadores activos, no en asistentes pasivos. Conservan memoria, invocan aplicaciones, actualizan bases de datos y ejecutan flujos de trabajo. La detección puede revelar una acción perjudicial, pero por sí sola no puede restaurar al agente ni revertir cada recurso afectado.
Cohesity trata al agente, su estado y su infraestructura conectada como un único sistema recuperable. Commvault, Druva y Rubrik persiguen enfoques relacionados, convirtiendo la recuperación de agentes de IA en una nueva competencia dentro del mercado de protección de datos.
Cohesity Agent Resilience protege más que al agente
Cohesity Agent Resilience considera que la memoria y la configuración de un agente de IA son un estado operativo recuperable.
Cohesity anunció la capacidad durante su evento virtual Catalyst 2026, celebrado en varias regiones los días 16 y 17 de septiembre. La empresa ya había indicado que Catalyst presentaría nuevos controles para entornos multiagente y flujos de trabajo de recuperación autónoma.
El estado de un agente incluye el contexto y la configuración almacenados que influyen en su comportamiento. Si instrucciones maliciosas, desviaciones de configuración o memoria corrupta alteran ese estado, restaurar una base de datos no restaurará necesariamente el criterio del agente.
Cohesity afirma que su nueva capacidad crea opciones de recuperación a un momento específico para ese estado. Los administradores pueden devolver un agente afectado a una versión conocida y fiable en lugar de reconstruirlo y perder su contexto acumulado.
La protección también se extiende a la infraestructura que rodea al agente. Según la descripción general de recuperación de agentes, ese alcance puede incluir aplicaciones, bases de datos, sistemas de archivos, almacenes de memoria y otros servicios que el agente utiliza o administra.
Este alcance más amplio aborda un problema básico del software basado en agentes. Un agente puede seguir funcionando mientras su memoria está corrupta, o recuperarse dejando cambios perjudiciales en los sistemas conectados.
Por ello, Cohesity separa dos tareas de recuperación. Una restaura el estado fiable del agente. La otra identifica y recupera los recursos afectados por sus acciones.
La empresa utiliza mecanismos consolidados de protección de datos para ambas tareas. Entre ellos se incluyen instantáneas, copias de seguridad inmutables y entornos de recuperación aislados, a menudo denominados salas limpias.
Una sala limpia es un entorno separado que se utiliza para inspeccionar y restaurar sistemas sin reconectarlos inmediatamente a producción. Ofrece a los equipos de respuesta espacio para comprobar si los componentes recuperados siguen comprometidos.
La empresa también describe una topología de agentes que vincula cada agente con su memoria, aplicaciones, bases de datos e infraestructura de soporte. Este mapa de relaciones busca mostrar brechas de protección e identificar todo lo necesario para una recuperación fiable.
Cohesity Agent Resilience admite inicialmente Amazon Bedrock AgentCore y Bedrock Agents. Algunos clientes seleccionados ya pueden acceder a la solución, mientras que la disponibilidad general está prevista para finales de 2026. Las plataformas Microsoft Azure y Google siguen en la hoja de ruta.
Estos límites hacen de este un lanzamiento inicial centrado, no una capa universal de recuperación de agentes. Cohesity debe demostrar que el modelo funciona en distintas nubes, marcos de agentes, sistemas de memoria y estructuras de permisos.
El anuncio aun así modifica el límite de la recuperación. Las plataformas de copia de seguridad tradicionalmente protegen datos y aplicaciones. Cohesity sostiene ahora que la memoria operativa de un agente debe estar dentro de ese límite porque puede influir directamente en la actividad de producción.
Los detalles comunicados sobre el lanzamiento y la hoja de ruta también están documentados en la cobertura original sobre resiliencia de agentes. La idea central es sencilla: las empresas necesitan una forma de recuperar tanto al actor como a los activos que este modificó.
Los agentes de IA ponen bajo presión los planes de recuperación tradicionales
Un agente de IA amplía la superficie del incidente porque una decisión comprometida puede propagarse por varios sistemas conectados.
La planificación tradicional de recuperación suele asumir que los equipos pueden identificar las cargas de trabajo dañadas, restaurar copias limpias y validar el entorno resultante. Los agentes de IA complican esa secuencia porque conservan contexto y realizan acciones a través de los límites entre aplicaciones.
Pensemos en un agente interno de soporte con acceso a tickets, registros de clientes y repositorios de conocimiento. Una instrucción corrupta podría hacer que divulgue información, cambie clasificaciones o introduzca material incorrecto en varios sistemas.
Restaurar la base de datos de tickets podría recuperar registros eliminados. No eliminaría la instrucción comprometida de la memoria del agente ni mostraría qué acciones posteriores requieren revertirse.
El mismo problema aparece en las operaciones de software. Un agente que puede modificar configuraciones, crear solicitudes de despliegue o gestionar recursos en la nube puede generar una cadena de cambios perjudiciales aunque correctamente autenticados.
Es posible que esas acciones no se parezcan a una intrusión convencional. El agente puede utilizar credenciales legítimas e interfaces aprobadas mientras opera con contexto contaminado o una configuración defectuosa.
Por eso Cohesity plantea la recuperación de agentes de IA como un problema de resiliencia, no solo de monitorización. La monitorización registra el comportamiento. La recuperación establece un punto fiable y restaura los sistemas dañados después de ese punto.
Vasu Murthy, director de producto de Cohesity, resumió directamente la brecha: la detección puede mostrar que un agente se desvió de su curso, pero no puede deshacer los cambios. Esta afirmación explica por qué la empresa protege tanto el estado como las dependencias.
La presión recae primero sobre los equipos de seguridad e infraestructura. Deben decidir qué memorias de agentes importan, con qué frecuencia capturarlas y cómo coordinar la recuperación de los recursos conectados.
Los equipos de ingeniería de IA enfrentan una carga relacionada. Deben exponer suficiente información para que los sistemas de protección identifiquen versiones de agentes, configuraciones, almacenes de memoria, permisos y dependencias externas.
Los propietarios de aplicaciones también pasan a formar parte de la cadena de recuperación. Restaurar un agente limpio tiene un valor limitado si sus bases de datos, controles de identidad o aplicaciones empresariales siguen en un estado inconsistente.
El problema organizativo puede resultar más difícil que el problema de almacenamiento. Equipos distintos pueden ser responsables del agente, de su acceso al modelo, de los datos subyacentes y de cada aplicación conectada.
El concepto de topología de Cohesity intenta hacer visibles estas relaciones antes de un incidente. Un mapa actualizado de dependencias puede indicar a los equipos de respuesta qué sistemas requieren investigación y qué orden de recuperación mantiene la coherencia.
Este mapeo también respalda los objetivos de tiempo de recuperación y los objetivos de punto de recuperación. Un RTO define la rapidez con que debería volver un servicio, mientras que un RPO define cuánto estado reciente puede permitirse perder una organización.
Estas mediciones se vuelven menos claras para un agente. Restaurar la memoria de ayer puede borrar contexto útil, mientras que restaurar la memoria de hoy puede preservar la corrupción que provocó el incidente.
Por ello, los equipos necesitarán políticas que distingan el conocimiento duradero del estado transitorio. También deben decidir qué acciones de los agentes pueden revertirse automáticamente y cuáles requieren revisión empresarial.
La propuesta de Cohesity presiona a otros proveedores de copias de seguridad porque los clientes esperarán que los planes de recuperación sigan este límite de sistema más amplio. Proteger solo archivos o cargas de trabajo parece incompleto cuando el software autónomo puede modificar ambos.
El problema también alcanza a las empresas que no han adoptado agentes altamente autónomos. Incluso los agentes limitados pueden redactar resúmenes, clasificar registros, invocar herramientas o activar flujos de trabajo que influyen en decisiones posteriores.
La resiliencia de agentes no está reservada, por tanto, a sistemas plenamente autónomos. El umbral relevante es si el software puede conservar estado o realizar cambios significativos sin revisar cada acción con una persona.
La nueva competencia enfrenta la recuperación de agentes de IA de Cohesity con controles fragmentados
La competencia de mercado no consiste simplemente en Cohesity frente a otro proveedor; enfrenta la recuperación unificada de agentes de IA con controles desconectados de monitorización, copia de seguridad y aplicaciones.
Las empresas ya disponen de herramientas que abordan partes del riesgo de los agentes. Los sistemas de observabilidad capturan trazas, las plataformas de identidad gestionan accesos, los registros de aplicaciones documentan cambios y los productos de copia de seguridad preservan datos.
El problema de recuperación aparece entre esas capas. Un equipo de respuesta ante incidentes puede identificar una sesión sospechosa de un agente y aun así carecer de una forma coordinada de restaurar su memoria y todas las dependencias afectadas.
Cohesity quiere que su plataforma de datos se convierta en esa capa de coordinación. Puede utilizar sus instantáneas y copias inmutables existentes, al tiempo que añade conocimiento sobre la topología y el estado de los agentes.
Este enfoque proporciona a un proveedor consolidado de copias de seguridad un punto de entrada natural. La empresa ya gestiona copias de recuperación y entornos aislados para muchos clientes.
Sin embargo, la infraestructura existente no resuelve automáticamente la semántica de los agentes. Una plataforma debe saber qué elementos de memoria, archivos de configuración, prompts, herramientas, credenciales y cambios de aplicaciones pertenecen a un punto de recuperación específico.
Los competidores avanzan hacia el mismo problema desde direcciones diferentes. AgentCloud de Rubrik pone el acento en las operaciones, la gobernanza, la observabilidad de agentes y una capacidad de reversión para acciones no deseadas.
Rubrik también está abriendo sus datos de resiliencia cibernética a los agentes de clientes mediante Model Context Protocol, o MCP. MCP es una interfaz estándar a través de la cual los sistemas de IA pueden acceder a herramientas y datos externos bajo controles definidos.
Esta estrategia permite a los agentes razonar sobre información de recuperación e iniciar flujos de trabajo gobernados. Los recientes detalles de integración de MCP muestran la rapidez con la que las plataformas de recuperación se están convirtiendo en componentes invocables dentro de sistemas de IA más amplios.
Commvault ha anunciado AI Protect, diseñado para descubrir agentes e inventariar sus dependencias en entornos conectados. Sus registros previstos incluyen modelos, configuraciones, fuentes de datos, aplicaciones e infraestructura.
Druva ha descrito protección para agentes, acceso a información de copias de seguridad mediante agentes y respuestas automatizadas ante presuntos ataques de IA. Esto combina la recuperación de agentes con la investigación asistida por agentes.
Estos enfoques se solapan, pero cada uno enfatiza un punto de control distinto. Cohesity se centra en el estado recuperable y los recursos conectados. Commvault destaca el descubrimiento recurrente. Druva combina protección con investigación de seguridad, mientras que Rubrik vincula la gobernanza con operaciones reversibles.
Los clientes deben examinar hasta qué punto cada plataforma comprende las dependencias de los agentes. Un producto que captura la configuración sin mapear los recursos posteriores resuelve solo la mitad del problema.
También deben examinar la cobertura de marcos. El soporte inicial de Cohesity para AWS Bedrock proporciona una superficie de integración definida, pero muchas empresas desarrollan agentes con marcos personalizados y servicios de nube mixtos.
Una plataforma de recuperación debe gestionar esos entornos sin obligar a que cada agente adopte el modelo de orquestación de un único proveedor. Las interfaces abiertas pueden ayudar, pero también amplían los permisos y las decisiones de seguridad que los administradores deben gestionar.
Es probable que la presión competitiva favorezca a los proveedores que conecten tres capacidades. Deben descubrir las relaciones entre agentes, preservar versiones confiables y orquestar una recuperación coherente en todos los sistemas dependientes.
Ningún proveedor ha demostrado todavía que esto pueda funcionar de forma universal en las pilas de agentes empresariales. Los anuncios de producto marcan la dirección, mientras que la evidencia en producción determinará si la recuperación unificada supera a los controles fragmentados.
La ventaja de Cohesity es su base de recuperación existente. Su desafío consiste en demostrar que esa base puede representar el estado en constante cambio de los agentes con suficiente precisión para permitir una restauración segura.
La resiliencia cibernética autónoma sigue dependiendo del criterio humano
El plan de automatización de Cohesity puede reducir el trabajo repetitivo, pero no puede eliminar la necesidad de decidir qué debe preservar una recuperación segura.
Junto con Cohesity Agent Resilience, la empresa presentó una visión más amplia denominada Autonomous Cyber Resilience. Utiliza flujos de trabajo agénticos para automatizar partes de un marco de resiliencia de cinco pasos.
Estos pasos abarcan la protección, la capacidad de recuperación, la remediación de amenazas, la práctica de recuperación y la mejora continua de la postura de riesgo de datos e IA. El sistema propuesto descubriría activos de forma continua, evaluaría la protección, validaría la preparación para la recuperación y actualizaría los planes.
Cohesity describe un flujo de trabajo en el que los administradores establecen objetivos empresariales mediante Cohesity Copilot. A continuación, la plataforma evalúa las cargas de trabajo relevantes y recomienda políticas de protección, análisis de amenazas y simulacros de recuperación.
Los humanos aprobarían esas recomendaciones antes de su ejecución. Durante un incidente, los administradores podrían iniciar flujos de trabajo automatizados que evalúan el impacto, detectan indicadores de actividad de atacantes y preparan un entorno de recuperación aislado.
Este modelo es más prudente que una remediación totalmente autónoma. Otorga al software la responsabilidad del descubrimiento, el análisis, la preparación y la orquestación, mientras mantiene la aprobación en manos de operadores humanos.
Ese límite es importante porque las decisiones de recuperación implican objetivos en conflicto. El punto de restauración disponible más reciente podría conservar un estado corrupto. Un punto de restauración anterior podría eliminar la amenaza, pero perder transacciones recientes.
Los flujos de trabajo agénticos pueden reunir evidencia y probar opciones, pero las organizaciones aún necesitan personas responsables que elijan entre esos resultados. La decisión correcta depende de las prioridades empresariales y del contexto del incidente.
Cohesity afirma que el modelo se basa en RecoveryAgent, que ya coordina partes de la respuesta a incidentes y la recuperación. También planea ampliar Cohesity Maestro, una capa de interfaz que conecta las capacidades de resiliencia con herramientas externas de IA.
La empresa espera que Maestro funcione con sistemas como Claude, ChatGPT, Gemini y su consola de gestión Helios. Cohesity ya ha descrito cómo los flujos de trabajo de Claude pueden acceder a su inteligencia de resiliencia mediante MCP y habilidades de agentes.
Estas integraciones ofrecen una flexibilidad útil. Los equipos de seguridad pueden acceder a información de recuperación desde el entorno de IA en el que ya investigan incidentes.
También crean otra superficie de control. Cualquier agente que pueda consultar datos de recuperación o preparar acciones necesita permisos estrictamente delimitados, identidad fiable, registros exhaustivos y resultados revisables.
Un sistema de automatización comprometido no debe obtener acceso sin restricciones tanto a los activos de producción como a sus copias de recuperación. La separación de funciones sigue siendo importante incluso cuando un agente coordina el proceso.
La expresión resiliencia cibernética autónoma también puede ocultar distintos niveles de automatización. El descubrimiento automático de activos conlleva menos riesgo operativo que la restauración automática de aplicaciones de producción.
Las recomendaciones de políticas se sitúan en algún punto intermedio. Pueden ahorrar trabajo administrativo, pero una recomendación deficiente se vuelve relevante cuando los equipos la aprueban sin comprender sus supuestos.
El actual tutorial de automatización de Cohesity muestra que las capacidades fundamentales ya conectan el descubrimiento de datos con las decisiones continuas de protección. Una automatización comercial más amplia llegará de forma gradual.
Este enfoque por etapas es sensato porque el sistema necesita evidencia en cada nivel. La precisión del descubrimiento, la calidad de las políticas, la preparación de entornos limpios y la coherencia de la recuperación deben medirse por separado.
La mayor incertidumbre no es si los agentes pueden ejecutar los pasos de recuperación. El software de automatización lleva años coordinando tareas de infraestructura.
La incertidumbre es si la plataforma puede mantener un modelo suficientemente preciso de las dependencias empresariales mientras cambian las aplicaciones y los agentes. Una topología desactualizada podría producir una recuperación técnicamente exitosa, pero operativamente incompleta.
La aprobación humana no elimina ese riesgo. Los revisores necesitan explicaciones claras sobre lo que encontró el flujo de trabajo, lo que excluyó, qué puntos de recuperación seleccionó y qué grado de confianza tiene.
La resiliencia cibernética autónoma será creíble cuando haga que esos juicios sean inspeccionables. La velocidad importa durante un incidente, pero la velocidad sin explicación puede multiplicar el daño.
Lo que Cohesity Agent Resilience aún no ha demostrado
El anuncio define un modelo de recuperación creíble, pero la cobertura en producción y los resultados medibles de recuperación siguen sin verificarse.
La primera limitación es la disponibilidad. Algunos clientes seleccionados pueden usar Cohesity Agent Resilience ahora, mientras que la disponibilidad general está prevista para finales de 2026.
Un despliegue controlado puede ayudar a Cohesity a perfeccionar el descubrimiento y la recuperación de agentes. También significa que la mayoría de los clientes potenciales aún no pueden comparar el producto con sus entornos completos de producción.
La segunda limitación es el alcance de la plataforma. La compatibilidad inicial se centra en Amazon Bedrock AgentCore y Bedrock Agents, mientras que los entornos de Azure y Google siguen previstos.
Los agentes empresariales suelen abarcar varios servicios. Un agente puede ejecutarse en una nube, recuperar documentos de otra plataforma, llamar a una aplicación SaaS y almacenar memoria en una base de datos externa.
Recuperar solo la parte compatible podría crear un estado inconsistente. Cohesity tendrá que mostrar cómo funcionan la topología y la restauración cuando parte de esa cadena se encuentra fuera de su control directo.
La tercera limitación implica la granularidad de la recuperación. El estado de un agente puede incluir prompts, memoria a corto plazo, memoria a largo plazo, definiciones de herramientas, configuraciones de modelos, políticas de acceso y registros externos.
No todos los componentes deberían volver a la misma marca de tiempo. Algunos registros pueden seguir siendo válidos después de que comenzó un incidente, mientras que un único elemento de memoria contaminado puede ser la causa real.
Restaurar un paquete de estado completo podría eliminar trabajo legítimo. Restaurar de forma demasiado limitada podría dejar intacto el compromiso.
Cohesity no ha proporcionado públicamente resultados detallados de rendimiento para estos escenarios. Los compradores deberían buscar evidencia sobre la precisión del descubrimiento, el tiempo de restauración, la coherencia de las aplicaciones y la cantidad de conciliación manual necesaria.
También deberían preguntar cómo gestiona el sistema las dependencias compartidas. Dos agentes pueden escribir en la misma base de datos o utilizar el mismo almacén de memoria, lo que dificulta la recuperación individual.
La identidad introduce otro problema sin resolver. Devolver un agente a una configuración limpia no revoca necesariamente un token comprometido ni corrige privilegios excesivamente amplios.
Un proceso de recuperación completo debe coordinarse con los sistemas de identidad y acceso. De lo contrario, el agente restaurado puede heredar la misma vía que permitió el problema.
La cuarta limitación se refiere a las recomendaciones automatizadas. Cohesity afirma que su plataforma puede evaluar la postura y proponer políticas, estrategias de análisis y planes de simulacros de recuperación.
Esos resultados son afirmaciones de la empresa hasta que los clientes los validen en incidentes reales y entornos complejos de aplicaciones. Los compradores deberían evaluar la calidad de las recomendaciones en lugar de tratar la automatización como un resultado en sí mismo.
La propia investigación de Cohesity añade urgencia, pero no valida el producto. Su quinto informe anual sobre resiliencia cibernética concluyó que el 78 por ciento de las organizaciones encuestadas centran sus esfuerzos de recuperación en restaurar sistemas en lugar de mantener las operaciones empresariales.
Esa cifra respalda el argumento de la empresa de que la restauración técnica puede quedarse corta. No demuestra que Agent Resilience o los flujos de trabajo autónomos cierren la brecha.
La distinción entre recuperación de sistemas y recuperación empresarial sigue siendo útil. Una aplicación restaurada puede depender de servicios de identidad, datos actuales, acceso de los empleados y otras aplicaciones antes de que las operaciones puedan reanudarse.
Cohesity destacó este problema durante su evento Catalyst, donde la empresa planteó la recuperación en torno a restaurar un negocio mínimo viable en lugar de infraestructura aislada.
Ese enfoque eleva el estándar adecuado. Los clientes deberían evaluar la recuperación de agentes según si se reanudan procesos empresariales confiables, no según si una instantánea se montó correctamente.
La quinta limitación es la responsabilidad. Si un flujo de trabajo automatizado recomienda la secuencia de restauración equivocada, las organizaciones necesitan un registro de por qué tomó esa decisión y quién la aprobó.
La gobernanza no puede limitarse a un botón de aprobación humana. Los revisores necesitan suficiente contexto para que la aprobación sea significativa, especialmente cuando la presión de un incidente incentiva una acción rápida.
Ninguna de estas cuestiones invalida la dirección de Cohesity. Definen la evidencia necesaria para pasar de una arquitectura plausible a un sistema operativo fiable.
Tres señales mostrarán si la estrategia funciona
La estrategia de Cohesity debe evaluarse a través de la cobertura de la plataforma, resultados de recuperación verificados y los límites establecidos en torno a la automatización.
La primera señal es la disponibilidad general antes de finales de 2026. Ese lanzamiento debería incluir documentación clara sobre el estado protegido, el descubrimiento de dependencias, la secuenciación de la restauración y las configuraciones no compatibles.
La compatibilidad más amplia con nubes será tan importante como la fecha. Los avances en las integraciones de Microsoft y Google demostrarían que Cohesity puede extenderse más allá de una implementación de AWS estrechamente controlada.
Un lanzamiento retrasado o una cobertura limitada de marcos debilitaría la afirmación de que la plataforma puede convertirse en una capa general de recuperación para agentes empresariales.
La segunda señal es la evidencia de clientes. Cohesity necesita ejemplos que muestren a un agente regresando a un estado confiable mientras las aplicaciones y los datos conectados permanecen coherentes.
La evidencia útil informaría sobre el tiempo de recuperación, la cantidad de dependencias descubiertas, las restauraciones fallidas o incompletas y el trabajo manual requerido posteriormente.
La prueba más sólida involucraría incidentes realistas en lugar de demostraciones preparadas. La corrupción de configuración, la memoria contaminada, los permisos excesivos y las escrituras posteriores no deseadas deberían generar distintos desafíos de recuperación.
Los clientes también deberían buscar ejercicios repetidos. Una recuperación exitosa una sola vez dice menos que pruebas periódicas que demuestren que el sistema se mantiene actualizado a medida que cambian los agentes y las aplicaciones.
La tercera señal es cómo Cohesity amplía la resiliencia cibernética autónoma. La empresa afirma que añadirá automatización a medida que el modelo se acerque a la disponibilidad comercial.
La pregunta crítica es qué decisiones siguen siendo recomendaciones y cuáles se convierten en acciones ejecutables. El descubrimiento automático y la preparación de entornos limpios difieren de seleccionar automáticamente puntos de restauración de producción.
Los controles de aprobación transparentes reforzarían el caso de Cohesity. Esos controles deberían mostrar la acción propuesta, la evidencia de respaldo, el impacto esperado, los activos excluidos y una vía de reversión.
La estrategia se debilitaría si la autonomía avanza más rápido que la auditabilidad. La automatización de la recuperación debería reducir el tiempo de respuesta sin ocultar la responsabilidad.
El comportamiento de los competidores aportará contexto adicional en torno a las tres señales. Es poco probable que Commvault, Druva y Rubrik dejen la protección de agentes como una categoría de funciones limitada.
Sus respuestas pueden establecer expectativas comunes para el mapeo de topologías, la reversión de agentes, el estado inmutable y las integraciones abiertas. También pueden poner de manifiesto brechas en la cobertura de Cohesity.
Para los compradores empresariales, el paso práctico consiste en inventariar qué pueden modificar hoy sus agentes. Los equipos deben identificar los almacenes de memoria, las credenciales, las aplicaciones, las bases de datos y la infraestructura vinculados a cada agente importante.
Este ejercicio revelará si los planes de respaldo existentes cubren toda la cadena operativa. También mostrará dónde debe integrarse un producto de recuperación de agentes de IA con los controles de identidad, aplicaciones y seguridad.
Las organizaciones que desarrollan flujos de trabajo internos de conocimiento deberían aplicar la misma disciplina a las dependencias de información. Una base de conocimientos de IA bien mantenida puede ayudar a los equipos a comprender qué material fuente guía las decisiones humanas y automatizadas.
Cohesity Agent Resilience apunta a un cambio necesario: la planificación de recuperación debe tener en cuenta a actores de software que recuerdan y actúan. El éxito del producto depende ahora de si puede restaurar esos actores sin perder consistencia, contexto ni control.
Antes de confiar la recuperación a la automatización, plantee una pregunta concreta: ¿puede el sistema explicar exactamente qué restaurará, qué dejará intacto y por qué? Si la respuesta es incompleta, mantenga firmemente el control de aprobación humana.
