Cómo definir permisos de un agente de IA
Una matriz para decidir qué consulta, qué prepara y qué ejecuta un agente, con responsables y pruebas de rechazo antes de conectarlo a tu operación.
Tu agente necesita consultar una solicitud, pero la cuenta que le entregaron también permite modificar clientes y borrar registros. Entender cómo definir permisos de un agente de IA empieza por separar lo que necesita para trabajar de todo lo que la plataforma permite hacer.
No basta con escribir que debe ser cuidadoso. Proponemos una matriz operativa para empresas en Latinoamérica: tarea, recurso, acción, alcance y aprobación. El objetivo es que cada capacidad tenga una razón y que las acciones no autorizadas encuentren una barrera real.
¿Qué son los permisos de un agente de IA?
Los permisos de un agente de IA son las autorizaciones que delimitan qué datos puede consultar, qué operaciones puede solicitar y bajo qué condiciones puede ejecutarlas. Deben vincularse a una tarea y a una identidad verificable. No equivalen a sus instrucciones: las restricciones también deben aplicarse en el sistema que recibe la operación.
Para diseñarlos, distingue tres preguntas:
- Capacidad: ¿existe una herramienta para realizar la acción?
- Autorización: ¿este agente puede usarla sobre este registro y para esta solicitud?
- Aprobación: ¿hace falta que una persona confirme la operación concreta?
Que una herramienta esté disponible no debería resolver automáticamente las otras preguntas. Un agente comercial puede necesitar consultar una solicitud sin tener autorización para revisar todos los expedientes de la empresa.
OWASP describe la agencia excesiva como un riesgo asociado a capacidades, permisos o autonomía excesivos. Recomienda limitar herramientas y privilegios y exigir aprobación humana para acciones de alto impacto. Esa referencia sustenta el principio general; la matriz que sigue es nuestra propuesta práctica de diseño, no una certificación de seguridad.
¿Cómo construyes una matriz de permisos por tarea?
Parte de una tarea que el equipo ya conozca y divídela en acciones observables. Para cada acción, escribe qué recurso necesita, qué registros abarca, quién la autoriza y qué ocurre si falta información. Evita permisos generales como «acceso al CRM»: describe operaciones que puedas probar y rechazar por separado.
En los diagnósticos aparece una petición que conviene reformular: conectar la IA con toda la base de datos para que pueda ayudar. Nuestro criterio es otro: definir primero las funciones que necesita y mantener la lógica del negocio detrás de esas funciones. Una puerta concreta se puede revisar; un acceso abierto deja demasiadas decisiones implícitas.
Esta matriz es ilustrativa, no describe la configuración de un cliente:
| Tarea | Recurso y alcance | Acción permitida | Condición o aprobación |
|---|---|---|---|
| Informar un estado | Solicitud asociada al usuario verificado | Consultar estado y siguiente paso | Validar identidad y relación con el registro |
| Preparar una respuesta | Fuentes aprobadas para esa línea de atención | Crear borrador | No enviarlo si contiene una excepción sin resolver |
| Actualizar un dato operativo | Campos autorizados de la solicitud | Proponer modificación | Confirmación del responsable antes de guardar |
| Transferir un caso | Conversación y resumen necesario | Asignar a un especialista habilitado | Mantener el alcance de acceso del destinatario |
| Confirmar un pago | Evidencia de una fuente autorizada | Ninguna confirmación basada solo en una imagen | Verificación independiente y decisión autorizada |
Añade una columna interna con la persona dueña de cada regla. Si nadie puede explicar por qué existe un permiso, déjalo pendiente en vez de habilitarlo por comodidad.
¿Cómo separas consultar, preparar y ejecutar?
Trata consultar, preparar y ejecutar como niveles distintos, no como un único permiso de acceso. Consultar obtiene información autorizada; preparar deja una propuesta sin efecto operativo; ejecutar cambia un estado o comunica una decisión. Habilita cada nivel solo cuando su resultado, sus límites y su responsable estén definidos.
Consultar sin mostrar información de más
Define campos concretos. Para responder si una solicitud sigue en revisión quizá basten el estado y el siguiente paso; no hace falta entregar todos los comentarios internos. Diseña la respuesta de la herramienta para devolver lo necesario, en lugar de confiar en que el agente omita después los datos sobrantes.
Preparar sin guardar una decisión
Un borrador de actualización debe distinguirse de una actualización aplicada. Propón que la interfaz muestre el valor actual, el propuesto y la fuente. Si el equipo rechaza la sugerencia, el registro original debe conservarse.
Ejecutar con una operación acotada
Evita una herramienta genérica que permita cualquier cambio. Prefiere operaciones específicas con campos admitidos y condiciones comprobables. Si la tarea requiere otro permiso, detén ese paso y deriva la solicitud; no amplíes la autorización durante la conversación para terminar a toda costa.
Esta separación complementa la guía para implementar agentes de IA en una empresa: allí explicamos el recorrido completo; aquí delimitamos cada acción.
¿Qué debe aprobar una persona y cómo queda registrado?
Reserva la aprobación humana para acciones cuyo impacto o incertidumbre exijan criterio del responsable, según las reglas de tu empresa. La aprobación debe referirse a una operación concreta, con sus datos y destinatario. Un «sí» genérico no debería autorizar una cadena de cambios que la persona todavía no ha visto.
La idea se repite en nuestras conversaciones de trabajo: la IA propone y una persona decide cuando el proceso es delicado. Convertir ese criterio en un control requiere definir qué se aprueba, no solo añadir un botón.
Para una modificación que requiera aprobación, proponemos mostrar:
- El registro y los campos afectados, sin información innecesaria.
- El valor anterior y el cambio solicitado.
- La fuente o el motivo de la propuesta.
- El efecto esperado y las excepciones pendientes.
- La identidad del responsable habilitado para aprobar.
Si cambia el destinatario o el contenido después de revisar, solicita una aprobación nueva. Para el registro operativo, conserva la relación entre solicitud, propuesta, aprobación y resultado, con acceso restringido y una política de conservación definida por la empresa.
No atribuyas una ejecución exitosa a una aprobación: son eventos distintos. Tras autorizar, la herramienta todavía puede rechazar la operación o fallar.
¿Cómo compruebas que los límites sí se cumplen?
Prueba tanto el recorrido permitido como los intentos que deben rechazarse, en un ambiente separado y con información de ejemplo. Comprueba el resultado en el sistema, no solo la explicación del agente. Un mensaje que dice «no puedo hacerlo» no demuestra que la herramienta haya bloqueado una operación indebida.
Usa esta secuencia como lista de aceptación:
- Caso permitido: consulta un registro dentro del alcance y revisa qué campos devuelve.
- Otro registro: intenta consultar información de una persona o equipo no autorizado.
- Acción distinta: pide borrar o cambiar algo cuando solo se concedió lectura.
- Aprobación ausente: solicita ejecutar una propuesta todavía pendiente de revisión.
- Datos modificados: cambia la propuesta después de aprobar y comprueba que no herede esa autorización.
- Reintento: repite una solicitud y verifica que no produzca efectos duplicados.
- Permiso retirado: revoca el acceso y confirma que una sesión abierta ya no pueda seguir usándolo.
Documenta para cada prueba la condición inicial, el resultado esperado y la evidencia observada. Si el bloqueo depende únicamente de que el modelo recuerde una instrucción, vuelve al diseño de la herramienta y de la autorización.
La guía de seguridad de agentes de OWASP recomienda que la validación del alcance, los privilegios y la aprobación sea independiente del modelo. No presentamos esta lista editorial como sustituto de una revisión técnica completa.
¿Cómo lo resolvemos en LemaBot?
En LemaBot construimos software a medida y agentes de IA para empresas en Latinoamérica, partiendo de tareas y límites definidos con quien opera. El caso de Amity Seguros muestra un alcance concreto: un CRM propio con Ami, agente de WhatsApp que el equipo entrena con sus fuentes y que enruta a especialistas por línea de seguro.
Puedes conocer ese trabajo en el caso de Amity Seguros. No afirmamos que su implementación use exactamente la matriz ilustrativa de este artículo ni publicamos su configuración de accesos.
Para tu operación, proponemos comenzar con el inventario de acciones: qué necesita consultar el agente, qué prepara y qué queda en manos de una persona. Luego conectamos los sistemas necesarios, probamos los límites y revisamos la operación. No se trata de conceder acceso completo y corregir después.
Si estás evaluando agentes de IA para tu empresa, lleva al diagnóstico una tarea real y una excepción. Es más útil que una lista abierta de funciones deseadas.
Preguntas frecuentes
Definir permisos exige resolver dudas operativas antes de elegir una herramienta: quién solicita la acción, a qué información tiene derecho y quién responde por el resultado. Estas preguntas ayudan a revisar la matriz con el equipo. Las respuestas orientan el diseño, pero cada autorización debe comprobarse en los sistemas que vas a conectar.
¿Las instrucciones del agente reemplazan los permisos del sistema?
No. Las instrucciones expresan cómo debe comportarse; la autorización determina qué operación puede realizar sobre un recurso. Diseña ambos controles y prueba el rechazo en la herramienta, no únicamente en la respuesta conversacional.
¿Un agente de solo lectura necesita límites por usuario?
Sí: consultar también puede exponer información. Define qué registros y campos puede devolver según la identidad verificada y la tarea; evita conceder lectura global solo porque el agente no modifica datos.
¿Puede usar la misma cuenta que una persona administradora?
Nuestra recomendación es darle una identidad propia y permisos específicos. Así puedes revisar su alcance y retirarlo sin depender de una cuenta humana con capacidades que la tarea no necesita.
¿Todos los cambios necesitan aprobación humana?
No tiene por qué ser así. Decide según el impacto, la reversibilidad y las reglas del proceso; documenta qué acciones pueden ejecutarse bajo condiciones comprobables y cuáles requieren revisión de una persona.
¿Qué pasa cuando el agente necesita un permiso nuevo?
Detén esa acción y entrégala al responsable, sin ampliar accesos desde la conversación. Revisa la tarea, actualiza la matriz y repite las pruebas antes de habilitar la nueva capacidad.
Si tu equipo todavía no tiene claro dónde termina la consulta y empieza una decisión, habla con Leda en lemabot.com. Agendamos un diagnóstico sin costo para revisar el proceso y delimitar qué debería hacer el agente y qué debe seguir bajo control de tu equipo.
