Primero consultar, después modificar: cómo definir los permisos de un agente de IA

TL;DR (Quick Summary)

Un agente de IA no debería recibir permisos de escritura solo porque puede leer mucha información. El diseño correcto separa consulta, decisión y ejecución, con límites, aprobaciones, propiedad clara y revisiones periódicas.

• Empezar por el flujo real → Separar lectura, decisión y ejecución.
• Diseñar el alcance de lectura → Consultar solo lo necesario.
• Limitar la escritura por tipo de registro → Restringir registros, campos y acciones.
• Introducir umbrales de aprobación → Escalar acciones de alto impacto.
• Aplicar límites operativos → Evitar cambios masivos por error.
• Resolver la propiedad del agente → Suspender o revocar accesos cuando cambien las responsabilidades.
• Hacer una revisión trimestral → Detectar ampliaciones de alcance.
• FAQ: decisiones prácticas → Resolver excepciones y despliegues graduales.

Key Takeaway: Los permisos deben corresponder a las acciones que el agente necesita ejecutar en un flujo concreto. Consultar primero y modificar después limita el impacto de los errores y facilita mantener el control.

Un agente puede consultar el CRM, interpretar una solicitud y actualizar automáticamente un registro. El riesgo aparece cuando ese acceso le permite modificar cualquier cliente, campo o estado sin aprobación, límites de volumen ni un responsable vigente. Una instrucción ambigua, un cambio de proceso o una credencial sin revisar puede convertir una automatización útil en una fuente de datos incorrectos.

Empezar por el flujo real: qué consultas hace el agente y qué cambios tendría sentido permitirle

El diseño de permisos debe partir del trabajo que se quiere ejecutar; la lista de capacidades de la plataforma viene después. Hay que describir qué solicitud recibe el agente, qué contexto consulta, qué decide él y qué decide una persona, y cuál es la salida esperada.

Por ejemplo, ante una devolución, el agente puede consultar el pedido, el estado del pago, las políticas y las interacciones previas; después clasifica el caso y propone una respuesta. Crear una tarea para soporte, actualizar la prioridad del ticket y emitir un reembolso son acciones distintas y deben tener permisos separados. Modificar datos bancarios o cerrar una disputa puede requerir controles adicionales.

La separación entre observación, análisis y ejecución evita conceder edición a un agente que solo necesita entender un caso. Para documentar cada etapa, sirven tres preguntas:

• Entrada: ¿qué evento activa el flujo y qué datos entrega?
• Decisión: ¿qué condiciones debe evaluar el agente?
• Salida: ¿qué resultado genera, a quién lo envía y qué sistema podría modificar?

Esta descripción revela permisos innecesarios. Si el resultado es recomendar una prioridad, quizá el agente solo necesite leer tickets y proponer una etiqueta interna. Si debe asignar un caso, el permiso puede limitarse a ese campo. «Acceso al CRM» no describe una necesidad operativa; «leer tickets abiertos y actualizar únicamente su prioridad» sí.

También hay que distinguir entre proponer y aplicar. Primero, el agente puede generar una acción para revisión humana. Después, solo las decisiones repetitivas y de bajo impacto deberían pasar a ejecución automática, una vez observados los casos reales. En Bitrix24, ese paso puede darse con las reglas de automatización del CRM, que ejecutan una acción concreta, como crear una tarea o cambiar al responsable, cuando un registro llega a una etapa definida.

Lista de verificación de permisos y matriz de roles

Ingresa tu correo electrónico para descargar una guía que te ayudará a comenzar con cualquier software de gestión de proyectos.

Reconozco que he leído y entendido la Política de Privacidad de Bitrix24

Diseñar el alcance de lectura antes de pensar en permisos de escritura

La lectura tampoco es inocua. Consultar más información de la necesaria puede exponer datos personales, mezclar contextos o introducir variables ajenas al flujo. El acceso debe definirse por fuente, nivel de detalle y finalidad.

Para clasificar soporte, quizá basten el identificador del cliente, el producto, el estado del pedido y los últimos eventos del ticket. No hace falta consultar notas de recursos humanos, el historial completo de pagos o documentos de identidad. Si la tarea se resuelve con metadatos, una vista filtrada o un registro de eventos, no debe abrirse el registro original.

