ARQUITECTURA SEGURAv1.0Validada

Secure RAG Review

CyberSkill operativa para revisar la seguridad de una arquitectura RAG de extremo a extremo.

01

Objetivo

  • Identificador: CS-02
  • Versión / estado: v1.0 · Validada
  • Autor: No definido
  • Responsable: No definido
  • Última revisión: 18/09/2026
  • Criticidad: Alta
  • Rol de ejecución: Security Architect / AI Architect
  • Tiempo estimado: 4–8 horas para revisión documental; pruebas de recuperación y aislamiento pueden ampliar el tiempo
  • Marcos de referencia: ISO/IEC 27001 · NIST AI RMF · NIST CSF 2.0 · OWASP GenAI Security Project · ENS, DORA o NIS2 cuando resulten aplicables al entorno

Objetivo operativo

Revisar la cadena completa de una arquitectura RAG para determinar si la ingesta, procedencia, indexación, autorización, recuperación y ensamblado de contexto preservan confidencialidad, integridad y separación entre fuentes y usuarios.

Límite explícito: No valida por sí sola la exactitud factual del contenido recuperado ni sustituye la clasificación documental, revisión legal de derechos de uso o evaluación general del LLM.

Cuándo se usa

  • Antes de habilitar una nueva fuente documental o colección en un RAG.
  • Tras modificar chunking, embeddings, vector store, filtros de recuperación, ACL o tenancy.
  • Ante indicios de poisoning, fuga entre usuarios/tenants, recuperación indebida o eliminación incompleta.

Skills relacionadas: LLM Security Review para controles del modelo y prompt; Cloud AI Security Baseline cuando el RAG se despliegue en servicios cloud gestionados.

02

Entradas mínimas

  • Obligatoria:Inventario de fuentes documentales y propietario de cada fuente.
  • Obligatoria:Diagrama del pipeline de ingesta: adquisición, validación, transformación, chunking, embeddings e indexación.
  • Obligatoria:Configuración del vector store/índice, namespaces o mecanismo equivalente de segregación.
  • Obligatoria:Modelo de autorización de documentos y forma en que las ACL se propagan a la recuperación.
  • Obligatoria:Metadatos de procedencia almacenados por documento/chunk y mecanismo de actualización/eliminación.
  • Obligatoria:Consultas o filtros de recuperación, top-k/reranking y lógica de ensamblado del contexto.
  • Opcional:Muestras de documentos hostiles/controlados para pruebas de poisoning e indirect prompt injection.
03

Secuencia operativa

  1. Inventariar fuentes y procedencia. Relacionar cada corpus con origen, propietario, clasificación, método de ingesta y autorización. Entregable intermedio: Matriz fuente → propietario → clasificación → ingestión.
  2. Revisar la cadena de ingesta. Comprobar validación de tipo/contenido, tratamiento de archivos, origen y cambios antes de indexar. Entregable intermedio: Diagrama validado y lista de controles de ingesta.
  3. Verificar autorización en recuperación. Comprobar que la decisión de acceso se aplique en consulta/recuperación y no dependa solo del texto generado por el modelo. Entregable intermedio: Pruebas de acceso permitido/denegado y evidencia de filtros/ACL.
  4. Revisar aislamiento y tenancy. Probar separación entre usuarios, proyectos o tenants y evitar recuperación cruzada no autorizada. Entregable intermedio: Resultados de pruebas de aislamiento.
  5. Evaluar poisoning e instrucciones indirectas. Introducir contenido controlado en un corpus de prueba y verificar que no pueda alterar indebidamente comportamiento, herramientas o políticas. Entregable intermedio: Bitácora de pruebas de poisoning/inyección indirecta.
  6. Verificar actualización, borrado y reconstrucción. Comprobar cómo se actualizan/eliminan documentos y chunks y si existe divergencia entre fuente e índice. Entregable intermedio: Evidencia de baja/reindexación y trazabilidad de versiones.
  7. Cerrar la revisión. Consolidar fallos de procedencia, autorización, aislamiento, integridad y trazabilidad. Entregable intermedio: Informe Secure RAG Review y matriz de evidencias.
04

Principios de ejecución

Controles y evidencias

  • Procedencia del contenido: Cada documento/chunk debe conservar referencia a origen y versión; evidencia: metadatos del índice.
  • Autorización en retrieval: La recuperación debe respetar permisos efectivos; evidencia: configuración de filtros/ACL y pruebas positivas/negativas.
  • Segregación: Separación por tenant/proyecto/usuario cuando aplique; evidencia: namespaces, filtros, políticas y pruebas cruzadas.
  • Integridad de ingesta: Controles sobre fuentes, tipos de archivo y transformaciones; evidencia: pipeline/configuración y logs.
  • Gestión del ciclo de vida: Alta, actualización, borrado y reindexación trazables; evidencia: logs y pruebas de eliminación.
  • Resistencia a poisoning/inyección indirecta: Contenido no confiable no debe convertirse en instrucción privilegiada; evidencia: pruebas controladas y configuración del ensamblado de contexto.

Criterios de aceptación

  • Todas las fuentes del alcance tienen propietario y procedencia documentados.
  • Las ACL o restricciones equivalentes se verifican en recuperación con pruebas reproducibles.
  • No se observa acceso cruzado no autorizado entre dominios de seguridad probados.
  • Los documentos retirados o actualizados no permanecen recuperables fuera de la política definida.
  • Los fallos de poisoning o inyección indirecta con impacto alto quedan escalados.

Límites y escalado

  • Acceso a documentos sin autorización efectiva.
  • Fuga entre tenants o ámbitos de datos.
  • Ausencia de procedencia suficiente para reconstruir el origen del contexto.
  • Derechos de uso, privacidad o retención documental no definidos y con impacto legal.
La skill no debe asumir controles, evidencias ni decisiones no demostradas. Los puntos jurídicos, humanos o de fabricante quedan fuera de la autonomía de ejecución y deben escalarse al responsable correspondiente.
05

Resultado

Informe de arquitectura RAG segura con mapa de fuentes, pipeline, matriz de autorización, pruebas de aislamiento/poisoning, evidencias, hallazgos y riesgo residual. Destino: expediente de arquitectura y seguridad del sistema.

SKILL.md portable

El SKILL.md contiene la misma versión operativa de la skill en formato Markdown portable: metadatos, objetivo, triggers, entradas, secuencia, controles/evidencias, criterios de aceptación, salida, límites y referencias. La versión Validada se congela y se acompaña de un hash SHA-256 separado. El hash acredita integridad del fichero, no firma digital ni no repudio. Autor y responsable permanecen como “No definido” hasta que exista una asignación formal.

Ver SKILL.md portable →