La IA dijo que no podía. La estadística lo llamó rechazo.

Dentro del expediente

Quién hizo el estudio y qué estaban haciendo

Kolab es una investigación de un equipo de la Universidad de Minnesota encabezado por Shirley Anugrah Hayati. Su artículo se publicó como prepublicación académica en arXiv. La pregunta era cómo colaboran profesionales con agentes de IA para terminar trabajos que requieren varios pasos. No es un estudio nuestro ni una investigación sobre despachos españoles. El estudio y su método.

Reunieron a 50 profesionales de 40 ocupaciones. Cada participante eligió tareas procedentes de su trabajo y realizó dos sesiones grabadas de aproximadamente una hora. Usar Claude formaba parte del protocolo, aunque podían recurrir también a otras IA y a sus programas habituales. No era observar sin intervenir una jornada cualquiera. Cómo organizaron las sesiones.

Estos son trabajos concretos documentados en el artículo, no ejemplos inventados para esta pieza.

• Arquitectura. Pedir a Claude una distribución de espacios y reconstruirla en Revit, conservando parte de la propuesta y corrigiendo otra.
• Producción musical. Generar música con ElevenLabs e incorporarla a un proyecto audiovisual en DaVinci Resolve.
• Edición de vídeo. Pedir un clip a Kling AI, revisar su audio y descartarlo porque no servía para el montaje.

Los casos están en la tabla 2 del estudio. No estaban respondiendo un examen con una solución correcta conocida. Intentaban terminar tareas. Los investigadores clasificaron qué propuestas incorporaban tal cual, cuáles modificaban y cuáles rechazaban.

Un rechazo que no demuestra una falsedad

Una persona pide a ChatGPT un vídeo. La herramienta reconoce que no puede generarlo en ese chat y ofrece una imagen como alternativa. La propuesta figura como rechazada en un ejemplo de Kolab. No es un caso inventado para explicar una idea. Está en la tabla 9 del estudio. Fuente primaria.

Ese caso basta para detener un titular.

Si una respuesta reconoce una limitación y el profesional sigue por otro camino, el rechazo no demuestra que la máquina haya mentido. A veces lo responsable es precisamente no fingir que puedes hacer lo que te piden.

La diferencia importa cuando un estudio sale del laboratorio y empieza a circular por despachos, presentaciones y publicaciones de LinkedIn.

El porcentaje es correcto. La traducción puede no serlo.

La tabla 3 de Kolab recoge 692 anotaciones. De ellas, 456 corresponden a adopción, 132 a modificación y 104 a rechazo. Modificación y rechazo suman el 34,1 %. Los 508 son pasos del trabajo, otra unidad. Tabla original.

Hasta ahí, el dato.

El salto aparece al llamar a todo ese porcentaje «errores», «trabajo rehecho» o «cirugía experta».

Las etiquetas clasifican la incorporación de propuestas al trabajo. No son un examen independiente de exactitud. Modificar no significa necesariamente corregir una falsedad. Adoptar sin cambios tampoco acredita que se haya contrastado. Definiciones originales.

No estoy diciendo que la IA se equivoque menos. Tampoco que se equivoque más.

Estoy diciendo que esa cuenta no responde a esa pregunta.

El error que también podemos cometer quienes pedimos pruebas

Criticar una promesa de automatización es fácil. Basta con recordar que alguien responde por el resultado.

Lo incómodo es aplicar el mismo criterio a una frase que nos viene bien.

Si defiendo que revisar cuesta trabajo, una cifra de propuestas modificadas parece hecha a mi medida. Si defiendo la utilidad de una herramienta, una cifra de propuestas aceptadas parece demostrar mi caso.

Los dos usos pueden pasarse de frenada.

El defensor de la IA no puede convertir aceptación en acierto. El crítico tampoco puede convertir modificación en fallo.

La carga de justificar la traducción no desaparece porque la conclusión coincida con lo que ya pensábamos.

Lo que comprobé aquí, y lo que no

Las fuentes de esta pieza son el artículo académico de Kolab y el explorador público del mismo equipo. El explorador es material de esa investigación, no una segunda investigación independiente. El enlace de LinkedIn sirvió para llegar al estudio, no para sustituirlo como fuente.

Mi trabajo fue revisar las definiciones, los ejemplos y los recuentos publicados, y ejecutar una comprobación propia de la interfaz. No repetí las sesiones ni comprobé la exactitud de todas las respuestas de IA. Lo que sigue es el alcance concreto de esa comprobación.

Se descargó el explorador público de los autores, se fijó una copia a un commit concreto y se contaron sus marcadores con un script. No se descargaron vídeos ni se examinó el conjunto canónico de anotaciones.

El resultado del recuento fue este. Código y resultado de la comprobación.

La suma de los contadores de respuesta de las sesiones coincide con los marcadores. La comprobación independiente se hizo con otro método de lectura. Resultado de la comprobación propia.

Pero el total visual no coincide con las 692 anotaciones del artículo.

Con esos números habría sido muy fácil fabricar una exclusiva.

«He encontrado un error en el estudio». No. No he demostrado eso.

