Agentes con herramientas: cómo diseñar permisos, memoria y recuperación ante fallos sin ceder el control

De chatbot a agente: autonomía situada, no confianza ciega

Un agente no es simplemente un asistente que responde en una conversación. En una definición operativa útil para diseño, combina un modelo que interpreta una tarea con estado de ejecución, acceso a herramientas, una política que delimita las decisiones permitidas y un bucle que observa resultados y decide el siguiente paso. Puede consultar una base de datos, abrir un ticket, buscar información, actualizar un registro o invocar una API. La diferencia relevante no es que el modelo “razone”, sino que el sistema puede afectar a otros sistemas fuera de la ventana de chat.

Esta distinción obliga a desplazar la pregunta inicial. No conviene empezar por «¿qué modelo tiene mejores resultados?», sino por «¿qué puede hacer este sistema, con qué identidad, sobre qué recursos y bajo qué condición?». La capacidad de un modelo puede ayudar a completar una tarea, pero no sustituye límites de autorización, validación del resultado ni supervisión. Esta conclusión también sirve al leer análisis de GPT‑6 Astra, Claude Opus 5 o Gemini 3.8 Flash: una mayor capacidad declarada o medida no elimina la necesidad de controles operativos.

No todas las tareas requieren un agente autónomo. Un flujo fijo, con pasos previsibles y pocas excepciones, puede resolverse mejor mediante automatización convencional o un workflow donde el modelo solo clasifica o redacta una propuesta. La autonomía adicional debe justificarse por la variabilidad de la tarea y por la capacidad de contener sus efectos. Como regla de partida, una acción externa debe ser más restringida que una consulta, y una modificación difícil de deshacer debe exigir más evidencia y más supervisión que una acción reversible.

La tarjeta de entrada recomendada para la página matriz es «Agentes: diseño, evaluación y supervisión». Desde ella, esta guía debe presentarse como un marco de arquitectura y decisión, no como una receta universal ni una comparación de proveedores.

Antes de conectar una herramienta: clasificar el impacto de cada acción

Una herramienta no debe habilitarse porque parezca útil en una demostración. Debe tener una ficha de acción: finalidad, sistemas afectados, datos que recibe, identidad usada, operaciones permitidas, límites de volumen, efecto reversible o irreversible, dependencia externa y responsable humano. Esta ficha hace visible una diferencia que suele ocultarse: “consultar pedidos” y “cancelar pedidos” pueden usar la misma API, pero no representan el mismo riesgo.

La clasificación puede combinar cuatro ejes. El impacto estima el daño si la acción es errónea; la reversibilidad determina si puede deshacerse con seguridad; el alcance mide cuántas cuentas, registros o sistemas pueden verse afectados; y la sensibilidad valora los datos o secretos expuestos. Un quinto eje práctico es la ambigüedad: si la petición admite varias interpretaciones razonables, la acción no debería ejecutarse de forma autónoma aunque sea técnicamente posible.

Las comunicaciones externas merecen una categoría propia. Enviar un correo a un cliente, publicar una respuesta o crear una incidencia puede ser reversible en sentido técnico, pero no necesariamente en términos reputacionales, contractuales o de privacidad. Lo mismo ocurre con cambios de producción: disponer de una operación de reversión no convierte en inocuo un despliegue incorrecto. Para estos casos, el diseño debe prever revisión del contenido, destinatario, alcance y momento de ejecución.

En el primer tercio de la implementación conviene conectar esta clasificación con la guía sobre «acciones irreversibles y aprobaciones» cuando esté publicada. El objetivo es que la aprobación no sea un gesto genérico de confirmación, sino una decisión informada sobre una acción concreta, sus parámetros y sus posibles consecuencias.

Permisos de mínimo privilegio: controles que no dependen del texto del modelo

El mínimo privilegio consiste en conceder solo los permisos necesarios para una tarea definida, durante el tiempo necesario y sobre los recursos necesarios. En agentes, esto exige ir más allá de un token general con acceso amplio. Una credencial que permite leer, editar y borrar todos los recursos convierte una salida errónea, una instrucción manipulada o un fallo de integración en un incidente de gran alcance.

