Por qué el 60% de los POCs de IA en pymes mueren a los 3 meses.

El dato que nadie quiere ver

Cuando entramos en una pyme que ya ha intentado IA antes, casi siempre nos encontramos con el mismo cementerio: dos o tres pruebas de concepto que arrancaron con energía, presentaciones bonitas, un Slack lleno de capturas, y un final silencioso a los 90 días. Nadie cierra el proyecto formalmente. Simplemente deja de mirarse el panel.

El número exacto varía por estudio, pero la cifra que manejamos en campo es 60% de mortalidad a 3 meses. En sectores menos digitales sube al 75%. Y rara vez es un problema técnico.

”El POC no muere porque la IA falle. Muere porque el negocio no había decidido qué hacer cuando la IA funcionara.”

Las cinco causas reales

1. No había un dueño con poder de decisión

El POC se lanza porque “alguien tenía que probar IA”. El sponsor es de TI o de innovación, no de operaciones. Cuando llega el momento de cambiar un proceso real, no hay nadie con autoridad para hacerlo. La pieza queda flotando.

Síntoma temprano: nadie en el comité ejecutivo puede explicar en una frase qué métrica de negocio mueve el POC.

2. No había proceso debajo, había caos

Esto es lo que llamamos “AI on top of mess”. Pones un copilot encima de un proceso desordenado y obtienes desorden más rápido. El equipo descubre que la herramienta no soluciona nada porque el problema nunca fue de velocidad — era de claridad.

Síntoma temprano: si pides a tres personas del área que describan el proceso actual, te dan tres respuestas distintas.

3. La métrica de éxito era humo

“Mejorar la productividad”, “ahorrar tiempo”, “ser más eficientes”. Métricas no auditables. Cuando llega el día 90 y hay que defender continuar, nadie puede demostrar nada porque nadie había definido qué se medía.

Síntoma temprano: si la métrica de éxito no se puede consultar en un dashboard que ya existe, el POC va a morir.

4. El equipo no participó en el diseño

Las decisiones se toman arriba, la herramienta se entrega a las personas que la van a usar, y descubrimos a las 4 semanas que la sabotean en silencio. No por mala fe. Por miedo, por costumbre, o porque la herramienta efectivamente no encajaba en su día real.

Síntoma temprano: en la fase de diseño no se sentó en la mesa nadie del nivel operativo que va a tocar la pieza.

5. El proveedor vendió capacidades, no resultados

El contrato se firmó por número de usuarios, número de consultas, o “acceso a la plataforma”. No había compromiso por parte del proveedor con que la pieza funcionara para tu caso. Cuando algo no va bien, el proveedor tiene incentivos para alargar, no para resolver.

Síntoma temprano: si en el contrato no aparece una métrica de éxito que el proveedor acepta como criterio de continuidad, vas a tener problemas.

Lo que sí funciona

Los POCs que sobreviven al día 90 y se convierten en pieza estable comparten cinco rasgos. Son aburridos. No hay magia. Pero ahorran mucho dinero.

1. Dueño operativo, no de TI, con 4-6 horas semanales asignadas formalmente.
2. Proceso to-be diseñado antes de la primera línea de código. Aunque sea en una pizarra. Da igual.
3. Una métrica única, numérica, ya monitorizable. Tiempo de ciclo, ratio de conversión, NPS, tickets resueltos en primera respuesta.
4. El equipo operativo participó en validación cada sprint. No al final, cada semana o cada dos.
5. Contrato con criterio de continuidad explícito a 60 y 90 días, con compensación si no se cumple.

El verdadero coste

Un POC fallido no cuesta solo el dinero gastado. Cuesta la fatiga organizativa que deja: el comité que ya no quiere oír hablar de IA, el equipo escéptico, el “ya lo intentamos y no funcionó” que paraliza la siguiente decisión durante un año.

Por eso preferimos diagnosticar dos semanas antes de prometer ocho. Si el caso de uso correcto no aparece en el diagnóstico, te lo decimos. No firmamos. Es más barato para todos.