Por qué desvincular a un contratista es más difícil de lo que parece

Cuando un diseñador freelance termina un proyecto, o cuando un programador por contrato entrega un build, el reflejo natural es mandar la última factura y seguir. Ese reflejo está mal. El trabajo no termina de verdad hasta que el acceso que lo hizo posible se cierra, se rota y se verifica.

La mayoría de los fundadores aprende esto por las malas. Un contratista se va un viernes, el fundador cambia algunas contraseñas el lunes, y tres meses después descubre que una API key vieja sigue sacando datos de clientes, que un workspace de Notion sigue editable, o que un asiento pago en una herramienta de diseño se ha estado renovando silenciosamente para alguien que se fue en primavera. El riesgo rara vez es dramático en el momento — es el goteo lento de accesos vivos que nadie rastrea de principio a fin.

Esta guía es un checklist funcional para fundadores solos y equipos pequeños. Es opinada sobre el orden, conservadora con las afirmaciones, y construida alrededor de la pregunta real que se hace un fundador: ¿qué podría seguir siendo accesible mañana y se me está olvidando hoy?

El objetivo no es un checklist de TI con 200 puntos. El objetivo es una rutina que puedas correr en una tarde, cada vez que termina el trabajo de un contratista, y que produzca una respuesta clara a una sola pregunta: ¿hay algo mío todavía en sus manos?

Qué significa realmente “desvincular limpiamente”

Una desvinculación limpia tiene cuatro resultados. Si puedes decir que sí a los cuatro, has terminado.

  1. El contratista no puede iniciar sesión en nada que tú controles.
  2. El contratista no puede usar ninguna credencial compartida, API key o token que siga funcionando.
  3. La data del contratista — archivos, comentarios, borradores — queda contigo o se borra de forma intencional, no abandonada.
  4. El asiento, la licencia o la suscripción asociada a esa persona se recupera o se reasigna, no se cobra en silencio.

Cada uno de esos resultados corresponde a una categoría distinta de acceso. Saltarse una categoría es cómo los accesos viejos vuelven sin que te enteres.

El checklist de desvinculación para fundadores

Ejecuta los pasos en orden. Los pasos 1 a 4 son de descubrimiento, los pasos 5 a 8 son de revocación, y los pasos 9 y 10 son de verificación. El descubrimiento es donde más equipos fallan; la verificación es la que atrapa lo que el descubrimiento no vio.

1. Inventaría cada herramienta que el contratista tocó

Abre un documento nuevo y anota cada herramienta SaaS en la que el contratista inició sesión para tu trabajo. Saca la lista de señales reales, no de memoria:

  • Historial de correo y chat. Busca su dirección y su handle en el inbox compartido y en las herramientas de chat. Cada herramienta en la que fue copiado es candidata.
  • Facturas y recibos pasados. Todo lo que pagaste en su nombre, o que tocó su trabajo, es candidato.
  • Marcadores del navegador y entradas del gestor de contraseñas, si tienes acceso.
  • Invitaciones de calendario a herramientas recurrentes (revisiones de diseño, demos de sprint, aprobaciones de despliegue).
  • Logs del proveedor de identidad y de SSO, si usas inicio de sesión único — la mayoría de las herramientas modernas de identidad te dicen exactamente en qué apps ha entrado un usuario recientemente.

La lista será más larga de lo que esperas. Ese es el punto. Cuanto más larga, menos probable es que se te escape la herramienta oscura que tiene acceso a producción.

2. Clasifica qué tipo de acceso tenía cada herramienta

No todos los accesos son iguales. Para cada herramienta del inventario, anota cuál de estas categorías aplica:

  • Login personal — tenía su propio usuario y contraseña, posiblemente con su correo personal como dirección de recuperación.
  • Login compartido — usaba un correo de equipo tipo equipo@tudominio.com, o un login genérico que todos comparten. Esta es la categoría más arriesgada.
  • Login por SSO — se autenticaba vía Google Workspace, Microsoft 365 o un proveedor de identidad, y el acceso se controla de forma centralizada.
  • API key, token o cuenta de servicio — generaba o usaba una credencial que llama a tus sistemas de forma programática (CI/CD, hosting, analítica, pagos, herramientas de IA).
  • Concesión OAuth — conectó una app de terceros (un asistente de IA, una herramienta de reportes, un scheduler) a un sistema central como tu CRM o tu cuenta en la nube.
  • Compartición de archivos o documentos — tenía acceso a carpetas, archivos, documentos, tableros o repos específicos, más que a una cuenta completa.

