Qué abarca el control de acceso de los agentes de soporte
La mayoría de los equipos piensan en el control de acceso como "agente o administrador". En la práctica hay cuatro capas, y un hueco en cualquiera de ellas anula las otras tres.
| Capa | La pregunta que responde | Controles típicos |
|---|---|---|
| Identidad | ¿Es de verdad tu agente? | SSO, 2FA obligatorio, restricciones de IP, tiempos de espera de sesión |
| Visibilidad | ¿Qué tickets y datos de clientes puede ver? | Alcance de tickets, acceso por bandeja o departamento, enmascaramiento de datos |
| Capacidad | ¿Qué puede hacer con ellos? | Roles y permisos: responder, eliminar, exportar, reembolsar, cambiar ajustes |
| Trazabilidad | ¿Puedes demostrar lo que pasó? | Registro de auditoría, registro de accesos, historial de aprobaciones |
Soy Rama y construyo las integraciones de helpdesk de eesel, así que paso buena parte de la semana al otro lado de estas pantallas de permisos. Cada vez que eesel se conecta a un helpdesk tiene que pedir scopes y luego vivir dentro del rol de un agente real. En Zendesk, por ejemplo, las respuestas de eesel se publican como el usuario de Zendesk que aprobó la conexión, de modo que el rol de Zendesk de esa persona es el techo duro de lo que puede hacer la IA. Esa es la lente que uso todo el rato: el control de acceso trata tanto de los puestos que la gente olvida como de los que configura el primer día.
Si además separas clientes o marcas, la capa de visibilidad se solapa con el soporte al cliente multimarca y las bases de conocimiento por cliente, que no repetiré aquí.
Por qué el alcance de tickets no es lo mismo que el control de acceso
El alcance de tickets es el ajuste al que se refiere la mayoría cuando dice "los agentes solo ven sus propios tickets". En Zendesk, las opciones son todos los tickets, tickets de los grupos del agente, tickets de su organización o solo asignados. Freshdesk ofrece todos, por grupo o asignados desde Growth.
Este es el tipo de equipo que lo necesita, en un hilo de r/Zendesk sobre separar divisiones:
"the agents would belong to different business divisions under the same overall company. They'd work on tickets that employees submit with sensitive data so this is why we want the agents in one division not to have access to see another agent group's tickets and so on"
El alcance cubre la puerta principal. La documentación de los proveedores recoge al menos tres puertas laterales:
- CC. Zendesk dice que poner a un agente en CC, incluidos los light agents, le envía por correo cada actualización pública y privada, sin importar su acceso al ticket (roles estándar de Zendesk). Un solo CC en un ticket sensible y el ajuste de alcance deja de importar para ese hilo.
- Administradores. Los administradores lo ven todo. Zoho Desk lo dice claramente: incluso con el uso compartido en Privado, "support admins can view all the tickets within a department" (reglas de uso compartido de datos de Zoho). Así que la lista de administradores forma parte de tu política de visibilidad, lo hayas planeado o no.
- Borradores con IA. El auto assist de Zendesk "may generate text replies based on that content for agents and end users who don't belong to the related user segment". Es decir, el contenido restringido del centro de ayuda puede llegar a un agente que no podría abrir el artículo. Por defecto, todos los grupos tienen auto assist (configuración de auto assist).
Dos helpdesks son más directos sobre los límites. Help Scout acota por bandeja y su documentación dice "There is no method to restrict individual conversations" (roles de Help Scout). Gorgias da a todos los roles, incluido Observer, el permiso "View tickets" y una vista por defecto de todos los tickets abiertos, y no documenta ningún bloqueo estricto para abrir un ticket (permisos de usuario de Gorgias). Ninguno está mal para un equipo de una sola marca. Solo significan que la separación tiene que venir de bandejas o cuentas separadas, no de un rol.
Qué te deja controlar cada helpdesk
Esta es la comparación que me habría gustado tener la primera vez que lo mapeé. Los precios son por agente al mes según la página de precios de cada proveedor en octubre de 2026, con facturación anual donde la página muestra ambas.
| Zendesk | Freshdesk | Gorgias | Help Scout | Front | Zoho Desk | HubSpot Service Hub | |
|---|---|---|---|---|---|---|---|
| Roles personalizados | Solo Enterprise (presupuesto) | Pro (55 $) y superiores | Ninguno, 5 roles fijos | Personalizados por usuario en Plus (45 $) y Pro | Enterprise (105 $) | 5 en Standard (14 $), 25 en Professional, 50 en Enterprise | Interruptores por usuario; acceso solo de equipo en Professional+ |
| Alcance de tickets | Grupos, organización, asignados | Grupo, asignados; grupos de solo lectura en Enterprise | Solo vistas, sin bloqueo estricto | Por bandeja | Por bandeja compartida | Por departamento; reglas de uso compartido en Enterprise | Todos, equipo, propios |
| Puesto barato o limitado | Light agents: de 50 a 5.000 incluidos desde Growth | Colaboradores hasta 5.000; pases de día de 2 a 12 $ | No se cobra por agente; rol Observer | Light Users: 5 gratis en Plus, 15 en Pro | Cuentas de invitado | Light agents 6 $/mes | Puestos de solo lectura, gratis e ilimitados |
| SSO | SAML en todos los planes | SAML desde Growth | OIDC personalizado desde Advanced | SAML en Pro | SAML desde Professional | Active Directory | SAML desde Professional |
| Restricción de IP | Todos los planes | Enterprise | No documentado | No documentado | Enterprise | Todas las ediciones | No documentado |
| Registro de auditoría | Desde Enterprise, conservado indefinidamente | Enterprise | 12 meses (Pro, Advanced) | No documentado | Todos los planes, 365 días | Enterprise | Vistas de 30 días, completo en Enterprise |
| Quién configura la IA | Administradores de soporte por defecto | Administradores | Lead y Admin | Ajustes de Beacon | Preajuste de administrador del workspace | No documentado | Permiso de editor de agente de cliente |
Fuentes: Zendesk, Freshdesk, Gorgias, Help Scout, Front, Zoho Desk, HubSpot.
Un par de celdas merecen una frase. Zendesk y Zoho Desk incluyen restricciones de IP en todos los planes, y en Zendesk los agentes y administradores no pueden saltárselas (restricciones de IP de Zendesk). El registro de auditoría de Front funciona en todos los planes con 365 días de historial y también registra los cambios hechos por Admin Copilot, la API y las apps (registro de auditoría de Front), algo inusualmente generoso. Y Zendesk en Enterprise elimina por completo el rol de agente estándar, así que el acceso de cada agente sale de un rol personalizado, con un tope de 197 por cuenta.
El conjunto de permisos personalizado de Front es una buena imagen de lo que es el "mínimo privilegio" a nivel de botón. El propio ejemplo de Front: dejar que los nuevos redacten borradores en bandejas compartidas con "Send messages" desactivado hasta que estén formados.
Para el detalle por proveedor, mi guía de roles de Zendesk recorre la lista completa de permisos, y la versión de Freshdesk cubre los alcances. Gorgias también tiene su propio recorrido por los roles.
Cuánto cuesta el mínimo privilegio
El patrón de la tabla es que los roles de grano fino son una función de los planes altos. Aquí tienes dónde se desbloquean por primera vez los roles personalizados en cada helpdesk.
Un consultor de Zendesk en el mismo hilo de r/Zendesk resumió lo que esto significa en los planes más bajos:
"Groups (even normal) can do this. As long as agents access is set to "Only tickets in their group". Admins will be able to always see all tickets but agents get locked down as long as Access is set that way. If in Enterprise custom roles is how you handle this."
Front lleva años con esta queja. Una reseña de Capterra de 2022 (el precio que cita es de entonces, no de hoy) lo expresó así:
"basic features like a user and team management are exclusive to the highest tier. For this even managing just a few users and their permission and settings is a real pain as long as you're not willing to upgread to the highest tier"
Verified Reviewer, CPO, Food & Beverages, Capterra
Los controles de privacidad son los más caros. El enmascaramiento de datos de Zendesk, que oculta a un rol los nombres, correos y teléfonos de los usuarios finales, está en el complemento Advanced Data Privacy and Protection, que solo se vende a planes Enterprise a un precio no publicado (Zendesk ADPP). El mismo complemento incluye el registro de accesos, que anota quién vio qué tickets durante 90 días.
Mi opinión sincera: si los permisos por rol son un requisito imprescindible y no tienes presupuesto para Zendesk Enterprise, Freshdesk Pro y Zoho Desk Professional son las versiones completas más baratas de este conjunto. Si ya usas Zendesk en Suite Professional (115 $), los grupos con alcance solo asignados, una lista corta de administradores y restricciones de IP te llevan buena parte del camino. Revisa mis desgloses de precios de Zendesk y precios de Freshdesk antes de subir de plan solo por los roles.
Los roles que configuraría para un equipo de soporte típico
La mayoría de los equipos necesitan cinco formas de acceso, no quince. Este es el esquema del que partiría.
| Rol | Alcance de tickets | Puede | No puede |
|---|---|---|---|
| Agente de primera línea | Sus grupos | Responder, etiquetar, asignar dentro del grupo, usar macros | Eliminar tickets, exportar datos, editar usuarios finales, gestionar reglas de negocio |
| Líder de equipo | Todos los tickets | Todo lo que hace un agente de primera línea, más informes, vistas y macros del equipo | Facturación, gestión de usuarios, tokens de API |
| Contratista o agente externalizado | Solo asignados, o un grupo | Responder en la cola para la que está contratado | Exportar, acciones masivas, ver detalles completos de pago o identidad |
| Puesto ligero para otros equipos | Sus grupos | Leer, dejar notas internas | Responder a clientes, cambiar campos del ticket |
| Administrador | Todos | Ajustes, usuarios, integraciones | Nada restringido, por eso debería haber dos |
La fila del contratista es en la que dedicaría más tiempo. Después de que Coinbase revelara en mayo de 2025 que se había sobornado a personal de soporte en el extranjero para sacar datos de clientes, el hilo de Hacker News volvía una y otra vez al mismo principio:
"That's not how front line support agent access should work. You get access based on active cases you are working on, not the keys to the kingdom because you might need to support a member at some future point in time."
Otro comentarista que construyó un panel de administración para una empresa de pagos PCI Level 1 describió los controles que añadieron al contratar fuera de EE. UU.: "logging, monitoring and also rate-limiting (ask for manager to approve if more than 5 full details requests, etc.)" (vasusen, Hacker News). Esa última parte, la aprobación a partir de un umbral, es el mismo patrón al que volveré con la IA. Si trabajas con un BPO, mis guías sobre externalizar el servicio al cliente y la transferencia de conocimiento al soporte offshore cubren el resto de la configuración.
Para la fila del puesto ligero, elige el puesto de lectura y comentario más barato que ofrezca tu helpdesk. Zendesk incluye hasta 100 light agents en Suite Professional (puestos de light agent), los colaboradores de Freshdesk no pueden responder públicamente ni editar propiedades del ticket (colaboradores de Freshdesk) y los puestos de solo lectura de HubSpot son gratis e ilimitados en planes de pago (puestos de HubSpot).
Los ingenieros y el personal de finanzas que solo necesitan leer un hilo y dejar una nota no necesitan una licencia de agente completa, como expliqué en escalado de soporte entre equipos.
Bajas: dónde queda el acceso
El control de acceso suele fallar en la salida, no en la entrada. Todos los helpdesks te dejan eliminar a un usuario. Lo que cambia es qué pasa con sus tickets, sus automatizaciones y tu factura.
| Helpdesk | Opciones de baja | Qué pasa con los tickets abiertos | Facturación del puesto |
|---|---|---|---|
| Zendesk | Degradar a usuario final y luego suspender | Vuelven al grupo | Se sigue cobrando hasta que cambies la suscripción |
| Freshdesk | Desactivar o eliminar | Van a la cola sin asignar | El puesto se libera al desactivar |
| Gorgias | Solo eliminar | Sin asignar; se eliminan sus estadísticas | No se cobra por agente |
| Help Scout | Solo eliminar | Van a Unassigned; reasigna con un Workflow antes de eliminar | No consta |
| Front | Bloquear o eliminar | Las conversaciones de bandejas compartidas quedan sin asignar | La licencia sigue hasta el próximo periodo del contrato |
| Zoho Desk | Desactivar o eliminar | Eliges quién los asume | La licencia no se cancela |
| HubSpot | Desactivar y luego quitar | Siguen asignados hasta que se quite | Libera primero el puesto |
Fuentes: Zendesk, Freshdesk, Gorgias, Help Scout, Front, Zoho Desk, HubSpot.
Conviene conocer tres trampas antes del último día de alguien:
- El orden importa en Help Scout. Para pasar las conversaciones de quien se va a una persona concreta, ejecutas antes un Workflow, porque "There is no way to do this after the user has been deleted" (Help Scout).
- Las integraciones se rompen con la persona. Zoho Desk dice que las integraciones configuradas por un agente desactivado dejan de funcionar hasta que un administrador las vuelve a autorizar, y Zendesk avisa de que las apps configuradas con las credenciales de quien se va pueden fallar. Ten siempre claro con qué login funcionan tus integraciones, incluida tu IA.
- Los datos se van con ellos. Degradar a un agente de Zendesk elimina sus datos de CSAT y sus macros personales, y eliminar a un usuario de Gorgias borra sus estadísticas. Exporta antes lo que necesites.
El fallo más silencioso es que nadie recuerda cómo se configuraron los permisos. Un usuario de Zendesk escribió esto en abril de 2026:
"We had some turnover in IT so no one who set up Zendesk/my account for our team are here still and I can't figure out how to add it as an option for them."
Documenta la configuración de roles y lee tu registro de auditoría una vez por trimestre. Zendesk conserva su registro indefinidamente en Enterprise, con autor, dirección IP y tipo de actividad de cada cambio (registro de auditoría de Zendesk). Mi guía del registro de auditoría de Zendesk tiene la versión campo por campo.
En Gorgias, el registro de auditoría guarda 12 meses de eventos. Para contrataciones de temporada con puestos temporales, mi artículo sobre la incorporación de soporte estacional cubre las reglas de cada helpdesk.
Tu agente de IA también necesita un rol
Esta es la parte que la mayoría de las revisiones de acceso se saltan. Un agente de soporte de IA lee tickets, busca en tu base de conocimiento y, en muchas configuraciones, responde, etiqueta, cierra y reembolsa. Es un miembro del equipo con las manos más rápidas del edificio, y a menudo lo configura quien tenía permisos de administrador esa tarde.
La documentación de los proveedores muestra lo desigual que es hoy:
- Zendesk: cualquier administrador de Support es por defecto administrador de cliente de los agentes de IA (acceso a agentes de IA de Zendesk). El agente de IA de cara al cliente respeta los segmentos de usuarios, pero el auto assist del lado del agente no, como vimos arriba.
- Freshdesk: crear agentes de IA requiere acceso de administrador, y el agente de IA solo aprende de artículos visibles para todos los usuarios, de modo que el contenido restringido queda totalmente fuera (fuentes de conocimiento de Freshdesk).
- Gorgias: solo los Leads y Admins gestionan el AI Agent, pero todos los roles ven sus respuestas (permisos de Gorgias).
- HubSpot: el agente de cliente necesita el permiso "Customer agent editor", y una vez creado "it can't be deleted", solo se puede pausar (agente de cliente de HubSpot).
- Front: los ajustes de IA solo vienen con el preajuste de administrador del workspace, no como un permiso aparte (grupos de compañeros de Front).
Ninguno de los siete proveedores que revisé documenta si su agente de IA respeta el alcance de tickets de un agente concreto. Así que lo más seguro es asumir que la IA ve lo que ve su conexión y que lo controlas en la conexión.
Un buen consejo llegó de un hilo de r/AI_Agents sobre dar a los agentes acceso a datos de clientes:
"You should treat an agent like you would any user: limit access via end points and only give them access to the endpoints they absolutely need. So avoid full/broad access as much as possible."
Eso encaja con lo que oigo de los compradores. Un responsable de CX de una marca DTC de suplementos en Gorgias y Shopify, con unos 7,000 tickets al mes, lo dijo claro en una llamada de ventas con eesel:
"I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."
Por eso pienso en el acceso de un agente de IA como tres diales separados y luego un nivel de permiso para cada acción.
- Conocimiento. Conecta solo las fuentes que necesita. Si los agentes de una división no pueden ver los tickets de otra, la IA que atiende a esa división tampoco debería aprender de ellos.
- Acciones. Enumera cada acción y fija cada una: automática, requiere aprobación o desactivada. Consultar un pedido es de bajo riesgo. Enviar una respuesta o emitir un reembolso no lo es, al menos hasta que hayas visto que lo hace bien.
- Red. Si la IA llama a tus propias APIs, permite solo los dominios que necesita y mantén las credenciales fuera del alcance del modelo.
Así está construido el compañero de IA para helpdesk de eesel. Cada acción se fija por agente en Auto, Requiere aprobación o Desactivado, y las aprobaciones nunca se ejecutan solas tras un tiempo de espera. Solo los Owners y Editors del workspace pueden aprobar, y un Viewer puede leer el trabajo del agente pero el agente no ejecutará acciones de escritura en su nombre (roles de cuenta de eesel). Las llamadas salientes solo llegan a los dominios que añades en Network Access, y el agente "only ever sees the name of the header, never its value", así que las claves de API quedan fuera del modelo.
Los mismos permisos se aplican desde la terminal. La CLI de eesel maneja el mismo agente que el panel, y eesel integrations zendesk actions imprime cada acción de Zendesk con su ajuste de aprobación, de modo que puedes auditar los permisos de un agente con un solo comando o pedirle a un agente de programación como Claude Code que lo haga. Las escrituras desde la CLI siguen las mismas reglas, y las escrituras de un Viewer siempre quedan retenidas para un Editor. --dry-run muestra la llamada exacta que haría una escritura antes de enviar nada.
La documentación de eesel recomienda empezar supervisado: respuestas y todo lo irreversible en Requiere aprobación, reembolsos y cancelaciones tras aprobación para siempre. La mayoría de los equipos empiezan con notas internas y luego ceden más a medida que el agente demuestra su valía, el mismo camino que sigue un nuevo empleado. Si quieres el lado humano de ese camino, mi guía para incorporar a un agente de soporte de IA lo recorre, y la escalación con IA cubre las reglas de traspaso.
Una salvedad honesta del lado de eesel: la redacción de PII se aplica a los tickets pasados antes de indexarlos, pero cuando el agente obtiene un ticket de Zendesk en vivo para redactar una respuesta, el contenido sin procesar del ticket llega al modelo. Si enmascarar números de tarjeta en ese punto es imprescindible, combina eesel con la redacción propia de tu helpdesk, como la redacción de tickets de Zendesk.
Una lista de revisión trimestral del acceso
El acceso se desvía. La gente cambia de equipo, los contratistas se van y alguien recibe permisos de administrador "solo para esta tarde". Yo haría esto cada trimestre:
- Cuenta tus administradores. Dos bastan para la mayoría de los equipos. Cada administrador extra ve todos los tickets.
- Compara los puestos con la plantilla. Quien se fue y aún tiene un puesto es a la vez un hueco de seguridad y una partida de gasto, sobre todo en Zendesk, Front y Zoho Desk, donde el puesto sigue facturándose.
- Revisa el alcance de los puestos de contratistas y externalizados. Solo asignados o un grupo, sin exportación.
- Lee el registro de auditoría en busca de cambios de rol, exportaciones e inicios de sesión desde direcciones IP nuevas.
- Revisa tus agentes de IA como cualquier otro puesto. Qué fuentes, qué acciones en Auto, con el login de quién funciona la conexión. Hazle las mismas preguntas a tu configuración de IA para solicitudes de acceso a sistemas, si tienes una.
Si además estás reforzando el cumplimiento, mi lista sobre SOC 2 y RGPD para chatbots de soporte y el resumen de seguridad de Zendesk son buenas siguientes lecturas.
Prueba eesel como compañero de IA acotado
Si tu helpdesk es Zendesk, Freshdesk, Gorgias, Help Scout o Front y el puesto de la IA es del que menos seguro estás, el compañero de IA para helpdesk de eesel está pensado para eso. Se une a tu cola actual mediante la integración con Zendesk (o Freshdesk y Gorgias), lee solo las fuentes que conectes y ejecuta solo las acciones que actives. Conectar una herramienta no cambia nada por sí solo: no se activa ninguna automatización y no se envía ninguna respuesta hasta que añades un disparador.
Cada ticket que toca aparece en Activity con lo que buscó, lo que hizo, quién lo aprobó y por qué, y antes de salir en vivo la habilidad de simulación reproduce tus tickets pasados reales para que veas sus respuestas primero. Los precios incluyen agentes y puestos ilimitados en todos los planes, empezando gratis con 100 créditos y luego desde $299 al mes por 500 créditos, así que añadir revisores para vigilar a la IA no cuesta una licencia por cabeza. Lo que aún no es: certificado SOC 2 Type II (está en curso, según la página de seguridad), y el SSO con 2FA obligatorio es un complemento desde $199 al mes. Si quieres una IA que empiece con notas internas y vaya ganando terreno, prueba eesel gratis.