Una persona deja tu empresa y desactivas su cuenta. ¿Qué ocurre con el agente virtual que había creado? Puede seguir accediendo a un buzón compartido, una base de clientes y una biblioteca de documentos. Si nadie sabe qué identidad utiliza, dar de baja al empleado no garantiza que desaparezca la automatización.
Cuando los agentes pasan de responder preguntas a utilizar herramientas de negocio, el acceso se convierte en una cuestión de gestión además de técnica. La empresa necesita saber qué agentes existen, quién responde por ellos y qué acciones pueden realizar. De lo contrario, un piloto que funciona puede convertirse en una dependencia operativa sin un responsable claro.
Asigna a cada agente una tarea reconocible
Antes de discutir permisos, escribe una breve descripción de su trabajo. Por ejemplo: preparar un borrador de resumen con los documentos adjuntos a una solicitud de servicio asignada. Resulta más útil que decir que el agente ayuda al departamento de soporte. Esa descripción permite evaluar para qué necesita cada permiso.
Anota qué inicia el proceso, qué información puede utilizar, dónde debe guardar el resultado y cuándo necesita intervenir una persona. Para preparar un resumen quizá deba leer adjuntos y guardar un borrador. Eso no significa que necesite cerrar el caso, enviar un correo externo o modificar el contrato del cliente.
Asigna un responsable de negocio y alguien que mantenga la solución. El primero decide si la tarea sigue siendo necesaria y si los resultados cumplen las expectativas. El segundo se ocupa de la implementación, las credenciales y el despliegue. En una empresa pequeña puede ser la misma persona, pero ambas responsabilidades deben quedar claras.
Las plataformas incorporan identidades específicas para agentes
La documentación de Microsoft Entra Agent ID describe identidades de agentes, responsables y plantillas que gestionan su creación y credenciales. También distingue entre agentes que actúan de forma autónoma y agentes que actúan en nombre de un usuario. Son distinciones útiles para el diseño; hay que comprobar qué opciones e integraciones admite el entorno elegido. Consulta la guía de arquitectura de identidades de Microsoft.
La consecuencia para el negocio es sencilla: registra la identidad real de cada integración. Un nombre como “Asistente comercial” dice muy poco sobre su autoridad. Pregunta qué cuenta aparece en la auditoría, quién puede cambiar sus permisos y cómo desactivar el agente sin apagar otro servicio que la empresa necesita.
Evita compartir una identidad con muchos privilegios entre varios experimentos solo porque facilita las demostraciones. Si varios procesos utilizan las mismas credenciales, resulta difícil distinguir qué permiso corresponde a cada tarea. Separar responsabilidades desde el principio puede simplificar mucho una investigación o una retirada posterior.
Impón los permisos en la herramienta que ejecuta la acción
Imagina que un agente de soporte recibe una petición para consultar la factura de otro cliente. El agente debería rechazarla, pero el servicio de facturas también debe comprobar por su cuenta el límite entre clientes. La regla sigue siendo necesaria cuando el agente genera una solicitud técnicamente válida con un identificador incorrecto.
Siempre que sea posible, utiliza operaciones concretas: consultar la solicitud autorizada, proponer una modificación permitida o guardar un borrador asociado a un caso existente. Una herramienta que acepta consultas o destinos arbitrarios resulta más difícil de controlar. La aplicación debe validar usuario, registro y operación antes de realizar cambios.
Separa también una petición de una acción completada. Si una conexión se interrumpe después de solicitar una modificación, el agente debe comprobar el estado real o trasladar la incertidumbre a alguien. Repetir ciegamente puede duplicar mensajes o registros. Tener permiso para actuar no elimina la necesidad de hacerlo de manera fiable.
Trata los documentos como información, no como autoridad
Los agentes leen correos, páginas web y archivos que pueden incluir texto destinado a alterar su comportamiento. OWASP identifica este riesgo como inyección indirecta de instrucciones y explica que recuperar información no elimina el problema. Entre sus medidas figuran limitar privilegios y pedir aprobación para operaciones de alto impacto. Consulta su guía sobre prompt injection.
En una revisión de negocio, dibuja la separación entre lo que dice un documento y lo que permite el sistema. Un archivo puede aportar una dirección de entrega para revisarla. No puede concederse permiso para cambiar por sí mismo la dirección aprobada en el ERP. Las indicaciones de un adjunto de proveedor no deben convertirse en órdenes de administración.
Prepara una prueba con documentos de ejemplo inofensivos. Incluye una instrucción ajena a la tarea y comprueba que la operación propuesta sigue respetando las reglas aprobadas. Revisa las peticiones a las herramientas además del texto final. Una respuesta amable no demuestra que no se haya intentado una acción inapropiada.
Haz que las aprobaciones permitan decidir
Una persona no puede aprobar con criterio un botón que únicamente dice “continuar”. Muestra la acción propuesta, el cliente afectado, los campos que cambiarán y cualquier destinatario externo. Cuando la consecuencia sea importante, añade la evidencia relevante y la diferencia entre el estado actual y el propuesto.
La aprobación debe estar vinculada a esa propuesta. Si después cambian el destinatario o el importe, la aprobación anterior no debería autorizar silenciosamente la nueva versión. Define cuánto tiempo sigue siendo válida y si debe volver a comprobarse el registro antes de ejecutar la operación.
En el agente de resúmenes, guardar un borrador interno puede estar permitido dentro del alcance acordado. Enviarlo al cliente puede necesitar una revisión adicional. Estas diferencias deben verse en el proceso, en lugar de quedar escondidas dentro de un documento de instrucciones que el equipo apenas consulta.
Planifica la retirada al preparar el despliegue
Mantén un inventario con finalidad, responsable, identidad, sistemas conectados y fecha de revisión de cada agente. Incluye los pilotos temporales. Indica qué debe ocurrir cuando el responsable se marcha, termina un contrato o la empresa sustituye la tarea por otro procedimiento.
Ensaya una desactivación controlada. Comprueba que se detienen las tareas programadas, las credenciales dejan de autorizar nuevas acciones y los casos pendientes siguen visibles para las personas. Decide cuánto tiempo deben conservarse los registros y resultados según las políticas existentes. Retirar el agente no debería borrar la información necesaria para entender lo que ya hizo.
Revisa los accesos cuando amplíes el alcance. Añadir otro departamento, un buzón nuevo o la capacidad de enviar mensajes externos merece una decisión específica. Mantener el mismo nombre no convierte los nuevos permisos en equivalentes a los del piloto inicial.
Un primer trabajo concreto con Worktechlabs
En Worktechlabs podemos revisar los límites de aplicación e integración de un agente de IA y convertir los hallazgos en un plan de implementación acotado. Ayuda disponer de la tarea prevista, las integraciones actuales, ejemplos de resultados y las personas autorizadas para aprobar acciones.
Un primer entregable puede ser un mapa de accesos y una prueba funcional de una operación controlada. Así la empresa dispone de una base concreta para decidir qué puede hacer el agente, qué requiere aprobación y quién mantendrá la responsabilidad después del lanzamiento. También facilita discutir futuras ampliaciones: una tarea nueva, un permiso nuevo y alguien que responda por ambos.
Fuentes revisadas el 7 de octubre de 2026. Confirma las capacidades de identidad y los requisitos de despliegue antes de la implementación.