Tabla: ejemplo de alcance de lectura para un flujo de soporte.

El control base debe ser determinista: roles, tablas, campos, entornos y credenciales separadas por sistema fijan el límite antes de que el modelo interprete una instrucción. El agente no debería decidir por sí mismo qué datos puede consultar.

Las vistas filtradas pueden restringir los registros al país, unidad o proceso correspondiente, y una credencial de pruebas no debe conservar acceso a clientes reales. En Bitrix24, los permisos de acceso por rol permiten, por ejemplo, que un rol solo vea los elementos del CRM de los que es responsable o los de su departamento.

Cada lectura también debe quedar registrada. Un registro de auditoría útil incluye al menos:

• Fecha y hora: cuándo se realizó la consulta.
• Identidad técnica: agente y credencial utilizados, con identificadores que permitan rastrearlos.
• Fuente y objeto consultado: por ejemplo, el sistema y el ID del ticket o pedido.
• Caso o ID de operación: la solicitud que justificó el acceso.
• Categoría de datos: contacto, pedido, pago u otra categoría pertinente.

El objetivo es conservar evidencia suficiente para investigar una respuesta incorrecta o una consulta fuera de propósito, sin duplicar en los registros los datos sensibles consultados. Define también quién puede acceder a estos logs y durante cuánto tiempo se conservan.

Limitar la escritura por tipo de registro, campos permitidos y acciones exactas

«Permisos de edición» es una definición demasiado amplia. La escritura debe expresarse como una combinación de objeto, campo, operación y condición. Crear un registro, actualizar una etiqueta, cerrar un caso y escalar una solicitud tienen riesgos distintos.

Un agente de ventas podría crear una tarea y actualizar la fecha del próximo contacto, pero no cambiar el propietario de una cuenta estratégica ni el límite de crédito. En soporte, podría añadir una etiqueta aprobada, mientras que cerrar el ticket requeriría revisión. En finanzas, puede automatizarse la generación de una solicitud, no la aprobación del pago.

El permiso debe especificar:

• Tipo de registro y campos disponibles para escritura.
• Valores válidos y estados en los que puede actuar.
• Condición que activa la acción.
• Operaciones expresamente bloqueadas.

La denylist (lista de denegación o bloqueo) debe excluir campos como datos bancarios, descuentos máximos o información legal; registros como cuentas VIP, contratos en disputa o expedientes regulados; y acciones como borrar, transferir la propiedad o aprobar pagos. No debe depender de que el agente «sepa» qué evitar: el control tiene que imponerse en la capa de ejecución.

La guía de OWASP sobre exceso de autonomía recomienda aplicar la autorización en los sistemas de destino, en lugar de dejar que el modelo decida si una acción está permitida.

Esa misma configuración por rol sirve para el propio agente: se le asigna un rol con los permisos mínimos necesarios, por ejemplo, consultar negociaciones y tener denegada la eliminación de registros. Si el agente se equivoca, el sistema rechaza la acción aunque la instrucción la pida.

También hay que separar acciones reversibles de las difíciles de deshacer. Una etiqueta puede corregirse; eliminar un registro, enviar una comunicación legal o cambiar una condición comercial puede generar consecuencias externas. Sin una reversión confiable, el umbral de autorización debe ser mayor o la acción debe quedar fuera del agente.

No es un riesgo teórico. En julio de 2025, el agente de programación de Replit borró la base de datos de producción de un proyecto de Jason Lemkin, fundador de SaaStr, en plena congelación de cambios y pese a la instrucción de no actuar sin aprobación humana; según Fortune, se perdieron registros de más de 1.200 ejecutivos y 1.190 empresas, que luego pudieron recuperarse manualmente. La respuesta de Replit fue separar de forma automática las bases de datos de desarrollo y de producción: un límite impuesto fuera del modelo.

"Se ha mejorado el proceso de reclutamiento de personal, logrando una mayor eficiencia y transparencia."

Director de TI, Alejandro Rolandi

TEXO

EMPEZAR GRATIS