Esta clasificación importa porque cada categoría se revoca de forma distinta. Un login personal se elimina. Un login compartido se rota. Una API key se regenera. Una concesión OAuth se revoca. Un permiso de archivo se quita.

3. Rescata lo que quieras conservar antes de revocar

Revocar el acceso a veces borra la data detrás de él. Antes de empezar a tirar de credenciales, decide qué quieres conservar:

  • Archivos de diseño, repos, ramas, dashboards, documentos.
  • Borradores, comentarios y conversaciones en workspaces compartidos.
  • Grabaciones de llamadas o demos en las que participó.
  • Cualquier entregable para cliente que solo exista dentro de su cuenta.

Transfiere la propiedad de los repos, mueve archivos a una carpeta tuya, exporta lo que necesites. Haz esto antes del paso 5, no después.

4. Decide quién es dueño de la revocación

Incluso en un equipo de una sola persona, nombra la función dueña de este trabajo, aunque seas tú. La razón no es burocracia; es que la desvinculación falla cuando nadie es responsable del ciclo de vida completo. La función que otorgó el acceso debería ser la que confirma que se fue. Si el contratista fue configurado por una agencia o un partner, anota quién en ese partner era el contacto técnico — lo vas a necesitar.

5. Revoca primero los logins personales

Para cada herramienta donde el contratista tenía login propio:

  • Desactiva o elimina la cuenta de usuario en la consola de administración.
  • Si la herramienta lo permite, transfiere su trabajo a un dueño nombrado antes de borrar.
  • Quita la herramienta del perfil SSO si tenía uno.
  • Cambia cualquier correo de recuperación o teléfono vinculado a su cuenta para que no pueda disparar un reseteo de contraseña.

La mayoría de apps SaaS lo hacen desde un panel de configuración o de miembros. Para herramientas que no administras activamente, contacta a soporte y pide confirmación por escrito de que la cuenta está desactivada.

6. Rota cada credencial compartida

Este es el paso que los fundadores más se saltan, y es el que tiene el radio de explosión más largo. Las credenciales compartidas incluyen:

  • Correos o cuentas sociales compartidas (equipo@, social@, logins genéricos).
  • Contraseñas compartidas en tu gestor de contraseñas.
  • API keys, llaves de cuentas de servicio y secretos de webhooks guardados en cualquier lado.
  • Llaves SSH autorizadas en tus servidores o repos.
  • Tokens emitidos a integraciones y herramientas de automatización.
  • Códigos de recuperación de cualquier 2FA que se configuró bajo una identidad compartida.

La regla es simple: si más de un humano la supo alguna vez, rótala ahora. Rotar significa generar un secreto nuevo, actualizar todos los sistemas que la consumen, e invalidar la vieja. Para las API keys, trata la llave vieja como comprometida en el momento en que termina la relación.

7. Recupera o reasigna asientos de licencia

Cada asiento pago de SaaS que un contratista ocupaba es una línea en tu próxima factura. Recupéralos en la misma pasada:

  • Reasigna el asiento a un usuario actual si lo necesitas.
  • Baja tu plan a un nivel menor si el asiento era el único por encima del nuevo umbral.
  • Para contratos anuales, verifica si los asientos no usados se pueden acreditar o prorrogar — las condiciones varían por plataforma, así que confirma por escrito antes de asumir.
  • Para herramientas facturadas por workspace o por proyecto, archiva el workspace del contratista para que deje de contar como uso activo.

Este paso ahorra dinero real. También reduce la cantidad de cuentas que existen, lo que facilita la próxima desvinculación.

8. Revoca comparticiones de archivos, concesiones OAuth y conexiones de terceros

Una cantidad sorprendente del acceso de un contratista se concede por caminos indirectos:

  • Carpetas compartidas en Google Drive, Dropbox, OneDrive o Box.
  • Workspaces compartidos en Notion, Coda o Confluence.
  • Colaboradores de repositorios en GitHub o GitLab, deploy keys y personal access tokens.
  • Apps conectadas en tu CRM, herramienta de contabilidad, inbox de soporte, calendario o workspace de IA.
  • Extensiones del navegador y marcadores que guardan cookies de sesión.

Para cada uno, quita el acceso del contratista directamente desde el sistema principal. No confíes en que el contratista se desconecte — muchos flujos OAuth no notifican al sistema principal cuando se elimina a un tercero, y las concesiones obsoletas son una fuente conocida de acceso silencioso.

9. Verifica, no asumas

