Detalles del Artículo

Por qué la mayoría de los pilotos de IA nunca llegan a producción
ProductoStartupsIA

Por qué la mayoría de los pilotos de IA nunca llegan a producción

Volver

Una demo de IA que funciona le lleva a un buen ingeniero una semana. Una funcionalidad de IA de la que dependan diez mil clientes lleva un trimestre. Casi todos los proyectos de IA que nos piden rescatar murieron en el hueco entre esas dos frases, y las causas se repiten con una consistencia notable.

Fallo uno: nadie definió qué significa "bien"

"Que responda preguntas de soporte" no es una especificación. "Que resuelva el 40% de los tickets de nivel uno sin escalado, con menos de un 2% de respuestas incorrectas, medido cada semana sobre 200 tickets reales" sí lo es. Sin la segunda versión no existe el momento en que alguien pueda decir que está listo, así que nunca se lanza.

Escribe el objetivo antes que el prompt. Si no puedes enunciar el umbral, no estás listo para construir: estás listo para evaluar durante dos semanas.

Fallo dos: los datos nunca estuvieron realmente disponibles

Los pilotos funcionan con una exportación elegida a mano. Producción funciona con sistemas vivos, permisos, registros obsoletos y clientes que se dieron de baja el martes pasado. El trabajo poco vistoso de llevar datos limpios, actuales y con control de acceso hasta el modelo suele ser dos tercios del proyecto y casi nunca está en la estimación del piloto.

Fallo tres: no hay plan B

Toda funcionalidad de IA se equivoca a veces. Las que llegan a producción tienen respuesta al "¿y entonces qué?": escalar a una persona, mostrar un borrador según la confianza, negarse en lugar de inventar. Las que no llegan son aquellas en las que equivocarse no tiene consecuencia definida, así que legal y soporte bloquean el lanzamiento en silencio.

Fallo cuatro: la evaluación no tiene dueño

El comportamiento del modelo cambia, los proveedores retiran versiones y tus propios cambios de prompt interactúan entre sí. Si nadie mantiene una batería de regresión que se ejecute en cada cambio, la calidad se degrada de forma invisible hasta que un cliente se queja en público.

  • Un conjunto fijo de entradas reales con resultados esperados, versionado en el repositorio.
  • Una ejecución automática ante cada cambio de prompt, modelo o recuperación.
  • Una persona con nombre que lea las cifras semanales.
  • Una vuelta atrás documentada a la última configuración buena conocida.

Si la funcionalidad no se puede evaluar automáticamente, no se puede mantener. Todo lo demás es una demo con fecha de lanzamiento.

Nada de esto es exótico. Es la misma disciplina que separa un prototipo de un producto en cualquier otro ámbito; solo que se salta más a menudo cuando la demo impresiona lo suficiente.