Qué es un piloto de IA y cómo se hace en una empresa

El problema: probar en el vacío o apostarlo todo de una vez

Hay dos maneras de perder dinero con un piloto de IA, y las dos empiezan por saltarse la palabra piloto. La primera es la que ya conoces si trabajas en operaciones: un área de la empresa decide que la tecnología ya está madura porque funcionó en otro lado, así que la instala para toda la planta, toda la fuerza de ventas o todo el centro de atención de una sola vez. No hay ensayo previo con datos reales ni con los usuarios que van a convivir con el sistema todos los días. Cuando algo falla, y algo suele fallar la primera vez que un modelo se enfrenta a datos sucios de verdad, el error no queda contenido en un rincón controlado: llega a clientes reales, a facturas reales, a decisiones reales.

Un ejemplo típico: una cadena retail mediana en Colombia activó un asistente de atención por chat en sus tres canales digitales al mismo tiempo, entrenado con conversaciones históricas que ya no reflejaban el catálogo vigente. En la primera semana el asistente ofrecía descuentos que no existían y confundía referencias de producto frente a miles de clientes simultáneos. El equipo tuvo que apagarlo, y la conversación interna pasó de cómo escalamos esto a quién autorizó esto sin probarlo antes.

La segunda manera de perder dinero es la opuesta y más silenciosa: la empresa sí prueba, pero nunca decide. Una empresa de logística mediana en Perú lleva más de un año probando un algoritmo de optimización de rutas en una sola sede, revisando resultados mes a mes, sin que nadie haya escrito jamás qué número tenía que mover ese algoritmo para justificar llevarlo a las demás sedes. La prueba no fracasó ni tuvo éxito: simplemente nunca terminó, y sigue consumiendo horas de un equipo de datos que podría estar resolviendo otro problema.

Qué es un piloto de IA

Entre la promesa de un proveedor y la implementación total de un sistema hay un escalón que muchas empresas se saltan: la prueba en condiciones reales pero acotadas. Ese escalón, en criterio de negocio, no es un experimento de laboratorio ni un lanzamiento definitivo. Es la etapa donde la pregunta deja de ser si la tecnología puede hacer esto y pasa a ser si esto funciona con mi gente, mis datos y mi operación tal como son hoy, no como aparecen en la propuesta comercial.

Tres palabras de esa definición hacen todo el trabajo. Operación real significa que no se simula nada: ni el proceso, ni los datos, ni la gente que lo usa. Alcance limitado significa que si algo sale mal, el daño se queda contenido en una sucursal, un turno o un producto, no en toda la empresa. Y para medir si funciona significa que el piloto tiene un propósito de decisión, no de exhibición. Un piloto que no está diseñado para producir una decisión de negocio (escalar, ajustar o cancelar) no es un piloto: es una demostración prolongada con presupuesto de proyecto.

POC, piloto y MVP no son lo mismo

El error de vocabulario más caro en proyectos de IA es tratar POC, piloto y MVP como sinónimos intercambiables. No lo son, y cada uno responde una pregunta de negocio distinta que el anterior no contesta.

• POC (prueba de concepto): responde si es técnicamente posible. Se corre en un entorno controlado, muchas veces con datos históricos o de muestra, sin usuarios reales ni consecuencias operativas. La entrada del glosario sobre qué es una POC de IA desarrolla esta etapa a fondo.
• Piloto: responde si funciona en la operación real. Usa datos de verdad, usuarios de verdad y un proceso de negocio real, pero con alcance limitado en tiempo, sede o volumen.
• MVP con IA: responde si alguien lo usa y lo paga, o genera el ahorro o el ingreso que se prometió, de forma sostenida. Ya no se trata de probar que funciona técnicamente, sino de sostenerlo como producto u operación permanente, algo que la entrada sobre qué es un MVP con IA explica con más detalle.
• Cada etapa tiene su propio criterio de fracaso: una POC puede fallar por falta de datos suficientes; un piloto puede fallar porque el proceso alrededor no estaba listo para recibir el sistema; un MVP puede fallar porque nadie lo adopta aunque funcione de forma impecable.

