Una prueba de concepto sirve solo si resuelve la siguiente decisión de producción. Casi ninguna lo hace. Demuestra que un modelo puede hacer algo interesante en una demo acotada y deja al equipo sin dueño operativo, sin release gate (la condición que un cambio debe cumplir para salir a producción) y sin una sola evidencia de que un usuario real confiaría en el flujo.
El remedio no es alargar la PoC. Es meter a un usuario real dentro del sistema en la semana 2.
El usuario de la semana 2 te cambia la arquitectura
Cuando alguien real toca el sistema temprano, la pregunta deja de ser «¿puede el modelo hacerlo?» y pasa a ser «¿aguanta este flujo nuestras restricciones de verdad?».
Ahí es donde aparecen las decisiones de producto que valen algo:
- Qué paso sigue necesitando aprobación humana.
- Qué output generado necesita cita, historial de edición o vía de rechazo.
- Qué campo tiene que ir estructurado porque hay sistemas río abajo que dependen de él.
- Qué presupuesto de latencia importa de verdad, porque el usuario está esperando dentro del flujo.
- Qué fallo resulta incómodo y qué fallo resulta inaceptable.
Todo eso es arquitectura. No puede esperar a la semana del release.
La trampa del agente autónomo
La demo de IA más seductora es la del botón único: subes el archivo y recibes el resultado terminado. Y es justo ahí donde los equipos suelen quitar al humano que hacía defendible el output.
En respuestas comerciales, cuestionarios de seguridad, flujos legales, flujos clínicos, operaciones financieras y aprobaciones internas, el producto no es el agente. El producto es la vía de revisión que lo rodea: quién aprueba, quién edita, quién escala, qué queda registrado y qué no puede salir del sistema.
Si esa vía de revisión no está en la PoC, la PoC está esquivando el producto real.
Qué exigimos antes de seguir con un build
Al cerrar el discovery queremos tres cosas por escrito:
- El primer usuario real y el flujo que va a probar.
- Los casos del eval (la suite con la que decides si el sistema pasa) que bloquean un release.
- La decisión operativa que esperamos aprender antes de la semana 3.
Si nadie puede nombrar esas tres cosas, el proyecto no está listo para el build. Y parar ahí sale más barato que entregar una demo que después nadie puede operar.