Una práctica sólida es separar identidades por herramienta, entorno y propósito. El agente de soporte no debería usar la misma identidad que el proceso de despliegue, y una identidad de pruebas no debería tener acceso a producción. Las credenciales de duración limitada reducen la ventana de exposición, pero no corrigen por sí solas una autorización excesiva: también hacen falta ámbitos de acceso específicos, cuotas, restricciones de red y validación del lado del servidor.

La herramienta debe verificar la autorización de forma determinista. Es preferible una interfaz que exponga operaciones concretas —por ejemplo, crear un borrador de respuesta para un caso asignado— frente a una interfaz genérica que permita ejecutar consultas o comandos arbitrarios. Cuando el sistema use listas de recursos permitidos, importes máximos o roles, esos límites deben aplicarse fuera del contexto que el modelo puede modificar. Las instrucciones del prompt pueden orientar; no son una frontera de seguridad suficiente.

Los conectores deben tratar todo contenido recibido desde páginas, documentos, correos, tickets y respuestas de herramientas como datos potencialmente no confiables. Que un texto incluya una orden no le concede autoridad. La política de acciones, la identidad de servicio y el validador de parámetros deben prevalecer sobre cualquier instrucción hallada durante la tarea.

Esta sección debe enlazar, cuando exista, con «datos sensibles y credenciales». Para equipos que tratan datos personales, la minimización también implica evitar entregar a la herramienta más atributos de los necesarios para completar la acción y definir quién puede acceder a los registros resultantes.

Cuándo exigir a un humano en el circuito

La revisión humana es más útil cuando se integra en un punto de decisión definido. Pedir confirmación para cada consulta de bajo riesgo ralentiza el trabajo y favorece aprobaciones mecánicas; no pedirla para acciones relevantes traslada la carga de detectar el error a quien sufre sus efectos. El diseño debe fijar umbrales explícitos y presentar a la persona revisora la información necesaria para decidir.

Una aprobación debería mostrar la acción prevista, los parámetros finales, los sistemas afectados, la identidad que la ejecutará, la justificación generada por el agente y el efecto de aprobar o rechazar. Si la acción depende de hechos inciertos, la interfaz debe mostrar también esa incertidumbre en lugar de presentar una recomendación como si fuera una comprobación. Aprobar una intención abstracta, como “resolver el caso”, es menos seguro que aprobar una operación delimitada, como “enviar este borrador a este destinatario”.

Deben pasar por revisión humana, como punto de partida, los borrados, pagos o compromisos económicos, cambios de producción, comunicaciones externas, modificaciones de permisos, tratamiento de categorías especialmente sensibles y operaciones cuya solicitud sea ambigua. La organización puede añadir umbrales de importe, número de registros o gravedad operativa. Tales umbrales son decisiones de política interna: no hay una cifra universal que convierta una acción en segura.

La supervisión humana tampoco debe entenderse como una excusa para desatender el sistema. La persona revisora necesita autoridad real para rechazar, corregir y escalar; formación sobre el proceso; y una carga de trabajo que permita revisar. Si recibe cientos de solicitudes casi idénticas, el control puede convertirse en una formalidad.

Memoria útil sin retención indefinida

La memoria puede mejorar la continuidad de una tarea, pero también aumenta la superficie de privacidad, el riesgo de usar información obsoleta y la dificultad de corregir errores. Conviene distinguir al menos entre contexto de sesión, estado operativo de una tarea, preferencias persistentes autorizadas, conocimiento recuperado desde fuentes documentales y registros de auditoría. Estas categorías cumplen finalidades distintas y no deberían compartir automáticamente la misma retención ni los mismos permisos.

El contexto de sesión sirve para mantener coherencia durante una interacción y suele caducar al terminarla o tras un plazo breve. El estado operativo conserva información necesaria para retomar un trabajo, como una referencia de caso o un punto de control. Las preferencias persistentes requieren una finalidad clara, procedencia conocida y un mecanismo de consulta y corrección. El conocimiento recuperado debe conservar su origen, versión y fecha, para que el sistema pueda detectar si la fuente ha sido reemplazada o invalidada.

La procedencia es tan importante como el contenido. Si una memoria procede de un usuario, un sistema de negocio o una inferencia del propio agente, el sistema debería distinguirlo. Una inferencia no verificada —por ejemplo, una prioridad o una preferencia deducida— no debe tratarse como un dato confirmado. Además, una memoria persistente no debería convertirse en una vía para conservar secretos, datos irrelevantes o instrucciones introducidas por contenido externo.

