Tu IA te ahorró once horas. Y luego te pidió seis de vuelta.

Las horas que devuelve la IA vienen con un segundo trabajo

Empieza por los dos números que están más cerca el uno del otro. El Work AI Index 2026 de Glean, una encuesta a 6.000 trabajadores digitales a tiempo completo de EE. UU., el Reino Unido y Australia, preguntó cuánto tiempo les ahorra la automatización con IA y a dónde va ese tiempo. La respuesta: unas once horas a la semana ahorradas y 6,4 horas semanales dedicadas a hacer utilizable la IA: 2,3 horas para darle contexto, 2,2 horas para supervisar su salida y 1,7 horas para depurar sus errores. De las horas que la gente pasa cerca de la IA en total, el 37% se va en ese trabajo de mantenimiento y el 36% en producir algo.

La investigación de Workday llega al mismo punto desde otro ángulo: el 85% de los empleados dice que la IA le ahorra tiempo, y cerca del 40% de ese tiempo ahorrado vuelve a invertirse en revisar, corregir y rehacer la salida. La encuesta de Zapier a 1.100 usuarios de IA en EE. UU. encontró que el 58% dedica tres o más horas a la semana a revisar o rehacer lo que produjo la IA, con una media cercana a las 4,5 horas, y solo el 2% dice que rara vez necesita cambiar algo.

Tres encuestas, tres muestras, una dirección. Ninguna dice que la IA no sirva para nada. Dicen que la ganancia y el coste aterrizan en columnas distintas, y que la mayoría de las empresas solo mira la primera columna.

Eso importa más en una empresa pequeña que en una grande, y no porque los porcentajes sean peores. Importa porque quien revisa suele ser quien es dueño del negocio. Una empresa con un equipo de revisión puede absorber un aumento del 49% en el tiempo de revisión contratando. Una empresa de diez personas lo absorbe trabajando el sábado, o bajando el listón en silencio hasta que la revisión deja de detectar nada.

Así que la pregunta que merece respuesta no es «¿es exacta nuestra IA?». Es «¿cuánto de lo que produce lo tenemos que seguir revisando, y ese número está subiendo?». La primera pregunta tiene respuesta del proveedor. La segunda tiene una medición, y hasta hace poco nadie la había hecho.

Cuánto cuesta revisar, medido

En julio de 2026 un investigador independiente, Prerit Ahuja, publicó un artículo que hace lo aburrido que nadie hace en el mundo de los proveedores: contar la revisión. The Checking Problem puso a prueba seis flujos de trabajo cargados de documentos —extracción de campos fijos, cribado de entidades, conciliación entre documentos, clasificación normativa, resumen con atribución y comparación de varios documentos— con cuatro familias de modelos y tres niveles de esfuerzo de ingeniería, tres veces cada uno. Son 72 configuraciones y 5.093 elementos de salida puntuados uno a uno.

Cada configuración se juzgó dos veces. Primero contra lo que el artículo llama el listón de la demostración: una ejecución, un caso, todo correcto. Es la prueba que ve un comité de dirección, y es la prueba que casi todo piloto está montado para superar. Después contra un listón de producción, que pide cuatro cosas a la vez.

Cincuenta y siete de las 72 configuraciones superaron el listón de la demostración. Treinta y dos superaron el listón de producción. Eso deja una tasa de supervivencia del 56,1%, lo que significa que el 43,9% de las configuraciones que te habrían impresionado en una demostración no se pueden poner delante de un cliente, de una declaración o de una remesa de pagos.

El desglose es la parte útil. La exactitud estuvo implicada en 22 de los 25 fallos, así que sería un error afirmar que la exactitud da igual. Pero la exactitud por sí sola no predecía nada: tres configuraciones fallaron sin ningún problema de exactitud, y la reproducibilidad fue la única causa del fallo más veces que la exactitud. En los flujos que usaban documentos públicos reales, la confianza declarada por la herramienta apenas aportaba información sobre si acertaba —un AUC de 0,520, donde 0,5 es una moneda al aire—.

Y ahora el resultado que debería cambiar cómo compras. Una herramienta que no declara ninguna confianza exige revisar el 100% de su salida. No porque un responsable prudente haya decidido revisarlo todo, sino porque no hay ninguna señal con la que clasificar: si la herramienta nunca indica qué respuestas son flojas, quien revisa no tiene base para saltarse ninguna. Ese es el estado por defecto de la mayoría de las herramientas que una empresa pequeña puede comprar ya hechas.

