Volver al glosario

Retrieval-augmented generation (RAG)

2 min de lectura

En seguridad de IA, la retrieval-augmented generation (RAG) es una arquitectura que le da a un modelo de lenguaje acceso a un almacén de conocimiento externo en el momento de la consulta, recuperando los documentos relevantes y añadiéndolos al prompt. Es el diseño que despliega casi cualquier organización cuando dice que tiene IA, y es donde vive la indirect prompt injection.

29 de julio de 2026
Compartir:

Cómo funciona

RAG responde a una pregunta buscando contexto antes de generar. La consulta del usuario se convierte en un embedding, se contrasta con un almacén vectorial de documentos indexados de antemano, y los mejores resultados se insertan en el prompt del modelo junto a la pregunta. El modelo contesta entonces usando ese texto recuperado, lo que le permite citar datos actuales y privados con los que nunca se entrenó y reduce las invenciones dichas con aplomo. El intercambio es que el modelo pasa a consumir contenido que el desarrollador no escribió y que puede no haber revisado: lo que se indexara, y lo que un usuario tenga permitido recuperar, se convierte en parte de las instrucciones del modelo en ese turno.

Qué sale mal

Dominan dos fallos de seguridad. El primero es que el contenido recuperado es instrucción sin confianza: si un atacante consigue meter texto en el índice, o en un documento que la cadena vaya a traer, puede intentar una indirect prompt injection, y el modelo puede actuar sobre ella. El segundo es el control de acceso. Muchas cadenas lo indexan todo y aplican los permisos con flojera, así que un usuario puede recuperar, y hacer que el modelo le resuma, documentos que no debería ver jamás. Desde el asiento del atacante, el almacén vectorial es a la vez una superficie de inyección y una superficie de exposición de datos, y la base de datos vectorial que hay detrás se despliega con frecuencia con el acceso abierto por defecto.

Dónde aparece esto en una auditoría

Probamos la cadena de recuperación entera: qué se puede indexar y quién puede hacerlo, si la recuperación respeta los permisos del usuario que pregunta, y qué pasa cuando un documento recuperado lleva instrucciones. El control de acceso del almacén y de los documentos se evalúa de forma directa, porque «el modelo solo responde con nuestros datos» no es un control si cualquier usuario puede sacar cualquier documento. Comprobamos además qué se le permite hacer al modelo con lo que recupera, porque una cadena que deja que un documento recuperado dispare la llamada a una herramienta convierte un fallo de recuperación en una acción real. Los filtros se anotan como guardrails parciales, no como soluciones. Esto forma parte de cómo probamos una cadena de recuperación.

¿Quieres ver cómo trabajamos en Asperis Security?

Agenda 30 minutos con uno de nuestros especialistas. Revisamos tu stack y te decimos qué conviene probar primero.