Los agentes de inteligencia artificial (IA) pueden ofrecer respuestas convincentes en demostraciones, especialmente cuando las preguntas son claras, los documentos están actualizados y las herramientas funcionan según lo esperado. Sin embargo, esta aparente facilidad puede generar una confianza excesiva sobre su rendimiento en entornos reales.
En la práctica, esos agentes suelen enfrentarse a situaciones más complejas. Un usuario puede hacer una pregunta similar a la vista en la demo pero formulada de modo diferente, un registro puede estar incompleto, una herramienta puede retornar un error o una política puede haber cambiado recientemente. Incluso pueden detectarse límites de capacidades, como leer una factura sin poder modificarla. Estas son las dificultades reales donde comienza el trabajo.
La clave está en distinguir que el modelo de lenguaje es solo una parte del servicio. El resto lo constituye lo que se denomina el “armazón del agente”: la estructura que envuelve al modelo para proporcionarle las entradas correctas, validar sus respuestas y contener fallos antes de que se propaguen. Es un concepto similar a los marcos de prueba en desarrollo de software. Un agente para producción necesita ese envoltorio que controle qué datos puede ver, qué acciones realizar y cómo actuar cuando falta información esencial. 
“El modelo es solo una parte del servicio. El armazón del agente es el resto: la estructura que la aplicación construye alrededor del modelo.”
Obtener buenas respuestas del modelo es importante, pero no garantiza que el agente esté preparado para el trabajo real. Esa es la tarea del armazón: definir contratos para las herramientas que limiten los errores, imponer permisos fuera del modelo incluso si la instrucción intenta ignorarlos, mantener registros de contexto y trazabilidad que el equipo pueda inspeccionar, y construir pruebas basadas en fallos comunes.
El Armazón del Agente: el modelo es un componente; el armazón define los límites que el modelo no tiene por sí solo.
El modelo carece de contexto operativo
Un modelo de lenguaje es capaz de razonar con la información que se le envía, pero no cuenta con conocimiento inherente sobre los sistemas o reglas concretas de un negocio. No sabe si un registro está actualizado o si una acción requiere aprobación, a menos que el sistema que lo acompaña le proporcione esas reglas.
Por ejemplo, un agente de soporte puede limitarse a generar respuestas a partir de una base de conocimientos. Otro puede leer registros de cuenta, consultar políticas específicas y enviar excepciones a revisión. Este segundo agente necesita mucho más que un prompt mejorado.
“El modelo aporta el razonamiento, y el armazón aporta los límites que el modelo no posee por sí mismo.”
Muchas fallas en producción ocurren en este punto de interacción entre el modelo y los sistemas externos. La calidad de la respuesta no indica si el agente accedió a la cuenta correcta o si siguió funcionando después de una falla en una herramienta crítica.
Las herramientas requieren contratos que limiten errores
Las herramientas son el punto de contacto entre el armazón y los sistemas productivos y por ello deben tener contratos claros. Un agente puede llamar a una API equivocada; por eso cada herramienta debe tener funciones específicas con esquemas definidos para sus entradas y salidas, tiempos límite y estados de error bien categorizados (por ejemplo, errores recuperables o terminales).
Por ejemplo, una herramienta para actualizar un plan de facturación debe utilizar una clave de idempotencia para evitar la doble aplicación de cambios y diferenciar claramente los tipos de error:
{
"name": "update_billing_plan",
"description": "Aplicar un cambio de plan previamente cotizado a una cuenta.",
"input": {
"account_id": "uuid (verificado por servidor)",
"quote_id": "uuid",
"idempotency_key": "uuid"
},
"output": { "status": "applied | rejected", "effective_date": "date" },
"timeout_ms": 5000,
"errors": {
"retryable": ["LIMITACION_DE_TASA", "TIEMPO_AGOTADO_SERVIDOR"],
"terminal": ["COTIZACION_EXPIRADA", "APROBACION_REQUERIDA", "CUENTA_NO_ENCONTRADA"]
}
}
Además, es conveniente separar las herramientas de lectura, que solo consultan datos, de las de escritura, que modifican información o inician procesos. Los cambios deben realizarse solo tras confirmación explícita del usuario y una validación de permisos, garantizando transparencia y trazabilidad.
Los permisos son decisiones de producto
Los permisos determinan qué puede hacer un agente en nombre de una persona y son una parte esencial del diseño del producto. Un agente que dispone de credenciales demasiado amplias puede cometer errores graves, como enviar información al destinatario incorrecto o acceder a datos para los que no tiene autorización. Además, los permisos limitan el alcance de posibles ataques de inyección de instrucciones dentro de los datos que el modelo procesa, una vulnerabilidad potencial.
“No se puede confiar en que el modelo resista todas las instrucciones maliciosas contenidas en los datos, por ello el límite de permisos es una frontera crítica de seguridad.”
Cada herramienta debería tener identidad y autorización propias con solo los accesos estrictamente necesarios. Se debe pasar la identidad verificada del usuario en cada solicitud, y no depender del modelo para rellenar parámetros sensibles, evitando suplantaciones. También es clave distinguir permisos para contestar preguntas y permisos para actuar, integrando flujos de aprobación cuando se requiera.
El contexto requiere un camino definido
El contexto es la memoria de trabajo del agente, y el armazón decide qué información incluir. Proporcionar pocos datos limita la capacidad del agente para tomar decisiones adecuadas; incluir demasiados puede dificultar la identificación de hechos clave y aumentar costes y latencia.
Se debe construir el contexto cuidadosamente: normas del sistema, estado y solicitudes del usuario, evidencias autorizadas, y únicamente el historial reciente relevante. Además, hay que decidir qué memorias deben persistir en distintas interacciones, eliminando información obsoleta para dejar espacio a datos importantes futuros.
Es imprescindible registrar por qué se incluyó cada dato en el contexto y cuándo se actualizó por última vez, para saber con exactitud qué vio el agente ante cada solicitud y facilitar auditorías y aclaraciones.
La arquitectura de datos también influye: si la búsqueda vectorial, la memoria del agente y las reglas de acceso están repartidas en sistemas distintos, cada recuperación puede romper el control de permisos. Integrar estas funciones en un único sistema que aplique el control de acceso simplifica la seguridad y reduce errores.
Las trazas hacen visibles los fallos
Un registro de trazabilidad o “traza” es el historial de auditoría del agente y debe incluir no solo la respuesta final sino también cada paso intermedio, como las llamadas a herramientas o comprobaciones de permisos. Por ejemplo:
14:02:31 solicitud_usuario "Cámbiame al plan anual"
14:02:31 contexto política_v41 (actualizado 2026-07-28), cuenta 8143, ámbito verificado
14:02:33 llamada_herramienta obtener_plan_facturacion(cuenta_id=8143) -> { plan: "mensual-pro" }
14:02:35 llamada_herramienta cotizar_cambio_plan(plan="anual-pro") -> { cotizacion_id: "q_77", diferencia: "-$240/año" }
14:02:49 confirmación usuario aprobó cotización q_77
14:02:50 permiso escritura permitida (rol: propietario_cuenta)
14:02:51 llamada_herramienta aplicar_cambio_plan(cotizacion_id="q_77") -> { estado: "aplicado" }
14:02:52 respuesta "Estás en el plan anual a partir del 1 de septiembre." (13.4s, 2,180 tokens, $0.04)
Este historial es vital si, meses después, se investiga por qué se ejecutó un cambio, permitiendo identificar un fallo por política obsoleta o una acción no autorizada. Sin esta trazabilidad, las investigaciones comienzan en la incertidumbre.
Muchas herramientas y frameworks de IA ofrecen integración con estándares como OpenTelemetry para registrar estas trazas. Eso sí, hay que protegerlas con el mismo rigor que la información sensible que contienen.
Prueba los fallos reales que los usuarios encontrarán
Diseña escenarios de prueba basados en casos reales: tickets de soporte, errores reportados, registros de actividad. Usa documentos fijos y respuestas controladas, configurando previamente estados para poder reproducir fallos y no depender de recrear manualmente situaciones caóticas.
Incluye tanto tareas normales como peticiones ambiguas, con datos desactualizados o herramientas caídas, tareas que requieren aprobaciones, y procesos que necesitan mantener estado sin arrastrar información obsoleta. Es fundamental entender que los agentes no son deterministas y pueden comportarse distinto en momentos distintos, por lo que es preciso ejecutar cada prueba varias veces y establecer umbrales de aceptación basados en el riesgo.
Incorpora estas pruebas con cada cambio de prompt, modelo o interfaz de herramienta y especialmente antes de grandes actualizaciones, para asegurar que las mejoras no comprometan pasos críticos como las confirmaciones. Al detectar un nuevo fallo en producción, añádelo al conjunto de pruebas para evitar que se repita.
Un fallo controlado protege al usuario
No todos los peticiones deben completarse forzosamente. A veces, la respuesta correcta es reconocer la imposibilidad de continuar, solicitar información adicional o escalar a un humano. Por ejemplo, un agente puede requerir un número de cuenta para avanzar, o admitir que no puede verificar una política sin aprobación.
Estos escenarios deben estar diseñados para guiar al usuario con mensajes claros que expliquen qué falta, cómo proporcionarlo o cómo solicitar una revisión, en lugar de fallar silenciosamente o realizar acciones incorrectas. Ante falta de permiso, el agente debe expresar la necesidad de autorización o redirigir la tarea, evitando cambios no deseados y tareas costosas de revertir.
“Nada de esto es glamuroso. Tampoco lo es un arnés para escalar. Nadie lo nota hasta que alguien se cae y entonces es lo único que importa.”
Construye el armazón alrededor del agente
Si vas a iniciar un proyecto con agentes de IA, comienza por inventariar las herramientas y definir claramente los límites de lectura y escritura de cada una. Todo lo demás debería articularse en torno a este esquema.
El riesgo de omitir esta estructura es alto, porque sin ella un modelo, aunque potente, puede comportarse erráticamente o provocar daños en ambientes reales.
Para desarrollos con LangChain o LangGraph, existen integraciones con bases de datos especializadas como Oracle AI Database, que permiten gestionar búsquedas vectoriales, estado persistente, puntos de control y datos de aplicación, todo en un entorno que también controla permisos y seguridad.
