Una demo no es un agente en producción

Una POC que funciona todavía no está lista para producción. Falta el sistema que la demo no necesitaba: identidad y permisos, estado y recuperación, trazas y evaluación, límite de coste y un responsable con nombre.

Una demo está bien, pero ¿escala? Casi nunca a la primera, y rara vez por culpa del modelo. Una POC (prueba de concepto) responde bien porque juega en casa: datos limpios, permisos abiertos y alguien al lado que reformula la pregunta cuando el modelo se despista. Llevar un agente de IA a producción consiste en añadir todo lo que la demo no necesitaba: identidad y permisos, estado y recuperación, trazas y evaluación, límite de coste y un responsable con nombre. Si te falta alguna de esas piezas, el siguiente paso no es desplegar. Es recortar el alcance hasta que el sistema se pueda operar.

El patrón que vemos en casi todas las reuniones

El guion se repite tanto que ya lo recitamos de memoria. Alguien detecta una oportunidad, alguien monta una prueba en dos semanas, la prueba convence a todo el comité, y entonces llega la pregunta que congela la sala: ¿y esto lo enchufamos a los datos reales de los clientes?

Ahí se ve lo que había en realidad, que no era un agente sino un prototipo con suerte. Vive en un entorno con acceso total, un dataset amable y supervisión humana permanente. Funciona porque las condiciones son blandas. La demo no miente: está diseñada para lucir, y lo hace muy bien.

Lo que viene después casi nunca entra en la presentación. Permisos por tenant, trazas para auditar, regresiones cuando cambia el modelo, factura por ejecución, alguien de guardia. El equipo estima ese trabajo, lo compara con el roadmap que ya tiene comprometido y decide que ya lo verá el trimestre que viene. El piloto se queda meses en el limbo. No falló el modelo. Faltó el sistema alrededor.

Tampoco es un problema exclusivo de la IA. La investigación de entrega de software de DORA lleva años midiendo lo mismo en cada ola tecnológica: lo que determina si algo llega a producción y se sostiene ahí son las capacidades de entrega del equipo, no la herramienta que se compró. Con agentes de IA en producción pasa exactamente igual, solo que la factura llega antes.

Demo, piloto y producción: tres estados distintos

Antes de discutir arquitectura, pon nombre al estado en el que estás. La conversación demo vs producción de agentes IA no es un debate de vocabulario: cada estado tiene otro nivel de riesgo, otra forma de medirse y otro dueño.

Demo. Objetivo: credibilidad. Datos controlados, camino conocido y una persona vigilando. Autoriza a seguir invirtiendo tiempo en el caso. No autoriza a tocar datos de cliente.

Piloto. Objetivo: aprender con riesgo acotado. Un tenant, un flujo, una métrica definida antes de empezar, supervisión y fecha de go/no-go en el calendario. Aquí se explica la mitad de las veces por qué falla un piloto de IA: se midió entusiasmo en lugar de resultado, o nunca se puso fecha de corte. Si tu POC lleva cinco meses llamándose piloto, no es un piloto: es un limbo con presupuesto.

Producción. Objetivo: operar. Clientes reales, escritura posible, rollback probado, coste que cabe en el margen del SaaS y alguien que responde el teléfono cuando algo se rompe a las nueve de la mañana.

Una forma corta de recordarlo: la demo convence, el piloto mide, producción responde. Si tu POC agente IA sigue en el primer estado, no la presentes como el tercero. Nombrar el estado en voz alta, delante de negocio y de tecnología, ahorra semanas de conversación cruzada.

Las capas que aparecen después del MVP

Cuando intentas cruzar de piloto a producción aparecen capas que ningún prompt resuelve. Anthropic lo resume bien en Building effective agents: lo que hace fiable a un agente es el sistema que lo rodea, no el modelo suelto. Estas son las cuatro capas que más despliegues nos han frenado.

Autenticación y permisos

Qué identidad usa el agente, qué puede leer, qué puede modificar y cómo se aíslan los tenants entre sí. El prompt no es un control de acceso, por muy bien redactado que esté. Si el usuario no puede borrar una factura, el agente que actúa en su nombre tampoco debería poder.

La regla es mínimo privilegio, con scopes definidos por tool y por tenant, e identidad propia del agente para que cada acción sea auditable. Si tus tools tienen más acceso que el rol del humano, no has añadido una función: has abierto un boquete con muy buena interfaz. Esa capa es justo lo que cubre el harness de agentes de Devic.

Estado, errores y recuperación

Un agente que se cae a mitad de trayectoria no deja un error limpio: deja trabajo a medias. Media factura emitida, medio ticket escalado, medio registro actualizado. Eso exige contrato explícito de cada tool (qué entra, qué sale, qué pasa cuando falla), estado que sobreviva al corte, idempotencia (repetir la misma llamada no duplica el efecto) y rollback.

Sin esa capa, cada incidencia se convierte en un ticket urgente y en un correo de disculpa. Y el coste real no es el incidente, es la confianza del cliente que ya había empezado a delegar. Si además necesitas construir la interfaz de ese flujo, ahí entran los componentes React de Devic UI.

Observabilidad y evaluación

