Toda tercerización llega al mismo punto incómodo: el proveedor necesita entrar a los sistemas del cliente para poder trabajar. El CRM, la mesa de ayuda, el ERP, la plataforma de facturación, a veces el correo. Esa conversación suele resolverse mal en cualquiera de los dos extremos. O se estira semanas y el equipo llega al día uno sin poder abrir nada, o se despacha en diez minutos con un usuario compartido de perfil amplio que después nadie vuelve a mirar.
El acceso no es un trámite de arranque. Define al mismo tiempo el riesgo que asume el cliente y la velocidad a la que el proveedor puede producir. Conviene diseñarlo antes de firmar, no el viernes anterior al go-live.
El error de fondo: conceder por rol, no por tarea
Los permisos casi siempre se entregan copiando un perfil que ya existe. "Son el equipo de soporte, denles el perfil de soporte." Pero ese perfil se diseñó para empleados internos con años de contexto, y suele traer adentro cosas que la operación tercerizada no necesita: exportar la base completa, editar datos maestros, anular transacciones, ver información de otras áreas. Se entrega porque estaba a la mano, no porque corresponda.
La alternativa no es desconfiar del proveedor. Es partir del proceso: listar las tareas que el equipo va a ejecutar y derivar de cada una el permiso mínimo que exige. Ese ejercicio ya está medio hecho si el proceso se documentó antes de tercerizar, como planteamos en qué documentar antes de tercerizar un proceso. Si nadie sabe qué hace exactamente el equipo, tampoco se puede decidir qué necesita ver.
Un permiso que nadie usó en tres meses no es un permiso de reserva. Es una superficie de riesgo abierta sin contrapartida.
Qué conviene entregar
- Usuarios nominales, uno por persona. Cuestan más licencias y ahorran todos los problemas que trae el usuario compartido: sin nominalidad no hay auditoría posible, no se puede atribuir una acción ni cerrar un acceso cuando alguien sale.
- Permisos por tarea, revisables. Empezar corto y ampliar cuando el proceso lo pida deja rastro de por qué existe cada permiso. Empezar amplio y recortar nunca ocurre.
- Ambientes de prueba para el entrenamiento. Formar agentes sobre datos reales es la forma más silenciosa de exponer información. Un ambiente con datos ficticios resuelve la curva de aprendizaje sin costo de riesgo.
- Segundo factor y gestor de contraseñas. Definido por escrito quién lo administra, con cargo claro en el modelo de licencias que discutimos en herramientas y licencias en BPO.
- Vistas en lugar de bases. Cuando la tarea es consultar, una vista acotada o una integración de solo lectura suele bastar. Rara vez hace falta entregar la tabla completa.
Qué conviene pensar dos veces
- Exportación masiva. Es el permiso que convierte un incidente pequeño en una fuga grande. Si el proceso exige exportar, que sea con un flujo definido, un destino conocido y registro de quién exportó qué.
- Perfiles de administrador. Administrar la herramienta y operarla son dos trabajos distintos. Mezclarlos deja al proveedor cambiando las reglas que después lo evalúan.
- Correo corporativo del cliente. A veces es inevitable por experiencia de marca, pero abre un canal que el cliente no ve. Si se concede, debe ir con reglas de retención y revisión acordadas.
- Accesos de emergencia permanentes. El usuario de contingencia que se creó "por si acaso" durante la transición y quedó activo dos años es un hallazgo clásico de cualquier auditoría.
El ciclo de vida importa más que la concesión inicial
Casi toda la atención se va en el alta, y casi todo el riesgo está en lo demás. Cuatro momentos que deben tener dueño y plazo por escrito:
- Alta. Quién la solicita, quién la aprueba del lado del cliente, en cuánto tiempo. Sin plazo comprometido, la rampa del equipo se retrasa y el proveedor factura gente que no puede trabajar.
- Cambio. Un agente que asciende a supervisor acumula permisos si nadie retira los anteriores. La promoción interna es la principal fuente de perfiles inflados.
- Baja. El mismo día de la salida, no en el corte mensual. Este es el punto donde más operaciones fallan, y el que más fácil se arregla: basta con que la novedad de personal dispare la revocación de forma automática.
- Revisión periódica. Una recertificación trimestral en la que el cliente confirma usuario por usuario que sigue siendo necesario. Toma poco tiempo y es la única forma de que el inventario no se degrade solo.
Datos personales: el marco, sin improvisar
Cuando la operación toca datos personales, la discusión de accesos se vuelve también una discusión de responsabilidades. Quién decide sobre el dato y quién solo lo trata por cuenta de otro cambia las obligaciones de cada parte, y eso se define en el contrato, no en la práctica. Tratamos ese punto en encargado y responsable del tratamiento de datos. Lo que importa aquí es que el diseño técnico refleje lo que dice el contrato: si el proveedor solo puede tratar datos para una finalidad, el permiso no debería permitirle hacer más que eso. Esto es un encuadre general y no constituye asesoría legal; cada operación debe revisarlo con su propio asesor.
Trazabilidad: registrar es barato, reconstruir no
La pregunta que hay que poder responder no es "¿confiamos en el proveedor?" sino "¿podemos reconstruir qué pasó?". Eso exige registro de acceso y de acciones sensibles, retención acordada de esos registros, y alguien que los mire con alguna frecuencia en lugar de solo cuando hay un incidente. Un tablero de accesos activos, revisado en la misma reunión mensual de la operación, evita la mayoría de las sorpresas sin agregar burocracia.
Vale la pena separar dos cosas que se confunden: las certificaciones dicen que existe un sistema de gestión, no que el permiso de ayer estuviera bien puesto. Es el matiz que discutimos en certificaciones de un proveedor de BPO. El control real es el inventario vivo, no el certificado colgado en la pared.
Qué preguntar al proveedor
- ¿Cómo solicita, aprueba y documenta un acceso nuevo, y en cuánto tiempo?
- ¿Qué pasa con los accesos el día que un agente sale del equipo?
- ¿Usa usuarios nominales siempre, o comparte credenciales en algún caso?
- ¿Cómo entrena a agentes nuevos sin exponer datos reales?
- ¿Qué registro guarda de acciones sensibles y por cuánto tiempo?
- ¿Quién del lado del proveedor responde por el inventario de accesos y con qué frecuencia lo revisa con el cliente?
Cómo lo hace smartBPO
Levantamos la matriz de accesos durante el diseño de la transición, no en la semana del arranque, y la construimos desde las tareas del proceso: cada permiso queda asociado a una actividad concreta y a un aprobador del lado del cliente. Trabajamos con usuarios nominales, entrenamos en ambientes con datos ficticios cuando el sistema lo permite, y la novedad de salida de una persona dispara la solicitud de revocación el mismo día. Mantenemos un inventario de accesos activos y lo llevamos a la reunión de gobierno para que el cliente recertifique lo que sigue siendo necesario. El calendario de todo esto va dentro del plan de los primeros 90 días, porque un acceso pendiente es la causa más común de una rampa que se atrasa. No prometemos ausencia de incidentes: proponemos que el permiso mínimo quede escrito, que el rastro exista y que ambas partes puedan revisarlo cuando haga falta.