Las luchas de la IA para respetar el manual del empleado

Un nuevo benchmark encuentra que los agentes de IA en el lugar de trabajo ignoran las reglas de la empresa, realizan acciones prohibidas como despidos no autorizados y luego informan falsamente que cumplieron.

Un interesante estudio de investigación ha colocado a los principales modelos de LLM en la posición de tener que seguir instrucciones en una empresa simulada, respetando todos los principios del manual del empleado (creado por expertos en dominio humano), así como negociar torrentes de directivas confusas o contradictorias de subordinados y superiores, y realizar tareas basadas en PDF, publicaciones de Jira y otras plataformas y herramientas familiares de un escenario de oficina humano típico.

Si alguna vez ha trabajado en una oficina (o al menos ha visto Office Space), reconocerá las señales contradictorias y la relación señal ruido que los autores del nuevo trabajo lanzaron a los modelos de lenguaje:

La tormenta de variables que muchos trabajadores de oficina deben contender con diariamente, destilada en un entorno virtual para probar modelos de frontera agente. Fuente

El desafío clave que enfrentan incluso los sistemas de IA de vanguardia aquí es la necesidad de retener el manual de Relaciones con Empleados proporcionado como un filtro para todas las órdenes posteriores. Si alguna vez ha luchado para que ChatGPT o Claude recuerden las instrucciones que les dio al comienzo de una sesión, sabrá que la ventana de contexto de la IA a menudo hace que olvide las sugerencias anteriores y regresa, constantemente, a su comportamiento predeterminado.

Esto es por qué, en las pruebas, Claude Fable 5, GPT-5.5 y otros modelos líderes despidieron a empleados después de tomar órdenes de un ejecutivo que carecía de autoridad; aprobaron facturas sin la firma de aprobación del gerente requerida; aceptaron resultados de laboratorio vencidos que la política de la empresa rechazaba explícitamente; y luego informaron que habían seguido fielmente el manual – entre muchas otras infracciones de la política de la empresa.

Los autores del nuevo trabajo afirman:

‘Los fallos siguen patrones consistentes: los agentes dejan que una solicitud plausible en el entorno anule la política vigente, realizan una verificación requerida y luego actúan en contra de su resultado, pierden detalles de reglas a lo largo de horizontes largos, e informan de cumplimiento que no lograron.’

El análisis de fallos contiene algunos ejemplos divertidos: en una tarea de finanzas, Claude Opus 4.8 descubrió correctamente que un gasto de $7,500 había sido aprobado por el mismo analista junior que lo presentó, violando la política de la empresa.

Luego se razonó para creer que el analista era en realidad el Controlador de Finanzas y aprobó el pago de todos modos:

‘Habiendo promovido al Controlador dentro de su propia cadena de pensamiento, el modelo aprobó el artículo, luego envió un mensaje al verdadero Controlador para confirmar que cada artículo por encima de $5,000 tenía una aprobación documentada.

‘El fallo no es una capacidad que falta; todos los hechos requeridos para la decisión correcta habían sido recuperados por el modelo mismo.’

Cómo Claude Opus 4.8 no logró reconciliar $7,500.

En otro lugar, Gemini 3.5 Flash presentó la documentación del seguro utilizando resultados de laboratorio que ya habían caducado sin siquiera abrir el informe de laboratorio, a pesar de que la fecha de recopilación aparecía en el nombre del archivo en sí:

‘Gemini 3.5 Flash presentó la autorización previa al asegurador sin una sola llamada de lectura contra el PDF de laboratorio, luego informó que había procesado el caso “estrictamente según el Procedimiento Operativo Estándar”.’

A lo largo del benchmark, los autores también encontraron que muchos modelos afirmaban confiadamente que habían seguido cada regla de la empresa, mientras citaban las mismas secciones del manual que acababan de violar.

La razonamiento adicional a menudo no ayudó; por ejemplo, GPT-5.5 no mostró ninguna mejora con un esfuerzo de razonamiento aumentado, mientras que algunos modelos realmente se desempeñaron peor, aparentemente razonando su camino lejos de la decisión correcta.

En los resultados finales, Claude Fable 5 logró la tasa de aprobación estricta más alta con un 36,2%; GPT-5.6 Sol se ubicó en segundo lugar con un 23,5%; y GPT-5.5 y Claude Opus 4.8 cada uno obtuvieron un 21,5-21,9%.

La mayoría de los modelos evaluados restantes obtuvieron menos del 16%, y la mayoría de las configuraciones de frontera obtuvieron menos del 25% bajo los criterios de calificación estrictos del benchmark:

