Cómo llevar un proyecto piloto de IA que produzca una decisión real

Una demo prueba que el modelo puede hacer la tarea una vez. Un piloto prueba que al negocio le compensa pagarla todos los días.

Tres cosas reciben el nombre de piloto y solo una lo es. La demo enseña una capacidad sobre datos escogidos, normalmente para generar interés interno, y para eso es genuinamente útil. La prueba de concepto responde a una pregunta técnica de viabilidad: este modelo, sobre nuestros datos, alcanza siquiera una calidad aceptable. El piloto responde a una pregunta comercial: con volumen real y usuarios reales, la mejora sobre el proceso actual justifica operarlo. Confundir las tres es la forma más común de gastar seis semanas de presupuesto sin producir nada accionable.

La señal está en lo que ocurre al final. Si el resultado es una reunión en la que se dice que pinta prometedor, hiciste una demo. Si el resultado es un número junto a un umbral acordado de antemano, y una persona cuyo trabajo es decir sí o no, hiciste un piloto. La segunda versión puede acabar en un no y haber valido cada hora, porque un no documentado detiene un gasto mucho mayor.

Este encuadre resuelve además la cuestión del presupuesto. Durante un piloto no estás comprando software. Estás comprando la información necesaria para decidir si comprarlo. Eso cambia qué significa caro: un piloto que cuesta una fracción del desarrollo final y evita de forma fiable una construcción equivocada es barato, y uno más barato que produce un resultado ambiguo es un desperdicio a cualquier precio.

La atención al cliente es un tema. Redactar la primera respuesta a los correos de garantía entrantes es un proceso.

Un piloto necesita una tarea con bordes. La prueba práctica es poder nombrar quién la hace hoy, cuántas veces por semana ocurre, cuánto tarda una instancia y adónde va el resultado después. Si alguna de esas cuatro respuestas sigue siendo vaga, el alcance todavía es un tema y el piloto pasará sus tres primeras semanas descubriendo qué se suponía que era.

Además de tener bordes, el proceso necesita cuatro propiedades. Volumen, porque una tarea que ocurre once veces al mes no puede generar señal en seis semanas. Tolerancia al error, porque la primera versión se equivocará a veces y conviene que eso aterrice en un sitio recuperable y no delante de un cliente o de un regulador. Una referencia medible, porque una mejora no significa nada sin una base en la que ya confías. Y datos que ya existan, porque un piloto que empieza con un proyecto de recogida de datos es un proyecto de datos disfrazado de piloto.

Hay también una propiedad política que pesa más de lo que los equipos esperan: alguien en el negocio tiene que quererlo de verdad. Un proceso elegido porque quedaba bien en una presentación estratégica, entregado a un equipo que nunca se quejó de él, obtiene colaboración cortés y ninguna adopción, y el piloto acaba midiendo el entusiasmo en lugar de la tecnología. Elige la tarea que una persona concreta está visiblemente harta de hacer.

Los mejores candidatos rara vez son vistosos: extracción de documentos que llegan en formatos irregulares, primeros borradores de respuesta en una cola donde un humano sigue aprobando, clasificación y enrutado, conciliación entre dos sistemas que no coinciden. Comparten una forma: volumen alto, riesgo unitario bajo, un punto de control humano, y un número que ya existe en algún panel.

La regla que evita la mayoría de los fracasos: si los criterios de éxito no pueden escribirse de antemano, el proyecto no está listo para ser un piloto.

Un criterio de éxito utilizable tiene cuatro partes: la métrica, la referencia contra la que se mide, el umbral que cuenta como éxito y la persona responsable de medirlo. Por ejemplo: redactar la primera respuesta cuesta hoy nueve minutos de media a un agente, sobre unos 400 tickets por semana, medido por el responsable de soporte desde la exportación de la herramienta de tickets. El piloto tiene éxito si el tiempo mediano de gestión baja de cinco minutos manteniendo la tasa de aprobación en el nivel actual o por encima. Es una frase aburrida, y es toda la diferencia entre una decisión y una discusión.

