El mejor modelo de IA solo resuelve el 12% de las tareas laborales en el nuevo benchmark GDPx

El mejor modelo actual resuelve el 12% de las tareas profesionales reales. La cifra parece una errata, sobre todo si en su repositorio ya hay un proyecto escrito por IA. Pero ese es precisamente el resultado del nuevo benchmark GDPx de SemiAnalysis.

Qué evalúa el benchmark

SemiAnalysis es conocida por sus análisis del mercado de semiconductores y de la economía de la IA. El 2 de noviembre, la empresa publicó GDPx. Sus autores —Max Kan, Andrew Megalaa y el fundador de la empresa, Dylan Patel— lo concibieron como la prueba más exigente de las capacidades de los agentes. No evalúa conocimientos de hechos ni la capacidad de resolver problemas de olimpiadas, sino el desempeño en encargos por los que las empresas están dispuestas a pagar.

La elección de los autores es reveladora: la empresa analiza la IA desde una perspectiva económica, atendiendo al coste de los chips, los centros de datos y los tokens. Su pregunta principal no es «¿hasta qué punto es inteligente el modelo?», sino «¿sale a cuenta?». De ahí el énfasis en las tareas remuneradas.

Claude Opus 5.5, de Anthropic, obtuvo el mejor resultado global. Y ese resultado fue el mencionado 12%. Los demás modelos quedaron por debajo.

Una salvedad importante: el fragmento al que tenemos acceso no incluye detalles de la metodología, como la composición de las tareas, el método de evaluación o los resultados de otros modelos. Antes de citar la cifra en una presentación, consulte la publicación original de SemiAnalysis.

Por qué les cuesta tanto a los agentes

Una tarea laboral real no se reduce a una respuesta: exige una secuencia de pasos, desde comprender el contexto y elegir las herramientas hasta ejecutar el trabajo, comprobarlo y corregirlo. Un cálculo sencillo ilustra el riesgo. Si un agente completa cada paso con éxito en el 90% de los casos, terminará correctamente una secuencia de diez pasos aproximadamente en el 35% de los casos. Es un ejemplo ilustrativo, no un dato de GDPx, pero el mecanismo es el mismo: los errores se acumulan y, en el trabajo comercial, un resultado «casi correcto» a menudo vale cero.

Esto explica la distancia entre la percepción y las cifras. Cuando se le pide a un modelo que escriba una función o esboce un script, suele acertar. Cuando se le encarga una tarea completa —con instrucciones incompletas, código ajeno y la exigencia de dejarlo todo funcionando—, el panorama cambia. Un proyecto escrito por IA que «parece funcionar» y un encargo resuelto lo bastante bien como para que el cliente pague son cosas distintas.

Qué hacer al respecto

Para desarrolladores: no evalúe un agente por su demostración. Reúna entre 20–30 tareas reales propias, con criterios de aceptación claros, y ponga a prueba el modelo con ellas. Ese será su mini-GDPx particular. Registre la proporción de tareas completadas sin correcciones humanas: esa métrica es más honesta que cualquier puntuación media.

Para responsables de producto: incorpore supervisión humana al proceso. Si una función promete un funcionamiento totalmente autónomo, su alcance real puede ser varias veces menor de lo que sugieren las diapositivas de marketing. Incluya en los cálculos económicos el coste de revisar y mejorar el resultado.

Para fundadores: un 12% no es motivo para abandonar los proyectos de agentes. Es motivo para elegir casos de uso acotados, con secuencias cortas y una verificación barata, y para dejar de vender un «sustituto de un empleado». Un benchmark con un techo de rendimiento tan bajo también tiene una ventaja: no está saturado. Hay margen de mejora y permitirá observar el progreso de los próximos modelos.

Limitaciones

Un solo benchmark no refleja toda la realidad. Sus autores decidieron qué se considera una «tarea profesional real», y otro conjunto de tareas arrojará cifras diferentes. Además, SemiAnalysis es una empresa de análisis, no un laboratorio independiente, por lo que conviene examinar hasta qué punto son reproducibles los resultados y si el conjunto de tareas está disponible públicamente. Aun así, la señal es clara: sigue habiendo una gran distancia entre «escribir código» y «hacer el trabajo», y conviene medirla con tareas propias.