Arquitectura de IA para agentes en producción: modos de fallo y capas de control

Por qué se estancan los prototipos

Los sistemas de IA para producción rara vez fallan debido a que los modelos son débiles. Fallan porque la arquitectura que rodea al modelo nunca aceptó el no determinismo como una restricción de diseño. Tres tensiones influyen en casi todas las decisiones posteriores: la capacidad frente a la controlabilidad, la latencia frente a la precisión, y la autonomía frente a la auditabilidad.

Los buenos arquitectos se preguntan por qué antes que qué. Sin una filosofía de diseño, una lista de componentes es solo una lista de verificación. Con ella, se convierte en un marco que también abarca problemas que aún nadie ha enfrentado.

Esa filosofía invierte una suposición común. La arquitectura tradicional espera que los componentes hagan exactamente lo que indican sus especificaciones, lo cual deja al arquitecto la tarea de gestionar el enrutamiento, la escalabilidad y la tolerancia a fallos. Aquí, el propio componente es la fuente de incertidumbre, por lo que el sistema circundante debe absorberla, medirla y limitarla en cada capa.

Cómo mueren realmente los sistemas de IA

La mayoría de los fallos en producción se deben a tratar un sistema probabilístico como si fuera una API determinística. A continuación se presenta una taxonomía aproximada de las formas en que esto ocurre.

La alucinación como problema de recuperación

Por lo general, la gente atribuye las alucinaciones a la calidad del modelo. Desde el punto de vista arquitectónico, se trata de una brecha en la recuperación de información, un error en la gestión de la ventana de contexto o una falla en la calibración de la confianza. Si se pide a un modelo que razone sobre un documento de 200 páginas cuando solo caben 4,000 tokens, no puede saber qué le falta, por lo que inventa el resto. La solución reside en el sistema: una recuperación precisa, un límite para el contexto y la expresión explícita de la incertidumbre a través del prompt del sistema y el esquema de salida.

Tres tipos de deriva

Los equipos a menudo agrupan tres cosas distintas. El deriva del modelo ocurre cuando el proveedor actualiza el modelo base y cambia su comportamiento, aunque no se haya implementado nada en su lado. La deriva de los datos ocurre cuando cambian las entradas, como cuando un agente de soporte acostumbrado a patrones de consultas anteriores a 2024 comienza a tener dificultades con preguntas sobre nuevos productos. La deriva del conocimiento ocurre cuando el mundo sigue avanzando y lo que aprendió el modelo se vuelve obsoleto. Cada uno de estos casos requiere su propio método de detección y solución.

Errores que trascienden las fronteras entre agentes

Los sistemas multiagente plantean un problema más sutil. El agente A genera un resultado ligeramente incorrecto, el agente B lo toma como hecho y el agente C realiza una acción irreversible basándose en el razonamiento defectuoso de B. Una vez que surge el error, resulta casi imposible determinar dónde comenzó. Tres medidas de protección ayudan: los agentes intercambian puntuaciones de confianza, las transferencias que están por debajo de un umbral de confianza activan un mecanismo de detención y cada límite entre agentes escribe en un registro de auditoría de solo escritura.

Contaminación del contexto

Las conversaciones largas y grandes cantidades de historial de llamadas a herramientas llenan la ventana de contexto con información que perjudica el rendimiento. La atención se dispersa entre una cantidad cada vez mayor de datos, y las instrucciones clave terminan en la parte central, donde la atención es más escasa. Los arquitectos necesitan un ciclo de vida del contexto bien definido: desencadenantes para la resumen, estrategias para la compresión y una separación clara entre la memoria de trabajo y la memoria a largo plazo.

Bucles de intentos repetidos

Los agentes equipados con herramientas pueden caer en intentos repetidos patológicos. Una búsqueda devuelve resultados ambiguos, el agente reescribe la consulta, pero la nueva consulta resulta igualmente ambigua, y el ciclo continúa hasta que se agota el contexto o se alcanza un límite de frecuencia. A menos que la capa de orquestación cuente con detección de bucles, presupuestos por paso y condiciones de terminación, los sistemas basados en agentes gastan regularmente tokens, tiempo y dinero en subtareas que no pueden resolverse.

Inyección a través de contenido externo

