¿Por qué fracasan los pilotos de IA en las empresas?

El patrón se repite: una demostración consigue presupuesto, el piloto entrega un resultado y seis meses después ningún proceso lo utiliza. En los casos que he visto de cerca aparecen cuatro errores de diseño que ya existían al firmar. El modelo de IA rara vez explica por sí solo el desenlace.

Error uno: comprar producto para un problema en fase custom

El primer error ocurre al clasificar lo que se compra.

En un mapa de Wardley, cada componente está en una fase: génesis, custom, producto o utility. Comprar tiene sentido cuando el componente está estandarizado. Los modelos se compran por API. En cambio, hacer que un agente opere un proceso de la empresa exige conocer sus excepciones y decisiones no escritas. Ese eslabón sigue en fase custom.

El proveedor tiene incentivos para vender ese eslabón como un producto repetible. Es la abstracción prematura descrita en el manifiesto de la fase custom. Durante el piloto, el producto cubre el flujo estándar, mientras las excepciones quedan fuera o requieren trabajo adicional. Comprar puede ser correcto, igual que construir o contratar la operación. Comparo las tres opciones en cómo decidir el modelo de provisión.

Error dos: pilotos sin dueño del proceso

Mira quién promueve el piloto. Si innovación, sistemas o un comité gestionan el proyecto y el responsable del proceso solo participa como invitado, falta autoridad para cambiar la operación.

Un agente obliga a eliminar pasos, redefinir decisiones y documentar excepciones. Solo el responsable del proceso puede aprobar esos cambios y responder por ellos. Sin esa persona, el piloto funciona en paralelo a la operación y no sustituye ningún paso. Cuando termina el presupuesto, tampoco existe un área responsable de mantenerlo.

La versión inversa también existe y falla igual: el dueño del proceso entusiasmado pero sin capacidad técnica ni mandato de dirección, comprando por su cuenta. Piloto y proceso necesitan al mismo dueño, con presupuesto y con autoridad para cambiar cómo se trabaja.

Error tres: la demo usa datos preparados

Las demostraciones se ensayan con datos completos, casos previstos y sistemas disponibles. Sirven para enseñar una función. El problema aparece cuando el piloto también se limita a un subconjunto seleccionado y condiciones controladas.

Ese diseño no informa sobre el campo que se usa con otro significado, el pedido que llega por correo fuera del catálogo o la excepción que conoce una sola persona. Evitarlos pospone el trabajo de documentar y codificar la operación. Esa es la tesis de el modelo operativo como código, y el piloto puede ser su primera fase.

La regla que aplico es usar desde el primer día una muestra representativa de producción e incluir a propósito excepciones conocidas. Si el piloto no descubre ninguna regla no documentada, conviene revisar si el alcance representa el proceso completo.

Error cuatro: definir el éxito como “funciona” en vez de “opera”

Este error se introduce al redactar los criterios de éxito.

“Funciona” significa que, en condiciones de prueba, el sistema hace lo que se esperaba. “Opera” significa que lleva el proceso semana tras semana, con volumen real, con permisos definidos en tus sistemas, con sus acciones trazadas, con las excepciones escalando a personas concretas, y con alguien de la casa que responde por él como se responde por un equipo. La distancia entre lo uno y lo otro es la distancia entre un agente que responde y un agente que opera, que es la línea divisoria de todo lo que escribo sobre agentes de IA en operaciones.

Si “funciona” basta para cerrar el piloto, el proyecto puede terminar sin un paso a producción. Los criterios deben indicar qué volumen ha procesado, qué porcentaje escaló a personas, qué permisos ejerció, qué reglas descubrió y qué condiciones faltan para mantenerlo encendido bajo responsabilidad del dueño del proceso.

El piloto diseñado para convertirse en operación

El piloto no solo prueba el modelo. Debe comprobar si el proceso está definido, si tiene responsable y si la empresa puede gobernar a un agente con permisos.

El diseño resultante tiene un responsable, datos representativos, permisos acotados, trazabilidad desde el inicio y éxito definido como operación sostenida a pequeña escala. Describo las condiciones previas en preparar tu empresa para agentes. También puede concluir que no compensa seguir. En ese caso debe dejar una causa documentada y evidencia para decidir.

Preguntas que me hacen los comités

Ya hemos quemado dos pilotos. ¿Lo intentamos con otro proveedor?

Antes de cambiar de proveedor, revisa cuatro puntos: responsable del proceso, datos representativos, éxito definido como operación y clasificación buy/custom. Si alguno falló, cambiar solo el proveedor no corrige la causa.

¿Un piloto no debería ser barato y rápido?

Debe ser acotado en alcance y utilizar condiciones de producción. Un proceso pequeño con datos representativos y permisos limitados informa más que diez procesos con datos seleccionados. Repetir un piloto que no prueba la operación consume presupuesto y reduce el apoyo interno al siguiente intento.

¿Cómo elegimos el proceso del piloto?

Tres condiciones: responsable con autoridad, resultado verificable y excepciones frecuentes pero acotadas. El primer piloto debe priorizar esas condiciones sobre el impacto potencial, porque también construye la capacidad de operar agentes que se reutilizará después.

¿Qué métricas le ponemos?

Métricas de operación, no de demostración: volumen real procesado de principio a fin, tasa de escalado a personas y su tendencia, incidentes con permisos ejercidos, reglas no documentadas descubiertas y codificadas. Y una métrica de decisión: qué evidencia necesitaríamos para ampliar, mantener o parar. Si esa última no está escrita antes de empezar, el piloto acabará decidiéndose por sensaciones.