Qué le pido a una prueba de concepto de IA antes de pagarla

Hace poco escribí en LinkedIn que las demos de IA que más gustan tienen algo en común: no tocan ningún sistema de verdad. Al final dejaba una lista corta de lo que pido antes de llamar proyecto a una prueba de concepto. Me quedé con ganas de desarrollarla, así que aquí va la versión larga.

Antes, una aclaración. Una demo tiene su sitio. Sirve para enseñar una idea y para que alguien de dirección entienda en diez minutos lo que costaría una hora explicar. El problema aparece cuando se toma la demo como prueba de que el proyecto va a funcionar. Una prueba de concepto tiene que contestar otra pregunta: si esto, con nuestros datos y nuestros sistemas, aguanta el día a día.

Que trabaje con datos reales, también los feos

Una demo se prepara con ejemplos escogidos. Una prueba de concepto tiene que usar una muestra de los datos de verdad, incluidos los que dan guerra: el escaneado torcido, la ficha a la que le falta el CIF, la factura que llega reenviada por un compañero en vez de por el proveedor.

En lo que he montado, el primer caso real casi siempre ha roto algo que en la demo funcionaba. Mejor que pase en la prueba que en el tercer mes de uso.

Que lea y escriba en el sistema de verdad

Si la prueba consiste en exportar un Excel, pasárselo a la IA y mirar lo que sale, se ha probado el modelo, pero no el proyecto. La parte difícil casi siempre está en la conexión con el ERP o con la herramienta donde vive la información.

No hace falta tocar producción. Basta con un entorno de pruebas, una copia donde equivocarse no cuesta nada. Lo que sí pido es que el paso de pruebas a producción esté pensado desde el principio. En una implantación de ERP preparé la integración para que el proveedor solo tuviera que cambiar un dato de configuración al pasar a real. Si pasar a producción obliga a rehacer media solución, la prueba demostró menos de lo que parecía.

Que tenga sus propios permisos, y los justos

El sistema tiene que entrar con su propio usuario o sus propias credenciales, nunca con la cuenta personal de alguien. Y con los permisos mínimos: si solo necesita leer facturas, no debería poder borrar clientes. Mejor aún si esas credenciales caducan y alguien sabe cómo revocarlas.

Las preguntas que hago aquí son sencillas. ¿Qué puede tocar y qué no? ¿Quién lo controla? ¿Qué pasa si esa credencial acaba donde no debe?

Que deje rastro de todo lo que hace

Cada acción tiene que quedar registrada: qué leyó, qué decidió, con qué seguridad y qué escribió. En el sistema de facturas que monté, cada factura guarda cómo se identificó al proveedor y una nota de calidad según los datos que se pudieron leer. Cuando alguien pregunta por qué una factura acabó en un sitio, la respuesta está escrita.

Sin ese rastro, el primer error se convierte en una discusión sobre si el sistema es fiable o no. Con él, se convierte en un caso concreto que se mira y se corrige.

Que sepa qué hacer cuando falla o no está seguro

Hay dos tipos de fallo, y una prueba seria tiene que haberse encontrado con los dos.

• Los que hacen ruido: la conexión no responde, el ERP rechaza un dato, un adjunto no se descarga. Aquí pido que el fallo se aísle, que el resto siga su curso y que alguien se entere.
• Los silenciosos: el sistema devuelve un resultado con buena pinta que está mal. Son los peligrosos. Aquí pido que, cuando no esté seguro, lo marque para revisión y nunca rellene el hueco por su cuenta. Lo conté con más detalle en dónde dejo decidir a un agente de IA.

Mi pregunta favorita en este punto es «enséñame un caso en que se equivoca». Si no hay ninguno, no se ha probado lo suficiente.

Que se mida contra lo que se hace hoy

Antes de empezar hay que acordar cómo se va a medir el éxito: tiempo por documento, porcentaje que necesita revisión, errores detectados. Y medir primero cómo se hace hoy, porque sin esa cifra no hay con qué comparar.

Las cifras de la prueba tienen que poder comprobarse contra el origen, igual que cuando se valida un cuadro de mando. Un porcentaje de acierto que nadie puede reproducir sirve de poco.

Que alguien pueda mantenerlo

Una prueba de concepto se aprueba en un mes y luego vive años. Llegará un proveedor nuevo, un cambio de formato, una actualización del ERP. Si cada ajuste necesita a quien lo construyó, lo que se ha comprado es una dependencia.

En el sistema de facturas, el listado de proveedores y las reglas especiales acabaron en una hoja de cálculo que gestiona el propio departamento. Añadir un proveedor raro ya no necesita a nadie técnico. Ese tipo de decisión conviene tomarla en la prueba, no cuando el sistema ya está en marcha.

Las preguntas que hago antes de firmar

• ¿Con qué datos reales se ha probado, incluidos los difíciles?
• ¿Se conecta al sistema de verdad, aunque sea en un entorno de pruebas? ¿Qué cambia para pasar a producción?
• ¿Con qué permisos entra, y quién puede retirarlos?
• ¿Dónde queda el registro de lo que hace?
• ¿Qué hace cuando no está seguro? ¿Me enseñas un caso en que se equivoca?
• ¿Contra qué cifra de hoy vamos a medir el resultado?
• ¿Quién lo ajusta cuando cambie algo?

Si una prueba de concepto contesta bien a estas preguntas, el modelo de IA que use pasa a segundo plano. Y si no las contesta, da igual lo bien que responda en la demo.