Dos hallazgos más van contra la forma en que se suele vender la IA a un equipo pequeño. La exactitud dependía del flujo de trabajo, no del modelo: la extracción de campos fijos puntuó 1,000 en todos los modelos y configuraciones, mientras que la conciliación —decidir si un saldo declarado cuadra con un registro de transacciones, y por cuánto no cuadra— se quedó en 0,799. Y en una encuesta a 415 profesionales del software publicada en arXiv, el 84,3% de los usuarios frecuentes de IA generativa dijo que las herramientas no les habían reducido el tiempo de revisión, y los usuarios frecuentes eran más propensos que los ocasionales a decir que hacían más revisiones, no menos.

Un artículo con una muestra modesta no zanja un sector entero. Lo que sí zanja es la pregunta que probablemente te estabas haciendo: ¿hay forma de ponerle un número a la revisión, en lugar de intercambiar anécdotas sobre cómo se siente? La hay. Y en cuanto existe el número, resulta que la mitad se puede eliminar.

Dos preguntas que reducen la revisión a la mitad

El mismo artículo ejecutó los flujos de tres maneras, como una escalera de esfuerzo de ingeniería. La versión simple se limita a hacer la tarea, que es como está montada la mayoría de los pilotos. A la segunda se le pide que cite el pasaje fuente de cada elemento, que declare una confianza para cada uno y que se niegue explícitamente cuando el documento no respalde una respuesta. La tercera añade una pasada en la que la herramienta relee su propia salida contra la fuente y emite una corrección.

La versión simple exige revisar el 100% de su salida. La segunda exige el 49%, y lo consigue manteniendo el error residual dentro de la tolerancia en 17 de las 20 configuraciones probadas. La tercera baja al 44%: cinco puntos de mejora sobre la segunda, pagados con 2,3 veces la latencia, y es la única configuración del estudio que rompe la tolerancia de error.

Dicho claro: la ingeniería cara no compró una respuesta mejor. Pasar un flujo de la configuración simple a la verificada no produjo ninguna mejora medible de exactitud (cuatro configuraciones mejoraron, once empeoraron, p = 0,118) ni de reproducibilidad. Lo que compró fue atribución: la fundamentación subió de 0,933 a 0,952, algo que importa cuando el riesgo que cargas es un rastro de auditoría y no el volumen. Si tu exposición es «no podemos demostrar de dónde salió este número», paga la pasada extra. Si tu exposición es «esto tardó tres días y debería haber tardado uno», no la pagues.

Dos frases en una conversación con un proveedor son las que compran la primera mitad del ahorro. No «qué exacta es»: todos los pilotos reportan exactitud. Pregunta más bien: ¿cita el pasaje que usó, y me dice cuándo no está seguro? Exactitud, detectabilidad y fundamentación son tres propiedades distintas, y solo una de ellas aparece en el folleto.

La segunda mitad es un piloto que puedes hacer en una tarde sin comprar nada:

1. Coge un documento real del mes pasado, con la respuesta correcta ya conocida.
2. Pásalo por la herramienta tres veces con los mismos ajustes. Si las tres salidas difieren en el fondo, has encontrado un problema de reproducibilidad antes de que llegue a un cliente.
3. Subraya cada cita o cifra que te dé la herramienta y comprueba que el pasaje existe en el documento que nombra. Esto no exige ninguna especialidad y caza el fallo que más convincente parece.
4. Hazle una pregunta que el documento no pueda responder. Una herramienta que se inventa algo en lugar de negarse hará lo mismo delante de tu cliente.
5. Cuenta los minutos que dedicaste a los pasos 2 a 4 y divídelos entre el número de elementos producidos. Esa es tu tasa de revisión por elemento, y es el número del que va el resto del artículo.

También conviene saberlo antes de montar tu propia hoja de puntuación: estimar la carga de revisión a posteriori, con la ventaja de saber qué respuestas estaban mal, la infravalora unas 2,7 veces. Una herramienta que parece necesitar una muestra ligera cuando la revisas con la clave de respuestas delante necesita revisar casi toda su salida cuando la tienes delante sin ella. Calibra sobre una muestra piloto y luego aplica la regla a trabajo que no has visto, que es lo que hace un despliegue real.

