POC vs. producción: qué preguntas responde cada una

El error más caro: confundir validación técnica con validación de negocio

Muchas PYMEs llegan a una prueba de concepto (POC) esperando que les diga si la automatización va a funcionar en su empresa. Es una expectativa razonable, pero incorrecta. Una POC bien diseñada responde preguntas técnicas concretas. Las preguntas de negocio —si el sistema se adoptará, si reducirá carga real, si el ROI se sostiene— solo tienen respuesta en producción, con usuarios reales y datos reales.

Confundir ambos planos es el origen de muchos proyectos que se aprueban con entusiasmo tras una demo y mueren en silencio tres meses después.

Qué preguntas sí responde una POC corta

Una POC de alcance limitado —días o pocas semanas, no meses— puede responder con fiabilidad estas preguntas:

• ¿El modelo entiende el dominio? Si el vocabulario técnico de tu sector, tus productos o tu legislación produce respuestas coherentes o produce basura.
• ¿La calidad del dato es suficiente? Los documentos internos que tienes —manuales, FAQs, contratos— están en un estado que permite indexarlos y recuperarlos bien, o requieren limpieza previa.
• ¿La arquitectura elegida es viable? Si el enfoque técnico seleccionado —RAG, agente, flujo determinista— puede manejar los casos de uso prioritarios sin forzar el sistema.
• ¿Hay casos límite que rompen el sistema? Preguntas ambiguas, documentos contradictorios, idiomas mezclados: la POC los expone en entorno controlado, no delante del cliente.
• ¿El coste de inferencia es razonable? Con un volumen simulado puedes estimar qué gasto mensual genera el sistema antes de comprometerte.

Qué preguntas NO puede responder ninguna POC

Aquí está el territorio que muchos vendedores de IA prefieren no delimitar:

• ¿Lo usará el equipo? La adopción depende de hábitos, de si el sistema encaja en el flujo real de trabajo y de si la respuesta es suficientemente buena para que alguien deje de hacer lo que hacía antes. Ninguna demo lo predice.
• ¿Aguanta el volumen real? Simular carga es útil, pero no equivale a cien usuarios simultáneos con patrones de uso impredecibles y picos en momentos que nadie anticipó.
• ¿Cómo se comporta cuando los datos cambian? Los precios se actualizan, los procedimientos se modifican, los documentos se añaden. La POC trabaja con un snapshot estático. Producción es un organismo vivo.
• ¿Cuánto cuesta mantenerlo? El coste real incluye actualizaciones de la base de conocimiento, revisión de respuestas incorrectas, ajustes cuando el modelo de base cambia de versión. Eso no aparece en una POC.
• ¿Qué pasa cuando falla? Los modos de fallo reales —una pregunta que el sistema no debería responder y responde con seguridad; un dato desactualizado que nadie detecta— solo emergen con uso continuado.

El patrón que suele fallar: la POC como argumento de venta

Imagina una empresa de servicios profesionales que aprueba un chatbot interno tras una POC de dos semanas. La demo funciona bien con veinte documentos curados. Seis meses después, el sistema tiene trescientos documentos, la mitad desactualizados, y el equipo ha dejado de usarlo porque las respuestas mezclan versiones antiguas y nuevas de los procedimientos.

El problema no era la tecnología. Era que la POC nunca evaluó el proceso de mantenimiento de la base de conocimiento, porque ese proceso no existía. La POC respondió "¿funciona RAG con estos documentos?" y nadie preguntó "¿quién actualiza los documentos y cuándo?".

Es habitual que el alcance de la POC lo defina quien vende el sistema, no quien lo va a operar. El resultado es una validación técnica impecable de algo que no representa el problema real.

Cómo diseñar una POC que no te engañe

Antes de aprobar cualquier prueba de concepto, conviene tener respuesta a estas preguntas:

1. ¿Qué decisión concreta tomamos al terminar la POC? Si la respuesta es vaga ("ver si funciona"), la POC no está bien definida.
2. ¿Con qué datos trabajamos? Datos reales en el estado en que están hoy, no datos limpios preparados para la demo.
3. ¿Qué criterio de éxito tiene cada objetivo? No "responde bien", sino "responde correctamente en X de cada Y casos de prueba definidos antes de empezar".
4. ¿Qué queda fuera del alcance y cómo se valida después? La lista de lo que no se prueba es tan importante como la de lo que sí se prueba.
5. ¿Quién va a operar el sistema en producción y está en la sala durante la POC? Si la persona que lo va a mantener no participa en la validación, la POC mide la opinión del equipo técnico, no la viabilidad operativa.

La secuencia lógica: POC, piloto, producción

Una POC no es el paso anterior a producción. Es el paso anterior a un piloto. La secuencia correcta tiene tres etapas con preguntas distintas:

• POC: ¿Es técnicamente viable con estos datos y esta arquitectura?
• Piloto: ¿Funciona con usuarios reales en condiciones reales durante un periodo acotado?
• Producción: ¿Se sostiene en el tiempo, escala y se mantiene sin coste desproporcionado?

Saltarse el piloto es el error más frecuente. La presión por "pasar a producción rápido" convierte una validación técnica en un despliegue prematuro. Y cuando el sistema falla en producción, la conclusión suele ser "la IA no funciona", cuando la conclusión correcta sería "la validación fue insuficiente".

Lo que sí puedes exigir al terminar una POC

Al cerrar una prueba de concepto, deberías poder responder con evidencia —no con intuición— a estas tres preguntas: la arquitectura elegida maneja los casos de uso prioritarios sin forzarla; los datos disponibles son suficientes para arrancar o hay un plan concreto para los que no lo son; el coste técnico estimado está dentro del rango que hace viable el proyecto.

Todo lo demás —adopción, ROI, escalabilidad, mantenimiento— es una hipótesis razonable, no una certeza. Tratarla como certeza es donde empiezan los proyectos que fracasan con buenas demos.