JieGou vs. Rewst: por qué los MSP necesitan más que scripting

La parte que Rewst hace bien

Empecemos por el steelman. Rewst resuelve un problema real. Antes de Rewst (y Liongard, y un puñado de herramientas similares), los MSP tenían dos malas opciones para la automatización PowerShell multi-tenant: iniciar sesión en cada tenant de cliente individualmente y correr scripts localmente, o construir orquestación casera con cuentas de servicio y un scheduler. Ambas escalan mal.

Rewst productizó el patrón de «ejecutar PowerShell a través de N tenants de cliente desde un único plano de control». Es bueno en eso. Los MSP que lo adoptan ahorran horas reales por semana en acciones repetibles — provisión de usuarios, asignación de licencias, gestión de grupos, configuración de buzones.

No estamos diciendo que Rewst sea un mal producto. Estamos diciendo que está diseñado alrededor del eje equivocado.

La parte que las arquitecturas script-first hacen mal

Un script de PowerShell es un artefacto de ejecución. Lees el código, lo ejecutas, obtienes salida.

Pero un script que añade un usuario a un grupo de Global Admin no es solo código. Es un evento de autorización que un auditor querrá reconstruir dentro de dos años. Un script que resetea la contraseña de un usuario y la envía por email a una dirección de respaldo tampoco es solo código — es un evento de cumplimiento, potencialmente un evento de retención legal, potencialmente un evento de confianza del cliente si se eligió la dirección equivocada.

Las plataformas de automatización script-first tratan el script como el artefacto primario y la gobernanza como metadatos que agregas después. Los logs de ejecución existen; los flujos de aprobación existen; las funciones de redacción existen. Pero están compuestas encima, en la capa operativa del MSP, no integradas de base.

Qué sale mal en la práctica:

• La capa de aprobación está a nivel de flujo, no a nivel de acción. Una vez que el flujo arranca, las acciones individuales dentro se ejecutan sin revisión por acción. Aceptable para reseteos masivos de contraseñas durante un evento conocido como seguro. Menos aceptable si el flujo estaba equivocado en una de sus ramas.
• La salida sensible en los logs es problema del MSP. Tokens de cuenta de servicio, códigos de recuperación de un solo uso, contraseñas generadas — si el PowerShell los emite a stdout, terminan en el log de ejecución. Redactarlos es un paso de limpieza, no una preocupación de primera clase del pipeline.
• La historia de auditoría está centrada en ejecución, no en cambio. «¿Qué PowerShell corrió contra este tenant de cliente ese día?» es respondible. «¿Quién autorizó el cambio de privilegio del usuario X a las 3:47 PM?» a veces es respondible, a veces no — porque la autorización puede haber sido un resultado implícito de la configuración del flujo, no un evento discreto.

Estas no son quejas hipotéticas. Son las preguntas de auditoría específicas que revisores de SOC 2, evaluadores CMMC y auditores HIPAA hacen a los MSP que construyen sus operaciones sobre scripts de automatización.

Gobernanza primero: qué cambia

La capa de automatización de JieGou parte de una premisa diferente: el tenant del cliente es una frontera de gobernanza, y cada acción que cruza esa frontera es un evento revisable.

Las consecuencias:

1. Aprobación por acción, no por flujo. Un trabajo que «resetee la contraseña del CEO y la envíe a su dirección de recuperación» es un único evento revisable. El aprobador ve el PowerShell renderizado, el tenant objetivo y el radio de impacto de la acción antes de aprobar. La aprobación por flujo (el modelo Rewst/Liongard) confunde el punto de revisión con el punto de composición — apruebas una vez «este flujo parece estar bien», y luego todas sus ramas individuales disparan.

2. El modo sombra es un nivel de primera clase, no una variante de flujo. Cada acción puede correr en modo sombra: el PowerShell se prepara, los inputs se resuelven, la salida se simula sin llamar a Microsoft Graph / Exchange / lo que sea. El operador del MSP revisa exactamente lo que habría ocurrido. Solo después se promueve a vivo.

