Por qué tu piloto de IA nunca llegó a producción (y cómo evitarlo)
Por qué tu piloto de IA no llega a producción: faltan harness, memoria, evals, dueño y aprobación. Una checklist práctica para cruzar la brecha sin sorpresas.
El problemaEl piloto de IA funcionó en la demo, pero lleva meses sin que nadie lo use de verdad.
Hace seis meses, el director comercial presentó al comité un piloto de IA que redactaba respuestas a clientes en segundos. La demo fue impecable. Hoy, el piloto sigue en una carpeta compartida, lo usan dos personas de vez en cuando y nadie sabe exactamente cuánto cuesta al mes. Pasar de un piloto de IA a producción resultó ser otro proyecto, uno que nadie había presupuestado.
Si te suena, no estás solo. Una encuesta de marzo de 2026 a 650 líderes tecnológicos encontró que 78% tiene al menos un piloto de agentes, pero solo 14% lo ha escalado a toda la organización. La brecha entre "funciona en la demo" y "lo usa la empresa" es hoy el problema más común de la IA empresarial.
La causa real: un piloto prueba el modelo, no el sistema
Un piloto típico responde una pregunta: "¿puede un modelo hacer esta tarea?". Casi siempre la respuesta es sí. Pero producción exige responder otras preguntas que el piloto nunca tocó: qué pasa cuando falla, quién lo aprueba, cómo sabemos que lo hace bien, cuánto cuesta a escala, quién lo mantiene.
En 2026 se popularizó una fórmula que lo explica: Agente = Modelo + Harness. El modelo es el motor; el harness es todo lo demás: las herramientas, la memoria, las reglas, las verificaciones y los controles que convierten un modelo en algo confiable. Si quieres el detalle, lo explicamos en qué es el harness engineering. La mayoría de los pilotos son solo modelo.
Las seis razones por las que se atora un piloto
1. No hay harness
El piloto llama al modelo y muestra la respuesta. No maneja errores, no reintenta, no valida el resultado. El reporte State of AI Engineering 2026 de Datadog encontró que 5% de las llamadas a modelos en producción devolvieron error, y que límites de capacidad, rate limits y timeouts explicaban 60% de esos errores. En una demo no lo notas; con miles de tareas al día, sí.
2. No hay memoria
Cada conversación empieza de cero. El agente no sabe quién es el cliente, qué se le prometió ni qué reglas aplican. El equipo termina copiando contexto a mano y abandona la herramienta.
3. No hay evals
Nadie definió qué es una respuesta "buena". Sin evals (pruebas que miden la calidad del agente con casos reales antes de cada cambio) no puedes demostrar que funciona ni detectar cuándo empeora.
4. No hay dueño
El piloto lo hizo un equipo de innovación o un proveedor, pero el proceso pertenece a otra área. Cuando termina la demo, nadie tiene la responsabilidad ni el incentivo de llevarlo a producción.
5. No hay flujo de aprobación
Para que una empresa confíe en un agente, alguien con autoridad tiene que revisar lo que sale hacia el cliente, al menos al principio. Si el piloto no tiene ese punto de control, el área legal o el director del área lo bloquea, con razón.
6. Los costos sorprenden
En el piloto, el gasto en modelos era insignificante. A escala, sin topes por tarea ni monitoreo, la factura aparece de golpe y el proyecto se congela mientras alguien la explica.
Checklist para cruzar la brecha del piloto a producción
Antes de declarar que un piloto "funcionó", revisa que tenga respuesta para cada punto. Si falta alguno, ahí está tu siguiente trabajo.
- Proceso y dueño definidos. Un proceso concreto, con una persona responsable del resultado en el negocio.
- Criterios de éxito medibles. Tiempo por tarea, tasa de errores, volumen atendido, satisfacción. Con la línea base de hoy.
- Set de evals. Un conjunto de casos reales, incluidos los difíciles, con lo que se considera una buena respuesta.
- Memoria del negocio conectada. El agente consulta la ficha del cliente, las reglas y el historial, no un documento pegado a mano.
- Aprobación humana por rol. Quién revisa qué, en qué momento y con qué permisos. El detalle está en aprobación humana por rol.
- Manejo de errores. Reintentos, alternativas de modelo y qué hacer cuando nada funciona: escalar a una persona.
- Observabilidad. Poder ver cada paso que dio el agente, qué consultó y por qué decidió lo que decidió.
- Control de costos. Tope de gasto por tarea y por flujo, con alertas antes de que se rebase.
- Seguridad y permisos mínimos. El agente accede solo a lo que necesita para su tarea.
- Plan de adopción. Capacitación breve, canal de soporte y un periodo de convivencia con el proceso anterior.
Ejemplo ilustrativo: el mismo piloto, dos destinos
Imagina una empresa de distribución que pilotea un agente para responder consultas de estado de pedido.
Destino A (el habitual). El equipo de innovación conecta un modelo a una exportación de pedidos y lo prueba con veinte preguntas preparadas. Funciona. Al abrirlo a clientes, el agente responde con datos de ayer porque la exportación no se actualiza, no sabe qué hacer con un pedido parcial y nadie revisa lo que dice. Tras dos quejas, se apaga.
Destino B (con harness). Desde el inicio, el piloto tiene como dueño al gerente de servicio al cliente. Se define éxito como "consultas resueltas sin intervención y sin errores de información". Se arma un set de evals con cien consultas reales, incluidas las raras. El agente lee el estado en tiempo real, consulta la ficha del cliente y, cuando detecta un pedido parcial o un reclamo, escala a una persona con todo el contexto. Las primeras semanas, un supervisor aprueba las respuestas sensibles. Hay un tope de gasto por consulta y un tablero de errores. El paso a producción es una decisión basada en datos, no en la impresión de una demo.
La diferencia no fue el modelo. Fue el sistema alrededor. Para profundizar en cómo medir la calidad, revisa evals para agentes en producción.
Errores comunes al llevar un piloto de IA a producción
- Pilotear lo fácil. Un piloto sobre casos perfectos no te dice nada sobre el día a día.
- Medir con anécdotas. "A la gente le gustó" no es un criterio de éxito.
- Dejarlo sin dueño de negocio. Si el área que usa el proceso no lo pide, no va a sobrevivir.
- Ignorar la convivencia. Apagar el proceso anterior el primer día genera miedo y resistencia.
- Atarse a un solo modelo. Cuando ese proveedor falla o cambia precios, tu sistema queda expuesto.
Qué hacer el lunes
Saca tu piloto más prometedor y pásalo por la checklist de arriba. Marca en rojo cada punto sin respuesta. Esa lista es el plan real para llegar a producción, y casi siempre es más corta de lo que parece cuando se ataca con método.
En Addabra construimos sistemas agénticos sobre un harness ya probado en producción: memoria del negocio, evals, aprobación por rol, observabilidad y control de costos vienen de serie, no como proyecto aparte. Si tienes un piloto atorado, podemos ayudarte a diagnosticar qué le falta y llevarlo al día a día de tu equipo.
Preguntas frecuentes
¿Cuánto debería durar un piloto de IA?
Lo suficiente para medir el proceso real con datos reales, no para impresionar en una demo. Lo importante es que desde el inicio tenga criterios de éxito, un dueño y una fecha para decidir si pasa a producción o se descarta.
¿Por qué el piloto funcionaba bien y en producción falla?
Porque el piloto suele correr sobre casos escogidos, sin volumen y con alguien vigilando. En producción aparecen datos sucios, excepciones, errores de los proveedores de modelos y usuarios que no conocen el sistema. Sin harness, memoria y evals, esos problemas no se detectan a tiempo.
¿Necesito cambiar de modelo para llegar a producción?
Casi nunca es el modelo lo que falla. Lo que falta es el sistema alrededor: control de errores, memoria, evaluación, aprobación humana y control de costos. Con un buen harness puedes además usar el mejor modelo para cada tarea.
