Pregúntele al equipo de TI cómo está configurado hoy el parque de estaciones y la respuesta honesta suele ser «abra el portal y mire». Política de BitLocker, regla de firewall, excepción creada en una madrugada de incidente: todo vive dentro de una consola web, sin historial legible, sin revisión y sin camino de vuelta. Es el problema que la infraestructura resolvió con código versionado — solo que casi nadie aplicó la idea a la gestión de endpoints.

Fue lo que hicimos en un proyecto con una aseguradora brasileña: un framework en PowerShell sobre la API de Microsoft Graph que exporta el estado del tenant de Intune a archivos versionados y los aplica de vuelta de forma controlada. Las políticas del parque se convirtieron en código en git — revisables en un pull request y reproducibles. Con asistentes de IA escribiendo el framework, lo que habría sido un mes de trabajo se volvió cuestión de días.

El clic no deja rastro

La gestión de estaciones hecha a clics falla en tres puntos previsibles. El primero es la trazabilidad: el portal registra que algo cambió, pero no cuenta el porqué, ni muestra el antes y el después de una política con decenas de configuraciones. El segundo es la reversibilidad — deshacer un cambio malo depende de que alguien recuerde el valor anterior.

El tercero es el más caro: la reproducibilidad. Un parque bien configurado es un activo que existe en un único lugar. Si el tenant necesita ser recreado, o si hay que montar un ambiente de prueba fiel, el camino es rehacerlo clic a clic — y el resultado nunca es idéntico. Por eso el asunto es disciplina de infraestructura.

Qué resuelve el «as code» en Intune

La idea es simple. En vez de que el tenant sea la única fuente de la verdad, pasa a ser el destino de una configuración que vive en un repositorio. Cuatro efectos prácticos:

• Exportar el estado. Políticas de configuración, reglas de cumplimiento, perfiles de Autopilot, scripts y asignaciones salen como JSON legible. Eso ya es el inventario que nadie tenía.
• Versionar. «Qué cambió en la política de BitLocker en el último trimestre» se vuelve un comando, no una investigación — y el historial sirve de evidencia en una auditoría.
• Revisar en PR. Un cambio de baseline deja de ser una decisión solitaria: dos personas leen el diff antes de que algo llegue a las máquinas.
• Aplicar de nuevo. El mismo conjunto de archivos sube en otro tenant, en un ambiente de prueba o de vuelta al original después de un problema.

Qué aceleró la IA de verdad

Vale separar la promesa del resultado. La IA no diseñó la política de seguridad del cliente ni decidió qué era aceptable para ese parque. Acortó tres trabajos concretos.

Escribir el framework. La parte tediosa de hablar con Graph es siempre la misma: autenticación por aplicación con permisos mínimos, paginación de @odata.nextLink, tratamiento del throttling — el HTTP 429 con Retry-After, que aparece justamente al exportar el tenant entero — y normalización de los JSON, para que el diff no acuse un cambio por orden de campos o por una marca de tiempo. Describir eso en prosa y recibir las funciones estructuradas, con tratamiento de error y log, ahorró casi todo el esfuerzo mecánico.

Traducir políticas de baseline. La recomendación de seguridad llega como texto: exigir cifrado de disco, bloquear macros externas, habilitar las reglas de reducción de superficie de ataque. Transformar cada una de esas líneas en el identificador correcto del catálogo de configuraciones de Intune es rastrear documentación. La IA hizo el primer corte; el ingeniero verificó y corrigió — y había qué corregir.

Destrabar el troubleshooting de inscripción. Aquí es donde la ganancia sorprende. Una falla en la inscripción devuelve códigos hexadecimales poco amigables, con indicios repartidos entre el visor de eventos y el informe de diagnóstico MDM. Enviar ese material bruto para análisis acorta el camino entre «la máquina no entra» y «el alcance de inscripción automática no incluye ese grupo».

El método: exportar, comparar, versionar, aplicar

El orden importa, y empieza por el paso más seguro: nada de escribir la configuración ideal antes de conocer la real.