3. La redacción de salida está integrada al pipeline del runner. El runner de PowerShell captura stdout/stderr, lo pasa por una pasada de redacción (eliminando cadenas con forma de token, con forma de contraseña y otras formas sensibles), y almacena solo la versión redactada en el log de auditoría. El operador ve la versión redactada en la UI. La salida cruda nunca se persiste.

4. Las acciones generadas por IA comparten el pipeline. Esta es la diferencia arquitectónica significativa. Cuando se prepara un borrador de IA — ya sea un fragmento de PowerShell, una respuesta a un ticket o una escritura de entrada de tiempo — entra en la misma cola de aprobación que las acciones iniciadas por humanos. El operador del MSP no necesita gobernar por separado «cosas que hizo la IA» y «cosas que hicieron los scripts». Es una sola cola.

5. La anulación de emergencia es auditada, no indocumentada. A veces una caída no puede esperar. Los roles Owner y Admin pueden anular una aprobación pendiente proporcionando una razón. La acción de anulación, la razón, la identidad del aprobador y la solicitud original se preservan todas. La anulación existe para emergencias, no como atajo.

Cómo se ve cara a cara

Publicamos una comparación función por función en la página de PowerShell Automation. Resumiendo la fila que más importa:

Aprobación por acción. Rewst: solo a nivel de flujo; una vez corre el flujo, las acciones individuales disparan sin revisión por acción. JieGou: a nivel de acción individual — aprobar o rechazar cada cambio, con el PowerShell renderizado visible.

Puedes entrecerrar los ojos y argumentar que son lo mismo si diseñas tus flujos en ramas de acción única. Cierto. Pero los flujos no se mantienen tan ordenados en un MSP de 20 clientes, y la presión por componer flujos más grandes crece con la escala. La aprobación por acción mantiene la unidad revisable en la granularidad correcta.

Cuándo Rewst sigue siendo la elección correcta

Tratamos de no fingir que JieGou es correcto para todo MSP. Casos en los que Rewst sigue siendo la mejor opción:

• Ya estandarizaste tu biblioteca de automatización en Rewst y tu equipo tiene un año de memoria muscular. El costo de cambio es real.
• La propuesta de valor de tu MSP es «automatizamos agresivamente, la gobernanza es secundaria». Es un posicionamiento defendible. JieGou es para MSP que quieren gobernanza de primera clase.
• Necesitas una integración específica nativa de Rewst que no ofrecemos. Cubrimos las integraciones MSP comunes (ConnectWise Manage, Microsoft Graph, Exchange, Intune, Azure AD) pero Rewst tiene un catálogo más profundo en algunos nichos.

Hacia dónde creemos que va el mercado

El canal MSP lleva 18 meses en la conversación de «IA para MSP». Dos cosas se han movido:

• Los compradores de cumplimiento (MSP con cláusulas MSA que exigen evidencia SOC 2) quieren automatización gobernanza-nativa. No «le agregamos gobernanza encima». Quieren que la plataforma que compraron para las operaciones del MSP sea la misma que responde las preguntas del auditor — mismo log de auditoría, mismo rastro de aprobación, misma redacción.

• Las acciones asistidas por IA ya no están separadas de las acciones scripteadas en ningún sentido operativo. Si la capa de IA de tu MSP redacta una respuesta a un ticket y la capa de automatización de tu MSP escribe la entrada de tiempo del ticket, y ambas pasan por el mismo tenant de cliente, quieren ser un único pipeline. No dos pipelines que conciliar.

JieGou está construido para esos dos cambios de mercado. Rewst no — by design. Eso no hace que Rewst esté equivocado. Lo convierte en un producto diferente para un MSP diferente.

Si ese MSP diferente eres tú, deberías seguir usando Rewst y el resto de este artículo no es para ti.

Si eres el MSP que quiere operaciones gobernanza-nativas, IA-nativas y auditoría-nativas — estaremos encantados de mostrarte el pipeline funcionando de punta a punta. Agenda una demo o realiza la auditoría de sangrado operativo para ver dónde tus brechas actuales te costarán.