Por qué «aplicar IA» a tus procesos rotos solo hace que la basura vaya más rápido

Hay un mantra que se repite en cada conferencia de tecnología y en cada consejo de administración: «tenemos que aplicar IA». Empresas de todos los tamaños compran miles de licencias de asistentes de código, comprometen decenas de millones de euros en consumo de tokens y organizan sesiones de formación interna por videollamada. Y, sin embargo, la productividad apenas se mueve. ¿Por qué? Porque la gran mayoría de las organizaciones está haciendo exactamente lo mismo que hizo con la informática hace tres décadas: aplicar la tecnología sobre procesos que ya estaban rotos, y el resultado es simplemente hacer basura más rápido.

Lo cuenta con datos un hilo que circula estos días en X firmado por Vas (@vasuman), CEO de la firma estadounidense de adopción de IA Varick Agents. Tras hablar con más de 300 CEOs, CIOs y CFOs de las mayores empresas del planeta, su conclusión es demoledora: el mundo ha gastado una fortuna en IA y, para la mayoría de las empresas, casi nada ha cambiado. Puede que el problema no sea la tecnología, sino que nadie en la cadena es dueño del proceso. En este artículo lo desgranamos: por qué falla la adopción, qué dice la historia, y cómo evitarlo con una metodología que en BAOSS practicamos cada día.

La lección de 1990 que nadie quiso aprender

En 1990, Michael Hammer —profesor de informática del MIT— publicó en la Harvard Business Review un artículo que es casi una profecía. Tras pasar años dentro de empresas que habían gastado cantidades ingentes en ordenadores con escaso retorno, escribió:

«Las fuertes inversiones en tecnología de la información han dado resultados decepcionantes, en gran parte porque las empresas tienden a usar la tecnología para mecanizar viejas formas de hacer las cosas. Dejan los procesos existentes intactos y usan los ordenadores simplemente para acelerarlos».

Si sustituyes «tecnología de la información» por «IA», podrías publicar esa cita mañana en la portada de cualquier periódico económico. Hammer acuñó además una expresión gráfica: «deja de pavimentar los caminos de vacas» —es decir, deja de automatizar y consolidar un proceso ineficiente en lugar de rediseñarlo para que funcione como debería. Han pasado 36 años y seguimos pavimentando caminos de vacas.

La cifra que lo explica todo: 1 billón frente a 37.000 millones

La escala del desajuste es abismal. En 2025 se han gastado más de un billón de dólares en capex construyendo infraestructura de IA —solo Microsoft, Alphabet, Amazon y Meta superaron los 410.000 millones—, pero las empresas han gastado únicamente 37.000 millones en usarla de verdad. La punta del iceberg es el ensayo del Departamento de Comercio y Negocio del Reino Unido con Microsoft 365 Copilot.

El resultado, publicado con toda honestidad, fue decepcionante: desplegaron 1.000 licencias durante 3 meses y la media fue de tan solo 1,14 acciones de Copilot por usuario y día. Las presentaciones de PowerPoint tardaban 7 minutos menos (de 18 a 11), pero con la mitad de calidad; el análisis en Excel se completaba más lento; y el ahorro de tiempo en el correo era, textualmente, «extremadamente pequeño». Su conclusión literal: «No encontramos pruebas sólidas de que el ahorro de tiempo se esté traduciendo en una mejora de la productividad». Aun así, el 72% de los usuarios se declararon satisfechos o muy satisfechos.

Ethan Mollick, profesor de Wharton y reconocido investigador de IA, lo resume en una frase: «El uso de IA que mejora el rendimiento individual no se traduce, de forma natural, en mejorar el rendimiento de la organización». La gente disfruta la herramienta, pero produce exactamente lo mismo que antes.

El número que lo cambia todo: 22 días de proceso, 17 minutos de trabajo

La mejor cifra de Hammer proviene de una aseguradora que estudió. Una solicitud de seguro tardaba 22 días en recorrer la empresa. De esos 22 días, el tiempo total que alguien trabajaba sobre ella era de 17 minutos. Calcula qué pasa si hoy tu «experto en IA» despliega el mejor modelo del mundo sobre ese proceso y logra que cada paso individual sea el doble de rápido: ha ahorrado ocho minutos y medio. Lo venderá como un «ahorro del 50%», conseguirá su bonus y se irá. Pero son ocho minutos.

