Gartner pronosticó un 30% de PoCs de IA generativa abandonadas. Fue peor

La mayoría de las pruebas de concepto de IA generativa mueren por motivos que eran visibles antes de empezar: nadie acordó qué tenía que demostrar la PoC, nadie calculó cuánto costaría a escala y nadie tenía autoridad para decidir qué hacer con el resultado. El modelo casi siempre funciona. Lo que falta es el camino entre "funcionó en la demo" y "merece la pena invertir".

Lo que dijo Gartner, y lo que pasó

El 29 de julio de 2024, Gartner publicó su pronóstico de que al menos el 30% de los proyectos de IA generativa se abandonarían tras la prueba de concepto antes de finales de 2025. Los motivos citados: datos de baja calidad, controles de riesgo inadecuados, costes crecientes y un valor de negocio poco claro. En el mismo evento, la analista Rita Sallam dijo que los directivos estaban impacientes por ver el retorno de sus inversiones en IA generativa y que las organizaciones tenían dificultades para demostrar y materializar ese valor. Estimó que las iniciativas para cambiar el modelo de negocio con IA generativa pueden costar entre 5 y 20 millones de dólares.

El pronóstico se quedó corto. En un artículo posterior, Why 50% of GenAI projects fail, la propia Gartner afirma que a finales de 2025 al menos el 50% de los proyectos de IA generativa se habían abandonado tras la PoC, por los mismos cuatro motivos.

Otras investigaciones llegan a conclusiones parecidas por caminos distintos. El informe The Root Causes of Failure for Artificial Intelligence Projects, de RAND (2024), entrevistó a 65 científicos de datos e ingenieros y cita estimaciones de que más del 80% de los proyectos de IA fracasan, el doble que los proyectos de TI sin IA. La causa más citada no fue técnica: fue que la dirección del negocio entendía mal, o comunicaba mal, qué problema debía resolver la IA.

Los cuatro motivos, traducidos para su próxima reunión

Valor de negocio poco claro. La PoC demostró que el modelo responde bien, pero nadie escribió antes qué número debía mover. Sin eso, el resultado siempre es "interesante" y nunca "aprobado". La pregunta que lo resuelve: si esta PoC sale bien, ¿qué indicador cambia, cuánto y quién lo va a notar?

Costes crecientes. Una PoC con 20 usuarios y 500 preguntas al día cuesta poco. La misma aplicación con 3.000 usuarios, historial de conversación, búsqueda en documentos (RAG) y revisión humana cuesta otra cosa. Gartner describe bien el efecto: el coste por token parece despreciable hasta que se multiplica por miles de usuarios y decenas de casos de uso. Si la PoC no estima el coste por transacción a escala, la primera factura de producción se convierte en el motivo de la cancelación.

Datos de baja calidad. La PoC se hizo con 200 documentos elegidos a mano. En producción, el asistente se encuentra versiones duplicadas, PDF escaneados sin texto y políticas obsoletas que nadie borró. La precisión cae y la confianza del usuario cae con ella.

Controles de riesgo inadecuados. Legal, seguridad y privacidad solo entran cuando el proyecto quiere pasar a producción. Entonces aparecen las preguntas sobre el RGPD, el registro de decisiones o los datos de clientes enviados a un modelo de terceros. Si la PoC no se diseñó para responderlas, el proyecto vuelve al principio, o se detiene.

Observe que ninguno de los cuatro motivos es que el modelo se equivoque. Son fallos de diseño del proyecto, y todos aparecen en las preguntas que cualquier director financiero haría al aprobar un presupuesto. La diferencia está en el momento: cuando esas preguntas llegan después de la PoC, responderlas cuesta semanas de retrabajo; cuando llegan antes, cuestan una reunión. Hay además un efecto menos visible. Cada PoC abandonada sin explicación deja a la dirección un poco más escéptica, y la siguiente propuesta de IA empieza con menos crédito, aunque sea buena. Una PoC descartada con criterios y números preserva ese crédito, porque demuestra que la empresa sabe detener lo que no funciona.

Qué cambia cuando la PoC se diseña para decidir

Una PoC que termina en una decisión tiene cinco cosas definidas antes del primer día:

1. La hipótesis de negocio, con un número. Por ejemplo: "el asistente reduce en un 40% el tiempo de respuesta a dudas sobre política comercial, con una tasa de respuestas incorrectas inferior al 5%".
2. El criterio de salida, en tres franjas: qué tiene que ser cierto para escalar, qué justifica ajustar y qué justifica descartar.
3. La estimación de coste a escala, con el volumen real de producción, no el de la PoC.
4. Los datos reales, o una muestra representativa, incluidos los documentos malos.
5. El responsable de la decisión, una persona con presupuesto y autoridad para decir sí o no cuando llegue el resultado.

Ejemplo hipotético: asistente de políticas comerciales

El escenario siguiente es un ejemplo hipotético, construido para ilustrar el razonamiento. No es un resultado de cliente.

Una empresa con 400 comerciales quiere un asistente que responda dudas sobre política de precios, descuentos y plazos. Hoy esas dudas llegan por correo a un equipo de 4 personas, con un tiempo medio de respuesta de un día.

Criterio acordado antes de la PoC: el asistente debe responder correctamente al menos el 90% de un conjunto de 300 preguntas reales del último semestre, evaluadas por el equipo de políticas, y el coste estimado en producción debe quedar por debajo de 1,50 euros por comercial al mes.

La PoC dura cuatro semanas. Resultado: 86% de aciertos. El análisis muestra que casi todos los errores vienen de dos documentos de política obsoletos que seguían en la base. Coste estimado: 1 euro por comercial al mes.

La decisión es fácil de tomar: ajustar. Actualizar los dos documentos, repetir la prueba con las mismas 300 preguntas y, si supera el 90%, escalar a un grupo piloto de 50 comerciales. Sin el criterio escrito, la misma PoC se habría convertido en una discusión sobre si un 86% es bueno o malo, y probablemente se habría archivado.

Señales de que su PoC va a ser abandonada

• El criterio de éxito es "ver si funciona".
• Nadie conoce el coste por transacción en producción.
• El conjunto de prueba lo eligió el equipo que construyó la PoC.
• Legal y seguridad todavía no han visto el proyecto.
• El patrocinador de la PoC no tiene presupuesto para la siguiente etapa.
• No hay fecha en la agenda para la reunión de decisión.

Si tres o más de estas señales describen su proyecto, conviene pausar y reescribir el alcance antes de gastar otra semana de ingeniería.

Checklist para una PoC que termina en una decisión

• La hipótesis tiene un indicador de negocio y un número.
• Las franjas de escalar, ajustar y descartar están escritas y firmadas por el patrocinador.
• El conjunto de prueba usa datos reales, incluidos los casos difíciles.
• La estimación de coste refleja el volumen de producción.
• Los riesgos de privacidad y seguridad se mapearon en la primera semana.
• La reunión de decisión está en la agenda antes del kickoff.

Siguiente paso

Antes de aprobar la próxima PoC, pida al equipo que presente las tres franjas de decisión y la estimación de coste a escala. Si no puede hacerlo, la PoC todavía no está lista para empezar.

Por eso diseñamos la Cyborg Forge como un proceso de 3 a 6 semanas, con el criterio de éxito acordado antes del primer día y un Decision Package al final que recomienda escalar, ajustar o descartar. Los detalles de cada etapa están en nuestra metodología.