El mejor agente de IA que realizó más de un tercio de las tareas de lugar de trabajo gobernadas por políticas del benchmark, mientras que la mayoría de los modelos líderes fallaron más de tres cuartos bajo la evaluación estricta. Fuente

Como forma de remedio, los autores argumentan que las políticas críticas de la empresa deben ser aplicadas fuera de la IA utilizando guardias de herramientas deterministas (es decir, verificaciones codificadas que bloquean acciones prohibidas), en lugar de confiar únicamente en la memoria de contexto largo solo.

También proponen utilizar HANDBOOK.md como un benchmark estandarizado para medir y rastrear mejoras en la adhesión a políticas de contexto largo, a medida que se desarrollan futuros modelos agente.

El nuevo artículo se titula HANDBOOK.md: Un benchmark para el seguimiento de instrucciones agente de contexto largo, y proviene de siete autores en surge.ai. El artículo viene acompañado de un repositorio de GitHub que contiene los archivos Docker y otros requisitos para reproducir las pruebas.

Método

Se crearon sesenta y cinco escenarios de oficina simulados para el benchmark HANDBOOK.md, que abarcan finanzas; RRHH; seguros; logística; y facturación médica; y cada uno coloca un modelo dentro de un entorno de empresa contenedorizado que contiene archivos, correos electrónicos, conversaciones de Slack, calendarios, tableros de Jira y otras herramientas de lugar de trabajo familiares.

Cada tarea estaba gobernada por un manual de entre 20 y 124 páginas, proporcionado como documentos PDF, Word o HTML, en lugar de estar incrustado en la solicitud, lo que obligó a los modelos a localizar, leer y aplicar las reglas relevantes en todo el proceso.

Diez manuales base escritos por expertos se adaptaron de políticas de la industria real, después de lo cual cada tarea recibió su propia versión modificada con diferentes cadenas de aprobación, umbrales y reglas de procedimiento, para prevenir memorización:

‘Los expertos en dominio escribieron los diez manuales base adaptándolos de políticas reales de sus industrias. Cada uno es un documento de operación largo y de varias secciones, en lugar de una lista de reglas.

‘Un manual de RRHH representativo contiene 19 secciones numeradas: una visión general, definiciones, el equipo de RRHH y los contactos, el mapa de canal de Slack, archivos y sistemas de referencia, taxonomías de solicitudes, reglas de triage y enrutamiento, una matriz de prioridad con SLA, procedimientos para incorporación, desincorporación, licencia, rendimiento y contratación, caminos de escalada, reglas de limpieza de correo electrónico y una biblioteca de plantillas y formatos predeterminados requeridos’

El éxito se midió con 824 verificaciones de verificación deterministas basadas en Python, que cubrían tanto acciones requeridas como prohibidas – lo que permitió al benchmark detectar no solo si una tarea se había completado, sino también si se había violado la política de la empresa en el camino.

Se evaluaron treinta configuraciones de modelo de once proveedores; y durante las pruebas, cada tarea se repitió cuatro veces en condiciones idénticas.

A diferencia de los benchmarks convencionales, HANDBOOK.md evaluó tanto si se completaron las acciones requeridas como si se evitaron las acciones prohibidas, lo que permitió a los agentes fallar, a pesar de completar la tarea solicitada

Entornos y herramientas

Cada lugar de trabajo simulado está diseñado para ejecutarse dentro de un entorno de Docker estandarizado, lo que permite a cada modelo acceder al mismo conjunto de herramientas, mientras evita que las diferencias en la disponibilidad de software afecten los resultados. El benchmark presenta a los agentes con un espacio de trabajo de oficina realista, que incluye acceso a archivos, junto con los servicios empresariales mencionados anteriormente (es decir, Gmail, Slack, etc.):

Una representación aproximada del entorno de oficina en el que los modelos deben operar.

Los entornos también conservan cada acción realizada por el agente, lo que permite al sistema de evaluación determinista del benchmark evaluar la secuencia completa de acciones que conducen al resultado final.

Métricas

El rendimiento se midió principalmente utilizando aprobación estricta@1, en el que una tarea se consideró exitosa solo si cada criterio de evaluación se satisfizo. Cualquier requisito perdido o violación de la política resultaría en un fallo, reflejando la configuración empresarial, donde una acción incorrecta puede invalidar un flujo de trabajo competente.

Una métrica más indulgente, aprobación@1 (N−1), también se utilizó, en la que se permitió un criterio fallido por tarea, para que se pudieran distinguir los casi aciertos de los fallos completos.

Para análisis adicionales, se registró la puntuación promedio por criterio de cada modelo, aunque esto no se utilizó en las clasificaciones principales del benchmark.

