Qué pedirle a un piloto de IA antes de llevarlo a producción

La distancia entre una demostración que gusta y un sistema del que puedes responder no es una cuestión de modelo. Es la misma distancia que separa cualquier prototipo de cualquier producto: medición, coste, límites y operación.

1. Un conjunto de casos reales, no una demo

Antes de escalar nada hace falta un conjunto de entre cincuenta y doscientos casos reales con la respuesta correcta anotada por alguien que sepa del negocio. Es trabajo tedioso y es lo que convierte «parece que funciona bien» en un número.

Sin ese conjunto no puedes saber si un cambio de prompt, de modelo o de proveedor mejora o empeora las cosas. Estás optimizando a ciegas y con factura.

2. Coste por operación, medido

El coste unitario en el piloto multiplicado por el volumen real da una cifra que a veces cambia la decisión entera. Conviene calcularla antes de comprometerse, no después de la primera factura mensual.

La sorpresa suele ir en la buena dirección: para muchos casos de clasificación o extracción, un modelo pequeño y bien ajustado resuelve igual que uno grande por una fracción del precio. Pero eso solo se descubre si se mide.

3. Un límite claro de lo que el sistema no debe hacer

Todo sistema de IA en producción necesita una respuesta definida para «no estoy seguro». Sin ella, el sistema siempre contesta algo, y contestar algo con seguridad cuando no se sabe es exactamente el modo de fallo más caro.

• Umbral a partir del cual la operación escala a una persona.
• Categorías de consulta que nunca se responden automáticamente.
• Registro de qué se decidió y con qué información, para poder reconstruirlo después.

4. Alguien que mire los fallos cada mes

La calidad de un sistema de IA no es una propiedad fija: se degrada cuando cambian los datos de entrada, el proveedor actualiza el modelo o el negocio cambia un proceso. Si nadie tiene asignada la revisión mensual de los casos fallados, la degradación se descubre por una queja de un cliente.

Lo que no está en la lista

No está qué modelo usar, ni qué proveedor, ni si conviene una base de datos vectorial. Son decisiones reversibles y relativamente baratas de cambiar. Las cuatro de arriba son las que determinan si el sistema aguanta.