> ## Documentation Index > Fetch the complete documentation index at: https://docs.myrmex.ai/llms.txt > Use this file to discover all available pages before exploring further. # Gestión de Cambios (GMUD) > Planifica, aprueba y ejecuta cambios en tu entorno mediante un flujo de trabajo gobernado — tanto cambios estándar como parches de actualización, cada uno con un registro de auditoría completo. import { CardGroup, Card, Note, Tip, Warning, Steps, Step } from '@mintlify/components'; La **Gestión de Cambios** es donde se planifica, revisa, aprueba y ejecuta bajo control cada cambio en tu entorno. Cada cambio se registra como un **GMUD** (*Gestão de Mudança* — un registro de cambio), y nada que toque un sistema se ejecuta hasta que las personas adecuadas lo hayan aprobado. Es el mismo principio que el resto de Myrmex — **la IA propone, tú apruebas** — aplicado al momento en que un cambio realmente ocurre. Un **GMUD** es una única solicitud de cambio: qué cambiará, por qué, en qué sistemas, cuándo, cómo se revertirá y quién dio el visto bueno. Lleva el cambio desde un borrador hasta una ejecución completada y auditada. ## Dos tipos de cambio La Gestión de Cambios maneja dos tipos de cambio, y la diferencia está principalmente en *cómo se ejecuta cada uno*: Un cambio que tú (o la IA) planificas — una edición de configuración, un cambio de regla de firewall, una tarea de mantenimiento. Tiene un **plan de implementación** y un **plan de reversión**, y una vez aprobado lo inicias explícitamente con **Execute**. Los agentes entonces llevan a cabo los pasos. El despliegue de un parche del sistema operativo que se origina en el área de [Updates](/es/documentation/agent-endpoint-security/patch-management). La IA programa los parches pendientes en una **ventana de mantenimiento**; una vez aprobado, el agente **los instala automáticamente en esa ventana** — sin **Execute** manual. Ambos tipos comparten el mismo ciclo de vida, la misma puerta de aprobación, la misma ventana de cambio y el mismo registro de auditoría. Solo difieren en el momento de la ejecución: un cambio estándar se dispara bajo demanda, un parche se ejecuta dentro de su ventana programada. El [flujo de aprobación](/es/documentation/change-management/approvals) cubre ambos. ## El ciclo de vida de un cambio Un GMUD atraviesa un conjunto fijo de estados. El camino feliz tiene seis etapas; un puñado de estados de excepción cierran un cambio que no se completó normalmente. El cambio se está redactando — identificación, justificación, riesgo, ventana y los pasos de implementación/reversión. Totalmente editable. Enviado para aprobación. Ahora espera a los aprobadores según la [regla de aprobación](/es/documentation/change-management/approvals#approval-rules) correspondiente. Se registraron suficientes aprobaciones. Un cambio estándar ya está listo para **Execute**; un parche está listo para ejecutarse en su ventana. El cambio está en cola para su **ventana de cambio**. Mientras está programado, el registro se actualiza automáticamente cada 60 segundos. Los agentes están ejecutando los pasos. Para un parche, los paquetes se están instalando en los hosts de destino. Todos los pasos finalizaron con éxito. El cambio se cierra y queda totalmente auditado. Fuera del camino feliz, un cambio también puede terminar como: | Estado | Significado | | ------------- | ------------------------------------------------------------------------------------------------------ | | **Rechazado** | Un aprobador lo rechazó durante la puerta de aprobación — el flujo termina. | | **Cancelado** | Cancelado antes de la ejecución (permitido mientras está en borrador, enviado, aprobado o programado). | | **Parcial** | La ejecución terminó pero solo algunos pasos/elementos tuvieron éxito. | | **Fallido** | La ejecución no tuvo éxito. | | **Abortado** | La ejecución se detuvo en curso. | | **Revertido** | Se aplicó el plan de reversión para deshacer el cambio. | **Editar un cambio después de haberlo enviado lo reinicia.** Editar un cambio que está enviado, aprobado o programado cancela cualquier ejecución despachada y lo revierte a **Borrador** — debe enviarse y aprobarse de nuevo. Esto es deliberado: un cambio aprobado se aprueba *tal como está escrito*. ## Anatomía de un cambio Cada GMUD es un documento estructurado. Cuando abres uno, está organizado en las secciones que esperaría un comité asesor de cambios: Título, estado, **tipo de cambio**, **categoría** técnica y **clase** (cambio estándar o parche). El problema o la motivación, el objetivo y el resultado esperado, y qué está explícitamente **dentro del alcance** y **fuera del alcance**. Probabilidad, impacto y el **nivel de riesgo final**; servicios y usuarios impactados, tiempo de inactividad esperado, riesgos de seguridad/cumplimiento y dependencias. Los dispositivos e integraciones que el cambio toca, cada uno vinculado como **afectado** o **dependiente** — para que el radio de impacto sea explícito. Inicio y fin de la ventana de mantenimiento, además de la comunicación con las partes interesadas. El registro muestra cuándo se abre y se cierra la ventana. Los **pasos** ordenados para hacer el cambio y los pasos para deshacerlo — ver más abajo. ### Pasos de implementación y reversión El plan es una lista de **pasos** ordenados, cada uno etiquetado como **Implementación** o **Reversión**. Un paso registra la actividad, su orden, un responsable, una duración esperada y — opcionalmente — un **destino** (un dispositivo o integración específico) y una acción a ejecutar allí. Durante la ejecución, cada paso muestra su propio estado, para que puedas ver exactamente hasta dónde llegó el cambio y qué queda si algo debe deshacerse. Un buen plan de reversión es lo que hace que un cambio sea seguro de aprobar. Pídele a la IA que lo redacte por ti — *"agrega un plan de reversión que revierta este cambio de regla de firewall."* ## Cómo llegar ahí Abre la **Gestión de Cambios** desde el **Directory** a la izquierda de la consola. Lista tus cambios para el [contexto](/es/documentation/get-started/concepts#how-your-account-is-organized) que tengas seleccionado — los cambios estándar y los cambios de parche se muestran con iconos distintos — y cada uno se abre como una pestaña en el Workspace. Verlo requiere el permiso `gmuds.read`. También puedes traer un cambio a una conversación: **menciona con `@`** un cambio (o un parche) como [entidad de contexto](/es/documentation/multi-agent-system/overview) y pregúntale a la IA sobre él, o pídele que redacte o ajuste uno. ## Dónde encaja la IA La Gestión de Cambios está profundamente ligada a los agentes: * **Redacción** — pídele a [Centurion](/es/documentation/multi-agent-system/agent-orchestrator) que prepare un cambio y completará la identificación, el riesgo, la ventana y un primer plan de implementación/reversión para que lo revises. * **Proponer parches** — la IA revisa las actualizaciones pendientes y propone un cambio de parche (un GMUD de clase parche) con una ventana de mantenimiento (consulta [Gestión de parches y actualizaciones](/es/documentation/agent-endpoint-security/patch-management)). * **Ejecución** — una vez que apruebas (y, para un cambio estándar, haces clic en **Execute**), los agentes ejecutan los pasos, dirigidos desde el Workspace. En todo momento, **tú controlas la puerta**: ningún cambio abandona la etapa de aprobación sin una decisión humana, y cada acción — humana, de un agente o del sistema — se escribe en el historial del cambio. ## Traza de actividad y exportación Cada GMUD lleva una línea de tiempo de **Actividad**: cuándo se creó y quién lo hizo, cada aprobación o rechazo (con el motivo dado), cada paso a medida que se ejecutó y la última actualización. Responde *"¿quién hizo qué, y cuándo?"* en el propio registro. También puedes **exportar el cambio como PDF** — para un comité asesor de cambios o un auditor — directamente desde el registro. ## Siguiente Cómo funciona enviar → aprobar → ejecutar, y cómo gobernar quién debe aprobar qué. Revisa las actualizaciones del SO pendientes y aprueba los cronogramas de parches que propone la IA.