RAG en la empresa: arquitectura y buenas prácticas 2026

Q: ¿Cuándo elegir RAG en lugar de fine-tuning?

RAG es generalmente preferible al fine-tuning en 2026 para: conocimiento que evoluciona con regularidad (políticas, procedimientos, catálogo de productos), múltiples fuentes a citar, necesidad de transparencia sobre el origen de la información, equipos sin experiencia data science. Fine-tuning preferible para: estilo o tono específico a aprender de forma duradera, terminología ultra-especializada, latencia muy crítica. La mayoría de casos de uso empresariales se benefician de comenzar con RAG; el fine-tuning entra como complemento o segunda opción si el RAG por sí solo no basta.

Q: ¿Qué base vectorial elegir para RAG?

Para pymes y PoC: Qdrant (open-source, autohospedable, sencillo, la opción soberana de referencia en 2026), Chroma (muy simple, bueno para empezar), pgvector (extensión PostgreSQL, ideal si ya usa Postgres). Para producción a gran escala: Qdrant en cluster, Weaviate, Milvus. Para máxima soberanía: autohospedado en Stackscale, Arsys, Acens, OVHcloud Madrid o nubes españolas certificadas ENS. A evitar para datos sensibles: vectoriales SaaS estadounidenses (Pinecone, ciertas ofertas gestionadas) que reintroducen el riesgo de transferencia internacional que el RAG debía evitar.

Q: ¿Cuánto cuesta un RAG en producción?

Para una pyme española con 1.000 documentos y 100 usuarios: 50 a 200 € al mes de funcionamiento (LLM vía API + base vectorial autohospedada + almacenamiento). Inversión inicial de integración: 5 a 25 k€ según complejidad (número de fuentes, integraciones SI, calidad de la UI). Para gran organización con más de 100.000 documentos: 500 a 3.000 € al mes. ROI típico en 6 a 12 meses si la adopción se sostiene, principalmente por ahorro de tiempo de búsqueda documental y descenso del volumen de tickets de soporte de nivel 1.

Q: ¿Es el RAG conforme al RGPD?

El RAG es un tratamiento automatizado que debe inscribirse en el registro de actividades de tratamiento (artículo 30 RGPD). Si la base contiene datos personales, EIPD recomendada y obligatoria en ciertos casos (volúmenes elevados, categorías especiales, vigilancia). Hospedaje: LLM + base vectorial en infraestructura soberana española o europea (Stackscale, OVHcloud Madrid, Scaleway) para evitar el riesgo DPF. Control de acceso indispensable: un usuario solo debe ver los chunks a los que tiene acceso legítimo en la documentación origen. Las directrices de la AEPD sobre IA y protección de datos marcan el estándar.

Q: ¿Qué diferencia hay entre RAG y un agente IA?

Un RAG responde a una pregunta apoyándose en documentos internos — es un componente. Un agente IA decide una sucesión de acciones (búsqueda RAG, llamada API, redacción, validación humana) para cumplir una misión de alto nivel — es un sistema. RAG es un componente que se encuentra a menudo en los agentes. Empezar por un RAG es más simple, más previsible y menos arriesgado que un agente autónomo.

Q: ¿Alucina siempre el RAG?

Sí, pero mucho menos que un LLM solo. RAG obliga al LLM a fundamentarse en documentos provistos, lo que reduce drásticamente las alucinaciones factuales — típicamente del 90 % a menos del 5 % en preguntas cuya respuesta está en el corpus. Las alucinaciones residuales surgen cuando: los documentos no contienen la respuesta (el LLM inventa en vez de decir 'no sé'), el LLM extrapola pese al contexto, o los documentos son contradictorios. Un buen RAG siempre incluye citación de fuentes.

Q: ¿Cuánto se tarda en poner un RAG en producción?

PoC funcional: 1 a 2 semanas con un equipo de desarrollo cómodo con APIs LLM. Piloto en producción restringida (10-50 usuarios): 4 a 8 semanas adicionales (integración de fuentes, control de acceso, monitorización, formación). Industrialización completa: 3 a 6 meses según complejidad. El cuello de botella no suele ser la tecnología (LangChain, LlamaIndex y Haystack están maduros), sino la ingesta de fuentes y la gobernanza de accesos.

Quick Answer: ¿qué es el RAG en la empresa?

RAG (Retrieval-Augmented Generation, literalmente «generación aumentada por recuperación») es la arquitectura IA más desplegada en empresas españolas en 2026 para hacer que un gran modelo de lenguaje responda a partir de su propia documentación. El principio es simple, comparable a un consultor que abre los expedientes antes de responder:

El usuario formula una pregunta en lenguaje natural.
El sistema busca los documentos relevantes en una base de conocimiento preparada (la «base vectorial»: cada documento se almacena como una firma numérica para poder recuperar rápidamente los que se parecen a la pregunta).
Los documentos relevantes se insertan en el prompt enviado al LLM.
El LLM genera una respuesta anclada en esos documentos, con citación de fuentes.

Stack de referencia 2026 para el mercado español:

LLM: Mistral Large o Mistral Small 3 (soberano UE), MarIA del BSC-CNS (modelo del Barcelona Supercomputing Center, especializado en español), Salamandra (también del BSC-CNS, multilingüe ibérico), Llama 3.1/3.3 70B autohospedado, GPT-4o o Claude (si se acepta dependencia DPF).
Embeddings: E5-Multilingual (excelente en castellano), BETO embeddings (modelo BERT en español de la Universidad de Chile, ampliamente adoptado), MarIA-Sentence, BGE-M3, Mistral Embed. Para corpus puramente español: modelos especializados como PlanTL-GOB-ES/roberta-base-bne y derivados.
Base vectorial: Qdrant (autohospedable, referencia 2026), Weaviate, Milvus, pgvector si PostgreSQL ya está en el stack, Chroma para prototipos iniciales.
Orquestación: LangChain, LlamaIndex, Haystack — los tres son maduros y aptos para producción.

Casos de uso predominantes en España: retail y e-commerce (Inditex, Mercadona, Mango, El Corte Inglés ya operan RAGs sobre catálogos masivos), banca y seguros bajo supervisión del Banco de España (BBVA, Santander, CaixaBank, Mapfre), turismo y hostelería (búsqueda en bases de conocimiento operacionales multipropiedad), administración pública con DataCentric / Red.es / proyectos del Plan de Recuperación, sector legal en despachos como Cuatrecasas o Garrigues.

Por qué RAG y no fine-tuning: RAG es más simple, más mantenible, más transparente. Fine-tuning solo se justifica en casos muy específicos.

Coste: 50 a 200 € al mes de funcionamiento para una pyme, 5 a 25 k€ de inversión inicial.

Por qué RAG se impuso en 2026

Antes de 2024, integrar el conocimiento interno de una empresa en un LLM significaba fine-tuning — largo, costoso, frágil. RAG dio la vuelta a la ecuación por tres razones.

Cambio 1 — Madurez de los LLM long-context. Mistral, GPT-4o, Claude, Llama 3.3 y MarIA gestionan en 2026 contextos de 100.000 a 1 millón de tokens. Se pueden proporcionar decenas de páginas de documentos como input — exactamente lo que el RAG necesita. Antes de 2024, el límite de 8-32k tokens forzaba a compromisos duros sobre la cantidad de contexto; esa fricción ha desaparecido.

Cambio 2 — Madurez de las bases vectoriales open-source. Qdrant, Weaviate, Milvus, Chroma y pgvector permiten en 2026 desplegar una base vectorial productiva en pocas horas, gratis o a muy bajo coste. Antes de 2023 había que recurrir a Pinecone (SaaS estadounidense) o construir el stack propio. Hoy: Qdrant autohospedado en Stackscale, OVHcloud Madrid o Arsys, en pocos comandos.

Cambio 3 — Simplicidad de integración. LangChain y LlamaIndex han estabilizado los patrones de integración. Una pyme española puede prototipar un RAG en 1-2 semanas con un equipo técnico modesto. Los frameworks gestionan ingesta, chunking, embedding, retrieval, generación con citación.

Concretamente: en 2026, toda organización española con una base documental interna (>500 documentos) gana al explorar el RAG. Se ha vuelto accesible, previsible, y el ROI se mide en meses.

Arquitectura detallada de un RAG en producción

Una pipeline RAG madura en 2026 comprende seis componentes. Esquema y luego detalle.

Esquema de la pipeline

[Fuentes documentales]
   SharePoint, GED, wiki, Drive, CRM, ERP
            │
            ▼
[1. Ingesta] ─── parseo PDF/DOCX/HTML, OCR si escaneado
            │
            ▼
[2. Chunking] ─── división en pasajes 200-1000 tokens
            │
            ▼
[3. Embeddings] ─── firma numérica por chunk
            │
            ▼
