El salto de un agente de inteligencia artificial funcional en un entorno de laboratorio a un sistema fiable en producción no es un problema de ajuste de modelos, sino de arquitectura de gobierno. En Q2BSTUDIO, donde desarrollamos aplicaciones a medida y soluciones de IA, hemos aprendido que un prototipo que 'funciona' puede esconder riesgos graves: identidades no auditadas, herramientas sin control, costes disparados o fallos sin recuperación. Este artículo propone una checklist de producción original, pensada para equipos técnicos y directivos que quieren desplegar agentes de IA con garantías empresariales.
¿Qué distingue un prototipo de un sistema listo para producción? La diferencia no está en el prompt, sino en los planos de control que rodean al modelo. Un prototipo demuestra que un agente puede completar una tarea; un sistema productivo debe poder explicar quién actuó, qué estado se retuvo, qué herramientas se usaron, cómo se evaluó el comportamiento, qué telemetría se capturó, dónde se interrumpió para aprobación, cómo se limitó el coste, cómo se contuvieron los fallos y quién es el responsable del servicio. Son ocho ejes que deben tratarse como planos de control separados, no como parches posteriores.
Identidad: quién actúa realmente En producción, un agente opera con al menos tres identidades: la del solicitante (persona, aplicación o evento), la del propio agente (identidad de carga de trabajo no humana) y la identidad delegada que se presenta a la herramienta o fuente de datos. No se pueden colapsar en una única cuenta de servicio. En Q2BSTUDIO, al integrar agentes con cloud AWS/Azure, exigimos que cada identidad tenga un alcance claro, tokens de corta duración, rotación automática y registro de auditoría. Sin esta separación, cualquier fallo de seguridad es imposible de rastrear.
Estado: diseñado, no acumulado El estado en un prototipo suele ser un historial de conversación que crece sin control. En producción, hay que separar el estado de conversación, el estado del flujo de trabajo, la memoria duradera, las evidencias, las aprobaciones y los artefactos. Cada tipo necesita un esquema, propietario, política de retención y cifrado. El modelo solo debe ver una vista temporal del estado necesario para el paso actual, no el almacén autoritativo. La capacidad de pausar un agente, inspeccionar su estado y reanudarlo exactamente una vez sin efectos secundarios duplicados es un indicador de madurez.
Herramientas: API de producción, no funciones de juguete Cada herramienta que el agente invoca debe tener un registro de capacidad que defina su propósito, clasificación de datos, método de autenticación, esquemas de entrada/salida, timeouts, límites de reintentos, idempotencia y requisitos de aprobación. En Q2BSTUDIO clasificamos las herramientas por consecuencia: lectura, propuesta, cambio reversible, cambio de alto impacto. Cuanta más autoridad tenga la herramienta, menos discreción debe tener el modelo. Los argumentos de la herramienta deben validarse con código determinista, y los resultados deben tratarse como datos no confiables, porque un documento externo puede contener instrucciones maliciosas.
Evaluaciones: del prompt al flujo completo Un benchmark de modelo no dice si el agente eligió la herramienta correcta, respetó los límites de aprobación, se recuperó de un timeout o se mantuvo dentro del presupuesto. Las evaluaciones de producción deben medir el flujo completo: pruebas deterministas de comportamiento a nivel de código, evaluaciones offline con tareas representativas, evaluaciones de traza que inspeccionen el camino (no solo la respuesta final), evaluaciones adversariales (inyección de prompts, envenenamiento de memoria) y evaluaciones online con muestras reales. Los umbrales de release deben ser específicos: cero violaciones de políticas críticas, cero llamadas a herramientas de alto impacto incorrectas, éxito de tarea por encima del 95%.
Observabilidad: reconstruir cada ejecución La monitorización tradicional ve la petición externa y quizás una llamada al modelo. Un agente puede tener varias llamadas al modelo, recuperaciones, lecturas de memoria, decisiones de política, llamadas a herramientas, reintentos, aprobaciones y traspasos. La unidad observable es la ejecución completa del agente. Recomendamos un span raíz por invocación, con hijos para cada operación. La captura de contenido debe estar deshabilitada por defecto y habilitarse solo con políticas de redacción y cifrado. Los registros de baja cardinalidad (versión del agente, modelo, política, herramienta, entorno, resultado) permiten a un ingeniero de guardia diagnosticar con un solo identificador de ejecución.
Seguridad: control en tiempo de ejecución Las instrucciones en el prompt no son controles de seguridad. El modelo de amenazas debe cubrir toda la ruta del agente: entrada de usuario, documentos recuperados, contenido web, memoria, salida del modelo, metadatos de herramientas, argumentos y resultados, mensajes entre agentes, ejecución en sandbox, egress de red, almacenes de estado y registros. En Q2BSTUDIO, al implementar ciberseguridad en sistemas de IA, aplicamos controles como validación de esquemas, límites de egress, escaneo de secretos, cifrado en tránsito y reposo, y pruebas de corte (shutdown path). Un agente manipulado con acceso de solo lectura a documentación pública es un riesgo menor que uno con acceso a shell y credenciales de producción.
Coste: presupuesto por ejecución El coste de un agente no es el coste de una llamada al modelo, sino el coste de toda la ejecución: instrucciones, historial, contexto recuperado, esquemas de herramientas, reintentos, llamadas de validación, razonamiento, generación de salida y traspasos. Hay que poner un presupuesto en el límite de la ejecución: número máximo de llamadas al modelo, herramientas, reintentos, tiempo transcurrido, ramas paralelas, consumo de API externas. La métrica principal debe ser el coste por tarea exitosa. Un modelo barato que provoca reintentos o acciones incorrectas sale más caro. El enrutamiento de modelos, el caché de prefijos, la compactación de contexto y las reglas de parada deben ser parte del runtime, no buenas prácticas opcionales.
Aprobaciones: máquina de estados La intervención humana debe depender de la consecuencia, reversibilidad, autoridad y confianza. Las acciones de solo lectura pueden ser automáticas; las propuestas deben marcarse claramente como borradores; los cambios reversibles requieren aprobación solo cuando la evidencia de evaluación no es sólida; las acciones de alto impacto (financieras, destructivas, externas) necesitan aprobación obligatoria con separación de funciones. El flujo debe pausarse sin perder estado, y al reanudarse debe revalidar autorización, política y plazo de la aprobación.
Gestión de fallos: seguridad e intención Los fallos de un agente no son solo fallos del modelo. Pueden deberse a estructura inválida, recuperación obsoleta, estado corrupto, timeout de herramienta, aprobación caducada, dependencia no disponible, presupuesto agotado o política bloqueada. La respuesta debe depender de la clase de fallo: reintentar solo fallos transitorios conocidos con backoff exponencial, usar claves de idempotencia, detectar bucles de estado, usar circuit breakers, preservar checkpoints antes de operaciones de alto impacto, y desviar trabajo irrecuperable a una cola manual con evidencia completa. Las rutas de fallback no deben cambiar el modelo de seguridad sin el mismo diseño riguroso.
Propiedad: más allá del desarrollador original El primer incidente en producción revelará rápidamente quién no está asignado. Un agente cruza varios dominios: negocio, producto, plataforma, identidad, datos, herramientas, modelo, observabilidad, coste y gobernanza. Cada dominio necesita un propietario accountable, y un propietario del servicio global debe rendir cuentas del resultado final. La documentación de entrega debe incluir arquitectura, inventario, resultados de evaluaciones, dashboards, runbooks, contactos de escalado y procedimientos de apagado.
Despliegue por fases No se debe conceder autoridad total en la primera release. Un despliegue disciplinado expande tráfico y autoridad por etapas: modo sombra (sin exponer salida ni ejecutar efectos secundarios), piloto de solo lectura, canario con aprobaciones, automatización acotada y escala controlada. Cada expansión cambia el modelo de datos, identidad, herramientas, fallos, coste y propiedad. La pregunta de release no es '¿sigue funcionando el demo?' sino '¿qué nueva autoridad estamos otorgando, qué evidencia la respalda y con qué rapidez podemos contenerla si la evidencia es errónea?'.
En Q2BSTUDIO ayudamos a empresas a construir esos planos de control sobre BI/Power BI, cloud y automatización, integrando agentes de IA que no solo funcionan, sino que pueden gobernarse, explicarse y recuperarse. La producción no es el final del prototipo: es el comienzo de un sistema que merece confianza empresarial.
