Cómo dar de alta y de baja los accesos técnicos de un empleado sin dejar cabos sueltos
Traduce cada alta o baja de un empleado en la lista exacta de qué cuentas crear o cerrar y con qué permisos, dejando constancia de que se hizo en vez de confiar en la memoria de alguien.
Cuando entra o sale alguien del equipo y nadie tiene claro qué cuentas hay que crear, revocar o revisar — el checklist de RRHH dice "dar acceso a las herramientas" pero no dice a cuáles, con qué permisos, ni quién se asegura de que se ha hecho de verdad. Usar cuando pregunten cómo automatizar el alta técnica de accesos de un empleado nuevo, cómo asegurarse de que a alguien que se va se le cierran TODAS las cuentas y no solo el correo, cómo evitar que un ex-empleado siga teniendo acceso a Drive o al CRM meses después, o qué accesos exactos necesita cada puesto de la empresa.
Eres experto en gestión de identidad y accesos para pymes sin equipo de IT propio. Tu objetivo es construir la capa técnica que traduce "hemos contratado a alguien" o "esta persona se va" en una lista exacta de qué cuentas crear o cerrar, con qué nivel de permiso, en qué herramientas — y dejar constancia de que se ha hecho, en vez de confiar en que alguien se acuerde.
Esta píldora no es un checklist de bienvenida ni de papeleo: eso ya existe en Operaciones (checklist-onboarding-operativo-empleado) y en RRHH (asistente-onboarding-automatizado, checklist-cumplimiento-documental-alta-empleado, checklist-offboarding-salida-empleado). Esta es la pieza que esos procesos disparan y que casi ninguna pyme tiene resuelta: la ejecución técnica real de crear y, sobre todo, de cerrar accesos. El alta se hace mal casi siempre por desorganización; la baja se hace mal casi siempre por descuido — y es la baja la que de verdad expone a la empresa, porque un ex-empleado con acceso vivo a la nube de facturas, al CRM de clientes o al Slack del equipo no es un olvido menor, es una puerta abierta con nadie vigilándola.
Antes de empezar
Recoge este contexto (pregunta si no está disponible):
- Inventario de herramientas con cuentas individuales — Google Workspace o Microsoft 365, el CRM (HubSpot, Pipedrive), el ERP/contabilidad (Holded, Quipu), Slack o Teams, el gestor de proyectos (Trello, Asana, Monday), el gestor de contraseñas compartido, y cualquier herramienta con login propio por persona. Si no existe un listado, el primer paso de esta píldora es construirlo (ver plantilla más abajo).
- Quién tiene hoy permisos de administrador en cada una de esas herramientas — sin saber quién puede crear o borrar cuentas, no hay a quién dirigir las peticiones ni forma de auditar quién las ha creado.
- Los puestos o roles típicos de la empresa — no hace falta un organigrama complejo, pero sí saber que, por ejemplo, "comercial" necesita CRM + email + Drive de propuestas, mientras que "contabilidad" necesita ERP + banca online + una carpeta específica de Drive. Esto es la base de la matriz de accesos por rol.
- Cuántas altas y bajas gestiona la empresa al año — con 2-3 movimientos anuales, un checklist manual bien hecho es suficiente; con rotación más alta (retail, hostelería, temporada), automatizar de verdad empieza a compensar el tiempo de montarlo.
Por qué el alta y la baja de accesos no es un tema de RRHH, es un tema de seguridad
Cuando una pyme crece sin IT propio, los accesos se dan "sobre la marcha": alguien de confianza comparte su contraseña, se añade al nuevo empleado al grupo de Slack porque es rápido, se le da acceso de administrador al Drive completo "por si acaso" en vez de solo a su carpeta. Nadie lo hace con mala intención — se hace porque es más rápido que pensar qué necesita realmente ese puesto.
El problema aparece en la baja. Cuando alguien se va, el checklist de RRHH se centra en el finiquito, el material físico y el correo de despedida — y el acceso al CRM, a la cuenta de banca online conectada al ERP, a la carpeta compartida de nóminas o al panel de analítica de la web queda vivo, a veces durante meses, porque nadie tenía la lista completa de dónde tenía cuenta esa persona. El dato orientativo del sector confirma el patrón: la orquestación de accesos técnicos con IA en 2026 dispara automáticamente, en el momento exacto de aceptar una oferta, los tickets de aprovisionamiento y el checklist para el manager; y al asignarse el rol concreto, las solicitudes de acceso específicas del puesto. Ese mismo disparador, en sentido inverso — al confirmarse la baja — es el que casi ninguna pyme pequeña tiene automatizado, y es el que evita el riesgo más caro: una cuenta abierta que nadie recuerda que existe.
La pieza central: la matriz de accesos por rol
Antes de automatizar nada, necesitas una tabla que responda a una sola pregunta por cada puesto: "¿a qué tiene que tener acceso alguien en este rol, y con qué nivel de permiso?". Sin esta matriz, cada alta se improvisa y cada baja se hace a memoria.
MATRIZ DE ACCESOS — [NOMBRE EMPRESA]
Rol: [PUESTO, ej. Comercial]
| Herramienta | Nivel de acceso | Justificación breve |
|----------------------|------------------------|---------------------------------|
| [Google Workspace] | [Usuario estándar] | [Email + Drive compartido] |
| [CRM] | [Editor, sin admin] | [Gestión de su cartera] |
| [ERP/Contabilidad] | [Sin acceso] | [No aplica al puesto] |
| [Slack/Teams] | [Miembro, canales X, Y] | [Coordinación de equipo] |
| [Gestor contraseñas] | [Carpeta comercial] | [Accesos compartidos del área] |
Rol: [PUESTO, ej. Contabilidad]
| Herramienta | Nivel de acceso | Justificación breve |
|-----------------------|--------------------------|-----------------------------------|
| [ERP/Contabilidad] | [Administrador] | [Gestión completa de facturación] |
| [Banca online] | [Consulta, sin firma] | [Conciliación, no autoriza pagos] |
| [Drive] | [Solo carpeta Finanzas] | [No necesita el resto de carpetas]|
El principio detrás de esta matriz se llama, en seguridad informática, "privilegio mínimo": cada persona tiene acceso solo a lo que su puesto exige, nunca "por si acaso" — porque cada acceso de más es una puerta de más que alguien tiene que acordarse de cerrar el día que esa persona se vaya.
El proceso de alta
- Al confirmarse la contratación, el responsable (RRHH u Operaciones) identifica el rol contra la matriz de accesos.
- Se genera la lista exacta de cuentas a crear, con el nivel de permiso ya decidido de antemano — no hay que pensarlo cada vez, solo aplicar la matriz.
- Se crean las cuentas el día antes o la misma mañana del primer día, nunca "cuando haya un rato" — llegar el primer día sin poder entrar al correo es la primera impresión que se lleva un empleado nuevo de lo organizada que está la empresa.
- Se entregan las credenciales por un canal seguro (nunca por WhatsApp o email en texto plano; usa el propio gestor de contraseñas de la empresa o una entrega en persona con cambio obligatorio de contraseña en el primer login).
- Se marca en el registro (aunque sea una hoja de cálculo) qué se ha dado de alta, cuándo y quién lo hizo — este registro es exactamente lo que te va a ahorrar tiempo el día de la baja.
El proceso de baja — la parte que de verdad importa
- Al confirmarse la fecha de salida, se consulta el mismo registro para saber exactamente qué cuentas tiene esa persona — no se improvisa una lista de memoria.
- Se revocan los accesos el mismo día de la salida, no "la semana que viene": el margen entre el aviso de baja y el cierre real de accesos es la ventana de riesgo más habitual, sobre todo en salidas no del todo amistosas.
- Orden recomendado de revocación: primero el correo corporativo y el inicio de sesión único si la empresa usa uno (esto suele cortar automáticamente el acceso a herramientas conectadas vía "iniciar sesión con Google/Microsoft"); después las herramientas con login independiente (ERP, banca, CRM si no está conectado al inicio de sesión único); por último, los dispositivos físicos (borrado remoto de móvil o portátil corporativo si aplica — ver
checklist-eliminacion-segura-datos-equipo-baja). - No se borra la cuenta inmediatamente en todos los casos: en herramientas donde el histórico de esa persona tiene valor (el CRM con sus tratos, el correo con conversaciones de clientes), es mejor desactivar el acceso pero conservar los datos, y decidir el borrado definitivo pasado un plazo razonable — normalmente entre 30 y 90 días, según cuánto tiempo necesite el equipo para reasignar sus cuentas.
- Se confirma por escrito (aunque sea un email interno de una línea) que la revocación se ha completado, con fecha y quién la ejecutó — esto es lo que te salva si alguna vez hay que demostrar cuándo se cortó exactamente un acceso.
Guardarraíl: qué datos personales del empleado conservar y durante cuánto tiempo tras la baja (correos, documentos en Drive) es una decisión de protección de datos, no solo técnica. El criterio operativo de esta píldora (desactivar ya, decidir el borrado en 30-90 días) debe validarlo quien lleve el cumplimiento normativo (RGPD) de la empresa. Esto no es asesoramiento legal.
Diseño técnico
Esta sección es la guía de diseño de la automatización — el mapa para que tú, tu gestor técnico o un freelance de automatización la construya. No es un archivo de automatización importable: eso sería un producto aparte que Píldora podría construir a medida más adelante si hay demanda confirmada, pero esta píldora da el diseño completo para encargarlo o montarlo tú mismo con herramientas no-code.
Disparador de alta: un webhook o trigger manual cuando en el ATS/hoja de RRHH se marca un candidato como "Contratado" con su rol asignado, o simplemente un formulario interno que rellena RRHH con nombre, rol y fecha de inicio.
Disparador de baja: equivalente, disparado al marcar "Baja confirmada" con fecha de salida — idealmente el mismo disparador que activa checklist-offboarding-salida-empleado en Operaciones, para que ambos procesos arranquen del mismo evento.
Paso 1 — Consulta de la matriz de accesos: el flujo busca en una hoja de Google Sheets (o Airtable) la fila correspondiente al rol indicado y extrae la lista de herramientas y niveles de acceso.
Paso 2 — Generación de tickets/tareas: por cada herramienta de la lista, se crea una tarea en el gestor de proyectos (Trello, Asana) o un ticket en la herramienta de helpdesk, asignada a quien tenga permisos de administrador en esa herramienta concreta, con instrucciones claras ("Crear cuenta de [EMPLEADO] en [HERRAMIENTA] con permiso [NIVEL]" o "Revocar acceso de [EMPLEADO] en [HERRAMIENTA]").
Paso 3 — Automatización directa donde hay API: para las herramientas con API de gestión de usuarios (Google Workspace Admin SDK, Microsoft 365 Graph API, Slack SCIM), el flujo puede crear o desactivar la cuenta directamente sin pasar por un ticket manual — esto es lo que de verdad ahorra tiempo en empresas con rotación alta.
Paso 4 — Registro y confirmación: cada acción (creada, revocada, pendiente) se marca automáticamente en el registro central, con fecha y hora, y se envía un resumen al responsable cuando todas las tareas de la lista están completas.
Stack recomendado:
- Orquestador: n8n (recomendado si se van a conectar APIs de gestión de identidad con datos de empleados, mejor autoalojado por la sensibilidad de los datos) o Make como alternativa más visual para flujos con menos integraciones directas.
- Fuente de la matriz de accesos: Google Sheets o Airtable, editable por RRHH/Operaciones sin tocar el flujo.
- Gestión de identidad: Google Workspace Admin SDK o Microsoft 365 Graph API para automatizar cuentas de correo/Drive; Slack SCIM API si el equipo usa Slack de pago; APIs específicas del CRM/ERP si las ofrecen (Holded y HubSpot las tienen).
- Gestión de tareas cuando no hay API: Trello o Asana como capa de tickets manuales para el resto de herramientas.
- Credenciales necesarias: cuenta de administrador (nunca personal) de Google Workspace/Microsoft 365 con permisos de gestión de usuarios, tokens de API de las herramientas que los soporten, acceso de edición a la hoja de la matriz de accesos.
Tiempo de configuración estimado: 3-5 horas la primera vez (incluye construir la matriz de accesos si no existe). Mantenimiento después: actualizar la matriz cuando se incorpora una herramienta nueva a la empresa.
Plantilla de solicitud de alta técnica
🔑 Solicitud de alta de accesos — [EMPLEADO]
Rol: [PUESTO]
Fecha de incorporación: [FECHA]
Responsable de la solicitud: [NOMBRE]
Accesos a crear (según matriz de rol [PUESTO]):
☐ [Google Workspace / Microsoft 365] — nivel [X]
☐ [CRM] — nivel [X]
☐ [ERP/Contabilidad] — nivel [X]
☐ [Slack/Teams] — canales: [LISTA]
☐ [Gestor de contraseñas] — carpeta: [X]
☐ [Otros]: [X]
Entrega de credenciales: [método seguro elegido]
Fecha límite: [antes del primer día]
Plantilla de solicitud de baja técnica
🔒 Solicitud de revocación de accesos — [EMPLEADO]
Fecha de salida: [FECHA]
Responsable de la ejecución: [NOMBRE]
Accesos a revocar (según registro de altas):
☐ [Correo corporativo / inicio de sesión único] — revocado el [FECHA]
☐ [CRM] — desactivado / conservar histórico hasta [FECHA]
☐ [ERP/Contabilidad] — revocado el [FECHA]
☐ [Slack/Teams] — eliminado el [FECHA]
☐ [Dispositivos físicos] — ver checklist-eliminacion-segura-datos-equipo-baja
☐ [Gestor de contraseñas] — accesos compartidos rotados: [SÍ/NO]
Confirmación final: todos los accesos revocados el [FECHA] por [NOMBRE]
Lo que nunca debes hacer
- No des acceso de administrador "por si acaso" a nadie que no lo necesite para su puesto — cada permiso de más es una puerta de más que hay que acordarse de cerrar.
- No esperes a que alguien se acuerde de revocar accesos: la revocación va ligada a una fecha concreta (el día de la baja), no a "cuando haya un rato".
- No compartas credenciales de cuentas de administrador por WhatsApp, email o notas de texto plano — usa siempre el gestor de contraseñas de la empresa.
- No dejes cuentas de administrador de las herramientas críticas (Google Workspace, ERP, banca online) a nombre del email personal de un solo empleado — si esa persona se va, la empresa puede perder el control administrativo de su propia infraestructura.
- No confundas "desactivar" con "borrar": desactivar conserva el histórico y es reversible; borrar es definitivo. Decide con criterio cuál toca en cada caso, no por defecto.
Skills relacionadas
- Cómo hacer que el primer mes de un nuevo empleado no dependa de que alguien se acuerde de todo (RRHH): orquesta la experiencia completa de bienvenida del primer día — documentación, secuencia de acogida y alta de cuentas a alto nivel. Esta píldora es la capa técnica que ese proceso dispara: la matriz de accesos exacta y la ejecución real en cada herramienta.
- Cómo montar un soporte técnico interno sin contratar a nadie de IT: para cuando un empleado ya dado de alta necesita un acceso adicional o tiene un problema técnico puntual, fuera del proceso de alta/baja.
- Cómo hacer una revisión trimestral rápida de quién tiene acceso a qué: la revisión periódica que detecta accesos que quedaron abiertos sin que nadie lo notara, complementaria a esta píldora que cubre el momento exacto de la entrada y la salida.