He contado elementos de una interfaz. Hay claves de origen y destino que aparecen varias veces. Eliminar esas repeticiones tampoco reconstruye las anotaciones, porque una misma relación puede corresponder a acontecimientos distintos.

Sin el export canónico y su correspondencia con el artículo, no atribuyo una causa a la diferencia. Ni revisión del conjunto, ni error de los autores, ni error de la interfaz.

Esa conclusión queda fuera de lo comprobado.

Conservo el número del artículo para hablar del artículo. Conservo el recuento del explorador para hablar de lo que conté en el explorador.

No los mezclo para conseguir una cifra más llamativa.

La prueba no consiste en acumular archivos

Guardar una copia de la fuente permite saber qué se leyó. Un script permite repetir una cuenta. Ninguno convierte automáticamente esa cuenta en la respuesta a la pregunta importante.

Mi script sabe contar etiquetas. No sabe si el profesional detectó un error, si adaptó un estilo o si abandonó una herramienta porque necesitaba otra cosa.

Esa separación es el asunto de fondo.

En un despacho puedes conservar el texto de la respuesta, la hora, la versión y el clic de aprobación. Tendrás un rastro. Para demostrar revisión necesitarás explicar qué se sometió a contraste.

Propongo distinguir estas preguntas, sin convertirlas en otro sello.

Qué se propuso. El resultado concreto, no «se utilizó IA».

Qué se contrastó. La fuente, el documento, el cálculo o el requisito utilizado para revisarlo.

Qué decidió la persona. Qué mantuvo o cambió y por qué.

Qué quedó sin comprobar. El límite que no debería desaparecer cuando se entrega el resultado.

Estas preguntas son una propuesta de trabajo. No son un protocolo validado por Kolab ni garantizan por sí solas que una conclusión sea correcta.

Medir ahorro exige otra cuenta

Una propuesta aceptada puede haber exigido mucha lectura. Una rechazada puede haberse descartado enseguida. El porcentaje de aceptación, por sí solo, no revela cuál de las dos consumió más trabajo.

Por eso no usaría este reparto para prometer una reducción de costes. Tampoco para anunciar cuánto tiempo roba la IA.

Para responder eso mediría el trabajo completo sobre una tarea definida, con una comparación adecuada y un criterio de calidad fijado antes. Separaría preparación, generación, revisión, corrección y entrega.

No he ejecutado esa comparación para esta pieza. No hay un porcentaje propio de productividad escondido detrás de estas líneas.

La cautela funciona en las dos direcciones. Esta lectura no demuestra que la IA no sirva. Impide usar una medida de adopción como si ya fuera una medida de fiabilidad o de ahorro.

Lo que esta pieza no demuestra

Kolab describe una muestra y un protocolo concretos. Sus autores advierten que el análisis es descriptivo, no una comparación poblacional entre profesiones. Alcance original.

Aquí no se han vuelto a ejecutar sus experimentos. No se han visto todas las grabaciones. No se han probado las capacidades actuales de ChatGPT, Claude ni ninguna herramienta de vídeo.

El ejemplo inicial describe un episodio documentado. No establece lo que esas herramientas pueden hacer hoy.

Tampoco he demostrado que la supervisión humana funcione por el mero hecho de existir. Sería cometer el mismo salto que estoy discutiendo.

Lo defendible es más concreto.

Saber qué aceptó una persona no basta para saber qué comprobó.

Si tu procedimiento registra lo primero, no lo presentes como prueba de lo segundo.

El expediente para comprobarlo

• Kolab, versión inicial del artículo. Tabla 3, definiciones del apartado 4.1, alcance del apartado 4.3 y ejemplo de la tabla 9.
• Explorador público fijado al commit utilizado. Es una interfaz, no se presenta aquí como export canónico del conjunto de datos.
• Descargar el código, el resultado y las instrucciones. El paquete no redistribuye el explorador de terceros. Las instrucciones enlazan la copia fijada al commit y el script comprueba su huella antes de contar. También puedes leer el resultado sin descargar el paquete.
• El humano que solo hace clic es un adorno caro. Para continuar la distinción entre presencia humana y revisión.
• Si comprobarlo cuesta lo que hacerlo, la IA no te ahorra nada. Para continuar con el coste de comprobar.

El expediente detrás del artículo.

Kolab, Benchmarking Human-Agent Collaboration in Long-Horizon Workflows ↗Hayati y otros · University of Minnesota · arXiv 2610.21109v1, 15 de octubre de 2026. Tablas 3 y 9 y apartados 4.1, 4.3 y A.4.1 · 2026
Prepublicación de investigación; fuente primariaExplorador público de Kolab, copia fijada al commit 638ade1 ↗Minnesota NLP · HTML del explorador publicado el 16 de octubre y consultado el 25 de octubre de 2026. Interfaz, no export canónico de anotaciones · 2026
Material público de los autores; recuento propio de marcadores

Fuentes consultadas hasta el 25 de octubre de 2026. Las recomendaciones y ejemplos son elaboración editorial y no se atribuyen íntegramente a estas fuentes. Comprueba versión y ámbito antes de aplicar una norma.

Divulgación general. Ninguna herramienta de esta web certifica la revisión, seguridad o conformidad de un proceso.