Cómo desplegar un agente de IA en producción: guía de lanzamiento recuperable, observable y reversible desde la demo

Hoja de ruta para salir a producción: define primero los límites y valida cada punto

La clave para desplegar un agente de IA en producción no consiste en añadir más modelos o complejidad de orquestación, sino en conseguir que los fallos de las tareas puedan diagnosticarse y recuperarse, y que los cambios puedan validarse y revertirse. Se recomienda definir en orden las tareas y sus condiciones de finalización, elegir la forma de ejecución, establecer el entorno de ejecución y el almacenamiento de estado, aplicar los límites de seguridad, evaluar tareas representativas y, después, realizar un despliegue gradual con poco tráfico y organizar la guardia y la reversión.

Define primero las condiciones de activación, las entradas, las herramientas que se pueden utilizar, el resultado final de negocio, el tratamiento de los tiempos de espera y los puntos que requieren confirmación humana. Cuando un flujo fijo ya satisface las necesidades, no es necesario introducir múltiples agentes solo para convertirlo en un “agente”. Puedes consultar el análisis de Anthropic sobre las formas de construir agentes. Para la integración con interfaces del sistema y los permisos de las herramientas, consulta Cómo conectar un agente de IA con los sistemas empresariales existentes.

Elige la forma de despliegue: decide según las restricciones

La tabla siguiente sirve para comparar las restricciones arquitectónicas y no representa conclusiones sobre rendimiento o precio. Las capacidades, cuotas y responsabilidades operativas de cada plataforma candidata deben comprobarse en su documentación vigente.

Al utilizar inferencia mediante una API de modelos, los elementos que normalmente se despliegan son el entorno de ejecución de la aplicación, las herramientas controladas y los servicios de estado; la posibilidad de crear un entorno de inferencia propio debe evaluarse por separado según los requisitos de latencia, los límites de los datos, la disponibilidad del modelo y las necesidades operativas. La documentación de Kubernetes Deployment puede servir como referencia para sus mecanismos de actualización progresiva y reversión de revisiones, pero eso no significa que un Agent deba desplegarse en Kubernetes.

Arquitectura mínima de producción: conectar solicitudes, ejecución, estado y observabilidad

调用方 → 鉴权入口/请求校验 → 任务执行器（同步短任务或异步任务 ID）
      → Agent 运行逻辑 → 模型端点/受控工具 → 状态存储与结果核验
      → 日志、指标、追踪与告警

Las tareas cortas pueden esperar el resultado; cuando se supera la ventana de espera del cliente o se necesita recuperación entre procesos, se puede devolver un ID de tarea para que el cliente consulte el estado o reciba una notificación de finalización. Hay que definir los estados de la tarea, la semántica de cancelación, los límites de tiempo de espera y los permisos de lectura de resultados.

La integración con los sistemas no se desarrolla de nuevo aquí; consulta Cómo integrar AI Agent con los sistemas empresariales existentes. Las responsabilidades de guardia y colaboración entre ingeniería pueden consultarse en Responsabilidades de entrega de ingeniería y límites de colaboración de FDE; las responsabilidades concretas deben definirse en el proyecto.

Preparación de los artefactos de publicación: hacer que los cambios sean reproducibles

Incluye el código, los archivos de bloqueo de dependencias, la imagen de ejecución, la configuración del entorno, las plantillas de prompts y las versiones de configuración de los modelos y las herramientas en el registro de cambios. Las dependencias deben validarse durante la compilación; los entornos de desarrollo, pruebas y producción deben mantenerse separados; las credenciales deben inyectarse mediante mecanismos de configuración controlados y no deben escribirse en el repositorio de código ni en registros ordinarios. Las claves de API de modelos, las credenciales de los servicios de herramientas y las identidades empresariales deben gestionarse por separado.

La lista de publicación debe confirmar como mínimo lo siguiente:

• Se han validado el punto de entrada de ejecución, la comprobación de salud, los límites de recursos y el tratamiento de las señales de apagado;
• Las versiones de las dependencias, los resúmenes de las imágenes y los cambios de configuración son trazables;
• Las versiones de los prompts, los contratos de las herramientas, los identificadores de los modelos y los parámetros clave están registrados;
• Las muestras de regresión y los resultados de evaluación pueden asociarse a una versión de publicación;
• La versión de destino de la reversión puede iniciarse y leer el formato de estado actual, o rechazar explícitamente su procesamiento.

