Mantenga la misma prueba.
Después evalúe el control.

En el ejemplo desarrollado por Microsoft, el elemento importante no es únicamente la política generada. También lo es la evaluación que se conserva para la siguiente ejecución. Microsoft presentó run-assert-eval el 24 de septiembre de 2026 como un flujo que conecta el descubrimiento de riesgos, los requisitos de conducta medibles, los controles durante la ejecución y una nueva evaluación. Su artículo de Command Line indica que la definición de la conducta, los casos y el método de valoración permanecen constantes, mientras que la política constituye la intervención prevista. Para quien revisa la propuesta en una empresa, esto plantea una pregunta concreta: ¿puede el equipo identificar la evaluación exacta que reutilizó y explicar qué cambió a su alrededor? Un conjunto nuevo de casos más fáciles podría mejorar el resultado sin aclarar si se corrigió el fallo original. Conservar la prueba es, por tanto, una condición para interpretar la intervención, no un atajo para demostrar causalidad.

La distinción importa cuando el descubrimiento y la aceptación forman parte del mismo flujo. El descubrimiento pregunta qué más podría salir mal; el análisis de una intervención examina cómo responde el agente a un requisito definido después de un cambio revisado. Ambos son útiles, pero aportan evidencias distintas. Como práctica de aceptación, proponemos conservar la evaluación original como un registro identificable y añadir por separado la cobertura que se descubra después. Defina la conducta prohibida con suficiente precisión para que un fallo permita tomar una decisión específica. Indique también qué trabajo autorizado y legítimo debería seguir realizándose. De lo contrario, un control que simplemente rechace más solicitudes puede parecer eficaz aunque reste utilidad al agente. Microsoft separa expresamente esas dos categorías de resultados; ninguna debería desaparecer dentro de una única puntuación favorable.

Microsoft afirma que reutiliza el material conservado de la evaluación inicial para la ejecución con controles. Sin embargo, los resultados agregados principales de ambas ejecuciones se calculan sobre cantidades distintas de conversaciones aplicables. Antes de interpretarlos, es necesario conciliar los resultados caso por caso. El conjunto fijo de pruebas y el subconjunto aplicable no son conceptos intercambiables: conservar los casos no explica, por sí solo, qué conversaciones cumplieron los criterios de cada medida. Pregunte qué casos fueron aplicables en cada ejecución, por qué cambió alguna clasificación y cómo se vincula cada resultado con su caso. No interprete las cifras principales como una comparación pareada con idéntico denominador ni las convierta en un gráfico numérico de antes y después. Mantener el mismo evaluador ayuda a conservar el método, pero no lo hace infalible ni resuelve las diferencias de aplicabilidad. Una comparación útil parte de casos trazables, no de suponer que dos totales describen la misma población.

La fuente señala expresamente que generar no equivale a aprobar de forma automática: hay que revisar la política, la descripción de su aplicación, el punto de intervención y las conexiones con el agente antes de la ejecución con controles. Se trata de un traspaso de responsabilidad sustantivo, no de un trámite administrativo. Quienes revisan deben entender qué decisión se aplica, dónde surte efecto y si el agente evaluado pasa realmente por ese punto. Repetir la prueba no compensa un mecanismo de aplicación mal definido. Proponemos que el registro de revisión distinga el material generado de la versión aceptada por las personas para la evaluación, identifique el cambio de control previsto y declare cualquier otro cambio que pueda influir en la interpretación. Si hay que modificar los casos o los criterios de valoración, consérvelos como una nueva versión de la evaluación, en lugar de seguir presentándolos como la comparación original. El objetivo es dejar un rastro de decisiones examinable, no afirmar que la automatización ha aprobado su propio resultado.

En el ejemplo de Microsoft siguen apareciendo conductas prohibidas después de aplicar el control. Esos fallos deben figurar en el registro de decisión, no quedar eclipsados por una afirmación general de que el problema está resuelto. La muestra publicada tampoco presenta fallos observados en el trabajo legítimo en los resultados con controles; eso no demuestra que todo trabajo legítimo quede siempre intacto. Antes de aceptar un control, pregunte: ¿a qué requisito responde esta evidencia, qué casos siguen pendientes y quién se responsabiliza del siguiente paso? ¿Qué expectativas de trabajo legítimo se probaron y qué tareas pertinentes quedaron fuera de la muestra? ¿Puede quien revisa examinar las decisiones de aplicabilidad y distinguir un rechazo observado de una tarea autorizada realizada correctamente? La persona responsable debe registrar si acepta el alcance evaluado, lo restringe o solicita más trabajo, y explicar por qué. Son preguntas de aceptación propuestas, no conclusiones de un despliegue que hayamos probado. El diagrama adjunto organiza estas comprobaciones; no representa un éxito medido.