Enfoque general

Diez manuales base escritos por expertos se adaptaron de políticas de la empresa real, después de lo cual cada uno se modificó en múltiples versiones de tarea específicas con diferentes cadenas de aprobación, umbrales y procedimientos. Entornos de oficina realistas se construyeron alrededor de cada manual, que incluían correos electrónicos, calendarios, conversaciones de Slack, hojas de cálculo y otros artefactos de lugar de trabajo.

Cada tarea se refinó a través de pruebas repetidas hasta que los criterios de evaluación distinguieron de manera fiable los fallos reales del modelo de los defectos del benchmark en sí.

Pruebas y resultados

Incluso los modelos más fuertes fallaron la mayoría de las tareas bajo el sistema de calificación estricto del benchmark, con un rendimiento que se extendió a lo largo de un rango amplio, en lugar de agruparse en la parte superior:

La clasificación inicial de la tabla de clasificación de todos los 30 modelos de configuración evaluados por sus puntajes de aprobación estricta@1 en el benchmark HANDBOOK.md. Las puntuaciones representan el porcentaje de las 65 tareas de lugar de trabajo del benchmark que se completaron sin un solo criterio de evaluación fallido en cuatro intentos por tarea. Las puntuaciones empatadas comparten el mismo rango.

También se encontraron diferencias en la configuración de razonamiento que variaron sustancialmente según el modelo, con un razonamiento adicional que a veces mejoraba el rendimiento; a veces no hacía mucha diferencia; y a veces reducía el rendimiento:

‘El esfuerzo de razonamiento ayuda de manera desigual. Aumentar el esfuerzo mejora Opus 4.8 (+3.0), Sonnet 4.6 (+2.7) y Fable 5 (+2.0), deja GPT-5.5 sin cambios (21.5% en ambos ajustes) y perjudica GLM 5.2 (−2.7). ‘

‘La deliberación adicional parece convertirse en cumplimiento de reglas solo cuando el fallo subyacente es una inferencia perdida en lugar de una lectura perdida.’

Claude Fable 5 logró la puntuación más alta con un 36,2%; seguido por Claude Fable 5 con un 34,2%; y GPT-5.6 Sol (máximo) con un 23,5%. GPT-5.5 y Claude Opus 4.8 formaron el siguiente nivel, alrededor del 20%, mientras que la mayoría de los modelos de frontera restantes obtuvieron menos del 16%. Los modelos con clasificación más baja completaron menos del 2% de las tareas.

El análisis de fallos detallado del artículo sugiere que el problema a menudo no era la falta de información, ya que las reglas del manual relevantes y la evidencia de apoyo ya habían sido recuperadas con frecuencia, pero el razonamiento adicional a veces hacía que los modelos abandonaran la conclusión correcta en favor de una violación de la política plausible.

El trabajo también destaca el alcance de la autoilusión que caracteriza a muchas de las incursiones de los LLM:

‘Casi todas las trayectorias fallidas terminan con una declaración confiada de que se siguió el manual, con frecuencia citando las secciones específicas que se violaron. Los informes son detallados, bien estructurados y equivocados […]

‘[…] A lo largo del benchmark, el informe de autoinforme del agente es el artefacto menos confiable en la trayectoria, lo que importa para cualquier implementación que presente resúmenes de agente a humanos como evidencia de lo que se hizo.’

Al concluir, los autores concluyen que el razonamiento de contexto largo solo es poco probable que haga que la IA empresarial siga la política de la empresa de manera confiable. En su lugar, el cumplimiento de la política debe aplicarse cada vez más mediante controles externos deterministas, además de guardarraíles de flujo de trabajo.

Conclusión

Opinión Una consideración interesante es el eventual alcance en el que los entornos como los creados para los experimentos se reimaginarán para facilitar la IA, en lugar de forzar a los LLM a interpretar las mismas formas y formatos que definen los entornos de oficina humanos. Por ejemplo, ayer, por primera vez, un contacto comercial me envió una visión general en formato .md diseñada para ser explorada por un LLM, en lugar de leerse de manera lineal.

Y yo también estoy adoptando y adaptándome cada vez más a las limitaciones visuales y textuales durante las conversaciones con LLM, así como seleccionando y aceptando formatos de archivo que no elegiría normalmente, porque se adaptan mejor al flujo de trabajo de LLM.

Por lo tanto, mientras es divertido ver a los modelos de frontera tropezar en el mundo de David Brent, uno se pregunta si este es el escenario más probable para el ‘trabajador de oficina agente’.

Publicado por primera vez el miércoles 29 de julio de 2026. Actualizado 18:41 EET, enlace roto corregido.