1. Exportar el tenant entero con una credencial de solo lectura. Es la fotografía de lo que existe — incluidas las políticas duplicadas y las asignaciones huérfanas que nadie sabía que seguían activas.
2. Comparar el export con el baseline pretendido. La lista de diferencias es la agenda real del proyecto: qué falta, qué sobra y qué está en conflicto.
3. Versionar la configuración aprobada, con las asignaciones referenciando grupos por nombre, no por identificador. El identificador no sobrevive al cambio de tenant; el nombre, sí — y eso es lo que hace portable al repositorio.
4. Aplicar por anillo: piloto de diez máquinas del propio TI, después todo el TI, después un área de negocio y solo entonces el parque. Cada anillo queda en observación durante días.

Barandas de protección: el tenant es producción

Automatizar cambios en un parque de estaciones es poderoso y peligroso en la misma medida. Cuatro reglas no son negociables. Separar credenciales: lo que exporta usa permiso de lectura; lo que aplica usa escritura y vive en el pipeline. Respaldo antes de cada apply — un export del estado actual, marcado en el repositorio: es la diferencia entre revertir y reconstruir.

Nada se aplica sin revisión — el diff aprobado es lo que corre, y la aprobación queda registrada. Y anillos con criterio de parada definidos de antemano: si el piloto genera tickets por encima de lo acordado, el anillo siguiente no avanza. Sume a eso una práctica barata — correr el apply en modo simulado y leer lo que pretende alterar. Esto es continuidad operativa tanto como es ciberseguridad.

Antes y después: la migración de las estaciones

El caso fue la migración de estaciones Windows del modelo híbrido — unidas al dominio local y apenas registradas en la nube — a Entra Join con aprovisionamiento por Autopilot: el equipo sale de la caja, entra en el tenant y llega configurado al usuario, sin pasar por el banco de trabajo de TI.

Antes, armar el baseline de seguridad y las políticas equivalentes en el nuevo modelo era trabajo de semanas de configuración manual, con el riesgo de olvidar silenciosamente una regla del mundo antiguo. Con el framework, se volvió cuestión de días. Más importante que la velocidad: el parque quedó reproducible — el estado entero cabe en un repositorio que cualquier ingeniero del equipo lee y revisa.

Dos trampas valen el registro. La primera es el acceso a recursos locales: salir del modelo híbrido sin resolver cómo la máquina se autentica en carpetas compartidas e impresoras del datacenter rompe la rutina de quien trabaja. La segunda son las políticas heredadas del dominio, que deben traducirse una a una — y ahí es donde la comparación paga su propio costo.

El puente con Zero Trust

Nada de esto es un ejercicio de organización. Zero Trust parte de un principio simple: ningún acceso se concede por estar dentro de la red. Depende de identidad verificada y de dispositivo conocido, gestionado y en cumplimiento. La estación es la mitad de la ecuación, no un detalle del inventario.

Solo que «en cumplimiento» necesita tener significado técnico. Viene de la política que Intune evalúa — disco cifrado, protección contra amenazas activa, versión mínima del sistema — y que el acceso condicional consulta antes de liberar correo, archivos y aplicaciones. Si esa política no se versiona ni se revisa, el pilar de dispositivo de Zero Trust se apoya en clics que nadie audita.

Para profundizar, Inove Academy pone a disposición el e-book de ciberseguridad y LGPD (la ley brasileña de protección de datos), que trata la parte normalmente ausente de esta conversación: qué controles técnicos sostienen las obligaciones legales y cómo demostrarlo cuando alguien pide evidencia.

Una salvedad final. Poner el parque en código no elimina la decisión técnica; cambia el lugar donde ocurre. Qué bloquear, qué liberar y cuánta fricción aguanta el usuario siguen siendo elecciones humanas. Lo que el framework garantiza es que la elección quede escrita, revisada y reversible — en vez de convertirse en un cambio de portal más que nadie logra explicar seis meses después.