RAG y Document Intelligence: Cómo la IA entiende tus documentos

La pregunta central: ¿Puede la IA entender nuestros propios documentos?

“¿Podemos hacer que la IA responda a partir de nuestros propios documentos?” Esta pregunta surge en prácticamente todas las empresas. La respuesta es sí, con RAG (Retrieval Augmented Generation). El principio: tus documentos permanecen en tu infraestructura. El modelo de lenguaje no se entrena con tus datos. En su lugar, las secciones relevantes de los documentos se proporcionan al modelo como contexto con cada consulta. El modelo responde en base a esas secciones, con citas de fuentes.

Sin fuga de datos a terceros. Sin reentrenamiento. Sin pérdida de control. Y aun así, respuestas en lenguaje natural basadas directamente en el conocimiento de tu organización.

RAG es hoy el enfoque estándar para conectar modelos de lenguaje con conocimiento específico de la organización. Este artículo explica cómo funciona RAG, cuándo es la opción correcta y por qué Document Intelligence va mucho más allá de un mejor buscador, incluyendo anonimización PII, redacción de contratos y detección de firmas.

Cómo funciona RAG

RAG consta de dos fases: la indexación de tus documentos y la respuesta a consultas. El flujo se puede ilustrar en un diagrama:

Documentos → Chunking → Embedding → Base de datos vectorial
                                         │
Consulta del usuario → Query Embedding → Búsqueda por similitud
                                         │
                              Secciones relevantes + Consulta → LLM → Respuesta con cita de fuente

Fase 1: Indexación. Tus documentos – PDFs, archivos Word, páginas HTML, recibos escaneados – se dividen en secciones significativas (chunking). Cada sección se convierte mediante un modelo de embedding en un vector matemático. Estos vectores se almacenan en una base de datos vectorial. El vector representa el significado de la sección, no su redacción literal. “Política de teletrabajo” y “Acuerdo de trabajo a distancia” se encuentran próximos en el espacio vectorial, aunque usen palabras diferentes.

Fase 2: Consulta. Cuando un usuario formula una pregunta, esta también se convierte en un vector. La base de datos vectorial encuentra las secciones semánticamente más cercanas a la pregunta, no por búsqueda de palabras clave, sino por cálculo de similitud. Estas secciones relevantes se envían al modelo de lenguaje junto con la pregunta original. El modelo genera una respuesta basada en esas fuentes concretas.

El resultado: una respuesta en lenguaje natural fundamentada en tus documentos, con referencias a los pasajes fuente de donde procede la información.

La calidad de la indexación es decisiva. Chunks demasiado grandes diluyen la relevancia. Chunks demasiado pequeños pierden el contexto. La estrategia de chunking – tamaño, solapamiento, enriquecimiento con metadatos – determina en gran medida la calidad de las respuestas. Un buen pipeline RAG no es la tecnología en sí, sino su configuración para tu paisaje documental específico.

RAG vs. Fine-Tuning vs. Prompting

RAG no es la única forma de dotar a un modelo de lenguaje con conocimiento de dominio. Existen tres enfoques fundamentales que difieren en esfuerzo, coste e idoneidad:

Enfoque	Qué ocurre	Cuándo es adecuado	Coste	Actualización
Prompting	Contexto incluido directamente en el prompt	Volúmenes de datos pequeños	Bajo	Inmediata
RAG	Documentos relevantes encontrados automáticamente	Grandes bases de conocimiento	Medio	Re-indexación
Fine-Tuning	Modelo reentrenado	Lenguaje especializado/dominio	Alto	Solo mediante reentrenamiento

Prompting funciona cuando el contexto relevante cabe en la ventana de contexto del modelo, típicamente unas decenas de páginas. Para un único acuerdo de empresa, es suficiente. Para una base de conocimiento con cientos de documentos, no.

RAG escala a grandes colecciones documentales. La base de datos vectorial puede contener cientos de miles de secciones. Con cada consulta, solo se recuperan y envían al modelo las secciones relevantes. Los documentos pueden actualizarse en cualquier momento; basta una re-indexación. No es necesario reentrenar el modelo.

Fine-Tuning modifica los pesos del propio modelo. Es apropiado cuando el modelo necesita aprender un lenguaje de dominio completamente nuevo – por ejemplo, terminología médica o una nomenclatura propietaria – o cuando se requiere un formato de respuesta muy específico. El Fine-Tuning es costoso, complejo y requiere reentrenamiento con cada actualización.