Un agente que lee correos electrónicos, procesa documentos o navega por la web puede encontrarse con contenido que contiene instrucciones hostiles destinadas a apoderarse de él. Eso no es una cuestión relacionada con la seguridad del modelo, sino un ataque de inyección clásico en el límite entre datos confiables y no confiables. Las defensas son estructurales: ejecución en entornos aislados, una separación estricta entre el plano de instrucciones y el plano de datos, y validación de las salidas contra un esquema restringido antes de realizar cualquier acción posterior.

Sin evaluación continua

La razón más común por la cual los sistemas degradan silenciosamente es la falta de una capa de evaluación continua. Un equipo lanza un modelo, celebra la demostración y luego lo trata como una API estática. Cada actualización del proveedor, cada cambio en el esquema del corpus RAG y cada cambio en la población de usuarios puede causar problemas, y sin evaluaciones la primera señal es una queja del usuario.

La plataforma como una constelación

Una plataforma empresarial de IA no es un monolito. Se trata de un conjunto de sistemas, cada uno con sus propias responsabilidades, contratos de interfaz y modos de fallo. El diseño debe abarcar todo el ciclo de vida de la solicitud (ingestión, montaje del contexto, invocación del modelo, ejecución de herramientas, validación de la respuesta, observabilidad), asumiendo que cualquier capa puede fallar.

La recuperación de datos es un proceso en etapas

La generación mejorada por recuperación es más compleja de lo que sugiere su nombre. Un sistema de producción no se limita a incrustar documentos, consultar vectores y pegar contexto. Se trata de una cadena de procesos con al menos cinco etapas, cada una de las cuales puede fallar: ingestión y fragmentación, elección del modelo de incrustación y gestión de versiones, construcción del índice y frecuencia de actualización, clasificación de resultados mediante una combinación de métodos densos y dispersos, y montaje del contexto con umbrales de relevancia. Cada etapa necesita sus propias métricas, y un cambio en una de ellas puede deteriorar las demás sin que nadie se dé cuenta.

Cuatro niveles de memoria del agente

La memoria del agente debe dividirse en cuatro niveles:

• La memoria de trabajo es la ventana de contexto dentro de una sesión.
• La memoria episódica almacena resúmenes de conversaciones anteriores, accesibles durante la sesión.
• La memoria semántica representa el conocimiento empresarial, que corresponde a la capa RAG.

La memoria procedural almacena los patrones de uso de herramientas aprendidos y las heurísticas del dominio.

La difuminación entre estos niveles es una causa frecuente de contaminación del contexto y de que los agentes se comporten de manera inconsistente de una sesión a otra.

Sistemas multiagente y transferencias

A escala modesta, un único agente representa un problema resuelto. El diseño multiagente constituye la frontera más compleja, donde los problemas surgen debido a la sobrecarga de coordinación, la consistencia del estado compartido, la propagación de errores y los comportamientos emergentes que ningún agente individual mostraría.

La parte más descuidada es el protocolo de transferencia, el acuerdo sobre qué información pasa un agente a otro. Un envoltorio mínimo contiene el estado de la tarea, una puntuación de confianza, los pasos completados para la deduplicación, referencias al contexto relevante (no todo el contexto, ya que eso saturaría la memoria) y cualquier restricción detectada en el proceso. Al no existir un esquema estructurado, los agentes transfieren información en lenguaje natural sin formato definido, y el receptor debe interpretar nuevamente la intención, lo que constituye una fuente principal de desviaciones y errores amplificados.

Los equipos también deben decidir cómo comparten la memoria los agentes. Mantener la memoria privada para cada agente facilita su análisis y auditoría, pero duplica las operaciones de recuperación y permite que los estados difieran entre agentes. Una pizarra negra compartida favorece la coordinación, pero requiere control de concurrencia, versionado y lógica de invalidación. La opción predeterminada sugerida es la memoria privada, con eventos de publicación explícitos y versionados que envían los resultados a un almacenamiento compartido una vez completada la tarea.

Las medidas de seguridad son parte de la estructura

Las medidas de seguridad no son una función añadida a un sistema de IA en producción. Son una propiedad estructural. Un sistema que carece de medidas de seguridad por capas no es simplemente un sistema de IA sin funciones de seguridad; es un tipo diferente de sistema que no encaja en un entorno empresarial.

Frenos de emergencia graduales

Cada sistema en producción necesita algo más que un único interruptor de apagado. Necesita una gama de respuestas:

