Capítulo 12 — Control de acceso e identidad

Duodécima entrega del recorrido capítulo por capítulo de LLM Primer VII: Seguridad de la IA. El capítulo que responde a la pregunta composicional — quién tiene permiso para invocar qué capacidad de una aplicación integrada con LLM, y cómo se estructura la aplicación a lo largo de los componentes del sistema.

Por qué existe este capítulo

Las disciplinas tradicionales de control de acceso se aplican todas a los sistemas LLM: autenticar el principal, autorizar sus peticiones contra política, aislar inquilinos, acotar consumo por principal, exponer capas de gobernanza empresarial. Los mecanismos son los que el campo lleva décadas usando — OAuth 2.0, mTLS, RBAC, ABAC, token buckets, SAML, SCIM. Lo nuevo es que la llamada al modelo en sí puede convertirse en un principal — un agente actuando en nombre de un usuario porta su propia identidad y sus propios permisos — y que la configuración por inquilino del comportamiento del modelo es una funcionalidad de producto de primera clase para plataformas LLM multi-tenant.

En una línea: el control de acceso en sistemas LLM es la disciplina tradicional más una añadidura — el modelo, cuando actúa a través de herramientas, es a su vez un principal cuyos permisos deben acotarse lo bastante como para que un prompt comprometido no pueda canjearlos.

12.1 La autenticación y la autorización se transfieren, con añadiduras

La autenticación verifica la credencial. Las claves de API son el mecanismo más simple — una cadena de alta entropía entregada al principal en el aprovisionamiento, hasheada en la base de datos de credenciales, presentada en una cabecera en cada petición. Son fáciles de implementar y usar, y fáciles de filtrar a través de logs, salida de CI y repositorios commiteados. Los tokens bearer de OAuth 2.0 mejoran la situación con tokens de corta duración y restricción de scope; el borrador OAuth 2.1 consolida las mejores prácticas de seguridad de la última década. mTLS añade autenticación mutua para llamadas máquina a máquina, particularmente útil para servicios LLM internos. La autorización pregunta qué se permite hacer al principal autenticado. RBAC — roles, permisos, asignaciones — funciona cuando la población se divide en grupos estables. ABAC — control de acceso basado en atributos — evalúa predicados sobre atributos del principal, del recurso y del contexto, y maneja los casos que RBAC no: permisos que dependen del propietario del recurso, del momento o ubicación de la petición, o de las relaciones en el sistema. Los dos no son mutuamente excluyentes; los sistemas de producción a menudo los superponen, con RBAC para acceso grueso y ABAC para las condiciones específicas. Los motores de política del capítulo 10 — OPA, Cedar — son cómo el ABAC se vuelve mantenible a escala.

12.2 El aislamiento multi-tenant es una cuestión de defensa en profundidad

Un sistema multi-tenant sirve a varios clientes desde un solo despliegue. El requisito de aislamiento es que ningún inquilino pueda ver los datos, peticiones o interacciones con el modelo de ningún otro inquilino bajo ningún modo de fallo. Tres enfoques arquitectónicos se sitúan en un espectro. El aislamiento a nivel de base de datos — base de datos separada por inquilino — es el más fuerte pero el más caro de operar. El aislamiento a nivel de esquema — esquema PostgreSQL o base de datos MySQL separada por inquilino sobre infraestructura compartida — es un punto intermedio. El aislamiento a nivel de fila — esquema compartido, tenant ID en cada fila, seguridad a nivel de fila impuesta por la base de datos — es el más barato pero requiere código de aplicación disciplinado. Para sistemas LLM el aislamiento se extiende al corpus de recuperación (namespaces de base de datos vectorial por inquilino), a la lógica de construcción de prompts (sin concatenación cruzada entre inquilinos), al store de logs (sin lecturas cruzadas entre inquilinos) y al modelo mismo cuando se ajusta finamente con datos específicos de inquilino. Los límites de tasa y las cuotas añaden el eje de consumo de recursos. El token bucket permite ráfagas cortas hasta una capacidad definida; la ventana deslizante impone una tasa más uniforme con coste computacional más alto; el leaky bucket suaviza la tasa aguas abajo. Para sistemas LLM la dimensión del límite de tasa se expande: peticiones por segundo, tokens por minuto, coste por día, invocaciones de herramientas por hora, embeddings por segundo. Cada dimensión tiene su propia justificación económica y de seguridad, y los planes empresariales típicamente discriminan a lo largo de varias.