Para el 90% de los casos de uso empresarial, RAG es el enfoque correcto. La combinación de grandes bases de conocimiento, actualizaciones frecuentes y la necesidad de citas de fuentes convierte a RAG en el estándar para el conocimiento corporativo.

Document Intelligence: más que búsqueda

RAG responde preguntas basándose en documentos. Document Intelligence va más allá: abarca todos los métodos mediante los cuales la IA no solo lee documentos, sino que los entiende, clasifica y procesa, incluyendo la protección de información sensible.

Las tres áreas de aplicación más importantes en el contexto empresarial: anonimización PII, redacción de contratos y detección de firmas.

Anonimización PII: pseudonimización de ida y vuelta

Los datos personales (PII, Personally Identifiable Information) no pueden enviarse a un modelo de lenguaje en muchos casos de uso. Salarios, nombres reales, números de empleado, datos de salud. El RGPD y las políticas internas de protección de datos establecen límites claros.

La solución es la pseudonimización de ida y vuelta (roundtrip). Un ejemplo concreto:

Documento original: “María García, Departamento de Finanzas, salario 42.000 euros, se adhiere al acuerdo de empresa sobre horario flexible.”

Tras la pseudonimización (entrada al modelo): “Persona_A, Departamento_X, Salario_Y, se adhiere al acuerdo de empresa sobre horario flexible.”

El modelo de lenguaje procesa la consulta con datos pseudonimizados. En ningún momento ve el nombre real, el departamento ni el salario.

Tras la re-identificación (salida al usuario): Los marcadores en el resultado se reemplazan por los datos originales. El usuario ve la respuesta completa. El modelo nunca la vio.

Este ciclo ocurre automáticamente. Para el usuario, el proceso es transparente. Para el modelo, los datos son inaccesibles en todo momento. Para la infraestructura esto significa: la capa de pseudonimización se sitúa entre el usuario y el modelo y se aplica de forma técnica, no opcional.

La anonimización PII es especialmente relevante para aplicaciones de RRHH, donde expedientes de personal, nóminas o evaluaciones de rendimiento deben procesarse con ayuda de IA. Sin anonimización, estos casos de uso no son conformes con el RGPD en la UE.

Redacción de contratos (Redaction)

La redacción de contratos va más allá de la pseudonimización. Mientras la pseudonimización sustituye datos y los restaura al final, la redacción elimina físicamente el contenido del documento, de forma irrevocable para el destinatario correspondiente.

El caso de uso: distintos departamentos necesitan vistas diferentes del mismo contrato. El departamento jurídico ve el contrato completo. Compras ve una versión sin cláusulas de responsabilidad. La dirección ve un resumen sin detalles operativos.

La redacción funciona con reglas. Para cada categoría de documento y cada grupo de destinatarios se define qué secciones son visibles y cuáles se redactan. Las reglas se configuran y versionan en el Decision Layer, no se aplican manualmente.

El resultado: cada rol ve exactamente la información que es relevante y está autorizada para él. Sin redacción manual. Sin pasajes olvidados. Sin versiones reenviadas accidentalmente en su totalidad.

Detección de firmas

Los archivos de contratos en las empresas suelen contener miles de documentos. La pregunta de si un contrato específico está completamente firmado requiere hoy a menudo un repaso manual página por página. Con cientos de contratos, esto no es viable.

Document Intelligence resuelve este problema mediante la detección automatizada de firmas. El sistema comprueba contratos escaneados en busca de firmas en las ubicaciones previstas. Las firmas faltantes se señalan automáticamente. El resultado: una visión general de todos los contratos del archivo que aún no están completamente firmados, en minutos en lugar de semanas.

El caso de uso va más allá de la mera detección. En combinación con un pipeline RAG, el sistema también puede responder preguntas como: “¿Qué contratos marco con una duración superior a 3 años se renovaron en el último trimestre sin firma de la dirección?”

Ejemplo práctico: El asistente de acuerdos de empresa

Un escenario concreto de la práctica de RRHH. Un departamento de personal de una empresa mediana gestiona más de 100 acuerdos de empresa activos: jornada laboral, teletrabajo, viajes de trabajo, formación, planes de jubilación, gestión de la reincorporación, protección de datos, uso de TI, y más. Cada acuerdo tiene modificaciones, anexos y referencias cruzadas a otros acuerdos.

