Aprobación humana que no es teatro
El 18 de agosto de 2026, TechTarget publicó un reportaje sobre seguridad de agentes de IA en el que Jess Burn, analista principal de Forrester, hace la pregunta que el mercado venía evitando: si una persona está revisando cientos de decisiones después del hecho, o aprobando acciones que no puede validar de forma independiente, o sin la experiencia para saber qué está mirando, ¿eso es supervisión o es apenas una forma de teatro de responsabilidad?
En el mismo reportaje, Will Pearce, de Dreadnode, señala la salida: el paso que los defensores necesitan dar no es preocuparse menos, es volverse menos orientado a políticas y más orientado a la acción.
La crítica es justa. Y también vale para nosotros, porque "usted decide, Myrmex ejecuta" es nuestra frase. Así que merece respuesta, y la respuesta no es jurar que tenemos aprobación humana. Todos la tienen.
Qué vuelve vacía una aprobación
Una aprobación está vacía cuando el humano no logra evaluar lo que está aprobando. Eso ocurre de tres formas, y ninguna se resuelve con otra casilla de verificación.
Ocurre por volumen: treinta solicitudes por hora no son treinta decisiones, son una firma repetida. Ocurre por opacidad: aprobar "ejecutar remediación en el endpoint" sin ver qué se va a ejecutar es autorizar una caja cerrada. Y ocurre por desacople: cuando el registro guarda la intención pero no el comando, lo que se ejecutó puede alejarse de lo aprobado, y después nadie logra probar la diferencia.
El resultado es el mismo en los tres casos. Queda un registro de quién hizo clic, no un registro de lo que pasó. Eso aprueba una auditoría de proceso y falla en el momento en que alguien tiene que responder qué se hizo realmente en el parque.
La pregunta correcta tiene tres partes
Cambiamos "¿existe aprobación humana?" por tres preguntas que se pueden verificar una por una:
- Qué ve el humano antes de decidir.
- Qué pasa durante, después de que decide.
- Qué queda escrito después.
En esas tres se separa la gobernanza del teatro, porque las tres producen evidencia.
Antes: el plan viene antes que la acción, y la aprobación sale de la conversación
En MYRMEX, lo que va a aprobación no es la solicitud, es el plan. Antes de un cambio de red en nuestro propio ambiente, la plataforma armó un plan numerado con el objetivo y el impacto previsto de cada paso, preguntó si podía crear el borrador del cambio y registró el cambio con los pasos de implementación y los pasos de rollback lado a lado, antes de cualquier ejecución.
El detalle que cambia la naturaleza del asunto es dónde ocurre la aprobación. No ocurre en la conversación. El cambio queda en borrador y tiene que ser revisado, aprobado y puesto en ejecución en la pantalla de gestión de cambios. Eso importa porque el registro de la autorización deja de ser un mensaje de chat, difícil de auditar y fácil de perder de vista, y pasa a ser un objeto de gobernanza con estado, ventana, activos impactados y plan de vuelta.
En activos clasificados como críticos, la exigencia aparece un paso antes. La plataforma declara que el dispositivo está configurado para pedir confirmación antes de cualquier consulta o edición, y pide autorización explícita incluso para una lectura. A primera vista parece exceso de celo, y no lo es: es la única forma de que el operador descubra que ese activo es crítico en el momento en que importa, y no en el informe del mes siguiente.
Durante: verificar en vez de presumir
La ejecución en MYRMEX sigue una regla que llamamos Ground Truth Only: nunca simular salida, nunca presumir éxito. El agente ejecuta y lee la respuesta real del sistema operativo o de la API del proveedor, y esa respuesta es la que se convierte en estado.
La consecuencia aparece cuando algo falla. En una ejecución de cambio en nuestro propio ambiente, un paso se trabó porque la sesión con el equipo expiró. El producto no completó la tabla con lo que era probable. Escribió que los comandos de lectura en tiempo real no habían sido recolectados en ese intento, que ninguna tabla o valor presumido sería presentado, nombró las llamadas que fallaron y ofreció dos salidas, una de ellas el rollback ya registrado en el cambio.
El mismo patrón aparece en auditoría. Cuando parte de los controles de una auditoría de cumplimiento no pudo ser evaluada porque una API no estaba alcanzable, el resultado lo dijo en texto claro y mantuvo una postura conservadora, en vez de mostrar un valor cualquiera. Declarar lo que no se pudo determinar es lo que separa un dictamen de un informe generado. Y es lo opuesto al patrón que más daña la confianza en la automatización, que es la fuente fallando mientras la pantalla muestra un número.
Una aprobación no vale nada si lo que viene después reporta un éxito que no verificó.
Después: la cadena de ejecución, no solo el resultado
El registro que importa no es "acción X concluida". En el registro de auditoría de MYRMEX, cada evento abre con campos nombrados: fecha y hora, origen, tipo, usuario, agente, herramienta, objetivo, comando, estado, duración, sesión e invocación, además del payload de la llamada. El comando efectivo aparece completo, tal como se ejecutó.
Dos de esos campos hacen casi todo el trabajo.
El primero es la separación entre usuario y agente. Son dos campos distintos, y el origen del evento se registra aparte. Sin eso, una revisión de acceso no puede responder la pregunta más básica del año: de estas acciones, ¿cuántas fueron de personas? A medida que los agentes pasan a tener identidad y permisos propios, un registro que trata a ambos como "usuario" pierde la capacidad de responder eso justo cuando empieza a ser exigida.
El segundo es el comando efectivo. Es la diferencia entre saber que alguien aprobó una remediación y saber qué hizo la remediación. Sin él, el registro describe una decisión. Con él, el registro reconstruye un hecho.
Esto también explica por qué el registro tiene que nacer estructurado, campo por campo, en vez de volverse texto corrido en un log. Un artículo aceptado en BCCA 2026, conferencia del IEEE, midió la diferencia: las consultas forenses estructuradas alcanzaron precisión 1.0 en búsquedas por guardrail y por delegación, mientras que la búsqueda textual no estructurada quedó en 0,013 y 0,077. Son dos órdenes de magnitud, y aparecen en el peor momento posible, que es cuando alguien necesita reconstruir lo que pasó.
Qué preguntarle a cualquier proveedor, incluidos nosotros
Si está evaluando plataformas con agentes que ejecutan, estas cinco preguntas separan a quien pensó el problema de quien puso un botón:
- ¿Qué va a aprobación, la solicitud o el plan?
- ¿El plan tiene rollback escrito antes de la ejecución, o solo después de que rompe?
- ¿Dónde queda registrada la autorización: en una pantalla de gobernanza o en un mensaje de chat?
- ¿Quien ejecuta verifica el resultado real, o presume éxito?
- ¿El registro guarda el comando efectivo y separa acción humana de acción de agente?
Ninguna es sobre autonomía, y por eso funcionan. La autonomía es una mala regla: cada proveedor se posiciona donde le resulte conveniente en la conversación. Las cinco de arriba se verifican en una demostración, en quince minutos, y no dependen de creerle a nadie.
Dónde nos posicionamos
Seguimos diciendo que usted decide y Myrmex ejecuta. Lo que este post agrega es lo que sostiene la primera mitad de la frase: una decisión necesita un plan legible antes, verificación real durante y un registro reconstruible después. Sin los tres, "control humano" es una línea de marketing.
Escribimos hace poco sobre por qué rechazamos las etiquetas AI SOC y AIOps, y la razón es la misma que aparece acá: la operación ocurre dentro de la tecnología del cliente, y es ahí donde la evidencia tiene que producirse.
Leer el post sobre ITOps y SecOps · Ver las funcionalidades · Ver los planes
Fuentes citadas:
Sharon Shea, "AI agent security must move beyond human in the loop, experts say", TechTarget, 18/08/2026.
Bindschaedler, Botha y Siebenbrunner, "Agent Flight Recorder: Tamper-Evident Audit Trails with On-Chain Anchoring for Long-Horizon Tool-Using Agents", arXiv 2609.01931, aceptado en BCCA 2026.