• La limitación de tasas ralentiza las operaciones sin detenerlas por completo.
• La degradación de capacidades desactiva el acceso a las herramientas y pasa a un modo exclusivamente informativo.
• El enrutamiento humano envía todas las solicitudes a agentes humanos.
• La terminación de sesiones cierra de manera ordenada las sesiones activas de los agentes, preservando al mismo tiempo el estado de auditoría.
• Una parada total detiene todo inmutablemente y captura el estado forense.

Cada uno de estos métodos debe poder probarse en entornos reales, ya que una parada de emergencia que nunca se ha probado no cuenta como tal.

La reversibilidad es lo más importante

La seguridad del contenido recibe la mayor atención, pero la cuestión más importante es si una acción puede revertirse. Si un agente envía un correo electrónico incorrecto, elimina una fila de la base de datos, realiza un pago o despliega infraestructura, no hay forma de revertirlo. Cada herramienta debe situarse en una escala de reversibilidad, donde la barra de confianza aumenta a medida que resulta más difícil deshacer la acción: cuanto más permanente sea la acción, mayor debe ser la certeza del sistema antes de proceder sin intervención humana.

La capa de evaluación

Muchos proyectos empresariales cumplen con las “mejores prácticas” en teoría, pero no logran nada en la práctica. Una revisión humana trimestral de 50 resultados seleccionados no es más que un espectáculo de seguridad, y no un marco de evaluación real. Uno verdadero funciona de forma continua, automática y está vinculado al sistema de observabilidad.

Usar un modelo como juez

En la actualidad, hacer que un segundo modelo de lenguaje evalúe las salidas del primero es la forma más escalable para realizar revisiones de calidad continuas, ya que puede analizar respuestas abiertas que el método de coincidencia de cadenas no puede abordar. Sin embargo, también presenta sus propios problemas. Los evaluadores muestran sesgo posicional, favoreciendo respuestas más largas o presentadas antes. También exhiben autoafinidad, como cuando Claude califica más alto las respuestas de estilo Claude. Además, pueden generar alucinaciones en cadena, declarando que una salida es factual cuando en realidad no lo es. Las implementaciones sólidas utilizan conjuntos de pruebas adversarias, se calibran regularmente con juicios humanos y asignan puntajes de incertidumbre a los propios veredictos de los evaluadores.

Evaluaciones dentro del pipeline de despliegue

La evaluación no debería ser un ejercicio ocasional. Las actualizaciones de modelos, las ediciones de instrucciones, la renovación de corpus y los cambios en los esquemas de herramientas deberían activar cada una un conjunto automatizado de pruebas de evaluación, y las regresiones en las métricas clave deberían impedir el lanzamiento. Eso implica umbrales mínimos por métrica, que se consideran parte del contrato de servicio. Un microservicio que no pase sus pruebas unitarias no se lanza, al igual que un sistema de IA que no supere sus pruebas de evaluación.

Observabilidad cuando el espacio de estados es abierto

Observar un sistema de IA difiere de observar un microservicio en un aspecto fundamental: el espacio de estados no tiene límites. Un microservicio o bien procesa una solicitud correctamente o no lo hace. La respuesta de una IA se encuentra en algún punto de una escala continua de calidad, y el hecho de que sea buena puede depender de criterios que solo se pueden medir con otra llamada al modelo. Esto exige un diseño de observabilidad fundamentalmente diferente.

Para cada solicitud de LLM, el registro mínimo útil incluye:

• la solicitud completa, después de la renderización del modelo y antes de su truncamiento
• el contexto recuperado junto con sus fuentes
• la respuesta del modelo tal como fue generada, antes del procesamiento posterior
• un desglose del uso de tokens
• la latencia en cada etapa (recuperación, modelo, procesamiento posterior)
• las puntuaciones de evaluación, si se calculan de forma síncrona
• cada llamada a una herramienta y su respuesta
• señales de confianza o incertidumbre, cuando el modelo las expone
• identificadores de sesión y usuarios seudonimizados
• identificadores de versión para cada elemento involucrado: modelo, plantilla de solicitud, índice y esquema de herramientas

Los identificadores de versión son los más importantes. Sin ellos, relacionar una regresión en la calidad con un cambio específico resulta pura conjetura.

Tres señales de desviación

