Qué es un MVP con IA y en qué se diferencia de un piloto

El problema: llamar MVP a un producto incompleto

En muchas empresas, "MVP" se volvió sinónimo de "versión apurada". El equipo de producto arma un prototipo con la fecha del comité de dirección como único criterio de corte, no con un criterio de negocio. Entra todo lo que alcanzaron a programar, sale todo lo que no. El resultado es un artefacto que parece completo por fuera (tiene inicio de sesión, tiene panel de control, tiene notificaciones) pero que nadie validó de verdad con un usuario que pagara o dependiera de él.

Ese patrón ya era un problema antes de la IA generativa. Con IA generativa es un problema distinto de magnitud. Un formulario web mal terminado falla de forma visible: el botón no responde, la página se cae, el usuario ve el error y reintenta. Un modelo de lenguaje mal ajustado falla con la misma confianza con la que acierta. Responde mal con el mismo tono seguro con el que responde bien, y el usuario que recibió una respuesta incorrecta sobre su crédito, su pedido o su diagnóstico no vuelve a confiar en el sistema aunque el error se corrija al día siguiente.

He visto el mismo patrón en una aseguradora mediana en Colombia y en una cadena de retail en México: ambas lanzaron "MVPs" de atención al cliente con IA que en realidad eran productos incompletos con una capa de generación de lenguaje encima, sin monitoreo de qué tan seguido fallaban ni un plan para cuando fallaran. El sponsor ejecutivo perdió confianza en semanas, no en meses, y el proyecto quedó etiquetado como "la IA no funcionó" cuando lo que no funcionó fue la definición de mínimo.

Qué es un MVP con IA, en criterio de negocio

Antes de construir nada, vale la pena separar dos preguntas que el equipo suele mezclar: qué tan chico es el producto (alcance) y qué tan bien funciona lo que sí construyeron (calidad). Un MVP recorta la primera variable, nunca la segunda. La versión mínima de un producto no es la versión con errores tolerados; es la versión con menos funciones, dirigida a menos usuarios o a un solo caso de uso, pero que en ese terreno acotado funciona lo suficientemente bien como para que alguien la use en serio.

La prueba de fuego de un MVP no es que funcione en la demo, es que alguien afuera de la empresa lo usó, obtuvo un resultado real y ese resultado se puede medir o cobrar. Si todavía estás probando si la tecnología es capaz de resolver el problema, no tienes un MVP, tienes un experimento interno, y llamarlo MVP solo infla las expectativas del comité que lo aprobó.

Mínimo es alcance, no calidad

Recortar alcance significa decidir con qué parte del problema te vas a quedar, no cuánta tolerancia a fallos vas a aceptar. Un MVP de un asistente de cobranzas puede atender un solo tipo de cliente, un solo canal y un solo motivo de consulta, y aun así responder con exactitud en ese terreno reducido. Eso es mínimo bien hecho: menos superficie, misma exigencia de calidad sobre esa superficie.

Qué sí se puede recortar en un MVP

• El número de casos de uso: un solo motivo de consulta o de proceso, no los diez que el área soñaba automatizar.
• El número de canales: solo WhatsApp o solo el portal web, no los tres al mismo tiempo.
• El nivel de personalización: reglas y respuestas genéricas para el segmento elegido, sin adaptarse todavía a cada perfil de cliente.
• La automatización de excepciones: los casos raros se derivan a una persona, en vez de intentar que el modelo los resuelva todos.
• La integración con sistemas periféricos: conectar solo el sistema que aporta el dato crítico, dejar el resto para después.

Lo que no se recorta es la exactitud dentro de ese terreno acotado, el manejo de los casos en que el modelo no sabe la respuesta, y la trazabilidad de qué contestó y por qué. Si el equipo recorta eso para llegar a la fecha del comité, no está construyendo un MVP: está construyendo una demo con fecha de caducidad.

El agravante propio de la IA generativa

El manual clásico de producto mínimo viable se escribió pensando en software determinista: un formulario, un flujo de pago, un panel de control. Ese software falla de forma binaria, funciona o no funciona, y el usuario lo nota de inmediato. Un sistema con IA generativa produce una salida probabilística: la misma pregunta puede responderse bien nueve veces y mal la décima, sin que nada en la interfaz avise que esa décima respuesta es la que falló.

Ese matiz cambia la definición de mínimo viable. Un MVP tradicional puede lanzarse con errores conocidos y una lista de pendientes, porque el usuario ve el error, lo reporta y sigue usando el producto. Un MVP con IA que falla con frecuencia no acumula una lista de pendientes, acumula desconfianza silenciosa: el usuario deja de preguntar, deja de usarlo, y no siempre avisa por qué.

Por eso un MVP que alucina o falla en una porción alta de sus respuestas no es mínimo viable con margen de mejora. Es no viable, aunque el resto del producto (inicio de sesión, diseño, integración) esté impecable. La confianza que un modelo generativo quema en las primeras interacciones es más cara de recuperar que la que quema un botón roto.

Definir viable cuando la salida es probabilística

Si la salida es probabilística, viable deja de ser una palabra de sentido común y necesita convertirse en un número y en un plan. Un número: qué porcentaje de respuestas correctas, o de respuestas seguras aunque sean incompletas, es el piso aceptable para el caso de uso elegido. Un plan: qué pasa exactamente cuando el sistema cae por debajo de ese piso en una interacción concreta.