Los ahorros no estaban en trabajar sobre la solicitud, sino en las colas y los traspasos: la espera por otros equipos, el tiempo muerto antes de la segunda revisión, los intervalos entre departamentos. Acelerar los 17 minutos es peor que no hacer nada: has gastado el presupuesto y le has demostrado al consejo que «la IA no funciona».

Puede que creas que esto es un vestigio de los años 90. No lo es. Vas cuenta que trabajó con una empresa cuyo propio registro de sistemas demostraba el mismo fenómeno: abrir un nuevo caso de cliente requería 25 minutos de trabajo real, pero el tiempo transcurrido desde que el caso entraba hasta que se activaba iba de 2 días a 2 semanas. El trabajo puede ser minutos mientras el proceso sigue siendo semanas.

La tentación fatal: «unifiquemos los sistemas primero»

Cuando los datos son un desastre y los sistemas no se hablan, el instinto es arreglar eso antes de tocar nada más: «necesitamos un solo ERP, un solo CRM, una sola plataforma de datos, y luego IA encima». Suena bien en teoría, pero cualquier especialista de TI sabe que nunca es tan simple. Los ejemplos de fracasos sonoros con migraciones de sistemas son legión.

TSB gastó 318 millones de libras en una migración de banca core, se comió unos 200 millones más en costes de incidentes, fue multada por la FCA y la PRA con 48,65 millones en diciembre de 2022, y dejó sin servicio bancario a 5,2 millones de clientes. Zimmer Biomet, un fabricante de 8.000 millones de dólares, presentó en septiembre de 2025 una reclamación de 172 millones contra Deloitte tras una «migración y consolidación» fallida que les impidió realizar funciones básicas: enviar su producto, facturar a sus clientes o generar informes de ventas. Y esos son solo los casos que salieron en las noticias.

La clave es entender que no necesitas un solo sistema, necesitas un solo proceso. Las integraciones deterministas se rompían en el instante en que dos sistemas discrepaban sobre cómo era un registro de proveedor. Los agentes de IA, en cambio, toleran esa inconsistencia. Una capa de orquestación que se asiente sobre los sistemas que ya tienes es la solución a los sistemas dispares: tus sistemas no solo necesitan hablarse, necesitan estar «felizmente casados», tolerando sus defectos mutuos.

El método: mapear, ordenar en tres cubos, y medir líneas base

Para rediseñar tu negocio primero tienes que entenderlo. Y esa comprensión no se logra eligiendo un único flujo de trabajo y pasando ocho semanas perfeccionándolo —seguramente lo bloquee un proceso hermano aguas arriba y acabes con ROI neto cero. Pero tampoco puedes ingerir todo el negocio de golpe. La respuesta es empezar a nivel de departamento.

Elige un departamento (finanzas, compras, operaciones) e identifica los «paquetes» de flujos que alimentan ese departamento —por ejemplo, en Finanzas: cuentas a pagar, cuentas a cobrar, FP&A, facturación, banca, conciliaciones. Para cada flujo, mapea siete detalles:

• El camino feliz: de qué se encarga este flujo y qué ocurre en el escenario ideal.
• Las excepciones: qué porcentaje del volumen sale del camino feliz, a dónde va, a quién implica, cuál es el tiempo de ciclo para resolverla y cuánto cuesta un error aquí.
• Qué hay aguas arriba y aguas abajo: cómo interactúa el flujo con los demás cuando las cosas se retrasan o fallan.
• Los sistemas de registro: cuáles están implicados y cuál gana cuando dos de ellos se contradicen.
• Cómo varía por región, entidad, filial o adquisición de la que provenga.
• Tiempo de contacto frente a tiempo transcurrido, y cómo varia esa brecha en cada paso.
• Capacidad de IA de cada persona de la función y qué grado de propiedad debería tener sobre el sistema futuro.

