La escena es siempre la misma y nunca parece grave. Alguien del equipo se va —mejor oferta, cambio de ciudad, fin de contrato—, hay tarta, hay buenos deseos y hay una checklist de salida que alguien repasa con diligencia: devolver el portátil, cerrar el correo, quitar el acceso al CRM, liquidar la nómina. Todo correcto. Y en algún sitio, el flujo que esa persona montó hace catorce meses para clasificar las facturas que entran por correo sigue arrancando a las 7:05 de la mañana, como todos los días. Nadie lo apunta en la checklist, porque el proceso no se ha roto. Funciona. Eso es exactamente el problema.
La tesis en una línea: el riesgo operativo de la IA en una empresa sin equipo de plataforma no entra por un ataque, entra por una baja. No hay intrusión, no hay vulnerabilidad, no hay nada que un antivirus detecte. Hay un proceso vivo corriendo con la identidad de alguien que ya no está, y una lógica que vivía en su cabeza. El fallo no llega el día de la despedida: llega semanas después, cuando caduca un token, cuando se rota una contraseña, o cuando alguien decide —con todo el criterio del mundo— cerrar por fin esa cuenta que llevaba meses sin usarse.
Y cuando llega, llega sin pista. No es un error de código que un log explique: es un proceso que dejó de pasar y que nadie echa de menos hasta que un cliente pregunta por su factura.
Qué pasa con las automatizaciones cuando se va un empleado: nada, hasta que caduca una credencial
Merece la pena entender el mecanismo, porque aquí la intuición falla. Cuando una persona se va, su automatización no se detiene. Los flujos no están atados al contrato laboral: están atados a credenciales, y las credenciales sobreviven a la persona por diseño. Un token de API es válido hasta su fecha de caducidad. Una autorización OAuth concedida a una herramienta sigue en pie mientras exista la cuenta que la concedió. Una clave pegada en el panel de un conector no sabe si quien la pegó sigue en la empresa.
Así que el día de la baja no pasa nada visible, y eso genera la falsa sensación de que no había dependencia. La hay, y se materializa en uno de estos cuatro momentos, siempre con semanas o meses de retraso:
- Caduca el token. Casi toda credencial de integración tiene vida limitada. El día que expira, el flujo empieza a devolver un error de autenticación que nadie lee, porque las notificaciones iban al correo de quien se fue.
- Se borra la cuenta de verdad. Al principio se suele suspender el usuario para no romper nada. Meses después, en una limpieza de licencias —que es una conversación de coste, no de riesgo—, se elimina. Y con él se van todas las autorizaciones que concedió.
- Cambia algo al otro lado. El proveedor actualiza su API, el banco cambia el formato del extracto, el CRM renombra un campo. El flujo necesita un ajuste de diez minutos que solo puede hacer quien entienda por qué estaba montado así.
- Aparece una excepción nueva. El caso raro que la lógica no cubría. La persona que se fue sabía qué hacer con él porque lo decidió ella; quien queda no sabe ni que esa decisión existía.
No es shadow AI y no se arregla contando agentes
Esto se confunde con dos problemas vecinos, y la confusión sale cara porque las tres cosas se arreglan con palancas distintas.
El shadow AI es uso no autorizado: gente usando herramientas que la empresa no aprobó. Es un problema de demanda no atendida y se resuelve ofreciendo una vía sancionada. El inventario es un problema de recuento: no saber cuántas automatizaciones tienes ni qué tocan. Se resuelve mirando.
Lo de la baja es otra cosa: es ciclo de vida. Una automatización puede estar perfectamente autorizada, perfectamente inventariada y perfectamente descrita en una hoja de cálculo, y seguir siendo frágil, porque lo que le falta no es permiso ni registro: le falta un dueño vivo y una identidad propia. Un inventario te dice que el flujo existe. No te dice que corre con las credenciales de Marta, y que Marta se fue en marzo.
La diferencia práctica: el shadow AI y el inventario se resuelven con una foto. El ciclo de vida solo se resuelve con un proceso, porque la gente va a seguir entrando y saliendo de tu empresa mientras la empresa exista.
El dato: el mercado todavía no sabe revocarle las credenciales a un agente
Hay un número que conviene mirar con atención, no porque hable de pymes españolas —no lo hace— sino por a quién mide. En su informe 2026 Identity Security Landscape, basado en una encuesta a 2.930 responsables de seguridad de todo el mundo, Palo Alto Networks publica dos cifras que leídas juntas describen este agujero mejor que cualquier anécdota: el 99 % de las organizaciones ya ha adoptado agentes de IA, y solo el 37 % puede revocar las credenciales de un agente. Solo el 30 % tiene registro de auditoría inmutable de lo que esos agentes hacen. Fuente: How to Assess Maturity When Machine Identities Outnumber Humans 109:1, Palo Alto Networks, mayo de 2026.
El ámbito importa y hay que decirlo claro: es una encuesta mundial a empresas grandes, con equipo de seguridad, presupuesto y un CISO que responde el cuestionario. No es una muestra de pymes españolas ni portuguesas ni italianas. Pero por eso mismo es útil como suelo: si dos de cada tres organizaciones con equipo de seguridad no pueden cortarle el acceso a un agente, la pregunta de qué pasa en una empresa de cuarenta personas donde el flujo lo montó el responsable de operaciones un jueves por la tarde se responde sola.
El mismo informe apunta a dónde está exactamente el hueco: la mayoría de las organizaciones sabe explicar para qué sirve cada agente, y muchas menos saben definir a qué accede, cómo se limita ese acceso, cuándo se revocan sus permisos y qué otros sistemas heredan ese acceso. No es un problema de desconocimiento del propósito. Es un problema de final de vida.
| Lo que la checklist de salida sí cubre | Lo que no cubre | Qué se rompe |
|---|---|---|
| Correo, portátil, acceso al CRM, nómina | Las credenciales con las que corren sus automatizaciones | El flujo sigue vivo con la identidad de alguien que ya no está |
| Traspaso de clientes y tareas abiertas | El criterio con el que decidió los casos raros | La primera excepción nueva nadie sabe resolverla |
| Quitar a la persona de las listas de correo | Redirigir las alertas de error de sus flujos | El fallo ocurre y el aviso va a un buzón cerrado |
| Firmar la baja en el gestor documental | Anotar quién hereda ese proceso | El proceso se queda sin dueño sin que nadie lo decida |
Las tres preguntas que faltan en tu checklist de salida
No hace falta un proyecto para cerrar esto. Hacen falta tres preguntas en la conversación de salida, hechas antes del último día, cuando la persona todavía está y todavía tiene ganas de ayudar:
- ¿Con qué identidad corre cada cosa que montaste? No «qué montaste»: con qué cuenta. La respuesta útil es una lista de flujos y, al lado de cada uno, la cuenta o la clave que usa. Si alguna línea dice «mi cuenta», ya tienes el trabajo del lunes identificado. Esta es la pregunta que decide si una baja es un trámite o una incidencia aplazada.
- ¿Qué decidiste tú que no está escrito? Toda automatización útil tiene una capa de criterio que no está en la configuración: qué se considera una factura duplicada, cuándo un correo merece respuesta humana, qué proveedor es la excepción de siempre. Media hora grabando a esa persona contando los casos raros vale más que cualquier manual que escriba a la carrera.
- ¿A quién tiene que avisar esto cuando falle? No «a quién avisabas tú». A quién tiene que avisar a partir de ahora. Un flujo cuyas alertas van a un buzón que se va a cerrar es un flujo que ya está fallando en silencio, solo que todavía no lo sabes.
Las tres caben en una reunión de cuarenta minutos y resuelven la mayor parte del riesgo. La versión completa de la primera —qué identidad, con qué alcance y qué puede tocar— está desarrollada en la guía sobre los permisos de un agente de IA, que es donde se decide si esta conversación de salida es incómoda o trivial.
Qué hacer si ya te has quedado sin la persona
El caso más común no es el preventivo: es el reactivo, con la persona fuera desde hace tres meses y nadie seguro de qué sigue corriendo. Orden de trabajo, de lo barato a lo caro:
- No borres la cuenta todavía. Es tentador cerrarla por higiene, y es la forma más rápida de convertir un riesgo latente en una parada de servicio. Suspende el acceso interactivo —que nadie pueda entrar con ella— y deja las credenciales de integración vivas hasta haber terminado el paso 3.
- Mira qué sigue pasando con esa identidad. Los registros de acceso de tus herramientas principales (correo, CRM, ERP, la plataforma de automatización) te dicen qué actividad hay todavía a nombre de esa cuenta. Eso es tu inventario real, mucho mejor que el que montarías de memoria.
- Reemite cada credencial a nombre de la empresa. Crea una cuenta de servicio con permisos acotados por flujo y vuelve a autenticar las conexiones. Es trabajo aburrido, de una tarde, y es el único que elimina el problema en vez de posponerlo.
- Redirige las alertas a un buzón de equipo. No a otra persona: a una dirección que sobreviva a la siguiente baja. Esto es lo que convierte el próximo fallo en algo que alguien lee.
- Escribe la lógica que recuperes mientras la recuperas. Lo que te cuenten los registros y los que queden, escríbelo en el momento. Ese documento no se va a escribir después; nunca se escribe después.
Si durante el paso 2 descubres que un flujo lleva semanas fallando sin que nadie lo supiera, el problema ya no es la baja: es que nadie estaba mirando. Esa es otra conversación, y está en la guía sobre quién responde cuando se cae una automatización.
El error de diseño está antes, el día que se montó
Todo lo anterior es gestión de daños. La causa está en un momento muy anterior y muy barato de arreglar: el día en que alguien montó el flujo con su propia cuenta porque era lo que tenía a mano y funcionaba. Nadie hizo nada mal. Simplemente nadie decidió lo contrario, porque la decisión no estaba en ninguna lista.
La forma de que esto no vuelva a pasar son tres reglas que no cuestan dinero, solo acuerdo: ninguna automatización corre con la cuenta de una persona —cuentas de servicio con permisos acotados, siempre—; cada flujo vivo tiene un nombre al lado del que responde por él, y ese nombre se revisa cuando alguien cambia de puesto; y las alertas van a un buzón de equipo, nunca a un individuo. Las tres juntas convierten una baja en un trámite administrativo, que es lo que debería ser. El marco completo de esa decisión está en la guía de gobernanza y control de la automatización con IA.
Y hay un caso en el que ninguna regla interna llega: cuando la persona que montó el sistema nunca fue de la casa. Si tus automatizaciones las levantó un consultor o una agencia, el día que termine el contrato se reproduce exactamente esta misma escena, con la diferencia de que no hay conversación de salida ni café de despedida. Por eso el mantenimiento de lo que corre es un servicio y no un favor: alguien tiene que mantener los agentes de IA cuando quien los montó ya no está, y esa pregunta se contesta antes de firmar, no después.
Una automatización que solo una persona entiende no es un activo. Es una deuda con fecha de vencimiento desconocida, y la fecha la pone el mercado laboral, no tú.