Si no puedes reproducir la respuesta mala de ayer, no tienes un agente en producción: tienes una caja negra en buena racha. Necesitas trazas de las tool calls, versión de prompt y de modelo registradas, y evals (evaluaciones automatizadas y repetibles) que corran en staging sobre casos reales anonimizados.

El umbral de aprobación lo acuerda producto antes del deploy, no el equipo técnico la tarde del despliegue. Y "parece que va bien" no es un criterio de aceptación: es una sensación. Cuando cambies de modelo, esa misma batería es lo único que te dirá si has mejorado o si has roto tres casos que ya funcionaban.

Costes y ownership

El precio por token no es el coste de tu agente. Lo que necesita un SaaS es coste por ejecución y por tenant, con límite, alerta antes del límite, kill switch (interruptor de apagado), runbook de incidencias y una persona de guardia con nombre.

Sin límite, un bucle mal cerrado se come en una tarde el margen del mes. Sin dueño, el piloto se pudre solo: nadie lo mata y nadie lo mejora. Para aterrizar límites y modelo de coste, mira los planes de Devic y su límite de tool calls.

Qué debe probarse antes de permitir escritura

Pasar de lectura a escritura por presión comercial es el atajo más caro del sector. La escritura es el punto de no retorno: el agente deja de sugerir y empieza a modificar datos que el cliente factura, audita o presenta a su consejo.

Antes de abrir escritura, como mínimo:

1. Permisos y scopes de cada tool validados por tenant, sin más acceso que el rol del usuario que la invoca.

2. Evals en verde en staging, con casos reales anonimizados y un umbral acordado con producto por escrito.

3. Runbook de rollback, kill switch y owner de guardia, probados al menos una vez de verdad, no en teoría.

Si falta uno de los tres, el agente sigue en modo lectura. Eso no es falta de ambición. Es no querer explicarle a un cliente por qué se le han modificado cuatrocientos registros un viernes por la tarde.

Checklist de preparación para producción

Este es el checklist de agente en producción para SaaS que usamos como go/no-go en la reunión, no como slide de relleno.

• Sabes si estás en demo, piloto o producción, y lo has dicho en voz alta delante de negocio y de tecnología.

• El agente tiene identidad propia y scopes por tenant, revisables por alguien que no los escribió.

• Puedes reproducir un fallo de ayer con traza, versión de prompt y secuencia de tool calls.

• Hay evals con umbral acordado y una batería que se ejecuta cada vez que cambia el modelo o el prompt.

• Conoces el coste medio por ejecución y por tenant, y existe un límite con alerta antes de llegar a él.

• Hay owner, runbook, rollback y kill switch, y alguien los ha probado al menos una vez.

"La demo demuestra que el modelo puede responder. Producción demuestra que el sistema puede operar."

Si marcas menos de cinco, todavía no toca escritura. Toca piloto, y toca decirlo sin adornos en la siguiente reunión de producto.

Señales de que vas demasiado rápido

Estas señales aparecen cuando el equipo confunde velocidad de demo con madurez de producción. Si reconoces dos o más, para y reordena. También explican por qué falla un piloto de IA que en la demo iba fino.

• No sabes cuánto cuesta una ejecución media por cliente, y lo justificas diciendo que "aún es poco volumen".

• Las tools tienen más permisos que el rol del usuario, porque así iba más rápido en desarrollo.

• Nadie del equipo puede reconstruir una respuesta mala de la semana pasada.

• El piloto lleva meses sin métrica acordada ni fecha de go/no-go.

• El caso se eligió porque brillaba en la demo, no porque mueva una métrica del negocio.

La mayoría se corrigen en días si hay plataforma y criterio. Se convierten en meses cuando el equipo reescribe scripts a ciegas y llama iteración al puro prueba y error. Velocidad sin medición, en agentes, es deuda técnica con muy buen copy.

Cuándo empezar pequeño sí es la respuesta correcta

No todos los casos merecen agentes de IA en producción ahora mismo, y decirlo a tiempo es parte del trabajo. Pasar a producción no arregla por sí solo la falta de datos, de métrica o de ownership: solo la hace más cara y más visible.

Si el proceso es estable y verificable, un workflow determinista basta y cuesta menos de mantener. Si el riesgo de escritura es alto, un copiloto de solo lectura que sugiere y deja confirmar al humano suele ser el primer paso sensato. Y si las fuentes de verdad están rotas, primero se arreglan los datos: basura dentro, basura fuera, ahora con factura por token.

Si quieres una base abierta sobre la que construir, mira las herramientas open source de Devic para agentes. En ambos caminos la receta es la misma: una tarea, un flujo, un tenant piloto, con permisos, trazas, evals y límite de coste desde el primer día.

Checklist: ¿está tu agente listo para producción?

Repasa las seis líneas del checklist con tu equipo y sé honesto con las que fallan. Si están en verde, puedes plantear escritura con red debajo. Si no, ya sabes qué construir esta semana, y no es un prompt mejor.

Para aterrizarlo en tu stack, mira qué capas cubre ya un harness con observabilidad y control de coste. Si lo que te bloquea es que cuadre en el margen, compara los precios por plan y el volumen de tool calls incluido. Y si prefieres verlo con tu caso encima de la mesa, cuéntanoslo y lo miramos con los números delante.