Adónde se mueve el cuello de botella cuando nadie lo cuenta

Si este año vas a leer un solo estudio sobre IA y operaciones pequeñas, que sea el de la muestra aburrida y el resultado incómodo. Fiona Chen y James Stratton, ambos en Harvard, usaron un conjunto de datos de unos 300 millones de eventos de trabajo en 718 empresas —actividad de código, gestores de incidencias, calendarios y uso de herramientas de IA— entre enero de 2021 y marzo de 2026, y compararon empresas que adoptaron herramientas de IA para programar en momentos distintos.

El resultado de productividad es el que citan los proveedores. Los asistentes de IA produjeron un 12% más de líneas de código, un 9% más de commits y un 5% más de pull requests, y los agentes de IA, un 30%, un 20% y un 23% respectivamente. Luego los autores preguntaron si algo de eso llegaba a la producción de la empresa. Medido por incidencias resueltas y proyectos terminados, el efecto era pequeño y no estadísticamente significativo. Para los agentes, las estimaciones descartan un aumento de producción superior al 12%, frente al 30% de mejora a nivel de la persona que teclea.

¿Dónde se fue la diferencia? A la revisión. El tiempo medio para revisar un pull request subió un 49%. La proporción de pull requests que volvían con cambios solicitados casi se duplicó. Los comentarios por pull request subieron un 35%, y la proporción de personal que hace revisiones subió un 14%. El cuello de botella no desapareció cuando las empresas adoptaron herramientas de IA para ayudar en la revisión: los revisores humanos siguieron siendo centrales, y la cola se quedó donde estaba.

Dos detalles convierten esto en una historia de empresa pequeña y no en una historia de software. Primero, los autores estiman que los ingenieros dedican solo un 30-40% de su tiempo a escribir código; el resto se va en los pasos complementarios que lo rodean. Segundo, esa proporción no es exclusiva del software. En cualquier flujo que lleves, un paso produce y el siguiente aprueba, y el paso que aprueba es el que ocupa la persona con menos holgura.

Hay un efecto de segundo orden que debería preocuparte más que la propia cola. Un modelo de colas publicado en arXiv en 2026 describe qué pasa cuando la IA acelera la generación dentro de un flujo en el que las tareas compiten por la misma atención humana escasa: bajo congestión, quien revisa sube racionalmente su umbral de riesgo y revisa menos, precisamente cuando revisar es lo más importante. La IA parece rápida, el tiempo medio de gestión baja, y los errores que se cuelan vuelven más tarde en forma de retrabajo. La otra implicación del artículo es más dura: un flujo solo se estabiliza bajo carga si la proporción de trabajo que pasa por la IA es lo bastante alta y la atención necesaria para revisarlo es realmente menor que la atención necesaria para hacerlo a mano. Redactar más rápido no basta por sí solo.

Y luego está el problema de la percepción. En el ensayo aleatorizado de METR con desarrolladores de código abierto con experiencia, las tareas encomendadas a la IA tardaron un 19% más, no menos; los desarrolladores habían pronosticado una aceleración del 24% y, tras terminar, seguían creyendo que la IA les había acelerado en torno a un 20%. El propio seguimiento de METR en 2026 ya no pudo separar el efecto de cero, por motivos que documenta con honestidad, así que no cites el 19% como la verdad de hoy. Cita mejor la brecha: la gente juzga mal su propia velocidad cuando hay una máquina rápida en medio. Ese es todo el argumento para contar la revisión en vez de intuirla.

Un recuento de una semana que cabe en una hoja

No necesitas un consultor ni una licencia para medir tu propia carga de revisión. Necesitas una tarea repetible, un reloj y la disciplina de apuntar dos números en lugar de uno. Aquí está la aritmética sobre una empresa inventada con supuestos declarados, para que sustituyas los tuyos.

Pongamos que llevas una carpintería de diez personas que envía tres presupuestos al día, 22 días al mes. A mano, un presupuesto cuesta 45 minutos: 66 presupuestos son 49,5 horas al mes de presupuestar. Con la IA redactando la primera versión, supongamos que el borrador cuesta 10 minutos y revisarlo 12: 22 minutos en total, 24,2 horas al mes. Es un ahorro real de 25,3 horas, y es la versión que te va a enseñar el proveedor.

