Proyecto piloto de IA: cómo definir objetivo, muestra y decisión final

Un proyecto piloto sirve para responder a una pregunta, no para demostrar que la inteligencia artificial funciona. La diferencia se ve al final: si los criterios se han escrito antes, el resultado es una decisión; si se escriben después, es una interpretación, y gana quien mejor habla en la reunión.

Esta guía trata sobre cómo se organiza la prueba: qué se mete dentro, qué se mide, quién la supervisa y cómo se decide al final.

Lo primero: la pregunta a la que responde el piloto

«A ver si la IA puede ayudarnos» no es una pregunta, porque no existe una respuesta que la cierre. Una pregunta útil tiene una actividad, un sujeto y una condición verificable.

• Si un sistema prepara las primeras respuestas a las solicitudes de soporte, ¿consigue la oficina cerrar en el mismo día los expedientes del día?
• Si los documentos de los proveedores se leen automáticamente, ¿cuántos terminan de todos modos en manos de una persona?
• Si los presupuestos repetitivos se rellenan con asistencia, ¿baja el tiempo de preparación sin que aumenten los errores en los importes?

Cada una de estas preguntas puede recibir una respuesta negativa, y ese es el punto. Un piloto que no puede tener un resultado negativo no es una prueba: es una presentación.

El perímetro: qué entra y qué queda fuera

Es la parte que se tiende a dejar amplia, y es el error que hace ilegibles los resultados. Cuanto más amplio es el perímetro, menos se entiende a qué atribuir lo que ocurre.

• La actividad: una sola y delimitada. No «la atención al cliente», sino «las solicitudes sobre el estado del pedido que llegan por correo».
• Los usuarios: un grupo reducido e indicado por nombre, dispuesto a señalar los problemas en lugar de sortearlos en silencio.
• Los datos: qué fuentes, con qué permisos, y qué no debe usarse.
• Las exclusiones explícitas: los casos que el sistema no debe tratar y que deben pasarse de inmediato a una persona, por ejemplo reclamaciones, cuestiones contractuales, clientes en litigio.

El periodo debe elegirse de manera que quepa dentro una cantidad de casos suficiente para decir algo, y al menos un ciclo típico de la empresa: si el cierre mensual cambia la forma de trabajar, el piloto debe atravesarlo.

La situación inicial se registra antes

Sin un punto de partida no hay comparación, y reconstruirlo al final lleva siempre a números de conveniencia. Antes de poner en marcha nada, medid cómo se trabaja ahora: cuánto tiempo requiere la actividad, cuántos casos se tratan, cuántos errores o repeticiones de trabajo se producen, cuánto se espera.

Si una medida no existe, hay que construirla a mano durante unas semanas: dos personas que anotan tiempos y casos en una hoja dan una referencia más útil que una estimación hecha de memoria. Es trabajo de verdad y debe incluirse en el plan, no añadirse por sorpresa.

La ficha del piloto

Cabe en una página. El ejemplo es ilustrativo y se refiere a la lectura automática de los documentos entrantes.

Las dos filas peor rellenadas son casi siempre «fuera de perímetro» y «criterios de aceptación»: la primera porque parece limitante, la segunda porque obliga a decir de antemano qué se considera un éxito. Son exactamente las dos que hacen que la prueba sea decidible.

Supervisión y anomalías durante la prueba

Durante el piloto alguien debe mirar, no solo usar. Hace falta un momento fijo —semanal está bien— en el que se leen los casos que han salido mal y se decide si son corregibles o si indican algo más profundo.

• Cada resultado queda verificado por una persona: el piloto no es el momento para quitar el control.
• Las anomalías se recogen en una lista única, con el caso concreto adjunto: sin el ejemplo real no se corrige nada.
• Debe definirse de antemano qué hace detener la prueba: un error que ha llegado a un cliente, un dato salido de donde no debía, una carga de correcciones superior al trabajo ahorrado.
• Los cambios hechos durante la prueba deben anotarse con la fecha, si no, al final no se sabrá a qué versión se refieren los resultados.

Decidir: extender, corregir, interrumpir

La reunión final debe fijarse al principio, con las personas que deciden ya comprometidas. Las salidas posibles son tres, y ninguna de las tres es un fracaso.

1. Extender: los criterios se cumplen. Se pasa a definir quién mantiene el sistema, quién responde cuando falla y qué ocurre si cambia una fuente de datos.
2. Corregir y repetir: el resultado está cerca pero un caso concreto no se sostiene. Se repite una sola vez, con el mismo perímetro y una modificación declarada.
3. Interrumpir: el beneficio no existe, o cuesta más que el procesamiento manual. Se escribe el motivo, para que dentro de un año nadie vuelva a proponer la misma prueba sin saber cómo había ido.

En la cuenta hay que poner todo el coste, no solo la construcción: el mantenimiento, las verificaciones de las personas, el tiempo de quien corrige. Un sistema que ahorra media hora y requiere veinte minutos de control tiene un margen estrecho, y hay que decirlo antes de que alguien lo descubra solo.

Lo que esta guía no cubre

Aquí se trata la organización de la prueba. La elección de qué actividad llevar al piloto —cómo se comparan entre sí los candidatos y con qué criterios se ordenan— es un paso anterior y tiene su propia guía. También la verificación de un asistente conversacional antes de ponerlo a disposición de los clientes sigue un método dedicado.