· Actualizado el 2026-10-16 · validación de producto
Plan de validación de un MVP de IA con criterios para parar
Un MVP de IA debe comprobar si una persona concreta puede completar un trabajo valioso con un sistema que el equipo pueda operar. Una respuesta del modelo en una demo no valida el producto. Antes de construir más, acordad qué evidencia justifica continuar, qué fallo se puede corregir y qué haría que el equipo parase.
Esta guía se dirige a una persona fundadora y un equipo de producto que prueban una función de IA acotada. Distingue la evidencia de uso de las pruebas de calidad del modelo y reserva una vía de revisión humana cuando haya incertidumbre.
1. Escribe la hipótesis de producto
Resume en una frase quién usa el producto, qué trabajo quiere hacer y qué beneficio espera: «Cuando [persona usuaria] está en [situación], puede [completar tarea] con [mejora medible]». Anota la solución provisional actual y quién es responsable del problema. Si el equipo no puede identificar una persona usuaria real, una tarea repetible y una referencia para comparar, pausa el desarrollo y aprende primero sobre la necesidad.
Define también los límites: qué puede hacer la función, qué decisión nunca debe tomar, qué datos necesita y quién responde cuando falla. Mantén permisos, pagos, encaminamiento y confirmación final como pasos deterministas salvo que el caso de producto exija otra cosa.
2. Prueba el flujo antes de ampliar el desarrollo
Usa el prototipo más pequeño que permita comprobar el supuesto de mayor riesgo. Puede ser una interfaz clicable, una integración limitada o una prueba asistida por una persona. Si alguien trabaja detrás de la interfaz, díselo a quienes participan: una prueba tipo concierge solo aporta evidencia válida si se explica qué está automatizado.
Invita a personas parecidas a quienes usarían el producto y dales tareas realistas sin guiarles hasta la respuesta. Observa si terminan, dónde dudan, qué corrigen y si vuelven a elegir el flujo. Una opinión favorable en una entrevista es una señal más débil que el uso observado de la tarea real.
3. Prepara casos representativos de evaluación
Reúne ejemplos del trabajo concreto y elimina los datos personales que no sean necesarios. Incluye algo más que casos fáciles:
- entradas normales que se espera que la función resuelva;
- entradas ambiguas y campos ausentes;
- peticiones fuera de alcance e instrucciones contradictorias;
- casos donde una respuesta errónea tendría una consecuencia relevante;
- ejemplos de regresión que antes pasaban y deben volver a probarse tras cambiar prompt, modelo o datos.
Antes de probar, define qué es aceptable en cada caso: correcto, incompleto pero seguro, requiere revisión humana o debe rechazarse. Clasifica los errores por tipo en vez de mirar solo una nota global. Repite los mismos casos después de cada cambio y revisa los fallos nuevos antes de invitar a más usuarios.
4. Establece límites operativos y una alternativa
Hasta un MVP necesita límites de operación. Define el coste máximo por tarea y la expectativa de respuesta que encajan en el recorrido de uso. Decide qué campos de entrada y salida se conservan, quién puede revisarlos y cuándo se eliminan. Guarda solo la información necesaria para investigar un error.
Si falta evidencia o el resultado incumple los criterios, muestra una explicación útil y deriva la tarea a una persona o a una alternativa más sencilla. Permite pausar la función. No conviertas otra llamada al modelo —capaz de repetir el mismo error— en la única forma de recuperarse.
El perfil voluntario de IA generativa del NIST ofrece acciones de gestión de riesgos que pueden adaptarse durante el desarrollo y el uso. Es una referencia de planificación, no una certificación ni una prueba de que el producto sea seguro.
5. Acuerda criterios para continuar, revisar o parar
- Continuar: los casos representativos cumplen los criterios acordados, las personas usuarias completan el trabajo y el coste y la revisión caben en el producto.
- Revisar: el trabajo sigue siendo importante, pero hay un fallo concreto y acotado que se puede corregir. Cambia un supuesto cada vez y repite las mismas pruebas.
- Parar: las personas no necesitan ese flujo, la función no mejora de forma relevante una opción más sencilla, la ruta de datos necesaria no está aprobada o el equipo no puede ofrecer una alternativa segura y un responsable.
Registra la decisión junto con la evidencia y sus límites. Parar puede evitar que una demo débil se convierta en una obligación permanente. Una decisión de revisar debe especificar el siguiente experimento y qué resultado le pondría fin.
Nota de decisión reutilizable
- Hipótesis: persona, tarea y cambio esperado.
- Evidencia: quién probó el flujo, qué casos se usaron y qué ocurrió.
- Límites: fallos conocidos, frontera de coste o latencia y alternativa humana.
- Decisión: continuar, revisar o parar, con el motivo.
- Siguiente paso: una persona responsable, una prueba y la fecha de revisión.
Empieza por elegir un problema inicial acotado y consulta cómo avanzar sin atajos frágiles cuando la evidencia justifique construir. El menú de sprints y la página de contacto explican cómo conversar sobre un experimento de producto delimitado.