[4. Base vectorial] ── almacenamiento Qdrant / Weaviate / pgvector
            │
            ├──── (en runtime, consulta usuario)
            ▼                              │
[5. Retrieval] ◄─────────────────── embedding consulta
       │       top-K chunks                │
       ▼                                   │
[6. Generación] ─── LLM con contexto ◄─────┘
       │
       ▼
[Respuesta + citación de fuentes]

1. Ingesta documental

Fuentes: SharePoint, GED, wikis (Confluence muy presente en banca y telcos españolas), carpetas Drive, exportaciones CRM (Salesforce predomina), exports SAP, contratos, FAQ, intranet. Parseo: PDF (con OCR si está escaneado — Azure Document Intelligence o Tesseract), DOCX, HTML, Markdown, transcripciones audio (vía Whisper).

Buena práctica: preservar metadatos (autor, fecha, fuente, clasificación de sensibilidad, periodo de retención) a lo largo del pipeline para poder filtrar después.

2. Chunking

Los documentos se dividen en pasajes de 200-1000 tokens según el LLM objetivo y la naturaleza del contenido. Estrategias:

Chunking fijo: 500 tokens por chunk, simple
Chunking semántico: por párrafo o sección lógica, más relevante
Chunking jerárquico: gran chunk (vista general) más chunks pequeños (detalle), bueno para documentos estructurados (normativa BdE, manuales técnicos)

El buen chunking es la etapa que distingue un RAG mediocre de uno potente.

3. Embeddings

Cada chunk se convierte en un vector denso (768-3.072 dimensiones). Modelos 2026 para contenido en español:

Modelo	Origen	Calidad en español	Soberanía
E5-Multilingual	Open Source	Excelente	OK si autohospedado
BETO	Universidad de Chile / España	Excelente	OK si autohospedado
MarIA-Sentence	BSC-CNS Barcelona	Excelente	Total
BGE-M3	China open-source	Muy buena	OK si autohospedado
Mistral Embed	Francia	Buena	UE-soberano
OpenAI text-embedding-3	EE. UU.	Muy buena	Dependencia DPF

Para contextos sensibles (banca supervisada por el BdE, sanidad bajo LOPDGDD), preferir modelos del BSC-CNS o open-source autohospedados.

4. Almacenamiento vectorial

Almacenamiento de embeddings + metadatos + chunk original. Selección 2026:

Base vectorial	Tipo	Caso de uso ideal	Soberanía
Qdrant	Open-source autohospedable	Referencia 2026, pyme a gran cuenta	Sí
Chroma	Open-source	PoC, prototipo rápido	Sí
pgvector	Extensión PostgreSQL	Stack Postgres ya implantado	Sí
Weaviate	Open-source	Escala mayor	Sí si autohospedado
Milvus	Open-source	Escala muy grande	Sí si autohospedado
Pinecone	SaaS EE. UU.	A evitar para datos sensibles	No

Para casos regulados (banca BdE, sanidad SEPA, datos de menores bajo LOPIVI) Qdrant autohospedado en Stackscale, OVHcloud Madrid, Arsys o un proveedor con certificación ENS Alto es la elección soberana de referencia en 2026.

5. Retrieval

En runtime, la consulta del usuario es:

Convertida en embedding (mismo modelo que en ingesta)
Comparada con embeddings almacenados (similitud coseno)
Top-K chunks recuperados (típicamente K=5-10)

Mejoras habituales:

Hybrid search: combina búsqueda vectorial con búsqueda por palabras clave (BM25). Mejora la precisión en términos técnicos y referencias normativas.
Reranking: un modelo dedicado (cross-encoder) reordena los resultados top-K. Cohere Rerank 3 y BGE-Reranker son las opciones por defecto en 2026.
Filtros metadata: restringir la búsqueda a un subconjunto (por fecha, fuente, clasificación, perfil de usuario, comunidad autónoma).

6. Generación con citación

El LLM recibe:

La consulta del usuario
Los chunks relevantes como contexto
Un system prompt que exige citación explícita

Salida típica: «Según la Circular 1/2024 del Banco de España (apartado 4.2), las entidades deberán acreditar… [Fuente: Circular 1/2024 BdE, apartado 4.2, BOE 2024-03-15].»

Sin citación, no tiene un RAG: tiene un LLM que alucina sobre documentos internos. La citación no es negociable para la confianza del usuario y la conformidad (artículo 5.1.d RGPD — exactitud).

RAG vs fine-tuning — la decisión 2026