Qué necesita quedar definido antes de lanzar

• Un piso de exactitud aceptable para el caso de uso, definido con el área de negocio, no solo con el equipo técnico.
• Una forma de detectar cuándo el modelo no está seguro de su respuesta, para no entregarla como si lo estuviera.
• Una ruta de salida hacia una persona o un proceso manual cuando el sistema no cumple el piso de confianza.
• Un registro de cada interacción que permita medir el error real una vez en producción, no solo en las pruebas de laboratorio.
• Un criterio de apagado: en qué condición se retira el MVP del contacto con usuarios reales hasta corregirlo.

Esto es, en el fondo, el mismo ejercicio que exige un buen PRD de un proyecto de IA (la guía de cómo escribir un PRD para un proyecto de IA lo detalla): obliga a escribir antes de programar qué significa que el sistema funcione y qué se hace cuando no funciona. La mayoría de los equipos que llaman MVP a un producto que en realidad no es viable se saltaron justo ese ejercicio: nunca escribieron el piso de calidad, solo escribieron la lista de funciones.

Dónde termina la POC, dónde termina el piloto, dónde empieza el MVP

El MVP no vive solo: es el tercer paso de una secuencia que casi siempre se salta o se atropella. La página sobre qué es una POC de IA responde una pregunta técnica puertas adentro: ¿esta tecnología es capaz de resolver este problema, en un entorno controlado, sin usuarios reales de por medio? La página sobre qué es un piloto de IA prueba esa capacidad con usuarios reales, pero en un terreno protegido, sin cobrar y sin comprometer todavía la operación completa. El MVP es el primer punto de la secuencia donde el producto entrega valor real y medible o cobrable, con usuarios que dependen de él aunque sea en un alcance chico.

Saltarse pasos es el error más caro de ver. Construir directo un "MVP" sin haber pasado por una POC que confirme que el modelo puede sostener la exactitud requerida es apostar el presupuesto completo a una hipótesis técnica sin probar. Y quedarse eternamente en modo piloto, sin nunca definir el punto en el que el producto ya debería cobrarse o medirse como negocio, es la otra cara del mismo problema: la empresa nunca sabe si lo que tiene sirve o no.

Antes de definir el alcance del MVP conviene tener ya resuelto el caso de uso de IA que se va a atacar (qué proceso, qué usuario, qué resultado), algo que la guía sobre qué es un caso de uso de IA desarrolla, y haber pasado, aunque sea de forma rápida, por la decisión de construir versus comprar. Un MVP no es el lugar para seguir debatiendo si conviene construir el modelo a la medida o partir de una herramienta existente; esa decisión debería estar tomada antes de escribir la primera línea del producto.

Mi criterio

Cuándo sí, cuándo no

No todo caso de uso está listo para saltar a un MVP, y no todo lo que hoy llaman MVP debería seguir llamándose así. Estas señales ayudan a distinguir un caso listo para construir de un caso que necesita volver a la fase anterior.

Señales de que sí es momento de construir un MVP con IA

• Ya pasaste por una POC o un piloto que confirmó, con datos, que el modelo sostiene un nivel de exactitud aceptable en ese caso de uso concreto.
• Hay un proceso de negocio real, con un dueño identificado, dispuesto a depender de este sistema para una porción de su operación.
• El equipo puede nombrar, con un número o con un criterio claro, cuál es el piso de calidad aceptable y qué pasa cuando el sistema queda por debajo.
• Existe una forma de derivar a una persona los casos que el modelo no debe resolver solo, y esa ruta ya está probada, no solo diseñada en un documento.
• Hay una manera de medir, con datos reales de uso, si el producto genera el resultado de negocio (ingreso, ahorro de tiempo, reducción de un costo) que justificó el proyecto.

Señales de que no es momento, o de que lo que tienes no es un MVP

• Nadie en el equipo puede decir qué porcentaje de respuestas del sistema son incorrectas, porque nunca lo midieron fuera del entorno de pruebas.
• El alcance creció durante la construcción en vez de reducirse: se sumaron casos de uso, canales o integraciones sobre la marcha.
• La fecha de lanzamiento la puso el comité de dirección, no el nivel de exactitud alcanzado por el sistema.
• No existe una ruta de salida hacia una persona cuando el modelo no está seguro de su respuesta.
• El proyecto todavía está resolviendo si la tecnología es capaz de hacer la tarea, esa pregunta corresponde a una POC, no a un MVP.

Cierre

El orden que sostiene cualquier proyecto de IA que funciona empieza en el dolor operativo, sigue en el proceso que hay que rediseñar, después en el dato que ese proceso necesita, y termina en la herramienta. Un MVP con IA mal planteado invierte ese orden: arranca eligiendo el modelo y la interfaz, y solo al final, cuando ya falló con usuarios reales, alguien pregunta qué proceso de negocio se suponía que iba a mejorar y con qué dato. Para cuando llega esa pregunta, ya se quemó presupuesto y, peor, se quemó la confianza del usuario que probó el producto y no volvió.

Un MVP con IA bien hecho es aburrido de describir: cubre poco, lo cubre con un nivel de exactitud que el negocio definió de antemano, y tiene un plan explícito para el momento en que falla, porque va a fallar. La ambición no está en la lista de funciones del lanzamiento; está en la disciplina de no ampliar esa lista hasta que la porción chica que sí se construyó demuestre, con datos de uso real, que merece crecer.