Un POC exitoso no es una señal de producto. Es una señal de que el equipo técnico entendió la tarea. El problema aparece cuando ese POC tiene que operar dentro de un proceso real, con usuarios reales, datos reales y reglas reales.
Los cuatro cuellos de botella que aparecen siempre
1. Integración con sistemas legacy. El POC corrió contra un CSV o un sandbox. Producción requiere conectarse al ERP, al CRM, al sistema de tickets. Cada integración tiene su propio ritmo de autenticación, rate limits y convenciones. Cuando el proyecto arranca sin diseñar las integraciones, esta fase puede consumir el 60% del presupuesto.
2. Gobierno y permisos. En el POC, nadie preguntó quién puede ver qué. En producción, el agente tiene que respetar roles, filtros por unidad de negocio, y reglas de retención. Si el diseño no previó esto, no es un ajuste: es rediseñar.
3. Observabilidad operativa. Una demo con logs de consola no es producción. Producción necesita responder "qué hizo el agente el viernes a las 16:47 cuando el cliente reclamó." Sin trazas por decisión, el equipo de soporte no puede investigar nada.
4. Gestión del cambio. El agente no reemplaza un proceso: cambia cómo trabaja la gente. Cuando nadie se ocupa de formar al equipo operativo, el agente recibe quejas en vez de feedback constructivo, y muere por falta de uso.
Qué hacer distinto desde el día uno
- Incluir al menos una integración real en el scope del POC. No a nivel demo: a nivel "el dato entra y sale por el canal que usará en producción."
- Definir la matriz RACI antes de la implementación técnica. Quién decide qué, con qué permiso, y quién se queda con la responsabilidad final.
- Instalar observabilidad desde el primer commit. No es un nice-to-have: es el instrumento con el que se defiende el valor frente al sponsor.
- Planear la gestión del cambio en paralelo. El equipo operativo tiene que ver el agente como aliado, no como amenaza.
Un POC bien diseñado no es el que funciona en la demo. Es el que ya sabe cómo va a sobrevivir seis meses después.