Introducir umbrales de aprobación cuando el impacto supera lo que debe automatizarse

Las acciones con impacto económico, contractual, reputacional u operativo necesitan una regla de aprobación. El agente puede clasificar el caso y preparar la acción, pero la autorización debe depender de condiciones deterministas y de un aprobador identificado.

Los umbrales pueden considerar el monto, la criticidad del cliente, el volumen de registros, el tipo de información y el estado del proceso. La decisión de escalar no debe quedar en manos del modelo:

• Bajo impacto: el agente ejecuta y registra la acción.
• Impacto intermedio: crea una propuesta y solicita aprobación.
• Alto impacto: bloquea la ejecución y deriva el caso a una persona autorizada.

Ejemplo ilustrativo con reembolsos: por debajo de 50 USD, ejecución automática con registro; entre 50 y 500 USD, aprobación del líder del equipo; por encima de 500 USD, revisión de Finanzas. Los montos concretos dependen del margen, el valor promedio de los pedidos y el riesgo de fraude de cada empresa. Lo importante es que el tramo lo determine una regla explícita basada en el monto, no el criterio del agente.

La pausa debe ser operativa. La propuesta debe mostrar el registro afectado, la acción, los datos que la sustentan, las reglas aplicadas, los cambios esperados y la incertidumbre detectada. El aprobador debe poder aceptar, rechazar o devolver la propuesta sin reconstruir el caso. En Bitrix24, el diseñador de procesos de negocio del CRM permite añadir ese paso: el proceso se detiene hasta que la persona designada aprueba o rechaza el reembolso.

La aprobación debe asociarse a una identidad y a una versión de la propuesta. Si después cambia el monto, el destinatario, el registro o cualquier otro dato que afecte la decisión, la autorización debe invalidarse y solicitarse de nuevo. Si nadie responde, el caso debe escalarse, volver a una cola de revisión humana o permanecer bloqueado; nunca debe ejecutarse por defecto.

Aplicar límites operativos para evitar daños por error, bucles o uso excesivo

Aunque los permisos estén bien definidos, un agente puede repetir una acción, procesar un lote equivocado o interpretar una instrucción defectuosa a gran escala. Los límites operativos reducen el impacto de estos errores.

Establece límites por solicitud, lote, usuario, sistema y ventana de tiempo. Un agente que etiqueta tickets puede tener un máximo de actualizaciones por ejecución y un tope por hora; al alcanzar cualquiera de los límites, debe detener las escrituras y generar una alerta o una tarea de revisión. Los límites de frecuencia (rate limits) también protegen a los sistemas conectados de picos de actividad.

Ejemplo ilustrativo: permitir un máximo de 20 actualizaciones por ejecución y 100 por hora, con una ventana deslizante que contabilice siempre los últimos 60 minutos, en lugar de reiniciarse a cada hora en punto. Si varias ejecuciones comparten el mismo sistema o credencial, el límite horario debe contabilizarse de forma conjunta para evitar que cada ejecución tenga una cuota independiente.

Antes de escribir, el flujo debe validar el formato, la existencia del registro, los duplicados, los conflictos de estado y las reglas de negocio. Si dos procesos modifican el mismo caso, la actualización no debe sobrescribir silenciosamente la versión más reciente. Cuando sea posible, una simulación previa debe mostrar los registros que se modificarían.

El plan de respaldo debe definirse antes del despliegue. Ante falta de contexto, ambigüedad, respuesta incompleta o validación fallida, el agente debe suspender las modificaciones, conservar la información necesaria y enviar una propuesta a revisión humana. Los reintentos deben ser acotados e idempotentes: después de un tiempo de espera, el sistema debe comprobar si la operación ya se ejecutó para no duplicar tareas, comunicaciones o ajustes.

Las alertas deben cubrir ejecuciones sin salida, aumento de bloqueos, colas de aprobación acumuladas y cambios rechazados. Un tablero que solo muestra acciones completadas puede ocultar que el trabajo vuelve manualmente a los equipos.

Resolver la propiedad del agente: qué pasa cuando su responsable cambia o deja la empresa

