De demo a producción: cómo operar agentes de IA con control y observabilidad

Una demo demuestra capacidad, no confiabilidad

Un prototipo demuestra que un modelo puede completar una tarea. Producción exige conservar estado, respetar permisos, recuperarse de fallas, explicar evidencia y detenerse de forma segura.

Separa razonamiento de ejecución

Recomendar, preparar, aprobar, ejecutar y verificar deben ser estados distintos. Así una respuesta del modelo no se convierte automáticamente en un efecto externo sin control.

Conserva evidencia e historial

Cada ejecución debe registrar versión, fuentes, modelo, herramientas, aprobaciones, costo, latencia, resultado y verificación. Ese Run Ledger permite auditoría, replay y pruebas de regresión.

Incrementa la autonomía gradualmente

La progresión segura va de observar a recomendar, preparar, aprobar y ejecutar. La autonomía se concede por workflow y acción, nunca globalmente.

Observa valor y salud técnica

Además de tokens y latencia, mide cobertura de fuentes, correcciones, aprobaciones, acciones verificadas, tiempo ahorrado y recuperación.

Checklist

Arquitectura de referencia para un agente controlado

Un agente de producción se beneficia de seis capas explícitas: identidad y tenant, estado del workflow, ruteo de modelos, ejecución de herramientas, políticas y telemetría. Separarlas permite diagnosticar fallas y cambiar modelos o conectores sin rehacer todo.

El orquestador debe poseer el estado. El modelo propone decisiones estructuradas; código determinista valida esquemas, permisos, presupuestos y parámetros. Los efectos externos deben verificarse después de ejecutarse.

Ejemplo: brief operativo diario

Un brief para construcción puede reunir fechas límite, subcontratistas sin confirmar, clima, correos, hojas y mensajes de campo. Cada afirmación conserva su fuente. El agente prioriza riesgos y prepara acciones, pero cambiar el programa o contactar a un proveedor sigue siendo una acción aprobada.

Fallas que deben diseñarse antes del lanzamiento

Los modelos pueden devolver formatos inválidos, omitir evidencia o elegir una herramienta incorrecta. Los conectores pueden expirar, fallar o limitar solicitudes. Dos reintentos pueden duplicar una acción. Son condiciones normales de operación, no detalles para después.

Diseña timeouts, límites de reintento, claves de idempotencia, circuit breakers, colas de fallas y recuperación manual. Define qué workflows pueden degradarse, cuáles deben detenerse y cuáles pueden continuar en solo lectura.

Qué debe responder la observabilidad

La consola debe explicar qué inició la ejecución, qué evidencia leyó, qué modelo y versión usó, qué herramientas llamó, qué política autorizó la acción, quién aprobó, qué cambió y si se verificó el resultado.

Mide también resultados: tasa de finalización, correcciones, tiempo de resolución, latencia de aprobación, costo por resultado exitoso, excepciones y adopción. Baja latencia no sirve si el operador rehace el trabajo.

Seguridad y aislamiento

Cada ejecución hereda usuario, empresa, rol y recursos autorizados. Las credenciales se aíslan, cifran y rotan; nunca se exponen al modelo. La recuperación de datos aplica filtros de tenant antes de llegar al prompt.

Estrategia de liberación

Comienza en shadow mode, compara recomendaciones con decisiones humanas y luego permite preparar acciones sin ejecutarlas. Agrega aprobación para acciones de bajo riesgo y conserva un kill switch accesible para operaciones.

Siguiente paso

Comienza con un workflow read-only y demuestra la fuente de cada afirmación crítica antes de agregar escritura.