La solución de problemas agéntica de HPE Zerto lleva la IA en la nube a la recuperación local
HPE Zerto ha lanzado un sistema de solución de problemas agéntico con tres roles de agente, pero su característica más importante es dónde operan esos agentes. El entorno de ejecución de solución de problemas agéntica de HPE Zerto se encuentra dentro del entorno de cada cliente. Examina localmente señales activas de recuperación ante desastres, mientras envía consultas seleccionadas de inferencia y conocimiento a Amazon Web Services.
Esta división desafía la suposición de que los agentes empresariales útiles deben trasladar datos operativos a una aplicación centralizada en la nube. HPE Zerto, en cambio, ubicó la orquestación junto a la infraestructura investigada. Amazon Bedrock proporciona acceso a modelos, recuperación de conocimiento, barreras de protección y controles de apoyo sin convertirse en el hogar de todo el flujo de trabajo de solución de problemas.
El sistema entró en producción en el segundo trimestre de 2026. HPE y AWS afirman que más del 20 % de los clientes de Zerto lo adoptaron posteriormente. También informan una reducción del 10 % en los casos de soporte en los flujos de trabajo cubiertos por el sistema. Estas cifras proceden de las empresas y no han recibido validación independiente.
El resultado arquitectónico importa más allá de un único producto de recuperación. Los entornos de recuperación ante desastres combinan registros sensibles, configuraciones cambiantes, estrictos controles de acceso y una intensa presión de tiempo. Un asistente que no puede ver las condiciones actuales ofrece consejos genéricos. Un agente con acceso sin restricciones crea un riesgo operativo distinto.
HPE Zerto intenta ocupar el estrecho espacio entre esos dos resultados. Sus agentes reciben acceso estructurado a información local, dividen las investigaciones por dominio técnico y devuelven una respuesta condensada a través de un único orquestador de control. La cuestión central es si esa arquitectura puede preservar el contexto, la seguridad y un comportamiento predecible a medida que los entornos reales se vuelven más complejos.
La solución de problemas agéntica de HPE Zerto comienza dentro del entorno del cliente
El cambio definitorio no es la interfaz de chat. Es la ubicación del entorno de ejecución del agente junto a los sistemas y las pruebas que debe investigar.
HPE Zerto Software admite recuperación ante desastres, protección continua de datos y ciberresiliencia en infraestructuras híbridas y multinube. Los operadores utilizan el producto para supervisar cargas de trabajo protegidas, preparación para la recuperación, salud de la replicación y exposición a acuerdos de nivel de servicio.
Tradicionalmente, la solución de problemas en ese entorno requiere información de varios lugares. Un administrador puede inspeccionar una alerta, examinar el registro de un componente, revisar datos de configuración, buscar documentación del producto y comparar los hallazgos con un manual operativo. Durante una interrupción, cada transferencia entre esas fuentes añade retrasos y crea oportunidades para pasar por alto pruebas relevantes.
El nuevo sistema incorpora una experiencia de chat dentro de la interfaz de gestión existente de Zerto. Los operadores pueden consultar el estado de los grupos de protección, alertas recientes, prácticas de configuración, retrasos de replicación, errores de actualización o problemas activos del sistema. El asistente también puede mostrar problemas de salud y orientar las medidas de mitigación.
Según la descripción de la arquitectura conjunta, HPE implementa la capa agéntica como un pod dentro del entorno local del cliente. Un pod es un grupo desplegable de contenedores que se ejecuta como una unidad de aplicación. En este diseño, contiene el entorno de ejecución local del agente.
El entorno de ejecución utiliza Strands Agents, un marco de código abierto desarrollado por AWS para crear agentes guiados por modelos. El historial de sesión permanece almacenado localmente, y los agentes acceden a información activa de Zerto mediante un servidor local de Model Context Protocol.
Model Context Protocol, o MCP, define una forma estándar para que una aplicación de IA llame herramientas y obtenga datos contextuales. HPE integró las API existentes de Zerto Manager en un servidor MCP, proporcionando a los agentes acceso estructurado a información actual del entorno.
Esto difiere de forma sustancial de copiar cada registro y cada dato de configuración en un chatbot remoto. Los agentes de Zerto pueden solicitar los hechos locales necesarios para una investigación mientras el entorno de ejecución permanece dentro del dispositivo. HPE afirma que solo las solicitudes de inferencia de modelos y las consultas a Amazon Bedrock Knowledge Bases salen de la red local mediante HTTPS.
La distinción requiere una formulación cuidadosa. El sistema no está completamente desconectado de la nube ni es una implementación de modelo sin conexión. Amazon Bedrock sigue procesando solicitudes de modelos, mientras que su servicio gestionado de conocimiento recupera información relevante sobre el producto. El diseño local controla la orquestación y el acceso operativo, en lugar de eliminar el procesamiento externo.
Ese límite crea la tensión central del artículo. Un agente operado localmente puede mantenerse cerca de pruebas sensibles, pero su razonamiento sigue dependiendo de servicios de modelos remotos y de solicitudes salientes cuidadosamente diseñadas. Por tanto, la utilidad del sistema depende de qué contexto cruza ese límite, cómo se filtra y si la orientación resultante sigue estando fundamentada.
El lanzamiento también integra la asistencia de IA más profundamente en el flujo de trabajo de recuperación. Ya no se limita a explicar la documentación. El sistema puede inspeccionar las condiciones actuales y elaborar una investigación específica del problema, lo que aumenta tanto su valor operativo como el coste de una conclusión errónea.
Un diseño de centro y radios mantiene a un agente bajo control
HPE Zerto dividió la solución de problemas entre agentes especializados, manteniendo a la vez un único orquestador como punto de control para la delegación y las respuestas finales.
La arquitectura utiliza un agente orquestador y al menos dos subagentes especializados. El orquestador gestiona directamente las preguntas rutinarias y delega investigaciones más profundas cuando un problema requiere análisis especializado.
Un subagente se centra en Zerto Manager, también llamado ZVM. Investiga áreas como fallos de servicios, problemas de red y errores de actualización. Sus herramientas proporcionan acceso a datos relevantes del entorno, mientras que las competencias de dominio identifican conocimientos técnicos y patrones reconocibles en los registros.
Otro subagente se centra en Zerto Replication Engine, o VRA. Gestiona problemas de replicación, redes entre sitios, errores de instalación y retrasos. Recibe sus propias herramientas, instrucciones, conocimiento de dominio y contexto de trabajo.
Esta división refleja una importante decisión de ingeniería. Dar a un único agente general todos los registros, herramientas, instrucciones y detalles de conversación puede generar un contexto sobredimensionado con señales en competencia. También dificulta aislar fallos porque el mismo componente realiza el enrutamiento, el análisis y la generación de respuestas.
En cambio, HPE utiliza una estructura de centro y radios. El orquestador se sitúa en el centro y los agentes especializados operan como radios. Los subagentes informan al agente principal en lugar de llamarse entre sí directamente.
AWS describe este patrón multiagente como agentes-como-herramientas, donde un agente coordinador invoca especialistas a través de interfaces delimitadas. Cada especialista puede utilizar un prompt, contexto, modelo y conjunto de herramientas independientes.
Para Zerto, esa separación aporta tres beneficios prácticos. Primero, una investigación con muchos registros no llena el contexto del orquestador con material de diagnóstico sin procesar. El especialista devuelve un informe más breve con sus hallazgos, en lugar de todo su proceso de trabajo.
Segundo, cada agente se vuelve comprobable de forma independiente. Los ingenieros pueden evaluar si el especialista de VRA selecciona las herramientas adecuadas sin exigir que cada prueba atraviese un comportamiento de ZVM no relacionado. Esta separación puede facilitar la localización de regresiones.
Tercero, el orquestador mantiene la responsabilidad de la respuesta final. HPE afirma que elimina secretos y registros sin procesar antes de presentar los resultados al usuario. Una única ruta de salida también proporciona al producto un lugar para aplicar reglas de respuesta.
La estructura de centro y radios restringe la autonomía lateral. Si un especialista descubre que otro componente es responsable del problema, devuelve esa observación al orquestador. No invoca de forma independiente a un agente par.
Esta restricción reduce la posibilidad de que conversaciones recursivas entre agentes consuman tokens sin llegar a una decisión. También crea una secuencia trazable para la observabilidad. Toda delegación comienza y termina en el mismo punto de control.
La contrapartida es una posible fricción de enrutamiento. El orquestador debe reconocer correctamente cuándo una pregunta requiere especialización y seleccionar el agente adecuado. Un especialista también debe condensar sus hallazgos sin eliminar pruebas esenciales para el diagnóstico final.
HPE utiliza distintos perfiles de modelo para estas responsabilidades. El trabajo rutinario puede permanecer en el orquestador, mientras que las investigaciones con mayor carga de razonamiento pueden usar un modelo más potente. La empresa afirma que inicialmente evaluó modelos más grandes para establecer la viabilidad y luego comparó alternativas según la calidad de respuesta, la latencia y el coste.
Este enfoque multimodelo evita tratar cada solicitud como una tarea de igual dificultad. Comprobar el estado de un grupo de protección no requiere el mismo presupuesto de razonamiento que interpretar una secuencia prolongada de fallos entre registros y estado de red.
También desplaza la selección de modelos de una decisión puntual de adquisición a un proceso continuo de ingeniería. A medida que cambian los modelos fundacionales, HPE puede reevaluar qué modelo se adapta a cada agente sin reconstruir todo el producto en torno a un flujo de trabajo específico de un proveedor.
Los datos activos de recuperación son la ventaja y el riesgo
El sistema se vuelve útil cuando puede consultar la infraestructura actual, pero ese mismo acceso hace que la fundamentación, los permisos y la selección de herramientas sean críticos.
Un agente de solución de problemas necesita más que manuales de producto. La documentación puede explicar qué significa una alerta, pero no puede revelar si un motor de replicación concreto está retrasado, qué ruta de red está fallando o si un cambio reciente de configuración afectó a la preparación para la recuperación.
HPE conecta sus agentes a datos operativos activos mediante un servidor MCP local. El servidor expone API seleccionadas de Zerto Manager como herramientas estructuradas. En lugar de pedir a un modelo de lenguaje que interprete un volcado de datos sin procesar, el agente puede llamar a una operación definida y recibir un resultado tipado.
La especificación pública de MCP separa herramientas, recursos y prompts mediante una interfaz cliente-servidor acordada. Para el software empresarial, esa estructura puede convertir una API de producto existente en una capa accesible para agentes sin reescribir los servicios operativos subyacentes.
El acceso tipado ayuda, pero no garantiza un diagnóstico correcto. El agente aún debe elegir la herramienta adecuada, proporcionar parámetros válidos, interpretar la información obtenida y conectarla con documentación relevante.
HPE combina herramientas locales con Amazon Bedrock Knowledge Bases. La generación aumentada por recuperación, o RAG, recupera material fuente relevante antes de que el modelo cree una respuesta. El objetivo es fundamentar la orientación en documentación y manuales operativos aprobados del producto, en lugar de basarse únicamente en la memoria del modelo.
El servicio de bases de conocimiento de Amazon gestiona la recuperación de documentos y puede devolver material fuente relevante para una consulta. En el diseño de Zerto, ese conocimiento externo complementa el estado del entorno local obtenido mediante MCP.
La distinción entre esas fuentes importa. La documentación del producto describe el comportamiento esperado. Las API locales describen el estado actual del cliente. Una solución de problemas fiable exige que el agente compare ambos sin confundir un procedimiento genérico con pruebas sobre el incidente activo.
Considere una pregunta sobre retraso de replicación. La documentación podría enumerar limitaciones de ancho de banda, interrupciones de red, cambios en la carga de trabajo o el estado del appliance como posibles causas. Las herramientas locales deben determinar qué condiciones existen en el entorno del cliente. Una respuesta útil debe acotar las posibilidades en lugar de repetir la lista completa.
HPE afirma que los agentes especialistas también utilizan habilidades de dominio que contienen patrones de registros conocidos. Estas habilidades proporcionan al modelo orientación estructurada para reconocer señales asociadas con componentes y fallos concretos.
Después, el sistema debe preservar la procedencia internamente. Los ingenieros deberían poder distinguir un hallazgo respaldado por datos en tiempo real de una hipótesis inferida por el modelo. La cuenta publicada de AWS describe telemetría, evaluaciones y resultados estructurados, pero no revela el comportamiento completo de citación que se muestra a los administradores.
El control de acceso presenta otro punto de presión. Una herramienta MCP amplia puede exponer más información operativa de la que requiere una pregunta. Una herramienta limitada reduce la exposición, pero puede omitir el contexto necesario para el diagnóstico. Por tanto, diseñar el límite de la herramienta se convierte en una decisión de seguridad y producto, no simplemente en una tarea de integración.
El etiquetado de solicitudes por tenant añade otro control. La arquitectura utiliza etiquetas de roles de AWS Identity and Access Management asociadas con cada tenant. CloudWatch, DynamoDB y Lambda permiten supervisar el uso y aplicar límites por tenant.
Amazon Bedrock Guardrails revisa los prompts y las salidas en torno a la inferencia del modelo. La documentación de AWS indica que sus controles de guardrails pueden filtrar contenido seleccionado, detectar ataques de prompt, restringir temas denegados y enmascarar información sensible.
Estos filtros reducen riesgos concretos, pero no pueden verificar cada conclusión operativa. Una respuesta puede mantenerse dentro de un tema aprobado y aun así recomendar la corrección equivocada. Los guardrails regulan los límites del contenido, mientras que la evaluación y la lógica de producto deben abordar la corrección técnica.
Por eso, la arquitectura local de HPE no debe interpretarse como una simple afirmación de privacidad. La orquestación local reduce la recopilación centralizada y mantiene la ejecución de herramientas cerca del entorno. No elimina la necesidad de controles sobre datos salientes, diseño de autorización, pruebas de riesgo del modelo o criterio humano durante incidentes de alto impacto.
Respuestas probadas de HPE Zerto, rutas de herramientas, latencia y tokens
HPE trató la evaluación como un sistema operativo, no como una única prueba de precisión realizada antes del lanzamiento.
La evaluación de agentes es difícil porque la respuesta final es solo un resultado observable. Un agente puede producir una respuesta plausible tras seleccionar la herramienta equivocada, utilizar evidencia irrelevante o seguir una ruta excesivamente costosa. Ese comportamiento podría fallar en condiciones ligeramente distintas.
HPE creó sus pruebas con PyTest y el kit de desarrollo de software de evaluación de Strands Agents. Creó trabajos que ejecutan repetidamente una suite más amplia a medida que cambian los agentes, los modelos y los prompts.
La primera categoría de pruebas cubre consultas básicas. Cada prueba proporciona una única solicitud y evalúa la respuesta. Este enfoque encaja con preguntas estables que tienen un resultado esperado claro o criterios de puntuación definidos.
La segunda categoría evalúa conversaciones de varios turnos. Un modelo simulador de usuario interactúa con el agente después de la consulta inicial, y la conversación completa recibe una evaluación. Este formato prueba si el sistema solicita la información faltante y mantiene el contexto a lo largo de varios intercambios.
La tercera categoría genera pruebas dinámicas. El generador de experimentos de Strands crea casos a partir de criterios seleccionados, lo que ofrece a HPE una forma de explorar escenarios no representados en un conjunto de pruebas fijo. La generación dinámica amplía la cobertura, aunque las pruebas generadas siguen necesitando criterios significativos y revisión.
Cada prueba puede aplicar cuatro evaluadores. Un evaluador de respuesta puntúa la contestación según requisitos predefinidos. Un evaluador de trayectoria examina si el agente seleccionó las herramientas adecuadas y siguió una ruta aceptable.
Un evaluador de latencia comprueba el tiempo de finalización frente a un umbral. Un evaluador de tokens comprueba si el uso se mantiene dentro de límites definidos. En conjunto, estas medidas reflejan la disyuntiva de producción entre calidad diagnóstica, tiempo de respuesta y consumo de inferencia.
La evaluación de trayectoria es especialmente importante para un agente operativo. La redacción final puede parecer correcta incluso cuando el sistema llegó a ella mediante una secuencia insegura o poco fiable. Probar la ruta puede revelar que un agente omitió la verificación en tiempo real, invocó una API no relacionada o se basó en documentación cuando había datos actuales disponibles.
La suite de evaluación también respalda el diseño multimodelo. HPE puede comparar un modelo más pequeño con uno más grande utilizando los mismos criterios de respuesta, trayectoria, latencia y tokens. Esto convierte la sustitución de modelos en una decisión empírica, en lugar de asumir de forma general que un modelo más grande siempre rinde mejor.
El sistema transmite el progreso de la investigación a la interfaz mediante Server-Sent Events. SSE es un mecanismo web que permite a un servidor enviar actualizaciones continuamente a un navegador a través de una sola conexión. Los usuarios pueden ver el progreso mientras un especialista examina un problema.
HPE afirma que el streaming mejoró la experiencia de usuario porque los operadores ya no esperan sin recibir información. En la recuperación ante desastres, el progreso visible también ayuda a distinguir una investigación en curso de una interfaz bloqueada.
Sin embargo, la actividad transmitida puede crear una falsa sensación de confianza si muestra pasos sin explicar su valor probatorio. Una lista de llamadas a herramientas no equivale a un diagnóstico verificado. La interfaz debe presentar suficiente progreso para generar confianza sin convertir el razonamiento interno en una puesta en escena.
La misma cautela se aplica a las afirmaciones de adopción de HPE. La empresa informa de que más del 20 por ciento de los clientes utiliza activamente el sistema y de que los casos de soporte aplicables se redujeron un 10 por ciento. Estos resultados sugieren un uso real del producto, pero la publicación pública no define el uso activo, el periodo de medición ni la población de flujos de trabajo cubierta.
Una reducción de casos de soporte también tiene varias explicaciones posibles. El agente podría resolver problemas con éxito, redirigir a los usuarios hacia documentación existente, modificar cómo se clasifican los casos o desalentar algunas escalaciones. Datos independientes sobre tasas de resolución y resultados ofrecerían una perspectiva más clara.
Para los equipos de ingeniería que consideran un diseño similar, la lección no es que cuatro evaluadores resuelvan la fiabilidad. La lección es que los agentes en producción necesitan un comportamiento medible en varias capas. La calidad de las respuestas, la elección de herramientas, la capacidad de respuesta y el uso de recursos pueden fallar de forma independiente.
Una base de conocimientos de ingeniería con capacidad de búsqueda sigue un principio relacionado. La recuperación resulta más útil cuando los documentos se mantienen organizados, actualizados y conectados con el trabajo que realizan los ingenieros.
Las plataformas de recuperación en la nube afrontan ahora una cuestión de interfaz
La presión competitiva está pasando de las funciones de replicación por sí solas a quién puede interpretar el estado de recuperación y guiar a un operador durante un incidente.
HPE Zerto compite en un mercado que ya incluye servicios de recuperación nativos de la nube. Amazon Elastic Disaster Recovery replica cargas de trabajo locales y en la nube compatibles en un área de preparación dentro de una cuenta de AWS. Los operadores pueden iniciar instancias de recuperación para simulacros o incidentes reales.
El servicio de recuperación de AWS hace hincapié en la replicación continua, la recuperación a un momento dado, las pruebas no disruptivas y el failback. Está estrechamente integrado con la infraestructura de AWS y se orienta a la recuperación en Amazon EC2.
Microsoft Azure Site Recovery administra la replicación, el failover y el failback para máquinas virtuales y servidores físicos compatibles. Su plataforma de recuperación cubre la replicación de Azure a Azure y varios escenarios locales con Azure como destino de recuperación.
Estos servicios no se corresponden directamente con cada implementación de Zerto. HPE Zerto admite patrones operativos híbridos más amplios y mantiene su propia arquitectura de producto. La comparación relevante aquí no es una lista de comprobación de funciones de replicación.
La nueva presión se refiere a la interfaz operativa por encima de esas funciones. Los sistemas de recuperación generan alertas, estados de configuración, métricas de replicación y resultados de simulacros. Un agente puede traducir potencialmente esa información en una investigación guiada sin exigir que cada administrador sepa dónde se encuentra cada señal.
El movimiento temprano de HPE le da la oportunidad de establecer el comportamiento de los agentes en torno a su contexto operativo propietario. Sus especialistas pueden codificar patrones de registros específicos de cada componente y utilizar APIs ya asociadas con Zerto Manager y los motores de replicación.
Los proveedores de nube poseen una ventaja diferente. Controlan la infraestructura, la telemetría, los servicios de identidad, las APIs de recuperación y las plataformas de IA gestionadas dentro de sus respectivas nubes. Potencialmente pueden crear agentes con acceso directo a una colección más amplia de señales nativas.
Esto crea el principal competidor para el enfoque de HPE Zerto: la resolución de problemas controlada localmente frente a la inteligencia operativa centrada en la nube. La competencia no es simplemente HPE contra AWS o Microsoft, ya que AWS proporciona los modelos detrás del sistema de Zerto. Es una competencia entre ubicaciones arquitectónicas para el control y el contexto.
El control local mantiene la orquestación cerca de la infraestructura protegida y puede respaldar entornos con políticas estrictas de residencia. Los sistemas centrados en la nube pueden recurrir a telemetría integrada y servicios gestionados sin mantener un entorno de ejecución de agentes dentro del appliance de cada cliente.
La arquitectura de HPE combina ambas rutas. Los agentes y las herramientas operativas permanecen locales, mientras que la inferencia de modelos y la recuperación de documentos utilizan AWS. Esta disposición híbrida intenta mantener el límite de ejecución más sensible en las instalaciones sin renunciar a los modelos fundacionales gestionados.
El enfoque también otorga a HPE responsabilidades de implementación que un servicio de nube totalmente gestionado puede evitar. El pod local debe seguir siendo compatible con las versiones del producto, las políticas de red del cliente, los sistemas de autenticación y las conexiones salientes restringidas. Resolver problemas del agente de resolución de problemas pasa a formar parte de la carga operativa.
Los entornos aislados de la red presentan la limitación más marcada. HPE afirma que la infraestructura de recuperación ante desastres suele estar aislada, ser sensible a la latencia o estar sujeta a requisitos de residencia de datos. Sin embargo, el sistema descrito sigue necesitando acceso HTTPS para la inferencia de modelos y las consultas de conocimiento.
Por tanto, las instalaciones estrictamente desconectadas no pueden utilizar la arquitectura exactamente como se describe. Otros clientes podrían permitir tráfico saliente controlado de forma limitada, pero los equipos de seguridad aún tendrán que inspeccionar los destinos, el contenido de las solicitudes, los controles de identidad, el comportamiento de retención y los modos de fallo.
La latencia también abarca dos ubicaciones. Las llamadas a herramientas contra Zerto permanecen locales, mientras que las solicitudes de razonamiento viajan a AWS. Una investigación compleja puede requerir varios ciclos entre decisiones del modelo y resultados de herramientas locales. El streaming puede hacer visible esa espera, pero no puede eliminar la dependencia de la red.
El valor estratégico de la arquitectura depende de si este compromiso híbrido funciona mejor que las alternativas. Si proporciona orientación fiable y basada en evidencia sin centralizar datos operativos sin procesar, ofrece a los proveedores de software empresarial un patrón reutilizable. Si predominan las restricciones de red o los errores de fundamentación, los compradores podrían preferir asistencia más sencilla u operaciones en nube totalmente gestionadas.
La próxima prueba es si el diagnóstico guiado se convierte en operaciones de confianza
Tres señales mostrarán si la resolución de problemas mediante agentes de HPE Zerto se está convirtiendo en infraestructura fiable en lugar de una atractiva interfaz de soporte.
La primera señal es evidencia sobre la calidad de la resolución. Las cifras de adopción y casos de soporte son puntos de partida útiles, pero no muestran si los usuarios eligieron soluciones seguras o resolvieron incidentes más rápido.
Con el tiempo, HPE debería informar métricas de resultados para los flujos de trabajo compatibles. Entre las señales útiles se incluyen la resolución autoservicio exitosa, la escalación tras una interacción con un agente, los incidentes recurrentes, la aceptación por parte de los administradores y los errores detectados durante la revisión. Períodos de medición comparables harían que esos resultados fueran más significativos.
Si resultados revisados de forma independiente muestran diagnósticos precisos en diversos entornos de clientes, se reforzará el argumento a favor de las operaciones agénticas locales. Si las reducciones de soporte llegan sin datos fiables de resolución, la historia de rendimiento publicada seguirá siendo incompleta.
La segunda señal es la expansión más allá de las tareas de asesoramiento. HPE enumera la ejecución de tareas para los usuarios como uno de los objetivos del sistema. La arquitectura pública explica principalmente la asistencia, la investigación, las alertas de estado y la orientación para la mitigación.
Pasar de recomendaciones a acciones cambia el modelo de riesgo. Una explicación equivocada consume tiempo, mientras que un cambio de configuración erróneo puede afectar la protección o la preparación para la recuperación. Los agentes que ejecutan acciones necesitan permisos limitados, aprobaciones, registros de auditoría completos, operaciones idempotentes y rutas de reversión fiables.
Por ello, cualquier lanzamiento que permita al sistema modificar la configuración debería recibir una atención estrecha. Las acciones limitadas y reversibles, con confirmación explícita, reforzarían la arquitectura de HPE. Una remediación autónoma amplia sin detalles de control publicados aumentaría la incertidumbre.
La tercera señal es cómo se comporta el agente durante una conectividad degradada e incidentes graves. Una consulta cotidiana de soporte ofrece acceso de red estable y una urgencia moderada. Un ataque de ransomware o una interrupción de infraestructura puede alterar las mismas rutas de identidad, red o nube que utiliza el agente.
HPE necesita un comportamiento claro cuando Amazon Bedrock no está disponible, una consulta de conocimiento agota el tiempo de espera, una herramienta local devuelve datos obsoletos o el orquestador no puede completar una investigación. Una degradación segura debería distinguir entre evidencia faltante e infraestructura saludable, y dirigir a los operadores hacia procedimientos de recuperación establecidos.
El uso interno de la empresa ofrece otro campo de pruebas. HPE afirma que sus ingenieros usan el sistema para investigar problemas comunes, mientras que su equipo de aseguramiento de calidad lo integra en los flujos de trabajo de pruebas. Esos usuarios pueden revelar patrones de fallos antes de que los clientes dependan del mismo comportamiento durante una crisis.
La arquitectura ya contiene varias limitaciones sensatas. Los agentes especializados reciben responsabilidades delimitadas. Se prohíbe la recursión entre pares. El orquestador controla la salida final. Las API locales proporcionan datos actuales, mientras que las evaluaciones repetidas examinan las respuestas y las trayectorias de las herramientas.
Ninguno de esos controles hace determinista el razonamiento de los modelos de lenguaje. El sistema sigue operando entre versiones de software cambiantes, topologías de clientes, formatos de registros, lanzamientos de modelos y documentación. Por tanto, la evaluación continua debe acompañar al producto después de su despliegue.
Para los compradores empresariales, la pregunta correcta no es si un agente puede resumir una alerta. Es si el sistema muestra de dónde procede su respuesta, respeta los permisos operativos, reconoce la evidencia faltante y escala antes de que la incertidumbre se convierta en acción.
Los desarrolladores deberían vigilar el límite de las herramientas. Un servidor MCP bien diseñado puede hacer que las API existentes sean utilizables por agentes, pero cada operación expuesta amplía la autoridad del sistema. Los equipos de producto deberían tratar el diseño de herramientas con el mismo cuidado que aplican a las API públicas y los roles administrativos.
Los trabajadores del conocimiento pueden extraer una lección más amplia del despliegue. La IA se vuelve más útil cuando puede conectar material de referencia fiable con el contexto de trabajo actual. Ese beneficio depende de la calidad de las fuentes, los límites de acceso y una distinción clara entre hechos recuperados y juicio generado.
HPE Zerto ha llevado esa idea a uno de los entornos menos indulgentes de la informática empresarial. El sistema reúne orquestación local, datos activos de recuperación ante desastres, agentes especializados e inferencia en la nube administrada dentro de una única ruta operativa.
Ahora la evidencia debe ir más allá de la adopción. Observe si HPE publica resultados de resolución, introduce acciones controladas y documenta el comportamiento en modo degradado. Esas señales determinarán si el modelo de solución de problemas agéntico de HPE Zerto se convierte en un patrón que otros proveedores de infraestructura deberían seguir.
