Casi todas las guías sobre RAG explican la arquitectura: embeddings, base de datos vectorial, modelo de lenguaje que redacta la respuesta. Esa parte, en realidad, es la más estandarizada del proyecto. Lo que decide si un sistema RAG funciona en producción o se queda en una demo que nadie vuelve a abrir es lo que pasa antes: qué documentos entran, en qué estado están, quién puede verlos y quién se encarga de que sigan actualizados dentro de un mes. Esta guía recorre ese trabajo paso a paso, con el nivel de detalle que suele faltar cuando se busca «cómo preparo mis datos para un RAG» y solo aparecen explicaciones de la arquitectura.
Antes de empezar: qué son, en la práctica, «los datos de tu empresa»
El término «datos de empresa» esconde al menos tres tipos de información que se preparan de forma distinta. Los documentos no estructurados —manuales, procedimientos, contratos, correos, actas— son el caso típico de RAG: se trocean, se convierten en vectores y se recuperan por significado. Los datos estructurados —tablas del ERP, catálogos de producto, históricos del CRM— casi nunca se benefician de trocearse como si fueran texto libre: suelen resolverse mejor con consultas directas a la base de datos, a veces traducidas de lenguaje natural a SQL, y solo entran en el índice vectorial cuando hace falta buscarlos por significado en lugar de por campo exacto. Y existe un tercer grupo, mixto, que combina ambos: una ficha de producto con texto descriptivo y campos técnicos, un expediente con documentos adjuntos y metadatos de estado.
Confundir estos tres tipos es un error de enfoque habitual: alguien empieza a trocear una exportación de Excel como si fuera un manual, o intenta responder «¿cuál es el stock del artículo X-220?» con un buscador semántico que nunca va a leer un número que cambia cada hora. Antes de decidir herramienta o proveedor conviene clasificar cada fuente candidata en uno de estos tres grupos, porque esa clasificación es la que determina el resto de decisiones técnicas de esta guía.
La calidad de un sistema RAG depende más de cómo se prepara el corpus que del modelo de lenguaje elegido para redactar las respuestas. Un modelo excelente sobre datos desordenados sigue dando respuestas desordenadas; solo que ahora suenan convincentes.
Paso 1 — Inventariar antes de indexar nada
Mapea las fuentes reales, no solo las del organigrama de sistemas
El listado de repositorios «oficiales» —el gestor documental, el ERP, la intranet— casi nunca coincide con el listado real de sitios donde vive el conocimiento de la empresa. Hay procedimientos que solo existen en el disco de un ordenador concreto, hilos de correo que sustituyen a un manual que nadie actualizó y hojas de cálculo compartidas que funcionan como base de datos no oficial. El inventario tiene que salir de preguntar a las personas que usan esa información a diario, no solo de mirar el diagrama de sistemas de TI.
Clasifica cada fuente por sensibilidad
Cada fuente candidata necesita una etiqueta de sensibilidad antes de entrar en el proyecto: pública (folletos, contenido ya publicado), interna (procedimientos y políticas sin restricción especial), confidencial (contratos, condiciones económicas, informes internos) y datos personales (expedientes de empleados, historiales de clientes, currículums). Esta clasificación no es un trámite: determina si la fuente puede indexarse tal cual, si necesita anonimización previa o si simplemente se queda fuera del alcance inicial del proyecto.
Marca lo que sobra: duplicados y versiones muertas
Es habitual encontrar dos o tres versiones vivas del mismo procedimiento, revisiones antiguas que nadie retiró del repositorio y borradores guardados junto a la versión definitiva. Indexar todo eso sin depurarlo traslada el problema al sistema: el RAG citará, con total confianza, la versión que no toca. Resolver esta depuración en la fase de inventario cuesta bastante menos que descubrir el problema después de que alguien haya seguido un procedimiento derogado porque el sistema se lo recomendó.
Paso 2 — Poner en orden los datos personales antes de que entren en el índice
Si alguna de las fuentes que vas a indexar contiene datos personales —currículums, historiales de cliente, correspondencia con nombres y circunstancias personales—, ese tratamiento sigue sujeto al Reglamento (UE) 2016/679 (RGPD) exactamente igual que cualquier otro tratamiento de datos personales de la empresa. Montar un RAG no crea una excepción ni una base jurídica nueva: hay que poder justificar por qué esos datos se tratan, informar a las personas afectadas cuando corresponda y aplicar medidas de seguridad proporcionadas al riesgo, igual que se exigiría a cualquier otro sistema que accede a esa información.
En la práctica, esto se traduce en decisiones concretas antes de indexar: si el dato personal es imprescindible para responder a las preguntas previstas o puede sustituirse por una referencia genérica; si conviene anonimizar o seudonimizar los fragmentos antes de convertirlos en vectores; y quién, dentro de la empresa, es responsable de revisar esa fuente si una persona afectada ejerce sus derechos. Cuando el volumen de datos personales es alto o su naturaleza es especialmente sensible, conviene documentar una evaluación de impacto antes de poner el sistema en producción, no después.
Paso 3 — Decidir dónde van a vivir los datos y el modelo
Antes de elegir proveedor de modelo de lenguaje o base de datos vectorial hay una decisión previa: ¿los documentos y el índice pueden salir de la infraestructura de la empresa, o alguna cláusula contractual, requisito sectorial o simplemente el nivel de sensibilidad de los datos lo desaconseja? Si la respuesta es que los datos deben permanecer bajo control directo de la empresa, la opción es un sistema con el índice vectorial y, en los casos más exigentes, el propio modelo de lenguaje desplegados en infraestructura propia o en una nube con residencia de datos garantizada en la Unión Europea: es la vía que trabajamos en IA soberana y on-premise para empresas, con el coste operativo adicional que conlleva frente a usar directamente una API en la nube.
Si no hay ninguna restricción de ese tipo, usar un proveedor en la nube suele ser más rápido de poner en marcha y más barato de mantener. Lo importante es tomar esta decisión de forma explícita al principio del proyecto, con quien tenga la última palabra sobre el dato —dirección, asesoría legal, responsable de seguridad—, no dejar que la decida por defecto quien elige la biblioteca técnica.
Paso 4 — Convertir los documentos en algo que un índice pueda leer
Un PDF escaneado sin capa de texto, una tabla incrustada en una imagen o un documento con el formato roto tras varias conversiones no se pueden indexar tal cual: primero hay que extraer el texto de forma fiable, con OCR cuando haga falta, y reconstruir la estructura mínima —títulos, tablas, listas— para que el troceado posterior no corte una cláusula o una fila de tabla por la mitad. Esta fase de procesamiento inteligente de documentos suele ser la que más tiempo consume del proyecto entero, y también la que más condiciona el resultado: un error de OCR que cambia una cifra en un contrato se traslada directamente a la respuesta que el sistema le da al usuario.
Conviene también normalizar formatos de origen distintos —Word, PDF, HTML de intranet, exportaciones de correo— a una representación común antes del troceado, de modo que la lógica de chunking no tenga que lidiar con las particularidades de cada formato una por una.
Paso 5 — Diseñar el troceado según el tipo de documento
Un punto de partida habitual está entre 200 y 512 tokens por fragmento, con un solapamiento del 10-25% entre fragmentos consecutivos —Azure AI Search, por ejemplo, recomienda arrancar en 512 tokens y un 25% de solapamiento—, pero ningún tamaño funciona igual de bien para todos los documentos. Un contrato se trocea mejor por cláusula, para no separar una condición de su excepción. Un manual técnico se trocea mejor por sección, respetando los títulos. Un hilo de correo se trocea mejor por mensaje completo, para no perder el contexto de quién dijo qué. Aplicar el mismo criterio de troceado a los tres tipos de documento es una causa muy habitual de respuestas que citan la fuente correcta pero cortan la frase justo antes del dato importante.
El solapamiento entre fragmentos —repetir unas frases al principio del siguiente fragmento— reduce el riesgo de perder una idea que quedó justo en la frontera del corte, a cambio de un índice ligeramente mayor. Es un intercambio que casi siempre merece la pena.
Paso 6 — Heredar los permisos, no reinventarlos
Un fallo grave y evitable en muchos proyectos es que el sistema RAG termine devolviendo, a través del chat, contenido que un usuario no podía abrir directamente en el sistema de origen. Si un documento está restringido a un departamento en el gestor documental, esa misma restricción tiene que aplicarse cuando ese documento se recupera desde el índice vectorial: el permiso viaja con el fragmento, no se decide aparte. Diseñar esto desde el principio —en lugar de añadirlo como parche cuando alguien detecta el problema— evita tener que reindexar toda la base de conocimiento más adelante.
Paso 7 — Automatizar la ingesta y la actualización continua
Indexar el corpus una sola vez resuelve el arranque, pero un RAG que no se actualiza se queda obsoleto al mismo ritmo que la documentación de la empresa. Los documentos nuevos y las revisiones de los existentes deben entrar en el índice de forma incremental, sin reindexar la base completa cada vez, y las versiones retiradas deben salir del índice para que nadie reciba un procedimiento derogado. Construir este flujo como una automatización —vigilar una carpeta, escuchar los eventos del gestor documental, reindexar por lotes en un horario definido— es un trabajo habitual de automatización con n8n e IA, que conecta el sistema de origen con el proceso de indexación sin que nadie tenga que ejecutarlo a mano.
Paso 8 — Probar con preguntas reales antes de producción
Antes de dar por lista la implantación conviene reunir, junto con las personas que usarán el sistema, entre treinta y cincuenta preguntas reales de las que hoy cuesta tiempo encontrar respuesta. Ese banco de preguntas es el que decide si el sistema está listo, no una demo con dos o tres ejemplos preparados de antemano. Para cada pregunta conviene registrar si el sistema responde, si cita la fuente correcta y si la respuesta es completa; las que fallan señalan exactamente qué parte del corpus, del troceado o de la recuperación hay que revisar antes de ampliar el acceso a más usuarios.
Paso 9 — Desplegar con monitorización y mantener el corpus vivo
Un sistema RAG no se entrega y se olvida. Conviene dejar un panel con las consultas reales del día a día, marcando cuáles se resuelven con una cita útil y cuáles se quedan sin respuesta aprovechable: esas últimas señalan huecos concretos del corpus, no fallos del modelo. Revisar ese panel con regularidad, corregir o añadir los documentos que faltan y reindexar es lo que mantiene la calidad del sistema en el tiempo. Sin ese mantenimiento, un RAG que funcionaba bien en el lanzamiento se degrada al mismo ritmo al que envejece la documentación que lo alimenta.
Lo que cambia —y lo que no— con el nuevo calendario del AI Act
Si llevas meses oyendo que «en agosto de 2026 entran en vigor las obligaciones de alto riesgo del Reglamento Europeo de IA», conviene actualizar esa referencia. El Reglamento (UE) 2026/1744, en vigor desde el 27 de julio de 2026, modifica el Reglamento (UE) 2024/1689 (AI Act) y aplaza los plazos de las obligaciones para sistemas de alto riesgo: al 2 de diciembre de 2027 para los sistemas independientes recogidos en el anexo III (biometría, empleo, educación, entre otros ámbitos) y al 2 de agosto de 2028 para los sistemas integrados en productos ya sujetos a normativa de seguridad armonizada (anexo I). Las obligaciones de transparencia del artículo 50 —informar de que un contenido se ha generado con IA— siguen teniendo como referencia el 2 de agosto de 2026, aunque los proveedores de sistemas que generan contenido sintético y ya estaban en el mercado antes de esa fecha disponen, por el nuevo apartado 4 del artículo 50, hasta el 2 de diciembre de 2026 para cumplir la obligación de marcado.
Para un sistema RAG esto tiene una lectura práctica que conviene no confundir con «hay menos prisa». La mayoría de proyectos de RAG para consulta interna, atención al cliente o soporte a empleados no encajan en las categorías de alto riesgo del AI Act, así que el aplazamiento de esos plazos no les afecta de forma directa, con una excepción importante: si el RAG se usa para filtrar candidaturas o evaluar a personas en procesos de selección o de gestión de personal, entra en el anexo III.4 y sí le aplican esos plazos. Lo que no se ha movido ni un día es el RGPD: si el corpus contiene datos personales, la obligación de tratarlos con una base jurídica válida, informar a las personas afectadas y aplicar medidas de seguridad proporcionadas existe desde antes del AI Act y sigue existiendo igual, tenga o no la empresa un sistema clasificado como de alto riesgo. Si tu caso sí cae en esas categorías —o simplemente quieres tenerlo evaluado con criterio técnico en lugar de por intuición—, la gobernanza técnica de IA y AI Act de Summum IA parte precisamente de esa clasificación antes de tocar ninguna arquitectura.
El aplazamiento de los plazos de alto riesgo del AI Act no cambia las obligaciones del RGPD sobre los datos personales que puedan entrar en un RAG. Si tu proyecto maneja currículums, historiales de cliente o cualquier dato personal, esa parte del trabajo no espera a ningún calendario europeo.
Errores más frecuentes al preparar datos de empresa para un RAG
- Empezar a indexar sin haber decidido qué fuentes entran y cuáles quedan fuera, lo que obliga a rehacer el trabajo cuando aparece una fuente con datos sensibles a mitad de proyecto.
- Tratar los datos estructurados del ERP o del CRM igual que un documento de texto, en lugar de resolverlos con consultas directas a la base de datos.
- Lanzar a producción sin un banco de preguntas reales validado por el negocio.
Estos tres son los que más veces determinan si un proyecto arranca bien; hay más —cómo trocear cada tipo de documento, cómo heredar permisos, cómo mantener el índice actualizado— y los repasamos con detalle en los errores más caros de un proyecto de RAG.
Preguntas frecuentes
¿Por dónde empiezo si tengo documentación repartida en varios sistemas?
Por el inventario, no por la tecnología. Antes de elegir base de datos vectorial o proveedor de modelo, identifica qué repositorios existen de verdad (incluidos los no oficiales), quién es el propietario de cada uno y qué nivel de sensibilidad tiene. Esa lista es la que determina el alcance real del proyecto y el orden en que conviene abordar cada fuente.
¿Es obligatorio anonimizar los documentos antes de indexarlos?
No de forma automática, pero sí hay que evaluarlo caso por caso cuando la fuente contiene datos personales. La anonimización o seudonimización tiene sentido cuando el dato personal no aporta valor a la respuesta que va a dar el sistema; cuando sí lo aporta —por ejemplo, el nombre de un cliente en su propio expediente—, la alternativa es controlar el acceso y documentar el tratamiento conforme al RGPD, no eliminar el dato.
¿Cuánto tiempo lleva preparar los datos frente a montar la arquitectura técnica?
En la mayoría de proyectos, más. Componer la arquitectura de recuperación, indexado y generación es un trabajo relativamente estandarizado; encontrar al propietario de cada fuente, depurar duplicados, decidir el troceado por tipo de documento y validar los permisos es trabajo artesanal que no se puede comprimir sin perder calidad en el resultado.
¿El aplazamiento de los plazos del AI Act significa que puedo esperar para ordenar mis datos?
No. El aplazamiento afecta a los plazos de las obligaciones de alto riesgo del AI Act, que probablemente ni siquiera se aplican a un RAG interno de consulta o atención al cliente, con una excepción importante: si el RAG se usa para filtrar candidaturas o evaluar a personas en procesos de selección o de gestión de personal, entra en el anexo III.4 y sí le aplican esos plazos. El RGPD, que es el marco que de verdad determina cómo tratar los datos personales dentro de un RAG, no ha cambiado con este aplazamiento.
¿Qué pasa si la documentación tiene errores o está desactualizada?
El sistema los reproducirá con la misma seguridad con la que reproduce la información correcta, porque no tiene forma de distinguir un procedimiento vigente de uno obsoleto si ambos están indexados. Por eso la fase de inventario y depuración de duplicados no es opcional: es la que evita que el RAG amplifique errores que ya existían en la documentación de origen.
Preparar los datos de tu empresa para un RAG es, sobre todo, un trabajo de orden: saber qué tienes, quién puede verlo y en qué estado está antes de convertirlo en algo que un modelo de lenguaje pueda leer. Si quieres revisar el estado real de tus fuentes antes de decidir arquitectura, el equipo de RAG y búsqueda interna con IA de Summum IA puede acompañar ese diagnóstico, junto con el procesamiento de documentos y la revisión de gobernanza que exige un proyecto de este tipo.