Por qué fracasan proyectos de IA, y la solución práctica para cada causa

Por qué fracasan proyectos de IA: ¿qué dice la investigación?

La investigación coincide en que la mayoría de los proyectos se estancan entre el piloto y la producción, y en que el modelo rara vez es la causa. MIT NANDA informó en julio de 2025 de que el 95 % de las organizaciones no vio un retorno medible en su cuenta de resultados con la IA generativa, y señaló flujos de trabajo frágiles, herramientas que no aprenden del contexto y poco encaje con el trabajo diario.

El informe de BCG de octubre de 2025 sobre la creciente brecha de valor de la IA concluyó que solo una pequeña minoría de empresas obtiene valor de la IA a escala. Según una encuesta de S&P Global Market Intelligence, una proporción creciente de empresas abandonó la mayoría de sus iniciativas de IA en 2025, alegando costo, privacidad de datos y seguridad. Gartner pronosticó en junio de 2025 que más del 40 % de los proyectos de IA agéntica se cancelarán antes de finales de 2027 por su costo, un valor poco claro o controles de riesgo débiles, y advirtió del agent washing.

Leídas en conjunto, estas conclusiones apuntan a siete causas. Las secciones siguientes las tratan una a una, cada una con la solución que aplicamos.

Causa 1: Nadie midió el punto de partida

Un proyecto no puede demostrar su valor si nadie registró cómo se hacía el trabajo antes. El valor poco claro del que habla Gartner suele ser exactamente esto: el sistema funciona, pero no hay una cifra previa con la que compararlo, así que la revisión presupuestaria no tiene nada que señalar.

La solución es medir antes de construir. Para el flujo de trabajo elegido, registre los minutos por tarea, las tareas al mes, la tasa de errores o retrabajo y quién lo hace. Acuerde el objetivo en las mismas unidades (por ejemplo, el tiempo de registro de facturas y el porcentaje de facturas que necesitan corrección) e incluya la comparación en un informe mensual desde el lanzamiento.

Si todavía no puede medir la línea base, dedique dos semanas a registrarla a mano antes de financiar el desarrollo. Es barato y, a menudo, revela que el verdadero cuello de botella está en otro sitio distinto del que todos suponían.

Causa 2: El flujo de trabajo se rompe con entradas reales

Los flujos de trabajo frágiles, la primera causa que citó MIT NANDA, suelen venir de probar con muestras ordenadas. Las entradas reales incluyen PDF escaneados, cadenas de correos reenviados, personas que cambian de tema a mitad de llamada y registros que ya existen en el CRM con un nombre ligeramente distinto.

La solución es un conjunto de evaluación creado a partir de ejemplos reales y desordenados con respuestas correctas conocidas, que se vuelve a ejecutar tras cada cambio en los prompts, la recuperación o el modelo. Añada validación campo a campo (totales que deben cuadrar, fechas que deben estar en rango, identificadores que deben existir en NetSuite o QuickBooks) y un umbral de confianza que envíe los casos dudosos a una cola de revisión humana en lugar de adivinar.

• Conjunto de evaluación extraído de las entradas reales de los últimos meses, incluidos los fallos.
• Reglas de validación en cada campo que se escribe en un sistema de registro.
• Cola de revisión humana para todo lo que quede por debajo del umbral de confianza.

Causa 3: La herramienta queda fuera del trabajo diario

El poco encaje con el trabajo diario, la tercera causa de MIT NANDA, se manifiesta como una ventana de chat o un cuadro de mando aparte que la gente tiene que acordarse de abrir. En cuestión de semanas dejan de abrirlo, y el uso cae discretamente a cero.

La solución es entregar el resultado donde ya se hace el trabajo: una respuesta en borrador dentro del ticket de Zendesk, un registro rellenado en HubSpot o Salesforce, una factura de proveedor esperando aprobación en el ERP, un resumen publicado en el canal que el equipo ya usa. Uno de nuestros casos de éxito muestra el mismo principio sin ningún chatbot: un proveedor de servicios de terapia trasladó a sus terapeutas a un portal guiado en AppSheet con validaciones y sincronización con facturación; la carga de datos bajó de 10-15 minutos al día a menos de 3, y los errores se eliminaron en origen.

Causa 4: El sistema no aprende del contexto

