Un agente no se evalúa únicamente por el modelo que utiliza. También importa qué herramientas puede invocar, qué información recibe y qué efectos puede producir.
El caso de uso necesita límites que se entiendan
Cuando evalúo una solución de IA, necesito entender qué quiere hacer el negocio y qué capacidad estamos autorizando. Resumir documentos, consultar un sistema y modificar registros tienen impactos diferentes. Que todos utilicen el mismo modelo no convierte esas actividades en una única decisión.
Documentaría usuarios, información, herramientas y efectos permitidos. También quién valida los resultados y qué sucede cuando el sistema no está disponible. El alcance debe poder explicarse sin depender de una descripción comercial. Si un agente puede ejecutar acciones, necesito conocer cuáles, sobre qué recursos y con qué identidad. Una autorización genérica para “usar IA” deja demasiadas preguntas abiertas para diseñar permisos, responsabilidades y pruebas que sirvan en la operación real.
Definir el ámbito
Registrar el caso de uso, los usuarios, las fuentes de datos y las acciones permitidas. Un cambio de herramienta, integración o población puede requerir una nueva evaluación.
MCP conecta capacidades; hay que revisar lo que expone
Un servidor MCP puede proporcionar herramientas y acceso a información. Para revisarlo necesito conocer cada capacidad expuesta, sus parámetros, las credenciales utilizadas y la autorización aplicada. La confianza en el proveedor no sustituye a esa revisión, y un servidor interno también puede tener permisos demasiado amplios.
Separaría consulta y modificación, y comprobaría dónde se valida el acceso. Una descripción de herramienta que indique “solo lectura” no impide técnicamente una escritura si el servicio acepta esa operación. El control debe existir en el componente que ejecuta o autoriza la acción. También revisaría los destinos accesibles y cómo se gestiona el consentimiento o la delegación. La integración debe poder retirarse sin depender únicamente de que el agente decida dejar de utilizarla.
De la solicitud a la acción autorizada
- UsuarioSolicita una actividad dentro del caso aprobado.
- AgentePropone una acción y sus parámetros.
- Autorización y límitesValidar alcance; aprobación humana cuando corresponda.
- Herramienta MCP y servicioComprobar permisos y ejecutar la operación autorizada.
- Recurso y efectoRegistrar el resultado y relacionarlo con la solicitud.
El contenido consultado no concede permisos. Los límites se aplican en los componentes que autorizan y ejecutan.
Diseñar barreras de ejecución
Separar lectura y escritura. Restringir acciones de alto impacto y definir cuándo requieren intervención humana. Tratar las instrucciones de contenido externo como datos no confiables.
La información consultada puede intentar dar órdenes
Un documento, una página o una respuesta de herramienta puede contener instrucciones que intenten cambiar el comportamiento del agente. El problema aparece cuando ese contenido se interpreta como autorización para consultar más datos, modificar un recurso o enviar información a otro destino.
Lo probaría con escenarios que representen esas desviaciones. Por ejemplo, un documento que pida adjuntar información adicional a un mensaje o una respuesta que sugiera utilizar otra herramienta fuera del alcance. Necesitamos comprobar qué acción se intentó y qué barrera la impidió. Las instrucciones al modelo pueden ayudar, pero las decisiones sensibles requieren controles de permisos y ejecución. El resultado de una prueba debe incluir acciones y parámetros, no limitarse a que la respuesta textual parezca prudente.
Ejemplo: de resumir documentos a enviar mensajes
Un agente aprobado para resumir documentos obtiene después una herramienta para enviar mensajes a terceros. Aunque el modelo no cambie, ahora puede producir un efecto externo. Deben revisarse destinatarios permitidos, datos que puede incluir y acciones que necesitan aprobación. Autorizar una finalidad no equivale a autorizar cualquier ampliación de sus capacidades.
La aprobación humana necesita contenido concreto
Para una acción de alto impacto, una confirmación genérica puede aportar muy poco. La persona que aprueba debe entender qué se va a hacer, con qué datos y sobre qué destino. En el ejemplo del envío de mensajes, eso incluye destinatario y contenido antes de ejecutar.
También hay que controlar que lo aprobado corresponda a la acción realizada. Si cambian los parámetros después de la revisión, la autorización puede dejar de representar la operación. Definiría qué cambios requieren una nueva confirmación y cuáles son los límites de automatización. No pondría una aprobación manual en cada paso sin estudiar la actividad: puede generar aceptación automática por cansancio. El nivel de intervención debe responder al impacto y permitir que quien revisa tome una decisión informada.
Una prueba que aporta evidencia
Diseñar escenarios con contenido que intente cambiar las instrucciones del agente permite evaluar sus límites. El resultado relevante no es solo la respuesta textual: también importa si invocó una herramienta, qué parámetros utilizó y si logró acceder a información fuera del ámbito. Los registros deben evitar convertirse en una copia innecesaria de datos sensibles.
Mantener un inventario que represente capacidades
Un inventario de aplicaciones de IA puede quedarse corto si solo registra el nombre del proveedor o del modelo. Necesitamos saber qué integraciones están activas, qué datos alcanzan y qué acciones permiten. Dos usos del mismo servicio pueden requerir controles diferentes.
Relacionaría cada caso con su responsable, la configuración aprobada y las pruebas realizadas. También distinguiría las capacidades disponibles de las habilitadas. Que una herramienta ofrezca envío de mensajes no significa que ese permiso forme parte del alcance autorizado; debemos comprobar la configuración que impide utilizarlo.
Los cambios deben notificarse antes de ampliar el efecto del agente. Añadir un servidor MCP, otro repositorio o una población nueva puede alterar la exposición. La evaluación necesita centrarse en lo que cambia y conservar el vínculo con la finalidad original.
Para una revisión periódica, elegiría ejecuciones representativas y comprobaría si corresponden al caso aprobado. Miraría también permisos que ya no se utilizan y herramientas incorporadas durante pruebas. Una prueba de concepto debe tener un entorno, límites y criterio de finalización. Si continúa funcionando y gana usuarios sin una nueva decisión, el alcance real deja de coincidir con el inventario. Corregir esa diferencia requiere revisar capacidades y accesos, no solo actualizar el nombre de la iniciativa en una lista.
Asegurar trazabilidad
Relacionar ejecución, identidad del agente, usuario iniciador y acción realizada. Definir mecanismos para detener el agente y revocar sus accesos.
Operar, detener y revisar el alcance
Un agente necesita responsables para su configuración, sus accesos y sus incidencias. Debemos poder detener la ejecución, revocar credenciales y localizar las acciones ya realizadas. También definir cómo tratamos reintentos: una segunda llamada puede repetir un efecto externo si el servicio no evita duplicados.
Antes de ampliar el uso, revisaría escenarios permitidos y prohibidos, fallos de herramientas y cambios de permisos. Los registros deben relacionar solicitud, identidad y acción, sin almacenar innecesariamente información sensible. Para medir resultados, miraría desviaciones de alcance, bloqueos efectivos y cobertura de pruebas, además de utilización. Una nueva herramienta o una integración con más usuarios puede cambiar el riesgo aunque el modelo siga siendo el mismo. Esa ampliación merece una evaluación concreta y una nueva decisión sobre los límites.
Referencias para profundizar
Fuentes oficiales para contrastar y ampliar estos conceptos. Este artículo presenta un enfoque práctico; no reproduce los requisitos completos de las referencias.
Los ejemplos son ilustrativos. Las decisiones de implementación deben adaptarse a los requisitos y dependencias de cada organización.