«Ya le metí IA a mi empresa, y no funcionó…»

Introducción

Es una frase que se oye cada vez más. Se contrataron licencias, se conectó un asistente, alguien preparó una demostración que funcionaba muy bien, y a los seis meses la empresa trabaja exactamente igual que antes. La conclusión parece evidente: la inteligencia artificial no funciona, o al menos no funciona aquí.

A menudo la frase describe bien lo que pasó. Lo que casi nunca acierta es la causa. Cuando se examina con calma un proyecto que no dio resultado, lo habitual no es encontrar un modelo incapaz, sino una tecnología razonable colocada en el sitio equivocado o encima de un proceso que nadie se paró a mirar.

Este artículo explica por qué no funcionó y qué se hace distinto en los proyectos que sí funcionan.

Esto ya pasó hace treinta y cinco años

En 1990, Michael Hammer, antiguo profesor de informática del MIT, publicó en la Harvard Business Review un artículo que empezaba con una constatación incómoda: las grandes inversiones en tecnologías de la información habían dado resultados decepcionantes, en buena parte porque las empresas usaban la tecnología para mecanizar su forma antigua de trabajar, dejando los procesos intactos y usando los ordenadores simplemente para acelerarlos (Hammer, 1990). Cambiando «tecnologías de la información» por «inteligencia artificial», el diagnóstico podría publicarse hoy.

Hammer lo ilustraba con el sector asegurador. En Mutual Benefit Life, una solicitud de póliza podía atravesar hasta treinta pasos, cinco departamentos y diecinueve personas, y tardaba normalmente entre cinco y veinticinco días, la mayor parte en pasar información de un departamento a otro. Y recogía la estimación de otra aseguradora: una solicitud pasaba veintidós días en proceso, pero solo se trabajaba en ella diecisiete minutos.

El experimento se ha repetido con IA generativa. El Departamento de Negocios y Comercio del Gobierno británico repartió mil licencias de Microsoft 365 Copilot durante tres meses a finales de 2024 y publicó una evaluación detallada (Department for Business and Trade, 2025). El 72 % de los participantes se declaró satisfecho o muy satisfecho. Sin embargo, la evaluación no encontró pruebas sólidas de que el tiempo ahorrado se tradujera en más productividad, aunque advierte con honestidad que medirlo no era su objetivo principal.

Lo más instructivo está en las tareas observadas, con muestras pequeñas que el propio informe señala como limitación. Con Copilot se resumieron informes en menos de un tercio del tiempo y con mejor calidad. En cambio, el análisis de datos en Excel salió más lento y peor, y las presentaciones, más rápidas pero con peor calidad. La misma herramienta ayudaba mucho en unas tareas y empeoraba otras.

La gente estaba contenta, algunas tareas iban más rápido y la organización seguía produciendo lo mismo. Eso es lo que se esconde, casi siempre, detrás de «no funcionó».

Por qué no funcionó

Hay cuatro causas que explican la gran mayoría de los casos.

Se usó IA donde bastaba una regla

Buena parte de lo que se automatiza en una empresa no necesita inteligencia artificial. Si una factura cuadra con su pedido y está por debajo de un importe, se aprueba. Si un cobro lleva treinta días vencido, se envía un recordatorio. Son decisiones que se escriben con un «si pasa esto, haz aquello», sin nada que interpretar.

Para ese tipo de paso, un programa convencional es mejor en todo: apenas cuesta por ejecución, responde siempre igual ante la misma entrada, se puede auditar y no se inventa nada. Poner un modelo de lenguaje a tomar esa decisión añade coste, lentitud y una variabilidad que no aporta nada. Y cuando el modelo falla en algo que una regla nunca habría fallado, se concluye que la IA no es fiable, cuando el error fue usarla donde no tocaba.

El error contrario también existe. Hay pasos donde las reglas fracasan: leer facturas de doscientos proveedores con doscientos formatos distintos, clasificar correos escritos en lenguaje libre, entender qué pide un cliente en un mensaje ambiguo. Resolverlo con plantillas produce integraciones que se rompen cada vez que un proveedor cambia el diseño de su factura. Ahí la IA sí aporta algo que antes no había. La pregunta útil nunca fue si usarla, sino en qué pasos.

Se aceleró la tarea, pero el tiempo estaba en las esperas

Conviene volver a los veintidós días y los diecisiete minutos. Si el mejor modelo disponible hace cada paso el doble de rápido, se ahorran ocho minutos y medio. Sobre el papel, una mejora del 50 %. En la práctica, la solicitud sigue tardando veintidós días.

