Por qué las implementaciones RAG no superan la revisión de seguridad — y cómo crear una que sí lo haga
La demo funcionó. El piloto fue convincente. El caso de negocio era sólido. Y entonces comenzó la revisión de seguridad.
Para muchos equipos empresariales de IA, aquí es donde los proyectos de Generación Aumentada por Recuperación (RAG) se estancan — no porque la tecnología falle, sino porque la arquitectura que permitió una gran demo no es la que puede cumplir con los requisitos del equipo de seguridad para un sistema de acceso a datos en producción.
El patrón de fallo es tan consistente que resulta predecible: el equipo de IA construyó un sistema optimizado para la calidad de recuperación y la velocidad de desarrollo; el equipo de seguridad lo evaluó como un sistema que accede a datos empresariales sensibles a gran escala; las dos perspectivas llegaron a conclusiones diferentes sobre la preparación del sistema.
Este artículo es para VP de Ingeniería de IA/ML y CISOs que quieren entender el patrón, cerrar la brecha y llevar RAG a producción sin volver a empezar la revisión de seguridad.
Resumen Ejecutivo
Idea principal: Las implementaciones de RAG fallan la revisión de seguridad por seis razones predecibles, todas con la misma causa raíz: la capa de recuperación se trató como infraestructura en vez de como un sistema de acceso a datos gobernado. Los equipos de seguridad no bloquean RAG porque se opongan a la IA — lo bloquean porque el componente de recuperación tiene el perfil de acceso a datos de un sistema privilegiado y la postura de gobernanza de una herramienta de desarrollo. Resolver los seis modos de fallo requiere añadir una capa de gobernanza a la arquitectura de recuperación antes de la revisión de seguridad, no durante ella.
Por qué te debe importar: Cada ciclo que un proyecto RAG pasa en remediación de revisión de seguridad es un ciclo en el que no aporta valor al negocio. El coste no es solo el retraso — es la credibilidad del programa de IA ante los responsables de negocio que aprobaron la iniciativa, y la relación entre el equipo de IA y la función de seguridad que gobernará cada proyecto de IA posterior. Construir RAG correctamente desde el principio no es solo una cuestión de cumplimiento; es la forma en que los equipos de IA establecen la confianza que permite que los proyectos futuros avancen más rápido.
5 conclusiones clave
- Los equipos de seguridad evalúan los pipelines de RAG como sistemas de acceso a datos, no como herramientas de IA. Los criterios de evaluación son los mismos que para cualquier sistema que accede a datos empresariales sensibles a gran escala: autenticación, controles de acceso, registros de auditoría, monitoreo y respuesta a incidentes. Los equipos de IA que presentan RAG como una aplicación de productividad están respondiendo preguntas que el equipo de seguridad no está haciendo.
- Los seis modos de fallo más comunes en la revisión de seguridad son todos arquitectónicos, no de configuración. No se resuelven añadiendo documentación o ajustando políticas. Requieren cambios en la arquitectura de autenticación, autorización de la capa de recuperación, infraestructura de registros y la integración de monitoreo — cambios que son mucho más fáciles de implementar antes de construir la capa de recuperación que después de tener un piloto.
- La brecha entre lo que pide seguridad y lo que construyen los equipos de IA no es un problema de comunicación — es un problema de prioridades. La calidad de recuperación, la experiencia del desarrollador y el tiempo hasta la demo se optimizan en la fase de construcción; los controles de acceso, los registros de auditoría y el monitoreo no. El resultado es un sistema que rinde bien en los aspectos que mide el equipo de IA y falla en los que mide el equipo de seguridad.
- La definición de autorización previa a la recuperación es la decisión arquitectónica que resuelve más preguntas de seguridad al mismo tiempo. Cuando la capa de recuperación aplica RBAC y ABAC por solicitud y limita la recuperación a lo que el usuario autenticado está autorizado a acceder, se cierra el modo de fallo de recuperación sobre-permisionada, se responde la pregunta sobre la aplicación de clasificación de datos y se cumple la prueba de equivalencia de autorización.
- Una capa de recuperación gobernada no es una limitación para RAG — es la diferencia entre un proyecto RAG que llega a producción y uno que queda atascado en la revisión de seguridad. El patrón de puerta de enlace de datos IA proporciona la capa de gobernanza como un componente desplegable en vez de un desarrollo a medida, permitiendo a los equipos de IA cumplir los requisitos de seguridad sin reconstruir la arquitectura de recuperación desde cero.
Por qué las revisiones de seguridad detienen los proyectos RAG: la desconexión estructural
La desconexión entre equipos de IA y equipos de seguridad en RAG es estructural, no interpersonal. Los equipos de IA construyen pipelines RAG usando frameworks — LangChain, LlamaIndex, Haystack — optimizados para la calidad de recuperación y la velocidad de desarrollo. Estos frameworks gestionan bien el indexado vectorial, el embedding, la búsqueda semántica y el ensamblaje de contexto. No gestionan la autorización por usuario, el registro por documento, la aplicación de etiquetas de sensibilidad ni la integración con SIEM — porque esos no son problemas de calidad de recuperación. Son problemas de gobernanza, y los frameworks fueron creados por personas que resolvían problemas de calidad de recuperación.
Cuando un equipo de seguridad revisa el sistema resultante, aplica el mismo marco de evaluación que a cualquier nuevo sistema de acceso a datos. Preguntan: ¿quién puede acceder a qué datos, cómo se controla ese acceso, cómo se registra, cómo se monitorea y qué ocurre si algo sale mal?
El pipeline RAG responde mal a estas preguntas no porque el equipo de IA sea descuidado, sino porque el framework que usaron no genera buenas respuestas a estas preguntas por defecto. La cuenta de servicio existe porque era la forma más sencilla de hacer funcionar la recuperación. El registro a nivel de sesión existe porque era lo que proporcionaba el framework. La ausencia de aplicación de etiquetas de sensibilidad existe porque el framework no conoce las etiquetas MIP.
El resultado es un ciclo que se repite en las organizaciones: el equipo de IA presenta la demo, el equipo de seguridad revisa, el equipo de seguridad encuentra seis problemas, el equipo de IA pasa dos meses remediando mientras los responsables de negocio preguntan cuándo estará el proyecto en producción, el equipo de IA presenta de nuevo, el equipo de seguridad encuentra tres problemas pendientes, el ciclo se repite. Los proyectos que rompen este ciclo son los que diseñaron la arquitectura de recuperación pensando en los criterios de evaluación de seguridad desde el principio — donde la gobernanza de datos fue un insumo de diseño, no una barrera al final.
Confías en que tu organización es segura. Pero ¿puedes verificarlo?
Read Now
Los seis modos de fallo: qué encuentra seguridad y por qué bloquea la aprobación
Los siguientes seis modos de fallo aparecen en la mayoría de las revisiones de seguridad de RAG en empresas de sectores regulados. Cada uno representa una pregunta que hará el equipo de seguridad, una respuesta que el equipo de IA no puede dar con la arquitectura RAG por defecto y el cambio arquitectónico necesario para resolverlo.
| Modo de fallo | Qué construyó el equipo de IA | Por qué seguridad lo bloquea | Qué lo resuelve |
|---|---|---|---|
| Recuperación sobre-permisionada | El pipeline RAG usa una cuenta de servicio con acceso amplio al repositorio; la recuperación se basa en relevancia sin autorización por usuario | El equipo de seguridad pregunta: ¿qué impide que un usuario recupere documentos fuera de su nivel de autorización? El equipo de IA no tiene respuesta que no requiera rehacer la arquitectura. | Aplicación de RBAC/ABAC por solicitud en la capa de recuperación; recuperación limitada a lo que el usuario autenticado está autorizado a acceder, no a lo que es relevante semánticamente en todo el corpus |
| Autenticación por cuenta de servicio | El sistema de IA se autentica en las fuentes de datos mediante una cuenta de servicio compartida o clave API estática; no se conserva la identidad por usuario | El equipo de seguridad pregunta: ¿qué persona es responsable de cada evento de acceso a datos? El equipo de IA no puede atribuir acciones a individuos — la única identidad en el registro es la de la cuenta de servicio. | OAuth 2.0 con PKCE y autorización delegada por usuario; la identidad individual del usuario se conserva durante todo el flujo de autenticación hasta la capa de recuperación y se registra en cada evento de acceso |
| Sin registro de auditoría en la capa de recuperación | El registro se implementa en la capa de aplicación de IA (registros de sesión, de consultas) pero no en la capa de datos; las recuperaciones de documentos individuales no se registran | El equipo de seguridad pregunta: ¿puedes mostrar un registro de cada documento recuperado, por qué usuario, en qué fecha? El equipo de IA puede mostrar registros de sesión que no cumplen los requisitos de registro por documento y por usuario. | Registro de recuperación por documento en la capa de datos, capturando identificador de documento, identidad de usuario, decisión de autorización, clasificación de sensibilidad y marca de tiempo para cada evento de recuperación |
| Sin aplicación de etiquetas de sensibilidad | El pipeline RAG ignora las etiquetas MIP o de clasificación de datos existentes en los documentos indexados; la recuperación se basa en relevancia semántica sin importar la clasificación | El equipo de seguridad pregunta: ¿qué impide que la IA recupere un documento marcado como Restringido o Confidencial para un usuario sin el nivel de autorización necesario? El equipo de IA no tiene control técnico para demostrarlo. | Evaluación de etiquetas MIP en la capa de recuperación; los documentos por encima del nivel de autorización del usuario solicitante se deniegan antes de entrar en el contexto de IA; la denegación se registra con la base de la política |
| Sin controles de residencia o soberanía de datos | El pipeline RAG indexa documentos de repositorios en distintas jurisdicciones; la recuperación y el procesamiento pueden ocurrir en infraestructuras fuera de los límites legales de residencia de datos | El equipo de seguridad o legal pregunta: ¿dónde se procesan estos datos y cumple eso con nuestras obligaciones de GDPR/nube soberana para datos de la UE/Reino Unido? El equipo de IA no puede responder sin revisar la documentación de infraestructura. | Controles de residencia de datos que aplican dónde se realiza la recuperación, el procesamiento y el almacenamiento; aislamiento de inquilinos que garantiza que los datos de distintas jurisdicciones no se mezclan en las operaciones de recuperación |
| Sin integración con respuesta a incidentes | El pipeline RAG no tiene procedimiento documentado para detectar, contener o remediar un incidente de acceso a datos; sin integración con SIEM; sin detección de anomalías en volumen o patrón de recuperación | El equipo de seguridad pregunta: si la pipeline de IA se usa para extracción masiva de datos, ¿cómo lo detectarías? ¿Cuál es el procedimiento de respuesta? El equipo de IA no tiene respuesta documentada. | Integración en tiempo real con SIEM para la actividad de recuperación; líneas base de volumen de recuperación por usuario y alertas de anomalía; procedimientos documentados de respuesta a incidentes específicos de IA integrados en el programa general de IR |
Lo que realmente piden los equipos de seguridad
Traducir los requisitos de revisión de seguridad en especificaciones arquitectónicas es un punto de fricción recurrente entre equipos de IA y funciones de seguridad. Las preguntas de seguridad no son arbitrarias. Se corresponden directamente con los controles de seguridad que los programas empresariales aplican a todos los sistemas privilegiados de acceso a datos, derivados de los mismos marcos que gobiernan el acceso a EHR, sistemas de reporte financiero e infraestructura de transferencia de archivos regulada. Entender qué buscan realmente estas preguntas hace que la arquitectura necesaria sea comprensible.
Cuando seguridad pregunta «¿qué impide que un usuario acceda a datos fuera de su autorización?»…
…están pidiendo evidencia de que el sistema de recuperación aplica las políticas de control de acceso de la organización por solicitud, no por sesión. La respuesta que buscan es: «la recuperación está limitada por el perfil RBAC y ABAC del usuario autenticado en el momento de cada consulta, y los documentos fuera de ese alcance se excluyen de la recuperación antes de entrar en el contexto de IA.» La respuesta que no buscan es: «el modelo de IA está instruido para no referenciar documentos que el usuario no debería ver.»
Cuando seguridad pregunta «¿quién es responsable de cada evento de acceso a datos?»…
…están pidiendo atribución individual en el registro de auditoría, no la identidad de una cuenta de servicio. La respuesta que buscan es: «OAuth 2.0 con autorización delegada por usuario conserva la identidad del usuario autenticado hasta la capa de recuperación, y cada entrada de registro contiene tanto la identidad del sistema de IA como la del usuario individual.» La respuesta que no buscan es: «la plataforma de IA registra la sesión y podemos correlacionarla con la actividad del usuario.»
Cuando seguridad pregunta «¿cómo detectarías una extracción masiva de datos?»…
…están pidiendo una arquitectura de monitoreo, no una descripción teórica de cómo sería un comportamiento anómalo. La respuesta que buscan es: «la actividad de recuperación se envía a SIEM en tiempo real; se establecen líneas base de volumen de recuperación por usuario; las desviaciones por encima del umbral generan alertas automáticas.» La respuesta que no buscan es: «si alguien hiciera eso, probablemente lo veríamos en los registros.»
Cuando seguridad pregunta «¿qué pasa si este sistema se ve comprometido?»…
…están pidiendo procedimientos documentados de respuesta a incidentes específicos para la pipeline de IA, no una referencia a la política general de IR. La respuesta que buscan es: «el plan de IR tiene un anexo específico para IA que cubre indicadores de detección, procedimientos de contención para el componente de recuperación, pasos de preservación forense y el flujo de notificación si hay PHI o datos personales involucrados.»
Preparación para la revisión de seguridad: diez requisitos y qué necesita cada uno
La siguiente lista relaciona los diez requisitos de revisión de seguridad más consistentes para implementaciones empresariales de RAG con las capacidades arquitectónicas específicas necesarias para cumplir cada uno. Los equipos de IA deben usar esta lista antes de someterse a la revisión de seguridad — cualquier requisito cuya respuesta sea «aún no» será una observación que retrasará la aprobación.
| Requisito de revisión de seguridad | Categoría | Qué se requiere para cumplirlo |
|---|---|---|
| ¿Puedes demostrar que la recuperación está limitada a lo que el usuario solicitante está autorizado a acceder, no al corpus completo? | Autenticación / Acceso | Requiere aplicación de RBAC/ABAC por solicitud en la capa de recuperación con decisiones de autorización registradas; la recuperación basada solo en relevancia sin limitación por usuario no cumple este requisito |
| ¿Puedes demostrar que no se usan cuentas de servicio compartidas ni claves API estáticas para el acceso a datos de IA? | Autenticación | Requiere OAuth 2.0 con autorización delegada por usuario; la identidad individual del usuario debe conservarse hasta la capa de recuperación y estar presente en cada entrada del registro de auditoría |
| ¿Puedes mostrar una entrada de registro de ejemplo con el usuario individual, documento específico recuperado, decisión de autorización y marca de tiempo para un evento de recuperación RAG? | Auditoría / Registros | Requiere registro de recuperación por documento en la capa de datos; los registros de sesión o de aplicación no cumplen este requisito; la entrada de registro de ejemplo es la solicitud de evidencia más común en la revisión de seguridad |
| ¿Puedes demostrar que las etiquetas de sensibilidad MIP en los documentos indexados se evalúan en el momento de la recuperación? | Clasificación de datos | Requiere integración de etiquetas MIP en la capa de recuperación; los documentos por encima del nivel de autorización del usuario deben ser denegados antes de entrar en el contexto de IA; la denegación debe registrarse con la base de la política |
| ¿Puedes demostrar que los eventos de acceso a datos de IA se envían a SIEM en tiempo real? | Monitoreo / Detección | Requiere integración en tiempo real con SIEM en la capa de recuperación; las exportaciones periódicas de registros no cumplen los requisitos de monitoreo continuo para FedRAMP, SOC 2 o la política de seguridad empresarial |
| ¿Puedes describir las reglas de detección de anomalías activas para la actividad de recuperación de IA y mostrar una alerta de ejemplo? | Monitoreo / Detección | Requiere reglas documentadas de línea base para volumen de recuperación y patrones de consulta, y al menos una alerta de ejemplo que demuestre que el monitoreo está operativo y no solo configurado pero inactivo |
| ¿Puedes demostrar que la recuperación y el procesamiento de datos sujetos a requisitos de residencia se realizan dentro de la jurisdicción requerida? | Residencia de datos | Requiere documentación de infraestructura que muestre ubicaciones de recuperación, procesamiento y almacenamiento; para datos bajo GDPR, debe demostrarse residencia en la UE/Reino Unido o un mecanismo legal de transferencia |
| ¿Tienes un procedimiento documentado de respuesta a incidentes específico para incidentes de acceso a datos de IA? | Respuesta a incidentes | Requiere un anexo específico para IA en el plan de IR existente, que cubra indicadores de detección, procedimientos de contención y pasos de preservación forense específicos para incidentes en el pipeline RAG |
| ¿Puedes demostrar que los controles de acceso aplicados al acceso a datos de IA son equivalentes a los aplicados al acceso humano a los mismos datos? | Equivalencia de control de acceso | Requiere que las políticas RBAC/ABAC que gobiernan el acceso humano al repositorio también gobiernen la recuperación de IA desde el mismo repositorio; controles de acceso separados y más débiles para IA no cumplen este test |
| ¿Puedes demostrar que el sistema de IA no puede recuperar ni procesar datos a los que el usuario director no está autorizado a acceder por ningún otro canal? | Alcance de autorización | Requiere definición de autorización previa a la recuperación, no filtrado posterior; la prueba es si los datos no autorizados alguna vez entran en el contexto de IA, no si se eliminan de la respuesta |
Arquitectura que aprueba: construir la capa de gobernanza antes de la revisión de seguridad
La forma más eficaz de aprobar una revisión de seguridad RAG es realizar una versión previa a la construcción. Antes de finalizar la arquitectura de recuperación, el equipo de IA debe repasar los diez requisitos anteriores e identificar cuáles requieren decisiones arquitectónicas en vez de opciones de configuración.
Estas son las decisiones costosas de revertir una vez construido el pipeline. Las que son fáciles de añadir después — documentación, actualizaciones de políticas, anexos al plan de IR — pueden esperar. Las que requieren rediseñar el modelo de autenticación, reconstruir la capa de autorización de recuperación o reemplazar credenciales de cuenta de servicio no son fáciles de añadir después.
La decisión sobre la arquitectura de autenticación es la más importante y la más irreversible. Elegir OAuth 2.0 con autorización delegada por usuario en vez de una cuenta de servicio como mecanismo de autenticación de recuperación determina si la atribución individual del usuario estará disponible en cada entrada de registro posterior, cada registro de auditoría y cada determinación de alcance de notificación de brechas.
Es sencillo tomar esta decisión antes de construir; es costoso adaptarla a un pipeline ya implementado donde la gestión de sesiones se diseñó en torno a la identidad de cuenta de servicio.
La decisión sobre la arquitectura de autorización de recuperación es la segunda más importante. La definición de autorización previa a la recuperación — aplicar restricciones RBAC y ABAC antes de la operación de recuperación, no como filtro posterior — requiere que el sistema de recuperación conozca el perfil de autorización del usuario solicitante.
Esto no está disponible en las configuraciones estándar de frameworks RAG; requiere una capa de recuperación gobernada que se sitúe entre la consulta del usuario y la operación de búsqueda vectorial. Construir esta capa como parte de la arquitectura inicial es sencillo; adaptarla a un pipeline donde la búsqueda vectorial opera directamente sobre el corpus completo requiere reconstruir el componente de recuperación desde cero.
La decisión sobre la arquitectura de registros deriva de la arquitectura de autorización de recuperación. El registro de recuperación por documento requiere que la capa de recuperación genere un evento de registro por cada documento que devuelve, con el identificador del documento, la identidad del usuario, la decisión de autorización y la clasificación de sensibilidad.
Este evento de registro debe generarse en la capa de recuperación, no reconstruirse a partir de registros de aplicación. Si la capa de recuperación no genera este evento por diseño, añadirlo después requiere instrumentar el componente de recuperación — lo cual es más sencillo si el componente se diseñó para gobernanza que si es una operación de búsqueda vectorial por defecto del framework.
La capa de gobernanza: por qué el patrón de puerta de enlace de datos IA resuelve el problema de la revisión de seguridad
La clave arquitectónica que simplifica la revisión de seguridad RAG es que los seis modos de fallo pueden resolverse con una sola capa de gobernanza que se sitúa entre la solicitud de recuperación del pipeline RAG y los repositorios de datos que indexa.
Esta capa de gobernanza gestiona la autenticación (OAuth 2.0 con PKCE), la autorización por solicitud (RBAC y ABAC evaluados contra el perfil del usuario), la aplicación de etiquetas de sensibilidad (evaluación de etiquetas MIP en el momento de la recuperación), el registro por documento (cada evento de recuperación registrado con atribución completa) y la integración con SIEM (envío en tiempo real).
El pipeline RAG en sí — el indexado vectorial, el embedding, el ensamblaje de contexto, el modelo — no cambia. La capa de gobernanza no limita la calidad de recuperación; es un envoltorio alrededor de la operación de recuperación que produce acceso conforme en vez de acceso sin restricciones.
Este es el patrón de puerta de enlace de datos IA. En vez de construir capacidades de gobernanza directamente en el framework RAG — lo que requiere desarrollo a medida sobre frameworks que no fueron diseñados para ello — la capa de gobernanza es un componente separado por el que pasa la operación de recuperación.
El pipeline RAG solicita una recuperación; la capa de gobernanza evalúa la solicitud contra el perfil de autorización del usuario autenticado, aplica las políticas de sensibilidad, ejecuta la recuperación sobre el subconjunto autorizado del corpus, registra el resultado y devuelve los documentos recuperados al pipeline.
Desde la perspectiva del pipeline RAG, recibe los documentos que solicitó. Desde la perspectiva del equipo de seguridad, todos los requisitos de revisión de seguridad se cumplieron antes de devolver los documentos.
El cálculo de construir o comprar este patrón es sencillo para la mayoría de organizaciones. Construir una capa de recuperación gobernada desde cero requiere: implementar OAuth 2.0 con PKCE e integrarlo con el sistema empresarial de gestión de identidades y accesos; construir un motor de autorización por solicitud que evalúe políticas RBAC y ABAC del almacén de políticas de la organización; integrar la evaluación de etiquetas MIP en la ruta de recuperación; construir una infraestructura de registro por documento con envío a SIEM; y mantener todo esto como sistema en producción.
La alternativa es implementar una puerta de enlace de datos IA diseñada para este fin que proporcione todas estas capacidades como componente gestionado, permitiendo que el equipo de IA se enfoque en construir la aplicación de IA mientras la capa de gobernanza gestiona lo que necesita el equipo de seguridad.
Cómo Kiteworks lleva RAG a producción
La premisa detrás de la puerta de enlace de datos IA de Kiteworks es que el fallo en la revisión de seguridad de RAG es un problema arquitectónico con una solución arquitectónica — y que la solución no requiere reconstruir el pipeline RAG, solo añadir la capa de gobernanza que faltaba. La puerta de enlace de datos IA proporciona esa capa como un componente desplegable integrado con la Red de datos privados de Kiteworks, cerrando cada uno de los seis modos de fallo de revisión de seguridad sin necesidad de desarrollo a medida.
La autenticación se gestiona mediante OAuth 2.0 con PKCE, conservando la identidad del empleado autenticado desde el asistente de IA hasta la capa de recuperación. Ninguna cuenta de servicio media en la cadena de acceso; cada recuperación se autoriza bajo la identidad individual del usuario y cada entrada del registro de auditoría lleva esa identidad junto con la identidad del sistema de IA.
La autorización RBAC y ABAC por solicitud se aplica en la capa de recuperación mediante el motor de políticas de datos de Kiteworks, que evalúa el perfil de autorización del usuario frente al documento solicitado antes de que el documento entre en el contexto de IA. Las etiquetas de sensibilidad MIP se evalúan en el momento de la recuperación; los documentos por encima del nivel de autorización del usuario se deniegan antes de la recuperación y la denegación se registra con la base de la política.
El registro de recuperación por documento genera una entrada completa de registro de auditoría para cada evento de recuperación: identidad del usuario, identidad del sistema de IA, identificador de documento, clasificación de sensibilidad, decisión de autorización y marca de tiempo. Cada entrada se envía en tiempo real a la integración SIEM de Kiteworks, estableciendo el registro de monitoreo continuo que requieren los equipos de seguridad y los marcos de cumplimiento.
Las líneas base de volumen de recuperación por usuario están activas por defecto y se generan alertas de anomalía cuando los patrones de recuperación se desvían — proporcionando la capacidad de detección que piden los equipos de seguridad y que los equipos de IA rara vez pueden demostrar.
La arquitectura de intercambio de datos de confianza cero que gobierna el uso compartido seguro de archivos, la transferencia de archivos gestionada y el correo electrónico seguro en toda la organización se extiende a cada recuperación RAG — así que la postura de gobernanza de datos demostrada ante seguridad para los canales de datos tradicionales es la misma que se demuestra para el pipeline de IA.
No hay una revisión de seguridad separada para una nueva arquitectura de acceso a datos; hay una extensión de un marco de gobernanza ya aprobado a un nuevo patrón de consumo. Para los equipos de IA que quieren pasar RAG de piloto a producción, esa es la diferencia entre un ciclo de revisión de seguridad de seis meses y uno manejable.
Para VP de Ingeniería de IA/ML y CISOs que quieren dejar de perder proyectos RAG en la puerta de seguridad, Kiteworks proporciona la capa de gobernanza que cierra la brecha. Para ver cómo la puerta de enlace de datos IA cumple cada uno de los diez requisitos de revisión de seguridad, agenda una demo personalizada hoy mismo.
Preguntas frecuentes
Los frameworks RAG están diseñados para resolver problemas de calidad de recuperación: búsqueda semántica, calidad de embedding, ensamblaje de contexto y precisión de respuesta. No están diseñados para resolver problemas de gobernanza: autorización por usuario, registro de auditoría por documento, aplicación de etiquetas de sensibilidad e integración con SIEM. Cuando un equipo de IA construye un pipeline RAG usando frameworks estándar optimizados para la calidad de recuperación, produce un sistema que rinde bien en recuperación y mal en gobernanza. Los equipos de seguridad evalúan la gobernanza, la encuentran deficiente y bloquean la aprobación. El fallo es predecible porque los frameworks no proporcionan capacidades de gobernanza por defecto y la mayoría de los equipos de IA no las añaden hasta que seguridad lo solicita. Incluir la capa de gobernanza en la arquitectura de recuperación antes de la revisión de seguridad es la única forma fiable de evitar este ciclo.
La definición de autorización previa a la recuperación aplica el perfil de autorización RBAC y ABAC del usuario solicitante como restricción sobre la propia operación de recuperación, de modo que la búsqueda vectorial solo devuelve documentos que el usuario está autorizado a acceder. El filtrado posterior a la recuperación primero recupera todos los documentos relevantes semánticamente y luego elimina los que el usuario no está autorizado a ver. La diferencia de seguridad es fundamental: el filtrado posterior a la recuperación significa que los documentos no autorizados ya fueron recuperados y puestos en el contexto de la IA antes de ser eliminados — el acceso no autorizado ya ocurrió. La definición de autorización previa a la recuperación significa que los documentos no autorizados nunca se recuperan. Los equipos de seguridad exigen esto último porque lo anterior no previene el acceso a los datos; solo filtra la respuesta.
La revisión de seguridad empresarial para la autenticación RAG exige tres cosas: identidad individual del usuario conservada hasta la capa de recuperación (no una cuenta de servicio compartida), tokens de corta duración en vez de claves API estáticas (para limitar la ventana de exposición de credenciales) y autenticación que cumpla el marco empresarial de gestión de identidades y accesos ya existente. OAuth 2.0 con PKCE cumple las tres: la autorización delegada por usuario conserva la identidad individual del usuario durante todo el flujo de autenticación hasta la capa de recuperación; los tokens son de corta duración y PKCE previene la interceptación del código de autorización; y OAuth 2.0 se integra con los proveedores de identidad empresariales. Las cuentas de servicio y las claves API estáticas fallan el primer requisito y aparecen como observaciones en prácticamente todas las evaluaciones RAG de sectores regulados.
Técnicamente es posible pero en la práctica es difícil. Los frameworks RAG estándar no ofrecen autorización ABAC por solicitud, registro de recuperación por documento, integración de etiquetas MIP ni envío a SIEM como capacidades integradas. Implementar estas capacidades sobre frameworks estándar requiere desarrollo a medida de una capa de integración OAuth 2.0, un motor de autorización por solicitud, una capa de instrumentación de recuperación para el registro por documento, una integración de evaluación de etiquetas MIP y una integración de envío de registros — cada uno como sistema de producción mantenible. Las organizaciones que construyen esto a medida están, en la práctica, creando una puerta de enlace de datos IA desde cero. Implementar un componente diseñado para esto es más rápido, más fiable y produce un paquete de evidencias para la revisión de seguridad que se ajusta directamente a los criterios de evaluación, en vez de requerir que el equipo de IA documente cómo cada implementación personalizada cumple cada requisito.
Una capa de gobernanza correctamente implementada no degrada la calidad de recuperación ni la precisión de la respuesta; cambia el alcance de la operación de recuperación. La definición de autorización previa a la recuperación implica que la búsqueda vectorial se ejecuta sobre el subconjunto del corpus al que el usuario está autorizado a acceder, no sobre el corpus completo. Para la mayoría de los usuarios, este es el corpus que esperan que la IA busque — su dominio de gobernanza de datos autorizado. La precisión de la respuesta para su alcance autorizado no cambia. El único cambio de calidad es que la IA no referenciará documentos fuera del nivel de autorización del usuario — que es el comportamiento esperado, no una degradación. El principio de intercambio de datos de confianza cero de verificar cada solicitud en vez de confiar en el acceso amplio aplica aquí: una recuperación gobernada que devuelve resultados precisos dentro del alcance autorizado es un mejor sistema de producción que una recuperación no gobernada que ocasionalmente devuelve resultados fuera del alcance autorizado.
Recursos adicionales
- Artículo del Blog
Estrategias de confianza cero para una protección de privacidad de IA asequible - Artículo del Blog
Cómo el 77% de las organizaciones falla en la seguridad de datos de IA - eBook
Brecha de gobernanza de 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.