Por qué el piloto de IA no llega a producción: los cuatro bloqueos que no son del modelo
Ochenta y ocho por ciento de las grandes empresas brasileñas ya tienen alguna iniciativa de inteligencia artificial. Cuarenta y ocho por ciento siguen en piloto.
Los dos números son de la encuesta Antes de TI, a Estratégia 2026, hecha por IT Forum con 243 grandes empresas, y juntos describen una situación específica: la mitad del mercado probó que la cosa funciona y no logró ponerla en producción. No es escepticismo. Es un atasco.
La explicación que circula en los eventos es que falta madurez, o dato, o gente. Nuestra experiencia apunta a otra cosa, menos cómoda: lo que traba el piloto casi nunca tiene que ver con el modelo. Tiene que ver con cuatro asuntos aburridos que nadie quiere discutir en una reunión sobre IA.
Qué cambia entre el piloto y la producción
Vale nombrar la diferencia antes de listar los bloqueos, porque los explica a todos.
En el piloto, una persona está mirando. Elige los casos, revisa el resultado, corrige lo que salió torcido y cuenta la historia en la presentación. El sistema no necesita saber qué hacer cuando no sabe — la persona sabe.
En producción nadie está mirando. El acierto se vuelve asiento, el error se vuelve asiento también, y el descubrimiento ocurre semanas después, en la conciliación. Todo lo que la persona hacía sin darse cuenta tiene que volverse diseño.
Es la misma razón por la cual la autonomía hereda el ambiente: dar autonomía quita el último sensor humano de un ambiente que quizá no tenga ningún otro. Cada uno de los cuatro bloqueos de abajo es un sensor que hay que construir en su lugar.
Bloqueo 1 — ¿con qué identidad actúa?
Es la pregunta que termina más proyectos de IA que cualquier limitación técnica, y suele aparecer tarde: cuando el proceso corre solo, ¿qué usuario firma el asiento?
En el piloto corre con el usuario de quien está demostrando — normalmente con acceso amplio, porque es quien lo construyó. En producción eso no se sostiene: un proceso automático con permisos de persona es un hallazgo de auditoría esperando fecha.
Y entonces la conversación deja de ser sobre IA y se vuelve diseño de perfiles. ¿Qué actividad necesita este proceso? ¿Solo visualizar, o también modificar? ¿Sobre qué datos, de qué sociedades? ¿Quién responde por lo que haga?
Es un trabajo conocido, pero es otro trabajo — y es donde la mayoría de los pilotos descubre que nadie reservó tiempo para él. Conviene entender antes cómo catálogo, espacio y actividad dividen un perfil, porque las tres capas aparecen aquí.
Bloqueo 2 — ¿qué pasa cuando lo mismo llega dos veces?
El piloto procesa una lista. Producción recibe eventos, y el evento se repite: el tiempo límite se agotó del otro lado, la cola reenvió, alguien reprocesó un mensaje que ya había pasado.
Un proceso determinístico repetido genera un duplicado, lo que ya es malo. Un proceso con IA repetido puede generar un duplicado distinto — porque no hay garantía de que la segunda pasada decida como la primera. Eso convierte un problema conocido en uno que nadie sabe investigar.
La solución es la misma de cualquier integración seria — una clave que identifica la operación y una respuesta de «ya lo procesé» —, y hay que decidirla antes, no después. El mecanismo está detallado en pedido facturado dos veces: por qué el mismo mensaje llega dos veces.
Bloqueo 3 — ¿adónde va lo que no resuelve?
Todo piloto tiene una tasa de acierto y siempre es buena, porque los casos fueron elegidos. En producción llega el resto: el documento ilegible, el proveedor nuevo, el caso que no estaba en la muestra.
La pregunta que decide si va a producción no es «cuál es la tasa de acierto», es «qué pasa con los que no acierta». Tiene que existir una cola de excepción con dueño, plazo y un camino de vuelta — y alguien tiene que aceptar que esa cola existe.
Los proyectos que prometieron automatización total suelen trabarse justo aquí, porque asumir la cola de excepción parece asumir fracaso. No lo es: es la diferencia entre un sistema honesto y uno que esconde el problema hasta la conciliación.
Bloqueo 4 — ¿quién explica la decisión dentro de seis meses?
La auditoría no pregunta si el modelo es bueno. Pregunta por qué ese documento fue clasificado de esa manera, en marzo.
Si la respuesta depende de correrlo de nuevo y esperar que dé igual, no hay respuesta. Producción exige registrar la decisión junto con lo que la sustentó: qué entrada, qué versión, qué regla, cuál fue la alternativa descartada. Eso es log, no es IA — pero es obligación de quien pone un proceso automático encima de dato fiscal o contable.
Lo que sale mal, con nombre
Elegir el caso por la facilidad técnica. El primer piloto suele ser el más fácil de demostrar, no el que más dolía. Funciona, encanta, y no genera presión para resolver los cuatro bloqueos — porque nadie lo extraña en producción.
Medir el piloto por la tasa de acierto. Es la métrica del laboratorio. La métrica de producción es costo por transacción, tiempo hasta detectar el error y tamaño de la cola de excepción.
Dejar la seguridad para el final. Cuando la identidad del proceso entra en discusión después del piloto terminado, el resultado suele ser rehacer el diseño — o subir con permisos de más, que es peor.
Prometer que no habrá excepciones. Se compra aprobación y se pierde credibilidad el primer mes.
Tratar el dato malo como problema de la IA. Un maestro inconsistente tumba un proceso automático con o sin modelo. Si el piloto brilló, hay buena chance de que haya corrido sobre una muestra limpia que no representa la base.
El límite honesto
Nada de esto es argumento contra la IA — es la lista de lo que separa un buen experimento de un sistema. Las cuatro preguntas son las mismas que se le hacen a cualquier automatización; la diferencia es que con IA se saltan con más frecuencia, porque la demostración impresiona y la conversación se va al modelo.
También es honesto decir que resolver los cuatro no garantiza retorno. Un proceso automático bien construido sobre un proceso de negocio malo entrega el mismo resultado malo, más rápido. La pregunta anterior a todas — ¿este proceso debería existir así? — sigue siendo de personas.
Y hay una consecuencia de plazo que cambia la planificación: el trabajo de los cuatro bloqueos suele ser mayor que el del piloto. Planificar la entrada en producción como «dos semanas más después de la prueba de concepto» es planificar mal.
Si el punto de partida es entender el ambiente antes de automatizar cualquier cosa dentro de él, empiece por el diagnóstico de TI. Para ver IA aplicada a un proceso real, con el límite dicho de frente, vea leer el XML y contabilizar dentro de SAP. Y para el panorama de arquitectura, el desafío no es el modelo, es la arquitectura.