Qué debe demostrar una prueba de concepto de IA de cuatro semanas antes de escalarla

Una prueba de concepto que impresiona en una demo puede ser, aun así, lo que no conviene escalar. El modelo resuelve los casos de ejemplo, la sala queda convencida y, unos meses después, el proyecto se ha detenido sin hacer ruido. Gartner informó en enero de 2026 de que, a finales de 2025, al menos la mitad de los proyectos de IA generativa se habían abandonado tras la prueba de concepto, por mala calidad de los datos, controles de riesgo insuficientes, costes crecientes o un valor de negocio poco claro.

Ninguna de esas razones tiene que ver con si el modelo puede hacer la tarea. Esa suele ser la parte fácil. Una buena prueba de concepto se diseña para responder a las preguntas difíciles mientras lo que está en juego todavía es poco. Si aún está eligiendo qué proceso probar, empiece por cinco preguntas para elegir la primera automatización.

Una demo no es una prueba

Una demo muestra que algo es posible. Una prueba muestra que funciona con sus datos, con su volumen y para las personas que lo van a usar. La diferencia importa porque el modelo es solo una pequeña parte de un sistema que funciona. En un conocido artículo sobre machine learning en producción, ingenieros de Google mostraron que el código del modelo es una pequeña fracción de un sistema real y que la infraestructura que lo rodea es amplia y compleja.

Por eso, una prueba de cuatro semanas debe hacer algo más que preguntar si el modelo puede hacer el trabajo. Debe poner en marcha la versión real más estrecha de todo el recorrido: la entrada real que llega, el modelo que hace su paso, el resultado que aparece donde trabaja la gente y una persona capaz de corregirlo.

Fije el listón antes de la primera semana

Un piloto sin una definición de éxito acordada tiende a alargarse, porque cada resultado queda abierto a interpretaciones. Acuerde tres cosas antes de construir nada.

• Un conjunto de pruebas con casos reales. Reúna ejemplos históricos con el resultado correcto conocido, en la proporción en que realmente llegan, incluidos los difíciles. La guía de Anthropic sobre evaluaciones recomienda conjuntos de pruebas que reflejen la distribución real de la tarea e incluyan casos límite.
• Una línea base. Mida cómo se hace hoy el trabajo: tiempo por elemento, tasa de error, plazo de respuesta. Las Rules of Machine Learning de Google ponen las métricas en primer lugar y aconsejan registrar todo lo posible en el sistema actual antes de definir qué hará el nuevo.
• Un umbral para cada medida. Anote el resultado que justificaría escalar y el que le haría parar. Que cada uno sea específico y medible: "la categoría correcta en las solicitudes habituales y ningún error dado con seguridad en los reembolsos" en lugar de "funciona bien".

Cinco cosas que deben demostrar cuatro semanas

Cada fila de la tabla corresponde a una razón por la que los pilotos fracasan más tarde. Use la tabla como orden del día de la revisión final.

Sobre los datos: si los casos de prueba contienen datos personales, el RGPD se aplica al piloto igual que a la producción. Use solo los datos que la prueba necesita (el principio de minimización de datos del artículo 5) y confirme cómo puede usarlos antes de la primera semana.

El coste merece su propia comprobación. Gartner señala que proyectos que parecen viables en una prueba de concepto pueden convertirse en un problema de presupuesto en producción, porque los pequeños costes por uso se multiplican por usuarios y casos de uso. Mida el coste por elemento durante el piloto y lea el coste real de crear un sistema de IA para saber qué más debe presupuestar.

Un plan de cuatro semanas que deja espacio para la respuesta

Cuatro semanas bastan cuando el alcance es un proceso y una decisión. Una estructura que funciona:

1. Semana 1: acordar y reunir. Fije el listón, prepare el conjunto de pruebas, consiga acceso a los datos reales y designe a las personas que probarán el sistema.
2. Semana 2: construir el recorrido mínimo. Conecte entrada, modelo y salida de principio a fin, solo para el caso principal. Ejecute el conjunto de pruebas completo al final de la semana, aunque los resultados sean flojos.
3. Semana 3: ponerlo en manos de los usuarios. Deje que el equipo lo use con trabajo real en paralelo al proceso normal, para que nada dependa todavía de él. Registre cada corrección y mida el coste por elemento.
4. Semana 4: corregir, repetir, decidir. Aborde los tipos de error más frecuentes, vuelva a ejecutar el conjunto de pruebas y redacte una nota de decisión de una página que compare las cifras con el listón.

Ejecutar el mismo conjunto de pruebas en la segunda y en la cuarta semana es precisamente la idea. Convierte el avance en una cifra y evita que la revisión final se convierta en un debate de impresiones. El AI Risk Management Framework del NIST indica que los sistemas de IA deben probarse antes de su despliegue y con regularidad durante su funcionamiento, y el conjunto de pruebas que construya ahora puede convertirse en la prueba de regresión del sistema en producción.

Escalar, ajustar o parar

Al final de la cuarta semana hay tres resultados honestos.

• Escalar cuando cada fila de la tabla tiene pruebas, se alcanza el listón y una persona concreta del negocio es responsable del resultado. La siguiente fase es trabajo de ingeniería: integración, monitorización, control de accesos y soporte.
• Ajustar cuando una o dos filas flojean y la solución está clara, por ejemplo una fuente de datos que falta. Acuerde una ampliación corta, con fecha de fin fija y el mismo listón. Ajustar no debe convertirse en un estado permanente.
• Parar cuando la calidad está lejos del listón, o cuando el valor desaparece al contar el coste de funcionamiento y el tiempo de revisión. Un piloto que termina así tras cuatro semanas ha cumplido su función: le ha ahorrado un proyecto mucho mayor.

En nuestros proyectos, los pilotos que pasan a producción sin sobresaltos son aquellos en los que las reglas de decisión se pusieron por escrito primero. Para fijar un listón realista, calcule lo que vale hoy el proceso con la calculadora de ROI o consulte flujos de trabajo habituales por área de negocio para encontrar candidatos que merezca la pena probar.