IA en la empresa: cómo distinguir un caso de uso real de una demo cara

Por Néstor Verde, CIO/CTO de Fractional.

 

Recuerdo un sistema para leer albaranes y documentos de transporte que en la presentación extraía todos los campos sin error. Luego llegaron los documentos del día a día: escaneados en el almacén, fotografiados con el móvil, alguno con el sello tapando la mitad de los datos. La precisión bajó lo justo para obligar a revisar cada documento a mano, y el ahorro que justificaba la inversión se esfumó.

Casos así me han convencido de que la mayoría de proyectos de IA que se caen no lo hacen por la tecnología. Se aprobaron sin que nadie distinguiera entre un caso de uso y una demostración. Antes de dar el visto bueno a una propuesta, yo intento aclarar unas cuantas cosas.

Lo primero, qué proceso concreto va a cambiar y quién lo hace hoy. Si nadie sabe decirme cuánto tarda esa persona o cuántos errores comete ahora, no tengo con qué comparar. "Mejorar la eficiencia" o "aprovechar los datos" son intenciones, no casos de uso.

Después pido verlo funcionar con una muestra de nuestros datos tal como están, sin limpiar. Si el equipo o el proveedor necesita semanas para prepararlos, bien, pero ese trabajo forma parte del proyecto y tiene que figurar en el presupuesto.

También quiero saber qué pasa cuando el modelo se equivoca, porque se va a equivocar. Clasificar mal un correo es una molestia. Equivocarse en una factura o en un plazo aduanero cuesta dinero. Hay que acordar qué margen de error se acepta, quién revisa los resultados y qué hace el sistema cuando no está seguro.

Pregunto siempre si alguien lo ha comparado con una solución sin IA. Me he encontrado propuestas que resolvían con un modelo lo que una regla de negocio o una integración entre dos sistemas habría resuelto por mucho menos dinero. A veces la IA se elige porque es lo que toca este año, y la opción aburrida ni siquiera se llega a valorar. Merece la pena ponerla sobre la mesa aunque sea para descartarla con argumentos.

Otra cuestión que se suele olvidar es quién se hace cargo cuando termine el piloto. El piloto tiene un patrocinador entusiasta; la explotación necesita a alguien del negocio que vigile la calidad, pague el coste mensual y decida cuándo ajustar el sistema o apagarlo. Si nadie asume ese papel, el proyecto se queda en la presentación.

Conviene fijar desde el principio cómo se medirá el éxito, con qué valor de partida y en qué fecha se decide seguir o cerrar. Sin esa fecha, los pilotos se alargan indefinidamente porque a nadie le apetece declarar que no ha funcionado.

Queda el coste por uso. Cien consultas en una demo salen prácticamente gratis. Cien mil al mes con un modelo de pago por uso son una partida que hay que calcular antes de firmar, no descubrir en la primera factura.

En mi experiencia, cuando la conversación se centra en todo lo que el modelo es capaz de hacer, lo más probable es que estemos ante una demo. Cuando se habla de excepciones, de datos sucios, de coste por operación y de responsables, empieza a parecer un proyecto.

Nada de esto va contra la IA. Es el mismo rigor que aplicaríamos a cualquier otra inversión. Los proyectos que pasan este filtro suelen lucir menos, pero llegan a producción, y eso facilita mucho defender el siguiente delante del comité.