Agentes de IA en producción: arquitectura, guardrails y control de costos

El abismo entre el demo y la producción

Hay un momento que se repite en casi todas las empresas que se entusiasman con la IA agéntica. Alguien arma un prototipo en una tarde, lo conecta a un par de herramientas, le hace tres preguntas en vivo y la sala se queda en silencio. Funciona. Parece magia. Y de ahí se salta, demasiado rápido, a la frase peligrosa: "pongámoslo en producción la próxima semana".

El problema es que el demo y el sistema en producción no son la misma cosa con más usuarios. Son animales distintos. Gartner viene advirtiendo que más del 40 por ciento de los proyectos de IA agéntica se cancelarán para finales de 2027, y la causa rara vez es que el modelo "no era lo bastante inteligente". Lo que mata estos proyectos es lo aburrido: costos que se disparan, valor que nunca queda claro y controles de riesgo que llegaron tarde o nunca llegaron. Un demo se evalúa por su mejor respuesta; un agente en producción se juzga por su peor comportamiento un martes a las tres de la tarde, con un usuario haciendo algo que nadie anticipó.

Vale la pena entonces hablar en serio de qué hace falta para que un agente cruce ese abismo. No de la parte que sale en los videos, sino de la fontanería: la arquitectura, los guardrails, la observabilidad y el control de costos.

Qué es realmente una arquitectura agéntica

Conviene empezar por una distinción que Anthropic dejó clara en su guía sobre cómo construir agentes efectivos: no todo lo que llamamos "agente" lo es. Hay flujos de trabajo, donde el modelo recorre pasos predefinidos por código, y hay agentes propiamente dichos, donde el modelo decide en un bucle qué hacer a continuación y qué herramientas usar. La mayoría de los problemas de negocio se resuelven mejor con flujos predecibles que con un agente autónomo dándole vueltas a un objetivo abierto. La autonomía es una palanca con costo, no un trofeo. Pedirla cuando no se necesita es la primera forma de quemar presupuesto.

Cuando el caso sí amerita un agente, el bloque fundamental es lo que Anthropic llama el "LLM aumentado": un modelo enriquecido con tres capacidades que conviene pensar por separado. La primera es la orquestación, que es el cerebro que decide el flujo. Hay patrones distintos según el problema, desde el clásico ReAct para tareas dinámicas hasta planificar-y-ejecutar para procesos más predecibles, pasando por arquitecturas multiagente cuando el dominio es lo bastante complejo para repartir el trabajo. Microsoft, en su centro de arquitectura de Azure, describe varios de estos patrones de orquestación, y la elección entre ellos no es estética: se decide contra restricciones reales de latencia, costo y fiabilidad. Un agente jerárquico con sub-agentes es más capaz y también más caro y más difícil de depurar.

La segunda capacidad son las herramientas, y aquí es donde muchos proyectos tropiezan sin darse cuenta. La interfaz entre el agente y sus herramientas es tan crítica como la interfaz entre un humano y una computadora. El consejo de ingeniería de Anthropic es contraintuitivo para quien viene del mundo de las APIs: en vez de exponer "listar usuarios", "obtener usuario" y "listar eventos" como tres herramientas que el agente tiene que combinar, conviene construir una sola herramienta "agendar evento" que haga todo eso por dentro. Pocas herramientas de alto impacto, cada una con un propósito distinto y una descripción clara, reducen la carga cognitiva del modelo y, de paso, reducen los pasos, que es lo mismo que decir que reducen los tokens.

La tercera es la memoria y el contexto, lo que hoy se conoce como ingeniería de contexto, la sucesora natural de la ingeniería de prompts. El orden y la calidad de lo que entra en la ventana de contexto, instrucciones de sistema primero, luego memoria relevante, definiciones de herramientas e historial, pesa más en el rendimiento que casi cualquier otra cosa. Un agente que arrastra contexto irrelevante no solo responde peor: paga por cada token de esa basura en cada llamada.

Los guardrails que evitan el daño

Un agente en producción puede actuar sobre el mundo. Envía correos, modifica registros, ejecuta consultas, mueve dinero. Esa capacidad de acción es precisamente lo que lo hace valioso y lo que lo vuelve peligroso. Por eso los guardrails no son un adorno de cumplimiento que se agrega al final, sino parte de la arquitectura desde el primer día.

Conviene pensarlos en capas que operan en distintos momentos. Antes de que el agente procese una entrada, hay validación de entrada que rechaza prompts adversariales o fuera de tema, la primera línea contra la inyección de prompts, que encabeza el OWASP Top 10 para aplicaciones LLM de 2025 como LLM01. Después de que el modelo genera, hay filtrado de salida que detecta fugas de datos sensibles y contenido que no debería salir. Y alrededor de cada herramienta, validación específica del efecto secundario. Como explica bien la documentación de LangChain sobre guardrails, si necesitas controles alrededor de cada llamada a herramienta, no basta con guardrails a nivel de agente: la validación tiene que vivir pegada a la herramienta que produce el efecto, no flotando en una capa genérica.

