Sí, es seguro ejecutar PowerShell generado por IA en producción, pero solo con una puerta de aprobación delante. Un script escrito por un asistente no es de por sí más peligroso que uno escrito por un ingeniero a las cuatro de la tarde de un viernes, y suele estar mejor comentado. Lo que lo vuelve arriesgado es que casi ninguna organización tiene una regla que lo cubra. Hay un proceso de cambio para una regla de firewall y un proceso de publicación para una aplicación, y luego hay un script que llegó por una ventana de chat y se ejecutó con un token de Administrador global porque alguien tenía prisa. El control que falta no es un ajuste del modelo. Es una persona aprobadora con nombre, una lista definida de lo que esa persona revisa y un registro de qué se ejecutó y por qué.
Tenemos ISO 27001, ISO 9001, ISO/IEC 42001 y Cyber Essentials, así que esto está escrito desde que nos hagan estas preguntas en las evaluaciones y no desde la teoría.
El fallo es la puerta que falta, no el modelo
Casi toda la discusión sobre la IA en operaciones es en realidad una discusión sobre la calidad del modelo, que es la discusión equivocada. Esa misma organización ya ejecuta scripts escritos por contratistas, copiados de foros y heredados de personas que se fueron en 2019. La procedencia nunca fue el control. La revisión sí.
Lo que de verdad cambia es el volumen. Un ingeniero puede producir ahora veinte planes de remediación plausibles en una tarde, así que la restricción se traslada de la generación a la revisión, y la revisión es la parte para la que nadie asignó personal. Un plan que se lee con seguridad y cita los cmdlets correctos es exactamente lo que se cuela ante una persona revisora cansada, porque nada en él está obviamente mal. Lo que falta es un alcance acotado, y una ausencia es más difícil de ver que un error.
Así que la primera pregunta no es «¿podemos confiar en la IA?» sino «¿qué revisa realmente la persona que pulsa aprobar?».
La puerta es el producto: todo lo anterior es un borrador y todo lo posterior es evidencia.
Tres carriles de autonomía
Decidir si la IA «puede actuar» es la forma equivocada de la pregunta, porque la respuesta cambia según la tarea. Ordene el trabajo en tres carriles y conceda el carril al flujo de trabajo en lugar de a la herramienta.
Solo lectura. Análisis de registros, redacción de documentación, explicar qué hace una política. Nada cambia de estado, así que el modo de fallo es una respuesta incorrecta y no una acción incorrecta. Todo empieza aquí, y aquí puede quedarse más de lo que la gente espera.
Proponer y aprobar. El asistente produce el plan y el script; una persona lo lee y lo ejecuta. Casi todo el trabajo operativo útil pertenece aquí, y aquí vive la puerta. La aprobación tiene que ser un acto con registro, no un encogimiento de hombros. Si el proceso es «el ingeniero lo mira y lo ejecuta», eso es el tercer carril con pasos añadidos.
Ejecutar dentro de la política. El asistente ejecuta el cambio dentro de un límite preautorizado: un conjunto definido de operaciones, un alcance objetivo definido, un techo de radio de impacto y condiciones de parada automáticas. Los buenos candidatos son estrechos, repetitivos, reversibles y supervisados, como aplicar una recuperación de licencias documentada a cuentas ya confirmadas como bajas.
Un flujo de trabajo gana el tercer carril cuando ha corrido en el segundo las veces suficientes para volverse aburrido: aprobado repetidamente sin correcciones, determinista, acotado por algo estructural en lugar de por un filtro escrito a mano, y probado de forma reversible. Degrádelo ante cualquier sorpresa, y nunca transfiera un carril a una tarea que se le parezca.
Qué revisa realmente una persona revisora
Esta es la lista que falta en casi todas las políticas. Póngala junto al botón de aprobar y exija que la persona revisora registre qué comprobaciones hizo.
Alcance y filtros. ¿Qué toca esto, y qué define ese conjunto? Un filtro escrito a mano es una promesa; una pertenencia a grupo revisada es un límite. El incidente clásico es un filtro que coincide en silencio con todo porque una propiedad estaba vacía en más objetos de los que nadie esperaba.
Operaciones destructivas. Busque remove, delete, disable, reset y cualquier escritura sobre una configuración de producción. Equivocarse en las lecturas sale barato. En las escrituras no.
Soporte de ejecución en seco. ¿Admite una vista previa, y se ha ejecutado y leído esa vista previa? En PowerShell eso significa un tratamiento real de ShouldProcess para que -WhatIf funcione, no un comentario que afirme que el script es seguro.
# Unbounded: matches every disabled account in the tenant, no preview, no confirmation
Get-MgUser -Filter 'accountEnabled eq false' -All | Remove-MgUser
# Bounded: a reviewed membership defines the scope, and the preview runs first
$leavers = Get-MgGroupMember -GroupId $ConfirmedLeaversGroupId -All
$leavers | ForEach-Object { Remove-MgUser -UserId $_.Id -WhatIf }
Idempotencia. Si esto se ejecuta dos veces, ¿la segunda ejecución no hace nada o causa daño? Pregunte qué hace un reintento tras un fallo parcial, porque el fallo parcial es el caso habitual.
Radio de impacto. No «¿es correcto?» sino «si está mal, ¿cuánta gente lo nota y con qué rapidez?». Una asignación de licencia y una política de Conditional Access dan respuestas muy distintas, y la segunda merece otra persona revisora.
Bajo qué identidad se ejecuta. La comprobación que la gente se salta. Si el trabajo se ejecuta dentro de la sesión privilegiada de un ingeniero, cada entrada del registro dice que lo hizo una persona y la reconstrucción posterior desaparece. El trabajo desatendido pertenece a una identidad de carga de trabajo que solo tiene los permisos que la tarea necesita, la misma disciplina que el conjunto de preguntas actual exige sobre las cuentas de servicio en nuestra lista de fallo automático de Microsoft 365.
Vía de reversión. ¿Qué deshace esto, y lo ha probado alguien? Restaurar desde una copia de seguridad no es una vía de reversión para un objeto de directorio. Si no se puede deshacer, necesita una aprobación más alta, no una más rápida.
Qué dicen las normas y qué le dejan a usted
Ni ISO 27001 ni Cyber Essentials contienen un control que diga «no puede ejecutar scripts generados por IA». Esperar a que aparezca es un error, porque las obligaciones ya se aplican y simplemente no usan esa palabra.
ISO 27001:2022 pide cambios controlados en las instalaciones de tratamiento de información, un registro que permita reconstruir los eventos, separación del acceso privilegiado y una gestión de la configuración definida. Una acción originada en un asistente es un cambio y necesita la misma autorización y el mismo registro que cualquier otra. ISO/IEC 42001 va más lejos y pide un sistema de gestión en torno al uso de la IA: propósito definido, roles definidos, evaluación de riesgos y supervisión del comportamiento en la práctica.
A Cyber Essentials en general no le importa cómo se escribió un script. Le importa que el acceso administrativo esté separado y que las cuentas capaces de hacer el cambio estén controladas. La conexión es indirecta y aun así real: en el momento en que un asistente necesita privilegio permanente para ser útil, ha creado exactamente la identidad elevada de forma permanente con la que el esquema no está contento.
Lo que le dejan a usted es el juicio: ninguna de ellas le dirá qué operaciones pertenecen al tercer carril, y lo que un evaluador pide es el razonamiento y el registro detrás de esa decisión. Nuestro mapeo de los ajustes de Microsoft 365 a Cyber Essentials e ISO 27001 cubre el cuadro de controles que hay debajo.
El registro de evidencias que acepta un evaluador
Una aprobación que no deja rastro no ocurrió. Un registro utilizable por acción ejecutada guarda el desencadenante, la intención de quien lo pidió en sus propias palabras, el artefacto aprobado completo en lugar de un resumen, la herramienta y la versión que lo produjeron, la persona revisora con nombre y qué comprobaciones registró, la decisión y su marca de tiempo, la identidad que ejecutó el trabajo, el alcance objetivo resuelto en el momento de la ejecución, el resultado incluyendo fallos parciales y cualquier reversión aplicada.
Dos propiedades importan más que la exhaustividad. Tiene que ser consultable, porque un evaluador pregunta por un rango de fechas y no por una carpeta. Y tiene que sobrevivir a los propios registros de la plataforma, que caducan antes de lo que casi todo el mundo supone.
Dónde se rompe
Cuentas administrativas compartidas. El registro de aprobación nombra a una persona, el registro de ejecución nombra a una cuenta, y nada los une. Arregle las cuentas antes que el proceso de IA.
El asistente actuando con las credenciales de una persona. Cómodo, y destruye la atribución. Cada registro posterior muestra entonces a una persona realizando acciones que puede que no leyera con atención.
Retención de registros. Su registro de aprobación puede vivir años mientras el registro de la plataforma sobre qué cambió caduca en semanas. Demuestra que alguien aprobó algo y no consigue demostrar qué hizo.
Acceso delegado en proveedores de servicios gestionados. Cuando el trabajo aterriza en el tenant de un cliente mediante acceso delegado, decida de forma explícita qué lado guarda el registro de aprobación y cómo lo obtiene el cliente, junto con qué informar cada mes.
Teatro de aprobación. El fallo más común. Si la persona revisora aprueba todo en cuestión de segundos, la puerta es decorativa. Mida la tasa de correcciones, no la tasa de aprobaciones.
Una secuencia de adopción con condiciones de parada
- Inventaríe lo que ya ocurre. Ya se están ejecutando scripts generados por IA. Necesita la línea de partida honesta.
- Escriba la lista de la persona revisora. Las siete comprobaciones de arriba. Pare si no puede nombrar a quien revisa.
- Ejecute todo en el carril de proponer y aprobar durante un trimestre. Pare si la tasa de correcciones es cercana a cero, porque eso significa que nadie está leyendo.
- Dé al trabajo desatendido su propia identidad. Sin Administrador global permanente, sin cuentas compartidas, permisos acotados por flujo de trabajo. Nada de lo que viene después funciona sin esto.
- Promocione dos o tres flujos de trabajo, con condiciones de parada fijadas de antemano: un techo de número de objetos, un umbral de errores, un bloqueo fuera de horario.
- Revise cada trimestre y degrade sin reparos.
Dese unos dos trimestres. La parte lenta nunca es la tecnología; es acordar de quién es la decisión.
Dónde encaja EtherAssist
Alrededor de esa puerta está construido EtherAssist. Produce el plan y el script con el contexto operativo de un entorno Microsoft detrás, retiene el trabajo en un paso de aprobación humana y escribe el registro de ejecución al otro lado, de modo que la aprobación y la evidencia son un solo artefacto en lugar de dos sistemas que alguien concilia más tarde.
Eso es lo que cubre nuestra ruta de operaciones agénticas: ejecución acotada con aprobación humana y un rastro de auditoría, mantenida aparte del trabajo más amplio de operaciones de TI y conformidad. Si el motor es una evaluación próxima, conformidad ISO y preparación para auditorías encaja mejor, y nuestra guía sobre qué significa la IA agéntica para los equipos de TI fija el vocabulario. EtherAssist cuesta GBP 16.00 por usuario y mes con una prueba de 14 días, así que puede pasar un flujo de trabajo real por la puerta antes de comprometerse.
Explore las operaciones agénticas para ver cómo la ejecución acotada, la aprobación humana y el registro de evidencias encajan en un solo flujo de trabajo.