12.3 La gobernanza empresarial es la capa que hace usable el sistema

Los clientes empresariales tienen requisitos de gobernanza más allá de la autenticación y el límite de tasa. Necesitan saber qué empleados usan el sistema, sobre qué datos, con qué propósitos. Necesitan logs de auditoría suficientes para el cumplimiento interno y la auditoría externa. Necesitan controles sobre qué modelos se permiten, qué herramientas están disponibles, qué categorías de contenido se permiten. Necesitan compromisos de manejo de datos — uso para entrenamiento, cifrado, residencia, retención, borrado. Las funcionalidades que se han vuelto estándar reflejan estos requisitos. El single sign-on vía SAML u OpenID Connect hace del proveedor de identidad empresarial la fuente de verdad sobre quién puede usar el sistema. El aprovisionamiento SCIM propaga automáticamente los cambios de usuario. La exportación de logs de auditoría envía la telemetría del sistema LLM al SIEM empresarial. Los compromisos de residencia de datos garantizan que los datos de un inquilino no salgan de una jurisdicción especificada. Las claves de cifrado gestionadas por el cliente permiten a la empresa rotar o revocar de forma independiente al proveedor. Las opciones de despliegue privado mueven el servicio LLM a la propia cuenta de nube de la empresa. Cada una de estas funcionalidades es una superficie de gobernanza que hay que operar, no solo implementar; la capa de gobernanza empresarial es lo que convierte una plataforma LLM multi-tenant en algo que una industria regulada puede adoptar.

Vale la pena recordar: cada herramienta que el modelo pueda invocar debería autorizarse como si el usuario la hubiera invocado directamente — con la identidad del llamador, en el inquilino del llamador, sujeta a los límites de tasa del llamador. Cualquier otra cosa concede al modelo autoridad más allá del principal para el que actúa, que es el modo de fallo que la mayoría de las arquitecturas de agentes construyen accidentalmente.

Lo que prepara el Capítulo 12

La parte IV ha desarrollado las dimensiones a nivel de sistema de la seguridad LLM: fronteras arquitectónicas (cap. 10), observabilidad y respuesta a incidentes (cap. 11) e identidad y controles de acceso (cap. 12). El tratamiento ha empezado por el mecanismo y da una postura técnica defendible. El capítulo 13 abre la parte V moviéndose hacia fuera del núcleo técnico hacia el perímetro regulatorio. El Reglamento de IA de la UE, en pleno vigor desde agosto de 2026 para la mayoría de las categorías de alto riesgo, es el instrumento único más consecuente, pero la postura federal de EE. UU. (evolucionando tras la transición EO 14110 a EO 14179), las leyes a nivel estatal (Colorado, California, Nueva York y otras), el RGPD aplicado a la IA y los marcos emergentes en Singapur, Japón, Corea, India y otros hacen colectivamente que la superficie de cumplimiento sea plural en lugar de unificada. El capítulo examina qué exigen estas regulaciones en términos prácticos y cómo los controles de los capítulos 3, 10, 11 y 12 se mapean a esos requisitos.

Próximamente — Capítulo 13: Panorama regulatorio. La aplicabilidad por fases del Reglamento de IA de la UE, el RGPD frente a sistemas de IA, auditabilidad, model cards y los marcos de clasificación de riesgo que estructuran la arquitectura regulatoria.

¿Quieres el panorama completo? El capítulo del libro incluye configuraciones desarrolladas de OAuth y mTLS, la matriz completa de decisión RBAC-frente-a-ABAC con ejemplos de producción, patrones de aislamiento de inquilinos entre capas de almacenamiento, y las cápsulas «In Plain English» que este artículo solo resume. Consulta LLM Primer VII en Amazon →