Aquí entra una distinción que Datadog y la propia guía de OpenAI subrayan. Los guardrails automáticos validan entrada, salida y comportamiento de herramientas sin intervención. El human-in-the-loop es algo distinto: pausa la ejecución para que una persona apruebe o rechace una acción sensible antes de que ocurra. No es que uno reemplace al otro. Para una consulta de solo lectura, los guardrails automáticos bastan; para que el agente emita una factura, transfiera fondos o borre un cliente, lo correcto es que alguien con un dedo sobre el botón confirme. Decidir qué acciones cruzan ese umbral es una decisión de negocio, no técnica, y debería configurarse desde la administración del sistema, no quedar enterrada en una heurística del código.

A esto se suman los controles más antiguos y aburridos, que siguen siendo imprescindibles: autenticación, autorización por roles, límites de tasa y, muy concretamente, límites de tokens por ejecución. Un agente sin tope de tokens es una factura abierta esperando un bucle infinito. El OWASP llama a esto agencia excesiva (LLM06): darle al agente más permisos, más herramientas y más autonomía de la que el caso realmente requiere.

Observabilidad: ver lo que el agente realmente hizo

Los agentes fallan distinto al software tradicional, y por eso necesitan instrumentación distinta. Un agente puede devolver una respuesta segura, bien formada y completamente equivocada, habiendo hecho tres llamadas innecesarias a herramientas y una acción sintácticamente válida que hizo exactamente lo que no debía. No hubo excepción, no hubo error 500, no hubo nada que un monitor clásico levantara. Salió mal en silencio.

Por eso la observabilidad de agentes exige capturar la traza completa de cada ejecución: los prompts, los documentos recuperados, cada invocación de herramienta, la latencia, el costo, las ejecuciones de sub-agentes, las salidas y la retroalimentación del usuario. Y no solo el camino que el agente tomó: si evaluó tres herramientas y eligió una, las tres evaluaciones deberían quedar en la traza, no solo la ganadora. Sin esa visibilidad estás depurando a ciegas. La buena noticia es que el ecosistema se está estandarizando alrededor de convenciones semánticas de OpenTelemetry para agentes de IA, lo que evita amarrarse a una herramienta propietaria.

La observabilidad alimenta lo que de verdad mantiene un agente honesto con el tiempo: la evaluación continua. La práctica que está madurando consiste en convertir las trazas reales de producción en conjuntos de evaluación, de modo que la cobertura de pruebas evolucione con el uso real en vez de depender de casos hechos a mano que envejecen mal. Los jueces basados en LLM, alineados contra retroalimentación humana, permiten medir calidad a escala. Un agente que no se evalúa de forma continua no es un sistema en producción, es una apuesta en producción.

El costo, que es donde mueren los proyectos

Llegamos a la parte que decide si el proyecto sobrevive al segundo trimestre. La inferencia se paga por token, cada paso del bucle suma tokens, y un agente mal diseñado multiplica los pasos. El control de costos no es una optimización tardía, es parte del diseño.

La palanca más grande y subutilizada es el caché de prompts. Cuando el agente reutiliza el mismo contexto, instrucciones de sistema, definiciones de herramientas, documentos de referencia, una y otra vez, no tiene sentido pagar el procesamiento completo en cada llamada. Según AWS, el caché de prompts puede reducir la latencia hasta en un 85 por ciento y el costo de tokens de entrada hasta en un 90 por ciento. Los números de los proveedores lo confirman: Anthropic cobra alrededor de 0,30 dólares por millón de tokens leídos de caché frente a 3,00 dólares por procesarlos frescos, y OpenAI ofrece un 50 por ciento de descuento sobre tokens cacheados. Estructurar el prompt para que la parte estable vaya al inicio y sea cacheable es de las decisiones de arquitectura con mayor retorno por hora invertida.

La segunda palanca es la elección del modelo. No toda tarea necesita el modelo más grande. Una buena arquitectura rutea: un modelo pequeño y barato para clasificar, extraer o decidir el siguiente paso, y reserva el modelo potente para el razonamiento que de verdad lo amerita. La tercera es la disciplina de tokens, que vuelve a conectar con todo lo anterior: contexto curado en vez de volcado, herramientas que resuelven en un paso lo que de otro modo tomaría cinco, y límites duros por ejecución. Cada token que el agente no necesita gastar es margen que el proyecto conserva.

Aterrizarlo en tu empresa

Si tu empresa quiere llevar un agente a producción de verdad, la pregunta útil no es "¿qué modelo usamos?" sino "¿tenemos la fontanería?". ¿Está clara la frontera entre lo que el agente decide solo y lo que requiere aprobación humana? ¿Hay validación pegada a cada herramienta que toca datos o dinero? ¿Podemos ver la traza completa de una ejecución que salió mal? ¿Sabemos cuánto cuesta cada interacción y dónde se va el presupuesto? Si alguna de esas respuestas es "todavía no", tienes un demo, no un sistema en producción, y conviene saberlo antes de prometer fechas.

En sof-IA construimos exactamente este tipo de sistemas a la medida, montados sobre AWS, con la orquestación, los guardrails, la observabilidad y el control de costos pensados desde el diseño y no parchados al final. Porque la diferencia entre un agente que impresiona en una reunión y uno que aguanta el martes a las tres de la tarde está, casi siempre, en lo que no se ve.