Un piloto de IA llega a producción cuando tiene tres cosas: un dueño que responde por el resultado del negocio, un número con línea base y plazo, y un proceso rediseñado para trabajar con el agente. Sin las tres, se queda en demo.
Si tienes una inversión de IA sobre la mesa y todavía no la autorizas, hay una pregunta que conviene contestar antes que cualquier otra: ¿contra qué número la vas a medir?
Casi nadie la contesta antes de firmar. Se autoriza algo que promete mejorar un proceso sin haber puesto en números cómo está ese proceso hoy: cuánto cuesta, cuánto tarda, cuánto margen se va en él. Y lo que viene después ya lo describió Gartner en abril de 2026: al menos 50% de los proyectos de IA generativa se abandonan después de la prueba de concepto, por datos de mala calidad, controles de riesgo insuficientes, costos que escalan o valor de negocio poco claro. Ninguna de las cuatro causas es tecnológica.
Nosotros no llegamos a esta conclusión leyendo estudios. La primera empresa a la que le rediseñamos un proceso para que un agente pudiera trabajar sobre él fue la nuestra, y ahí aprendimos la parte cara: la tecnología casi nunca es lo que falla; falla el proceso al que la conectaste. Por eso no entramos por la tecnología, sino por el proceso que mueve tus números.
Este artículo responde una sola pregunta: ¿qué tiene que estar en su lugar, antes de autorizar, para que un piloto cruce a producción en vez de quedarse en demo? Son tres cosas. Y la primera es ese número.
Antes de autorizar: contra qué número lo vas a medir
El número de partida no es un entregable del proyecto. Es un requisito para autorizarlo. Se toma antes, sobre el proceso como está hoy, y es la única cifra contra la que va a poder compararse todo lo que venga después.
No hace falta un tablero. Hacen falta tres datos del proceso que la inversión promete mejorar:
- Cuánto mueve al mes: ingresos que dependen de él, o costo directo de correrlo.
- Cuánto tarda hoy: el ciclo completo, de punta a punta, no el paso que más duele.
- Cuánto margen se queda en él: reprocesos, esperas, correcciones.
Con esos tres puedes hacer la cuenta que casi nunca se hace: multiplica lo que mueve el proceso al mes por el porcentaje que la iniciativa promete mover, por los meses que va a tardar en dar señal. Ese es el valor en juego, y también el costo de no decidir, porque mientras el proyecto no cruza, el proceso sigue dejando ese dinero en la mesa.
Súmale lo que no es contable y sí es real: el trimestre de atención directiva que consume, y que la siguiente inversión de IA ya nace con sospecha en el consejo.
Una dirección que no puede decir en dinero qué va a cambiar no está evaluando una inversión: está opinando sobre ella. Esa es la diferencia entre decidir con anticipación y explicar el resultado después.
¿Qué significa exactamente «en producción»?
Un agente está en producción cuando el proceso ya no puede correr sin él. No cuando funciona, no cuando el equipo lo usa "cuando se acuerda": cuando quitarlo obligaría a rehacer el flujo.
Esa es la línea que separa a un piloto de un sistema. Un piloto corre en paralelo al proceso real y por eso es reversible sin consecuencias, y por eso también es invisible en el estado de resultados. Un agente en producción está dentro del flujo, con permisos, con trazabilidad y con alguien que responde cuando falla.
¿Y cuánto tarda poner un agente de IA en producción? En nuestra línea de entrada el alcance declarado es 90 días o menos para el primer agente sobre un proceso real. No es una promesa de resultado: es un límite de alcance. Si un primer caso necesita más de un trimestre para dar señal, casi siempre es porque se eligió un proceso demasiado grande, no porque la tecnología sea lenta.
Condición 1 · El proceso rediseñado para trabajar con el agente
La causa número uno de que un piloto no cruce es haberle pedido a una herramienta nueva que corriera sobre una forma de trabajar vieja. El piloto hereda los pasos que existían solo porque antes no había datos: la validación manual que compensaba un sistema que no conversaba con otro, el reporte que alguien armaba porque nadie confiaba en el anterior, la doble captura que nació de un error de hace ocho años.
Automatizar eso no lo arregla. Lo acelera.
Lo vimos con claridad en el caso que más citamos: una embotelladora líder en México con vacantes críticas abiertas casi dos meses, donde cada semana sin cubrir se traducía en línea detenida y horas extra. La primera opción sobre la mesa era automatizar el proceso de reclutamiento tal como estaba. Se descartó. Habría producido el mismo flujo, más rápido y más caro de mantener. Se rediseñó el flujo completo primero y los agentes entraron después, sobre filtrado, evaluación y coordinación.
Esa decisión, la de no automatizar lo que ya existía, es la que explica el resultado. Y es la que más resistencia genera, porque obliga a tocar la forma de trabajar antes de haber visto el beneficio. Por eso es una condición de autorización y no un ajuste sobre la marcha: si el rediseño no está aceptado antes de firmar, no va a aceptarse después.
Rediseñar el proceso antes de automatizarlo también significa decidir qué pasa con lo que sobra y con lo que falta. Hay pasos que desaparecen porque ya no tienen razón de existir una vez que el agente asume el trabajo, y hay pasos nuevos que aparecen porque el proceso rediseñado los necesita: revisión de excepciones, ajuste de reglas, supervisión del agente. Algunos puestos que hoy operan el proceso dejan de tener sentido tal como están definidos después de la implementación, y esa conversación se tiene antes de firmar, no se descubre después. La pregunta que sigue nunca es cuánta gente sobra: es qué se hace con el tiempo que se libera y a qué proceso de valor se redirige ese talento. Por eso nunca se automatiza a una persona. Se automatiza un proceso, y a la persona se le asigna otro que sí mueve el número.
El estudio del MIT de 2025 trae el hallazgo más incómodo de este tema: la enorme mayoría de los pilotos de IA generativa en empresas no producía retorno medible en el estado de resultados, y la causa raíz no era la calidad de los modelos, sino qué tan integrados estaban al flujo de trabajo. Los que sí generaban valor eran los que se metieron dentro del proceso, no al lado.
Condición 2 · Un dueño de negocio que responda por el resultado
Si el dueño del proyecto es sistemas, se aprobó una herramienta, no un cambio en cómo se gana dinero. Y una herramienta no tiene por qué mover un número: no es su trabajo.
El dueño de un caso de IA es quien responde por el proceso ante la dirección. El de cobranza, si el caso es cobranza. El de planta, si es planta. Sistemas construye, habilita y controla; no puede responder por un resultado comercial que no gobierna.
Aquí es donde entra el gobierno y control de agentes de IA en producción, que es lo que un consejo pregunta antes de aprobar y casi nadie lleva contestado: quién puede ver qué, qué queda registrado, qué decisiones toma el agente solo y cuáles requieren un humano.
Agentes de IA con humano en el loop no es una concesión al miedo: es diseño. El punto de confirmación humana se define desde el arranque, no se agrega después de un susto: cuando se coloca al final como parche, el equipo lo usa dos semanas y luego lo salta.
Condición 3 · La línea base, tomada antes de empezar
Sin el número de antes, no hay forma de defender el número de después. Es la condición más silenciosa de las tres, porque no rompe nada: solo deja al proyecto sin manera de ganar.
Un piloto sin línea base entra en un limbo cómodo. No gana ni pierde: sobrevive. Tres meses después nadie puede decir si mejoró, no porque no haya mejorado, sino porque no hay contra qué compararlo. Y reconstruir la línea base al final no sirve: el consejo sabe distinguir entre un número medido y un número recordado.
¿Cómo medir el desempeño de un agente de IA? Con una sola métrica de negocio, tomada antes de empezar y con fecha de corte en el calendario. Una, no un tablero. Nosotros lo decimos así en cada caso que entregamos:
No reportamos horas ahorradas. Reportamos ingresos recuperados, tiempo de ciclo, costo por transacción y capacidad ganada sin sumar estructura, con línea base tomada antes de empezar y revisión con la dirección en cada fase.
Ese es también el criterio de arranque: un caso sin línea base no se empieza. Es la conversación más incómoda de la primera semana y la que evita la discusión imposible del mes seis.
Qué se ve distinto cuando sí cruza
Un caso que cruza se reconoce por su tamaño, no por su tecnología: alcance chico, número grande, dueño con nombre y fecha de corte.
En la embotelladora, el ciclo de reclutamiento pasó de 50 a 10 días (-80%), con las posiciones críticas cubiertas 40 días antes. El dato se pudo afirmar porque la línea base existía desde el día 0. La tecnología no fue la parte difícil.
Las tres condiciones se sostienen entre sí, y por eso fallan juntas. El dueño de negocio es quien acepta rediseñar el proceso, porque es el único con autoridad para cambiar cómo trabaja su área. El proceso rediseñado es lo que hace que el número se mueva de verdad. Y la línea base es lo que permite probarlo ante quien autorizó la inversión.
Quítale una y las otras dos dejan de servir: un proceso rediseñado sin dueño se revierte en tres meses; un dueño con línea base pero sin rediseño defiende un número que no se movió; y un rediseño con dueño pero sin línea base produce una mejora que nadie puede acreditar.
Por eso el orden importa. Primero dónde se está quedando el dinero y con qué línea base. Recién después, qué se automatiza y en qué orden.
Qué hacer el lunes
- Toma el número de partida del proceso que estás por autorizar. Cuánto mueve al mes, cuánto tarda, cuánto margen se queda en él. Si no puedes escribirlo en una línea, ese es el hallazgo, y es razón suficiente para no firmar todavía.
- Ponle nombre y apellido al dueño del proceso, no del proyecto. Si el nombre es de sistemas, todavía no hay dueño.
- Marca en el flujo actual los pasos que existen solo porque antes no había datos. Esos son los candidatos a desaparecer, no a automatizarse.
- Define la fecha de corte: si al día X no está el número, se para. Escríbela en el calendario y comunícala; si solo vive en la minuta, no existe.
Empieza por dónde estás
La pregunta útil no es si la IA sirve. Es cuál de las tres condiciones te falta hoy: antes de autorizar, o en el caso que ya tienes andando.
Nuestro autodiagnóstico son 14 preguntas y cinco minutos, y sales con la lectura de dónde está tu empresa frente a la IA: madurez de datos y madurez de negocio por separado, para que veas el desbalance.
Si ya sabes cuál es el proceso y lo que falta es el número, ahí empieza un Agentic Discovery: diagnóstico, caso de negocio y un primer agente en producción, con el retorno estimado sobre la mesa antes de autorizar.
Para ir más a fondo:
- El método completo, fase por fase: cómo trabajamos en Neurya
- Qué pasa después del primer caso: Transformación Agéntica
Casos documentados por industria disponibles bajo acuerdo de confidencialidad.
Preguntas frecuentes
¿Cuánto debe durar un piloto de IA?
Un primer caso debe dar señal en 90 días o menos. Si necesita más de un trimestre, el problema casi siempre es el alcance: se eligió un proceso demasiado grande o con demasiados dueños. Achica el alcance antes de extender el plazo.
¿Quién debe ser el dueño de un proyecto de IA?
Quien responde por el proceso ante la dirección, no quien lo construye. Si es cobranza, el responsable de cobranza. Sistemas habilita, controla y sostiene el sistema, pero no puede responder por un resultado de negocio que no gobierna.
¿Qué diferencia hay entre un piloto y un Quick Win?
Un piloto prueba si la tecnología funciona. Un Quick Win prueba si el negocio mejora: corre sobre un proceso real, con línea base, dueño de negocio y fecha de corte, y entrega un número propio en 90 días o menos.