Respuesta rápida
El diseño de permisos de un agente de IA debe empezar por el flujo útil más estrecho. Separa lectura, borrador, envío, exportación y borrado; exige aprobación para acciones difíciles de revertir; registra cada cambio externo; y amplía permisos solo después de ejecuciones revisadas.
- No concedas acceso a toda una app cuando puedes definir permisos por acción.
- Leer, redactar, crear, actualizar, enviar, exportar, borrar, reembolsar y aprobar son permisos distintos.
- La aprobación humana debe colocarse antes de la llamada de herramienta arriesgada, no solo al final.
- Todo cambio en un sistema externo necesita log trazable y ruta de recuperación.
- La expansión de permisos debe ser gradual, revisable y reversible.
- Ideal para
- Diseñadores de automatización, operadores, consultores y equipos técnicos que conectan agentes de IA con sistemas de negocio, APIs, documentos y plataformas de workflow.
- Tema
- Automatización
- Última revisión
- 13 jun 2026
Mapa del flujo
Un mapa práctico para convertir esta guía en un flujo de automatización.
- 01 Entrada
Define primero la tarea repetida, los datos necesarios, el responsable y el criterio de éxito.
- 02 Paso de IA
Usa IA en pasos con límites claros: redacción, clasificación, resumen, enrutamiento o llamadas a herramientas.
- 03 Revisión humana
Mantén aprobaciones, excepciones, límites de coste y decisiones sensibles bajo revisión humana.
- 04 Salida
Convierte el resultado en una checklist, un prompt guardado, un SOP o una automatización monitorizada.
- agentes de IA
- automatización con IA
- permisos
- mínimo privilegio
- llamadas a herramientas
Antes de aplicar
Usa la guía como decisión de flujo, no como atajo de herramienta.
Antes de automatizar, confirma la entrada, el punto de revisión humana y el resultado que medirás después.
¿Qué paso debe volverse repetible primero?
Ayuda a decidir qué puede leer, redactar, cambiar, enviar, exportar o borrar un agente de IA antes de conectarlo a herramientas reales.
6 Fuentes consultadas
Verifica funciones y precios cambiantes con las fuentes enlazadas y las páginas oficiales.
Abrir recursos
Empieza con un piloto pequeño y amplía solo cuando el punto de revisión esté claro.
- No concedas acceso a toda una app cuando puedes definir permisos por acción.
- Leer, redactar, crear, actualizar, enviar, exportar, borrar, reembolsar y aprobar son permisos distintos.
- La aprobación humana debe colocarse antes de la llamada de herramienta arriesgada, no solo al final.
- Todo cambio en un sistema externo necesita log trazable y ruta de recuperación.
Ruta de workflow
Dónde encaja esta guía
Usa esta sección para conectar la guía que estás leyendo con el workflow más amplio que apoya.
Una ruta para comparar plataformas de automatización, builders de apps, builders de agentes, contabilidad y asistentes de IA.
Abrir ruta de workflow- Mejor encaje
- equipos que deciden entre comprar una herramienta simple, construir un flujo interno o adoptar una plataforma más amplia
- No es ideal si
- El trabajo aún no tiene un disparador, responsable o entrada repetible. Primero define el proceso.
Un agente de IA se vuelve delicado en cuanto toca sistemas reales. Leer una política interna es una cosa. Cambiar una etapa de CRM, enviar un correo, exportar datos de clientes, aprobar un reembolso o borrar un registro pertenece a otra categoría.
La pregunta equivocada es: “¿Puede el agente conectarse a esta app?” La pregunta útil es: “¿Qué acción exacta puede ejecutar, con qué datos, bajo qué regla de aprobación y cómo recuperamos el estado si se equivoca?”
Esta checklist sirve para workflows de automatización en los que un agente de IA usa herramientas, APIs, documentos, acciones de navegador o plataformas de workflow. No sustituye una revisión de seguridad, pero da un patrón práctico de permisos antes de permitir que el agente actúe.
Respuesta rápida
Empieza con el flujo útil más estrecho y escribe cada llamada a herramienta que el agente necesita. Da primero acceso de lectura. Permite redactar antes de enviar. Permite crear antes de actualizar. Trata exportar, borrar, reembolsar, pagar, usar lenguaje legal, notificar a clientes y cambiar permisos como acciones de alto riesgo. Cada acción de alto riesgo debe pausar para una persona responsable, conservar entrada y salida, escribir un log de auditoría y tener una ruta de recuperación.
Si no puedes explicar quién posee el permiso, por qué hace falta, qué no puede hacer el agente y cómo se revoca, el permiso todavía no está listo.
El permiso es diseño de workflow
La documentación de OpenAI Agents SDK presenta los agentes como sistemas con modelos, herramientas, instrucciones, handoffs, guardrails y estado. Por eso el permiso no es solo una pantalla de OAuth. Es parte de la arquitectura del workflow.
Desde el lado del riesgo ocurre lo mismo. La guía OWASP Top 10 for Agentic Applications se centra en sistemas que planifican, actúan, usan herramientas y toman decisiones con más autonomía que un chatbot normal. Cuanto más puede hacer un agente, más explícitos deben ser sus permisos.
En la práctica, el diseño tiene cuatro capas.
| Capa | Pregunta | Ejemplo |
|---|---|---|
| Datos | ¿Qué puede ver? | Perfil de cliente, estado de factura, notas contractuales |
| Acción | ¿Qué puede hacer? | Buscar, redactar, actualizar, enviar, exportar, borrar |
| Aprobación | ¿Cuándo debe detenerse? | Antes de enviar a un cliente o cambiar datos de dinero o contrato |
| Recuperación | ¿Qué pasa si falla? | Revocar token, restaurar registro, avisar al responsable, revisar logs |
No omitas la capa de recuperación. Es lo que separa una automatización controlada de un fallo difícil de explicar.
Crea primero el inventario de permisos
Antes de conectar el agente, crea un inventario de permisos. Debe ser aburrido y concreto. Si una fila suena vaga, el agente no está listo para producción.
| Paso del workflow | Herramienta | Datos tocados | Acción del agente | Permiso requerido | Identidad | Responsable |
|---|---|---|---|---|---|---|
| Leer solicitud | Bandeja compartida | Mensaje, remitente, hilo | Leer y clasificar | Lectura de inbox | Cuenta de servicio | Líder de soporte |
| Crear nota CRM | CRM | Contacto, empresa, nota | Crear nota | Leer contacto, crear nota | Usuario bot | Operaciones |
| Redactar respuesta | Help desk | Contexto del ticket, políticas | Solo borrador | Leer ticket, guardar borrador | Usuario bot | Líder de soporte |
| Enviar respuesta | Help desk | Email del cliente | Enviar mensaje | Enviar tras aprobación | Acción aprobada por humano | Líder de soporte |
| Actualizar estado | Tablero de proyecto | Estado, responsable | Mover estado | Actualizar estado | Usuario bot | Operaciones |
Este inventario evita el problema de conectar apps enteras. El agente no necesita una app completa. Necesita un conjunto pequeño de acciones dentro de un workflow.
Usa una matriz de autoridad por acción
El modelo más útil es por tipo de acción. Separa lo permitido por defecto de lo que requiere aprobación.
| Tipo de acción | Postura inicial | Aprobación | Log | Recuperación |
|---|---|---|---|---|
| Buscar o leer | Permitir si está acotado | Normalmente no | Sí para datos sensibles | Revocar acceso |
| Resumir | Permitir | No | Guardar IDs de fuentes | Regenerar |
| Redactar | Permitir | No para borradores internos | Guardar prompt y fuentes | Descartar borrador |
| Crear registro interno | Condicional | A veces | Guardar estado creado | Archivar o borrar |
| Actualizar registro externo | Restringir | Sí para cliente, finanzas, legal o compliance | Guardar antes/después | Restaurar valores |
| Enviar mensaje | Restringir | Sí salvo plantillas de bajo riesgo | Guardar destinatario, contenido y aprobador | Corrección y nota de incidente |
| Exportar datos | Restringir | Sí | Guardar alcance y destino | Revocar enlace, rotar token, avisar responsable |
| Borrar, reembolsar, aprobar, firmar | Bloquear por defecto | Siempre | Auditoría completa | Plan manual |
La regla es simple: cuanto más afecta una acción a alguien o algo fuera del workflow, menos autónoma debe ser.
La aprobación debe llegar antes de la acción costosa
Aprobar solo al final suele ser tarde. Una buena puerta de aprobación detiene el flujo antes de una acción costosa, cuando el contexto todavía está visible.
Usa aprobación cuando:
- el agente enviará un mensaje fuera de la organización;
- cambiará datos de dinero, contrato, cuenta, legal o estado de cliente;
- usará un permiso por primera vez;
- el resultado depende de fuentes inciertas;
- el workflow contiene queja, seguridad, reembolso, texto legal, cancelación o cambio de cuenta;
- el agente intenta ampliar su acceso o cambiar otra automatización.
El patrón human-in-the-loop de OpenAI Agents SDK es útil porque el workflow puede pausar, pedir aprobación y continuar con una decisión explícita.
Limita OAuth y permisos de API
Los scopes de OAuth y permisos de API son donde muchos proyectos se vuelven demasiado amplios. “Conectar Google Workspace” o “conectar Microsoft Graph” no es un modelo de permisos. Es un modelo de riesgo sin bordes.
Revisa esto antes de aprobar:
| Acceso pedido | Alternativa más estrecha | Mantener solo si |
|---|---|---|
| Leer todos los archivos | Leer carpeta seleccionada o archivo elegido | La búsqueda amplia es necesaria y hay logs de fuentes |
| Enviar email como usuario | Crear solo borrador | Hay plantillas aprobadas y puerta de envío |
| Leer/escribir todo el CRM | Leer contactos y crear notas | El agente realmente necesita actualizar campos |
| Exportar reportes | Generar resumen dentro de la herramienta | El export externo es necesario y el destino queda registrado |
| Permisos admin | Separar como acción humana | Casi nunca hay un caso seguro para el agente |
La documentación de Google OAuth scopes y el resumen de Microsoft Graph permissions ayudan a ver cuánto puede abarcar un permiso amplio. Antes de aceptarlo, exige una alternativa más estrecha.
Registra logs que una persona pueda usar
Un log de auditoría no es una pila de tokens crudos. Debe permitir reconstruir qué ocurrió.
Para cada llamada importante a herramienta, guarda:
run_idy nombre del workflow;- solicitud del usuario o fuente del trigger;
- versión de instrucciones del agente;
- herramienta y tipo de acción;
- registros de entrada o IDs de fuente;
- destino de salida;
- valores antes y después si hubo actualización;
- solicitud de aprobación, aprobador y hora;
- confianza o razón cuando exista;
- error, reintento, fallback o escalación;
- estado de recuperación.
Si un cliente se queja, una factura está mal o un registro cambia sin esperarlo, el log debe responder: “¿Qué hizo el agente y por qué estaba permitido?”
Amplía permisos por etapas
No empieces con autonomía. Empieza observando.
| Etapa | Acciones permitidas | Acciones bloqueadas | Evidencia para ampliar |
|---|---|---|---|
| 1. Observar | Leer, clasificar, resumir | Redactar, enviar, actualizar, exportar, borrar | Clasificación correcta en ejecuciones revisadas |
| 2. Redactar | Borradores internos y notas | Envío externo, dinero, borrado | Baja tasa de edición y fuentes claras |
| 3. Acción aprobada | Ejecutar tras aprobación humana | Autoaprobación, cambios de permisos | Aprobaciones predecibles y logs completos |
| 4. Autonomía acotada | Acciones repetibles de bajo riesgo | Campos críticos, exportes, acciones destructivas | Fallos estables, recuperación probada |
| 5. Ampliar alcance | Añadir una acción nueva cada vez | Permisos admin amplios | Responsable y fecha de revisión definidos |
Este enfoque encaja con el NIST AI Risk Management Framework: mapear riesgos, medir comportamiento, gestionar controles y mantener visible la gobernanza.
Define revocación y recuperación antes del lanzamiento
Un plan de permisos está incompleto si no sabes apagarlo.
La checklist de emergencia debe responder:
- ¿Qué token, cuenta bot, API key, workflow o integración se desactiva primero?
- ¿Quién puede pausar el agente si el responsable no está disponible?
- ¿Qué logs deben preservarse antes de limpiar?
- ¿Qué sistemas externos necesitan corrección?
- ¿Qué registros se restauran con logs antes/después?
- ¿Qué permiso se elimina de forma permanente?
- ¿Qué evidencia hace falta para reactivarlo?
Diseñar recuperación no es pesimismo. Es lo que hace aceptable la automatización en operaciones reales.
Ejemplo: agente de seguimiento de clientes
Imagina un agente que lee solicitudes entrantes, revisa contexto de CRM, redacta una respuesta, crea una tarea de seguimiento y más adelante puede enviar el mensaje.
No le des acceso completo al CRM y al inbox desde el primer día.
Empieza con:
- lectura de una cola específica del inbox;
- lectura de CRM solo para contactos coincidentes;
- creación de notas internas;
- creación de borradores de respuesta;
- sin permiso de envío;
- sin cambios en valor de oportunidad, estado, reembolso, contrato o responsable;
- logs de cada fuente y borrador generado.
Cuando las ejecuciones revisadas muestren baja tasa de edición, añade una puerta de envío. El agente prepara el mensaje y una persona lo aprueba. Solo después considera envío autónomo limitado para plantillas de bajo riesgo, y solo si existen rutas de baja, queja, escalación y corrección.
Preguntas frecuentes
¿Debe un agente usar la cuenta de una persona?
Normalmente no para workflows duraderos. Una cuenta bot o de servicio con nombre es más fácil de monitorizar, revocar y limitar. Si hace falta delegación de usuario, debe ser visible y acotada.
¿El acceso de solo lectura siempre es seguro?
No. También puede exponer datos de clientes, financieros, legales o estratégicos. Es más seguro que escribir, pero sigue necesitando alcance, logs y reglas de manejo de datos.
¿Cuándo puede enviar mensajes sin aprobación?
Solo cuando el mensaje es de bajo riesgo, basado en plantilla, reversible, esperado por el destinatario y monitorizado. Quejas, reembolsos, lenguaje legal, cambios de cuenta, seguridad y precios deben mantener aprobación humana.
¿Cuál es el error más común?
Conceder permisos de app completa porque es más rápido que diseñar permisos por acción. Ahorra configuración y aumenta el riesgo operativo.
Siguiente paso
Si los límites del workflow todavía no están claros, empieza con el scorecard de auditoría de workflows de IA. Si ya eliges plataformas y rutas de modelo, combina esta checklist con la comparación de stacks de automatización antes del lanzamiento.
Fuentes consultadas
Principales páginas públicas usadas para comprobar detalles de producto, contexto de precios y afirmaciones comparativas.
