Los 7 errores típicos en POCs de IA (y cómo evitarlos antes de empezar).

Por qué los POCs siguen muriendo en 2025

Cuando entramos en una pyme que ya intentó 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 el rango que aparece consistentemente en la literatura (Gartner, McKinsey State of AI 2024, ONTSI 2024) es 60-70% de mortalidad de POCs de IA a 3 meses, llegando a 75% en sectores menos digitales. Y rara vez es un problema técnico. Los siete errores que siguen son los que se repiten en proyectos del sector.

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

Error 1 · Empezar por el modelo, no por el cuello de botella

El proyecto se lanza porque “alguien tenía que probar IA”. El sponsor compra una herramienta sin haber definido qué proceso concreto está cuello de botella. Resultado: una pieza tecnológica buscando un problema, en vez de un problema buscando solución.

Síntoma temprano: en la primera reunión, nadie del comité ejecutivo puede explicar en una frase qué métrica de negocio mueve el proyecto.

Cómo evitarlo: antes de hablar con proveedores, dedica una sesión de 90 minutos a mapear los 5 procesos críticos del área que más sufre. Identifica el que tiene mayor volumen, datos disponibles y métrica auditable. Esa es la pieza candidata.

Error 2 · Sponsor sin poder de decisión operativa

El sponsor es de TI, de innovación, de transformación digital. Cuando llega el momento de cambiar un proceso real, no tiene autoridad para hacerlo. La pieza queda flotando en el limbo entre “funciona técnicamente” y “nadie la usa”.

Síntoma temprano: el sponsor no puede aprobar cambios en el flujo de trabajo del equipo operativo sin pedir permiso a otro director.

Cómo evitarlo: el sponsor debe ser el director del área que va a usar la pieza. TI co-patrocina, no patrocina. Si no consigues un sponsor operativo, el proyecto no está listo.

Error 3 · Métrica de éxito definida después

“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 exactamente.

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

Cómo evitarlo: antes de firmar, define una métrica primaria y dos secundarias. Las tres deben cumplir: numéricas, consultables hoy, con un baseline auditado de los últimos 90 días. Sin baseline previo, no hay forma de demostrar mejora.

Error 4 · POC sobre datos sintéticos

El proveedor enseña la herramienta con datos demo, datos sintéticos o datos públicos. Sobre el papel funciona perfecto. Cuando se conecta a tus datos reales — sucios, incompletos, con errores históricos — el modelo se rompe.

Síntoma temprano: en la demo del proveedor no se vio ni un solo registro de tu empresa. Solo capturas de pantalla “tipo”.

Cómo evitarlo: exige que el POC se haga sobre una muestra real de tus datos (50-200 registros mínimo) antes de firmar. Esto se llama “POC con datos del cliente” y debería ser estándar. Si el proveedor se resiste, asume que su modelo no aguanta tu realidad.

Error 5 · Equipo operativo no participa 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 día a día.

Cómo evitarlo: 2-3 personas del equipo operativo en cada workshop de diseño. No “para informar”. Con voz y voto sobre cómo encaja la herramienta en su flujo. Esto es lo que más diferencia los proyectos que viven de los que mueren.

Error 6 · Sin criterio explícito de “matar el POC”

Nadie firma un contrato pensando “esto puede ir mal”. Resultado: cuando el POC va mal, nadie tiene autoridad ni criterio para cancelarlo. Se alarga 3 meses más esperando “mejoras”, y al final muere por agotamiento sin haberse cerrado nunca.

Síntoma temprano: el contrato no contiene una cláusula de salida con criterio objetivo en mes 3.

Cómo evitarlo: negocia desde el día 1 una cláusula que diga: “si en mes 3 la métrica X no ha mejorado en al menos Y%, el contrato se cierra sin penalización”. Si el proveedor no acepta este punto, el problema no es tu pyme — es que ellos saben que no van a llegar a la cifra.

Error 7 · Confundir POC con producción

Un POC valida una hipótesis. Una pieza en producción funciona todos los días, integrada con el resto del stack, monitorizada, mantenida. Son dos animales distintos. Casi todos los POCs fallidos son en realidad POCs exitosos que se intentaron escalar a producción sin pasar por la fase intermedia de “endurecer la pieza”.

Síntoma temprano: el contrato no diferencia presupuesto entre POC y go-to-production. Se asume que es lo mismo.

Cómo evitarlo: separa el proyecto en tres fases con presupuesto, calendario y criterio de éxito independientes:

• POC (4-6 semanas): validar hipótesis con datos reales sobre muestra acotada.
• Hardening (4-8 semanas): integración con stack, monitoring, escalabilidad, documentación, contingencia.
• Producción (continuo): operación, mantenimiento, mejora continua, métricas mensuales.

Checklist pre-POC: 8 preguntas que ahorran 60.000 €

Si estás a punto de firmar un POC de IA, contesta estas 8 preguntas. Si fallas en 3 o más, posponer el proyecto 30-60 días te ahorra mucho dinero.

• ¿Puedo explicar en una frase qué métrica de negocio mueve este POC?
• ¿El sponsor tiene autoridad para cambiar el flujo de trabajo del equipo afectado?
• ¿Tengo definida una métrica primaria, numérica, con baseline auditado?
• ¿El POC se va a hacer sobre una muestra real (no sintética) de mis datos?
• ¿Hay 2-3 personas del equipo operativo en el comité de diseño?
• ¿El contrato tiene cláusula de salida con criterio objetivo en mes 3?
• ¿Tengo presupuestos diferenciados para POC, hardening y producción?
• ¿Si el POC funciona, sé exactamente qué proceso cambia y quién lo aprueba?