Para extraer esa información se necesitan dos procedimientos complementarios: por un lado, process mining contra los sistemas de registro para obtener acciones, marcas de tiempo, rendimiento, ediciones y la realidad que no coincide con la documentación; por otro, entrevistas con los operadores, porque la realidad de tu organización vive en las cabezas de 10-20 personas que llevan años haciendo ese trabajo exacto para tu empresa exacta. Y tu IA, para que funcione, tiene que ser adoptada por esas personas. Hacer solo una de las dos cosas deja una imagen incompleta.

Agentes que funcionan: no son solo llamadas a un LLM

El rediseño de procesos es un ejercicio de clasificación. Cada paso del proceso cae en uno de tres cubos:

• Determinista. Si X entonces Y, sin juicio. Si la factura está bajo un umbral de importe y coincide con la orden de compra y el albarán, se paga. Estas acciones son mejor como software puro: barato, auditable, determinista (nunca alucina) y rápido. No necesitas una llamada sofisticada a un modelo para hacer lo que puede hacer código normal.
• Agéntico. Si tienes miles de ejemplos pasados de humanos tomando una decisión de criterio con el resultado registrado, y el riesgo es bajo (aprobaciones de deal desk, codificación contable GL), usa sin duda un LLM para el juicio. Sobre todo si el output es un sí/no, un «deriva a este equipo», un marcar/no marcar o un emparejar/no emparejar. Aquí juzgas la dificultad de la acción, no del pensamiento.
• Humano en el bucle. Para pasos demasiado arriesgados o sin suficiente contexto histórico, mantén a la persona en el bucle: el coste de que un agente se equivoque en la acción es demasiado alto. Pero pon toda la evidencia relevante delante del humano en el momento de decidir. Por ejemplo, el agente detecta una discrepancia entre factura y orden de compra y le presenta a la persona 3 opciones: aprobar, rechazar o dar feedback y derivar. El agente le ha ahorrado 40 minutos de búsqueda por correos y registros, para que decida en 30 segundos.

Una vez clasificado cada paso, puedes convertir un proceso de 25 pasos en un clúster de 3 agentes, con pasos deterministas antes y después y 2 puntos de humano-en-el-bucle para desbloquear. Ese trabajo de reingeniería, junto con los propios agentes, es donde vive todo el ROI.

Después, fija las líneas base de los KPIs antes de construir nada. Tu objetivo es calcular los números detrás del proceso que resuelves, dónde y cómo se miden hoy. Si no puedes hacerlo, el proyecto está destinado a fracasar: dentro de 12 meses necesitas poder decir «estábamos en X y ahora estamos en 3X, o 10X», gracias a los agentes. Solo entonces puedes decir que fue un éxito.

El caso real: una conciliación bancaria de 12 pasos convertida en 3

Otra vez, en la práctica, cómo se ve. Vas y su equipo reingenierizaron una empresa global que conciliaba más de 300 cuentas bancarias cada mes. Dos tercios las gestionaba un equipo offshore y el resto se repartía entre otras dos regiones en tres formatos distintos, pero todo en Excel. Había más de 12.000 elementos abiertos de conciliación y 4 días al inicio de cada mes solo se dedicaban a obtener extractos. Su proceso de conciliación ocupaba casi todo el mes, cada mes.

El flujo previo era un cúmulo de esperas: rastrear y recoger extractos de cada banco en su formato; normalizarlos en el libro regional; extraer el extracto contable; emparejar línea a línea; marcar lo que no coincide; escribir a un controlador local para pedir contexto; esperar su respuesta; perseguirla si no contestaba; publicar el ajuste; consolidar la región; y repetir todo el proceso para las otras dos regiones, cada una en su formato. Si aceleras cada paso, el emparejamiento se acelera. El problema es que el emparejamiento nunca fue el problema: los 4 días de espera por los extractos, el correo a un controlador en otra zona horaria y la respuesta que tardaba 3 días eran el problema.

El nuevo proceso era de tres pasos:

