Checklist de PoC de IA: qué debe estar listo antes, durante y al final

Una prueba de concepto de IA sirve para una cosa: permitir que alguien con presupuesto decida el siguiente paso. Si al final de varias semanas de trabajo la dirección recibe un informe técnico impecable y sigue sin saber si escalar, ajustar o descartar la idea, la PoC falló, aunque el modelo haya acertado todo lo que intentó.

Este tipo de fallo es frecuente y aparece en los estudios. En julio de 2024, Gartner predijo que al menos el 30% de los proyectos de IA generativa se abandonarían después de la prueba de concepto antes de finales de 2025, por mala calidad de datos, controles de riesgo insuficientes, costes crecientes y valor de negocio poco claro. Un año después, la misma firma estimó que más del 40% de los proyectos de IA agéntica se cancelarán antes de finales de 2027, por coste, valor incierto y riesgo mal controlado.

El informe de RAND Corporation sobre las causas de fracaso de los proyectos de IA, publicado en 2024, entrevistó a 65 científicos de datos e ingenieros con experiencia. La causa más citada fue entender mal, o comunicar mal, qué problema debía resolver la IA. El resultado son modelos optimizados para la métrica equivocada o que no encajan en el flujo de trabajo real.

Casi ninguno de estos motivos es técnico. Datos malos, costes que crecen, valor que nadie definió, riesgo que nadie midió: todo eso puede descubrirse dentro de una PoC bien diseñada, por una fracción de lo que costaría descubrirlo en producción. El checklist siguiente es nuestra forma de hacer que la PoC busque esas respuestas a propósito.

Antes del primer día

La mayor parte del resultado de una PoC se decide antes de que alguien escriba código.

1. La pregunta de decisión cabe en una frase. No "probar IA en atención al cliente", sino "¿merece la pena invertir en automatizar la clasificación de incidencias de segundo nivel el próximo semestre?". Si la pregunta no cabe en una frase, el alcance sigue abierto.
2. Existe un criterio de éxito numérico, con umbrales. Tasa de acierto, tiempo ahorrado por caso, coste por transacción. Los umbrales se acuerdan antes: por encima de un valor escalamos, en una franja intermedia ajustamos, por debajo descartamos. Un criterio interpretado después del resultado siempre favorece continuar.
3. Existe una línea base. Cuánto tarda hoy el proceso, cuál es la tasa de error humana, qué conseguiría una regla simple. Las Rules of Machine Learning de Google empiezan precisamente así: no tenga miedo de lanzar un producto sin machine learning y empiece con heurísticas. Si una regla de diez líneas resuelve buena parte del problema, la IA tiene que superar a la regla, no al cero.
4. El acceso a datos reales está aprobado. En una empresa grande, abrir una base de producción pasa por seguridad, jurídico y a menudo por el delegado de protección de datos. Si eso no está resuelto en el arranque, las primeras semanas se van esperando.
5. El responsable de la decisión tiene nombre. Una persona, con presupuesto, que leerá el resultado y decidirá. No un comité genérico.
6. Plazo y presupuesto son cerrados. En la PoC Factory trabajamos con 3 a 6 semanas. Un plazo abierto convierte la PoC en un proyecto encubierto, sin los controles de un proyecto.

Durante la construcción

• Pruebe con datos reales, incluidos los feos. Una muestra elegida a mano produce una demo buena y una decisión mala. Separe los casos difíciles (documentos escaneados torcidos, clientes que envían audios, registros incompletos) y mida sobre ellos.
• Mida el coste por unidad desde el principio. En IA generativa, el coste por llamada al modelo, por documento o por conversación decide si la idea es rentable a escala. El coste creciente es uno de los motivos de abandono que cita Gartner, y es fácil de medir en una PoC.
• Registre los errores, no solo la tasa de error. Una tasa de acierto alta no dice si los errores restantes son baratos o si uno de ellos genera una multa. Una hoja con algunas decenas de errores reales, clasificados por gravedad, vale más para la dirección que cualquier gráfico.
• Anote lo que quedó fuera. Integración con el ERP, volumen en picos, idiomas, perfiles de usuario. Todo lo que la PoC no probó se convierte en un riesgo explícito del informe.
• Mire el riesgo junto con el resultado. Datos personales en el prompt, respuestas que pueden interpretarse como asesoramiento, decisiones automáticas sobre clientes. El AI Risk Management Framework del NIST es una referencia gratuita y útil para ordenar esa lista.