Confundir estas etapas es lo que lleva a una empresa a comprar como si ya hubiera pilotado, saltándose el paso intermedio, o a seguir probando de forma indefinida cuando ya tiene evidencia suficiente para decidir. El caso de uso de IA que se elija para empezar, algo que desarrolla la entrada sobre qué es un caso de uso de IA, determina en buena parte cuántos de estos tres escalones hace falta recorrer, pero ninguno debería saltarse el piloto.

El criterio de éxito que nadie escribe antes de empezar

El defecto más caro y más común de un piloto de IA no es que falle. Es que nunca termine. Lo he visto en manufactura, en retail y en servicios financieros: el piloto arranca con entusiasmo, pasa el primer mes de revisión, entra a un segundo mes para confirmar tendencia, y a los seis meses ya nadie recuerda cuál era la meta original, porque nunca se escribió una.

El piloto eterno no ocurre por mala fe. Ocurre porque es más cómodo seguir midiendo que tomar una decisión que alguien tendrá que defender frente a su jefe o frente al directorio. Sin un criterio de éxito escrito antes de empezar, cualquier resultado se puede leer como prometedor, sigamos observando, y esa frase no cuesta nada decirla en una reunión, pero cuesta meses de presupuesto y de atención del equipo que podría estar en otra prioridad.

• Una métrica de negocio, no una métrica técnica: no es el modelo clasifica con precisión aceptable, es el tiempo de respuesta al cliente baja o el reproceso de un turno se reduce.
• Un umbral numérico definido antes de ver el primer resultado, no ajustado después para que el dato encaje con lo que ya se quería mostrar.
• Una fecha de cierre fija, con calendario, no una condición abierta del tipo hasta que estemos conformes.
• Un responsable con nombre y apellido que toma la decisión de escalar, ajustar o cancelar, no un comité que diluye la responsabilidad entre varias áreas.
• Un criterio de salida, es decir cuándo se cancela, tan claro como el criterio de escalamiento; la mayoría de empresas solo escribe el segundo.

Qué necesita una empresa antes de correr un piloto

Antes de correr un piloto de IA hay condiciones mínimas que, si faltan, garantizan un resultado inservible sin importar qué tan bueno sea el sistema por dentro.

• Datos reales del proceso que se quiere intervenir, no datos de muestra ni datos limpiados a mano para la demostración del proveedor.
• Usuarios reales que van a operar el sistema en su rutina diaria, no un equipo de proyecto probándolo en paralelo a su trabajo normal.
• Un proceso de negocio ya identificado y acotado, como una sede, un turno o una línea de producto, y no toda la operación de atención al cliente de una vez.
• Un patrocinador con autoridad para decidir al final del piloto, porque si la decisión depende de alguien ausente de todo el proceso, el piloto se estanca justo ahí.
• Un presupuesto y un plazo definidos como límite duro, no como estimado orientativo que se puede correr cada mes que hace falta.

Cuando falta cualquiera de estas condiciones, lo honesto es no llamarlo piloto: es una prueba técnica disfrazada de proyecto de negocio, y va a terminar midiendo lo que el sistema puede hacer en teoría, no lo que la empresa puede sostener en la práctica del día a día.

Qué no resuelve un piloto de IA

Un piloto bien ejecutado responde una pregunta acotada: si este sistema, en este proceso, con estos usuarios, produce el resultado de negocio que se buscaba. No responde preguntas más grandes que muchas empresas le piden que conteste.