1. Los extractos llegan por un feed, estilo cinta transportadora, en lugar de perseguirlos. Esto no tiene nada que ver con IA.
2. Todo lo que puede emparejarse por reglas se empareja automáticamente; si no, un agente ensambla el caso de principio a fin: con el propio elemento, las categorizaciones históricas, la evidencia recopilada de varios sistemas de registro y una propuesta de siguiente paso.
3. Por último, un humano trabaja su cola de excepciones con la evidencia preparada para su revisión, en lugar de rebuscar manualmente entre datos dispersos en ERPs y hojas de cálculo.

La búsqueda, el envío de correos, la espera, el re-tecleo y las consolidaciones regionales desaparecieron por completo. Esa es la diferencia entre un sistema de agentes que ahorra minutos y horas, y un sistema de agentes que ahorra semanas.

Los resultados cuando se hace bien

Cuando el trabajo se aborda así, el impacto toca las cuatro palancas que importan en una transformación con IA: coste (idealmente menor), ingresos (idealmente mayores), tiempo (idealmente más rápido) y riesgo (idealmente más bajo). En los despliegues de Varick, alrededor de la mitad en empresas públicas, esto fue lo que se movió palanca a palanca:

• Tiempo. El cierre de mes pasó de 18-22 días a 7-9 días. Las interrupciones de la cadena de suministro se clasifican ahora en menos de 6 horas, frente a varios días.
• Ingresos. Los acuerdos pasaban de media 23 días parados; ahora son 6 días. El tiempo administrativo de los comerciales bajó del 38% de la semana al 14%, y ese tiempo volvió a venderse.
• Coste. El manejo de excepciones de cuentas a pagar pasó de 600-800 facturas al mes a menos de 50. En una organización de marketing se recuperó del 8% al 12% del presupuesto de medios por errores de ritmo que antes solo afloraban a fin de mes, ahorrando millones por trimestre.
• Riesgo. Las correcciones de nómina cayeron un 90%, porque la conciliación entre sistemas se ejecutaba antes de la nómina y no después. El 80% de las consultas de soporte de empleados se respondían con los propios documentos de políticas de la empresa, mientras los casos límite seguían escalando a un humano de RR. HH.

En total, el valor entregado en ese conjunto de despliegues superó los 100 millones de dólares, y fue co-creado y medido junto con los clientes.

Por qué no es más común: interferencias, riesgo y el miedo de los operadores

Si el método funciona, ¿por qué tan poca gente lo aplica? Por tres razones que son menos tecnológicas y más humanas.

Primero, nadie en la cadena es dueño del proceso. Quien firma hoy un contrato de IA puede controlar las herramientas y la selección de proveedores, pero desde luego no controla el proceso. Nadie con esa función puede entrar en finanzas y decir que su proceso de 14 pasos debería tener 5. Así que nadie lo hace: «aplicas IA» sobre lo que ya tienes y acabas con mierda más rápida. Rediseñar un proceso que abarca cuatro departamentos exige alguien capaz de decirles a los cuatro que el proceso cambia. Hay muy pocas personas en una empresa que puedan hacerlo; tiene que venir de arriba.

Segundo, la IA se percibe como arriesgada. El statu quo es «seguro» para la mayoría: nadie recibe un ascenso porque la IA funcione, pero sí pueden despedirte si no funciona, aunque aferrarte al statu quo signifique dejar morir a la empresa lentamente.

Tercero, quienes hacen el trabajo hoy tienen que querer el nuevo sistema. El responsable de cuentas a pagar y los analistas de finanzas tienen que adoptarlo y empujarlo mañana. Y tienen que divulgar información que creen que puede reemplazarlos, aunque en la mayoría de los casos no sea así. Cuando en los años 90 Hammer intentó eliminar un traspaso, eso significaba despedir a la persona cuyo trabajo era ese traspaso y pedir a todos los demás que cambiaran su forma de trabajar, mientras el «software» de entonces no soportaba ese cambio. Por eso, cuando los consultores se iban, la estructura y el proceso volvían a su estado original: repleto de ineficiencias y errores.

