Zero Trust para sistemas de IA: por qué los mismos principios aplican — y dónde fallan
Zero-trust es uno de los marcos más consolidados en la seguridad empresarial. Sus principios — nunca confíes, verifica siempre, asume que hay una brecha, aplica el mínimo privilegio — están bien entendidos, implementados y profundamente integrados en la manera en la que los equipos de seguridad piensan el control de acceso.
El problema es que zero-trust se creó pensando en un modelo de actor específico: usuarios humanos con identidades estables, patrones de comportamiento predecibles y límites de sesión claramente definidos. Los sistemas de IA no cumplen con ninguna de estas características. Actúan en nombre de los usuarios sin ser usuarios. Su comportamiento es semánticamente complejo y operacionalmente opaco. Pueden ejecutar miles de operaciones de datos en el tiempo que una persona realiza una sola.
Este artículo es para CISOs y arquitectos de seguridad que necesitan ampliar la arquitectura zero-trust a actores de IA — y que deben entender dónde sus marcos actuales funcionarán y dónde no.
Resumen Ejecutivo
Idea principal: Los principios zero-trust que rigen el acceso humano a los datos empresariales se aplican igualmente a los sistemas de IA — pero los mecanismos que implementan esos principios para actores humanos no se trasladan directamente. Los actores de IA requieren controles diseñados específicamente para abordar sus características únicas de identidad, comportamiento y operación.
Por qué te debe importar: Los equipos de seguridad que aplican marcos zero-trust pensados para humanos a sistemas de IA sin adaptarlos están creando una brecha de gobernanza que no pueden ver. Los controles parecen correctos en papel — existe autenticación, las políticas de acceso están definidas, el registro está configurado — pero no se aplican de la forma que requieren las características operativas de la IA. El resultado es una postura zero-trust que es técnicamente correcta pero insuficiente en la práctica.
5 ideas clave
- Los principios zero-trust aplican a los sistemas de IA sin modificación — nunca confíes, verifica siempre, asume brecha, aplica el mínimo privilegio. Lo que requiere modificación es la implementación: los controles diseñados para humanos no resuelven el modelo de identidad, el comportamiento ni la escala operativa de la IA.
- La identidad de la IA es fundamentalmente diferente de la identidad humana. Un sistema de IA no tiene un ancla de identidad estable — actúa en nombre de usuarios, es vulnerable a la inyección de prompts que puede alterar su intención aparente y normalmente opera bajo cuentas de servicio que ocultan quién dirige realmente sus acciones.
- La autenticación a nivel de sesión — el enfoque por defecto en la mayoría de integraciones de IA — viola el requisito de verificación continua de zero-trust. La autorización por solicitud, aplicada mediante RBAC y ABAC en la capa de datos, es el único patrón de implementación que realmente cumple el «nunca confíes» para actores de IA.
- El radio de impacto de un sistema de IA comprometido es mucho mayor que el de una cuenta de usuario comprometida. Un sistema de IA con acceso amplio a datos y sin limitación de velocidad puede exfiltrar información a una escala y velocidad que hace que la respuesta a incidentes sea reactiva en vez de preventiva. La arquitectura de asume-brecha para IA requiere limitación de velocidad y controles de alcance que no tienen equivalente en zero-trust para humanos.
- Los registros auditables de operaciones de IA requieren doble atribución — la identidad del sistema de IA y el usuario humano en cuyo nombre actuó — para cumplir con los marcos de cumplimiento. Los registros que solo muestran las acciones del sistema de IA son incompletos tanto a nivel forense como regulatorio.
Por qué Zero-Trust es el marco adecuado — y por qué debe ampliarse
Zero-trust surgió como respuesta al fracaso de la seguridad perimetral: el reconocimiento de que, una vez que un actor está dentro de la red, los controles tradicionales otorgan demasiada confianza implícita. La respuesta fue tratar cada solicitud de acceso como potencialmente hostil, sin importar la ubicación en la red, y verificar la identidad, aplicar el mínimo privilegio y auditar cada operación de forma continua. Estos principios son correctos para actores de IA. Un sistema de IA que se ha autenticado en un repositorio de datos no debe recibir confianza implícita durante toda la sesión. Sus solicitudes deben evaluarse según la política. Sus operaciones deben registrarse. Su acceso debe estar limitado por los permisos del humano que lo dirige.
La ampliación necesaria no es de los principios, sino de los supuestos de implementación. Los marcos zero-trust asumen que el actor tiene una identidad estable y verificable — una cuenta de usuario, un certificado, un token físico. Suponen que los límites de sesión se corresponden razonablemente con los límites de autorización. Suponen que el «comportamiento normal» es reconocible y que las desviaciones son detectables. Los sistemas de IA rompen estas tres suposiciones, y los controles construidos sobre ellas deben rediseñarse para un modelo de actor que es fundamentalmente diferente.
El problema de la identidad: los sistemas de IA no tienen identidades estables
Zero-trust para humanos se basa en la verificación de identidad: autenticar al usuario, establecer su identidad y usar esa identidad como ancla para las decisiones de autorización. Esto funciona porque las identidades humanas son estables — una cuenta de usuario corresponde a una persona específica con roles y derechos de acceso concretos, verificados mediante MFA y sistemas IAM. Los sistemas de IA no tienen un ancla de identidad equivalente.
La «identidad» de un sistema de IA en la mayoría de implementaciones empresariales es una cuenta de servicio — una credencial compartida que representa la plataforma de IA, no al usuario específico que dirige las acciones de la IA. Esto genera dos problemas de gobernanza. Primero, la cuenta de servicio oculta quién es realmente responsable del acceso a los datos: cuando una IA recupera un documento, el registro de auditoría muestra la cuenta de servicio, no el empleado que hizo la consulta. Segundo, la cuenta de servicio normalmente tiene permisos que superan los que se concederían a cualquier usuario individual — porque se configuró para permitir que la IA trabaje para cualquier usuario, debe tener acceso a todo lo que cualquier usuario podría necesitar legítimamente.
El problema de identidad más profundo es la inyección de prompts. El comportamiento de una IA está determinado por su entrada — y esa entrada puede ser manipulada. Un ataque de inyección de prompts inserta instrucciones en los datos que la IA procesa, redirigiendo su comportamiento de formas que pueden eludir controles de gobernanza, extraer credenciales o acceder a datos fuera del alcance previsto. A diferencia de un usuario humano cuya identidad permanece estable sin importar lo que lea, la «identidad» efectiva de una IA — lo que hará a continuación — puede ser alterada por el contenido en su ventana de contexto. La verificación de identidad tradicional no tiene mecanismo para abordar esto. La protección de datos zero-trust para IA exige que las credenciales se almacenen fuera del contexto de la IA, en el llavero del sistema operativo, donde no puedan ser alcanzadas mediante manipulación de prompts.
El problema del límite de sesión: ¿cuándo «continuo» significa por solicitud?
El requisito de verificación continua de zero-trust suele implementarse mediante la gestión de sesiones: reautenticación tras inactividad, autenticación escalonada basada en riesgos y detección de anomalías en el comportamiento del usuario durante la sesión. Para actores humanos, esto es razonable — una sesión representa un periodo acotado de actividad intencionada, y la reautenticación en los límites de sesión aporta verificación significativa.
Las sesiones de IA no funcionan así. Un agente de IA operando en nombre de un usuario puede mantener una conexión persistente a sistemas de datos empresariales durante horas, ejecutando miles de operaciones individuales en una sola sesión. La autenticación a nivel de sesión significa que la IA fue verificada una vez, al inicio — pero cada operación posterior dentro de esa sesión hereda esa autorización inicial sin verificación independiente. Para un usuario humano navegando un sistema de archivos, esto es tolerable. Para un sistema de IA que puede ejecutar mil operaciones de recuperación por minuto, la autorización a nivel de sesión no es verificación continua — es un único punto de control seguido de acceso sin supervisión a velocidad de máquina.
La verdadera verificación continua para IA requiere autorización por solicitud: cada operación individual — cada acceso a archivo, cada consulta de recuperación, cada navegación de carpeta — evaluada contra políticas RBAC y ABAC en el momento en que se solicita. Esto no es solo una buena práctica — es la única implementación de «nunca confíes, verifica siempre» que se sostiene al ritmo operativo real de la IA. La autorización a nivel de sesión es una sola verificación seguida de confianza extendida. Eso no es zero-trust; es un modelo perimetral con un perímetro más corto.
Principios Zero-Trust: actores humanos vs. actores de IA
| Principio Zero-Trust | Cómo funciona para actores humanos | Dónde falla para actores de IA |
|---|---|---|
| Verificar identidad | Identidad del usuario verificada mediante MFA, SSO, certificados al iniciar sesión | La identidad del sistema de IA es una construcción en tiempo de ejecución — sin ancla de identidad estable; la inyección de prompts puede suplantar; las cuentas de servicio no reflejan quién actúa realmente |
| Aplicar mínimo privilegio | RBAC/ABAC limita lo que los usuarios autenticados pueden acceder según rol y atributo | Los sistemas de IA suelen operar bajo cuentas de servicio sobreprivilegiadas; el mínimo privilegio requiere aplicación por solicitud y por usuario — no solo autorización a nivel de sesión |
| Asumir brecha | Segmentar redes; limitar movimiento lateral; monitorear comportamiento anómalo | Un sistema de IA comprometido puede ejecutar miles de solicitudes de datos antes de ser detectado; el radio de impacto sin limitación de velocidad y aplicación de políticas por solicitud es enorme |
| Inspeccionar todo el tráfico | Inspección TLS; escaneo DLP; filtrado de contenido en datos en tránsito | El tráfico de IA es semánticamente opaco — las consultas en lenguaje natural no se ajustan a patrones DLP tradicionales; la inspección debe hacerse en la capa de recuperación de datos, no en la red |
| Verificación continua | Reautenticación de sesión; acceso basado en riesgos; detección de anomalías en el comportamiento del usuario | Las sesiones de IA pueden persistir indefinidamente; el «comportamiento normal» de la IA es muy variable; la verificación continua requiere evaluación de políticas por operación, no reautenticación periódica |
| Auditar todo | Registros de acceso del usuario con identidad, recurso, marca de tiempo, acción | Los registros de acceso de IA deben atribuir cada operación tanto al sistema de IA como al usuario humano en cuyo nombre actuó — sin esta doble atribución, los registros son incompletos para cumplimiento |
El problema del radio de impacto: por qué «asume brecha» significa algo diferente para IA
La arquitectura de asume-brecha para humanos se centra en contener el movimiento lateral: segmentación de red, acceso de mínimo privilegio y detección de anomalías para detener a un usuario comprometido antes de que pueda pivotar a otros sistemas. El radio de impacto de una cuenta humana comprometida, aunque grave, está limitado por el ritmo operativo humano — una persona solo puede acceder a cierta cantidad de datos en cierto tiempo.
Un sistema de IA comprometido opera en una escala totalmente diferente. Un agente de IA con acceso amplio a repositorios y sin limitación de velocidad puede recuperar cientos de miles de documentos en el tiempo que un analista de seguridad tarda en reconocer una alerta de SIEM. Los controles de asume-brecha que funcionan para humanos — detección de anomalías, cierre de sesión, segmentación de red — son en gran parte reactivos al ritmo de operación de la IA. Cuando se detecta una anomalía y se cierra la sesión, los datos ya se han movido.
Asume-brecha para IA requiere limitación proactiva del radio de impacto que no existe en los marcos zero-trust para humanos. La limitación de velocidad en las solicitudes de datos de IA — aplicada en la capa de datos, no en la aplicación — limita el volumen de datos que un sistema de IA puede recuperar sin importar sus instrucciones. Los controles de ruta y alcance impiden que la IA navegue fuera del dominio de datos previsto. Estos controles no detectan el compromiso después del hecho; limitan el daño que un compromiso puede causar antes de ser detectado. Es una filosofía de control fundamentalmente diferente a la de asume-brecha para humanos, y requiere arquitectura diseñada específicamente, no solo adaptación de controles de administración de riesgos de seguridad existentes.
El problema de la auditoría: ¿quién es responsable cuando una IA accede a los datos?
Los requisitos de auditoría zero-trust para humanos están bien establecidos: registrar la identidad del usuario, el recurso accedido, la marca de tiempo y la acción realizada. Esto produce una trazabilidad que cumple con los requisitos de cumplimiento de la ley HIPAA, GDPR, SOX y FedRAMP porque el registro responde a la pregunta de responsabilidad: una persona específica accedió a un recurso específico y es responsable de ese acceso.
Los registros de acceso de IA en la mayoría de implementaciones empresariales solo registran la identidad del sistema de IA — la cuenta de servicio — y nada más. Cuando una IA recupera un documento confidencial, el registro muestra que la cuenta de servicio de la plataforma de IA accedió al archivo. No muestra qué empleado realizó la consulta, qué preguntó ni qué se hizo con el resultado. Esta no es una brecha menor de atribución. Para la ley HIPAA, que exige registros que identifiquen a la persona responsable del acceso a información de salud protegida, una entrada de cuenta de servicio no cumple el requisito mínimo. Para GDPR, que exige la capacidad de demostrar la base legal de cada acceso a datos, un registro que no puede identificar al solicitante humano no puede establecer esa base.
Los registros de auditoría de IA requieren doble atribución: la identidad del sistema de IA y el usuario humano autenticado en cuyo nombre actuó la IA, combinados en una sola entrada por cada operación. Esto no es técnicamente complejo — requiere que el sistema de IA transmita la identidad del usuario a la capa de datos en el momento de la solicitud, y que la capa de datos registre ambas identidades juntas. Pero requiere un diseño arquitectónico deliberado. La mayoría de las integraciones de IA no lo implementan, y la mayoría de los marcos de auditoría zero-trust no lo exigen.
Controles zero-trust de Kiteworks para IA: implementación e impacto
| Control Zero-Trust | Cómo lo implementa Kiteworks para IA | Qué previene |
|---|---|---|
| Aislamiento de credenciales | OAuth 2.0 con PKCE; los tokens se almacenan en el llavero del sistema operativo, nunca en la ventana de contexto de la IA ni en archivos de configuración | Elimina el robo de credenciales por inyección de prompts; los tokens son inaccesibles para el modelo de IA bajo cualquier circunstancia |
| Autorización por solicitud | Las políticas RBAC y ABAC se evalúan en cada operación individual de IA — acceso a archivos, navegación de carpetas, consulta de recuperación | La IA no puede acumular acceso dentro de una sesión; cada solicitud se autoriza de forma independiente según la política vigente |
| Registro de auditoría con doble atribución | Cada operación de IA se registra con la identidad del sistema de IA Y la identidad del usuario autenticado, datos accedidos, marca de tiempo, acción, resultado | Cumple los requisitos de atribución de HIPAA, GDPR, SOX y FedRAMP; permite la investigación forense de incidentes que involucren IA |
| Limitación de velocidad | Límites de solicitudes por usuario y por sesión aplicados en la capa de datos, independientemente del comportamiento de la IA | Limita el radio de impacto de la extracción masiva; un volumen anómalo de recuperaciones activa controles antes de que los datos salgan de la organización |
| Controles de ruta y alcance | Restricciones absolutas de ruta; prevención de recorrido de rutas; lista blanca de operaciones aplicada por defecto | La IA no puede navegar fuera del alcance de datos previsto sin importar cómo se construyan o manipulen los prompts |
| Integración SIEM en tiempo real | Todas las operaciones de IA se envían al SIEM sin lotes, limitaciones ni retrasos | Los equipos de seguridad detectan comportamientos anómalos de IA en tiempo real; sin brecha de detección entre la actividad de IA y la visibilidad de seguridad |
Cómo Kiteworks amplía zero-trust a cada solicitud de IA
Los equipos de seguridad que mejor gestionarán la adopción de IA no son los que la prohíben — son los que amplían su arquitectura de seguridad existente para cubrir a los actores de IA con el mismo rigor que aplican a los actores humanos. Esa ampliación requiere controles diseñados específicamente, porque los supuestos sobre actores humanos incrustados en los marcos de seguridad zero-trust existentes no aplican a los sistemas de IA. El modelo de identidad es diferente. El modelo de sesión es diferente. El radio de impacto es diferente. Los requisitos de auditoría son diferentes.
Un equipo de seguridad que comprende estas diferencias e implementa controles diseñados para ellas puede habilitar la adopción de IA con confianza. Quien aplica controles para humanos a la IA y da el tema por cerrado tiene una postura zero-trust que es técnicamente correcta pero insuficiente en la práctica.
Kiteworks implementa zero-trust para actores de IA en cada capa donde el modelo humano falla. Aislamiento de credenciales: los tokens OAuth 2.0 se almacenan en el llavero del sistema operativo, fuera de la ventana de contexto del modelo de IA, inaccesibles mediante inyección de prompts bajo cualquier circunstancia. Autorización por solicitud: el Motor de Políticas de Datos de Kiteworks evalúa las políticas RBAC y ABAC en cada operación individual de IA — no al establecer la sesión, sino en el momento en que se realiza cada solicitud. La IA hereda los permisos del usuario que solicita y no puede superarlos en ninguna acción individual, sin importar el estado de la sesión.
El registro de auditoría con doble atribución registra tanto la identidad del sistema de IA como la del usuario humano autenticado en cada operación, alimentando el registro de auditoría de Kiteworks e integrándose con SIEM en tiempo real — sin lotes, sin retrasos, sin brecha de detección. La limitación de velocidad y los controles de ruta aplican la arquitectura de asume-brecha en la capa de datos: un sistema de IA comprometido o mal configurado no puede exfiltrar datos a gran escala porque los controles están integrados en la arquitectura de la Red de Contenido Privado, y no dependen de que el sistema de IA se comporte como se espera.
Y como estos controles amplían el mismo marco de intercambio de datos zero-trust que rige el uso compartido seguro de archivos, MFT segura y correo electrónico seguro en toda la organización, no hay un programa de seguridad de IA separado que construir y mantener. La arquitectura zero-trust ya implementada se amplía a la IA — no se reconstruye para ella.
Para CISOs y arquitectos de seguridad listos para extender zero-trust a actores de IA con el mismo rigor que aplican a los humanos, Kiteworks ofrece los controles diseñados específicamente que lo hacen posible. Para ver la implementación en detalle, agenda una demo personalizada hoy mismo.
Preguntas frecuentes
La arquitectura zero-trust existente fue diseñada para actores humanos con identidades estables, límites de sesión predecibles y un ritmo operativo humano. Los sistemas de IA rompen estas tres suposiciones: operan bajo cuentas de servicio que ocultan la identidad humana, funcionan en sesiones extendidas a velocidad de máquina y pueden ser redirigidos mediante inyección de prompts de formas que ningún control para humanos anticipa. Los principios aplican; los mecanismos deben diseñarse específicamente para un modelo de actor que es fundamentalmente distinto de un usuario humano.
La inyección de prompts es un ataque en el que instrucciones maliciosas se insertan en el contenido que procesa la IA — un documento, una página web, un archivo recuperado — redirigiendo el comportamiento de la IA sin que el usuario lo sepa. En una integración de IA mal protegida, una IA con acceso a sus propias credenciales de autenticación puede ser instruida mediante inyección de prompts para revelar esas credenciales, permitiendo el acceso no autorizado a sistemas de datos. La protección de datos zero-trust para IA exige que las credenciales se almacenen en el llavero del sistema operativo — completamente fuera de la ventana de contexto de la IA — para que no puedan ser alcanzadas mediante manipulación de prompts, sin importar el contenido que procese la IA.
La autorización a nivel de sesión verifica el sistema de IA una vez al momento de la conexión y otorga acceso implícito durante toda la sesión. La autorización por solicitud evalúa las políticas RBAC y ABAC en cada operación individual de IA — cada acceso a archivo, cada consulta de recuperación, cada navegación de carpeta — en el momento en que se solicita. Para sistemas de IA que ejecutan miles de operaciones por sesión, la autorización a nivel de sesión es una sola verificación seguida de acceso sin supervisión. Solo la autorización por solicitud cumple el requisito zero-trust de nunca confiar y verificar siempre al ritmo operativo real de la IA.
Una cuenta humana comprometida está limitada por el ritmo operativo humano — una persona solo puede acceder a cierta cantidad de datos en cierto tiempo, y la detección de anomalías tiene tiempo de responder. Un sistema de IA comprometido con acceso amplio a repositorios y sin limitación de velocidad puede recuperar cientos de miles de documentos antes de que se reconozca una alerta de SIEM. La arquitectura de asume-brecha para IA requiere limitar proactivamente el radio de impacto — limitación de velocidad y controles de alcance aplicados en la capa de datos — no solo detección reactiva. Esta es una filosofía de control fundamentalmente diferente a la respuesta a incidentes para humanos porque la ventana de detección es demasiado estrecha para que los controles reactivos sean suficientes.
Doble atribución significa registrar tanto la identidad del sistema de IA como la del usuario humano autenticado en cuyo nombre actuó la IA — en la misma entrada de registro, para cada operación. La mayoría de los registros de auditoría de IA solo muestran la identidad de la cuenta de servicio, lo que no identifica al solicitante humano. El cumplimiento de la ley HIPAA exige registros que identifiquen a la persona responsable de acceder a información de salud protegida. El cumplimiento de GDPR requiere la capacidad de demostrar la base legal de cada acceso a datos, lo que exige identificar al solicitante humano. Un registro que solo muestra «la cuenta de servicio de IA accedió al archivo» no cumple estos requisitos — la doble atribución es lo que cierra la brecha de responsabilidad.
Recursos adicionales
- Artículo del Blog
Estrategias Zero‑Trust para una protección asequible de la privacidad en IA - Artículo del Blog
Cómo el 77% de las organizaciones está fallando en la seguridad de datos de IA - eBook
Brecha de gobernanza en IA: por qué el 91% de las pequeñas empresas juega a la ruleta rusa con la seguridad de datos en 2025 - Artículo del Blog
No existe «–dangerously-skip-permissions» para tus datos - Artículo del Blog
Los reguladores ya no preguntan si tienes una política de IA. Quieren pruebas de que funciona.