Criterio	RAG	Fine-tuning
Plazo de puesta en marcha	1-4 semanas	4-12 semanas
Coste inicial	5-25 k€	30-100 k€
Mantenimiento (cambio de conocimiento)	Reindexar (horas)	Re-fine-tuning (días)
Transparencia	Citaciones posibles	Caja negra
Precisión factual	Alta (anclada en fuentes)	Media (alucinaciones posibles)
Estilo/tono específico	Limitado	Excelente
Coste de inferencia	Medio (contexto largo = más tokens)	Bajo
Competencias requeridas	Devs con APIs LLM	Data science + GPU

Regla de decisión 2026:

Conocimiento que evoluciona, fuentes múltiples, citación requerida → RAG
Estilo específico, terminología ultra-especializada, latencia crítica → Fine-tuning
Mayoría de los casos de negocio → RAG en primer lugar

Empezar por RAG; cambiar o complementar con fine-tuning solo si la evaluación lo justifica.

6 casos de uso empresariales del RAG en el mercado español

1. Retail y e-commerce — catálogos y atención al cliente. España alberga gigantes mundiales del retail (Inditex, Mango, Desigual, Mercadona, El Corte Inglés). RAGs sobre fichas de producto, fichas técnicas, devoluciones, manuales y preguntas frecuentes mejoran la coherencia del soporte cliente y la búsqueda interna. Volumetrías típicas: 100.000 a 5 millones de fichas y traducciones para grupos multipaís.

2. Banca y seguros bajo supervisión BdE/DGSFP. Indexación de circulares del Banco de España, normativa de la DGSFP, MiFID II, políticas internas, procedimientos KYC/AML. Los oficiales de cumplimiento consultan en lenguaje natural en lugar de buscar en miles de páginas de regulación.

Volumetría típica: 5.000 a 100.000 documentos, varios cientos de consultas al mes.

3. Soporte técnico de nivel 1. Indexación de la documentación de producto, tickets resueltos, runbooks. Beneficio: respuestas coherentes, tasa de resolución self-service al alza, descenso del 30-50 % del volumen de tickets nivel 1.

Volumetría típica: 1.000 a 50.000 documentos, 100 a 10.000 preguntas al día.

4. Sector legal — despachos y asesorías. Garrigues, Cuatrecasas, Uría, Pérez-Llorca, así como el tejido de asesorías españolas, despliegan RAGs sobre jurisprudencia (BOE, TS, AN), contratos tipo y opiniones internas. Cae el tiempo de búsqueda de precedentes para los abogados junior.

5. Turismo y hostelería — bases multimarca. Meliá, NH, Riu, Iberostar manejan bases de conocimiento operativas multipropiedad. Un RAG permite a recepcionistas y servicios técnicos consultar manuales de procedimientos, equipamientos y normativa local en lenguaje natural.

6. Administración pública — proyectos Red.es / Plan de Recuperación. Ministerios y comunidades autónomas (especialmente Madrid, Cataluña, Andalucía y País Vasco) experimentan con RAGs sobre normativa, procedimientos administrativos y documentación interna, con foco en proveedores certificados ENS Alto y modelos del BSC-CNS.

Conformidad RGPD y AEPD del RAG

El RAG es un tratamiento automatizado que debe enmarcarse.

Obligaciones clave:

Inscripción en el registro (artículo 30 RGPD): «asistencia IA a la búsqueda documental interna». Finalidad, datos tratados, encargados, duración.
EIPD si la base contiene datos personales: la AEPD ha publicado una guía específica sobre IA y protección de datos (versión actualizada 2024) y dispone de su Decálogo de la IA. La EIPD es además obligatoria conforme a la lista de la AEPD.
Pseudonimización en la ingesta cuando sea posible.
Hospedaje soberano español o europeo para datos sensibles: Stackscale, OVHcloud Madrid, Arsys, Acens — preferir proveedores con certificación ENS Alto y estar inscritos como encargados en el registro nacional.
Contrato de encargado de tratamiento (artículo 28 RGPD): cada componente del stack — proveedor LLM, base vectorial gestionada si aplica, proveedor de embeddings — debe estar bajo contrato de encargado, con cláusulas adecuadas y mecanismos de transferencia internacional (cláusulas tipo SCC + TIA — Transfer Impact Assessment) cuando aplique.
AI Act: el uso en RR.HH., scoring crediticio o evaluación educativa puede clasificar el RAG como sistema de alto riesgo. Coordinación AEPD + autoridades sectoriales (BdE, CNMV, AESIA — Agencia Española de Supervisión de la IA con sede en La Coruña).
Control de acceso: un usuario solo debe ver los chunks a los que tiene acceso legítimo en la documentación origen. Filtros de metadata por perfil de usuario alineados con los permisos de los sistemas fuente.