El tiempo estaba en las colas, en los traspasos entre personas y en las esperas. En una pyme el patrón es el mismo con otros protagonistas: la firma del gerente que se acumula hasta el viernes, el documento que el cliente no termina de enviar, la consulta a la gestoría que tarda cuatro días, el paso de quien vende a quien factura.

Un asistente que redacta en dos minutos el correo que antes llevaba diez no cambia nada si después hay que esperar una semana la respuesta. Un proyecto que se mide por los minutos ahorrados en la tarea, sin mirar cuánto tarda el proceso completo, puede declararse un éxito en la presentación y no notarse en la empresa.

Se puso la IA encima del proceso de siempre

Los procesos de una empresa se diseñaron, a propósito o por acumulación, alrededor de lo que podían hacer las personas, y muchos pasos existen solo por eso. Se revisa una muestra porque no hay tiempo para revisarlo todo. Se agrupan las tareas por semanas porque interrumpirse es caro. Se pide la misma información en tres formularios porque cada departamento tenía el suyo.

Si se introduce IA y esos pasos se mantienen, se paga la tecnología nueva sin recoger la mayor parte de su beneficio. Algunos pasos dejan de tener sentido. Y aparecen otros que antes no hacían falta: alguien tiene que atender los casos que el sistema no sabe resolver, revisar por muestreo lo que hace y dejar registro de todo para reconstruir qué pasó cuando algo falle, como detallamos en qué hacer cuando la IA se equivoca.

Hammer contaba un caso que lo ilustra mejor que ninguno. El departamento de cuentas a pagar de Ford en Norteamérica tenía más de quinientas personas, que dedicaban la mayor parte del tiempo a investigar discrepancias entre el pedido, el albarán y la factura. Una opción era ayudarles a investigar más deprisa. Ford eligió evitar las discrepancias: eliminó las facturas, registró los pedidos en una base de datos compartida y pasó a cotejar automáticamente tres datos en lugar de catorce al recibir la mercancía. Donde implantó el nuevo proceso redujo la plantilla un 75 %, frente al 20 % que habría logrado con un programa convencional (Hammer, 1990).

Dos detalles importan. La mejora vino de preguntarse por qué existían las discrepancias, no de investigarlas más rápido. Y en esa solución no había ninguna inteligencia artificial: era un proceso rediseñado con reglas bien pensadas.

Se le pidió a un solo agente que lo hiciera todo

La tentación más reciente es la opuesta a la de las reglas: contratar el modelo más potente, darle acceso a todos los sistemas, escribirle unas instrucciones larguísimas y esperar que resuelva el proceso completo.

Suele salir mal por razones ajenas a la inteligencia del modelo. Un sistema así no se puede probar por partes: cuando falla, solo se sabe que algo salió mal. Necesita permisos amplios, de modo que el mismo componente que lee correos de desconocidos puede modificar datos o pagar, justo la situación que describimos al hablar de inyección de instrucciones. Usa el modelo más caro también para lo trivial. Y los errores se encadenan: si cada paso acierta el 95 % de las veces, diez pasos seguidos sin comprobación intermedia aciertan algo menos del 60 %.

Anthropic, en la guía que elaboró a partir de su trabajo con decenas de equipos que construían agentes, distingue los sistemas en los que los modelos siguen caminos definidos de antemano en el código de aquellos en los que el propio modelo decide sus pasos. Recomienda buscar la solución más simple posible y añadir complejidad solo cuando haga falta, lo que a veces significa no construir agentes en absoluto, y advierte de que la autonomía implica más coste y errores que se acumulan (Schluntz y Zhang, 2024).

Repartir el trabajo entre muchos agentes tampoco garantiza nada. Un estudio presentado en NeurIPS 2025 analizó más de 1.600 ejecuciones de siete sistemas multiagente de código abierto y encontró tasas de fallo de entre el 41 % y el 86,7 % (Cemri et al., 2025). La categoría de fallo más frecuente, con el 44,2 % de los casos, correspondía a problemas de diseño y especificación del sistema (agentes que no respetaban su tarea o su papel, pasos repetidos, condiciones de parada desconocidas), por delante de la descoordinación entre agentes y de la verificación insuficiente. El estudio trata tareas de programación y matemáticas, no procesos de empresa, pero la lección se traslada bien: el fallo estaba sobre todo en cómo se definieron las piezas.