Un agente sin responsable vigente es una cuenta huérfana con capacidad de actuar. Cada agente debe tener un propietario humano, un responsable secundario y un inventario actualizado de sistemas conectados, permisos, propósito y rutas de escalamiento.

La propiedad no equivale a la cuenta técnica que ejecuta las llamadas. Esta puede ser estable, pero una persona debe responder por el alcance y el mantenimiento. Cuando el propietario deja la empresa o cambia de función, el agente debe pasar a un estado restringido o suspendido. Puede conservarse en modo de solo lectura para investigación, pero no debe seguir modificando registros hasta que se apruebe la reasignación.

La reasignación requiere revisar credenciales, aprobaciones pendientes, colas, conexiones externas y la vigencia del caso de uso. El inventario debe incluir tokens almacenados e integraciones configuradas por el propietario anterior.

Durante la salida y la reasignación, hay que revocar las credenciales que ya no deban utilizarse y rotar las claves y los tokens que deban mantenerse. La revisión debe abarcar también las credenciales compartidas o almacenadas en integraciones y sistemas externos. Una credencial que siga activa puede conservar acceso aunque su creador ya no trabaje en la empresa.

En Bitrix24, por ejemplo, los webhooks entrantes utilizan los permisos del usuario que los creó y los alcances configurados. Al despedir a un empleado con integraciones activas, el administrador elige entre desactivarlas o mantenerlas; si las mantiene, pasan a un usuario del sistema que conserva los permisos para que sigan funcionando, y cualquier persona con el enlace del webhook puede seguir usándolo.

En este segundo caso, el acceso no desaparece automáticamente: hay que revisar las integraciones que se conservan, quién puede usar sus enlaces y qué permisos siguen necesitando. Si se requiere cambiar el alcance, se deben ajustar o sustituir las integraciones y revocar las claves que ya no deban utilizarse.

Si nadie acepta formalmente la responsabilidad de la operación, suspenderla es más seguro que mantenerla activa por defecto.

Hacer una revisión trimestral que detecte ampliaciones de alcance antes de que se vuelvan permanentes

Los permisos suelen crecer por excepciones: se abre acceso para resolver una incidencia o se conecta una tabla durante una prueba y el cambio permanece. La revisión trimestral debe comparar el alcance aprobado con el comportamiento real.

Cruza los permisos concedidos, las acciones ejecutadas y las excepciones aprobadas. La diferencia puede revelar una ampliación progresiva del alcance (scope creep). En Bitrix24, la sección Recursos para desarrolladores > Integraciones muestra las integraciones activas y el usuario con el que se ejecuta cada una, así que el administrador puede ver de un vistazo qué conexiones revisar. Un permiso usado una sola vez durante una emergencia exige una decisión explícita: retirarlo, limitarlo o justificar su continuidad.

Para cada permiso, responde estas preguntas:

• ¿El agente utilizó el permiso durante el periodo?
• ¿La tarea todavía requiere ese nivel de acceso?
• ¿Existe una alternativa de solo lectura o una vista filtrada?
• ¿La acción tiene un responsable y una ruta de reversión?

La fiabilidad no se mide solo por las acciones completadas. También deben observarse las propuestas aprobadas sin cambios, los errores de validación, los bloqueos por la lista de denegación o bloqueo (denylist), las reversiones, los reintentos y los escalamientos. Muchas correcciones pueden indicar problemas de contexto, reglas o permisos, no necesariamente del modelo.

La revisión debe terminar con una decisión documentada: mantener, reducir, suspender, ampliar bajo control o retirar. Registra también el motivo, la persona responsable y la fecha límite para aplicar el cambio, y actualiza el inventario y la documentación. Los cambios relevantes de sistema, propietario, fuente de datos o caso de uso deben activar una revisión extraordinaria; el ciclo trimestral no sustituye ese control.

FAQ: decisiones prácticas al configurar permisos de un agente

Conclusión

Un agente debería empezar leyendo y ganarse los permisos de escritura por etapas, con evidencia de que funciona de forma fiable. Como próximos pasos:

• Definir un flujo y delimitar qué puede leer el agente.
• Restringir la escritura y fijar umbrales de aprobación.
• Asignar un propietario y establecer revisiones trimestrales de permisos.