Antes de almacenar, hay que responder cuatro preguntas: qué finalidad concreta cubre, quién puede leerlo, cuándo caduca y cómo se invalida. La guía futura sobre «memoria, retención y caducidad» puede desarrollar estas políticas. En el ámbito europeo, si la memoria contiene datos personales, su diseño debe evaluarse dentro de las obligaciones aplicables de protección de datos; esta guía no sustituye el análisis jurídico ni determina por sí sola la base de licitud de un tratamiento.

Diseñar para el fallo: detener, comprobar y recuperar

Los fallos de herramientas, redes y dependencias externas son normales. También lo son las respuestas incompletas, los tiempos de espera y los estados ambiguos: una llamada puede haber llegado al sistema receptor aunque el agente no haya recibido confirmación. Un diseño robusto no presupone que “reintentar” es siempre seguro. Primero debe saber qué operación se intentó, qué resultado se confirmó y qué operaciones pueden repetirse sin cambiar el efecto final.

La semántica HTTP distingue las operaciones idempotentes, cuyo efecto previsto es el mismo tras una o varias solicitudes idénticas, de las que no lo son. Esta distinción ayuda a diseñar reintentos, pero no elimina la necesidad de comprobar el estado de negocio. Una solicitud técnicamente idempotente puede seguir teniendo consecuencias no previstas si sus parámetros son incorrectos. Para operaciones de creación, pago o envío, una clave de idempotencia y una consulta de estado previa a reintentar suelen ser controles más apropiados que repetir ciegamente la llamada.

El agente necesita condiciones de parada. Deben fijarse un número limitado de intentos, tiempos de espera, presupuesto de llamadas y criterios de escalado. Tras superar un umbral, el caso debe entrar en una cola de revisión con el contexto mínimo necesario: acción prevista, identificador de correlación, respuestas recibidas y pasos ya realizados. Reintentar indefinidamente puede amplificar una incidencia externa o generar acciones duplicadas.

Toda acción relevante debería tener un punto de control antes de su efecto irreversible y, cuando sea viable, un plan de compensación. Una compensación no equivale siempre a una reversión perfecta: devolver un importe no borra una comunicación ya enviada, y restaurar un registro no elimina una posible divulgación. La documentación de recuperación debe declarar expresamente esos límites.

Observabilidad y auditoría sin recopilar datos innecesarios

La observabilidad permite reconstruir qué ocurrió; no exige conservar cada dato intercambiado sin límite. Para una acción relevante, el registro debería asociar la solicitud inicial, la política aplicada, las herramientas elegidas, los parámetros autorizados o una representación protegida de ellos, la identidad de ejecución, el resultado, los reintentos y la intervención humana. Los identificadores de correlación permiten seguir un caso entre componentes sin depender de copiar el contenido completo en todos los registros.

Los registros deben protegerse como un activo sensible. Si incluyen prompts, respuestas, documentos o parámetros, pueden contener información personal, secretos o instrucciones no confiables. Por ello necesitan controles de acceso, retención definida, separación de entornos y mecanismos que impidan modificaciones silenciosas. También es útil distinguir el registro operativo para detectar fallos del registro de auditoría orientado a investigar una decisión; pueden requerir distintos niveles de detalle y acceso.

Una buena reconstrucción separa hechos de interpretación. Debe ser posible saber qué dato devolvió una herramienta, qué regla bloqueó o permitió una operación y qué recomendación formuló el modelo. No es razonable prometer una explicación completa de todo comportamiento del modelo, pero sí es posible registrar la cadena de decisiones programáticas y los artefactos operativos que determinan si una acción se ejecutó.

La minimización no es solo una obligación de privacidad; mejora la seguridad y la utilidad de los registros. Un log excesivo dificulta encontrar señales relevantes y amplía el conjunto de datos expuestos ante un acceso indebido.

Evaluar antes del despliegue: tarea, permisos y recuperación

