¿Qué es IAM?
Privacidad, seguridad e identidad
IAM significa Gestión de Identidades y Accesos (Identity and Access Management). Es la combinación de políticas, procesos, roles y controles técnicos que una organización utiliza para decidir quién o qué accede a sistemas, datos y acciones, cómo se autentica ese acceso, cómo se otorgan y revisan los permisos, y cómo se modifica o revoca el acceso con el tiempo. En el trabajo práctico habilitado por IA, IAM es la capa operativa que subyace al inicio de sesión, la búsqueda interna, los asistentes de conocimiento, las unidades compartidas, las aplicaciones en la nube, el acceso de administración y la auditabilidad. No es un producto único. Es la disciplina que convierte la identidad, los permisos y la responsabilidad en algo que la organización puede gestionar de forma coherente.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
Una forma sencilla de entender IAM es la siguiente: toda persona, cuenta de servicio, dispositivo y aplicación que interactúe con sistemas empresariales importantes debe tener una identidad conocida, una forma adecuada de iniciar sesión y únicamente los permisos necesarios para su función. Parece obvio, pero en muchas organizaciones pequeñas y medianas esto está repartido entre nóminas, recursos humanos, portátiles, software en la nube, documentos compartidos, sistemas financieros, herramientas de soporte y, ahora, funciones de IA. Sin un enfoque integrado, el acceso tiende a crecer de forma desordenada e invisible.
Por eso IAM importa más que los simples "inicios de sesión". Bien aplicado, cubre el ciclo de vida completo del acceso. Alguien se incorpora, obtiene las cuentas correctas, se autentica de forma controlada, recibe permisos acordes a su rol y queda registrado en los registros y revisiones. Cuando cambia de puesto, su acceso se actualiza. Cuando se va, se elimina con rapidez. La misma lógica se aplica a contratistas, cuentas de servicio, integraciones y administradores con privilegios. En otras palabras, IAM no consiste solo en dar acceso a las personas a los sistemas. Se trata de hacer que el acceso sea deliberado, limitado, revisable y reversible.
Por qué es importante
IAM cobra especial relevancia cuando el trabajo está habilitado por IA, porque la IA amplifica cualquier acceso que ya exista. Un asistente de búsqueda, una herramienta de tipo Copilot, una capa de recuperación, un chatbot interno o una función de resumen no crean buena gobernanza por arte de magia. Por lo general, exponen los datos y permisos que la organización ya tiene. Si el acceso es demasiado amplio, está desactualizado o se comprende mal, la IA puede hacer ese problema más rápido y más visible en lugar de resolverlo.
Esto tiene consecuencias prácticas. Si un miembro del equipo de finanzas puede buscar en carpetas de recursos humanos que nunca debería ver, una herramienta de búsqueda empresarial puede mostrar esos archivos en segundos. Si un antiguo responsable de proyecto sigue teniendo acceso a una sala de operaciones, un asistente de preguntas y respuestas puede resumirle ese material incluso después de que su necesidad operativa haya concluido. Si las cuentas de administrador con privilegios se usan de forma descuidada, un compromiso puede propagarse por la infraestructura de identidad y luego afectar a múltiples sistemas. IAM forma parte, por tanto, de la resiliencia operativa, no solo del mantenimiento rutinario.
También es relevante para los datos personales y la información comercialmente sensible. Las organizaciones del Reino Unido no necesitan convertir cada debate sobre accesos en asesoramiento jurídico, pero sí deben reconocer que un control de acceso deficiente puede derivar en divulgaciones no autorizadas, tratamientos inadecuados y decisiones difíciles ante una brecha. Por eso las revisiones de acceso, el principio de mínimo privilegio, el registro de actividad y la gestión del ciclo de vida son cuestiones de gobernanza tanto como técnicas.
En la práctica, IAM es el paraguas bajo el que se sitúan o conectan otros controles habituales. SSO gestiona el patrón de inicio de sesión. RBAC y ABAC configuran las decisiones de autorización. La gestión de accesos privilegiados acota y supervisa la administración de alto riesgo. DLP ayuda a gestionar el movimiento arriesgado de información sensible. Ninguno de esos controles reemplaza a IAM, porque IAM es el modelo operativo que los conecta.
Cómo funciona
IAM funciona vinculando cinco elementos que con frecuencia se gestionan por separado.
En primer lugar, establece identidades. Esto incluye usuarios humanos, contratistas, administradores, cuentas de servicio, APIs, flujos de trabajo y, en ocasiones, dispositivos. La organización necesita saber qué es cada identidad, quién la gestiona, cómo se crea y qué evidencia respalda la confianza en ella.
En segundo lugar, gestiona la autenticación. Esto implica decidir cómo las identidades demuestran que son genuinas. En una configuración moderna, esto suele significar un proveedor de identidad centralizado, métodos de autenticación robustos, autenticación multifactor cuando corresponda y un control coherente sobre los eventos de inicio de sesión. SSO suele ubicarse aquí, pero SSO es solo un patrón dentro del diseño más amplio.
En tercer lugar, IAM gestiona la autorización. Una vez que alguien se ha autenticado, la organización aún debe decidir qué puede hacer. Aquí es donde entran en juego los roles, grupos, atributos, derechos, flujos de aprobación y la separación de funciones. Algunas organizaciones utilizan principalmente RBAC porque es más fácil de administrar. Otras añaden condiciones de tipo ABAC para decisiones más dinámicas. El principio debe mantenerse igual: derechos mínimos para un propósito claro.
En cuarto lugar, IAM gestiona el ciclo de vida. Las incorporaciones, los cambios de puesto y las bajas no son un cliché de recursos humanos; son el origen de muchos fallos de acceso. Un buen enfoque de IAM trata el cambio de acceso como un proceso empresarial normal. Los nuevos empleados obtienen lo que necesitan, quienes cambian de rol pierden lo que ya no corresponde, las bajas se desconectan con prontitud y los accesos temporales caducan en lugar de prolongarse indefinidamente.
En quinto lugar, IAM incorpora revisión y monitorización. Los permisos no deben simplemente otorgarse y olvidarse. Los responsables, propietarios de sistemas y operadores necesitan revisiones periódicas de acceso, visibilidad sobre la actividad privilegiada y una forma de investigar comportamientos inusuales. Esto cobra mayor importancia cuando las herramientas de IA se basan en datos internos, porque los permisos débiles se convierten en límites débiles para la IA.
Una prueba útil es si una organización puede responder rápidamente a preguntas básicas. ¿Quién puede acceder a los datos de nóminas? ¿Qué contratistas siguen teniendo cuentas activas? ¿Qué cuentas de servicio pueden leer la base de conocimiento utilizada por un asistente interno? ¿Qué cuentas de administrador global existen y cuándo se usaron por última vez? Si esas respuestas son lentas, disputadas o manuales cada vez, IAM probablemente está poco desarrollado.
Dónde aparece en flujos de trabajo reales
Consideremos un ejemplo práctico de una empresa de consultoría en crecimiento. Un nuevo responsable de operaciones se incorpora y necesita acceso al CRM, al espacio de trabajo de proyectos, a las plantillas de contratos, a determinados informes financieros y al asistente de IA interno que responde preguntas a partir de documentos de política. Con un modelo IAM adecuado, esos accesos se aprueban mediante un perfil de rol estándar, se añaden a través de la plataforma de identidad y quedan registrados. El asistente solo ve las mismas colecciones de documentos que el usuario está autorizado a consultar. Cuando esa persona pasa posteriormente a un rol comercial, su acceso operativo se reduce y se añade su acceso comercial. No acumula ambos sin más.
Tomemos ahora un segundo ejemplo. Una empresa lanza un sistema interno de recuperación de información sobre SharePoint, una wiki y documentación de soporte. El personal lo valora porque responde preguntas con rapidez. Entonces la organización se da cuenta de que carpetas antiguas de proyectos, borradores de actas del consejo y notas disciplinarias archivadas son accesibles para personas que no deberían verlas. El problema de fondo no es el chatbot. Es el modelo de acceso subyacente. El trabajo de IAM aquí implica limpiar permisos, restringir grupos, revisar accesos heredados, eliminar cuentas obsoletas y verificar que la capa de recuperación respeta esas reglas.
Un tercer ejemplo tiene que ver con el acceso privilegiado. Una pequeña empresa de software permite a sus ingenieros senior usar derechos de administrador amplios en el entorno cloud porque resulta cómodo. Eso funciona hasta que la cuenta de un ingeniero queda comprometida mediante un ataque de phishing. De repente, el atacante tiene acceso a la configuración de identidad, los registros y los ajustes de producción. Una mayor madurez en IAM reduciría este radio de impacto separando las identidades de administración, usando autenticación más robusta, acotando los derechos, limitando temporalmente el acceso de alto riesgo y revisando la actividad privilegiada.
Estos son flujos de trabajo empresariales ordinarios, no casos extremos. Ese es precisamente el punto. IAM es valioso porque mejora el trabajo cotidiano al tiempo que reduce la probabilidad de que la comodidad se convierta silenciosamente en exposición.
Malentendidos frecuentes
Un malentendido habitual es creer que IAM significa adquirir una nueva plataforma. Las plataformas importan, pero IAM tiene que ver principalmente con la calidad de las decisiones y la disciplina operativa. Un directorio o herramienta de identidad reluciente no puede solucionar la falta de claridad en la titularidad de los permisos, los procesos débiles de incorporación y baja, ni la ausencia de revisiones periódicas.
Otro malentendido es que IAM es solo para grandes empresas. Las organizaciones más pequeñas suelen pensar que son demasiado pequeñas para una gobernanza formal de accesos, y luego descubren que tienen decenas de aplicaciones SaaS, espacios compartidos no gestionados, cuentas de contratistas, credenciales de servicio y funciones de IA que extraen contenido interno. La complejidad llega antes de lo que la mayoría de los equipos espera.
Un tercer malentendido es que la autenticación equivale al control. No es así. Gestionar bien el inicio de sesión es necesario, pero no responde a qué puede ver, modificar, exportar o administrar alguien una vez dentro de un sistema. Un usuario puede estar fuertemente autenticado y aun así tener los permisos incorrectos.
También es fácil asumir que, una vez implantado SSO, el acceso está gobernado. Tampoco es del todo cierto. SSO puede centralizar la autenticación y simplificar el inicio de sesión, pero los permisos dentro de cada aplicación siguen necesitando un diseño adecuado. Lo mismo ocurre con DLP. Bloquear ciertos comportamientos de uso compartido arriesgado es útil, pero no reemplaza unos derechos limpios, una buena clasificación ni el diseño de roles.
Por último, algunos equipos tratan la revisión de accesos como papeleo anual. Eso pasa por alto el propósito operativo. La revisión no existe para cumplimentar un formulario. Existe para detectar accesos obsoletos, acumulación de privilegios, derechos de administración duplicados, contratistas olvidados y membresías antiguas en proyectos antes de que se conviertan en incidentes.
Riesgos y límites
Un IAM deficiente tiene dos tipos de costes. El primero es el riesgo de seguridad: demasiado acceso, derechos de administración mal protegidos, control débil de cuentas de servicio y una revocación lenta aumentan la probabilidad y el impacto de un compromiso. El segundo es la fricción operativa: el personal no puede obtener el acceso correcto con rapidez, nadie confía en los límites de permisos y cada cambio se convierte en un caos de tickets o en una excepción.
También existen límites en lo que IAM puede hacer. No puede solucionar por sí solo una arquitectura de información deficiente. Si los equipos almacenan material sensible y rutinario juntos en los mismos espacios, incluso unos buenos controles de identidad se vuelven más difíciles de aplicar. IAM tampoco puede reemplazar la clasificación de datos, la respuesta a incidentes, los controles contractuales con proveedores ni la formación del personal. Debe conectarse con esas actividades, no sustituirlas.
En el trabajo habilitado por IA, otro límite es relevante: la herencia de permisos no equivale al juicio. Un sistema puede respetar correctamente los derechos de un usuario y aun así exponer demasiada información contextual porque las estructuras de documentos, las etiquetas o los grupos de acceso estaban mal diseñados. Por eso los líderes deben ser cautelosos ante promesas amplias como "nuestra IA solo muestra lo que las personas ya tienen acceso a ver". A veces ese es exactamente el problema.
El riesgo final es la concentración. Cuando la identidad está centralizada, los fallos de identidad importan más. Una cuenta de administrador mal protegida, una política mal configurada o una interrupción del proveedor de identidad pueden afectar a muchos servicios conectados a la vez. Eso no es un argumento en contra de IAM. Es un argumento para proteger los sistemas de identidad como infraestructura crítica, mantener el acceso de emergencia bajo un control estricto y tratar los cambios de identidad privilegiada como eventos de alto riesgo.
Qué deberían hacer los líderes a continuación
Los líderes deben empezar por tratar IAM como un modelo operativo, no como una partida de compras. Soliciten un mapa claro de identidades, aplicaciones principales, cuentas privilegiadas, rutas de aprobación y cadencia de revisión. Si nadie puede producir ese panorama, comiencen por ahí.
A continuación, concéntrense en algunas mejoras de alto valor. Refuercen el proceso de incorporaciones, cambios de puesto y bajas. Identifiquen los sistemas críticos y los repositorios de datos sensibles. Separen la actividad normal de los usuarios de la administración privilegiada. Reduzcan el acceso compartido amplio. Acorten los ciclos de revisión y hagan que sean más deliberados para los sistemas de alto riesgo. Comprueben a qué pueden acceder realmente la IA interna, la búsqueda empresarial y las herramientas basadas en conectores, no lo que asumen que pueden acceder.
Después, decidan dónde encajan los controles de apoyo. SSO puede reducir la proliferación de contraseñas. RBAC puede estabilizar los permisos cotidianos. ABAC puede ayudar cuando el contexto importa. DLP puede contribuir a reducir el movimiento descuidado o inadecuado de datos. Pero la tarea del liderazgo es mantener estas decisiones vinculadas al proceso empresarial, la titularidad y la responsabilidad.
Bien ejecutado, IAM no es glamuroso. Es una forma más tranquila y fiable de gestionar el acceso en una organización que hoy depende de sistemas en la nube y funciones de IA cada día.
¿Tiene alguna pregunta o sugerencia, o desea saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Es IAM lo mismo que SSO?
No. SSO es un patrón de autenticación dentro de un enfoque IAM más amplio. Puede facilitar y hacer más coherente el inicio de sesión mediante un proveedor de identidad centralizado, pero IAM también abarca identidades, permisos, diseño de roles, revisiones, incorporaciones y bajas, acceso privilegiado y monitorización. Una organización puede tener SSO y aun así tener un IAM deficiente si los usuarios mantienen accesos excesivos u obsoletos dentro de las aplicaciones conectadas.
¿Por qué es importante IAM antes de desplegar asistentes de IA o búsqueda empresarial?
Porque esas herramientas suelen heredar o depender de las estructuras de identidad y permisos existentes. Si los recursos compartidos, grupos y derechos de aplicación están desordenados, la IA puede exponer ese desorden con mayor rapidez. Antes de un despliegue amplio, compruebe a qué fuentes de datos puede acceder la herramienta, cómo se aplican los permisos, si los grupos antiguos siguen existiendo y cómo se gestionan los cambios de acceso cuando el personal cambia de equipo o se va.
¿Cuál es la señal más rápida de que nuestro IAM es débil?
Una señal de alerta clara es cuando nadie puede responder con confianza a preguntas básicas sobre accesos sin buscar manualmente. Si no puede identificar rápidamente quién tiene acceso a sistemas sensibles, qué cuentas de administrador están activas, qué contratistas siguen existiendo o si los derechos de un exempleado se eliminaron en todos los sistemas, su problema de IAM es operativo, no cosmético. Ese es habitualmente el punto de partida para una mejora significativa.
Fuentes
National Cyber Security Centre: Introduction to identity and access management - Core definition of IAM as policies, processes and systems; broad IAM areas including policy, identity management, privileged user management, architecture, operations and monitoring.
National Cyber Security Centre: Principle B2 Identity and Access Control - Minimum required access rights, joiners/movers/leavers review expectations, logging and monitoring of access, and privileged user management expectations.
National Cyber Security Centre: Identity and access management - Practical joiners, movers and leavers policy expectations and revocation of access for staff and third parties.
National Institute of Standards and Technology: The NIST Cybersecurity Framework (CSF) 2.0 - Identity management, authentication, access control, least privilege, separation of duties, and protection of data at rest, in transit and in use.
National Cyber Security Centre: Using a cloud platform securely - SSO use, MFA, integration with joiners/movers/leavers, and keeping powerful emergency accounts for rare emergency access only.
National Cyber Security Centre: Use privileged access management - Relationship between IAM and privileged access management, just enough administration, least privilege and protected break-glass processes.