Saltar al contenido
SwankyForge
SwankyForge
Todos los insights
Artículo10 min de lectura

El 95% de los pilotos de IA no muestra impacto en la cuenta de resultados, según un recuento. Acuerde la métrica antes de construir el modelo.

Cuatro estudios de 2025 y principios de 2026 coinciden en que la mayoría de las empresas ve poco retorno medible de la IA, y el fallo habitual está del lado del negocio, así que la solución es una métrica, una línea base y una regla de decisión escritas antes de construir nada.

En julio de 2025 el proyecto NANDA del MIT publicó un informe que afirmaba que el 95% de las organizaciones obtenía un retorno nulo de la IA generativa, pese a una inversión empresarial de 30–40 mil millones de dólares. Fortune llevó la cifra a un titular en agosto de 2025, y a partir de ahí se extendió.

La cifra es más débil que su fama. Se apoya en entrevistas con 52 organizaciones, una encuesta a 153 altos directivos recogida en cuatro conferencias del sector y una revisión de más de 300 iniciativas públicas de IA. Los críticos consideraron demasiado estrecha la definición de éxito. Pero otros tres estudios con métodos distintos apuntan en la misma dirección: la mayoría de las empresas que usan IA todavía no la encuentran en sus resultados financieros.

Nuestra lectura es que la mayoría de estos pilotos se decidió antes de entrenar un modelo. Nadie midió una línea base, nadie acordó una métrica, nadie en el negocio era responsable del resultado y nadie planificó cómo entraría la salida en el proceso diario. Son carencias de negocio, y cerrarlas cuesta días de trabajo, no meses.

Cuatro estudios, una dirección

Fuente Muestra Qué se midió Resultado principal
MIT NANDA, julio de 2025 52 organizaciones entrevistadas, 153 directivos encuestados, más de 300 iniciativas públicas revisadas, enero–junio de 2025 Retorno autodeclarado de la IA generativa El 95% de las organizaciones obtiene retorno nulo; el 5% de los pilotos integrados extrae millones en valor
BCG, septiembre de 2025 1.250 altos directivos y responsables de decisiones de IA Valor de la IA en toda la empresa El 5% genera un valor sustancial a escala; el 60% declara mejoras mínimas de ingresos y costes
McKinsey, noviembre de 2025 Encuesta global a organizaciones Impacto en el EBIT a nivel de empresa El 88% usa IA en al menos una función; el 39% declara algún impacto en el EBIT, y la mayoría lo sitúa por debajo del 5% del EBIT
Documento de trabajo del NBER, febrero de 2026 Casi 6.000 directivos de empresas de cuatro países Efecto en el empleo y la productividad en los últimos tres años El 69% de las empresas usa IA; nueve de cada diez no declaran impacto en el empleo ni en la productividad

Las definiciones difieren. El MIT pregunta si un despliegue produjo un retorno medible, BCG clasifica a las empresas en grupos de madurez, McKinsey pregunta por el EBIT y la encuesta del NBER pregunta por productividad y plantilla. Ninguno es una medición limpia del efecto de la IA. En conjunto, dicen que la adopción es amplia y el retorno medido es raro.

Cuánto fiarse del 95%

Menos de lo que sugieren los titulares, y el propio informe lo dice. Su sección de limitaciones afirma que las cifras son «direccionalmente correctas» y proceden de entrevistas individuales y no de informes oficiales de las empresas, que las definiciones de éxito varían entre organizaciones y que una ventana de observación de seis meses puede subestimar el éxito en sistemas complejos. El éxito se definió como un despliegue más allá de la fase piloto con KPIs medibles, con el retorno evaluado seis meses después del piloto. Para herramientas de tareas específicas, una implantación exitosa era aquella que los usuarios o directivos describían como de efecto marcado y sostenido sobre la productividad o la cuenta de resultados.

La crítica del Marketing AI Institute añade que la definición ignora mejoras de eficiencia, retención y efectos sobre el pipeline comercial, y que 52 entrevistas no pueden sostener una afirmación sobre todo el mercado. Ambos puntos son justos. Trate el 95% como un dato ruidoso, no como una tasa de fracaso.

Dos partes del informe aguantan mejor que el titular. La primera es su diagnóstico. Los autores escriben que la brecha no parece deberse a la calidad de los modelos ni a la regulación, y que la mayoría de los despliegues falla por flujos de trabajo frágiles, falta de aprendizaje contextual y desalineación con las operaciones diarias. La segunda es lo que hicieron los compradores con éxito: juzgaron las herramientas por resultados operativos y no por benchmarks de modelos, y dejaron que los responsables de presupuesto y los gestores del área eligieran los problemas y dirigieran los despliegues.

El informe también encontró que las colaboraciones externas llegaban a despliegue alrededor del 67% de las veces, frente a alrededor del 33% de los desarrollos internos. Somos proveedores, así que esa cifra nos interesa, y debe leerse con la propia advertencia del informe: los números son autodeclarados, y las empresas que eligen socios pueden diferir en otros aspectos de las que desarrollan internamente. Es una correlación.

Por qué se estancan los pilotos

