En julio de 2025, un equipo de investigadores de METR publicó el resultado de un experimento incómodo. Habían reclutado a dieciséis desarrolladores con años de experiencia en repositorios de software libre que ellos mismos mantenían, les habían pedido 246 tareas reales de su propio backlog y habían sorteado, tarea a tarea, si podían usar herramientas de IA o no. Antes de empezar, los participantes estimaron que la IA les haría un 24 % más rápidos. Al terminar cada tarea, calcularon que les había hecho un 20 % más rápidos.
El cronómetro dijo otra cosa: con IA tardaron un 19 % más.
Ese mismo año, con la misma tecnología disponible en el mercado, una consultora documentaba despliegues con tres veces más productividad y un 80 % menos de tiempo de ciclo, y un banco global pasaba de una mejora del 10-15 % con copilotos a mejoras del 40-80 % en los mismos equipos. No habían cambiado de modelo. Habían cambiado el proceso.
Entre esos dos extremos está casi toda la discusión seria sobre IA y procesos, y también casi todo el dinero. La conclusión que se repite en los datos de 2026, vengan de encuestas globales, de ensayos controlados o de despliegues reales, es siempre la misma y no tiene nada que ver con los modelos: la productividad de la IA no es una propiedad de la herramienta, es una propiedad del sistema formado por las personas, los agentes y el proceso que los conecta. Cambiar el tercer elemento es lo que separa a las empresas que ganan dinero con esto de las que sólo lo gastan.
La IA no arregla un proceso malo. Lo ejecuta más rápido, con más volumen y con menos gente mirando.
Este artículo es un intento de poner en orden lo que hoy sabemos sobre cómo se organiza una transformación de procesos basada en agentes: qué está demostrado, qué está emergiendo, qué sigue siendo una promesa de vendedor, y en qué secuencia hay que tomar las decisiones para no acabar en la estadística de proyectos cancelados. Al final encontrará la bibliografía con los enlaces a las fuentes originales, para que pueda contrastar cada cifra sin fiarse de mí.
La paradoja de 2026: mucha adopción, muy poco EBIT
Empecemos por el hecho que define el momento. La adopción de IA en la empresa ya no es un problema. El impacto económico sí.
La encuesta global State of AI de McKinsey de 2026 encuentra que prácticamente nueve de cada diez organizaciones usan IA con regularidad en al menos una función y que el 62 % está, como mínimo, experimentando con agentes. Hasta ahí, la historia de éxito. A partir de ahí, la factura: sólo el 39 % declara algún impacto en el EBIT a nivel de empresa, y apenas en torno al 6 % alcanza la categoría de high performer, definida como atribuir a la IA al menos un 5 % del EBIT y reconocer un valor significativo.
Dicho de otra forma: casi todo el mundo tiene la tecnología y aproximadamente una de cada dieciséis empresas puede demostrar que le ha cambiado la cuenta de resultados.
Lo que dicen las otras fuentes, que coinciden sospechosamente
Deloitte encuestó entre abril y junio de 2026 a 501 responsables estadounidenses —de senior manager a comité de dirección— en organizaciones que ya estaban al menos experimentando con agentes. El retrato es de una madurez muy desigual: el 42 % está en pruebas o pequeños despliegues, el 43 % expandiendo agentes por funciones aisladas y sólo el 15 % tiene sistemas multiagente orquestados a escala.
Lo interesante llega al cruzar esa foto con las expectativas. El 74 % de esos líderes espera que en cuatro años cerca de la mitad de sus procesos estén rediseñados o reconstruidos alrededor de agentes. Pero cuando se les pregunta por su preparación actual, sólo el 21 % se considera preparado o muy preparado en procesos de negocio, y sólo un 5 % dice estar muy preparado. Los procesos aparecen como el área más débil de todas las evaluadas. La brecha entre lo que se espera hacer en cuatro años y lo que se está en condiciones de hacer hoy es, probablemente, el dato más honesto de todo el informe.
Microsoft, en su Work Trend Index de 2026 —20.000 trabajadores del conocimiento en diez países, cruzados con telemetría de Microsoft 365—, aporta el otro lado del mismo fenómeno. Los agentes activos en su ecosistema se han multiplicado por quince en un año, y por dieciocho en las grandes empresas: la infraestructura ya no es experimental. Y sin embargo sólo alrededor del 19 % de los trabajadores se sitúa en la zona en la que capacidad individual y preparación organizativa se refuerzan, mientras que un 31 % son personas capaces atrapadas en organizaciones que no han cambiado. Microsoft lo llama, con bastante precisión, la paradoja de la transformación: los empleados están listos para reinventar cómo trabajan y el sistema que los rodea sigue premiando la forma antigua.
Un solo dato de ese informe basta para entender el resto del artículo: cuando modelan qué explica el valor percibido de la IA, los factores organizativos —cultura, comportamiento de los jefes, prácticas de talento— pesan alrededor de un 67 %, frente a un 32 % de los factores individuales. La variable dominante no es quién usa la herramienta. Es cómo está organizado el trabajo alrededor de ella.
Si el 90 % usa IA y el 6 % gana dinero con ella, el problema dejó de ser tecnológico hace bastante tiempo.
La trampa de la tarea: acelerar un paso no acelera el proceso
La explicación de la paradoja no es misteriosa. Es aritmética, y cualquiera que haya hecho Lean la reconocerá al instante.
Imagine un proceso cualquiera de los que se aprueban en un comité: cinco pasos, A a E. A cuesta dos horas de trabajo. B, un día. C, una hora. D es una aprobación que tarda tres días en llegar. E, dos horas. El proceso completo, de punta a punta, tarda algo más de cuatro días.
Ahora ponemos IA en B y lo bajamos de un día a una hora. Es una mejora espectacular: un 87 % menos de tiempo en esa actividad. La persona que ejecuta B nota la diferencia todos los días y la contará encantada en la encuesta interna de satisfacción. Y el proceso completo sigue tardando, redondeando, cuatro días.
Aquí está la contradicción aparente entre las encuestas: dos tercios de los usuarios de IA declaran dedicar más tiempo a trabajo de valor, y menos de cuatro de cada diez empresas ven algo en el EBIT. Ambas cosas son ciertas a la vez porque miden cosas distintas. La primera mide touch time, el tiempo en el que alguien está efectivamente trabajando sobre el caso. La segunda depende del lead time, que en la mayoría de los procesos administrativos está dominado por el queue time: el tiempo en el que el caso está parado esperando a que alguien lo mire.
En procesos de oficina reales, la proporción de tiempo de espera sobre tiempo total suele ser abrumadora. Si usted acelera el 10 % del reloj y deja intacto el 90 %, el cliente no percibe absolutamente nada. Y como el cliente no percibe nada, no hay ingreso adicional, no hay coste evitado y no hay línea en la cuenta de resultados. Sólo hay gente algo menos harta.
La pregunta que hay que cambiar
Casi todos los proyectos que fracasan empiezan con una pregunta perfectamente razonable y estructuralmente equivocada: «¿cómo consigo que este informe se redacte en veinte minutos en vez de en dos horas?».
La pregunta que produce valor es otra: «¿por qué existe este informe, quién necesita realmente su contenido, qué decisión provoca y podría esa información llegar directamente a esa decisión sin que nadie produzca el documento?».
La primera pregunta acelera trabajo. La segunda lo elimina. Y eliminar trabajo tiene una propiedad que acelerarlo no tiene: no hay que mantenerlo, ni supervisarlo, ni pagar tokens por él, ni auditarlo cuando llegue el regulador.
Antes de seguir: qué es un agente y qué es agent washing
Conviene detenerse un momento en el vocabulario, porque una parte no menor de los fracasos empieza por comprar una cosa creyendo que se compraba otra.
Gartner publicó en junio de 2025 una previsión que sigue siendo la más citada del sector: más del 40 % de los proyectos de IA agéntica se cancelarán antes de que termine 2027, por costes crecientes, valor de negocio poco claro o controles de riesgo insuficientes. En el mismo análisis introdujo el término agent washing: rebautizar como agentes productos que son asistentes, RPA o chatbots. Su estimación es que, de los miles de proveedores que se presentan como agénticos, apenas unos ciento treinta lo son de verdad.
La distinción operativa que hay que hacer antes de diseñar nada es esta:
| Categoría | Qué hace | Cuándo es la respuesta correcta |
| Asistente | Recupera información y redacta; el humano decide y ejecuta | Trabajo de conocimiento no repetitivo, sin acceso a sistemas críticos |
| Automatización determinista | Ejecuta un flujo cerrado; mismo input, mismo output, siempre | El proceso es estable, las reglas están escritas y el error es caro |
| Agente | Planifica varios pasos, usa herramientas y decide dentro de unos límites | El input es variable, hace falta juicio y el resultado admite verificación |
De aquí sale una regla que ahorra mucho dinero: si el proceso es estable y determinista, una regla sigue siendo mejor que un agente. Es más barata, más rápida, absolutamente predecible y trivial de auditar. Un IF/THEN no necesita reflexionar durante diecisiete mil tokens sobre si debe emitir una factura, ni requiere un marco de gobernanza, ni aparece en el informe de riesgos del consejo.
La consecuencia práctica es que «agentic first» no es una buena filosofía de diseño. La empresa no se diseña alrededor de los agentes; se diseña alrededor de resultados, y después se elige, actividad por actividad, la combinación más barata y fiable de personas, agentes, automatización determinista y software convencional. El orden inverso —decidir que hay que meter agentes y luego buscar dónde— es exactamente el que produce los proyectos que Gartner ve cancelarse.
Las seis restricciones que se rompen y las cuatro escaseces que aparecen
Los procesos que hoy tiene su empresa no son arbitrarios. Son la solución óptima a un problema que ya no existe.
Se diseñaron suponiendo que la inteligencia aplicada era un recurso caro, escaso, limitado a un horario y difícil de replicar. De ese supuesto salen, con lógica impecable, la secuencialidad (una persona detrás de otra), la especialización funcional (nadie puede saberlo todo), las capas de coordinación (alguien tiene que sincronizar a los especialistas) y los comités de decisión (el juicio experto es caro, así que se concentra). Nada de eso fue una tontería. Era la respuesta correcta a las restricciones de su época.
Lo que cambia con los agentes no es que trabajen mejor que las personas —en muchas cosas no lo hacen—, sino que relajan seis restricciones que estaban en los cimientos del diseño.
Y aquí viene la parte que casi nunca aparece en la presentación del proveedor: la escasez no desaparece, cambia de sitio. Un proceso agéntico no tiene los cuellos de botella del anterior, tiene otros nuevos, y son cuatro:
- Contexto fiable. Un agente sin acceso a datos correctos no es un agente, es un generador de contenido plausible. Deloitte encuentra que la falta de una base de datos unificada y accesible es el primer obstáculo declarado, por delante de cualquier consideración de modelo.
- Permisos e identidad. En cuanto un agente escribe en un sistema, alguien tiene que poder responder a quién era, quién lo autorizó y con qué límites.
- Verificabilidad. Producir más rápido sólo sirve si se puede comprobar a la misma velocidad. Si no, se acumula deuda.
- Capacidad de supervisión. Las horas humanas disponibles para revisar son finitas, caras y, como veremos, acaban dominando el coste del proceso.
Un rediseño que no piense explícitamente en esas cuatro cosas produce el resultado clásico: un piloto que funciona de maravilla con veinte casos y se vuelve ingobernable con veinte mil.
Se empieza por el resultado: del organigrama al mapa de trabajo
Si hay una sola idea estructural que merezca la pena rescatar de todo el material de 2025 y 2026, es la del Work Chart, popularizada por Microsoft en su Work Trend Index y desarrollada después en varias direcciones.
El organigrama responde a una pregunta: ¿quién depende de quién? Es una pregunta legítima para nóminas, carrera profesional y responsabilidad jerárquica, y completamente inútil para rediseñar un proceso, porque no dice nada de cómo ocurre el trabajo. Un mapa de trabajo responde a otra: ¿qué resultado hay que producir, qué trabajo y qué decisiones hacen falta para producirlo, quién o qué lo ejecuta y quién responde de él?
Llevado a su forma completa, ese mapa tiene diez capas, y merece la pena escribirlas porque cada una es una decisión de diseño que alguien va a tomar, con usted o sin usted:
| Capa | Pregunta | Error típico si se salta |
| Outcome | ¿Qué resultado concreto buscamos y cómo se mide? | Se optimizan actividades que no producen nada medible |
| Value stream | ¿Qué flujo lo genera, de punta a punta? | Se mejora un tramo y se empeora el conjunto |
| Work | ¿Qué trabajo es realmente necesario? | Se automatiza trabajo que sólo existía por costumbre |
| Decisions | ¿Qué decisiones hay dentro y dónde se toman? | Se acelera la ejecución y la decisión sigue tardando tres días |
| Information | ¿Qué información necesita cada decisión? | El agente alucina porque nadie le dio el contexto |
| Capabilities | ¿Qué capacidad hace falta para ejecutarlo? | Se compra herramienta y falta el criterio para usarla |
| Execution | ¿Humano, agente o regla determinista? | Se pone un agente donde bastaba una condición |
| Handoffs | ¿Qué se transfiere y en qué formato? | La espera vuelve a aparecer, ahora entre agentes |
| Controls | ¿Qué hay que verificar y cuándo? | El control se hace al final y descubre todo a la vez |
| Accountability | ¿Quién responde del resultado? | Cuando falla, no hay nadie con nombre |
Cómo se levanta ese mapa sin morir en el intento
Hay un problema previo, y es viejo: la empresa conoce su procedimiento, no su proceso. Conoce lo que está escrito en la norma interna, no lo que realmente ocurre cuando el caso llega con la documentación incompleta un viernes por la tarde. Y el rediseño se hace sobre lo segundo, no sobre lo primero.
De ahí que el process mining y el task mining hayan pasado de ser una herramienta de mejora continua a ser un prerrequisito de la transformación agéntica. Sacar de los logs las variantes reales del proceso, sus cuellos de botella, su retrabajo y sus excepciones cuesta semanas y evita meses. La secuencia sensata es:
- Logs de eventos de los sistemas por los que pasa el caso.
- Variantes reales: cuántos caminos distintos existen de verdad y qué porcentaje del volumen cubre cada uno.
- Separación de touch time y queue time en cada paso. Este es el dato que casi nadie tiene y el que decide dónde está el dinero.
- Mapa de decisiones: qué se decide, con qué información, quién lo hace y cuánto tarda.
- Coste actual por resultado completado, todo incluido. Sin esa línea base, cualquier mejora posterior será una opinión.
Un aviso desde la experiencia: los talleres con las personas que ejecutan el proceso siguen siendo imprescindibles, porque el mining ve lo que se registra y no ve el correo, el Excel paralelo ni la llamada de teléfono que resuelve la mitad de las excepciones. Casi todo proceso real tiene una economía sumergida que no está en ningún sistema y que sostiene el resultado.
El orden del rediseño: eliminar, simplificar, automatizar y sólo entonces agentificar
Con el mapa delante, empieza el rediseño. Y aquí es donde el orden importa más que las medidas.
McKinsey propone hacerlo con una clean sheet: no preguntar cómo acelerar el proceso actual, sino cómo debería funcionar si hoy pudiéramos diseñarlo desde cero con las personas y los agentes disponibles. Esa formulación es correcta pero difícil de operar en una sala llena de directivos que llevan quince años defendiendo su tramo. En la práctica funciona mejor una secuencia explícita de cuatro preguntas, obligatoriamente en este orden:
- 1. Eliminar. ¿Este trabajo debería existir? Informes que nadie lee, conciliaciones que existen porque dos sistemas no se hablan, aprobaciones que se pusieron en 2011 después de un incidente que ya nadie recuerda, comités cuya única función es consolidar información. La pregunta de control: ¿qué decisión cambia si esto desaparece? Si la respuesta es «ninguna», ya tiene su primer ahorro y es gratis.
- 2. Simplificar. Lo que sobrevive, ¿puede hacerse con menos pasos, menos handoffs y menos esperas? Cada transferencia entre áreas es una cola en potencia. Cada campo que se pide «por si acaso» es un motivo de excepción futura.
- 3. Automatizar. Lo que queda y es estable y determinista no necesita un agente: necesita una regla, una integración o un flujo clásico. Más barato, más rápido, más auditable.
- 4. Agentificar. Sólo lo que llega hasta aquí —input variable, necesidad de juicio, resultado verificable— justifica un agente.
El error dominante en 2026 consiste en entrar directamente por el escalón 4. Se compra la plataforma, se monta un catálogo de casos de uso y se agentifica el proceso tal y como está, con sus informes inútiles, sus aprobaciones fósiles y sus handoffs intactos. Deloitte tiene un nombre para eso: layering, poner una capa de agentes encima del proceso existente.
En defensa del layering (y contra confundirlo con el destino)
Aquí conviene matizar un discurso que se ha vuelto demasiado cómodo. El layering no es intrínsecamente malo, y el propio Deloitte no lo condena: puede ser una excelente fase de aprendizaje. Genera retorno temprano, desbloquea financiación interna, desarrolla capacidades reales en los equipos, saca a la luz los problemas de datos que nadie quería mirar e identifica dónde están de verdad los cuellos de botella.
La formulación correcta es layering como puente, no como destino. La secuencia sensata es poner la capa, aprender, medir, rediseñar y entonces escalar. El problema aparece cuando la empresa confunde el primer escalón con la transformación terminada, declara victoria en un comité y se queda ahí durante tres años.
Poner agentes sobre el proceso actual es una forma legítima de aprender. Es una forma pésima de terminar.
De secuencial a paralelo: donde está el dinero de verdad
Si tuviera que elegir una sola palanca de rediseño para un proceso administrativo, elegiría esta, y no está ni de lejos tan explotada como debería.
Tome cualquier flujo de aprobación —una operación de crédito, una contratación, un alta de proveedor, un expediente de siniestro— y observe su forma: documentación, después riesgo, después legal, después financiero, después aprobación. Esa secuencia no responde a ninguna dependencia lógica real. Legal no necesita esperar a que riesgo termine. Financiero no necesita el informe de legal para hacer su parte. La secuencia existe porque son personas distintas con agendas distintas, y una persona no puede estar en cuatro sitios a la vez.
Un sistema multiagente sí puede. Riesgo, legal, financiero y validación documental pueden ejecutarse simultáneamente sobre el mismo expediente, consolidarse en un único informe y llegar a la persona que decide con todo el material contrastado. El proceso pasa de una cadena a un abanico que converge.
Lo relevante de este movimiento es que puede generar valor aunque ninguna actividad individual mejore. Si cada comprobación sigue costando lo mismo pero se hacen a la vez, el lead time se desploma. Y el lead time sí es visible para el cliente, sí compite en el mercado y sí aparece en la cuenta de resultados. BCG documenta en despliegues agénticos rediseñados de extremo a extremo reducciones de tiempo de ciclo de hasta el 80 %, frente a las mejoras del 10-20 % típicas de las primeras oleadas de IA. La diferencia entre ambas cifras es, en buena medida, esta decisión de arquitectura.
Los dos relojes: machine loop y human loop
La segunda consecuencia de la paralelización es menos obvia y bastante más disruptiva. Los agentes no tienen horario. Pueden trabajar de noche, de madrugada y en agosto. Eso genera dos ciclos que conviven en el mismo proceso a velocidades distintas: un ciclo de máquina que se mide en segundos o minutos y un ciclo humano de gobierno que se mide en horas o días.
En desarrollo de producto esto ya se observa como una especie de turno nocturno: los agentes investigan, generan, prueban y preparan alternativas mientras el equipo no está, y por la mañana las personas revisan, deciden y reorientan. McKinsey señala que estos flujos empiezan a parecerse muy poco a las secuencias clásicas de Scrum, y tiene sentido: el sprint es una unidad de sincronización inventada para gestionar capacidad humana finita. Cuando parte de la capacidad deja de ser finita y de estar sincronizada, la cadencia deja de ser la unidad natural de coordinación.
No, Agile no ha muerto; ese titular conviene dejárselo a quien necesite impresiones. Lo que cambia es más concreto: el cuello de botella del proceso se desplaza. Cuando las cuatro comprobaciones ocurren en paralelo y en minutos, el nuevo límite del sistema es cuánto tarda un humano en decidir. Y ahí entramos en la parte del diseño que casi ninguna organización ha hecho.
Derechos de decisión: la pieza que casi nadie diseña
Durante décadas, el diseño de procesos consistió en repartir tareas: quién hace qué. La aparición de actores digitales capaces de ejecutar introduce una pregunta distinta, que es de gobierno y no de operaciones: qué tiene derecho a decidir cada uno.
La confusión más cara del momento es asimilar capacidad técnica con autoridad organizativa. Un agente puede ser perfectamente capaz de conceder un descuento de treinta mil euros; que pueda no significa que deba. Son dos decisiones separadas y las toman personas distintas: la primera es de ingeniería, la segunda es del comité de dirección.
La escala que mejor funciona en la práctica tiene seis niveles. Conviene escribirla literalmente para cada decisión relevante del proceso, no para el proceso en su conjunto:
| Nivel | El agente | La persona | Cuándo tiene sentido |
| 0 | Informa: recopila, limpia y resume | Decide y ejecuta | Decisiones irreversibles con impacto material |
| 1 | Recomienda una opción y su razonamiento | Decide | Juicio experto con consecuencias externas |
| 2 | Prepara la acción completa | Aprueba antes de ejecutar | Alto impacto pero patrón repetitivo |
| 3 | Ejecuta y deja traza | Es informada; puede auditar | Impacto medio y reversible |
| 4 | Ejecuta salvo excepción | Gestiona sólo la excepción | Alto volumen, error acotado y detectable |
| 5 | Opera de forma autónoma | Supervisa el sistema, no el caso | Impacto bajo, totalmente reversible |
Cómo se elige el nivel sin discutir durante seis meses
La regla operativa es sencilla de enunciar y sorprendentemente eficaz para cerrar debates:
Riesgo ≈ probabilidad de error × autonomía × alcance × irreversibilidad.
Los cuatro factores se multiplican, lo que significa que basta con que uno sea muy alto para que el producto lo sea. Una devolución de cinco euros y una decisión de contratación no pueden tener la misma arquitectura de autonomía, por muy competente que sea el modelo en ambas. Y la variable que más se olvida es la cuarta: la irreversibilidad. Un error que se puede deshacer en dos clics no es el mismo problema que un correo enviado a doce mil clientes o una transferencia ejecutada.
De esa fórmula sale también el argumento contra el exceso de control, que es un fallo tan grave como el defecto. Si usted construye un agente capaz de actuar y luego le pone encima revisión humana, aprobación del responsable, validación de riesgos y firma final, ha construido un agente autónomo y a continuación una pequeña administración pública para impedirle actuar. El resultado no es más seguro: es más lento, más caro y, sobre todo, psicológicamente peor, porque cuando un humano tiene que aprobar trescientas operaciones intrascendentes al día deja de leerlas. El NIST lo llama fatiga de consentimiento: la supervisión se convierte en un clic de goma y el control real desaparece justo cuando parece máximo.
La gobernanza tiene que ser basada en riesgo, no basada en todo.
El Agent Charter: una página por agente
La forma práctica de materializar todo esto es un documento corto —una página— por cada agente desplegado, que responda siempre a lo mismo:
- Propósito de negocio y resultado del que forma parte.
- Propietario humano, con nombre y apellidos. No un área.
- Sistemas a los que accede, distinguiendo lectura de escritura.
- Nivel de decisión (0 a 5) por cada tipo de acción, no uno global.
- Límites duros: importes, volúmenes, tipos de cliente, ventanas horarias.
- Presupuesto de cómputo y coste máximo por caso.
- Ruta de escalado: qué dispara una excepción y quién la recibe.
- Criterio de retirada: qué tiene que ocurrir para apagarlo.
El último punto es el que casi nunca está escrito y el que más se agradece a los seis meses.
El proceso se diseña alrededor de la excepción, no del happy path
Este es probablemente el cambio de mentalidad más importante de todo el artículo, y el que menos aparece en las presentaciones.
El diseño tradicional funciona así: se define el flujo estándar, se documenta con cuidado y las desviaciones se tratan como anomalías que alguien resolverá a mano. Mientras el trabajo lo hacían personas, esto tenía sentido: una persona absorbe la variabilidad sin que nadie lo note, aunque le cueste dos horas y tres llamadas.
En un proceso agéntico eso deja de funcionar, porque la excepción ya no es un caso raro que absorbe el sistema: es el único trabajo humano que queda, y por tanto define la economía completa del proceso. El diseño se invierte. El objetivo no es dibujar el camino feliz, sino maximizar el straight-through processing y construir con cuidado quirúrgico el carril de excepciones.
Hacer esto bien exige responder a cuatro preguntas antes de desplegar nada, no después del primer incidente:
- Qué constituye una excepción. No «cuando el agente falle», sino un criterio explícito: confianza por debajo de un umbral, importe por encima de un límite, cliente de un segmento determinado, contradicción entre fuentes, ausencia de un dato obligatorio.
- Quién la recibe. Una persona o un rol con nombre y con capacidad de decidir, no una cola compartida donde los casos envejecen hasta que alguien se apiada.
- Con qué llega. El agente no debe entregar el problema: debe entregar el contexto completo, lo que ya ha comprobado, las opciones y su recomendación. La diferencia entre un caso que se resuelve en tres minutos y uno que cuesta cuarenta está aquí.
- Cómo vuelve. Resuelta la excepción, el caso tiene que reincorporarse al flujo automático sin que nadie reintroduzca datos a mano. Si no, ha creado usted un proceso paralelo manual, que es exactamente lo que quería eliminar.
Y hay una quinta, que es la que separa un sistema que mejora de uno que se estanca: cada excepción debe alimentar el rediseño. Si al cabo de tres meses las excepciones siguen siendo las mismas y en la misma proporción, el proceso no está aprendiendo; simplemente ha trasladado el trabajo manual de sitio.
La próxima batalla de productividad no es automatizar el 90 %. Es pasar del 90 % al 97 %. Ese último tramo suele valer más que todo el primero.
Verificación por diseño: no se puede controlar al final
Hay un dato de la encuesta de McKinsey sobre desarrollo de producto que debería estar en la primera diapositiva de cualquier comité de IA. En los equipos analizados, el ahorro medio de tiempo rondaba el 11,8 %. La reducción de retrabajo, en cambio, se quedaba en el 6,2 %.
Traducido: estamos acelerando la producción aproximadamente al doble de velocidad de la que mejoramos la calidad. Esa diferencia no se evapora. Se acumula, primero como retrabajo y después como deuda técnica, deuda documental o deuda de proceso, según el dominio. Y la deuda generada por IA tiene una característica especialmente incómoda: se genera a velocidad de máquina y se paga a velocidad humana.
La respuesta arquitectónica es meter la verificación dentro del flujo en lugar de ponerla al final. El patrón, simplificado:
- Ejecutar la actividad.
- Verificar automáticamente contra criterios explícitos: requisitos, coherencia interna, límites financieros, reglas de compliance, seguridad, presencia de los datos obligatorios.
- Puntuar la confianza del resultado.
- Enrutar según riesgo: riesgo bajo, el propio sistema corrige y sigue; riesgo medio, verificación humana; riesgo alto, parada y escalado a un experto responsable.
La regla que se deduce es la que debería gobernar todas las decisiones de autonomía: cuanta más autonomía se concede, más importa haber diseñado la verificabilidad. No la verificación —que es una actividad— sino la verificabilidad, que es una propiedad del diseño. Un proceso cuyo resultado no se puede comprobar automáticamente no debería operar por encima del nivel 2 de la escala anterior, por muy bueno que sea el modelo.
El requisito ambiguo, multiplicado por la velocidad
Hay un corolario poco intuitivo. En un proceso humano, una instrucción ambigua produce una pregunta: alguien levanta la mano y pide aclaración. En un proceso agéntico, una instrucción ambigua produce, a gran velocidad y en gran volumen, resultados plausibles e incorrectos que nadie ha cuestionado.
Por eso la calidad de los requisitos deja de ser una cuestión de documentación y pasa a ser una cuestión de control. McKinsey lo formula con una prueba práctica muy útil: un requisito tiene que poder ser usado simultáneamente por el agente que ejecuta, la persona que revisa, la batería de pruebas que valida y el auditor que pregunta. Si sólo lo entiende quien lo escribió, no es un requisito: es una nota.
La economía real: coste por resultado, no por token
Llegamos a la parte que suele decidir si el proyecto sobrevive al segundo año.
La contabilidad tradicional de la automatización mide licencias, transacciones y FTE ahorrados. En un proceso probabilístico esa cuenta es directamente engañosa, porque el consumo varía con la complejidad del caso y porque los costes relevantes están fuera de la factura del proveedor. La métrica correcta es el coste totalmente cargado por resultado completado: no por token, ni por agente, ni por tarea, sino por cliente incorporado, siniestro resuelto, pedido conciliado o incidencia cerrada.
Coste por resultado = coste humano + coste de IA + sistemas + supervisión + excepciones + errores, dividido entre resultados completados.
Cuando se calcula así aparece el hallazgo que más ha cambiado la conversación en 2026. En flujos bancarios complejos analizados por McKinsey, la supervisión humana llega a representar en torno al 70-75 % del coste variable, mientras la inferencia se queda en el 20-25 %.
Eso da la vuelta al problema económico. El reto deja de ser «hagamos que el modelo sea más barato» y pasa a ser «hagamos que el proceso necesite menos intervención humana». Son proyectos completamente distintos, con equipos distintos y presupuestos distintos.
La aritmética de las excepciones, que nunca falla
Un ejemplo numérico sencillo explica por qué la excepción es la variable dominante. Supongamos un proceso con un 95 % de casos automáticos a 0,50 € cada uno y un 5 % de excepciones que requieren a un especialista y cuestan 30 € cada una.
El coste medio ponderado es 0,95 × 0,50 + 0,05 × 30 = 1,975 €. De esos 1,975 €, un euro y medio procede de las excepciones: casi el 76 % del coste lo genera el 5 % de los casos.
Las consecuencias de esta aritmética son bastante contundentes:
- Bajar el coste de inferencia un 30 % mueve el coste total apenas un 7 %. Bajar la tasa de excepción del 5 % al 3 % lo mueve casi un 30 %.
- Reducir en diez minutos el tiempo de resolución de cada excepción vale más que cambiar de proveedor de modelo.
- Un proceso con una tasa de excepción por encima del 15 % rara vez es rentable: la fricción y los handoffs se comen la automatización del resto.
Por eso las tres métricas que hay que poner en el cuadro de mando desde el primer día no son de tecnología: tasa de excepción, minutos humanos por excepción y toques humanos por resultado. Si esas tres bajan, el proyecto va bien aunque el gasto en tokens suba. Si no bajan, el proyecto va mal aunque el gasto en tokens baje.
El valor que no está en el ahorro de horas: el dividendo de decisión
Todo lo anterior asume implícitamente que el objetivo es hacer lo mismo más barato. Es el objetivo más pequeño de los tres posibles, y probablemente el menos interesante.
Hay un argumento económico que se ha ido consolidando durante 2026 y que conviene tomarse en serio: el mayor valor de la IA no suele venir de eliminar trabajo, sino de permitir decisiones que antes no salían a cuenta. La lógica es sencilla. Los gastos generales y administrativos representan típicamente una fracción acotada de los ingresos de una compañía; recortar ahí tiene un techo aritmético evidente. En cambio, mejorar las decisiones que gobiernan el negocio principal —qué precio poner, a qué cliente atender, dónde colocar el inventario, qué riesgo aceptar— actúa sobre el margen, que no tiene ese techo.
Los tres niveles, en orden creciente de valor y decreciente de facilidad para justificarlos en un comité:
- Eficiencia. Hacer lo mismo más barato. Se mide en horas y en coste unitario. Es donde está casi todo el discurso actual y donde está casi todo el techo.
- Eficacia. Hacerlo mejor: menos errores, mejores decisiones, más consistencia. Se mide en calidad, en retrabajo evitado y en riesgo no materializado.
- Expansión. Hacer lo que antes no tenía sentido económico. Si un servicio requería una hora de experto, sólo podía ofrecerse a clientes suficientemente rentables. Si la inteligencia marginal se abarata mucho, ese mismo servicio puede ofrecerse a todo el long tail. No ha reducido plantilla: ha ampliado el mercado direccionable.
El indicador que captura esto es incómodo porque nadie lo tiene en su cuadro de mando: el throughput de decisiones. Cuántas decisiones relevantes es capaz de tomar la organización por unidad de tiempo, con qué latencia y con qué calidad. Antes se podían revisar mil clientes al año, con lo cual se revisaban los mil más grandes y el resto recibía una política media. Ahora se pueden revisar todos. Eso no aparece como ahorro en ninguna partida y puede ser la mayor fuente de valor del proyecto.
La pregunta deja de ser cuántas horas ahorramos y pasa a ser cuántas decisiones buenas más podemos tomar.
Un aviso, porque esto se malinterpreta con facilidad: tomar más decisiones no es un bien en sí mismo. Una organización que multiplica por mil sus decisiones sin haber diseñado la verificación multiplica por mil sus errores. El dividendo de decisión sólo existe si antes se ha construido la parte aburrida: datos fiables, verificación integrada y derechos de decisión explícitos. Sin eso no hay dividendo, hay volumen.
La capa que se construye una sola vez: AI Control Plane y AgentOps
Con cinco agentes, todo se puede administrar artesanalmente. Con quinientos, la administración artesanal es la causa del incidente.
La convergencia entre consultoras, fabricantes y organismos de normalización en este punto es notable: escalar agentes exige separar de forma estricta el plano de ejecución —los modelos, los frameworks, las herramientas, las integraciones— del plano de control, que es determinista, está escrito en código convencional y por el que pasa absolutamente todo.
Las funciones que esa capa tiene que cubrir están razonablemente estabilizadas:
| Función | Qué resuelve | Qué pasa si falta |
| Identidad | Cada agente tiene una identidad propia y verificable | Las acciones aparecen bajo la credencial de una persona |
| Permisos | Acceso mínimo necesario, separando lectura y escritura | Un agente de consulta acaba pudiendo modificar el ERP |
| Herramientas | Qué API o comando puede invocar cada agente | Integraciones que nadie inventarió ni puede retirar |
| Memoria y contexto | Historial coherente entre pasos y entre agentes | Contradicciones y alucinaciones en flujos largos |
| Políticas | Reglas de negocio y límites aplicados en tiempo de ejecución | Cada equipo reinventa sus propios controles |
| Observabilidad | Traza paso a paso de entradas, salidas y herramientas | Los incidentes no se pueden reconstruir |
| Evaluación | Validación continua de salidas y detección de deriva | La calidad baja durante meses sin que nadie lo note |
| Coste | Consumo por agente, por caso y por resultado | La factura aparece agregada y no se puede gestionar |
| Audit trail | Registro inmutable de quién autorizó qué y cuándo | No hay defensa posible ante una reclamación |
En el terreno técnico, la conversación de 2026 gira en torno a estándares ya existentes reutilizados para este problema: identidades de carga de trabajo tipo SPIFFE, autorización delegada con OAuth 2.0 y protocolos estandarizados de acceso a herramientas como el Model Context Protocol. El NIST ha formalizado la línea de trabajo con su AI Agent Standards Initiative, lanzada en febrero de 2026, y el NCCoE publicó ese mismo mes un documento conceptual específico sobre identidad y autorización de agentes de software. En seguridad aplicada, la referencia práctica es el Top 10 for Agentic Applications de OWASP, que cataloga superficies de ataque que no existían con los modelos conversacionales: secuestro de objetivos, envenenamiento de memoria, abuso de herramientas, fallos en cascada entre agentes.
Y en Europa, además, es una obligación con fecha
Para una empresa europea esta capa no es sólo buena práctica de ingeniería: es la única forma realista de cumplir. El Reglamento de IA está en aplicación escalonada y el omnibus digital aprobado en julio de 2026 movió los plazos de los sistemas de alto riesgo: 2 de diciembre de 2027 para los sistemas autónomos del Anexo III —empleo, crédito, educación, infraestructuras críticas, entre otros— y 2 de agosto de 2028 para los integrados en productos regulados.
Ese aplazamiento no es una excusa para no hacer nada, por dos razones. La primera es que los requisitos de fondo no han cambiado: trazabilidad, registro de eventos, documentación técnica, supervisión humana efectiva, robustez y precisión. La segunda es que esas propiedades no se añaden al final; o están en la arquitectura o hay que rehacerla. Una empresa que en 2028 tenga que demostrar qué datos y qué lógica determinaron una decisión automatizada concreta, caso por caso, sólo podrá hacerlo si lleva tiempo registrándolo.
Dicho de otra forma: la observabilidad deja de ser una cuestión de operaciones y pasa a ser un elemento de diseño regulatorio.
Lo que le pasa a la gente (y el agujero del júnior)
Ninguna transformación de procesos sobrevive si el rediseño se queda en el diagrama y no llega a los roles. Aquí la evidencia de 2026 es abundante y, en algunos puntos, contraintuitiva.
Lo primero, el desplazamiento del trabajo. En los equipos con mayor aceleración estudiados por McKinsey, los responsables de producto reducen alrededor de un 24 % el tiempo dedicado a ejecución y los desarrolladores en torno a un 19 %, mientras crece el peso de la definición, el criterio y la revisión. El trabajo no desaparece: sube de altura. Se pasa de ejecutar a dirigir, definir estándares, validar y responder del resultado.
Lo segundo, el tamaño de los equipos. Entre esos mismos equipos, en torno al 79 % declara que sus squads se han reducido, con una mediana que pasa aproximadamente de diez a siete personas, y cerca de un 20 % de los directivos de esas organizaciones ya trabaja con equipos de una a cuatro. La explicación que dan no es «hemos despedido»: es que desaparecen la especialización fragmentada, los handoffs, las tareas auxiliares y buena parte de la coordinación interna. Conviene no convertir esto en ley universal —la muestra es de desarrollo de producto y software—, pero como señal temprana es importante.
Lo tercero, y para mí lo más útil de todo el material de este año: el comportamiento del jefe directo es una de las variables más determinantes. En los datos de Microsoft, que el responsable use IA de forma visible se asocia a un salto de diecisiete puntos en el valor percibido, y la seguridad psicológica del equipo a veintidós puntos más de pensamiento crítico y a una probabilidad claramente mayor de adoptar agentes. La inversión que más rinde no es la licencia: es que el manager cambie de comportamiento.
Cuatro efectos distintos sobre las capacidades, no uno
La conversación sobre reskilling suele tratar el asunto como un problema único. En realidad son cuatro fenómenos separados y con soluciones distintas:
- Amplificación. El estudio de Brynjolfsson, Li y Raymond sobre 5.179 agentes de atención al cliente encontró un aumento medio de productividad del 14 %, pero de hasta un 34 % entre los empleados con menos experiencia, y muy poco efecto entre los mejores. La IA difunde las prácticas de los buenos y acorta la curva de aprendizaje.
- Compresión. Como consecuencia, parte de la diferencia entre experto y novato se estrecha, con todo lo que eso implica para la estructura salarial y la carrera profesional.
- Atrofia. Lo que no se practica se pierde. Es notable que, en los datos de Microsoft, los profesionales más avanzados hagan justo lo contrario de lo que cabría esperar: alrededor del 43 % completa deliberadamente parte de su trabajo sin IA para conservar el oficio, frente al 30 % del resto. El trabajador sofisticado no delega todo; sabe qué no delegar.
- Formación. Este es el problema serio y sin solución conocida: si el trabajo júnior es exactamente el que absorben los agentes, ¿cómo se forma el sénior de dentro de diez años? Ninguna de las fuentes revisadas tiene una respuesta convincente. Quien diga lo contrario está vendiendo algo.
Mientras tanto, la inversión no acompaña. Deloitte encuentra que en torno al 71 % de las organizaciones trabaja la alfabetización básica en agentes y un 65 % hace reskilling específico, pero la mitad de los propios líderes considera que su empresa está invirtiendo insuficientemente en la transformación de la plantilla. Y no basta con un curso de prompting: hace falta aprendizaje en el puesto, entornos de prueba, tiempo protegido para experimentar, práctica con agentes reales y entrenamiento explícito en supervisión, validación y gestión de errores, que son competencias nuevas y no triviales.
Qué está funcionando, qué está emergiendo y qué sigue siendo humo
Toca separar el grano de la paja, que era una de las razones de escribir esto.
Antes de la lista conviene entender una cosa sobre la evidencia disponible, porque en las presentaciones se mezclan alegremente cifras de naturaleza muy distinta. Un ensayo controlado aleatorizado, una encuesta de percepción y un caso publicado por el proveedor que hizo el proyecto no valen lo mismo, por más que las tres cosas se pinten en la misma diapositiva con el mismo tamaño de letra.
| Tipo de evidencia | Ejemplo | Qué demuestra | Qué no demuestra |
| Ensayo controlado | METR con desarrolladores expertos; Brynjolfsson y otros en atención al cliente | Efecto causal en un contexto concreto | Que se replique en su empresa o en otro tipo de tarea |
| Experimento de campo | Harvard y BCG con 758 consultores | Que el efecto depende mucho de si la tarea cae dentro o fuera de la frontera de capacidad | Un porcentaje universal de mejora |
| Encuesta a directivos | McKinsey, Deloitte, Microsoft | Prevalencia, expectativas y correlaciones | Causalidad; y está sesgada por percepción |
| Caso de cliente | Cifras de despliegues publicadas por consultoras | Que es técnicamente posible llegar ahí | Que sea reproducible, ni el denominador de fracasos |
| Previsión | Cancelaciones de proyectos, cuotas de adopción futura | Una hipótesis informada | Absolutamente nada sobre el futuro real |
Con esa cautela por delante, este es el mapa honesto a mediados de 2026.
Demostrado: funciona hoy, en producción y con riesgo bajo
- Triaje y enrutamiento de peticiones, incidencias y correos entrantes. Alto volumen, error barato y reversible, mejora inmediata del tiempo de respuesta.
- Extracción de datos de documentos no estructurados —facturas, contratos, partes, formularios— con validación posterior.
- Conciliación y comprobación de coherencia entre sistemas que no se hablan.
- Resolución de peticiones de primer nivel en soporte interno y de cliente, con escalado claro.
- Generación de primeros borradores, documentación y pruebas, siempre con revisión humana explícita.
- Preparación de expedientes para una decisión humana: reunir, contrastar y presentar. Aquí el agente no decide y aun así ahorra la mayor parte del tiempo.
El reto en esta columna no es la IA. Es la calidad del dato de entrada y la integración con sistemas antiguos, que es exactamente el mismo problema que teníamos en 2015 con el RPA. La humanidad conserva sus tradiciones.
Emergente: hay casos reales, pero exige rediseño y gobierno
- Flujos financieros completos de extremo a extremo, del tipo procure-to-pay u order-to-cash, con validación, resolución de desviaciones y escalado.
- Procesos de admisión y alta sin tickets: contratación, onboarding de empleados, alta de proveedores o de clientes.
- Simulación masiva de escenarios comerciales y de riesgo. La literatura recoge casos donde un conjunto de agentes especializados coordinados por un orquestador y un validador permite evaluar diez o veinte veces más escenarios de precio y de mercado de los que un comité podía revisar en su ventana semanal de decisión.
- Ciclos de producto con trabajo asíncrono, con agentes trabajando fuera del horario humano y revisión al comenzar la jornada.
- Compresión radical de ciclos de informes. Hay casos documentados de elaboración inicial de informes de auditoría que pasan de unas veinticuatro horas a unas dos.
El requisito de entrada de esta columna es el que casi nadie cumple: derechos de decisión escritos, excepciones diseñadas y una plataforma común de operación de agentes. Sin las tres cosas, lo que se obtiene no es un proceso agéntico; es un piloto que no escala y que acaba en la lista de cancelaciones de Gartner.
Especulativo: interesante como hipótesis, peligroso como plan
- La empresa sin capa de gestión, coordinada íntegramente por protocolos y mercados de micro-agentes especializados. Hay modelos teóricos serios que exploran esa dirección; no hay ninguna organización relevante operando así.
- Organizaciones que se rediseñan solas en tiempo real, ajustando su propia estructura según la carga.
- Autonomía total sin responsable identificable. Además de imprudente, en Europa es sencillamente ilegal para cualquier proceso clasificado como de alto riesgo.
- La sustitución generalizada de la coordinación humana. Es la hipótesis más interesante de todo el debate y, a día de hoy, sigue siendo una hipótesis.
El problema no es que estas ideas se discutan; es sano que se discutan. El problema aparece cuando se presupuesta la tercera columna con la madurez de la primera, que es una forma cara de aprender lo que ya sabíamos.
Casi todas las empresas están entre el nivel 1 y el 3 de madurez. Casi todo el discurso empresarial habla del 7 al 9. Ahí está buena parte del ruido.
Los diez errores que matan una transformación de procesos con IA
Ninguno de los diez es tecnológico. Esa es, probablemente, la conclusión más consistente de todo el material revisado.
- Empezar por el catálogo de casos de uso. Una lista de cincuenta oportunidades ordenada por facilidad de implantación produce cincuenta mejoras locales que no suman nada. La unidad de trabajo es el flujo completo, no el caso de uso.
- Automatizar el proceso tal y como está. Útil para aprender, letal como destino. Si nadie ha cuestionado por qué existe cada actividad, lo que se automatiza son también las que no deberían existir.
- Medir despliegue en lugar de valor. Licencias, usuarios activos, número de prompts, número de agentes. Todas suben cuando se compra software y ninguna dice si el negocio va mejor.
- Poner un humano a aprobarlo todo. Convierte la supervisión en un clic reflejo, destruye el beneficio de velocidad y da una falsa sensación de control. La supervisión tiene que ser proporcional al riesgo.
- No definir qué es una excepción. Sin criterio explícito, la excepción se define implícitamente como «lo que alguien se encuentre roto», que es la peor forma posible de asignar trabajo.
- Dejar el control para el final. Cuando la producción se acelera y la verificación no, la diferencia se acumula. Aparece como retrabajo, y el retrabajo se lo come todo.
- Permitir repúblicas independientes. Cada área montando sus agentes con sus credenciales, sus accesos y sus registros. Funciona con diez agentes y es una arqueología tecnológica particularmente cara con mil.
- Trabajar con requisitos ambiguos. La ambigüedad, multiplicada por la velocidad de un agente, produce grandes volúmenes de resultados plausibles e incorrectos.
- Cambiar el flujo y no cambiar a nadie. Mantener los mismos roles, los mismos objetivos y los mismos incentivos cuando desaparecen tareas y handoffs garantiza que la organización reconstruya el proceso antiguo por debajo del nuevo.
- Declarar terminada la transformación. Si las capacidades cambian cada pocos meses, el modelo objetivo caduca antes de que la presentación termine de circular por los comités. Lo que hay que construir no es un destino, es una capacidad de rediseño continuo.
Cómo se organiza esto: fábrica de rediseño y plan de 90 días
Queda la pregunta práctica: quién hace todo esto y con qué ritmo.
La respuesta que va ganando en la evidencia disponible es que no funciona como gran programa central de transformación y sí funciona como capacidad permanente que recorre la organización flujo a flujo. BCG lo llama fábrica de transformación de procesos; la idea de fondo es industrializar el rediseño en vez de convertirlo en un proyecto de tres años que termina justo cuando la tecnología con la que empezó ya está obsoleta.
El ciclo de esa fábrica es siempre el mismo: seleccionar flujo → medir el proceso real → rediseñar en hoja en blanco → construir con verificación → medir coste por resultado → escalar o descartar → siguiente flujo. Con dos rasgos que lo diferencian de un programa clásico: el rediseño lo lidera el equipo que conoce el dominio, no una oficina central, y la oficina central aporta lo que no tiene sentido replicar —la plataforma, los estándares, los guardarraíles, la evaluación y la financiación—.
Cómo se elige el primer flujo
La selección del primer proceso determina en buena medida si habrá un segundo. Los criterios que funcionan:
| Criterio | Busque | Evite |
| Volumen | Muchos casos repetidos al mes | Procesos de veinte casos al año |
| Tiempo de espera | Mucho queue time entre pasos | Procesos ya rápidos de punta a punta |
| Reversibilidad | Errores detectables y corregibles | Decisiones irreversibles con impacto externo |
| Datos | Información ya digital y accesible | Procesos que dependen de papel o de correo |
| Propiedad | Un responsable único de punta a punta | Flujos repartidos entre cuatro barones |
| Medición | Resultado contable y con línea base | «Mejorar la experiencia», sin definir |
Y una advertencia de gestión política: elija un proceso que le importe a alguien con poder, pero no el más crítico de la compañía. El primero tiene que poder fallar sin que nadie pierda su puesto, porque va a fallar en algo.
Los cinco roles que hacen falta
- Propietario del resultado. Responde del outcome completo, no de un tramo. Sin esta figura no hay rediseño posible, sólo negociación entre áreas.
- Arquitecto de flujo. Diseña la secuencia, decide qué se elimina, qué se paraleliza y qué ejecuta cada actor.
- Ingeniero de agentes. Construye, instrumenta y mantiene. Y retira lo que deja de aportar.
- Responsable de control. Define verificaciones, umbrales de confianza, niveles de decisión y evidencias de auditoría.
- Gestor de excepciones. El rol más nuevo y el más subestimado: resuelve lo que el sistema escala y, sobre todo, convierte cada excepción en una mejora del diseño.
El plan de 90 días, sobre un único flujo, con nombre y con responsable:
- Semanas 1-3, medir. Sacar el proceso real de los logs, separar touch time de queue time, contar variantes y excepciones, y calcular el coste por resultado de hoy. Esa cifra es el contrato con el comité.
- Semanas 4-6, rediseñar. Eliminar, simplificar, paralelizar y sólo entonces decidir dónde hace falta un agente. Escribir los derechos de decisión y el criterio de excepción. Nada de tecnología todavía.
- Semanas 7-10, construir. Un flujo entero de punta a punta, no una demo bonita de un paso. Con verificación integrada, excepciones enrutadas a un responsable con nombre y trazas desde el primer día.
- Semanas 11-13, decidir. Comparar coste por resultado, lead time, tasa de excepción y toques humanos contra la línea base. Escalar sólo lo que haya movido esas cuatro cifras. Y fijar la siguiente revisión a noventa días.
La prueba del algodón: si en la semana 6 no ha eliminado ninguna actividad, no ha rediseñado nada. Ha hecho un proyecto de tecnología con vocabulario de transformación.
El cuadro de mando que sí importa
Entre los equipos con mayor aceleración estudiados por McKinsey, alrededor del 86 % utiliza métricas de resultado —calidad, time-to-market, coste, fiabilidad, impacto en cliente— en lugar de métricas de adopción. La correlación no demuestra causalidad, pero el mecanismo es evidente: lo que se mide es lo que se rediseña.
| Dimensión | Indicador | Qué le está diciendo |
| Flujo | Lead time de extremo a extremo | Si el cliente nota algo o no |
| Flujo | Toques humanos por resultado | Si ha rediseñado o sólo ha acelerado tareas |
| Autonomía | Tasa de straight-through | Cuánto proceso funciona sin intervención |
| Autonomía | Tasa de excepción y minutos por excepción | Dónde está realmente su coste |
| Calidad | First-pass yield y retrabajo | Si está generando deuda mientras acelera |
| Riesgo | Reversiones, anulaciones e incidentes | Si el nivel de autonomía concedido era el correcto |
| Economía | Coste totalmente cargado por resultado | Si el proyecto se sostiene solo |
| Decisión | Decisiones por periodo y latencia media | Si está capturando el dividendo de decisión |
Dos advertencias sobre este cuadro. La primera: hay que calcular la línea base antes de tocar nada, porque después será imposible y todo se convertirá en una discusión de percepciones. La segunda: si sólo puede seguir dos indicadores, siga coste totalmente cargado por resultado y toques humanos por resultado. Con esos dos se detecta el 90 % de los autoengaños.
Conclusión: lo que hay que rediseñar no es la tecnología
Volvamos al principio. Dieciséis desarrolladores expertos convencidos de ir un 20 % más rápidos cuando iban un 19 % más lentos, y un banco que multiplica por cuatro su mejora simplemente cambiando el proceso alrededor de la misma herramienta. Entre esos dos puntos no hay una diferencia de modelo, de proveedor ni de presupuesto de tecnología. Hay una diferencia de diseño.
Casi todo lo que hemos visto se sostiene sobre una idea que no es nueva —Hammer la escribió hace más de treinta años— pero que ahora opera sobre restricciones distintas: no se automatiza un proceso, se rediseña el trabajo alrededor del resultado. Lo genuinamente nuevo no es que podamos automatizar más tareas. Es que, por primera vez, podemos automatizar parte de la coordinación y de la decisión que sostenían la estructura de la empresa. Y esa es una conversación de diseño organizativo, no de compras.
Si tiene que quedarse con cuatro frases de todo el artículo, que sean estas:
- El orden importa más que las herramientas. Eliminar, simplificar, automatizar y sólo entonces agentificar. Casi todo el mundo empieza por el cuarto escalón y luego se pregunta por qué el EBIT no se mueve.
- El dinero está en el tiempo de espera, no en el de trabajo. Acelerar una tarea es una mejora local; eliminar colas y paralelizar cambia el lead time, y el lead time sí lo nota el cliente.
- La excepción define la economía. En un proceso muy automatizado, un puñado de casos difíciles concentra la mayor parte del coste. Optimizar la excepción vale más que optimizar el modelo.
- La autonomía sin verificabilidad es deuda. Cuanto más decide un agente, más importa haber diseñado cómo se comprueba lo que hace y quién responde de ello.
Y si va a hacer una sola cosa después de leer esto, haga esta: coja el proceso que más quejas le genera, siéntese con quien lo ejecuta y calcule dos números —cuánto tiempo del total es trabajo real y cuánto es espera, y cuántas personas distintas tocan cada caso—. No hace falta ninguna tecnología para averiguarlo, se tarda una semana y esas dos cifras le dirán, con más precisión que cualquier proveedor, si su problema es de inteligencia artificial o de diseño.
Nota sobre datos y fuentes
Qué es verificable en fuentes públicas. Los datos del ensayo de METR (dieciséis desarrolladores, 246 tareas, previsión del 24 %, percepción del 20 %, medición de un 19 % más lento) están en su informe y en el preprint asociado. Las cifras del estudio de Brynjolfsson, Li y Raymond (5.179 agentes, +14 % de media, +34 % en los menos experimentados) están en el documento de trabajo del NBER. El experimento de Harvard y BCG con 758 consultores y el concepto de jagged frontier están en el documento de trabajo 24-013 de la Harvard Business School. La previsión de Gartner sobre cancelaciones y el término agent washing están en su nota de prensa de junio de 2025. Los porcentajes de adopción, impacto en EBIT y high performers proceden de la encuesta global State of AI de McKinsey de 2026; los de preparación de procesos y horizonte a dos y cuatro años, del informe de Deloitte de agosto de 2026; los de agentes activos, factores organizativos y comportamiento de los profesionales avanzados, del Work Trend Index 2026 de Microsoft. Las fechas del Reglamento europeo son las resultantes del omnibus digital aprobado en julio de 2026.
Qué está redondeado o depende de la definición. Los porcentajes de adopción y de impacto varían según cómo se formule la pregunta: «declarar algún impacto en EBIT» y «atribuir a la IA al menos un 5 % del EBIT» no son lo mismo, y la diferencia entre ambos es justamente el argumento del artículo. Las cifras de reducción de tiempo de ciclo y de coste procedentes de despliegues de consultoras son resultados comunicados sobre clientes propios, no experimentos controlados: demuestran que es posible llegar ahí, no que sea reproducible ni cuántos intentos fracasaron por el camino. Los datos de reducción de tamaño de equipo y de desplazamiento del tiempo de ejecución proceden de una encuesta de desarrollo de producto y software; extrapolarlos al resto de la empresa es razonable como hipótesis y arriesgado como plan.
Qué conviene contrastar en la fuente antes de citarlo. Las cifras de 11,8 % de ahorro de tiempo frente a 6,2 % de reducción de retrabajo, y el reparto de 70-75 % de supervisión humana frente a 20-25 % de inferencia, proceden del trabajo de McKinsey sobre ciclo de desarrollo de producto y sobre flujos bancarios. Son cifras de encuesta y de análisis de casos concretos, no constantes universales: úselas por el orden de magnitud y por la dirección del hallazgo, que es lo relevante, y no por el decimal. El ejemplo numérico de la economía de las excepciones (0,50 € y 30 €) es una ilustración construida para el artículo, no un dato de campo; lo que importa de él es la estructura del cálculo, que sí es general. Y los plazos del Reglamento europeo han cambiado ya una vez, así que conviene comprobar el texto vigente antes de fijar una fecha en un plan.
Qué es interpretación propia. La secuencia eliminar-simplificar-automatizar-agentificar, la escala de seis niveles de derechos de decisión, la lista de diez errores, los criterios de selección del primer flujo, los cinco roles, el plan de 90 días y el cuadro de mando final son elaboración de Transformalix a partir del material citado. También lo es la lectura de que el cuello de botella se desplaza hacia la decisión humana cuando se paraleliza el proceso, y la afirmación de que ninguna de las fuentes tiene una respuesta convincente al problema de cómo se formará el profesional sénior de dentro de diez años.
Bibliografía y documentos oficiales
Todos los enlaces apuntan a la fuente original. Algunos exigen registro gratuito para descargar el informe completo.
Encuestas e informes de consultoría
- Deloitte (2026). AI agents are only the beginning: The path to agentic transformation. Encuesta a 501 responsables estadounidenses, abril-junio de 2026. deloitte.com
- McKinsey & Company (2026). The State of AI: Global Survey 2026. Adopción, impacto en EBIT y perfil de los high performers. mckinsey.com
- McKinsey & Company (2026). Beyond the copilot: Scaling the agentic product development life cycle. Encuesta a 334 profesionales de producto e ingeniería. mckinsey.com
- McKinsey & Company. Seizing the agentic AI advantage. El argumento del rediseño de flujos frente al despliegue de herramientas. mckinsey.com
- McKinsey & Company. Where AI will create value—and where it won’t. Fuente del argumento del dividendo de decisión. mckinsey.com
- McKinsey & Company (2026). State of AI trust in 2026: Shifting to the agentic era. Barreras de seguridad y riesgo para escalar agentes. mckinsey.com
- Microsoft (2026). 2026 Work Trend Index: Agents, human agency, and the opportunity for every organization. 20.000 trabajadores en diez países más telemetría de Microsoft 365. microsoft.com
- BCG (2026). Scaling AI Requires New Processes, Not Just New Tools. bcg.com
- BCG (2026). Agentic AI Turns Every Team into Its Own Transformation Engine. Rediseño liderado por los equipos frente a programa central. bcg.com
- BCG (2026). AI-First Enterprise Operations: Reinventing the Operating System of Work. bcg.com
- Gartner (2025). Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027. Origen del término agent washing. gartner.com
Evidencia experimental y académica
- METR (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. El ensayo aleatorizado del 19 % más lento. metr.org · arXiv:2507.09089
- METR (2026). We are Changing our Developer Productivity Experiment Design. Revisión posterior del propio diseño experimental, útil para no absolutizar el resultado anterior. metr.org
- Brynjolfsson, E., Li, D. y Raymond, L. Generative AI at Work. NBER Working Paper 31161. Los 5.179 agentes de atención al cliente. nber.org
- Dell’Acqua, F. y otros. Navigating the Jagged Technological Frontier. Harvard Business School Working Paper 24-013. El experimento con 758 consultores. hbs.edu (PDF)
Seguridad, identidad y regulación
- OWASP GenAI Security Project. OWASP Top 10 for Agentic Applications 2026. Riesgos específicos de sistemas agénticos. genai.owasp.org
- NIST. AI Agent Standards Initiative. Línea de trabajo de estandarización de agentes. nist.gov
- NIST NCCoE. Software and AI Agent Identity and Authorization. Identidad y autorización de agentes con OAuth 2.0, SPIFFE y MCP. nccoe.nist.gov
- Unión Europea. Reglamento (UE) 2024/1689 por el que se establecen normas armonizadas en materia de inteligencia artificial. Texto consolidado. eur-lex.europa.eu
- Consejo de la Unión Europea (2026). Artificial intelligence: Council and Parliament agree to simplify and streamline rules. Acuerdo que aplaza las obligaciones de alto riesgo a diciembre de 2027 y agosto de 2028. consilium.europa.eu
En Transformalix acompañamos a empresas que quieren rediseñar procesos de verdad, no ponerles una capa de agentes encima: medimos el proceso real, separamos el trabajo de la espera, escribimos los derechos de decisión y construimos el flujo completo con verificación dentro. Si en tu compañía ya hay pilotos de IA y la cuenta de resultados sigue sin enterarse, hablemos.
