Los fallos del RAG pueden comenzar antes de la recuperación: documentos desactualizados, tablas omitidas, fuentes sin propietario, metadatos de permisos perdidos, vectores no eliminados, texto oculto contradictorio o archivos inseguros.
La ingestión segura de documentos es el control de fuentes para el conocimiento empresarial. Decide qué entra en el sistema de recuperación, quién puede verlo, cómo se rastrea la frescura, cómo funciona la eliminación y cómo se detectan las entradas defectuosas.
Este artículo cubre la capa de ingestión: PDFs, OCR, metadatos, permisos, conservación y comprobaciones operativas.
Si un usuario no debe acceder a un documento en el sistema de origen, tampoco debe acceder a sus fragmentos, embeddings, resúmenes ni respuestas almacenadas en caché en el sistema RAG. Los metadatos de permisos no son opcionales.
El pipeline de ingestión
Un pipeline de producción debe tener etapas explícitas:
- Registro de la fuente.
- Clasificación de datos.
- Comprobaciones de seguridad del archivo.
- Extracción de texto y OCR.
- Preservación de la estructura.
- Adjunción de metadatos.
- Mapeo de permisos.
- Fragmentación y generación de embeddings.
- Comprobaciones de calidad.
- Publicación del índice.
- Gestión de conservación y eliminación.
- Propiedad operativa.
Las herramientas exactas pueden variar. Los puntos de control no deben hacerlo.
Etapa 1: registro de la fuente
No ingestes carpetas al azar solo porque sean fáciles de conectar.
Para cada fuente, registra:
- nombre de la fuente,
- sistema oficial de registro,
- propietario de la fuente,
- propietario de los datos,
- usuarios o roles permitidos,
- tipos de documento,
- nivel de sensibilidad,
- regla de conservación,
- frecuencia de actualización,
- comportamiento de eliminación,
- calendario de revisión.
Ejemplos de fuentes:
- centro de ayuda público,
- manual interno de soporte,
- material comercial (sales collateral),
- contratos con clientes,
- políticas de recursos humanos,
- manuales de operaciones de ingeniería,
- documentación del producto,
- transcripciones de reuniones.
Estas fuentes no deben terminar todas en el mismo índice con los mismos permisos.
Etapa 2: clasifica los datos antes de la extracción
Clasifica la fuente antes de que el modelo o el proveedor de embeddings vea el contenido.
Clases útiles:
| Clase | Ejemplo | Postura predeterminada |
|---|---|---|
| Pública | documentación publicada, páginas de marketing | Permitida para recuperación amplia |
| Interna | manuales, documentos de procesos | Solo empresa, filtrado por rol |
| Confidencial | contratos, detalles del cliente, finanzas | Roles restringidos, registro más estricto |
| Regulada/sensible | salud, legal, RR. HH., nóminas, incidentes de seguridad | Evitar a menos que esté aprobada explícitamente |
La clasificación no es solo papeleo de cumplimiento normativo. Determina si el contenido puede enviarse a una API alojada de embeddings, almacenarse en una base de datos vectorial compartida, incluirse en registros o usarse como ejemplo de evaluación.
Etapa 3: comprobaciones de seguridad del archivo
Los documentos pueden ser hostiles o simplemente estar dañados.
Antes de la extracción:
- verifica el tipo de archivo contra una lista de permitidos,
- aplica límites de tamaño de archivo,
- escanea en busca de malware donde tu entorno lo requiera,
- rechaza archivos cifrados a menos que haya una ruta de descifrado aprobada,
- rechaza archivos con objetos incrustados no compatibles,
- normaliza los nombres de archivo,
- almacena el hash del archivo original,
- registra quién subió o conectó el archivo.
Esto es especialmente importante si los usuarios no administradores pueden subir documentos. La ingestión solo para administradores reduce una vía de amenaza pero no hace seguro un documento comprometido, malicioso, de tamaño excesivo o con formato incorrecto. La ingestión mediante conectores y URLs también requiere orígenes incluidos en una lista de permitidos, controles de redirección y DNS, alcance de autenticación, límites de solicitudes (rate limits) y pruebas SSRF.
Si los usuarios no confiables pueden subir archivos, implementa una capa de seguridad de archivos antes del análisis. Utiliza como línea base la Hoja de referencia de OWASP sobre carga de archivos, que recibe mantenimiento, y modela las amenazas de los analizadores y la ruta de almacenamiento seleccionados. Para el modelo de amenazas más amplio de la recuperación, que incluye el envenenamiento, la filtración de permisos, la inyección de prompts y la salida insegura, utiliza también la Hoja de referencia de OWASP sobre seguridad de RAG.
Los controles candidatos incluyen tipos incluidos en una lista de permitidos y verificados a partir del contenido del archivo, límites de tamaño y de expansión de archivos comprimidos, nombres de almacenamiento aleatorios, escaneo de firmas, análisis aislado sin salida de red y con límites de recursos, y desarme y reconstrucción de contenido donde el modelo de amenazas lo justifique. Ningún escáner individual establece que un archivo sea seguro.
Etapa 4: extracción de texto y OCR
Los PDFs no son un único formato en la práctica. Algunos contienen texto seleccionable. Otros son escaneos. Algunos tienen columnas, tablas, notas al pie, formularios, comentarios, sellos o capas de texto oculto.
Elige la ruta de extracción según el tipo de documento: compara extractores orientados al texto para PDFs digitales nativos, convertidores que reconocen el diseño de página para documentos estructurados y OCR para escaneos. La elección de la herramienta debe guiarse por la precisión medida en diseño y tablas, el soporte de idiomas, la licencia, el proceso de parcheo y el límite de datos.
En cuanto a los umbrales: no adoptes un corte universal de confianza del OCR tomado de una publicación de blog; calíbralo con una muestra de tus propios documentos. La forma útil tiene dos bandas: por debajo de la banda inferior se rechaza la página directamente; entre las bandas se pone en cola para revisión humana; por encima de la banda superior pasa sin intervención. Dónde se sitúan esas bandas depende de tu escáner, de la antigüedad del documento y de tu idioma.
Para archivos estonios y multilingües, incluye diacríticos, páginas antiguas mecanografiadas, tablas, sellos y ejemplos ruso-estonios en la prueba comparativa. Verifica que el motor OCR elegido tenga los datos de idiomas requeridos, luego mide la precisión de caracteres, palabras, campos y tablas en páginas representativas. No prometas una duración universal del piloto.
Rastrea la calidad de la extracción:
- método de extracción,
- confianza del OCR,
- número de páginas,
- recuento de caracteres extraídos,
- estado de extracción de tablas,
- idioma detectado,
- páginas sin texto,
- advertencias del analizador.
La extracción de baja calidad no debe entrar silenciosamente en el índice. Dirígela a revisión o márcala como baja confianza.
Problemas comunes:
- columnas leídas en orden incorrecto,
- filas de tablas fusionadas incorrectamente,
- encabezados repetidos en cada fragmento (chunk),
- páginas escaneadas faltantes por completo,
- notas manuscritas ignoradas,
- capa de texto oculto que contradice el escaneo visible,
- OCR convirtiendo números de cuenta incorrectamente.
Para documentos de alto valor, haz comprobaciones puntuales de la página renderizada frente al texto extraído.
Etapa 5: preserva la estructura
Los sistemas RAG necesitan más que texto. Necesitan suficiente estructura para producir respuestas útiles y fundamentadas en fuentes (grounded).
Preserva:
- título,
- ruta de encabezados,
- número de sección,
- número de página,
- leyendas de tablas,
- límites de listas,
- versión del documento,
- fecha de entrada en vigor,
- URL de origen o ruta de almacenamiento.
Fragmenta el texto con encabezados y referencias de página. Un fragmento que dice «Se aplica lo siguiente» sin el encabezado precedente es evidencia débil.
Para las tablas, decide si:
- mantener la tabla como Markdown,
- convertirla a JSON estructurado,
- almacenar tanto texto como filas estructuradas,
- excluirla hasta que haya un mejor analizador disponible.
No fingas que la extracción de tablas está resuelta si tu caso de uso depende de precios exactos, fechas, límites o umbrales.
Etapa 6: adjunta metadatos
Cada fragmento debe llevar metadatos que puedan sobrevivir a la recuperación:
{
"sourceId": "policy-2026-expenses",
"documentId": "doc_123",
"tenantId": "tenant_a",
"visibility": "internal",
"allowedRoles": ["finance", "leadership"],
"sensitivity": "confidential",
"sourceOwner": "Finance",
"version": "2026-02",
"lastReviewedAt": "2026-02-10",
"effectiveFrom": "2026-03-01",
"page": 7,
"headingPath": ["Travel", "Hotel limits"],
"contentHash": "sha256:..."
}
Los metadatos aportan los datos necesarios para aplicar las políticas, pero no las hacen cumplir por sí solos. La aplicación debe validar la procedencia fiable de los metadatos y aplicar la autorización en los límites de publicación, recuperación, caché, cita, generación y exportación.
Etapa 7: mapeo de permisos
Los permisos deben aplicarse antes de que los resultados de la recuperación lleguen al modelo y de nuevo en cualquier límite de respuesta, cita, caché o exportación en el que puedan haber cambiado la identidad o la política.
Buen patrón:
- El usuario hace una pregunta.
- La aplicación deriva el inquilino (tenant), usuario, roles, grupos y permisos de datos desde la autenticación.
- El recuperador filtra los fragmentos candidatos por permisos.
- El ranking ocurre dentro de los fragmentos permitidos.
- El modelo recibe solo fragmentos permitidos.
Mal patrón:
- Recuperar ampliamente.
- Enviar todos los fragmentos probables al modelo.
- El prompt dice «responde solo usando los fragmentos a los que el usuario puede acceder».
El mal patrón ya ha expuesto datos al contexto del modelo.
Si los permisos de la fuente son complejos, comienza más restringido. Es mejor perder una respuesta que filtrar un documento confidencial.
Etapa 8: fragmentación y generación de embeddings
La fragmentación es una decisión de seguridad y calidad, no solo una decisión de ajuste de búsqueda.
Directrices:
- Mantén los fragmentos dentro de los límites de permisos.
- No fusiones texto público y confidencial en un solo fragmento.
- Incluye encabezados y referencias de origen.
- Evita fragmentos gigantes que contengan secciones no relacionadas.
- Evita fragmentos diminutos que pierdan contexto.
- Vuelve a generar los embeddings cuando cambien el texto de origen o los metadatos.
- Almacena el modelo y la versión usados para los embeddings.
Para fuentes sensibles, confirma si el proveedor de embeddings, el almacén vectorial y los registros están aprobados para esa clase de datos.
Etapa 9: puertas de calidad (quality gates)
Antes de publicar una fuente en la recuperación de producción, ejecuta comprobaciones:
- todos los documentos tienen propietarios,
- todos los fragmentos tienen metadatos de permisos,
- se marcan los documentos desactualizados,
- las páginas con extracción fallida están excluidas o revisadas,
- preguntas de muestra recuperan fuentes esperadas,
- usuarios no autorizados recuperan cero fragmentos restringidos,
- los documentos eliminados desaparecen de la búsqueda,
- las citas apuntan a ubicaciones válidas del origen,
- instrucciones sospechosas en documentos se aíslan como contenido, no se siguen.
El último punto es importante. Los documentos pueden contener inyección de prompts. El pipeline de ingestión no debe eliminar silenciosamente todo ese texto, porque los usuarios pueden necesitar saber lo que dice un documento y la eliminación puede dañar la evidencia. El entorno de ejecución (runtime) debe mantener el contenido recuperado en un canal de datos, evitar que otorgue herramientas o cambie la política, validar los argumentos de las herramientas de forma independiente y requerir aprobación humana para los efectos con consecuencias.
Etapa 10: publica una versión del índice atómicamente
No permitas que documentos ingestados parcialmente o una mezcla de permisos antiguos y nuevos se filtren en el índice activo. Construye un índice candidato o espacio de nombres versionado, luego:
- congela el manifiesto fuente/versión y los hashes de contenido;
- verifica el número de documentos, los fallos de extracción, la cobertura de permisos, la política de duplicados, el modelo y la versión de embeddings, y consultas representativas autorizadas y no autorizadas;
- registra la versión candidata, versiones de origen, resultado de prueba, aprobador y objetivo de reversión (rollback);
- cambia atómicamente un alias o puntero de aplicación a la versión aprobada donde el almacén lo soporte;
- invalida o versiona las cachés de recuperación y respuesta; y
- supervisa los errores, las denegaciones de acceso, las recuperaciones vacías y el tráfico de versiones desactualizadas tras la promoción.
Si el almacén vectorial no puede cambiar de versión de forma atómica, implementa en la aplicación un estado de publicación que excluya los registros incompletos y prueba lectores concurrentes durante la puesta en producción. La revocación de permisos y la eliminación urgente de fuentes no deben esperar a una reconstrucción completa: aplica la autorización vigente fuera del índice, bloquea de inmediato la fuente afectada, purga las cachés pertinentes y completa la limpieza de derivados mediante el flujo de trabajo del ciclo de vida.
La reversión (rollback) debe restaurar el último puntero de índice aprobado sin restaurar acceso revocado o datos eliminados. Prueba que la reversión no resucite una ACL obsoleta, un documento eliminado, una fuente envenenada o una respuesta almacenada en caché desactualizada.
Etapa 11: conservación y eliminación
Los sistemas RAG a menudo mantienen accidentalmente datos por más tiempo que el sistema de origen.
El artículo 17 del RGPD establece un derecho de supresión sujeto a condiciones y excepciones. La asesoría jurídica especializada debe determinar la obligación aplicable y cualquier conservación lícita. El sistema sigue necesitando un inventario y una operación de ciclo de vida para cada copia y derivado:
- caché del archivo original,
- texto extraído,
- fragmentos (chunks),
- embeddings,
- resúmenes,
- miniaturas o páginas renderizadas,
- muestras de evaluación,
- registros, con una base aprobada de minimización y conservación,
- copias de seguridad, con expiración documentada y comportamiento de restauración.
Cuando se elimina un documento o se revoca el acceso, las cachés de recuperación y respuesta deben dejar de devolverlo dentro del objetivo documentado. El flujo de trabajo de eliminación debe cubrir los almacenes derivados y prevenir que una copia de seguridad antigua o un trabajo de ingestión retrasado resucite el registro.
Rastrea:
- deletedAt,
- deletedBy o evento de origen,
- motivo de la eliminación,
- estado de la limpieza posterior,
- resultado de verificación.
No confíes en «lo eliminamos de la interfaz». Los almacenes vectoriales y las cachés son fáciles de olvidar.
Etapa 12: propiedad operativa
Cada fuente de producción necesita un propietario responsable y un desencadenante o cadencia de revisión derivados de su tasa de cambio e impacto.
Para cada fuente, define:
- quién aprueba la ingestión,
- quién aprueba los cambios de permisos,
- quién revisa documentos desactualizados,
- quién gestiona los fallos de extracción,
- quién responde a las solicitudes de eliminación de datos,
- quién investiga errores de recuperación.
Si nadie es propietario de una fuente, no debería estar en un sistema RAG de producción.
Gobernanza de fuentes, no garantías
La ingestión segura del RAG es la gobernanza deliberada de fuentes. Hace que el comportamiento y los fallos de recuperación sean más observables y comprobables; no hace que las respuestas generadas sean inherentemente correctas o seguras.
Los controles principales:
- registrar fuentes,
- clasificar datos,
- verificar archivos antes del análisis,
- medir la calidad de la extracción,
- preservar la estructura,
- adjuntar metadatos,
- aplicar permisos antes de la recuperación,
- probar acceso no autorizado,
- admitir eliminación,
- asignar propietarios.
La calidad y los controles de las fuentes son entradas necesarias para la calidad y seguridad de las respuestas, no garantías. Valida la recuperación, autorización, fundamentación (grounding), rechazo, uso de herramientas y comportamiento del ciclo de vida de extremo a extremo.