En nuestra opinión, cuatro carencias explican la mayoría de los pilotos estancados, y ninguna es técnica.

  1. Sin línea base. «El tiempo de gestión bajó un 20%» no significa nada si nadie midió el tiempo de gestión antes del piloto, con la misma definición, durante un periodo comparable.
  2. Sin métrica acordada. El equipo de datos informa de la exactitud del modelo, finanzas pregunta por el coste, operaciones pregunta por el throughput. Cada parte elige su número a posteriori, y el piloto acaba en una discusión en lugar de una decisión.
  3. Sin responsable en el negocio. Un piloto dirigido por un equipo central, sin nadie del lado del negocio que controle el presupuesto o el proceso, no tiene a nadie que lo despliegue cuando funciona.
  4. Sin camino hacia el proceso. El modelo funciona en un sandbox, pero nadie cambió la pantalla que usa la gente, el orden de los pasos ni los objetivos con los que se la mide. La salida que llega fuera del flujo de trabajo se ignora.

Para quien gestiona el presupuesto: una página antes de construir nada

Antes de mover ningún dato o elegir ningún modelo, escriba una página con seis líneas.

  • Métrica. Un número que ya le importa al negocio, con una definición exacta.
  • Línea base. Su valor actual, en una ventana declarada, calculado con la consulta que usará el piloto.
  • Regla de decisión. Qué resultado significa desplegar y cuál significa parar.
  • Salvaguardas. Qué no debe empeorar mientras la métrica mejora.
  • Responsable. La persona del negocio que cambiará el proceso si el piloto funciona.
  • Fecha de decisión. El día en que se toma la decisión, sea cual sea el resultado.

Un ejemplo ilustrativo para un copiloto de soporte que redacta respuestas a tickets de primera línea:

Línea Entrada ilustrativa
Métrica Mediana del tiempo de gestión por ticket de primera línea
Línea base Medida durante las cuatro semanas anteriores al piloto, mismas categorías de tickets
Regla de decisión Desplegar si la mediana baja un 10% o más; parar si baja menos de un 3%
Salvaguardas Tasa de reapertura y satisfacción del cliente a menos de un punto de la línea base
Responsable Responsable de soporte
Fecha de decisión Seis semanas después del lanzamiento

Si acordar esta página lleva más de una semana, el problema no está listo para la IA. A veces escribirla muestra que la métrica se puede mover con una regla o un informe, y entonces la respuesta más barata es la correcta.

Para ingenieros: que la métrica se sostenga

Aleatorice en la unidad donde ocurre el efecto. Para un copiloto de soporte, es el agente o el equipo, no el ticket, si de otro modo los agentes aprenderían del copiloto y cambiarían cómo gestionan los tickets de control. Para procesos operativos que no se pueden dividir a la vez, alterne periodos con un diseño switchback. Mantenga un pequeño holdout tras el despliegue para ver si el efecto se diluye.

Mida la línea base con el propio pipeline del piloto. Misma consulta, mismos filtros, misma duración de ventana. Haga primero una comparación A/A, dividiendo el tráfico sin aplicar ningún cambio, para ver cuánto se mueve la métrica por sí sola. Las métricas estacionales necesitan un grupo de control simultáneo; una comparación antes-después mezclará el piloto con el calendario.

Dimensione la prueba antes de empezar. Para dos grupos con un 80% de potencia y un 5% de significación, una regla práctica común es n por grupo ≈ 16·σ²/δ², donde σ es la desviación típica de la métrica y δ es el efecto más pequeño que vale la pena detectar. Números ilustrativos: si el tiempo de gestión tiene una desviación típica de 6 minutos y el efecto que importa es de 0,6 minutos, n ≈ 16 × 36 / 0,36 = 1.600 tickets por grupo. Un equipo que gestiona 200 tickets de este tipo a la semana necesita 16 semanas para reunir 3.200. Es el momento de elegir un efecto mayor, un piloto más largo o una métrica menos ruidosa, por ejemplo ajustando por el tiempo de gestión de cada agente en el periodo previo. Los tiempos de gestión son asimétricos, así que compare medianas o valores con transformación logarítmica, o calcule el intervalo con bootstrap.

Ponga la métrica en el contrato. La definición, la fuente de datos, la consulta, la ventana y el umbral van en el statement of work como criterio de aceptación del hito. La aceptación consiste entonces en ejecutar la consulta acordada, no en debatir si el sistema parece útil.

Escriba el criterio de cancelación antes del lanzamiento. Si el efecto en la fecha de decisión está por debajo del umbral, el piloto se detiene. Mirar el resultado cada día y parar cuando parece bueno infla los falsos positivos; si las miradas tempranas son inevitables, use un test secuencial diseñado para ellas.

Cómo trabajamos con esto

Acordamos la métrica antes de entrenar ningún modelo, y entra en el contrato como criterio de aceptación. Los hitos se facturan solo tras la aceptación, así que la métrica decide la factura. Un ingeniero con nombre se queda en el proyecto de principio a fin, lo que evita que la definición de la métrica se desvíe entre traspasos. Cuando la página de una sola hoja muestra que una regla o un informe movería la métrica por menos, lo decimos y recomendamos no comprar ML.

En nuestra tabla de tarifas, un discovery cuesta 6k–14k € en 2–3 semanas, y es la fase en la que redactamos la página anterior junto con quien gestiona el presupuesto. Un teardown muestra cómo se presupuestan discovery, prueba de concepto y producción, y la página de contacto es la forma de empezar uno.

Fuentes

¿Tiene un proceso que cuesta demasiado?

Cuéntenoslo. La primera llamada es gratuita y, si la IA no es la respuesta, se lo decimos.

Hablar de su tarea