"Tenemos IA, ¿dónde la usamos?" — El error que hunde proyectos antes del primer modelo

Hay una pregunta que condena a un proyecto de IA antes de que nadie escriba una línea de código: "Tenemos esta herramienta, ¿dónde podemos usarla?"

Suena razonable. Alguien en la organización consiguió acceso a un modelo, una plataforma o una alianza con un proveedor, y ahora toca "encontrarle un caso de uso". El problema es que esa pregunta invierte el orden correcto. Empieza por la tecnología y busca después el problema, cuando debería ser exactamente al revés: ¿qué problema necesitamos resolver, qué resultado esperamos, y cómo sabremos si funcionó?

Esa diferencia —tool-first versus outcome-first— no es un matiz semántico. Es la línea que separa un prototipo llamativo de una solución que produce valor sostenido.

Por qué gestionar IA no es gestionar software

En un proyecto de software tradicional, los requisitos son relativamente estables y el camino hacia la entrega es lineal: se define, se construye, se prueba, se despliega. En IA, esa linealidad se rompe. Entran en juego la calidad y disponibilidad de los datos, la evaluación continua del modelo, el riesgo, la privacidad, la explicabilidad, la adopción por parte de los usuarios y el monitoreo posterior al despliegue. Un modelo que funciona hoy puede degradarse mañana si los datos que lo alimentan cambian. Un prototipo que impresiona en una demo puede no sobrevivir el contacto con datos reales, procesos reales y usuarios reales.

Esto obliga a pensar el proyecto en fases que se retroalimentan: entender el negocio, entender los datos, prepararlos, desarrollar el modelo, evaluarlo y llevarlo a operación. No como un checklist rígido, sino como un ciclo donde es normal —y necesario— regresar a una fase anterior cuando algo no cuadra. Retroceder no es fracaso. Es la metodología funcionando como debe.

El caso que lo explica mejor que cualquier framework

Una organización industrial quería "predecir fallas" en sus equipos de producción. Sonaba a proyecto de IA clásico: sensores, datos, modelo predictivo, alerta temprana. Pero al examinar el problema de negocio con más profundidad, apareció el dato que cambió todo: el equipo de mantenimiento no necesitaba predecir la falla en abstracto. Necesitaba siete días de anticipación, porque ese era el tiempo real que tomaba conseguir los repuestos.

Ese matiz —de "predecir fallas" a "avisar con siete días de margen"— redefinió por completo qué tenía que hacer el modelo y qué datos necesitaba para lograrlo.

Y ahí llegó el segundo hallazgo, más incómodo: los sensores registraban lecturas una vez por hora, mientras que ciertas fallas podían desarrollarse en cuestión de minutos. No importaba qué tan sofisticado fuera el modelo elegido; con esa granularidad de datos, la ventana de siete días de anticipación era, sencillamente, inalcanzable.

Ningún ajuste de hiperparámetros iba a resolver eso. El problema no estaba en el modelo. Estaba en cómo se había definido el objetivo y en si los datos disponibles podían siquiera sostenerlo. Un proyecto bien intencionado, con presupuesto y buena voluntad, puede irse contra un muro invisible si nadie hizo antes las preguntas incómodas.

Elegir el modelo, además, nunca es solo una cuestión de precisión. Entran en la ecuación el costo, la privacidad, la explicabilidad, el mantenimiento a futuro y la capacidad real de la organización para gobernar esa solución en el tiempo. Una opción técnicamente superior pero imposible de explicar a un regulador, o inviable de mantener con el equipo disponible, no es la mejor opción: es un riesgo disfrazado de innovación.

El rol del Project Manager cambia, no desaparece

El Project Manager de un proyecto de IA no necesita convertirse en Data Scientist. Pero sí necesita aprender a hacer las preguntas que antes daba por resueltas: ¿qué problema estamos resolviendo, realmente? ¿Qué significa éxito, en términos medibles? ¿Tenemos los datos adecuados, con la calidad y la frecuencia que el objetivo exige? ¿Qué margen de error es aceptable para este caso? ¿Cómo se va a evaluar el resultado antes de confiar en él? ¿Quién lo valida? ¿Cómo se va a operar y monitorear después del lanzamiento? ¿Está produciendo valor real, o solo funcionando?

Dicho de otra forma: el Project Manager de IA no necesita saber entrenar un modelo. Necesita saber reconocer cuándo el proyecto todavía no está listo para entrenarlo. Ese criterio —saber frenar a tiempo, o regresar una fase— vale más que cualquier certificación técnica, porque protege el presupuesto, la credibilidad del equipo y la confianza de quienes esperan resultados.

Muchos de los mayores obstáculos de un proyecto de IA no están en el algoritmo. Están en los datos, en la confianza que genera (o no) la solución, en la adopción real por parte de los usuarios, en el gobierno del proyecto y en procesos que no estaban pensados para convivir con un sistema que aprende y cambia.

La misma lógica aplica a lo pequeño

Este razonamiento no es exclusivo de proyectos industriales de gran escala. Aplica también a soluciones puntuales, como una herramienta de transcripción de audio.

La pregunta equivocada es "¿qué modelo de speech-to-text utilizamos?". La pregunta correcta es "¿qué necesita obtener realmente el usuario de esa grabación?". No es lo mismo transcribir una reunión para archivarla que transcribirla para extraer decisiones y tareas accionables. El objetivo define la herramienta, no al revés.

Con esa lógica nació ELISA Transcribe, pensada para convertir archivos de audio en contenido textual que pueda volver a utilizarse. El valor no está únicamente en pasar audio a texto: está en liberar información que antes quedaba atrapada dentro de una grabación y que nadie volvía a revisar. Hoy está disponible una prueba gratuita para audios de hasta 10 minutos, para quien quiera comprobar esa diferencia con un caso propio.

Al final, la pregunta que decide si un proyecto de IA prospera no es qué tan potente es el modelo disponible. Es si alguien se detuvo a preguntar, antes de tocar la tecnología, qué problema real se está resolviendo.

Referencia: Este artículo toma como punto de partida algunas ideas y casos presentados en el webinar de PMI “From Learning to Practice: Applying the CPMAI Methodology on Real-World AI Projects”. A partir de ellos desarrollo una reflexión propia sobre cómo abordar proyectos de IA desde el problema de negocio, los datos y la generación de valor.