Qué es una prueba de concepto (POC) de IA

El dolor real detrás de una POC mal planteada

En una empresa de manufactura mediana en México, con línea de producción propia y control de calidad manual, el área de sistemas recibe una instrucción del directorio: necesitamos ver si la inteligencia artificial nos sirve para detectar fallas en las piezas antes de que salgan a planta. Nadie define qué significa ver si sirve. El proveedor que gana la conversación propone un ejercicio de tres semanas con quinientas fotos seleccionadas por el propio cliente, todas nítidas, todas con buena luz, todas del mismo ángulo. El resultado sale casi perfecto. La gerencia general aprueba presupuesto para una implementación completa antes de que nadie revise una sola foto tomada en condiciones reales de planta: polvo, luz variable, cámaras de celular de operarios distintos.

Seis meses después el sistema en producción falla el doble de lo prometido. No porque la tecnología no funcione, sino porque nunca se probó con los datos reales de la operación, sino con una muestra curada para que la demo se viera bien. Esa confusión, entre probar la tecnología y probar la operación, es la que más dinero le cuesta a las empresas que se meten a IA sin orden.

El segundo problema es de nombres. Un gerente llama POC a lo que en realidad es un piloto con usuarios reales, y otro llama POC a un desarrollo completo a medio terminar. Cuando el nombre de la fase no tiene un límite claro, el presupuesto tampoco lo tiene, y el proyecto se extiende sin que nadie pueda decir con certeza en qué momento se debía haber detenido o avanzado a la siguiente etapa.

Qué es exactamente una POC de IA

Una POC de IA no es un piloto chiquito ni una versión beta del producto final. Es, en criterio de negocio, la pregunta más barata y más rápida que se puede hacer antes de comprometer presupuesto serio: esto que quiero hacer, ¿es técnicamente posible con la información que yo realmente tengo, no con la información que me gustaría tener?

Esa definición tiene dos partes que casi nadie respeta en la práctica. La primera es corto: una POC que dura meses ya dejó de ser una POC, es otra cosa con otro nombre y otro presupuesto. La segunda es con tus datos: si el ejercicio se corrió con datos de ejemplo, con una muestra limpia o con un conjunto de datos genérico, no respondió la pregunta de tu empresa, respondió la pregunta genérica de si la tecnología existe en el mundo, algo que en la mayoría de los casos de lenguaje ya se sabe que sí.

Por eso una POC no mide adopción, no mide retorno, no mide si a los usuarios les gusta la herramienta. Mide una sola cosa: viabilidad técnica sobre tu información real, con tus excepciones, tus formatos inconsistentes y tu volumen real. Todo lo demás se prueba después, en otras fases del proyecto.

La pregunta que sí responde una POC

La pregunta que responde una POC es angosta a propósito, y esa angostura es la que le da valor. No pregunta si el proyecto conviene, ni si el equipo lo va a usar, ni cuánto cuesta operarlo en volumen. Pregunta, y solo pregunta, si el modelo puede leer, clasificar, extraer o generar lo que se necesita, partiendo de la información tal como existe hoy en la empresa: con campos vacíos, con nombres de cliente escritos de tres formas distintas, con documentos escaneados torcidos.

Lo que sí debe quedar claro al cerrar una POC

• Si el modelo logra un nivel de acierto aceptable sobre una muestra real y no curada de la operación.
• Qué tipo de casos falla sistemáticamente y por qué (formato, calidad de imagen, ambigüedad del texto, falta de contexto).
• Qué tan sucios están realmente los datos de la empresa una vez que alguien los mira de cerca.
• Si el esfuerzo de limpieza o de conexión a las fuentes es menor, similar o mayor al esfuerzo del modelo mismo.
• Si hay una razón técnica real para detener el proyecto ahí, antes de gastar en un piloto.

Las preguntas que una POC no responde

La lista de lo que una POC no contesta es más larga que la de lo que sí contesta, y ahí es donde más empresas se equivocan al leer un resultado. Un ejercicio técnico exitoso no dice nada sobre si el equipo va a cambiar su forma de trabajar, sobre si el costo de operar el modelo en volumen real es razonable, ni sobre si el proceso que rodea a la herramienta está listo para sostenerla.

• No responde si los usuarios van a adoptar la herramienta en su rutina diaria.
• No responde cuál es el retorno económico del proyecto ni en cuánto tiempo se recupera la inversión.
• No responde qué pasa cuando el volumen de casos se multiplica por diez o por cien.
• No responde si el proceso actual, el que rodea a la tarea que la IA ayuda a resolver, está en condiciones de sostener el cambio.
• No responde qué tan estable se mantiene el desempeño cuando cambian las condiciones de entrada con el tiempo.

Un retailer mediano en Chile vivió esta secuencia completa: una POC sobre clasificación automática de reclamos de clientes salió con un acierto alto y bien documentado. La gerencia lo tomó como aprobación para lanzar el sistema a todas las tiendas en un mes. Nadie había probado si el equipo de tienda, acostumbrado a resolver los reclamos por teléfono y de memoria, iba a cambiar su rutina para escribir el caso en el sistema nuevo. El modelo funcionaba; el proceso que lo rodeaba, no, y esa parte nunca la había medido la POC.

Confundir una POC exitosa con luz verde para escalar es el error que más caro sale. Esas preguntas restantes se responden en el piloto de IA (con usuarios reales, alcance acotado) o en el MVP con IA (con la versión mínima ya integrada al proceso), no en el experimento inicial.