Lo que no prometemos

Tres antipatrones recurrentes que evitamos en DPLIANCE al diseñar un RAG a medida.

«Indexamos todo, ya regularemos el acceso después.» Falso. El control de acceso debe diseñarse en la ingesta, no a posteriori. Indexar 100.000 documentos con acceso uniforme crea un canal de fuga de permisos monumental — el RAG responderá basándose en documentos a los que el usuario no tenía acceso en la fuente. La aplicación retroactiva de derechos es técnicamente compleja y jurídicamente frágil bajo RGPD.

«El RAG va a resolverlo todo, ya no necesitamos organizar bien las fuentes.» Falso. Un RAG sobre fuentes mal organizadas, contradictorias responderá con… información mal organizada y contradictoria. El RAG amplifica la calidad de las fuentes — no la corrige.

«Empezamos directo con un agente autónomo que hace RAG más acciones.» Habitualmente un error para un primer proyecto IA. RAG solo ya tiene sus trampas. Añadir un agente autónomo que ejecuta acciones externas multiplica los riesgos.

DPLIANCE es editor de software. Cuando diseñamos una solución IA a medida que incluye un RAG, nos ocupamos del stack completo: elección del modelo (Mistral, MarIA, on-premise según su nivel de sensibilidad), elección de base vectorial (Qdrant soberano por defecto), ingesta de fuentes, control de acceso alineado con sus permisos existentes, citación sistemática, monitorización de calidad.

FAQ

¿Qué es el RAG (Retrieval-Augmented Generation)?

RAG es una arquitectura que combina un LLM (Mistral, MarIA, GPT-4o, Claude) con una base de conocimiento interna. Es la arquitectura IA más desplegada en empresas españolas en 2026 para búsqueda documental, soporte y onboarding.

¿Cuándo elegir RAG en lugar de fine-tuning?

RAG para conocimiento que evoluciona, múltiples fuentes a citar, transparencia, equipos sin data science. Fine-tuning para estilo duradero, terminología ultra-especializada, latencia crítica.

¿Qué base vectorial elegir para RAG?

Pyme y PoC: Qdrant, Chroma, pgvector. Producción: Qdrant cluster, Weaviate, Milvus. Soberanía máxima: Stackscale, OVHcloud Madrid, Arsys, certificación ENS Alto.

¿Cuánto cuesta un RAG en producción?

Pyme con 1.000 documentos y 100 usuarios: 50-200 € al mes. Inversión inicial: 5-25 k€. Gran organización con 100.000+ documentos: 500-3.000 € al mes.

¿Es el RAG conforme al RGPD?

Sí, con inscripción en el registro art. 30, EIPD si datos personales, hospedaje soberano (Stackscale, OVHcloud Madrid), contrato de encargado y control de acceso por perfil.

¿Qué diferencia hay entre RAG y un agente IA?

Un RAG responde apoyándose en documentos — componente. Un agente decide acciones para una misión — sistema. RAG suele ser componente del agente.

¿Alucina siempre el RAG?

Sí, pero mucho menos que un LLM solo: típicamente del 90 % a menos del 5 %. Citación de fuentes es obligatoria.

¿Cuánto se tarda en poner un RAG en producción?

PoC: 1-2 semanas. Piloto: 4-8 semanas adicionales. Industrialización completa: 3-6 meses.

Fuentes: documentación oficial Mistral AI, Qdrant, Weaviate, Milvus, pgvector, Chroma; literatura científica RAG (Lewis et al. 2020 y trabajos posteriores); documentación LangChain, LlamaIndex y Haystack; Reglamento (UE) 2016/679 (RGPD); LOPDGDD (Ley Orgánica 3/2018); Guía de la AEPD sobre IA y protección de datos; Reglamento (UE) 2024/1689 (AI Act); BSC-CNS — proyectos MarIA y Salamandra.

Para enmarcar un proyecto RAG en su organización — elección de arquitectura, base vectorial, integración SI, control de acceso, conformidad — consulte nuestra guía IA conforme RGPD, nuestra guía carta IA empresa, nuestros casos de uso de IA, o contáctenos vía nuestras soluciones IA a medida.