Prueba piloto de IA: cómo diseñarla para poder decidir

El objetivo del piloto es decidir, no demostrar

Una prueba piloto es un experimento con un final previsto: al terminar, tienes que poder decidir si continúas, si corriges el enfoque o si detienes el proyecto. Si al acabar nadie sabe qué conclusión sacar, el piloto ha consumido tiempo sin reducir la incertidumbre.

La diferencia con una demostración es importante. Una demostración enseña lo que la tecnología puede hacer en condiciones favorables; un piloto comprueba lo que hace con tus datos, tus usuarios y tus excepciones. Por eso un buen piloto se diseña pensando en lo que podría salir mal, no en lo que luce en una presentación.

Escribe la pregunta del piloto en una frase. Por ejemplo: «¿Podemos extraer los datos de los albaranes de proveedores con una revisión que lleve menos tiempo que la grabación manual actual?». Una pregunta así ya indica qué datos hacen falta, quién participa y qué hay que medir. «Probar la IA en administración» no lo hace.

Acota el alcance: proceso, personas, datos y tiempo

El alcance de un piloto debe ser lo bastante pequeño para controlarlo y lo bastante real para que el resultado signifique algo. Un solo proceso, un equipo concreto y un periodo definido suelen bastar. Ampliar el alcance durante la prueba es una de las formas más habituales de llegar al final sin conclusiones.

Trabajar en paralelo al proceso real reduce el riesgo: el equipo sigue haciendo la tarea como siempre y la solución genera su propuesta a la vez, de forma que se pueden comparar ambos resultados sin afectar a clientes ni a la contabilidad.

• Proceso: qué tarea exacta se prueba, dónde empieza y dónde termina.
• Participantes: quién usa la solución, quién revisa los resultados y quién decide al final.
• Datos: qué conjunto se usa, de qué periodo y con qué permisos.
• Integración: si se trabaja en paralelo al sistema real o con una conexión de solo lectura.
• Duración: un número de semanas fijado de antemano, con una revisión intermedia.
• Fuera de alcance: lo que explícitamente no se probará en esta fase.

Mide la situación de partida y fija los umbrales

Sin línea base no hay comparación. Antes de empezar, mide cómo funciona hoy el proceso: cuánto tiempo lleva cada unidad de trabajo, cuántos errores aparecen y cuántas veces hay que rehacer algo. Si no existen registros, cronometra una muestra representativa durante unos días; una estimación de memoria no sirve.

Acuerda también los umbrales de decisión antes de ver resultados: qué nivel de calidad es aceptable, cuánto esfuerzo de revisión estás dispuesto a asumir y qué resultado llevaría a detener la prueba. Escribirlo antes evita la tentación de mover los criterios para que el resultado parezca positivo.

• Continuar: la calidad supera el umbral y el tiempo total, incluida la revisión, es menor que el actual.
• Corregir: la calidad se acerca al umbral y los errores tienen causas identificables, como un tipo de documento concreto.
• Detener: los errores no siguen un patrón, la revisión cuesta más que hacer la tarea a mano o los datos necesarios no están disponibles.

Prepara un conjunto de prueba con casos difíciles

Una demostración con ejemplos perfectos oculta los problemas. El conjunto de prueba debe parecerse a la realidad, incluidas sus imperfecciones: documentos incompletos, entradas ambiguas, formatos poco frecuentes y solicitudes que deberían quedar fuera del alcance de la solución.

Una forma práctica de construirlo es separar tres grupos: casos habituales, que representan el grueso del volumen; casos difíciles, que el equipo reconoce como problemáticos; y casos fuera de alcance, ante los que la solución debería abstenerse o derivar a una persona. Pide a quien ejecuta el proceso a diario que aporte los ejemplos difíciles: sabe cuáles son.

Reserva una parte de los casos sin enseñarla al proveedor durante la configuración. Si la solución solo funciona con los ejemplos que se usaron para ajustarla, el resultado del piloto será engañoso.

Durante la prueba: registra lo que se aparta de lo previsto

Lleva un registro sencillo de cada resultado revisado: si fue correcto, si necesitó corrección, cuánto tiempo llevó la revisión y por qué falló cuando falló. Esa información vale más que una cifra global de aciertos, porque te dice qué hay que arreglar.

Reserva una reunión breve cada semana con los usuarios y el proveedor para revisar excepciones. Muchas veces el problema no está en el modelo, sino en una regla de negocio que nadie había explicado o en un dato de origen incorrecto. Anota esas causas: son aprendizaje del proyecto aunque el piloto no continúe.

Vigila también la experiencia de uso. Si los usuarios evitan la herramienta, rehacen los resultados por desconfianza o necesitan pasos adicionales para revisar, el ahorro previsto no aparecerá cuando la solución pase a producción.

El informe final y la decisión

Cierra el piloto con un informe corto que alguien ajeno al proyecto pueda entender. No hace falta un documento extenso; bastan una o dos páginas que respondan a la pregunta inicial con los datos recogidos.

Si la decisión es continuar, el informe se convierte en la base del plan de implantación: ya sabes qué datos hay que preparar, qué integración hace falta y qué indicadores seguirás midiendo en producción.

• Pregunta del piloto y alcance real, incluidos los cambios respecto al plan.
• Línea base y resultado medido con el mismo método.
• Errores agrupados por tipo y causas identificadas.
• Esfuerzo de revisión y de preparación de datos.
• Riesgos detectados y condiciones para pasar a producción.
• Decisión recomendada (continuar, corregir o detener) con su justificación.

La misma lógica que aplica el Bono IA

El documento del Plan IA360 aplica este enfoque al propio programa: para el Bono IA prevé un piloto controlado en el primer semestre de 2027, con los primeros ecosistemas de la Red NEURONA, antes de una convocatoria general que debería llegar antes de final de 2027, con una dotación de 600 millones de euros. A día de hoy no hay convocatoria abierta ni bases publicadas.

El plan menciona también que la implantación incluirá una medición posterior del impacto en productividad. No se sabe todavía cómo se concretará, pero un piloto bien documentado, con línea base y criterios explícitos, es una práctica que te sirve en cualquier escenario.