Escribe la condición de fracaso con el mismo cuidado, porque es la parte que todo el mundo se salta. Define de antemano qué resultado significaría parar, y consigue que quien decide lo acepte mientras nadie está aún involucrado emocionalmente. Sin eso, un resultado mediocre siempre se lee con indulgencia, y un proyecto que debería haber terminado en la semana seis se desliza hacia una fase dos sostenida solo por el entusiasmo. Buena parte de los abandonos que recoge S&P Global es esa deriva chocando contra un muro, más tarde y más caro de lo necesario.

Dos elementos acompañan al umbral. Un techo de coste, expresado por unidad de trabajo en lugar de como total mensual, porque es lo unitario lo que te dice si la economía aguanta a diez veces el volumen. Y un suelo de calidad separado del objetivo de velocidad, ya que casi cualquier cifra de latencia o coste puede alcanzarse degradando la salida: un piloto que optimiza la métrica que escribiste mientras estropea en silencio la que no escribiste es un desenlace conocido y evitable.

Este es además el examen honesto sobre si conviene lanzar un piloto. No poder escribir la referencia suele significar que el proceso no está instrumentado, y el primer proyecto correcto es la instrumentación. No poder nombrar a quien decide suele significar que nadie ha aceptado realmente cambiar la forma de trabajar, y ningún resultado de piloto lo arreglará.

Un piloto que corre sobre un extracto limpio en un cuaderno no te dice casi nada del sistema que tendrías que operar.

Condiciones de producción significa los datos reales con sus huecos reales, los usuarios reales haciendo su trabajo real, y los puntos de integración que existirán después. La razón no es el rigor por sí mismo: los fallos interesantes viven exactamente ahí. El registro mal formado, el caso límite que supone el cuatro por ciento del volumen y el ochenta por ciento de la dificultad, el traspaso que resulta necesitar un permiso que nadie tiene. Un piloto sobre datos limpios no encuentra ninguno y devuelve un número en el que no puedes apoyarte.

Cuatro cosas deben existir al final, y construirlas durante el piloto es el objetivo y no una carga añadida. Un banco de evaluación que corra en tu integración continua, para que la calidad sea una prueba y no una impresión, y para que el número siga siendo reproducible tras un cambio de modelo o de prompt. Barreras de entrada y de salida. Un techo de coste estricto, para que un bucle descontrolado no se convierta en una factura sorpresa. Y un repliegue documentado al proceso anterior, que es lo que hace aceptable poner esto delante de usuarios reales.

Seis semanas es la forma que hemos adoptado para una única funcionalidad de producción: bastante larga para topar con casos límite reales y obtener una medida estable, bastante corta para que la decisión siga delante de quienes la autorizaron. Los encargos más largos tienden a perder a su decisor en una reorganización o un ciclo presupuestario, que es su propia manera silenciosa de fracasar.

Mantén el código en tus repositorios desde el primer commit. Durante el piloto no cuesta nada y determina cuánto vale un sí: si el trabajo vive en el entorno de un proveedor hasta una entrega de fin de encargo, un resultado positivo te compra una dependencia en lugar de un sistema, y una entrega puntual falla mucho más a menudo que un proceso de traspaso.

La medida de un piloto no es si funcionó. Es si el resultado fue lo bastante claro para actuar, en un sentido o en el otro.

Al final deberías poder decir cuatro cosas en un párrafo: cuál era la referencia, qué logró el sistema frente a ella, cuánto cuesta por unidad a volumen real, y qué se rompe si triplicas ese volumen. Un piloto que produce esas cuatro frases ha hecho su trabajo, sea el veredicto construir, comprar o parar.

Un no limpio es un buen resultado y debe tratarse como tal internamente, porque la alternativa era descubrirlo tras el desarrollo completo. Lo que conservas de un piloto negativo es real: una referencia instrumentada que antes no tenías, un banco de evaluación que sobrevive al intento, código funcionando en tus propios repositorios, y una razón documentada por la que este proceso se resiste a la automatización, lo que evita que la misma idea se vuelva a proponer cada dos trimestres.

El riesgo de verdad no es ni el sí ni el no. Es un resultado que cada cual puede interpretar a su favor, algo que ocurre siempre que el umbral se escribió después o no se escribió nunca. Esa ambigüedad es lo que alimenta las estadísticas de abandono: no un proyecto que fracasó, sino uno que nunca pudo decirle a nadie que había funcionado.