Ahora cambia una variable, porque aquí es donde se equivoca la mayoría de las empresas. Supongamos que los borradores vuelven fluidos pero con el valor U equivocado en una línea de puertas acristaladas, un precio de proveedor del trimestre pasado y un supuesto de plazo de entrega que nadie le contó a la herramienta. Revisar eso cuesta 40 minutos, no 12, porque ya no estás corrigiendo el texto: estás rehaciendo el presupuesto a partir de los documentos originales. Borrador más revisión: 50 minutos, frente a 45 a mano. El mes ahora va de 55 horas en vez de 49,5, y la herramienta ha convertido un trabajo de presupuestar en un trabajo de revisar.

El número que separa esos dos desenlaces es la proporción de revisión: los minutos de revisión divididos entre los minutos totales con IA. En el primer caso, 12 de 22, es decir el 55%. En el segundo, 40 de 50, el 80%. La misma herramienta, la misma empresa, veredicto opuesto, y ningún cuadro de mando te dirá en cuál de los dos estás.

Luego añade una columna que la aritmética no puede capturar: los errores que se escapan, los que pasaron por encima de ti y llegaron a un cliente, a un proveedor o a una cuenta bancaria. Un solo error de precio que se escape en una cocina a medida puede costar más que un año de horas ahorradas. Una proporción de revisión del 55% con cero errores escapados es mejor negocio que un 35% con dos.

La semana en sí es así. Elige la tarea con volumen real, al menos diez casos a la semana, para que un día raro no distorsione el resultado. Cronometra primero la versión manual, porque después de dos meses de borradores con IA nadie recuerda cómo se sentía hacerlo a mano. Luego, durante una semana, apunta por separado los minutos de borrador y los de revisión —una fila por elemento en una hoja de cálculo, o un temporizador de cocina y una cuenta en la pizarra—. Etiqueta cada corrección por tipo: cifra equivocada, dato que falta, cita que no existe, tono. Al final, cuenta los errores escapados y saca dos números: la proporción de revisión y los minutos ahorrados por elemento. Si el primero pasa del 60% y el segundo es negativo, ya tienes tu respuesta, y la has obtenido por el precio de una semana de atención.

Cuándo no poner la IA en una tarea

El material del proveedor nunca te dará esto, porque es la mitad de la decisión que les cuesta una venta. La conclusión del propio artículo fija la regla mejor que cualquier consultor: cuando revisar una salida es mucho más barato que producirla, la herramienta se paga incluso si la revisas entera. Cuando revisar cuesta casi lo mismo que decidir, no.

Traduce eso al trabajo que tienes sobre la mesa. Sacar doce valores de un albarán y llevarlos a una hoja de cálculo es una tarea barata de revisar: puedes confirmar cada valor de un vistazo, y la herramienta puntuó 1,000 exactamente en esa forma de trabajo. Decidir si un juego de cuentas cuadra, o si las circunstancias de un cliente encajan en una regla, es una tarea cara de revisar: confirmar la respuesta exige el mismo juicio que producirla. El mismo estudio puntuó la conciliación en 0,799, y ninguna cantidad de ingeniería de prompts la movió.

Así que, si la tarea es una decisión de criterio con una cifra detrás —qué presupuestar, qué prometer, qué firmar, qué declarar—, la IA puede preparar el material, pero no cuentes el borrado como ahorro. Has movido los mismos minutos a más temprano en el día y has añadido un paso donde puede colarse una respuesta equivocada y muy segura de sí misma. Si la tarea es una transformación acotada de un documento en el que ya confías, la herramienta merece la pena aunque mires cada línea.

Cuatro casos más en los que lo correcto es esperar o pasar de largo.

Si no tienes volumen, no tienes caso. El coste de montaje y el de revisión son por tarea, no por mes. Diez casos a la semana justifican una semana de medición; dos al mes no justifican nada, porque nunca vas a recuperar el tiempo de montaje ni vas a desarrollar el reconocimiento de patrones que hace rápida la revisión.

