Una licencia SaaS puede parecer un gasto menor hasta que se multiplica por equipos, filiales y herramientas. El problema no se resuelve solo mirando el número de usuarios contratados: hay que distinguir entre una cuenta activa, una persona que conserva acceso, una licencia asignada y un uso que justifica mantenerla.
La automatización y la IA pueden ayudar a preparar decisiones repetitivas, pero no deberían retirar permisos o reducir capacidad por una señal aislada. La meta es construir un proceso que detecte oportunidades de reasignación, reúna contexto y deje la decisión y su evidencia donde corresponde.
La intención correcta: decidir sobre una licencia, no vigilar a una persona
El caso de uso consiste en revisar periódicamente licencias nominativas o de pago por usuario para decidir si se mantienen, se reasignan, se cambian de nivel o se cancelan en la siguiente renovación. Es distinto de gestionar un contrato de proveedor: el foco está en la asignación concreta de cada acceso y en el valor operativo de conservarlo.
Antes de automatizar, fija una definición que sea comprensible para negocio, IT y seguridad:
- Licencia asignada: asiento o derecho de uso que consume capacidad contratada.
- Uso verificable: señal documentada por la aplicación, como actividad, propiedad de contenidos o pertenencia a un proceso aprobado.
- Cuenta crítica: acceso que no debe retirarse automáticamente porque sostiene una integración, una función de guardia, una responsabilidad legal o una operación de continuidad.
- Oportunidad de revisión: caso que merece confirmación; no equivale a una baja automática.
Qué datos reunir antes de proponer una reasignación
La calidad de la decisión depende de cruzar fuentes, no de pedir a un modelo que interprete una lista de nombres. Un flujo útil parte de datos estructurados y conserva el origen de cada conclusión.
1. Inventario de aplicaciones y condiciones de licencia
Mantén para cada aplicación su propietario interno, tipo de licencia, fecha de revisión, restricciones de transferencia y canal de aprovisionamiento. Si un producto exige conservar registros, separa esa obligación de la decisión sobre la licencia de acceso.
2. Relación entre identidad y puesto
Conecta el directorio corporativo o la fuente de RR. HH. con la cuenta SaaS. Así se pueden detectar salidas, cambios de equipo, duplicidades y cuentas sin propietario. Las cuentas técnicas, compartidas o de emergencia deben quedar identificadas como excepciones, no mezcladas con usuarios individuales.
3. Señales de uso y contexto operativo
Recoge solo las señales que la herramienta permita obtener y que tengan una finalidad clara: fecha de acceso, nivel contratado, pertenencia a grupos, propiedad de recursos o actividad relevante. Una ausencia de inicio de sesión no demuestra por sí sola que una licencia sea prescindible: puede haber uso por integración, periodos de baja actividad o una tarea estacional.
4. Evidencia de la decisión
Cada propuesta debe guardar la regla que la originó, las fuentes consultadas, quién confirmó la acción y el resultado. Esto permite explicar una reasignación y corregirla sin reconstruir el caso desde correos dispersos.
Un flujo seguro de principio a fin
- Descubrir: importar asignaciones de licencias y cuentas desde el panel SaaS o su API autorizada.
- Normalizar: asociar cada cuenta a una identidad, unidad, responsable y aplicación; marcar las que no se puedan asociar con certeza.
- Aplicar reglas deterministas: por ejemplo, cuentas de personas que ya no están, licencias duplicadas o accesos sin propietario. Las reglas deben ser visibles y modificables por el responsable del servicio.
- Enriquecer: usar IA para resumir el expediente, clasificar la respuesta del responsable o preparar un mensaje de confirmación. No use la IA como única fuente de una decisión de retirada.
- Pedir confirmación: enviar la propuesta al responsable del acceso cuando exista impacto funcional, incertidumbre o excepción.
- Ejecutar con control: reasignar, degradar o retirar solo tras la aprobación que defina la política; registrar la acción y la fecha.
- Comprobar y aprender: verificar que la licencia quedó liberada o que el nuevo acceso funciona, y analizar las reversiones para ajustar reglas.
Reglas que suelen ser razonables y reglas que no lo son
Conviene que las reglas iniciales sean conservadoras. Una cuenta vinculada a una baja confirmada puede generar una propuesta prioritaria, pero si posee documentos, automatizaciones o roles administrativos, debe ir a revisión. Del mismo modo, una licencia duplicada puede sugerir una consolidación, pero no debe retirarse si cada una cubre entornos o responsabilidades separadas.
Evita reglas del tipo «sin actividad durante X días, eliminar». En lugar de eso, usa una secuencia: detectar, clasificar el nivel de riesgo, solicitar confirmación, ejecutar una acción reversible cuando sea posible y verificar. La caducidad, los periodos de cierre, campañas comerciales y equipos temporales necesitan tratamientos explícitos.
Criterios para decidir qué acción tomar
| Situación | Acción recomendada | Control necesario |
|---|---|---|
| La persona ha salido y la cuenta no tiene recursos críticos | Preparar retirada o reasignación | Confirmar baja y comprobar propiedad de recursos |
| Hay baja actividad, pero el responsable sigue activo | Pedir confirmación antes de cambiar la licencia | Contexto de puesto, estacionalidad y fecha límite |
| La cuenta es técnica, de emergencia o administrativa | Excluir del flujo estándar | Propietario técnico, revisión específica y registro de excepción |
| Dos licencias cubren funciones diferentes | Mantener hasta validar el alcance | Comparar roles, entornos y dependencias |
| Existe una solicitud aprobada para una nueva incorporación | Reasignar una licencia liberada si es compatible | Validar perfil, aprobación y trazabilidad de la asignación |
Límites de la IA y de la automatización
Un modelo puede resumir respuestas abiertas o señalar incoherencias, pero no conoce por sí mismo una excepción de negocio ni la implicación contractual de un cambio de licencia. Tampoco debe recibir listados de usuarios o actividad sin revisar la base legal, el alcance de los datos y la configuración de seguridad del proveedor.
Diseña siempre una salida segura: una acción reversible cuando la plataforma lo admita, un canal de soporte para recuperar acceso y una cola de excepciones que no se cierre automáticamente. Separa además el permiso para proponer del permiso para ejecutar cambios.
Cómo empezar sin convertirlo en un proyecto interminable
Elige una sola aplicación con muchas licencias nominativas, un propietario claro y una fuente de identidad fiable. Documenta el proceso actual, define tres o cuatro reglas de revisión, prueba con propuestas sin ejecución y mide cuántos casos requieren corrección humana. Solo después conviene conectar la reasignación o la retirada.
Si necesitas diseñar este flujo, integrar las fuentes de identidad y uso, o establecer controles de aprobación y auditoría, en KMOOPS podemos ayudarte desde nuestros servicios de automatización, IA y consultoría IT. Para revisar un caso concreto, contacta con el equipo.