Los permisos no se vuelven correctos porque se aprobaron una vez. Los puestos cambian, se incorporan aplicaciones, se conceden accesos temporales y algunos responsables dejan de tener visibilidad sobre lo que conserva su equipo. La recertificación de accesos es el proceso periódico de confirmar que cada persona mantiene solo los permisos que necesita para su función.
Este artículo se dirige a responsables de IT, seguridad y áreas de negocio que necesitan revisar accesos a ERP, CRM, herramientas financieras, repositorios documentales u otras aplicaciones corporativas sin convertir cada revisión en una exportación interminable de usuarios. La IA puede ayudar a ordenar expedientes y resumir contexto; no debe decidir quién conserva privilegios ni ejecutar retiradas sensibles sin una regla y una validación humana.
Qué problema resuelve una recertificación de accesos
Una alta o una baja bien gestionadas no cubren todo el ciclo de vida. Entre ambos eventos pueden aparecer cambios de puesto, proyectos temporales, permisos añadidos para resolver una incidencia o aplicaciones que quedan fuera del directorio central. La recertificación busca responder con evidencia a cuatro preguntas: quién tiene acceso, a qué recurso, para qué tarea y quién confirma que sigue siendo necesario.
No es un inventario técnico aislado ni una campaña para retirar permisos de forma indiscriminada. Es una decisión de negocio respaldada por datos de identidad, rol, actividad y riesgo. Si no existe un propietario de la aplicación o un responsable capaz de decidir, el primer resultado de la campaña debe ser una excepción asignada, no una aprobación automática.
Delimite el alcance antes de pedir revisiones
Empezar por todas las aplicaciones y todos los permisos suele producir revisiones superficiales. Seleccione un ámbito con propietario claro y consecuencias relevantes: por ejemplo, usuarios con capacidad de exportar datos de clientes, aprobar documentos financieros o modificar parámetros de un ERP.
- Incluya: identidades nominales, grupos, roles de aplicación y permisos delegados que permitan leer, modificar, aprobar o exportar información.
- Separe: cuentas técnicas, cuentas de emergencia y accesos de proveedores. Requieren expedientes y responsables específicos; no deben perderse entre usuarios ordinarios.
- Defina la frecuencia por riesgo: no todos los accesos necesitan la misma cadencia. Un rol de administración o aprobación requiere una revisión más frecuente que un permiso básico de consulta.
- Fije una fecha de referencia: el revisor debe saber qué estado está validando y cuándo se extrajeron los datos.
El alcance debe expresar también lo que queda fuera. Así se evita que una respuesta afirmativa se interprete como una certificación global de todos los sistemas de una persona.
Construya un expediente comprensible para quien decide
Un responsable no debería recibir una lista de identificadores de grupos sin contexto. Para cada decisión, prepare una ficha breve que relacione la identidad con el permiso y la necesidad operativa. La información mínima suele incluir el nombre de la persona, área, responsable, aplicación, rol o grupo, descripción funcional, fecha de concesión si está disponible, última revisión, fuente del dato y nivel de riesgo.
No confunda actividad con necesidad
Una fecha de inicio de sesión o de uso puede ser una señal útil, pero no prueba que un permiso sea innecesario. Puede haber trabajo estacional, una responsabilidad de sustitución o una actividad realizada mediante una integración. Muestre la señal como contexto y pida confirmación cuando no sea concluyente. Nunca convierta una ausencia de actividad en una baja automática.
También conviene señalar incoherencias verificables: una persona dada de baja que conserva una cuenta activa, un rol administrativo sin propietario, una pertenencia que no coincide con el puesto declarado o un permiso temporal cuya fecha ha vencido. Esas señales deben abrir una revisión prioritaria, no resolverla por sí mismas.
Diseñe decisiones simples y trazables
Una campaña eficaz ofrece un conjunto limitado de decisiones. En lugar de un botón genérico de “aprobar”, permita elegir entre mantener, reducir, retirar, transferir la revisión a otro responsable o declarar una excepción temporal. Cada elección debe guardar quién la tomó, cuándo, sobre qué permiso y con qué justificación cuando proceda.
| Situación observada | Decisión posible | Control necesario |
|---|---|---|
| El acceso sigue siendo necesario para la función actual | Mantener | Responsable identificado y nueva fecha de revisión |
| La persona necesita una parte del acceso, no el rol completo | Reducir | Rol alternativo aprobado y comprobación posterior |
| La tarea o el proyecto ya terminó | Retirar | Confirmación del sistema destino y ruta de reversión si falla |
| Existe una necesidad excepcional y limitada | Mantener temporalmente | Motivo, vencimiento, medidas compensatorias y revisor futuro |
| El revisor no conoce el caso | Reasignar o escalar | Propietario alternativo y plazo de resolución |
Evite mezclar la aprobación del acceso con la ejecución técnica. Quien certifica la necesidad no tiene por qué poder modificar permisos, y quien ejecuta el cambio debe poder demostrar que aplicó la decisión autorizada.
Automatice la preparación, no el juicio de acceso
La automatización aporta valor al reunir datos de directorio, aplicación, sistema de RR. HH. y catálogo de roles; agrupar permisos por persona o responsable; enviar recordatorios; registrar decisiones; y abrir tareas de retirada o escalado. Son pasos repetibles que reducen correos y hojas de cálculo.
La IA puede utilizarse para resumir la descripción de un rol, detectar que una justificación está incompleta, clasificar respuestas abiertas o preparar un informe de pendientes. Debe trabajar con datos mínimos, instrucciones acotadas y salida revisable. Las políticas de acceso, la clasificación de criticidad y la decisión final deben permanecer en reglas explícitas y en responsables humanos.
Ejemplo: revisión de permisos de aprobación en un ERP
Una empresa identifica usuarios con capacidad de aprobar solicitudes por encima de un umbral. El flujo reúne el rol concedido, el área actual, la fecha de última certificación y el propietario del centro de coste. Envía al responsable una ficha por usuario con las opciones de mantener, reducir o retirar. Si se selecciona retirar, crea una tarea para el equipo administrador y verifica que el rol ha desaparecido del ERP antes de cerrar el expediente. Si el responsable solicita mantenerlo por una sustitución temporal, exige una fecha de vencimiento y programa la siguiente revisión.
Gestione silencios, errores y casos que no encajan
Una campaña no termina cuando se envían los avisos. Defina qué ocurre si el responsable no responde, si ya no pertenece a la organización, si la aplicación no devuelve datos suficientes o si la retirada falla. Un silencio no equivale a una aprobación.
- Envíe recordatorios con un plazo conocido y escale al propietario de la aplicación o al responsable jerárquico.
- Trate los datos incompletos como una incidencia de calidad de inventario, con un dueño y una fecha objetivo.
- Para permisos críticos sin confirmación, aplique la política acordada: suspensión controlada, revisión urgente o extensión temporal documentada. No improvise durante la campaña.
- Si una retirada puede interrumpir una operación, pruebe primero el rol alternativo o planifique una ventana con el equipo afectado.
Conserve una ruta manual para aplicaciones sin API o para cambios que requieran presencia de un administrador. Automatizar la coordinación no obliga a automatizar cada clic.
Compruebe que la decisión se ejecutó de verdad
La evidencia de la campaña debe unir la decisión con el estado final. Tras una retirada o reducción, consulte el sistema de destino y registre el resultado, la fecha y el identificador de la tarea. Si se mantiene un acceso temporal, compruebe que el vencimiento se ha configurado realmente y que existe una revisión futura.
Un cuadro de mando útil no necesita medir decenas de indicadores. Puede empezar con permisos revisados dentro de plazo, decisiones sin responsable, retiradas pendientes de confirmar, excepciones vencidas y diferencias entre el inventario de identidad y el de aplicaciones. Revise una muestra de expedientes cerrados para detectar respuestas rutinarias, roles mal descritos o automatizaciones que cierran casos sin evidencia.
Límites y criterios para decidir si es el momento
Una recertificación no sustituye el diseño inicial de roles, la gestión de altas y bajas, la protección de datos ni una auditoría técnica de seguridad. Tampoco arregla por sí sola una aplicación que no puede exportar permisos o una organización sin propietarios de proceso.
Es un buen punto de partida cuando existen accesos sensibles distribuidos entre varias aplicaciones, cambios frecuentes de puesto, permisos temporales que se acumulan o dudas sobre quién aprobó un acceso. Si no hay catálogo de roles ni fuente de identidad fiable, comience por ordenar esos elementos en un sistema y un colectivo acotados. Amplíe el alcance solo cuando pueda demostrar que cada decisión llega al sistema destino y que las excepciones tienen vencimiento.
Cómo avanzar con un piloto útil
Elija una aplicación de negocio, un tipo de permiso relevante y un grupo de responsables que conozcan el proceso. Defina qué datos componen la ficha, qué decisiones admite, quién ejecuta cada cambio y cómo se confirma. Haga primero una campaña en modo revisión: recopile decisiones sin cambiar permisos automáticamente y corrija los datos que generen dudas. Después conecte la ejecución para los casos de bajo riesgo y mantenga la aprobación humana en las acciones sensibles.
En KMOOPS ayudamos a diseñar procesos de control, automatización e integración que se puedan explicar y operar. Si quiere revisar el alcance de una recertificación o un piloto sobre sus aplicaciones de negocio, contacte con el equipo.