Detectar la deriva implica observar tres señales al mismo tiempo. En el caso de la deriva en la distribución de las entradas, la pregunta es si las solicitudes recibidas difieren estadísticamente de lo para lo cual estaba ajustado el sistema, algo que la distancia en el espacio de embedding, como la similitud coseno frente a un corpus de referencia, puede revelar antes de que disminuya la calidad. En cuanto a la deriva en la calidad de las salidas, la cuestión es si las puntuaciones de evaluación están disminuyendo, lo cual requiere una evaluación continua y no solo verificaciones periódicas. En relación con la deriva en el comportamiento del modelo, la duda radica en si el proveedor modificó silenciosamente el modelo; por eso se debe ejecutar periódicamente una prueba de referencia determinista contra cada modelo, con alertas cuando la diferencia supere un umbral.

El costo es la arquitectura

El costo es el aspecto que con más frecuencia falta en las discusiones sobre arquitecturas de IA, y es una de las primeras cosas que fallan a escala empresarial. Un sistema que cumple con todos los requisitos técnicos pero cuesta 4 dólares por solicitud no sobrevivirá a su primera revisión operativa. Considere el costo como una restricción arquitectónica, no como un detalle de facturación posterior.

Enrutamiento al modelo más económico y capaz

La herramienta más importante es el enrutamiento inteligente de modelos, que dirige cada solicitud al modelo más económico que aún cumpla con los estándares de calidad. Se necesita una función de enrutamiento que clasifique la complejidad (una búsqueda factual simple, razonamiento multietapa o generación de código), asocie cada categoría a un nivel de modelo y ofrezca una solución alternativa cuando el enrutamiento falla. El propio router puede ser un clasificador pequeño y rápido, y su costo suele recuperarse la primera vez que una solicitud se envía con éxito a un nivel más económico.

Caché semántica

El caché simple rara vez funciona bien con aplicaciones de LLM, ya que las solicitudes con significado idéntico pocas veces coinciden como cadenas de texto. El caché semántico indexa las respuestas según su cercanía en el espacio de embeddings y no según el texto exacto, logrando tasas de acierto del 30 al 60 por ciento en cargas de trabajo de alto volumen, al tiempo que permanece invisible para la capa de aplicación. Requiere un índice rápido de vecinos más cercanos aproximado, un umbral de similitud por debajo del cual se fuerza un error de búsqueda, y una política TTL acorde a la rapidez con la que el conocimiento se vuelve obsoleto.

Presupuestos de tokens

En producción, aproximadamente del 60 al 80 por ciento del uso de tokens proviene normalmente de los prompts del sistema, los esquemas de herramientas y el contexto recuperado, y no de los mensajes de los usuarios ni de las respuestas del modelo. Por lo tanto, la gestión del presupuesto debe realizarse en la fase de configuración: se deben recortar dinámicamente los prompts del sistema para que solo se incluyan las secciones relevantes para el tipo de solicitud, cargar los esquemas de herramientas de forma perezosa para que solo se inserten aquellos seleccionados por el planificador, y organizar la ventana de contexto en niveles de modo que los fragmentos de alta relevancia permanezcan en el contexto principal, mientras que los de menor relevancia aparezcan como resúmenes comprimidos.

Confianza cero para agentes

El concepto de confianza cero fue diseñado para usuarios humanos y servicios estáticos. Aplicarlo a los agentes implica ampliarlo para abarcar conjuntos de capacidades dinámicas, diferentes niveles de confianza y la posibilidad de actuar en nombre de los usuarios sin una aprobación explícita para cada acción.

Identidad para cada agente

Cada agente en un flujo de trabajo de producción necesita su propia identidad criptográfica, distinta del usuario para quien trabaja y de los demás agentes. Las credenciales deben estar vinculadas a la sesión y vencer cuando esta finalice. Deben estar limitadas por capacidades, de modo que la credencial codifique qué puede hacer el agente y no solo quién es. Además, cada emisión y revocación deben registrarse de forma inmutable. Esto permite que el registro de auditoría responda a qué agente, con qué credencial, realizó qué acción para qué usuario y cuándo, una pregunta que resulta crucial durante la investigación de incidentes.

Instrucciones separadas de los datos

La primitiva de seguridad más importante en la IA agente es mantener las instrucciones y los datos en planos separados. Las fuentes no confiables nunca deben contaminar las instrucciones del sistema. En concreto, los datos externos pasan por una capa de saneamiento antes de llegar al contexto, el contenido recuperado recibe una etiqueta de confianza, y se indica al modelo que trate el texto de baja confianza como material para analizar, nunca como comandos. Esto es similar a las consultas SQL parametrizadas: mismo principio, implementación diferente.

