Cómo saber si un caso de uso de IA merece la pena antes de construirlo

Una demostración de inteligencia artificial casi siempre impresiona. El problema llega seis meses después, cuando hay que explicar qué ha cambiado en la operativa. Muchos proyectos no fallan por la tecnología: fallan porque nunca se definió contra qué se iban a comparar.

Estos son los cuatro filtros que conviene pasar antes de escribir una línea de código.

Filtro 1: la tarea existe y alguien la hace hoy

Los casos que funcionan sustituyen trabajo que ya se está haciendo: leer una factura y teclear sus datos, clasificar correos entrantes, buscar en qué documento estaba una cláusula, redactar el borrador de una respuesta que se repite.

Si nadie hace hoy esa tarea, no hay punto de comparación, no hay ahorro medible y probablemente tampoco había necesidad. «Nos gustaría tener un chatbot» no es un caso de uso; «cada semana respondemos cuarenta consultas sobre el estado de un pedido» sí lo es.

Filtro 2: el dato existe y está en condiciones

Este es el filtro que tumba más proyectos, y conviene aplicarlo pronto porque es el más caro de descubrir tarde. Preguntas concretas:

• ¿Los documentos están en un sitio identificable o repartidos por carpetas personales?
• ¿El histórico es suficiente y refleja cómo se trabaja ahora, o cambió el proceso a mitad?
• ¿La información está actualizada, o hay tres versiones del mismo procedimiento?
• ¿Existen ejemplos de la respuesta correcta para poder comprobar los aciertos?

Si la respuesta a varias es «no», el primer proyecto no es de IA: es ordenar el dato. Es menos vistoso y suele aportar valor por sí solo.

Filtro 3: el error tiene un coste asumible

Ningún sistema acierta siempre. Lo que distingue un caso viable de uno arriesgado es qué ocurre cuando se equivoca.

Si un documento se clasifica mal y alguien lo detecta en la revisión, el coste es reordenarlo. Si un error se traslada directo a una factura enviada al cliente, el coste es distinto. Los casos que mejor funcionan son aquellos en los que el sistema propone y una persona confirma, al menos hasta que los datos de acierto justifiquen soltar el control.

Filtro 4: se puede medir contra el proceso actual

Antes de construir hay que fijar la métrica y tomar la medida de partida. Sin eso, la conversación final se resuelve por impresiones.

Las métricas útiles son aburridas y concretas: minutos por documento, porcentaje de casos resueltos sin intervención humana, número de expedientes tratados por jornada, tiempo medio hasta la primera respuesta. Si no se puede medir así, probablemente el caso todavía está mal definido.

Cómo se ve un buen primer proyecto

Suele tener este aspecto: una tarea acotada, con un volumen que justifica el esfuerzo, sobre datos que ya existen, con revisión humana en el circuito y una métrica clara medida antes y después. Se construye en semanas, no en trimestres, y al terminar se puede decir con números si sigue o se para.

Los proyectos ambiciosos vienen después, cuando el primero ha demostrado que el dato aguanta y el equipo confía en el sistema. Al revés funciona mal casi siempre.

Un proyecto de IA sin métrica de comparación no es un proyecto: es una demostración.