En la entrega

El entregable final debe poder leerlo quien decide en quince minutos. En Cortex IQ lo llamamos Decision Package, y siempre tiene las mismas partes:

1. La pregunta de decisión original, copiada del documento de arranque.
2. El resultado medido frente al criterio acordado y frente a la línea base.
3. La estimación de impacto de negocio, con las hipótesis por escrito: volumen mensual, coste por hora, adopción esperada. Las hipótesis ocultas son la forma más habitual de inflar un business case.
4. El coste estimado de operar en producción: infraestructura, llamadas al modelo, monitorización, personas.
5. Las limitaciones conocidas y lo que la PoC no probó.
6. La recomendación: escalar, ajustar o descartar, con el porqué.
7. Si la recomendación es escalar, lo que falta para producción: integraciones, responsable operativo, plan de monitorización.

Un ejemplo, con números hipotéticos

Piense en una distribuidora que recibe pedidos de compra por correo, en PDF, con formatos de decenas de clientes distintos. Hoy dos administrativos teclean esos pedidos en el ERP.

La pregunta de decisión: "¿merece la pena automatizar la lectura de pedidos en PDF este año?". El criterio: extraer correctamente los campos obligatorios en al menos el 95% de los pedidos, con un coste por pedido inferior al de la entrada manual actual. La línea base: medir, durante una semana, cuánto tarda cada pedido y cuántos vuelven por errores de tecleo.

La PoC se ejecuta con tres meses de pedidos reales, escaneados incluidos. Suponga que el resultado es un 97% de acierto en PDF nativos y un 81% en escaneados, que son una quinta parte del volumen. Una PoC mal diseñada entregaría "94% de acierto medio" y dejaría a la dirección adivinando. Una bien diseñada recomienda escalar ya los PDF nativos, mantener los escaneados con revisión humana y reevaluarlos en seis meses. Es una decisión que alguien puede tomar en una reunión.

Los errores que más vemos

Criterio definido después. Cuando sale el resultado, siempre aparece un motivo para decir que un 80% es suficiente. Si nadie escribió antes que el mínimo era un 90%, la discusión se vuelve opinión.

La demo en lugar de la evidencia. Una demo en directo convence a la sala y no demuestra nada sobre el volumen real. Use la demo para mostrar cómo funciona y el registro de errores para mostrar si funciona.

El "ajustar" que nunca termina. Ajustar es una recomendación válida cuando tiene plazo y un criterio nuevo. Una segunda ronda de ajustes sin fecha es una PoC que nadie se atrevió a cerrar.

Descartar tratado como fracaso. Una PoC que concluye "no merece la pena" en cinco semanas ahorró el presupuesto de un proyecto entero. Si la cultura de la empresa castiga ese resultado, los equipos dejan de recomendarlo y las PoC se convierten en proyectos que nadie consigue apagar.

Por dónde empezar

Antes de aprobar la próxima prueba de concepto, pida al equipo una página con tres cosas: la pregunta de decisión en una frase, el criterio numérico con los umbrales de escalar, ajustar y descartar, y el nombre de quien va a decidir. Si esa página no está lista en una semana, el problema no es técnico y ninguna PoC lo va a resolver.

Si quiere un formato ya preparado, la PoC Factory ejecuta este proceso en AWS o Google Cloud y termina con el Decision Package descrito arriba. Para iniciativas más amplias de datos y modelos, vea nuestro trabajo en Datos e IA.