Gobernanza integrada desde el inicio

La gobernanza de la IA no es un simple casillero de verificación para cumplir normativas. Es una disciplina operativa continua que necesita soporte arquitectónico. Una organización no puede gobernar un sistema que no puede observar, ni auditar uno que no registra datos, ni hacer cumplir políticas en uno que no fue diseñado para ello. La gobernanza debe integrarse desde el inicio y no añadirse posteriormente.

Políticas como código

Las políticas que se encuentran en documentos en prosa no pueden gestionarse a gran escala. Lo que se necesita es una política como código: reglas que sean legibles por máquinas, conservadas en control de versiones, probables y evaluadas por la pasarela de IA en tiempo de ejecución. Open Policy Agent con su lenguaje Rego es una opción madura. Puede codificar reglas como “ninguna decisión dirigida a clientes en la UE por este modelo, a menos que el resultado incluya una marca de revisión humana”, o “este agente no puede utilizar la herramienta de pagos con datos clasificados como PII”. La evaluación en la pasarela crea un único punto de aplicación y un registro de auditoría completo, lo cual reemplaza a las políticas dispersas, inconsistentes e inexplicadas típicas de la IA empresarial en la actualidad.

Derecho a una explicación

Regulaciones como el Acta de IA de la UE, junto con la gestión de riesgos empresariales, exigen cada vez más que las decisiones tomadas con inteligencia artificial sean explicables para las personas a quienes afectan. Se trata de un requisito arquitectónico y no de una cuestión relacionada con las capacidades del modelo. Incluso un modelo que no pueda explicar su propio razonamiento puede formar parte de un sistema explicable si la arquitectura registra qué información recibió, qué herramientas utilizó, qué opciones consideró y cuán seguro estaba del resultado. El registro de auditoría debe estar diseñado para responder a una solicitud de explicación en el momento de la auditoría, y no reconstruirse posteriormente a partir de los registros que sucedan tener disponibles.

La arquitectura es el producto

Un sistema de IA listo para producción no se define por la calidad de su modelo de lenguaje, sino por lo sofisticada que sea la arquitectura que rodea al modelo. El modelo es un componente poderoso y valioso, difícil de reemplazar, pero que sigue siendo solo un componente.

La arquitectura de IA es el arte de construir sistemas que mantengan su fiabilidad, sean gestionables y puedan mejorarse en el punto donde el no determinismo de la IA se encuentra con los contratos deterministas del software empresarial. Cada capa responde a una pregunta:

• ¿Cómo evitamos resultados defectuosos? Con medidas de control.
• ¿Cómo detectamos una disminución en la calidad? Con evaluaciones y capacidad de observación.
• ¿Cómo coordinamos varios componentes de IA? Con topologías multiagente y protocolos de transferencia.
• ¿Cómo evitamos que los costos aumenten exponencialmente? Con presupuestos de tokens y enrutamiento de modelos.

¿Cómo nos aseguramos de que solo se realicen acciones autorizadas? Con un enfoque de cero confianza y permisos para las herramientas.

¿Cómo satisfacemos a los reguladores y auditores? Con una arquitectura de gobernanza.

Quienes sean nuevos en este campo deben entender que la arquitectura de IA no es simplemente una rama de la arquitectura de software. Es una disciplina independiente, con sus propias primitivas y modelos mentales, y trata la incertidumbre como la principal restricción en el diseño en lugar de como un caso excepcional. Diseñe para la variabilidad y no para el resultado esperado. Observe la distribución, no el promedio. Un sistema que maneja bien al 5 por ciento de casos más difíciles es el que merece el derecho de servir al resto del 95 por ciento en producción.

Leer más

• Construcción de un DeepAgents Harness: permisos, subagentes y aprobación humana — Una guía práctica para crear un planificador de diseño de sistemas con DeepAgents: servidores backend para archivos, reglas de permisos, subagentes, mecanismos de aprobación, habilidades y MCP, además de los casos en que el juicio del modelo sigue fallando.
• Uso de herramientas en producción por parte de los agentes: trazabilidad, intentos repetidos y capacidad de observación — Un agente de un banco llamó en exceso a una API de pago e inventó un número de teléfono. Se explican los conjuntos mínimos de herramientas, la trazabilidad de parámetros, tres niveles de intentos repetidos y las métricas específicas para cada herramienta.