Hoy dos cosas son fundamentalmente distintas. Primero, las herramientas nativas de IA ofrecen un estado de software increíblemente fluido que se adapta a los cambios. Un agente instalado en tu sistema de registro puede ejecutar traspasos que antes dependían de personas, gestionar a la vez las discrepancias del software determinista, y es inmune a la varianza habitual en los humanos. Segundo, el trabajo que se elimina primero es casi en su totalidad coordinación: perseguir, esperar, escalar, clasificar. Después de esas mejoras y de una transformación real con IA, lo que queda es trabajo de alto juicio y alto apalancamiento, que es a lo que tu mejor gente debería dedicar todo su tiempo de todas formas.

La trampa del proveedor único

Las consultoras tradicionales son decentes en el trabajo de procesos, hay que reconocerlo: si quieres una ilustración elaborada de un proceso de 15 pasos que abarca 10 países y 3 entidades, te producirán el PowerPoint más bonito que hayas visto por 300.000 dólares. Lo que no saben hacer es la otra mitad, la más importante: saber en qué se puede confiar a un modelo, cuánto cuesta un agente que se ejecuta 40.000 veces al mes, qué modelo usar para qué tipo de tarea, cómo diseñar un conjunto de evaluación óptimo, y en cuál de los tres cubos cae cada paso. Así que tu rediseño lo crean consultores que están adivinando.

Los laboratorios de IA, por el contrario, tienen el problema contrario: pueden construir un agente, pero nunca se han sentado con finanzas y operaciones a desmontar un flujo donde ambos departamentos discuten sobre quién es dueño y quién está aguas arriba de quién. Así que pegan IA sobre un proceso roto y lo llaman «automatizado», en lugar de destriparlo y rediseñarlo. Y los mayores laboratorios de «IA aplicada» te forzarán a casarte con sus modelos para siempre. Apostar toda la incrustación de inteligencia de tu empresa a un único proveedor es suicidio: mañana, cuando limiten la tasa, cuantifiquen, suban precios o retiren el modelo en el que corres, te quedas con el lío y con la factura. Cambiar el endpoint de Claude a Gemini o DeepSeek no es tan simple como parece: volver a ejecutar las evaluaciones y redeterminar qué nivel de razonamiento usar por llamada es un proceso laborioso, y los laboratorios no te van a ayudar.

Lo que necesitas es lo mejor de ambos mundos combinado: personas que hayan dirigido de verdad una función de finanzas, operaciones, ventas o RR. HH.; ingeniería capaz de llevar software de producción a los ERPs y CRMs; e ingenieros de IA capaces de construir armazones empresa-neutrales con gobernanza y conjuntos de evaluación integrados. Lo que sigues necesitando es que el equipo tenga dentro del proyecto al responsable de procesos, a los ingenieros de software y a los ingenieros de IA en la misma sala —y casi nadie tiene las tres cosas.

Conclusión

La lección de este hilo es tan antigua como vigente: la tecnología nunca sustituyó a un mal proceso; lo aceleró. El tiempo perdido no estaba en el trabajo en sí, sino en las colas y los traspasos. Antes de comprar miles de licencias de asistentes de IA, pregúntate qué proceso vas a rediseñar y quién tiene autoridad para cambiarlo. Empieza por un departamento, haz process mining y entrevista a los operadores, clasifica cada paso en determinista, agéntico o humano-en-el-bucle, mide las líneas base y solo entonces construye.

En BAOSS llevamos años aplicando esta misma disciplina: ayudar a empresas a rediseñar procesos antes de automatizarlos, con agentes de IA sólidos, gobernanza y medición de ROI desde el primer día. No vendemos «aplicar IA»; vendemos transformación que se mide. Si estás en ese punto, hablemos de cómo empezar.

Pide tu diagnóstico de proceso y descubre cuánto valor hay realmente en automatizar tu empresa →

Artículo inspirado en el hilo de Vas (@vasuman, CEO de Varick Agents), «AI Adoption Without Process Change» (septiembre de 2026). Las cifras citadas provienen de fuentes públicas (Harvard Business Review 1990, ensayo del Gobierno del Reino Unido sobre Copilot, casos TSB y Zimmer Biomet, métricas publicadas del despliegue de Varick).