MVP con inteligencia artificial: qué cambia y cómo acotarlo

Lo que cambia cuando el MVP lleva IA dentro

Un producto mínimo viable clásico se construye para resolver una incertidumbre de demanda: ¿existe el problema, la solución encaja, alguien la usará? El código hace lo que se le pidió; lo que está en duda es si a alguien le importa.

Un MVP con inteligencia artificial arrastra una segunda incertidumbre, y de otra naturaleza: ¿el sistema acierta lo suficiente para que el proceso mejore? Esa parte no se sabe hasta que se prueba con casos reales, no depende solo de decisiones de diseño, y no se resuelve programando mejor. Es una incertidumbre de rendimiento, y hay que atacarla de forma explícita porque no se disuelve sola.

De ahí salen dos consecuencias prácticas que ordenan todo el proyecto. La primera: el orden se invierte, y hay que evaluar antes de construir la experiencia alrededor. La segunda: existe un resultado legítimo que un MVP clásico casi nunca contempla, que es «funciona, pero no lo bastante bien para este proceso». Contemplarlo desde el principio es lo que separa un aprendizaje barato de un fracaso caro.

El criterio de aceptación se acuerda antes

Esta es la conversación que decide el proyecto y la que más se pospone. Antes de construir hay que dejar por escrito qué significa que el sistema funcione, en términos que el negocio entienda:

• Qué es un acierto. Suena obvio hasta que se intenta escribir. En una clasificación puede ser inequívoco; en una redacción o un resumen, «acierto» significa que alguien lo aprueba sin reescribirlo, y hay que decidir quién es ese alguien.
• Qué error se tolera y cuál no. Los dos errores casi nunca cuestan lo mismo. Dejar pasar un caso que había que revisar y marcar uno que no lo necesitaba tienen consecuencias distintas, y el sistema se calibra hacia el lado barato.
• Contra qué se compara. El punto de referencia es cómo se hace hoy, medido. Sin línea base la conversación posterior será una discusión de impresiones, exactamente el mismo problema que hace imposible calcular el retorno de un proyecto de IA.
• Qué pasa cuando el sistema no está seguro. Un MVP que solo tiene una salida está mal diseñado. Debe poder decir «no lo sé» y derivar a una persona; el porcentaje de casos que deriva es una decisión de negocio, no un defecto.

Una advertencia sobre los números: no existe un umbral de acierto válido para todos los casos, y desconfiaríamos de cualquiera que lo ofrezca antes de conocer el proceso. Depende por completo de lo que cuesta el error y de lo bien que se haga hoy la tarea. Un sistema que acierta menos que una persona puede ser perfectamente útil si revisa un volumen que nadie revisaba, y otro que acierta mucho puede ser inaceptable si el error que comete es irreversible.

El conjunto de evaluación es el entregable que nadie pide

Si el MVP produce una sola cosa duradera, que sea esta: un conjunto de casos reales, con la respuesta correcta acordada por quien sabe del negocio. No hace falta que sea enorme; hace falta que sea real, que incluya los casos raros y que esté acordado.

Sirve para tres cosas, y las tres siguen valiendo mucho después del MVP. Permite comparar opciones sobre el mismo terreno en vez de por sensación —que es la única forma seria de responder a cuál es la mejor IA para tu caso—. Permite detectar si algo empeora cuando se cambia una pieza. Y obliga a la conversación más útil de todo el proyecto: la que ocurre cuando dos personas del negocio no se ponen de acuerdo en cuál era la respuesta correcta de un caso. Ese desacuerdo, que aparece siempre, es información valiosa sobre un proceso que nadie había escrito del todo.

Construirlo lleva tiempo de gente que sabe, y por eso se recorta en los pliegos. Es un mal recorte: sin él, la única forma de saber si el sistema funciona es la opinión de quien vio la demo.

Qué entra y qué no en el alcance

Dentro del MVP	Fuera, hasta que el criterio se cumpla
Un caso de uso, un tipo de decisión, un flujo	Varios casos «porque el sistema ya está»
Los datos que ese caso necesita, en su estado real	Un proyecto de unificación de datos completo
Una salida de baja confianza que deriva a una persona	Automatización de punta a punta sin supervisión
Registro de qué decidió el sistema y por qué	Cuadros de mando y analítica del uso
Una integración de lectura con los sistemas implicados	Escritura automática en el sistema de producción
Un grupo de usuarios reales acotado	Despliegue general a toda la organización

