Los pilotos de IA generativa casi nunca fallan por el modelo. Fallan porque nadie es dueño del resultado y porque no existe un criterio medible para promoverlos a producción. La salida es tratar producción como una decisión con gate (compuerta): un responsable, un criterio de éxito acordado antes de construir y una evaluación que puede bloquear el despliegue.
Mientras la aprobación dependa de una demo que convence, el piloto queda atrapado entre el entusiasmo y el riesgo.
¿Qué es un piloto de IA generativa?
Un piloto de IA generativa es un sistema construido con un modelo de lenguaje para probar, en un alcance acotado y con usuarios o datos limitados, que un caso de uso concreto aporta valor antes de invertir en llevarlo a producción. Un piloto no es un producto. No tiene por qué escalar, no tiene por qué ser barato de operar y no tiene por qué sobrevivir a entradas hostiles. Precisamente por eso, el salto de piloto a producción no es un paso más del mismo camino: es un cambio de naturaleza. Lo que en el piloto era aceptable (una respuesta lenta, un permiso amplio, un caso raro sin cubrir) en producción se convierte en un incidente.
El problema aparece cuando nadie hace explícito ese cambio. El piloto funciona en la reunión, el equipo celebra y la conversación pasa directamente a «¿cuándo lo lanzamos?», sin que nadie haya definido qué tendría que ser cierto para lanzarlo. Ahí empieza el limbo: el sistema existe, pero ninguna decisión lo empuja hacia adelante ni lo detiene.
¿Por qué un piloto que funciona en la demo no se despliega?
Las causas que he encontrado de verdad son cuatro, y ninguna tiene que ver con elegir el modelo equivocado. Se refuerzan entre sí: un piloto rara vez cae por una sola, y casi siempre la primera esconde a las demás.
¿Qué pasa cuando no hay criterio de éxito ni evals?
La primera causa es que el piloto se aprueba por demos. Alguien prepara una sesión con preguntas que el sistema responde bien, la audiencia queda convencida y esa impresión se convierte en el único argumento para avanzar. El problema es que una demo mide el mejor caso, no el comportamiento del sistema sobre el conjunto real de entradas que va a recibir. Sin un criterio de éxito escrito antes de construir, nadie puede decir si el piloto ya está listo o si le falta poco o mucho.
Las evals son la respuesta técnica a ese vacío: un conjunto de casos representativos, incluidos los difíciles y los adversariales, con una forma reproducible de puntuar cada respuesta. Cuando existen, la pregunta deja de ser «¿nos gustó?» y pasa a ser «¿cumple el umbral que acordamos?».
¿Por qué los datos casi nunca están listos?
La segunda causa son los datos. En el piloto se trabaja con un extracto limpio, a veces preparado a mano, y con permisos amplios para no frenar el avance. En producción, el sistema tiene que leer de los sistemas reales, con su calidad real, sus vacíos y sus inconsistencias. Aparecen preguntas que el piloto pudo esquivar: quién puede ver qué, qué datos personales llegan al modelo, cómo se respeta la privacidad, qué sistemas exponen la información que el caso necesita y con qué latencia.
Ninguna es exótica, pero todas toman tiempo y requieren a personas que no estaban en la demo. Si se descubren después de la aprobación, el piloto queda esperando a que otro equipo priorice un trabajo que nadie le pidió a tiempo.
¿Por qué la seguridad y el compliance llegan tarde?
La tercera causa es que seguridad y compliance entran al final, cuando el sistema ya está construido, y su revisión frena el despliegue. Es especialmente típico en industrias reguladas, donde un error no es un inconveniente sino un dato expuesto, una recomendación fuera de alcance o una decisión que alguien tiene que poder auditar. Quien revisa no es un obstáculo: hace preguntas legítimas que el piloto nunca tuvo que responder. ¿Qué pasa si alguien intenta extraer las instrucciones del sistema? ¿Se registra cada decisión con su fuente? ¿Puede el agente ver datos que el usuario no tiene permiso de ver?
Si esas preguntas llegan cuando el diseño ya está cerrado, la respuesta honesta suele ser «hay que rehacer una parte». Y ese rehacer, sin un dueño que lo empuje, es justamente donde los pilotos se quedan.
¿Qué es una arquitectura de demo y por qué no escala?
La cuarta causa es la arquitectura de demo: un sistema pensado para mostrar que algo es posible, no para operarlo. En el piloto nadie miró el coste por interacción, la latencia bajo carga, la observabilidad ni la operación diaria. Con el volumen real, el coste se dispara, las respuestas tardan más de lo que el usuario tolera y, cuando algo falla, nadie sabe por qué, porque no hay trazas que permitan reconstruir qué recuperó el sistema, qué decidió y qué respondió.
Una arquitectura de producción no es más compleja por principio: trata coste, latencia y observabilidad como requisitos medidos desde el inicio, con presupuestos explícitos.
¿Cuál es la señal más clara de que un piloto no llegará a producción?
La señal más clara es que nadie es dueño del resultado. No me refiero a quien construyó el piloto ni a quien lo patrocinó en la reunión de aprobación, sino a un responsable de negocio que vaya a operar y medir el sistema después del piloto. Esa persona es la que tiene un motivo real para exigir un criterio de éxito, para conseguir que los datos estén listos, para meter a seguridad en la conversación desde el principio y para preguntar cuánto va a costar cada interacción a escala.
Sin ese dueño, las cuatro causas anteriores no tienen quién las resuelva. El equipo técnico puede construir evals, pero no puede decidir qué umbral es aceptable para el negocio. Puede proponer una arquitectura de producción, pero no puede aprobar el presupuesto de operación. Puede documentar los riesgos, pero no puede aceptarlos en nombre de nadie. Por eso, ante un piloto que no avanza, la primera pregunta útil no es técnica: es quién va a responder por este sistema cuando el piloto termine. Si la respuesta es un silencio, el piloto ya tiene su diagnóstico.
¿Cómo se lleva un piloto de IA generativa a producción?
Mi método tiene cuatro partes, y cada una ataca una de las causas desde el principio en lugar de descubrirla al final. Es la forma de trabajo de un Sprint POC-to-Production con criterio de éxito medible: acotado en alcance y con una decisión de promoción explícita al final.
La primera parte es acotar el alcance y fijar un criterio de éxito medible antes de construir. Qué casos cubre el sistema, cuáles quedan fuera, qué tiene que medir la evaluación y qué umbral convierte un piloto en un sistema promovible. Este acuerdo se hace con el dueño del resultado, por escrito, y es lo que más adelante permite decir que sí o que no sin discusiones de opinión.
La segunda parte es un harness de evaluación que actúa como gate de promoción, con un veredicto capaz de bloquear el despliegue. Si el veredicto no está en verde, el cambio no se promueve. Esto obliga a que la evaluación sea reproducible, a que cubra los casos adversariales y no solo los cómodos, y a que sus resultados se lean por categoría, porque un promedio alto puede esconder un fallo grave en una sola dimensión.
La tercera parte son los guardrails, la gobernanza, el control de acceso y la trazabilidad desde el primer día, en proporción al riesgo del caso de uso. El agente solo debe ver lo que el usuario puede ver; debe rechazar lo que queda fuera de su alcance y escalar lo que corresponde; cada decisión debe dejar un registro con su fuente. Cuando esto se diseña desde el inicio, la revisión de seguridad deja de ser un muro al final y se convierte en una conversación que acompaña la construcción.
La cuarta parte son los presupuestos de coste y latencia, con observabilidad, como criterio de salida. No basta con que el sistema responda bien: tiene que responder bien dentro de un tiempo y un coste por interacción acordados, y tiene que ser posible ver en producción qué está haciendo. Si un cambio mejora la calidad pero rompe el presupuesto, el gate lo detiene igual que si hubiera roto la calidad.
¿Qué pasa cuando el gate dice que no?
El caso que puedo mostrar con números, porque está documentado en público, es el agente de IA para industrias reguladas y su harness adversarial. Es un agente conversacional acotado a fuentes verificadas, construido de forma independiente, que pasa por un harness de evaluación antes de cada promoción a producción.
El harness, la batería de pruebas automáticas que decide si un cambio puede pasar, combina 8 scorers: 5 deterministas, reglas fijas que corren sin modelo, y 3 que usan un modelo como juez para lo que una regla no puede decidir. En la corrida fijada del 2026-07-28, 231 de 319 entradas puntuadas aprueban; las otras 88 arrastran al menos una razón de gate, sobre todo citas faltantes. Además, el gate de coste y latencia falló: la latencia media del corpus fue de 8088 ms frente a un presupuesto de 8000 ms por turno. Es una sola corrida y el presupuesto se mide sobre la media, sin p95; repetir la corrida y medir el p95 es el siguiente paso. El veredicto global es FAIL por ambos motivos, y el cambio medido en esa corrida no se promueve: el sistema en vivo sigue en su última versión aprobada.
No es un detalle menor: es el método funcionando. Un sistema cuyas respuestas convencen, pero que deja afirmaciones sin cita y se sale de su presupuesto de latencia, no está listo para producción según el criterio fijado, y el gate lo dice sin matices. Un gate bien diseñado no deja que una buena demo compense el número. Las excepciones no se negocian en una reunión: se aceptan por escrito. En este agente, el harness detectó un exceso de escalamiento ante frases con negación, y la decisión de aceptarlo quedó en registros de decisión públicos.
Esa es la diferencia entre un piloto con gate y un piloto que se aprueba por demo. Con aprobación por demo, ese cambio podría haber pasado a producción porque las respuestas convencen, y las citas faltantes y la latencia aparecerían frente a usuarios reales. Con gate, aparecen cuando todavía es barato resolverlos.
Un gate que nunca dice que no no es un gate. Un veredicto en rojo, publicado y con causas concretas, es la mejor prueba de que la decisión de producción la toma el criterio y no el entusiasmo.
¿Qué responder antes del próximo piloto, o si el tuyo ya está atascado?
Las mismas preguntas sirven antes de escribir una línea de código y para diagnosticar un piloto que ya no avanza:
- ¿Quién es el dueño del resultado y va a operar el sistema después?
- ¿Qué criterio medible lo vuelve promovible, y con qué casos se va a evaluar?
- ¿Qué datos necesita, quién puede verlos y en qué estado están?
- ¿Qué revisión de seguridad y compliance tiene que pasar, y quién la hace?
- ¿Cuál es el presupuesto de coste y latencia por interacción, y cómo se observa en producción?
Si el piloto ya está atascado, el orden de trabajo es el de un Sprint POC-to-Production que encuentra el bloqueo real: primero, diagnosticar cuál de las causas lo frena; después, acordar por escrito con el dueño del resultado qué significa «listo para producción» y cómo se mide; y al final, poner un gate delante de la promoción.
Producción no es el premio a una demo que convence. Es una decisión con gate, tomada por alguien que es dueño del resultado, contra un criterio que se acordó antes de construir. Cuando eso existe, el modelo casi nunca es el problema.