• No prueba que la adopción se sostenga cuando el entusiasmo inicial del equipo piloto se apague; eso lo mide la adopción real después del piloto, con datos de uso, algo que cubre la guía para medir la adopción real de un sistema de IA.
• No arregla un proceso que ya estaba roto antes de la IA; si el problema de fondo es que el proceso mismo no está definido, el piloto solo lo va a exponer más rápido, no a resolverlo.
• No prueba el costo a escala completa; el costo de correr un sistema en una sede rara vez escala de forma lineal cuando se multiplica a diez sedes.
• No sustituye la gestión del cambio; un piloto exitoso en resultados técnicos puede fracasar igual en la expansión si nadie preparó a los equipos de las demás sedes para recibirlo.

Este es el punto donde se decide qué sigue. Si el piloto cumplió el criterio de éxito escrito al inicio, el paso siguiente no es seguir probando un poco más, es escalar con método. Ese proceso de escalamiento (qué cambia de una sede a diez, qué se vuelve a validar, qué presupuesto nuevo hace falta) tiene su propio desarrollo en la guía para escalar un piloto de IA a toda la empresa, y no lo voy a repetir aquí. Si no cumplió el criterio, la decisión igual de válida es cerrarlo y documentar por qué, no dejarlo en pausa indefinida esperando que las condiciones cambien solas.

Mi criterio

Cuándo sí y cuándo no correr un piloto de IA

No todo problema de negocio necesita un piloto de IA, y no toda empresa está lista para correr uno todavía. Estas son las señales que de verdad importan, no las obvias.

Señales de que conviene correr un piloto de IA

• Ya existe evidencia de que la tecnología funciona en general (una POC propia o casos comparables del mercado) y la pregunta pendiente es si funciona con tus datos y tu gente.
• Hay un proceso de negocio acotado y medible donde probarlo, como una sede, un turno o un segmento de clientes, y no la intención de arreglar toda un área de un salto.
• Existe un responsable dispuesto a poner fecha de cierre y a tomar la decisión de escalar o cancelar con esa fecha ya fijada.
• El equipo que va a operar el sistema todos los días participa desde el piloto, y no se entera cuando ya está en producción.
• La empresa puede tolerar que el piloto falle sin que eso cueste la reputación o la operación completa.

Señales de que no deberías correr un piloto todavía

• El proceso que se quiere intervenir no está documentado ni es consistente entre sedes o turnos; primero hay que ordenar el proceso, después probar la IA sobre él.
• Nadie puede nombrar la métrica de negocio que el piloto tiene que mover; sin eso, cualquier resultado se puede justificar después de visto.
• La decisión real ya está tomada de antemano (esto se va a implementar sí o sí) y el piloto solo existe para justificar una compra ya hecha.
• No hay presupuesto ni tiempo del equipo de negocio para participar; solo el área de tecnología está involucrada en el proceso.
• Los datos disponibles son de mala calidad o insuficientes, y el plan es arreglarlos durante el piloto; eso convierte el piloto en un proyecto de datos disfrazado de otra cosa.

El piloto como el lugar más barato para equivocarse

El orden que funciona en un piloto de IA es el mismo que funciona en cualquier decisión seria de negocio: primero el dolor operativo real que se quiere resolver, después el proceso que hay que ajustar alrededor de ese dolor, después los datos que hacen falta para sostenerlo, y solo al final la herramienta. Cuando una empresa invierte ese orden, eligiendo primero la herramienta y buscando después dónde meterla, el piloto se convierte en la búsqueda de un problema para una solución ya comprada, y esos son los pilotos que más tiempo tardan en fracasar, porque nadie quiere admitir que empezaron al revés.

Un piloto de IA no es el lugar para lucirse ni para demostrar que la tecnología es impresionante: es el espacio más barato que va a tener la empresa para equivocarse antes de comprometer presupuesto y reputación en toda la operación. Tratarlo como tal, con criterio de éxito escrito, alcance acotado y fecha de cierre, es la diferencia entre aprender rápido y quedar atrapado, durante años, en un experimento que nadie se atrevió a cerrar.