zoff.tech

31 mar 2026

No hacemos PoCs huérfanas: un usuario real entra al sistema en la semana 2

Una PoC sin camino a producción esconde las decisiones difíciles. Un usuario en semana 2 las fuerza a aparecer cuando la arquitectura todavía es barata de cambiar.

Una prueba de concepto sirve solo cuando prueba la siguiente decisión de producción. La mayoría no lo hace. Prueba que un modelo puede hacer algo interesante en un demo acotado, pero deja al equipo sin dueño operativo, sin gate de release y sin evidencia de que un usuario real confiaría en el flujo.

La solución no es una PoC más larga. La solución es poner un usuario real dentro del sistema en la semana 2.

El usuario de semana 2 cambia la arquitectura

Cuando un usuario real toca el sistema temprano, la conversación deja de ser "¿puede hacerlo el modelo?" y pasa a ser "¿puede este flujo sobrevivir nuestras restricciones reales?"

Ahí aparecen las decisiones de producto útiles:

  • Qué paso todavía necesita aprobación humana.
  • Qué output generado necesita cita, historial de edición o ruta de rechazo.
  • Qué campo debe ser estructurado porque sistemas posteriores dependen de él.
  • Qué presupuesto de latencia importa porque el usuario está esperando dentro del flujo.
  • Qué falla es incómoda y qué falla es inaceptable.

Esas decisiones son arquitectura. No deben esperar hasta la semana de lanzamiento.

La trampa del agente autónomo

El demo de IA más seductor es el flujo de un botón: sube el archivo, recibe el resultado terminado. También es donde los equipos suelen quitar al humano que hace 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 ruta de revisión alrededor del agente: quién puede aprobar, quién puede editar, quién puede escalar, qué queda registrado y qué no puede salir del sistema.

Si esa ruta de revisión no está en la PoC, la PoC está evitando el producto real.

Qué exigimos antes de continuar un build

Al final de discovery queremos tres cosas por escrito:

  • El primer usuario real y el flujo que va a probar.
  • Los casos de evaluación que bloquean un release.
  • La decisión operativa que esperamos aprender antes de la semana 3.

Si eso no puede nombrarse, el proyecto no está listo para build. Detenerse ahí es más barato que enviar un demo que nadie puede operar.