La trampa comercial de la POC bonita

La trampa comercial más común en esta fase tiene un patrón repetido: el proveedor pide una muestra representativa para la POC, y la empresa entrega, sin mala intención, los mejores casos que tiene a la mano. Las facturas mejor escaneadas, los contratos con formato estándar, las conversaciones de soporte más claras. El resultado se ve espectacular porque se probó contra un escenario que no existe en la operación diaria.

• Pedir explícitamente los casos más feos, más antiguos y más mal capturados del archivo, no los mejores.
• Incluir los expedientes incompletos, los formatos legado y las excepciones que el equipo evita mostrar por vergüenza operativa.
• Exigir que la muestra la elija alguien de operación, no de sistemas ni del proveedor.
• Revisar el tamaño real de la muestra: cincuenta casos perfectos no prueban nada sobre miles de casos reales.
• Desconfiar de cualquier demo que no pueda fallar en vivo con un dato que tú mismo aportes en el momento.

Una empresa de seguros mediana en Perú vivió esta trampa completa: la POC de lectura de siniestros mostró un acierto altísimo sobre expedientes escaneados en escáner de oficina, y cuando entró en operación con fotos de celular tomadas por peritos en campo, el desempeño cayó a la mitad. El problema nunca fue el modelo, fue la muestra con la que se lo evaluó.

Cuándo no necesitas gastar en una POC

Hay un error simétrico al anterior, igual de caro: pagar por una POC cuando la respuesta técnica ya se conoce. Hoy, la mayoría de los casos de uso basados en lenguaje (leer texto, resumir, clasificar, responder sobre un documento) ya tienen una respuesta técnica conocida en la industria: sí es posible. Lo que está en duda casi nunca es la tecnología, es el proceso que la rodea: quién revisa, quién corrige, qué pasa cuando el modelo se equivoca, quién es dueño del dato.

• El caso de uso es de lectura, clasificación o generación de texto sobre información razonablemente estructurada.
• Ya existe un caso de uso de IA documentado, dentro o fuera de la empresa, resolviendo algo casi idéntico.
• La duda real es organizacional (quién aprueba, quién corrige) y no técnica.
• El equipo ya cuenta con un sandbox de IA donde probar ideas sin comprometer producción.
• El presupuesto de la POC alcanzaría para financiar directamente un piloto acotado con usuarios reales.

En esos casos, saltarse la POC y entrar directo a un piloto de IA con alcance limitado ahorra tiempo y dinero. El procedimiento detallado para correr una POC bien acotada, paso a paso, cuando sí corresponde hacerla, está en la guía de cómo hacer una POC de IA en dos semanas; acá no se repite ese proceso, solo el criterio de cuándo aplica.

Una empresa de logística mediana en Colombia pidió cotización para una POC de tres meses sobre lectura automática de guías de remisión, un caso de clasificación de texto y extracción de campos que ya está resuelto en la industria desde hace tiempo. La duda real de esa empresa no era técnica, era que nadie había decidido quién revisaba las excepciones ni qué pasaba con una guía ilegible. Esa empresa terminó gastando el presupuesto de la POC en un piloto de un mes con un área concreta, y llegó a una decisión operativa antes de lo que hubiera tardado el experimento técnico que no necesitaba.

Mi criterio

Cuándo sí correr una POC y cuándo no

Antes de aprobar o rechazar una POC de IA, conviene mirar señales concretas de la operación, no la simpatía del proveedor ni la calidad de la presentación.

Señales de que sí conviene correr una POC

• El caso de uso involucra datos propios con estructura o calidad dudosa (imágenes, audio, documentos heterogéneos) sobre los que nadie ha probado nada todavía.
• Ningún caso de uso similar y documentado existe en la industria del sector como referencia técnica.
• El costo del experimento es una fracción pequeña y acotada frente al costo de construir la solución completa.
• Hay desacuerdo interno real sobre si la tecnología puede o no con ese dato específico, no sobre si conviene usarla.
• El plazo y el entregable están definidos por escrito antes de empezar, con fecha de cierre y criterio de éxito técnico.

Señales de que no necesitas una POC (salta directo a otra fase)

• El caso de uso es de lectura o generación de texto sobre información razonablemente estructurada, ya resuelto en el mercado para casos similares.
• La verdadera duda es de proceso o de personas (quién aprueba, quién corrige, quién es dueño del dato), no de tecnología.
• Ya existe un sandbox de IA interno donde el equipo puede probar la idea sin gastar en un proveedor externo.
• El presupuesto disponible alcanza para un piloto de IA acotado, que además responde preguntas de negocio, no solo técnicas.
• El proveedor no puede explicar, en una frase, qué pregunta técnica específica va a responder el ejercicio.

El orden correcto aplicado a una POC

El orden correcto en una empresa que quiere usar IA nunca empieza por la herramienta, y una POC bien entendida respeta ese orden mejor que casi ninguna otra fase: primero está el dolor operativo real (piezas que fallan, siniestros que tardan, facturas que se traban), después el proceso que rodea ese dolor, después el dato que ese proceso genera con su desorden real, y solo al final la herramienta, que se prueba contra ese dato tal cual es, no contra una versión bonita de él.

Una POC que se corre en ese orden cuesta poco, dura poco y responde exactamente lo que promete: si la tecnología aguanta tus datos reales. Una POC que se corre al revés, empezando por la herramienta y con datos de ejemplo, no es un experimento barato, es una demo cara disfrazada de rigor técnico.