Recuperación de tareas largas: un punto de control no equivale a una ejecución empresarial exactamente una vez

La recuperabilidad abarca tres niveles: el registro de la tarea, el estado de ejecución y los efectos secundarios empresariales. Hay que saber si la tarea está en cola, en ejecución o esperando intervención humana; hasta qué pasos ha avanzado la ejecución; y si las escrituras en sistemas externos se han realizado correctamente. Guardar únicamente el texto de la conversación puede no bastar para recuperar el contexto de ejecución, y disponer de puntos de control tampoco demuestra que el resultado de las operaciones de escritura externas sea correcto.

Tomando LangGraph como ejemplo, la documentación distingue entre el checkpointer, que guarda el estado de ejecución por hilo, y el store, que comparte datos entre hilos. Para reanudar la ejecución tras reiniciar el proceso se necesita un backend de persistencia adecuado, y deben verificarse la escritura, la lectura, el aislamiento, la retención y la recuperación ante fallos; un guardador basado en memoria no puede considerarse una base de persistencia entre reinicios. Consulta la documentación de Persistencia de LangGraph.

La estrategia de reintentos debe distinguir entre el tiempo de espera de un intento individual, los errores reintentables y el tratamiento después de agotar los reintentos. Las herramientas con efectos secundarios deben diseñarse con claves de idempotencia o mecanismos de deduplicación. Antes de reintentar, consulta el resultado de negocio: que una llamada agote el tiempo de espera no significa que la escritura no se haya producido. Cuando no sea posible confirmarlo, deriva el caso a una comprobación manual o ejecuta un flujo de compensación; los puntos de control, las colas y los reintentos, por sí solos, no constituyen una garantía end-to-end de exactly-once. Consulta la documentación de tolerancia a fallos de LangGraph.

Controles de seguridad: establece condiciones de bloqueo para las acciones de alto riesgo

Antes de publicar, verifica como mínimo:

• Los documentos externos, las páginas web y las entradas de los usuarios no pueden ampliar por sí mismos los permisos de las herramientas;
• Los servicios de herramientas verifican en cada llamada la identidad, el alcance de los recursos y los parámetros; las acciones de alto impacto requieren una confirmación humana explícita;
• Las credenciales están aisladas por entorno y se pueden rotar; los registros se minimizan y anonimizan según el nivel de sensibilidad, y tienen establecido un periodo de conservación;
• Los registros de aprobación relacionan la solicitud, el operador, la acción prevista y el resultado final de negocio;
• Las pruebas de escalada de privilegios, inyección de instrucciones, envíos duplicados y filtración de datos sensibles producen los rechazos esperados.

Los recursos de OWASP sobre amenazas y mitigaciones de la IA agéntica pueden ayudar a elaborar una lista de amenazas, pero no constituyen una prueba de la seguridad ni del cumplimiento normativo de este sistema.

Puertas de evaluación: analiza a la vez el resultado y el proceso

No consideres la afirmación del Agent de que «ya ha terminado» como criterio de aceptación. Para cada tipo de tarea, define condiciones de éxito verificables en el entorno, como el estado del registro objetivo, el formato de salida y las acciones prohibidas; conserva la traza de ejecución para localizar fallos en la planificación, las llamadas a herramientas o la validación de resultados. Puedes consultar la explicación de Anthropic sobre los métodos de evaluación de Agents.

Las muestras deben abarcar entradas normales, campos ausentes, información contradictoria, tiempos de espera agotados de las herramientas, denegaciones de permisos, solicitudes duplicadas e inducciones procedentes de contenido externo. Las muestras importantes pueden ejecutarse varias veces y registrar la variación de los resultados. Las puertas de publicación pueden incluir el resultado de la tarea, las acciones prohibidas, el tratamiento de excepciones, los simulacros de recuperación y las rutas de toma de control humano; los umbrales deben determinarse según el riesgo del negocio, las líneas base existentes y los resultados de las pruebas.

Monitorización: calidad, latencia, recuperación y costes

Define para cada métrica su criterio de medición, el punto de recopilación, las condiciones de alerta y la persona responsable:

La traza sirve para localizar desviaciones en la ejecución de varios pasos, mientras que el estado final de negocio permite confirmar que la tarea se ha completado. Los campos anonimizados de los registros, el alcance del acceso y el periodo de conservación deben determinarse según el proyecto; durante la fase inicial de puesta en producción, establece una línea base de observación y ajusta después los umbrales de alerta según el riesgo empresarial.