La columna derecha no es una lista de cosas malas: es una lista de cosas que solo se justifican cuando ya se sabe que el núcleo funciona. La quinta fila merece énfasis porque es la que más riesgo concentra: leer para decidir y escribir para actuar son dos proyectos con perfiles distintos, y en un sistema heredado esa frontera es todavía más marcada — la desarrollamos en cómo integrar IA en un sistema legacy.

La secuencia de un MVP con IA

• 1 · Acordar el criterioQué es acertar, qué error duele más, contra qué se compara y qué pasa cuando el sistema duda. Sin esto, lo demás no se puede juzgar.
• 2 · Reunir casos realesCon la respuesta correcta acordada. Incluidos los casos raros, que son los que rompen el sistema en producción.
• 3 · Probar el núcleo, sin producto alrededorLa pregunta es si acierta lo suficiente. La interfaz, la integración y el pulido vienen después y no cambian la respuesta.
• 4 · Construir el mínimo alrededorSolo si el paso 3 pasa el criterio. Interfaz, integración de lectura, registro y la ruta de derivación a una persona.
• 5 · Producción acotadaUsuarios reales, volumen limitado, medición contra la línea base y una forma clara de apagarlo.
• Salida legítima en cada pasoParar en el 3 con un «no llega» es un buen resultado: cuesta semanas en vez de trimestres.

El paso 3 es el que más se salta, y es el único que responde a la pregunta que motivaba el MVP.

El MVP manual: cuando lo correcto es no poner IA todavía

Hay una situación frecuente en la que el mejor primer paso es hacer el proceso a mano, de forma deliberada y con la intención de sustituirlo después: cuando el proceso no está definido lo bastante como para poder decir qué sería acertar.

Suena a retroceso y no lo es. Hacerlo a mano durante unas semanas produce exactamente lo que falta: el criterio explícito, los casos de ejemplo con su respuesta correcta y una medida honesta de cuánto cuesta hoy. Con eso, el MVP con IA se plantea en la mitad de tiempo y con mucha menos discusión.

Se aplica sobre todo en tres situaciones: cuando el volumen todavía es bajo y automatizar no compensa; cuando el proceso cambia cada pocas semanas y cualquier sistema quedaría desfasado; y cuando nadie sabe articular por qué una decisión es correcta, que es la señal más clara de que aún no hay nada que enseñar a un sistema. Es la misma lógica de priorización que ordena qué procesos conviene automatizar primero: la madurez del proceso pesa tanto como el volumen.

Cómo se sabe que el MVP ha terminado

Un MVP con IA no termina cuando la funcionalidad está construida, sino cuando se ha respondido a la pregunta que lo motivaba. Termina bien —en cualquiera de sus tres finales— cuando:

• Hay una respuesta medida sobre casos reales, no sobre ejemplos elegidos.
• Se sabe qué casos falla y si esos fallos son tolerables para el proceso.
• Está medido cuánto deriva a una persona y si ese volumen es asumible.
• Se puede comparar con la línea base de cómo se hacía antes.
• Está claro qué haría falta para llevarlo a producción completa, con su coste.
• El conjunto de evaluación queda como activo reutilizable.
• La decisión de seguir, replantear o parar está tomada y escrita.

Los tres finales son igual de válidos: sigue adelante, se replantea con otro alcance, o se para. El único mal final es el que casi siempre ocurre en la práctica: que el MVP se quede funcionando indefinidamente en un limbo, usado por tres personas, sin haberse evaluado nunca contra un criterio y sin que nadie se atreva a apagarlo.

Del MVP a producción

El salto no es una fase de pulido. Producción exige fiabilidad, seguridad, mantenimiento y una respuesta clara para el día en que el sistema no esté disponible o se comporte peor de lo esperado. También exige decidir qué acciones puede ejecutar solo y cuáles necesitan aprobación, con el criterio de impacto y reversibilidad que aplicamos siempre y que desarrollamos en cuándo una decisión de IA necesita revisión humana.

Y exige presupuestar el mantenimiento desde el principio. Un sistema con IA se degrada cuando cambia aquello sobre lo que decide —los datos, el proceso, el tipo de caso que llega— y esa degradación es silenciosa: sigue devolviendo respuestas con la misma seguridad. Sin una revisión periódica contra el conjunto de evaluación, nadie se entera hasta que alguien se queja. Es el punto donde un MVP deja de ser un experimento y se convierte en parte de cómo se implanta la IA en una empresa.

Siguiente paso

Definir el criterio, construir el conjunto de evaluación y llevar un MVP con IA a producción acotada es lo que hacemos en Productos digitales e ingeniería de producto con IA. Si el proyecto forma parte de un rediseño más amplio de cómo trabaja el equipo, se aborda como Transformación con IA. Cuéntanos tu reto y acotamos el primer caso contigo.