La tentación de la demo

Empty stage with lights
Foto de Elijah Ekdahl en Unsplash

Este año he visto muchas demostraciones. De herramientas de IA sobre todo, que ahora hacen cosas que hace dos años parecían imposibles: leer un documento y resumirlo, transcribir una reunión, generar una imagen a partir de una descripción, responder preguntas sobre un conjunto de datos.

Casi todas eran impresionantes. Y he aprendido a desconfiar exactamente en proporción a lo impresionantes que son.

Qué es una demo

Una demostración es una pieza de comunicación, no una prueba. Está construida hacia atrás: se elige un caso que la herramienta resuelve bien, se preparan los datos, se ensaya el recorrido y se elimina todo lo que introduce fricción.

Eso no es engañar. Es lo que haría cualquiera que tenga veinte minutos para explicar algo complejo. El problema no está en quien la presenta, sino en la conclusión que sacamos: si esto funciona, funcionará con lo mío.

Y no. Porque lo tuyo tiene documentos escaneados torcidos, con sellos encima del texto, con nombres que se escriben de tres maneras distintas y con casos que no encajan en ninguna categoría.

La distancia entre el 90% y el 99%

Aquí está, en mi experiencia, el malentendido más caro.

Una herramienta que acierta el 90% de las veces parece casi resuelta. En una demo con diez ejemplos, falla uno, y ese uno se atribuye a un caso raro.

Pero el 10% restante no es un resto: en muchos procesos administrativos es el trabajo entero. Si el sistema clasifica bien nueve de cada diez documentos, alguien tiene que revisar los diez para encontrar el que está mal. El ahorro no es del 90%, porque la revisión sigue siendo completa.

Para que el ahorro sea real hace falta una de dos cosas: o que el error sea detectable automáticamente —que el sistema sepa cuándo no está seguro— o que el coste de equivocarse sea bajo. En un procedimiento con efectos jurídicos, el coste de equivocarse no es bajo.

Esa pregunta, "¿cómo sabemos cuándo se ha equivocado?", es la que más incomoda en una reunión comercial y la más importante.

Lo que pregunto ahora

He ido acumulando una lista de preguntas que cambian bastante el tono de la conversación.

¿Puedo probarlo con mis datos, sin preparar, delante de vosotros? La reacción a esta pregunta ya es informativa.

¿Qué pasa con un documento mal escaneado, con un caso que no está previsto, con un valor vacío?

¿Cómo se integra con lo que ya tenemos? Casi siempre la respuesta es "vía API", que es una forma de decir que ese trabajo lo pondremos nosotros.

¿Quién revisa el resultado y cuánto tarda? Si la respuesta es que no hace falta revisarlo, la conversación ha terminado.

¿Qué ocurre con los datos que le damos? En el sector público esta pregunta no es opcional.

No es escepticismo

Quiero dejar clara una cosa, porque el tono puede sonar a rechazo y no lo es. Estas herramientas son útiles y han cambiado cosas de mi trabajo diario de forma sustancial.

Lo que sostengo es que la demo no informa sobre eso. La demo informa sobre el mejor caso posible, y las decisiones hay que tomarlas sobre el caso medio y el peor.

La forma de saberlo es una prueba pequeña, con datos reales, medida contra el procedimiento actual. Cuesta unas semanas, cuesta poco dinero y evita bastantes disgustos.

Y tiene un efecto secundario valioso: obliga a definir con precisión qué problema estamos intentando resolver. Que es, casi siempre, la parte que faltaba.

Por qué caemos igual

Termino con la parte incómoda, que tiene que ver con nosotros y no con quien vende.

Una demostración impresionante genera una sensación agradable: la de que un problema difícil tiene una solución al alcance. Esa sensación es la que se compra, más que el producto.

Y hay un factor organizativo que empuja en la misma dirección. Quien vuelve de una demostración con entusiasmo tiene algo que contar; quien vuelve diciendo que habría que hacer una prueba pequeña de tres meses antes de decidir, no. En organizaciones que premian el anuncio, el escéptico siempre juega en desventaja.

Por eso creo que la prueba piloto no es solo una buena práctica técnica. Es una manera de proteger a quien decide de la presión de tener que parecer decidido.

Lo he visto funcionar así más de una vez: en cuanto existe un procedimiento establecido para probar, dejar de comprar sin probar deja de ser una postura personal y pasa a ser lo normal.