Despliegue gradual, reversión y gestión de tareas en curso

Antes del lanzamiento, realiza pruebas de regresión sobre las combinaciones de código, prompts, configuración del modelo y contratos de las herramientas; valida primero con tráfico limitado o tareas de bajo riesgo y aumenta gradualmente el volumen. Establece condiciones de detención, como anomalías en los resultados de negocio, fallos en las pruebas de acceso indebido o errores y latencias que superen los límites definidos por el equipo.

En caso de fallo, pausa la recepción de nuevas tareas o desactiva las herramientas de alto riesgo, haz inventario de las tareas en ejecución, en espera y completadas, y verifica los efectos externos antes de volver a una versión validada. Comprueba que la versión anterior sea compatible con el formato de estado existente; las tareas que no puedan recuperarse automáticamente deben transferirse a una persona o someterse a una compensación aprobada. Kubernetes Deployment puede servir como referencia de publicación al utilizar Kubernetes; revertir la aplicación no revierte automáticamente las escrituras de negocio ya realizadas.

Ejercicio didáctico: validar la ruta de recuperación mediante inyección de fallos

El siguiente diseño corresponde a un ejercicio didáctico, no a un caso de cliente ni a resultados medidos. Define la tarea como «generar un informe y escribir el resultado después de la confirmación manual» y registra en cada ejecución el resultado esperado, el resultado real y las evidencias:

El ejercicio debe comprobar si el estado de negocio, el registro de ejecución y el resultado esperado son coherentes, y debe definir claramente a la persona responsable de cada tarea anómala y la ruta de actuación.

Lista de comprobación para la aceptación del lanzamiento

• El alcance de las tareas, la definición de finalización, las acciones prohibidas y los puntos de confirmación manual están documentados.
• La modalidad de despliegue es adecuada para la duración de las tareas, los requisitos de recuperación y la capacidad operativa del equipo.
• Las dependencias, las imágenes, los prompts, la configuración del modelo y los contratos de las herramientas son trazables.
• El estado de las tareas, la persistencia y los efectos secundarios de negocio pueden verificarse por separado, y los reintentos cuentan con protección de idempotencia.
• Los permisos, la inyección de prompts, los registros sensibles y la aprobación manual han superado las pruebas.
• La evaluación cubre tareas representativas, muestras anómalas, verificación de resultados y escenarios de recuperación.
• Se han confirmado las definiciones de métricas, las personas responsables de las alertas, las condiciones de detención del despliegue gradual y el procedimiento de guardia.
• Se han ensayado la versión de reversión, las tareas en curso, la compatibilidad del estado y la ruta de compensación empresarial.

Problemas habituales de despliegue

Pregunta: ¿Es obligatorio usar Kubernetes? Respuesta: No necesariamente. Si el equipo ya dispone de una plataforma que cumple los requisitos de duración de las tareas, recuperación del estado, aislamiento de red y operaciones, no es necesario añadir complejidad al clúster por el hecho de incorporar un agente.

Pregunta: ¿Es necesario crear un modelo propio para desplegar un agente? Respuesta: No necesariamente. Al usar una API de modelos para la inferencia, normalmente basta con desplegar el entorno de ejecución de la aplicación, herramientas controladas y componentes de estado. La inferencia autogestionada requiere evaluar por separado los límites de los datos, la latencia, la disponibilidad y los requisitos operativos.

Pregunta: ¿Se perderán las tareas después de reiniciar el servicio? Respuesta: Depende de la persistencia de los registros de tareas y del estado de ejecución, así como de la validación del proceso de recuperación. La memoria del proceso por sí sola no permite recuperarse tras un reinicio; también hay que verificar si las operaciones de escritura externas se completaron correctamente para evitar ejecuciones duplicadas.

Pregunta: ¿Cómo se pueden evitar las escrituras duplicadas provocadas por los reintentos? Respuesta: Diseña claves de idempotencia o registros de deduplicación para las operaciones de negocio y comprueba el estado del sistema externo antes de reintentar. Si no se puede confirmar el estado, pausa los reintentos automáticos, realiza una comprobación manual o sigue un proceso de compensación.

Pregunta: ¿Qué umbral debe establecerse para la tasa de éxito tras el lanzamiento? Respuesta: No existe un valor universal. Define las barreras de control y las alertas según el riesgo de la tarea, la línea base del negocio y los resultados de las pruebas. La aceptación también debe cubrir las acciones prohibidas, la intervención humana, la recuperación y los resultados de negocio.