Un sistema que responde desde un prompt congelado sigue cometiendo los mismos errores, y por eso las herramientas que no aprenden del contexto entraron en la lista de MIT NANDA. Las políticas cambian, las listas de precios se actualizan y el personal corrige el mismo error cada semana sin ningún efecto.

La solución tiene dos partes. Primero, anclar las respuestas en los documentos actuales de la empresa mediante recuperación con citas, de modo que actualizar un archivo en SharePoint o Google Drive actualice la respuesta y un revisor pueda ver la fuente. Segundo, cerrar el circuito: cada corrección hecha en la cola de revisión se registra, se añade al conjunto de evaluación y se usa para ajustar prompts o reglas con una periodicidad fija.

En los agentes de voz, la misma idea se aplica a las transcripciones: las llamadas en las que el agente transfirió, entendió mal o perdió a quien llamaba son el mejor material de entrenamiento para la siguiente ronda de cambios en prompts y enrutamiento.

Causa 5: Los costos crecen más rápido que el valor

El costo es la razón que aparece tanto en las conclusiones de S&P Global como en las de Gartner. Las facturas por uso de tokens de modelo y minutos de voz crecen con el volumen, y un agente atrapado en un bucle puede gastar en una tarde más de lo que valía su tarea.

La solución es incorporar el presupuesto al sistema desde la ingeniería. Fije un tope de costo por tarea que detenga la ejecución y avise a alguien, registre tokens y minutos por tarea desde la primera prueba, envíe la clasificación sencilla a un modelo más pequeño y reserve el grande para el razonamiento real, y revise cada mes el costo por tarea frente al valor por tarea. Nuestra guía sobre el costo de implementar IA enumera los componentes del costo de operación que conviene seguir.

Causa 6: Las dudas sobre privacidad y seguridad frenan el despliegue

La privacidad de los datos y la seguridad son las otras razones que citó la encuesta de S&P Global, y suelen aparecer tarde, cuando el departamento legal o TI ve el diseño por primera vez. Un piloto construido sobre una cuenta de chat de consumo no puede pasar a producción con datos de clientes o pacientes.

La solución es resolver el tratamiento de datos en las primeras semanas. Use planes de API o empresariales cuyas condiciones se ajusten a sus datos, obtenga un Business Associate Agreement (BAA) firmado de cada proveedor que trate información sanitaria protegida, dé al sistema solo el acceso mínimo que necesita y registre cada prompt y cada resultado. Los clientes son los propietarios de las cuentas, así que los datos permanecen bajo contratos que ellos controlan.

Incorpore a TI y al departamento legal a la revisión antes del desarrollo, no después. Un diagrama de flujo de datos de una página que muestre qué sistemas se leen, cuáles se escriben, qué proveedores ven los datos y dónde se guardan los registros responde pronto a la mayoría de sus preguntas.

Causa 7: Los agentes actúan sin suficiente control

Los controles de riesgo débiles son la tercera razón en el pronóstico de cancelaciones de Gartner, y los agentes elevan el riesgo porque ejecutan acciones, no solo escriben texto. El agent washing agrava el problema: productos vendidos como agentes autónomos que en realidad son scripts sencillos, o que actúan con mucha más libertad de la que el comprador creía.

La solución es acotar lo que un agente puede hacer. Enumere sus herramientas de forma explícita, dé a cada una el permiso mínimo, exija aprobación humana para todo lo que mueva dinero, contacte a un cliente o modifique registros regulados, y mantenga una vía de reversión que permita apagar el agente y devolver el trabajo a las personas. Al evaluar a un proveedor, pídale que muestre las llamadas a herramientas y los registros de una ejecución real, no solo la respuesta final.

¿Construir internamente o con un socio especializado?

MIT NANDA informó de que los proyectos comprados a socios especializados o construidos con ellos tuvieron éxito con más frecuencia que los desarrollos internos. La misma investigación concluyó que los mayores retornos procedían de la automatización del back office, aunque los presupuestos se inclinaban hacia ventas y marketing.

Sea cual sea el camino que elija, lo que importa son las soluciones anteriores. Nosotros definimos el alcance de cada proyecto en una revisión gratuita, lo presupuestamos como un desarrollo a precio cerrado y entregamos el código, los prompts y las cuentas para que su equipo pueda operarlo. Nuestra guía sobre la hoja de ruta de implementación expone las fases en orden.