Compartir una cuenta de suscripción puede ahorrar licencias, pero el coste real suele ser mayor. El artículo explica cuatro problemas: incumplimiento de términos, circulación de credenciales, registros sin atribución y accesos que persisten tras una salida, además de alternativas compatibles.
Añadir otro puesto de usuario a una herramienta SaaS puede suponer un gasto considerable. A medida que crece el equipo, ese coste se vuelve mucho más visible.
Por eso, compartir un mismo juego de credenciales puede parecer una opción natural, sobre todo cuando alguien solo necesita consultar un informe de vez en cuando o comprobar datos para un cliente. Sin embargo, el coste real suele subestimarse y se reparte entre varios frentes: términos de servicio, credenciales, registros de actividad y cambios de personal. Cada uno tiene sus propios problemas.
Los términos son claros: las cuentas no se comparten
La mayoría de los productos SaaS utilizan licencias por puesto. Salvo los planes empresariales o de equipo que admiten explícitamente varios usuarios, los demás suelen estar limitados a una sola persona. Los términos de servicio normalmente prohíben que varias personas compartan el mismo inicio de sesión, y la plataforma puede suspender o retirar el acceso si lo detecta. Hay un detalle que se pasa por alto con facilidad: este tipo de cancelación suele hacerse sin reembolso, por lo que el dinero ya pagado puede perderse.
También existe un coste menos visible. El objetivo de compartir es ahorrar dinero, pero la plataforma sigue cobrando en función de cuántas personas necesitan acceso. En la práctica, el ahorro sustituye un coste de licencia por un riesgo de incumplimiento que permanece oculto mientras no ocurra ningún problema.
Si muchas personas conocen la contraseña, no se sabe quién actuó
Compartir implica que la contraseña circule entre varias personas, normalmente por chats, notas u otros medios donde un mensaje puede quedar guardado de forma permanente.
El problema no es solo la contraseña, sino dos consecuencias. La primera es que aumenta la superficie de exposición: cuantos más participantes haya, mayor será la posibilidad de que alguien reutilice la misma contraseña en otro servicio o de que uno de sus dispositivos sea comprometido, creando una vía de acceso a la cuenta. La segunda es la dificultad para atribuir responsabilidades. Si la cuenta se usa para exportar datos, cambiar ajustes o enviar algo indebido, después solo puede verse lo que hizo la cuenta, no quién realizó la acción. Para equipos que deben explicar a sus clientes por dónde han pasado los datos, este suele ser uno de los puntos más difíciles.
Los registros guardan la cuenta, no la persona
Los sistemas administrativos de SaaS suelen almacenar la actividad por cuenta: quién exportó un informe, qué ajustes se cambiaron y qué datos se borraron. En el registro suele aparecer un único nombre de cuenta.
Cuando varias personas comparten esa cuenta, se pierde esa trazabilidad. El equipo no puede saber quién hizo el cambio y la detección de anomalías de la plataforma se enfrenta al mismo problema. Puede ver que una misma cuenta inicia sesión desde varias ciudades, dispositivos y salidas de red, con sesiones simultáneas, y marcar la actividad. Las respuestas habituales incluyen cerrar las sesiones a la fuerza, congelar temporalmente la cuenta o pedir una nueva verificación. Si la herramienta es esencial para el trabajo diario, quedarse sin acceso en horario laboral puede costar mucho más que unas cuantas licencias adicionales.
Cambiar de proxy o uniformar la huella del navegador solo puede reducir la probabilidad de detección; no convierte el uso compartido de credenciales en una práctica compatible con los términos. Además, si todos los accesos quedan ligados a un mismo entorno, un problema con ese entorno —por ejemplo, una IP marcada o un entorno considerado anómalo— puede interrumpir el acceso de todos al mismo tiempo y ampliar el impacto del fallo.
La persona se va, pero el acceso permanece
Cuando un empleado deja la empresa o termina una colaboración externa, a menudo nadie asume claramente la revocación del acceso a una cuenta compartida. La razón es sencilla: como la cuenta es de todos, no existe un paso de entrega con un responsable definido.
Quedan varios riesgos. La persona que se fue puede seguir conociendo la contraseña, y nadie sabe quién más la guardó. Las cookies de sesión emitidas anteriormente pueden seguir activas. Si esa persona configuró scripts de automatización o llamadas a API con la cuenta, esas vías de acceso tampoco desaparecen automáticamente. Cuando el problema se descubre, es posible que los datos ya hayan sido modificados.
Además, cada vez que cambia la composición del equipo, habría que cambiar la contraseña para todos. En un modelo compartido, esa actualización rara vez se completa de forma exhaustiva.
Las alternativas compatibles no son complicadas
Si se separan los motivos por los que se comparte una cuenta, las opciones compatibles son bastante claras.
- Para miembros permanentes que necesitan acceso: comprar puestos adicionales. Es la única forma de uso multiusuario respaldada oficialmente y permite recuperar la trazabilidad individual en los registros.
- Para equipos grandes: comprobar si la plataforma ofrece un plan de equipo o empresarial con varios usuarios. Estos planes suelen incluir modelos de permisos para limitar qué puede ver o modificar cada rol.
- Para un control centralizado: utilizar SSO. Cuando alguien se va, su acceso puede desactivarse de forma central sin depender de que otra persona recuerde revocarlo.
- Para mostrar resultados temporalmente a un cliente: exportar un informe o generar un enlace de solo lectura, de modo que el cliente pueda verificar los datos sin iniciar sesión en la cuenta.
Conviene distinguir entre compartir una cuenta y utilizar varias cuentas. En el primer caso, varias personas usan las mismas credenciales. En el segundo, cada persona tiene sus propias credenciales, pero necesita trabajar en el mismo dispositivo sin interferir con las demás; este segundo modelo puede ser compatible por sí mismo. Por ejemplo, si el equipo compra un puesto para cada miembro y todos tienen su propia cuenta, las cookies y sesiones pueden sobrescribirse dentro de un mismo navegador. Asignar un entorno de navegador independiente a cada cuenta permite separar sesiones, caché y datos. PurpleMark ofrece precisamente este tipo de aislamiento de entornos. Resuelve la convivencia estable de varias cuentas legítimas en un mismo dispositivo; no cambia el hecho de que varias personas compartan un único inicio de sesión, lo cual sigue infringiendo los términos del servicio.
Haga las cuentas antes de decidir
En esencia, compartir una cuenta cambia una pequeña reducción de costes por un riesgo de incumplimiento. Un uso ocasional, temporal y por una sola persona puede parecer viable durante un tiempo, pero a escala de equipo, la retirada del acceso o un incidente de datos puede costar mucho más que lo ahorrado.
Calcule primero el coste de las licencias y luego elija el método adecuado. Si puede comprar puestos, cómprelos; si puede exportar los datos, expórtelos.
Las reglas específicas de licencia dependen de los términos oficiales de cada producto.