La evaluación debe reproducir el entorno de decisión, no solo medir la calidad de una respuesta textual. Un plan mínimo combina tareas representativas, casos límite, errores de herramientas, peticiones ambiguas, intentos de introducir instrucciones desde contenido externo y comprobaciones de autorización. El criterio de éxito debe incluir tanto completar correctamente una tarea permitida como rechazar una acción prohibida, detenerse ante incertidumbre y escalar cuando corresponde.

Los benchmarks son útiles para comparar determinadas capacidades en condiciones definidas. Terminal-Bench evalúa la resolución de tareas en entornos de terminal aislados, mientras que OSWorld reúne tareas sobre aplicaciones web y de escritorio en entornos reales de evaluación. Esas mediciones pueden aportar señales sobre el desempeño de un agente en esas tareas, pero no certifican que su identidad tenga permisos correctos, que proteja datos de una organización o que se recupere de manera segura en una integración concreta.

Por ello, cuando estén disponibles, deben incorporarse enlaces a Terminal-Bench y OSWorld con un texto que aclare que los benchmarks no sustituyen las pruebas en el entorno propio. Las pruebas internas necesitan cuentas de ensayo, datos sintéticos o adecuadamente controlados, simulación de dependencias y casos de recuperación. También deben verificar que un rechazo de autorización no desencadena rutas alternativas más permisivas.

El marco de gestión de riesgos puede ayudar a asignar responsables, documentar decisiones y revisar controles a lo largo del ciclo de vida. No sustituye la especificación técnica de cada permiso. La evidencia de prueba, los incidentes y los cambios de herramientas deben alimentar revisiones periódicas de la matriz de autonomía.

Plantilla final: decidir el nivel de autonomía

La decisión de autonomía debe poder revisarse como una política, no quedar implícita en un prompt. Para cada herramienta y acción, documente la categoría de riesgo, los datos involucrados, el permiso concreto, la identidad, los límites, la necesidad de aprobación, la estrategia de recuperación, los registros y el propietario. Si alguno de estos elementos no está definido, la autonomía asignada probablemente es prematura.

Un punto de partida razonable es usar cuatro niveles. El nivel de solo lectura permite consultar recursos autorizados. El nivel de propuesta con aprobación permite investigar y preparar una acción, pero reserva la ejecución a una persona. El nivel de ejecución limitada habilita operaciones reversibles y acotadas bajo reglas deterministas. El nivel de ejecución autónoma se reserva para acciones de bajo impacto, con alcance reducido, reversión o compensación conocida, supervisión disponible y evidencia de pruebas suficientes.

La matriz no debe ser permanente. Un incidente, un cambio de proveedor, una herramienta nueva, una ampliación de datos accesibles o una modificación de la política de negocio justifican revisarla. Del mismo modo, un agente puede empezar en modo de propuesta y ganar autonomía solo después de demostrar comportamiento fiable dentro de un alcance medido. Reducir la autonomía tras una anomalía es una respuesta de control, no un fracaso del proyecto.

Como siguiente paso editorial, el cierre puede enlazar con «decidir si automatizar un flujo». La pregunta decisiva no es si un agente puede realizar una tarea, sino si la organización puede delimitar, observar y recuperar sus efectos con un nivel de riesgo aceptable.

Alcance e incertidumbres

Esta guía presenta un marco técnico y operativo basado en fuentes institucionales, documentación técnica y guías de construcción de agentes aportadas. Sus recomendaciones de arquitectura no garantizan por sí mismas la seguridad de un caso de uso ni sustituyen pruebas, análisis de amenazas, revisión de privacidad, controles sectoriales o asesoramiento jurídico.

La aplicación del Reglamento General de Protección de Datos depende de las circunstancias del tratamiento, de los roles de las partes y de otros requisitos aplicables. En particular, la guía no determina si un caso concreto entra en las reglas sobre decisiones individuales basadas únicamente en tratamiento automatizado ni qué salvaguardas adicionales proceden. Tampoco cubre obligaciones nacionales, laborales, financieras, sanitarias o contractuales que puedan ser relevantes.

Las características de herramientas, modelos, APIs y benchmarks cambian con rapidez. Antes de desplegar, el equipo debe confirmar la versión evaluada, el comportamiento de las integraciones, los permisos efectivos y las condiciones de ejecución. La evidencia de un entorno de prueba no debe extrapolarse automáticamente a producción.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.