Cognition, que construye agentes de programación, llegó a una conclusión parecida por la vía práctica. En 2025 desaconsejaba los sistemas con varios agentes trabajando en paralelo, porque cada uno toma decisiones implícitas que chocan con las de los demás (Yan, 2025). En 2026 matizó: sí funcionan las configuraciones en las que solo un agente actúa y los demás aportan criterio, como un revisor que examina el trabajo de otro sin haber compartido su contexto. Las redes de agentes que negocian libremente entre sí le parecen, sobre todo, una distracción (Yan, 2026).

Qué se hace distinto cuando sí funciona

Se mide antes de construir, y se mide el proceso entero. En quince o veinte casos reales se anota cuánto tiempo se trabajó en cada uno y cuánto tardó desde que entró hasta que se cerró. En una pyme bastan las fechas de los correos y los registros del programa de gestión. Esa diferencia dice, antes de gastar nada, si el problema es la tarea o son las esperas, y fija la línea de partida para comprobar después si el proyecto funcionó, como explicamos en cómo evaluar si un sistema de IA funciona de verdad.

Cada paso se asigna a una de tres herramientas. Una regla fija, cuando la decisión se puede escribir sin interpretar nada. Inteligencia artificial, cuando la entrada varía o hay que interpretar y un error es barato de detectar y corregir. Y una persona, cuando el error es caro o irreversible, o no hay casos anteriores suficientes para fiarse de un criterio automático. Incluso entonces la IA es útil: reúne los datos, los antecedentes y los documentos, y los presenta para que la persona decida en un minuto lo que antes le costaba media hora de búsqueda.

Se decide conscientemente si hay que cambiar el proceso. No siempre hace falta. Si el proceso ya está ordenado, el tiempo se va en el trabajo y la IA sustituye un paso concreto (por ejemplo, teclear los datos de un documento), automatizar ese paso da resultados sin tocar nada más. Hay que rediseñar cuando el tiempo se va en esperas y traspasos, cuando hay pasos que solo existían por las limitaciones de las personas o cuando la IA introduce necesidades nuevas de revisión y registro. En esos casos no basta con colocar la IA en el hueco que dejaba una persona: el flujo se rehace a partir de lo que hace bien cada una de las tres herramientas. En el sector lo llaman diseñar AI-first; en castellano, diseñar el proceso pensando en la IA desde el principio.

La parte de IA se construye con piezas pequeñas y bien definidas. Cada pieza hace una sola cosa: extraer los datos de una factura, clasificar un correo, preparar el expediente de una discrepancia. Cada una tiene una entrada y una salida precisas, sus propios casos de prueba, solo los permisos que necesita y el modelo adecuado a su dificultad, que casi nunca es el más caro, como argumentamos en cómo elegir el modelo según la tarea. El orden en que actúan lo decide un flujo escrito en código convencional, no los agentes. Y cuando hay que modificar algo en un sistema, lo hace una sola pieza; las demás leen, preparan o revisan. El día que algo falla, se sabe qué pieza fue, se corrige y se vuelve a probar sin tocar el resto.

Un ejemplo: la factura de proveedor

Un proceso que existe en casi cualquier empresa sirve para ver las cuatro ideas funcionando juntas.

Antes. La factura llega por correo en PDF. Alguien la abre y teclea los datos en el programa de gestión. Busca el pedido y el albarán. Si algo no cuadra, escribe al comprador o al proveedor y espera. Las facturas revisadas se acumulan hasta que el gerente las firma, normalmente una vez por semana, y entonces se programa el pago.

La tentación habitual sería poner un asistente de IA a leer las facturas. Aceleraría el tecleo, que es la parte que menos tiempo consume. Las esperas por las discrepancias y la firma semanal seguirían igual.

Después.

1. Primero se elimina lo que se puede eliminar. Si un proveedor puede enviar la factura en formato estructurado, no hay nada que leer. Y, siguiendo la lección de Ford, se revisa por qué se producen las discrepancias más frecuentes (pedidos sin registrar, albaranes que se apuntan tarde) para evitarlas en origen.
2. Para las facturas que siguen llegando en PDF, una pieza de IA extrae los datos. Aquí la IA aporta algo real, porque cada proveedor usa un formato distinto.
3. Una regla coteja la factura con el pedido y el albarán.
4. Otra regla aprueba las facturas que cuadran y están por debajo de un importe fijado por la empresa. La firma semanal, que existía como control, se sustituye por ese umbral y por la revisión de excepciones. Este es el cambio de proceso.
5. Cuando algo no cuadra, otra pieza de IA prepara el caso: qué dato no coincide, qué ha pasado otras veces con ese proveedor y qué correos relacionados hay. No modifica nada.
6. Una persona revisa esa cola de excepciones y decide con la información delante.
7. Una regla programa el pago.

