Por qué tantos pilotos de IA no llegan a producción

Un piloto de inteligencia artificial suele empezar bien. Hay un caso vistoso, una demostración que convence al comité de dirección y un presupuesto pequeño. Meses después, el sistema sigue funcionando solo en el entorno de pruebas y nadie ha decidido si se amplía o se apaga.

Este artículo repasa las causas más habituales de ese bloqueo y propone una forma de diseñar el piloto para que termine en una decisión clara.

Qué significa que un piloto llegue a producción

Un piloto llega a producción cuando el sistema trabaja con casos reales, dentro del flujo de trabajo habitual, con un responsable de negocio y un presupuesto de operación aprobado. Hasta ese momento sigue siendo un experimento, por útil que parezca.

La distinción importa porque los riesgos cambian de escala. En el piloto, un error lo detecta y corrige el propio equipo técnico. En producción, ese error puede llegar a un cliente, a un expediente o a una decisión económica.

El fenómeno está documentado. En julio de 2024, Gartner (2024) estimó que al menos el 30 % de los proyectos de IA generativa se abandonarían tras la prueba de concepto antes de terminar 2025. Los motivos que citaba eran la mala calidad de los datos, unos controles de riesgo insuficientes, el aumento de los costes y un valor de negocio poco claro. Un año después, Gartner (2025) previó que más del 40 % de los proyectos de IA agéntica se cancelarán antes de que acabe 2027, por razones muy parecidas.

Siete causas por las que un piloto de IA se queda en pruebas

Las causas más frecuentes tienen que ver con la organización y el diseño del proyecto, y coinciden en buena parte con las que señala Gartner. Estas son las siete que más se repiten.

1. El problema está sin definir

El piloto arranca con una pregunta tecnológica, del tipo «qué podemos hacer con IA», y nunca llega a concretar qué proceso mejora, cuántos casos trata al mes ni cuánto cuesta hoy resolverlos. Al final, nadie puede decir si ha funcionado, porque nunca se acordó qué significaba funcionar.

2. Los datos están dispersos

Los documentos viven en carpetas compartidas, correos y hojas de cálculo, con versiones duplicadas y nombres que cada persona pone a su manera. El piloto funciona con veinte ejemplos elegidos a mano y falla cuando recibe el volumen real. Preparar y ordenar los datos suele ser la parte más larga del trabajo, y conviene presupuestarla desde el principio.

3. Nadie responde del resultado

Si el piloto lo impulsa solo el área de tecnología, la decisión de escalarlo queda sin dueño. Hace falta una persona de la unidad de negocio con autoridad para cambiar el proceso y responder de los resultados ante la dirección.

4. El sistema queda fuera del flujo de trabajo

Una herramienta que obliga a copiar y pegar entre ventanas se usa durante la demostración y se abandona a las pocas semanas. El sistema debe leer de donde ya están los datos y devolver el resultado donde el equipo trabaja cada día, sea el gestor documental, el ERP o la bandeja de tareas.

5. La validación humana está sin diseñar

La frase «una persona lo revisará» necesita concretarse. Hay que decidir quién revisa, qué revisa, con qué criterio y qué ocurre cuando rechaza un resultado. Si la revisión no tiene un lugar definido en el proceso, acaba convertida en un cuello de botella o, peor, se omite.

6. Nadie controla el coste

El coste de cada consulta a un modelo parece pequeño con cien casos de prueba. Con decenas de miles de documentos al mes, reintentos y revisiones, la factura crece en proporción y puede dejar de compensar. Medir el coste por caso tratado durante el piloto permite saber si la operación es viable antes de comprometer presupuesto.

7. Falta un plan de operación

Un sistema de IA en producción necesita mantenimiento continuo. Alguien tiene que revisar errores, actualizar los documentos de referencia, ajustar reglas y atender incidencias. Si el piloto termina sin decidir quién hará ese trabajo y con qué presupuesto, el proyecto se detiene el día de la entrega.

Lista de comprobación antes de aprobar un piloto

Antes de aprobar un piloto de IA conviene responder por escrito a estas nueve preguntas. Cada pregunta sin respuesta es un riesgo concreto de que el proyecto se quede a medias.

1. ¿Qué proceso concreto se va a mejorar y cuántos casos trata al mes?
2. ¿Cuánto tiempo y dinero cuesta hoy cada caso, aunque sea una estimación?
3. ¿Qué datos necesita el sistema, dónde están y quién autoriza el acceso?
4. ¿Qué persona del negocio responde del resultado?
5. ¿En qué sistema verá y usará el equipo lo que produzca la IA?
6. ¿Quién valida cada resultado, con qué criterio y en qué paso del proceso?
7. ¿Qué métrica decide si el piloto se escala y qué umbral debe alcanzar?
8. ¿Cuál es el coste máximo aceptable por caso tratado?
9. ¿Quién operará el sistema después del piloto y con qué presupuesto?

Piloto exploratorio frente a piloto acotado

Un piloto exploratorio busca descubrir qué puede hacer la tecnología. Un piloto acotado comprueba si un proceso concreto mejora lo suficiente como para invertir en él. La tabla resume las diferencias prácticas.

Cómo diseñar un piloto acotado en cinco pasos

Un piloto acotado prueba un único proceso con casos reales, durante un periodo corto, y termina en una decisión explícita. Estos cinco pasos lo hacen posible.

Paso 1. Elegir un único proceso

Conviene elegir un proceso frecuente, con reglas razonablemente estables y un coste actual conocido. La clasificación de documentos entrantes o la revisión de un tipo concreto de contrato son buenos candidatos. Un proceso que ocurre dos veces al año da muy pocos casos para medir.

Paso 2. Trabajar con casos reales

El piloto se prueba con documentos y expedientes reales de los últimos meses, incluidos los difíciles, los incompletos y los mal escaneados. Los ejemplos limpios dan resultados que luego no se repiten en el trabajo diario.

Paso 3. Fijar las métricas antes de empezar

Las métricas habituales son el tiempo por caso, el porcentaje de resultados aceptados sin corrección, los errores graves detectados en la revisión y el coste por caso. Cada una necesita un umbral acordado con el responsable de negocio antes de ver el primer resultado. Si el umbral se fija después, la tentación de ajustarlo a lo obtenido es grande.

Paso 4. Ejecutar en paralelo al proceso actual

Durante el piloto, el equipo sigue trabajando como siempre y el sistema trata los mismos casos por su cuenta. Así se comparan resultados sobre la misma base y la operación diaria no corre ningún riesgo. Esta fase también muestra dónde encaja la revisión humana y cuánto tiempo consume.

Paso 5. Decidir con los datos

Al terminar, el comité compara los resultados con los umbrales y toma una de tres decisiones: escalar, ajustar y repetir, o cerrar. Cerrar un piloto que no alcanza sus métricas también es un buen resultado, porque evita una inversión mayor en algo que no iba a funcionar.

El piloto como primera fase de la operación

Un piloto bien planteado responde a una pregunta de negocio con datos propios y en un plazo corto, y deja preparadas las piezas que la producción va a necesitar: responsable, integración, revisión humana, control de costes y plan de operación. Adoq AI sigue ese orden en sus proyectos y empieza por entender el proceso y su cuello de botella antes de escribir código.