Conectar un agente al correo de una empresa abre varias posibilidades: buscar un mensaje, preparar una respuesta o enviarla. Las tres pueden usar la misma integración. Las consecuencias son distintas, y el permiso para una no debería habilitar las otras.
MCP ayuda a conectar modelos con recursos y herramientas. Cuando esa conexión permite actuar sobre un sistema, la empresa necesita definir el alcance: qué datos puede leer el agente, qué puede modificar y en qué momento necesita una persona.
La autonomía no es el objetivo inicial. El objetivo es que una tarea quede mejor resuelta y que la empresa pueda reconstruir qué ocurrió.
Dibujá la superficie de acción
Antes de elegir un framework, listá las herramientas que el agente podría usar y separalas por efecto:
- Lectura: consultar una base, buscar documentación o recuperar un registro.
- Preparación: redactar un borrador, clasificar una solicitud o armar una propuesta.
- Escritura reversible: crear un archivo de trabajo, abrir un ticket en estado pendiente o guardar una versión.
- Acción externa: enviar un mensaje, modificar un registro, aprobar un pago o activar un proceso.
El primer piloto puede limitarse a lectura y preparación. La escritura reversible se agrega cuando existe una forma clara de deshacerla. Las acciones externas necesitan autorización explícita, registro y un responsable que pueda detener el flujo.
La especificación de Model Context Protocol describe tres capacidades centrales que un servidor puede ofrecer: recursos, prompts y tools. También indica que los implementadores deben cuidar el consentimiento, la privacidad y la seguridad de las herramientas. Un protocolo ordena la conexión; no reemplaza la política de permisos de la empresa.
Separá instrucciones de autoridad
Un documento recuperado, un mensaje de un cliente o una página web puede contener texto que intenta cambiar el comportamiento del agente. Ese contenido es entrada de datos, no una orden de la organización. El sistema debe mantener separadas las instrucciones del producto, los datos que consulta y las acciones que tiene permiso de ejecutar.
La distinción se vuelve visible cuando el agente trabaja con correo, documentos, repositorios o sistemas internos. ¿Puede leer todo o sólo una carpeta? ¿Puede usar datos de una empresa para responder a otra? ¿Puede copiar un secreto a una salida? ¿Puede enviar algo sin revisión? Las respuestas deben estar implementadas en la frontera de la herramienta y en la cuenta que la herramienta usa.
El proyecto GenAI de OWASP mantiene riesgos específicos de aplicaciones con modelos y agentes. Prompt injection, divulgación de información sensible, exceso de agencia y dependencia ciega de la salida son problemas de diseño y operación. No se resuelven con un prompt más largo.
Poné una persona en los lugares correctos
La revisión humana no significa leer cada token. Significa definir qué decisiones requieren criterio, autorización o responsabilidad legal. Un agente puede preparar un presupuesto, pero alguien debe confirmar los precios y las condiciones. Puede sugerir una respuesta, pero una persona debe decidir cuándo se envía. Puede detectar una anomalía, pero el equipo debe saber qué hacer con la señal.
El punto de revisión necesita información suficiente: entrada usada, herramientas invocadas, salida propuesta, incertidumbres y acción que se solicita. Un botón que dice «aceptar» sin contexto transfiere responsabilidad sin ayudar a decidir.
Evaluá el flujo completo
La calidad del agente se mide con casos representativos y con fallas esperadas. Probá entradas incompletas, permisos insuficientes, datos contradictorios, herramientas caídas y solicitudes que deben rechazarse. Registrá qué debía pasar y qué pasó.
La guía de evaluaciones de OpenAI describe cómo definir criterios, fuentes de datos y graders, y cómo ejecutar una evaluación sobre distintas configuraciones. La idea se puede aplicar aunque el modelo no sea de OpenAI: separar el conjunto de casos, el criterio y la ejecución evita discutir sólo a partir de ejemplos llamativos.
Una evaluación mínima puede tener cuatro preguntas:
- ¿El agente eligió la herramienta correcta?
- ¿Usó solamente los datos permitidos?
- ¿La salida cumple el formato y la regla de negocio?
- ¿Pidió revisión cuando no podía decidir con seguridad?
Agregá una quinta pregunta para la operación: ¿se puede explicar y revertir lo que hizo?
Empezá con un flujo pequeño
Elegí una tarea repetitiva con un resultado acotado. Definí el rol del agente, sus herramientas, los datos permitidos, los casos de prueba, el punto de aprobación y la forma de volver al proceso anterior. Durante el piloto, guardá la versión de las instrucciones y de las herramientas; si cambia una pieza, tiene que ser posible distinguir el efecto.
En 42N, la orquestación se piensa con roles, tickets, revisión y criterios de aceptación. Esa estructura sirve para un equipo de agentes y también para una automatización simple: cada paso tiene una responsabilidad y una condición de salida.
El siguiente nivel no es darle más permisos porque el piloto fue interesante. Es demostrar que la tarea conserva calidad, que los datos están controlados y que el equipo entiende cuándo intervenir. Cuando la evidencia alcanza, se amplía el alcance. Cuando no, se vuelve al límite anterior.
Si estás evaluando agentes para una operación, contanos qué tarea querés revisar y qué sistema interviene. La primera decisión es saber qué puede leer, qué puede preparar y qué nunca debería ejecutar por su cuenta.