Cuando un administrativo debe responder la pregunta: “¿Qué normativa aplica para días de teletrabajo de empleados a tiempo parcial en producción?”, hoy eso significa: encontrar el acuerdo de empresa correcto, localizar el pasaje relevante, comprobar si existe una modificación, cotejar con el convenio colectivo, considerar las normas específicas del centro de trabajo. Resultado: de 30 a 45 minutos de búsqueda. En caso de duda, consulta al departamento jurídico. Otros días más de espera.

Con un asistente de acuerdos de empresa basado en RAG: todos los acuerdos se indexan, incluyendo modificaciones, anexos y referencias cruzadas. El administrativo formula la pregunta en lenguaje natural. El sistema encuentra los pasajes relevantes de los documentos correctos, tiene en cuenta la modificación de marzo de 2025, referencia la normativa especial para empleados de producción y entrega la respuesta en 10 segundos. Con cita de fuente. Con versión de la norma.

Esto no es un escenario teórico. Es el caso de uso estándar con el que las empresas implementan su primer pipeline RAG. El esfuerzo es asumible: proporcionar documentos, configurar la estrategia de chunking, definir derechos de acceso, probar. La infraestructura – base de datos vectorial, modelo de embedding, modelo de lenguaje, pipeline de recuperación – se construye una vez y queda disponible para casos de uso adicionales.

Aseguramiento de calidad: Por qué los resultados RAG son tan buenos como la indexación

RAG no funciona solo. Las fuentes de error más comunes en la práctica:

Mala estrategia de chunking. Chunks demasiado grandes (capítulos enteros) proporcionan demasiado contexto irrelevante. Chunks demasiado pequeños (párrafos individuales) pierden la coherencia. El tamaño de chunk adecuado depende del tipo de documento: una especificación técnica requiere chunks diferentes que un acuerdo de empresa.

Metadatos ausentes. Sin metadatos (tipo de documento, fecha de vigencia, versión, ámbito de aplicación) el pipeline de recuperación no puede distinguir entre una normativa vigente y una obsoleta. El enriquecimiento de metadatos durante la indexación no es opcional, es esencial.

Sin control de acceso. En un entorno empresarial, no todos los usuarios deben acceder a todos los documentos. El pipeline RAG debe reflejar la estructura de permisos existente: documentos de RRHH solo para RRHH, datos financieros solo para Finanzas, comunicaciones de dirección solo para personas autorizadas.

Sin verificación de fuentes. RAG proporciona citas de fuentes. ¿Pero son correctas? Un aseguramiento de calidad – comprobación aleatoria de referencias, mecanismo de retroalimentación para usuarios, evaluación periódica – es necesario para detectar alucinaciones y mejorar el pipeline.

Este aseguramiento de calidad forma parte de la operación continua, no de una configuración inicial única. Los documentos cambian. Se añaden nuevos. Los antiguos dejan de ser válidos. El pipeline RAG debe evolucionar, mediante re-indexación periódica, actualización de metadatos y retroalimentación de los usuarios.

Integración en el portal Enterprise AI

RAG no es un sistema aislado. En una arquitectura bien diseñada, el pipeline RAG está integrado en el portal Enterprise AI. Los empleados formulan preguntas a través de una interfaz unificada, la misma a través de la cual interactúan con los agentes de IA.

El portal gestiona los derechos de acceso: ¿quién puede consultar qué base de conocimiento? Los empleados de RRHH ven el asistente de acuerdos de empresa. El departamento jurídico ve el asistente de contratos. Compras ve el asistente de directrices de proveedores. Cada usuario ve solo aquello para lo que está autorizado.

La combinación de RAG y agentes de IA abre posibilidades ampliadas: un agente puede no solo responder una pregunta, sino, basándose en los resultados RAG, desencadenar una acción – por ejemplo, generar una alerta de vencimiento cuando un contrato está a punto de expirar, o crear una lista de verificación cuando un nuevo acuerdo de empresa entra en vigor.

---

Enterprise AI-Infrastruktur Blueprint 2026 – Serie de artículos

← Anterior	Visión general	Siguiente →
Portal Enterprise AI: Cuatro interfaces Open Source en comparación	Visión general	De chatbots a agentes IA: MCP, A2A y sistemas Multi-Agent

Todos los artículos de esta serie: Enterprise AI-Infrastruktur Blueprint 2026

---

¿Quieres hacer accesible el conocimiento de tu empresa para la IA? Gosign construye pipelines RAG y soluciones de Document Intelligence para clientes empresariales – agnóstico en cuanto a modelos, con anonimización PII y control de acceso completo.

Reserva una consulta. 30 minutos para determinar qué documentos deberían hacerse accesibles para la IA primero.