La mayoría de los fallos de RAG comienzan antes de recuperar nada. El documento era antiguo. El OCR omitió una tabla. La fuente carecía de responsable. Se perdieron los metadatos de permisos. Un contrato eliminado permanecía en la base vectorial. Un PDF escaneado contenía texto oculto que nadie había revisado. El sistema respondió con seguridad porque el pipeline de ingesta confundía “el texto existe” con “el conocimiento es seguro”.
La ingesta documental segura controla las fuentes de conocimiento de la empresa. Determina qué entra en el sistema de recuperación, quién puede verlo, cómo se controla la vigencia, cómo funciona la eliminación y cómo se detectan entradas defectuosas.
Este artículo cubre la capa de ingesta: PDFs, OCR, metadatos, permisos, conservación y verificaciones 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 el RAG. Los metadatos de permisos no son opcionales.
El pipeline de ingesta
Un pipeline de producción debe tener etapas explícitas:
- Registro de fuentes.
- Clasificación de datos.
- Verificaciones de seguridad de archivos.
- Extracción de texto y OCR.
- Preservación de estructura.
- Incorporación de metadatos.
- Mapeo de permisos.
- Fragmentación y embeddings.
- Verificaciones de calidad.
- Publicación del índice.
- Gestión de la conservación y la eliminación.
Las herramientas exactas pueden variar. Los puntos de control no deben hacerlo.
Etapa 1: registro de fuentes
No ingieras carpetas aleatorias porque son fáciles de conectar.
Para cada fuente, registra:
- nombre de la fuente,
- sistema de registro,
- responsable de la fuente,
- responsable de los datos,
- usuarios o roles permitidos,
- tipos de documentos,
- 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,
- guía interna de soporte,
- material de ventas,
- contratos con clientes,
- políticas de recursos humanos,
- runbooks de ingeniería,
- documentación de productos,
- transcripciones de reuniones.
Estas fuentes no deben todas terminar en el mismo índice con los mismos permisos.
Etapa 2: clasificar 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 por defecto |
|---|---|---|
| Pública | documentos publicados, páginas de marketing | Permitida para recuperación general |
| Interna | guías, documentos de proceso | Solo para la empresa, filtrado por roles |
| Confidencial | contratos, detalles de clientes, finanzas | Roles restringidos, registro más fuerte |
| Regulada/sensible | salud, información jurídica, RRHH, nóminas, incidentes de seguridad | Evitar salvo aprobación expresa |
La clasificación no es un mero trámite de cumplimiento. Determina si el contenido puede enviarse a una API alojada de embeddings, almacenarse en una base vectorial compartida, incluirse en registros o utilizarse en ejemplos de evaluación.
Etapa 3: verificaciones de seguridad de archivos
Los documentos pueden ser hostiles o simplemente dañados.
Antes de la extracción:
- comprueba el tipo de archivo frente a una lista permitida,
- aplica límites de tamaño de archivo,
- escanea para malware donde tu entorno lo requiera,
- rechaza archivos cifrados salvo que exista una vía de descifrado aprobada,
- rechaza archivos con objetos incrustados no compatibles,
- normaliza los nombres de archivos,
- almacena el hash del archivo original,
- registra quién subió o conectó el archivo.
Esto es especialmente importante si usuarios no administradores pueden subir documentos. Limitar la ingesta a los administradores reduce el riesgo, pero no lo elimina.
Los controles antivirus y de desarme de contenido no son automáticos en la mayoría de los stacks RAG. Si usuarios que no son de confianza pueden subir archivos, añade una capa real de seguridad antes de analizarlos.
En la práctica, esta capa presenta varios niveles de rigor. Como mínimo, utiliza un escáner de firmas como ClamAV. Después, analiza dentro de un contenedor aislado sin acceso de salida: los parsers de PDF y formatos ofimáticos acumulan un largo historial de CVE, por lo que el propio parser debe tratarse como superficie de ataque. Para entradas que realmente no son de confianza, emplea desarme y reconstrucción de contenido (CDR), que crea una copia limpia en vez de confiar en el original. La mayoría de los pipelines para pymes necesitan los dos primeros niveles; añade CDR cuando terceros puedan enviar documentos.
Etapa 4: extracción de texto y OCR
En la práctica, los PDFs no son un solo formato. Algunos contienen texto seleccionable. Algunos son escaneados. 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: un extractor de texto para PDF nativos digitales, como PyMuPDF o pdfplumber; un conversor que respete el diseño para documentos estructurados, como Docling o Unstructured, que conserva mucho mejor las tablas y el orden de lectura; y OCR solo para escaneos reales, con Tesseract como opción base de alojamiento propio o un servicio en la nube cuando la calidad del escaneo sea baja y la clasificación de datos lo permita.
En cuanto a los umbrales, no adoptes un valor de corte universal para la confianza del OCR a partir de una entrada de blog: calíbralo con una muestra de tus propios documentos. Lo útil es establecer dos bandas: por debajo de la inferior, la página se rechaza directamente; entre ambas, se envía a revisión humana; por encima de la superior, continúa por el pipeline. La ubicación de esas bandas depende del escáner, la antigüedad de los documentos y el idioma.
Una nota específica para nuestro mercado: el OCR en estonio es más difícil que en inglés. Tesseract incluye un modelo para estonio, pero la precisión con õ/ä/ö/ü, archivos mecanografiados antiguos y documentos mixtos en estonio y ruso varía lo suficiente como para justificar una comparación piloto con una muestra representativa del archivo propio antes de elegir un motor. Para una empresa estonia, dedicar medio día a este piloto evita después una cuarta parte de los fallos silenciosos de recuperación.
Rastrea la calidad de extracción:
- método de extracción,
- confianza de OCR,
- número de páginas,
- número 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. Envíala a revisión o márcala como de baja confianza.
Problemas comunes:
- columnas leídas en el orden incorrecto,
- filas de tablas fusionadas incorrectamente,
- encabezados repetidos en cada fragmento,
- páginas escaneadas perdidas 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, verifica visualmente la página renderizada contra el texto extraído.
Etapa 5: preservar estructura
Los sistemas RAG necesitan más que texto. Necesitan suficiente estructura para producir respuestas útiles y fundamentadas en fuentes.
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 efectiva,
- URL de la fuente o ruta de almacenamiento.
Fragmenta el texto con encabezados y referencias de página. Un fragmento que dice “Lo siguiente aplica” sin el encabezado anterior es evidencia débil.
Para tablas, decide si:
- mantener la tabla como Markdown,
- convertirla a JSON estructurado,
- almacenar tanto el texto como las filas estructuradas,
- excluirla hasta que esté disponible un mejor analizador.
No pretendas que la extracción de tablas esté resuelta si tu caso de uso depende de precios exactos, fechas, límites o umbrales.
Etapa 6: incorporar 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 permiten que la aplicación aplique las políticas después de la recuperación. Sin ellos, el modelo recibe texto separado de las reglas que garantizan un uso seguro.
Etapa 7: mapeo de permisos
El mapeo de permisos debe ocurrir antes de que los resultados de recuperación lleguen al modelo.
Buen patrón:
- El usuario hace una pregunta.
- La aplicación deriva el inquilino, el usuario, los roles, los grupos y los permisos de datos desde la autenticación.
- El recuperador filtra los fragmentos candidatos por permisos.
- La clasificación se realiza entre los fragmentos permitidos.
- El modelo recibe solo los fragmentos permitidos.
Patrón incorrecto:
- Recuperar ampliamente.
- Enviar todos los fragmentos probables al modelo.
- El prompt indica “responde solo con fragmentos a los que el usuario pueda acceder”.
El patrón incorrecto ya ha expuesto los datos al contexto del modelo.
Si los permisos de la fuente son complejos, comienza más estrecho. Es mejor omitir una respuesta que filtrar un documento confidencial.
Etapa 8: fragmentación y embeddings
La fragmentación es una decisión de seguridad y calidad, no solo 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 fuentes.
- Evita fragmentos gigantes que contengan secciones no relacionadas.
- Evita fragmentos muy pequeños que pierdan contexto.
- Vuelve a generar los embeddings cuando cambien el texto de origen o los metadatos.
- Almacena el modelo de embeddings y su versión.
Para las fuentes sensibles, confirma que el proveedor de embeddings, la base vectorial y los registros estén aprobados para esa clase de datos.
Etapa 9: puertas de calidad
Antes de publicar una fuente en recuperación de producción, ejecuta verificaciones:
- todos los documentos tienen responsables,
- todos los fragmentos tienen metadatos de permisos,
- los documentos antiguos están marcados,
- las páginas con extracción fallida se excluyen o revisan,
- 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 de fuentes válidas,
- instrucciones sospechosas en documentos se aíslan como contenido, no se siguen.
El último punto es importante. Los documentos pueden contener inyecciones de prompts. El pipeline de ingesta no debe eliminar todo ese texto, porque a veces los usuarios necesitan saber qué dice un documento. Sin embargo, durante la ejecución debe tratarse como contenido no fiable del documento.
Etapa 10: conservación y eliminación (aquí entra el artículo 17 del RGPD)
Los sistemas RAG suelen conservar los datos durante más tiempo que el sistema de origen.
En esta etapa, el derecho de supresión del RGPD (artículo 17) se convierte en un requisito de ingeniería, no solo en una declaración de políticas: cuando llega una solicitud de supresión, “hemos eliminado el archivo de origen” no es una respuesta defendible si persisten copias en otras partes del pipeline. La eliminación debe abarcar:
- caché del archivo original,
- texto extraído,
- fragmentos,
- embeddings,
- resúmenes,
- miniaturas o páginas renderizadas,
- muestras de evaluación,
- registros, cuando la ley exija eliminarlos,
- copias de seguridad según la política.
Cuando un documento se elimina o se revoca el acceso, la recuperación debe dejar de devolver sus fragmentos. Idealmente, el sistema debe admitir eliminación dura para fuentes sensibles y conservación documentada para copias de seguridad.
Rastrea:
- deletedAt,
- deletedBy o evento de fuente,
- razón de eliminación,
- estado de limpieza de todos los derivados,
- resultado de verificación.
No dependas de “lo eliminamos de la interfaz”. Las bases de vectores y cachés son fáciles de olvidar.
Etapa 11: responsabilidad operativa
Cada fuente necesita una persona responsable, y cada responsable necesita una periodicidad de revisión.
Para cada fuente, define:
- quién aprueba la ingesta,
- quién aprueba los cambios de permisos,
- quién revisa los documentos antiguos,
- quién maneja los fallos de extracción,
- quién responde a las solicitudes de eliminación de datos,
- quién investiga los errores de recuperación.
Si nadie se responsabiliza de una fuente, esta no debe estar en un sistema RAG de producción.
La conclusión
La ingesta segura de RAG es aburrida en el mejor sentido: hace que la recuperación sea predecible.
Los controles principales:
- registrar fuentes,
- clasificar datos,
- verificar archivos antes de analizarlos,
- medir la calidad de extracción,
- preservar estructura,
- incorporar metadatos,
- aplicar permisos antes de la recuperación,
- probar el acceso no autorizado,
- admitir la eliminación,
- asignar responsables.
Las buenas respuestas proceden de buenas fuentes. Las respuestas seguras, de buenos controles sobre esas fuentes.