Una revocación que no se verifica es una suposición. Elige un método de verificación que cuadre con el riesgo:

  • Intenta iniciar sesión en las cuentas más sensibles con las credenciales viejas, en una ventana de incógnito, con los datos de contacto del contratista todavía pegados.
  • Para API keys, llama a la key contra un endpoint de solo lectura y confirma que falla.
  • Para logins compartidos, entra con la contraseña nueva desde otro dispositivo para confirmar que la vieja ya no sirve.
  • Para concesiones OAuth, lista las apps conectadas en tus herramientas centrales y confirma que la conexión del contratista se fue.
  • Para SSO, revisa el log de actividad reciente del proveedor de identidad para la cuenta del contratista — debería mostrar cero logins exitosos después de la fecha de desvinculación.

Verificar es barato. También es la diferencia entre creo que está apagado y sé que está apagado.

10. Documenta y fecha la limpieza

Guarda un registro breve de qué se revocó, cuándo y por quién. Esto sirve por tres motivos: hace más rápida la próxima desvinculación, te da un rastro de auditoría si algo se cuestiona después, y saca a la luz herramientas que olvidaste inventariar para sumarlas a la próxima ronda. Una hoja de cálculo simple alcanza.

Dónde ayuda la automatización — y dónde no

Las herramientas de revocación automática de accesos, las plataformas de gobernanza de identidad y los suites de gestión de SaaS pueden atar la revocación a un evento disparador — una fecha de fin de contrato, un cambio de estado en RR. HH., una marca manual. El beneficio es la consistencia: la revocación ocurre en el instante en que se dispara el evento, no cuando alguien se acuerda.

La letra chica para un equipo pequeño es el costo y la complejidad. Muchas plataformas de gobernanza están pensadas y priced para organizaciones medianas, y el tiempo de configuración puede rivalizar con el tiempo ahorrado. Una alternativa más ligera es atar el checklist de arriba a un único disparador — normalmente la fecha de fin de contrato en tu herramienta de proyectos o contratos — y asignarlo a un dueño con fecha límite. Eso es automatización de espíritu, si no de software.

Para las identidades no humanas — API keys, cuentas de servicio, tokens de automatización — aplica el mismo principio de ciclo de vida: las credenciales son activos con dueño, caducidad y paso de revocación. Tratarlas como logins de contratistas, solo que programáticos, es un modelo mental útil.

Puntos ciegos comunes que tropiezan a los fundadores

  • El correo del contratista es la dirección de recuperación de un inbox compartido. Aunque cambies la contraseña, puede resetearla.
  • Una cuenta personal de GitHub es colaboradora de un repo privado. Quitarlo de la org no es lo mismo que quitarlo de cada repo.
  • Una herramienta de IA conectada tiene acceso de lectura a tu CRM o data warehouse. La cuenta de la herramienta sigue viva aun después de que el contratista se va.
  • Un asiento anual se pagó por adelantado y sigue facturándose. Las condiciones de cancelación varían; no asumas nada.
  • Un vault compartido en 1Password, Bitwarden o LastPass guarda secretos de producción. Compartir entradas del vault es tan conveniente como peligroso.
  • Una deploy key en un servidor se configuró una vez y nunca se documentó. Busca en tus archivos known_hosts y en tu proveedor de hosting las huellas SSH.

Cuánto debería tomar esto

Para un solo contratista en un stack SaaS típico, la primera corrida toma entre dos y cuatro horas. Con práctica, y con un inventario mantenido, puede ser de treinta a sesenta minutos. El costo de saltárselo rara vez se ve el día que pasa. Aparece como una anomalía de facturación seis meses después, un incidente de seguridad que se rastrea hasta una key obsoleta, o una pregunta de auditoría que nadie puede responder.

Preguntas frecuentes

¿De verdad tengo que rotar una contraseña compartida que solo usamos internamente? Si más de una persona la supo alguna vez, sí. La gente se va, los dispositivos se reutilizan, y los excontratistas a veces reenvían credenciales al sucesor. Rotar es un seguro barato.

¿Y si el contratista nunca entró a nada sensible? Haz el inventario de todas formas. El costo es bajo y la ganancia es encontrar la única herramienta que olvidaste que tocó — un CMS, una plataforma de traducción, un workspace de IA — que tiene más acceso del que recordabas.

¿Borro las cuentas del contratista y me salto el paso de rotar? Borrar quita la cuenta, pero no los secretos que el contratista pudo copiar. Rota credenciales compartidas y API keys sin importar si la cuenta sigue activa.

¿Cada cuánto reviso los accesos de los contratistas activos? Una revisión ligera trimestral atrapa la deriva. El checklist de desvinculación se encarga del punto final. Entre los dos cubren tanto la acumulación rutinaria como las salidas limpias.

Fuentes