En abril publiqué aquí un repaso escéptico sobre agentes de IA autónomos: qué funciona en producción, qué sigue siendo una demo bien montada y qué preguntarle a un vendor antes de firmar. La conclusión de entonces era cualitativa, basada en lo que veíamos en proyectos reales. Dos meses después han salido dos papers que hacen lo que ningún proveedor va a hacer por ti: ponerle números a esa frontera.
Los dos se publicaron con una semana de diferencia y, leídos por separado, parecen contradecirse. Uno dice que el mejor agente evaluado completa el 89% de las tareas que le echan. El otro dice que la tasa media de aprobado está por debajo del 1%. Ambos están bien hechos y ambos son correctos. La diferencia entre esas dos cifras no es un error de metodología: es, literalmente, el mapa que necesitas para decidir qué automatizar en tu empresa este año y qué dejar en manos de una persona.
Este artículo explica qué mide cada uno, por qué la distancia entre ellos define la frontera de lo automatizable, y cómo se traduce eso a decisiones concretas en una pyme.
Dos papers, dos mundos
WorkBench Revisited: el 89% que cambia el cálculo
El 10 de junio de 2026 se publicó "WorkBench Revisited" (arXiv 2606.13715). Es una reejecución de WorkBench, un benchmark de tareas de oficina acotadas que se publicó originalmente en 2024: mandar un correo, actualizar un registro en un CRM, cuadrar una reunión en un calendario, consultar y modificar datos en herramientas de trabajo típicas. Cosas de cinco minutos con un resultado comprobable.
La gracia de reejecutar un benchmark de hace dos años con los modelos de hoy es que mide el progreso real sobre un listón fijo, sin cambiar las reglas por el camino. Los datos de la versión del 10 de junio de 2026 son estos:
| Agente | Fecha | Tareas completadas | Acciones dañinas no intencionadas |
|---|---|---|---|
| GPT-4 | Marzo 2024 | 43% | 26% |
| Claude Opus 4.8 | Junio 2026 | 89% | 2,5% |
Es un salto grande en las dos columnas a la vez, y ese "a la vez" es lo interesante. La conclusión que sacan los autores es que capacidad y seguridad se están alineando, no compitiendo: el mismo modelo que completa el doble de tareas comete una décima parte de las acciones dañinas. Durante dos años la hipótesis dominante en el sector era la contraria —que un agente más capaz sería también más peligroso, porque tendría más margen para hacer estropicios—. Los datos de junio no la sostienen.
Que capacidad y seguridad avancen juntas es la noticia estructural del paper. Significa que esperar a modelos mejores no implica aceptar más riesgo operativo: implica menos, si el sistema alrededor está bien diseñado.
Aun así, los propios autores no venden triunfalismo. Señalan que los modelos frontera siguen cometiendo "errores básicos que ocasionalmente resultan en daño irreversible". Volveré sobre esa frase, porque es la que debería dictar cómo construyes el sistema.
Agents' Last Exam: el menos del 1% que lo pone en su sitio
Una semana antes, el 3 de junio de 2026, el grupo RDI de UC Berkeley publicó "Agents' Last Exam" (ALE, arXiv 2606.05405). El planteamiento es el opuesto: en lugar de medir microtareas de oficina, mide trabajo profesional real.
Cómo está construido importa, porque es lo que le da peso:
- Participaron más de 250 expertos de industria aportando tareas de su propio oficio.
- Son más de 1.000 tareas sobre una taxonomía de 55 subsectores agrupados en 13 clústeres, alineada con O*NET/SOC 2018 —la clasificación ocupacional estándar—. No es una lista de problemas que se le ocurrieron a un equipo de investigación: es un muestreo deliberado del mapa del trabajo.
- Todas las tareas tienen resultado verificable. No se puntúa "qué bien redacta": se comprueba si el entregable es correcto.
- Todas son de horizonte largo: el tipo de encargo que a un profesional le lleva días, no minutos.
El resultado, en palabras del paper: "a través de las configuraciones habituales de harness y backbone, la tasa media de aprobado completo está por debajo del 1%". Y el nivel de máxima dificultad sigue sin saturarse, es decir, no hay ninguna configuración que esté cerca de resolverlo.
Cuidado con las cifras que circulan en prensa sobre ALE. He visto varios porcentajes concretos por modelo que no aparecen en el abstract del paper y que no he podido verificar contra la fuente. El dato sólido, el que puedes citar sin sonrojarte en un comité, es el que está en el propio texto: aprobado completo medio por debajo del 1%.
Conviene subrayar qué significa "aprobado completo". No es una nota media ni un porcentaje de progreso. Es una tarea profesional terminada de principio a fin, correcta y verificada. Un agente puede haber hecho el 80% del trabajo y contar como cero. Eso es duro, pero es exactamente el criterio con el que se juzga a un profesional: un informe pericial al 80% no vale nada.
Por qué no es una contradicción, sino una definición de frontera
Poner 89% y "menos del 1%" en la misma frase suena a que uno de los dos papers está mal. No lo está. Están midiendo cosas que se parecen en la superficie —"un agente hace un trabajo"— y que son estructuralmente distintas en cuatro ejes.
| Eje | WorkBench (89%) | ALE (<1%) |
|---|---|---|
| Horizonte | Minutos, pocos pasos | Días, decenas o cientos de pasos encadenados |
| Criterio de éxito | Explícito y comprobable al instante | Verificable, pero sólo al final de todo |
| Contexto necesario | Está en la herramienta | Vive en la cabeza del profesional |
| Coste del error | Bajo y normalmente reversible | Alto, a menudo irreversible |
El eje del horizonte es el que más pesa, y por una razón aritmética. Si un agente acierta cada paso individual con probabilidad alta pero no perfecta, la probabilidad de acertar una cadena de cien pasos es esa probabilidad elevada a cien. Un sistema que acierta el 99% de las veces en un paso suelto falla más de seis de cada diez cadenas de cien pasos. Los errores no se compensan: se acumulan. Por eso una tarea que se resuelve en tres pasos y una que se resuelve en doscientos no están en la misma categoría de problema, aunque las dos las haga "la misma IA".
El eje del contexto tácito es el que más subestiman las empresas. Cuando un gestor decide cómo clasificar una factura rara, no aplica una regla escrita: aplica quince años de saber qué hace ese cliente concreto y qué criterio siguió el despacho en un caso parecido. Ese contexto no está en ningún documento que puedas pasarle al modelo, y ALE lo captura precisamente porque las tareas las escribieron profesionales de cada subsector.
El eje de la reversibilidad es el que define el diseño técnico, y le dedico su propia sección más abajo.
Cuando alguien te enseñe el resultado de un benchmark de agentes, la primera pregunta no es "¿qué nota saca?". Es "¿cuántos pasos tiene la tarea media y qué pasa si falla el paso 40?". Sin eso, el número no significa nada.
Leídos juntos, los dos papers dicen lo mismo desde dos lados: los agentes de 2026 son excelentes ejecutando y malos dirigiendo. Saben hacer el trabajo; no saben llevar el trabajo. Esa es la frase que resume la frontera, y encaja punto por punto con lo que veíamos en proyectos reales cuando escribí el artículo de abril.
Qué tareas de tu empresa caen del lado bueno
Traducido a una pyme, del lado de WorkBench cae todo lo que cumple las cuatro condiciones a la vez. No tres: las cuatro.
- Repetitiva. Se hace muchas veces al mes con la misma forma. Si ocurre dos veces al año, el coste de construir y mantener la automatización se come el ahorro.
- Verificable. Existe una comprobación objetiva y barata de si el resultado está bien. El campo del CRM tiene el valor correcto o no lo tiene. El importe cuadra o no cuadra.
- Con criterio de éxito claro y previo. Alguien puede escribir en una frase qué significa "bien hecho" antes de ver el resultado. Si el criterio es "que quede resultón", no es automatizable: es opinable.
- Reversible. Si sale mal, se deshace. Un borrador que se descarta, un registro que se corrige, un correo que aún no se ha enviado.
Ejemplos concretos que cumplen las cuatro en empresas con las que trabajamos: extraer los datos de una factura o un albarán y volcarlos a un campo estructurado; clasificar y enrutar correos entrantes a la persona o cola correcta; preparar el borrador de una respuesta comercial recurrente; actualizar un registro de CRM a partir de la transcripción de una llamada; cuadrar disponibilidad y proponer una cita; generar el resumen de un documento largo para que alguien lo revise en dos minutos en lugar de en veinte.
Fíjate en un patrón: en varios de esos ejemplos la palabra clave es borrador o propuesta. Convertir una acción irreversible en una propuesta reversible es la maniobra de diseño que mueve una tarea del lado malo al lado bueno sin cambiar el modelo. Volveré sobre esto.
Qué cae del lado malo (todavía)
Del lado de ALE cae todo lo que tiene alguno de estos cuatro rasgos. Basta con uno.
- Juicio profesional. La tarea consiste en decidir, no en ejecutar. Qué estrategia seguir en una reclamación, qué cliente merece un descuento excepcional, si un proveedor es de fiar. Aquí el agente puede preparar el material para que alguien decida, pero la decisión no se delega.
- Horizonte largo. El encargo se extiende días y encadena decenas de pasos dependientes entre sí. Los errores se acumulan y el agente no tiene forma fiable de saber que se ha desviado.
- Contexto tácito. La información necesaria no está escrita en ningún sitio: está en la experiencia de quien lo hace. Puedes documentar parte de ese contexto —y es un ejercicio que merece la pena por sí solo—, pero nunca todo.
- Consecuencias irreversibles. Dinero que sale, datos que se borran, comunicaciones que llegan a un cliente, presentaciones ante la Administración. Lo que no se puede deshacer no se automatiza sin confirmación humana. Punto.
Un matiz importante, porque es donde más se equivocan las empresas al planificar: el problema no suele ser el modelo, es la forma del proceso. Un proceso de horizonte largo con criterio ambiguo no se arregla esperando al siguiente modelo. Se arregla partiéndolo en trozos cortos y verificables, que es un trabajo de análisis de procesos, no de IA. Muchos proyectos que fracasan lo hacen porque intentaron automatizar una tarea de ALE con herramientas de WorkBench.
El dato que manda el diseño: 2,5% de acciones dañinas
Si sólo te llevas un número de este artículo, que sea este. No el 89%, que es el que sale en los titulares. El 2,5%.
Que el mejor agente evaluado tome una acción dañina no intencionada en el 2,5% de los casos significa una de cada cuarenta ejecuciones. Y "no intencionada" quiere decir exactamente eso: no es un ataque ni un jailbreak, es el sistema haciendo su trabajo y equivocándose de una forma que causa daño. Es un enorme avance frente al 26% de 2024, donde de cada cuatro ejecuciones una salía mal. Pero una de cada cuarenta no es cero, y la aritmética de producción es implacable: un agente que ejecuta cuarenta tareas al día produce, de media, un incidente diario.
Un 2,5% de acciones dañinas es perfectamente aceptable si todas son reversibles, y absolutamente inaceptable si alguna no lo es. La tasa de error no decide si puedes automatizar: decide qué arquitectura necesitas para poder hacerlo.
De ahí salen cinco reglas de diseño que aplicamos en cualquier automatización con agentes, y que no dependen de qué modelo uses:
1. Todo lo destructivo pasa por confirmación humana. Enviar un correo a un cliente, emitir una factura, borrar registros, mover dinero, presentar algo ante un organismo. El agente lo prepara y lo deja en cola; una persona da al botón. Esto no es desconfianza en la IA: es el mismo control que aplicarías a un becario competente en su primera semana.
2. Por defecto, el agente propone; no ejecuta. Cambiar la salida de "acción realizada" a "acción propuesta" mueve la tarea entera del lado peligroso al lado seguro. El ahorro de tiempo se conserva casi entero —el 90% del trabajo es preparar la acción, no darle a enviar— y el riesgo cae a cero.
3. Permisos mínimos y límites duros. El agente sólo accede a lo que necesita para su tarea concreta, en modo lectura salvo donde escribir sea imprescindible. Y con topes explícitos codificados fuera del modelo: número máximo de pasos, importe máximo, número máximo de registros afectados en una ejecución. Esos límites viven en tu código, no en el prompt, porque un límite que depende de que el modelo lo respete no es un límite.
4. Todo queda registrado y es reconstruible. Qué hizo el agente, con qué datos, en qué orden y con qué resultado. Sin traza no puedes auditar el incidente cuando ocurra, ni explicárselo a un cliente, ni corregir la causa. Y ocurrirá: una de cada cuarenta.
5. Deshacer tiene que estar diseñado, no improvisado. "Reversible" no es una propiedad que aparece sola. Significa versiones anteriores guardadas, papelera en lugar de borrado, colas de salida con retención de unos minutos, transacciones que se pueden revertir. Si tu diseño no contempla el deshacer desde el principio, en la práctica no es reversible.
Con estas cinco reglas, el 2,5% deja de ser un riesgo y pasa a ser un coste operativo conocido: una de cada cuarenta ejecuciones necesita que alguien la corrija. Eso se mide, se presupuesta y se compara con el ahorro. Es una conversación de negocio normal.
Ahí está, además, la síntesis de los dos papers en una sola frase: la capacidad la pone el modelo; la seguridad la pone tu arquitectura. WorkBench dice que la capacidad ya está para tareas cortas. El 2,5% dice que la arquitectura sigue siendo tuya.
Tabla de decisión: automatiza esto, no automatices esto todavía
Esta es la traducción práctica de los dos papers a una pyme española típica. La columna de la derecha es la que evita discusiones: explica por qué cae de ese lado, y ese porqué es reutilizable para tareas que no estén en la lista.
| Tarea | Veredicto | Por qué |
|---|---|---|
| Extraer datos de facturas, albaranes y contratos a campos estructurados | Automatiza | Repetitiva, verificable contra el documento, reversible |
| Clasificar y enrutar correos o tickets entrantes | Automatiza | Criterio de éxito claro, error barato y corregible |
| Redactar borradores de respuestas comerciales recurrentes | Automatiza | Sale como borrador; una persona revisa y envía |
| Actualizar registros de CRM tras una llamada o reunión | Automatiza | Campo correcto o incorrecto, verificable, con historial |
| Resumir documentación larga para revisión humana | Automatiza | El humano valida el resumen; coste de error mínimo |
| Cuadrar agendas y proponer citas | Automatiza | Horizonte corto, resultado comprobable al instante |
| Buscar y sintetizar información interna dispersa | Automatiza | Exploratorio, con revisión humana del resultado |
| Enviar comunicaciones a clientes sin revisión | No todavía | Irreversible: el correo enviado no vuelve |
| Emitir facturas o mover dinero de forma autónoma | No todavía | Consecuencia económica irreversible y auditable por terceros |
| Decidir precios, descuentos o condiciones comerciales | No todavía | Juicio profesional con contexto tácito de cada cliente |
| Gestionar una reclamación de principio a fin | No todavía | Horizonte largo + juicio + consecuencia legal |
| Presentar documentación ante la Administración | No todavía | Irreversible, con responsabilidad legal identificable |
| Contratar, evaluar o seleccionar personas | No todavía | Juicio sobre personas y requisitos regulatorios exigentes |
| Cualquier borrado o modificación masiva sin vuelta atrás | No todavía | Una de cada cuarenta ejecuciones basta para el desastre |
Sobre las dos últimas filas, un apunte: cuando la automatización afecta a derechos de personas, además del criterio técnico hay obligaciones regulatorias que conviene mirar antes de construir nada. La automatización bien diseñada ayuda a cumplir con la normativa —porque deja traza y hace explícito el criterio—, pero no exime de la evaluación previa. Si te toca ese terreno, el checklist del AI Act europeo es el punto de partida.
Cómo se traduce esto a un proyecto real
La tabla anterior es un mapa, no un plan. Para pasar de una a otro, el orden que funciona es este:
- Lista las tareas candidatas y clasifícalas con los cuatro criterios: repetitiva, verificable, criterio claro, reversible. Las cuatro o nada.
- Para las que fallan sólo por reversibilidad, comprueba si puedes rediseñar la salida como propuesta en lugar de como acción. Muchas cruzan al lado bueno con ese único cambio.
- Para las que fallan por horizonte largo, intenta partirlas. Una tarea de cuarenta pasos rara vez es automatizable entera, pero a menudo contiene tres bloques de cinco pasos que sí lo son, y ahí está la mayor parte del tiempo.
- Descarta sin pena las que fallan por juicio o contexto tácito. No es una tarea pendiente para el trimestre que viene: es trabajo humano, y está bien que lo sea.
- Valida la primera con datos reales antes de comprometer presupuesto. El framework de validación en cuatro semanas sirve exactamente para esto: fijar el umbral de éxito antes de ver los resultados y probar con datos sucios de verdad.
Y una recomendación de secuencia: empieza por una tarea aburrida y de volumen alto, no por la más vistosa. La aburrida te da un caso de éxito medible en semanas con el que justificar la siguiente.
Lo que estos papers no dicen
Por honestidad intelectual, tres límites de lo anterior.
Ninguno de los dos benchmarks es tu empresa. WorkBench mide tareas de oficina sobre herramientas simuladas; tu ERP de 2011 con su integración a medida no está ahí. Los porcentajes son una señal de dirección, no una predicción de lo que vas a obtener. Por eso el paso 5 de la lista anterior no es opcional.
"Menos del 1%" no significa que el agente no aporte nada en tareas largas. Significa que no las completa. Un agente que hace el 70% del trabajo de un informe largo y se lo deja preparado a un profesional puede ser rentabilísimo, y eso no aparece en la métrica. La lectura correcta de ALE no es "no lo uses para trabajo profesional", es "no lo dejes solo con trabajo profesional".
Los benchmarks miden modelos, y tú despliegas sistemas. Entre el modelo y el valor hay integración, permisos, datos, interfaz y personas que tienen que usarlo. La parte que decide si tu proyecto funciona rara vez es la del porcentaje del paper.
Conclusión
En abril decía que el éxito con agentes no consiste en tener el más autónomo del mercado, sino en tener procesos donde la IA hace bien la mayor parte del trabajo y las personas validan la parte crítica. Los dos papers de junio le ponen cifras a esa intuición: 89% en lo acotado, menos del 1% en lo profesional de horizonte largo, 2,5% de acciones dañinas.
Ese es todo el mapa. Automatiza lo repetitivo, verificable y reversible, que es más de lo que crees. No automatices el juicio profesional, y no porque un modelo futuro no vaya a poder, sino porque hoy no puede y la factura de equivocarse la pagas tú. Y diseña asumiendo que una de cada cuarenta ejecuciones va a salir mal: si eso te asusta para una tarea concreta, esa tarea necesita confirmación humana antes que un modelo mejor.
La ventaja competitiva de los próximos doce meses no va a ser tener el agente más avanzado. Va a ser saber de qué lado de esa frontera está cada proceso de tu empresa.
¿Hablamos?
Si quieres clasificar los procesos de tu empresa con estos criterios y saber cuáles se pueden automatizar hoy con garantías, cuéntanos tu caso en nuestro formulario de contacto. Revisamos juntos qué cae del lado bueno, qué necesita rediseñarse para cruzar y qué conviene dejar en manos de personas.