Dos piezas de IA, cuatro reglas y una persona. Ninguna pieza de IA puede pagar, y cada una se prueba por separado con facturas reales. Y la mejora más importante la producen dos cambios que no son de IA: quitar la espera de la firma semanal y reducir las discrepancias en origen.

Por qué no se hace así más a menudo

La forma más fácil de introducir IA en una empresa es comprar licencias. No obliga a tocar ningún proceso ni a discutir con nadie, y por eso mismo tampoco cambia nada. Rediseñar un proceso incomoda: toca costumbres, obliga a decidir quién aprueba qué y saca a la luz problemas que llevaban años sin nombrarse.

Además, las dos mitades del trabajo suelen estar en manos distintas. Quien vende herramientas de IA rara vez se sienta a desmontar un proceso con quien lo ejecuta cada día, y tiende a colocar su producto encima de lo que encuentra. Quien sabe dibujar procesos rara vez sabe qué se le puede confiar a un modelo, cuánto cuesta ejecutarlo miles de veces al mes o qué pasos deberían seguir siendo reglas. Hacen falta las dos cosas en la misma mesa.

Aquí una pyme tiene una ventaja que no suele aprovechar. En una empresa grande, cambiar un proceso que cruza cuatro departamentos exige a alguien con autoridad sobre los cuatro, y esa persona casi nunca está en la reunión. En una pyme, quien puede decidir que la firma semanal desaparece suele estar sentado a la mesa, y un rediseño se puede probar en semanas.

En resumen

• Cuando un proyecto de IA «no funciona», casi nunca es por el modelo. Hammer describió lo mismo con la informática en 1990: se usa la tecnología para acelerar procesos que deberían haberse replanteado.
• Buena parte de la automatización no necesita IA. Las reglas son más baratas, predecibles y auditables. La IA se reserva para los pasos donde hay que interpretar, y ahí resuelve lo que antes no tenía solución.
• El tiempo de un proceso suele estar en las esperas y los traspasos, no en el trabajo. Por eso hay que medir el tiempo total antes de decidir qué automatizar.
• A veces basta con automatizar un paso. Otras hay que rediseñar el proceso, porque muchos pasos existían solo por las limitaciones de las personas y la IA trae necesidades nuevas.
• Un agente que lo hace todo es difícil de probar, caro y peligroso en permisos. Funcionan las piezas pequeñas y bien especificadas, coordinadas por un flujo definido, con una sola que actúa.
• Una pyme tiene ventaja para hacerlo bien: quien puede cambiar el proceso suele estar en la reunión.

Referencias

Cemri, M., Pan, M. Z., Yang, S., Agrawal, L. A., Chopra, B., Tiwari, R., Keutzer, K., Parameswaran, A., Klein, D., Ramchandran, K., Zaharia, M., Gonzalez, J. E., & Stoica, I. (2025). Why do multi-agent LLM systems fail? En Advances in Neural Information Processing Systems 38: Datasets and Benchmarks Track. https://proceedings.neurips.cc/paper_files/paper/2025/file/b1041e52d3be19f0a9bc491657488e4a-Paper-Datasets_and_Benchmarks_Track.pdf

Department for Business and Trade. (2025). The evaluation of the M365 Copilot pilot in the Department for Business and Trade. GOV.UK. https://assets.publishing.service.gov.uk/media/68adbe409e1cebdd2c96a19d/dbt-microsoft-365-copilot-evaluation.pdf

Hammer, M. (1990). Reengineering work: Don't automate, obliterate. Harvard Business Review, 68(4), 104-112. https://hbr.org/1990/07/reengineering-work-dont-automate-obliterate

Schluntz, E., & Zhang, B. (2024, 19 de diciembre). Building effective agents. Anthropic. https://www.anthropic.com/engineering/building-effective-agents

Yan, W. (2025, 12 de junio). Don't build multi-agents. Cognition. https://cognition.com/blog/dont-build-multi-agents

Yan, W. (2026, 22 de abril). Multi-agents: What's actually working. Cognition. https://cognition.com/blog/multi-agents-working