PoC, MVP y producto responden a tres preguntas distintas. La PoC pregunta si se puede hacer. El MVP pregunta si alguien lo usa y paga por ello. El producto pregunta si aguanta la escala con calidad y margen. Cuando una empresa pide "un MVP" queriendo saber si la tecnología funciona, o aprueba "una PoC" esperando usuarios reales en producción, el problema empieza antes de la primera línea de código: el presupuesto, el plazo y las expectativas se construyeron para la pregunta equivocada.
En proyectos de IA la confusión sale más cara, porque la distancia entre una demo convincente y un sistema fiable es mayor que en el software tradicional. Un modelo que acierta 20 preguntas de prueba delante de la dirección parece listo. No lo está.
PoC: ¿se puede hacer?
La prueba de concepto responde a una pregunta técnica y de negocio bien acotada: ¿funciona este enfoque con nuestros datos y con un coste aceptable? No necesita una interfaz pulida, ni inicio de sesión, ni soportar mil usuarios. Necesita datos reales (o representativos), un criterio de éxito escrito de antemano y una estimación honesta de cuánto costaría en producción.
Lo que entrega una PoC es una decisión, no un sistema. La respuesta correcta puede ser "descartar", y eso es bueno: descubrir en cuatro semanas que la idea no se paga es mucho más barato que descubrirlo en un año. Gartner pronosticó en 2024 que al menos el 30% de los proyectos de IA generativa se abandonarían tras la PoC antes de finales de 2025, por datos de mala calidad, riesgos mal controlados, costes crecientes y un valor poco claro. Una buena PoC existe para sacar a la luz esos cuatro problemas pronto.
Duración típica: de 3 a 6 semanas. Quién la usa: el equipo del proyecto y algunos expertos del negocio. Error habitual: tratar la demo de la PoC como un producto casi terminado.
MVP: ¿alguien lo usa y paga?
Eric Ries, que popularizó el término, define el MVP como la versión de un nuevo producto que permite a un equipo reunir la mayor cantidad de aprendizaje validado sobre los clientes con el menor esfuerzo (Startup Lessons Learned, 2009). La palabra clave es clientes. El MVP da por resuelta la viabilidad técnica y pone a prueba el comportamiento: ¿la gente lo adopta, vuelve, paga, cambia su forma de trabajar?
Eso exige usuarios reales, ajenos al equipo del proyecto, y el mínimo de producto para que la experiencia sea honesta. En IA incluye cosas que la PoC ignoró: qué hacer cuando el modelo no sabe la respuesta, una vía para que el usuario corrija el sistema y una monitorización básica de coste y calidad.
En una empresa, el "cliente" del MVP puede ser interno: el área de crédito, el equipo de atención. La pregunta es la misma: ¿lo usan sin que nadie les obligue?
Duración típica: de 2 a 4 meses. Quién lo usa: un grupo real y limitado de usuarios. Error habitual: llenar el MVP de funcionalidades y retrasar el aprendizaje que debía aportar.
Producto: ¿aguanta la escala con calidad y margen?
El producto da por validadas la tecnología y la demanda. La pregunta ahora es operativa y financiera: ¿funciona con diez o cien veces más usuarios igual que funcionó con pocos? ¿Se sostiene el margen cuando el coste del modelo crece con el volumen?
Aquí aparece la mayor parte del trabajo que nadie ve en la demo. El artículo Hidden Technical Debt in Machine Learning Systems, de ingenieros de Google (NeurIPS 2015), muestra que el código de machine learning es una parte pequeña de un sistema real, rodeada de recogida y validación de datos, configuración, monitorización, infraestructura de servicio y gestión de procesos. Con la IA generativa, la lista suma evaluación continua de respuestas, control del coste por token, protección frente a prompt injection y trazabilidad para auditoría.
Duración típica: continua. Quién lo usa: todos los usuarios previstos. Error habitual: escalar el código de la PoC en lugar de reconstruir lo que hay que reconstruir.
¿Y el piloto?
Muchas empresas usan una cuarta palabra: piloto. En la práctica, un piloto suele ser el MVP de una iniciativa interna, con usuarios reales de un área o unidad y un plazo definido. El nombre importa menos que la pregunta. Si el piloto tiene usuarios reales que lo usan en su trabajo diario, trátelo como un MVP, con criterios de adopción y de calidad. Si solo es el equipo del proyecto probando con datos reales, es una PoC con otro nombre, y debe terminar en una decisión, no en una ampliación automática. El riesgo más habitual es el piloto que nunca termina: sigue activo durante meses, con pocos usuarios, sin que nadie decida si se convierte en producto o se apaga.
Ejemplo hipotético: análisis de contratos en el departamento legal
El escenario siguiente es un ejemplo hipotético, construido para mostrar la diferencia entre etapas. No es un cliente.
Un departamento legal revisa unos 150 contratos de proveedores al mes. La idea es usar IA para extraer cláusulas de riesgo (penalizaciones, revisión de precios, jurisdicción, limitación de responsabilidad) y señalar desviaciones de la política interna.
En la PoC, el equipo toma 100 contratos ya revisados por abogados y mide si el modelo encuentra las mismas cláusulas. Criterio acordado: encontrar al menos el 90% de las cláusulas de riesgo, con un coste estimado inferior a 2 euros por contrato. Ningún abogado usa el sistema en su día a día. En cuatro semanas hay una decisión.
En el MVP, tres abogados empiezan a recibir el análisis de la IA antes de revisar cada contrato nuevo, durante dos meses. La pregunta cambia: ¿confían en él, revisan más rápido, piden seguir usándolo? Si vuelven a leer cada contrato desde cero, el MVP ha mostrado algo que la PoC nunca podría mostrar.
En el producto, el sistema da servicio a todo el departamento legal y está integrado en la herramienta de gestión de contratos, con cada análisis registrado para auditoría, la precisión monitorizada por tipo de contrato y un presupuesto mensual de modelo seguido por finanzas.
Observe que el mismo "sistema de análisis de contratos" tiene tres alcances, tres presupuestos y tres criterios de éxito distintos. Aprobar el presupuesto de producto antes de la PoC sería apostar a ciegas. Pedir el plazo de una PoC para el producto garantizaría un proyecto con retraso.
Cómo saber en qué etapa está
Responda en orden. El primer "no" le indica dónde está:
- ¿Se ha demostrado, con datos reales y un criterio escrito de antemano, que el enfoque funciona y que el coste en producción es aceptable? Si no, está en la PoC.
- ¿Hay usuarios reales, ajenos al equipo del proyecto, usando el sistema por voluntad propia desde hace al menos unas semanas? Si no, está en el MVP.
- ¿El sistema tiene monitorización de calidad y coste, un responsable con nombre, trazabilidad para auditoría y un plan para diez veces más volumen? Si no, está construyendo el producto, y todavía no ha llegado.
Checklist para la reunión de alcance
- La pregunta que debe responder esta etapa está escrita en una frase.
- El criterio de éxito tiene un número y se acordó antes de empezar.
- El presupuesto y el plazo corresponden a esta etapa, no a la siguiente.
- Está definido qué pasa si el resultado es negativo.
- Quien aprueba la siguiente etapa sabe que tendrá que decidir, y cuándo.
Siguiente paso
En su próxima reunión sobre un proyecto de IA, antes de hablar de precio, escriba la pregunta que la etapa tiene que responder. Esa pregunta define el alcance correcto.
Por eso ofrecemos las etapas como servicios separados. La PoC Factory pone a prueba una hipótesis en 3 a 6 semanas y termina con un Decision Package. MVP As a Service construye un MVP ajustado para fundadores que ya han validado la idea y necesitan una ejecución disciplinada. Y nuestra metodología muestra cómo se pasa de una etapa a la siguiente.