Si nadie en la empresa puede confirmar la respuesta, no la despliegues. Un revisor que no distingue un borrador bueno de uno malo no sirve de control: es una firma. Es el fallo que hay detrás de cada historia de contenido generado por IA que llega a un cliente con una referencia inventada: la persona que lo aprobaba no tenía forma de comprobarlo, y la confianza de la herramienta no aportaba información —un AUC de 0,520 en la mitad del estudio anterior que usaba documentos reales, donde 0,5 es una moneda al aire—.

Si el error solo se hace visible cuando es caro, mantén a la persona como quien decide, no como quien corrige el texto. Todo lo que lleve un compromiso de precio, una condición contractual o una declaración regulada pertenece ahí. El retrabajo que estás evitando no es un borrador, sino una conversación con un cliente.

Y no intentes comprar la salida del problema. La configuración verificada del estudio —la de la segunda pasada de autocomprobación— bajó al 44% de revisión en vez del 49%, corría 2,3 veces más lenta y fue la única que rompió la tolerancia de error. Pagar más por más maquinaria es el instinto de toda empresa, y aquí compró cinco puntos de tiempo de revisión y una garantía peor.

Un límite que conviene reconocer en todo esto: los estudios detrás del artículo midieron documentos del sector financiero, equipos de software y encuestas a grandes empleadores, no una carpintería en su segundo año. Sus números te dicen la forma del problema y dónde mirar. Solo tu propia semana te dice el tamaño del tuyo, y por eso el recuento de la sección anterior es la parte que merece la pena hacer hoy.

Preguntas frecuentes

¿Cuánto de la salida de una herramienta de IA tengo que revisar?

Si la herramienta no declara una confianza para cada respuesta y no cita el pasaje que usó, la respuesta es toda, porque no tienes base para saltarte nada. Esto no tiene que ver con la prudencia, sino con la aritmética: sin una señal que separe las respuestas sólidas de las flojas, cada elemento cuesta lo mismo de verificar. Añadir citas y una confianza declarada llevó la tasa de revisión medida del 100% al 49% en el estudio anterior.

¿Puedo reducir la revisión sin bajar la calidad?

En parte, y solo mejorando las entradas y no el modelo. Exigir un pasaje fuente para cada cifra, fijar la lista de precios o el documento que la herramienta puede leer, y conseguir que diga «no está en la fuente» en lugar de adivinar son las cosas que cambian la tasa de revisión. Lo que no funcionó en las mediciones fue añadir una segunda pasada de autocomprobación: movió la tasa de revisión del 49% al 44%, costó 2,3 veces la latencia y fue la única configuración que rompió la tolerancia de error.

¿Un modelo mejor o más caro reduce la carga de revisión?

Poco, con la evidencia disponible. La exactitud en el estudio de documentos variaba más por flujo de trabajo que por familia de modelos, y pasar de una configuración simple a una muy trabajada no produjo ninguna mejora medible de exactitud. Lo que varía entre modelos es hasta qué punto su confianza declarada acompaña a su corrección, y esa propiedad rara vez se publica. Pruébalo tú con tres ejecuciones del mismo documento.

¿Cuánto tardo en medir esto antes de saber algo?

Una semana de una sola tarea, con al menos diez casos dentro. Apunta por separado los minutos de borrador y los de revisión, etiqueta cada corrección y cuenta cualquier error que se haya escapado hacia un cliente o un pago. Salen dos números: la proporción de revisión y los minutos ahorrados por elemento. Si el segundo es negativo y el primero pasa del 60%, la herramienta te está costando tiempo y puedes dejar de discutir sobre ello.

¿Y si solo uso IA para correos y textos de marketing?

Entonces tu proporción de revisión será probablemente baja, porque una frase equivocada en un correo es barata de detectar y de corregir. Vigila los dos puntos donde eso deja de ser cierto: las cifras y las afirmaciones, que necesitan una fuente que puedas abrir, y todo lo que te comprometa con un precio, una fecha o un alcance. Esas son las frases que merecen revisarse línea a línea, no los adjetivos.

Si quieres un segundo par de ojos sobre dónde está aterrizando realmente la revisión en tu negocio, cuéntanos qué tarea sospechas. Construimos y medimos automatizaciones para empresas de cinco a cincuenta personas, y te diremos cuándo lo correcto es dejar un proceso en paz.