¿Qué es una prueba de concepto (PoC) en un proyecto de IA?

¿Qué valida una prueba de concepto?

Valida una pregunta concreta: ¿puede esta solución hacer este trabajo, con nuestros datos, con la calidad que necesitamos y a un costo razonable? No busca impresionar en una demostración, sino producir evidencia para decidir. Conviene distinguirla de las etapas que vienen después:

¿Cómo se diseña una que sirva?

1. Un proceso y un indicador. Por ejemplo, facturas de proveedores cruzadas con su orden de compra sin intervención humana.
2. Una línea base medida. Cómo se hace hoy, cuánto tarda y cuántos errores tiene.
3. Datos reales, preparados con cuidado. Si incluyen datos personales, seudonimizados.
4. Un plazo corto y cerrado. Semanas, no trimestres.
5. Un criterio de salida firmado. Qué resultado justifica pasar al piloto o a producción y cuál obliga a detener.
6. Un camino a producción. Desde el inicio se verifica cómo se conectará con el ERP y quién será el dueño del proceso.

Un ejemplo en una empresa ecuatoriana

Una importadora de Quito quiere saber si la inteligencia artificial puede cruzar las facturas electrónicas de sus proveedores con las órdenes de compra. Toma tres meses de XML reales y las órdenes del ERP, define como indicador el porcentaje de facturas cruzadas correctamente sin intervención y fija un criterio: pasar a producción solo si el resultado supera un nivel acordado y ninguna factura con diferencias se aprueba por error. En pocas semanas tiene una respuesta con números, no una opinión.

¿Qué exige la LOPDP si la prueba usa datos reales?

Una prueba con datos personales reales es un tratamiento de datos, aunque dure pocas semanas. La LOPDP obliga a hacer una evaluación de impacto antes de empezar en ciertos casos, como la evaluación sistemática de aspectos personales basada en tratamiento automatizado que sirva para tomar decisiones con efectos jurídicos, o el tratamiento a gran escala de categorías especiales de datos (artículo 42). Y la norma de la Superintendencia sobre inteligencia artificial, Resolución SPDP-SPD-2026-0009-R, pide la gestión de riesgos y la evaluación de impacto antes de desarrollar un sistema que trate datos personales; su reforma, firmada en septiembre de 2026, precisa que la evaluación se hace cuando corresponda. La guía de evaluación de impacto explica cuándo es obligatoria.

Errores comunes

• El piloto eterno. Sin criterio de salida, la prueba se extiende y nunca se decide.
• Datos de juguete. Una prueba con diez documentos perfectos no anticipa lo que pasará con miles de casos reales.
• Medir el éxito por la demostración. Lo que cuenta es el indicador contra la línea base.
• Nadie del negocio es dueño. Si el área usuaria no participa, el resultado no se adopta.
• Ignorar la integración. Una solución que funciona aislada puede ser inviable cuando hay que conectarla al ERP.

Relación con otros términos

Las razones por las que tantos proyectos se quedan en esta etapa están en la guía de por qué fracasan los proyectos de inteligencia artificial. En Advise, en lugar de una prueba aislada, el objetivo es tener el primer proceso en producción en 60 días: el reloj arranca con la entrega de accesos y el primer flujo con datos se ve dentro de los 15 días siguientes.