Cuando una empresa decide que quiere buscar y responder preguntas sobre sus propios documentos con un modelo de lenguaje, la primera duda casi nunca es qué es RAG (eso ya lo hemos explicado en otros artículos de este blog), sino con qué construirlo. Microsoft 365 Copilot promete respuestas ancladas en SharePoint sin escribir una línea de código. Media docena de plataformas SaaS ofrecen subir unos documentos y preguntarles en cuestión de minutos. Y un desarrollo a medida con base de datos vectorial propia sigue siendo, para muchos proyectos, la única opción que da control real sobre qué documento entra en el índice y quién puede verlo. Ninguna de las tres es la mejor opción en abstracto: cada una resuelve bien un problema distinto y falla en un escenario distinto. Este artículo compara seis caminos reales para dar a un modelo acceso a los datos de tu empresa, con los criterios que de verdad pesan en un proyecto —coste, dónde vive el dato, esfuerzo técnico de puesta en marcha— y no los que aparecen en las demos comerciales.
El mapa de opciones: seis caminos para dar a un modelo acceso a los datos de tu empresa
Antes de comparar productos concretos conviene situar cada camino dentro de su familia. Dos opciones que resuelven el mismo problema, anclar las respuestas de un modelo en tus propios documentos, pueden diferir radicalmente en dónde vive el dato, cuánto cuesta escalarlas y cuánta capacidad técnica exigen.
- RAG nativo en Microsoft 365 Copilot: el modelo busca directamente en SharePoint, OneDrive y Teams a través de Microsoft Graph, sin montar infraestructura propia.
- Plataforma SaaS vertical «chat con tus documentos»: subes los ficheros a un servicio ya construido y preguntas sobre ellos en minutos.
- RAG a medida: un modelo de lenguaje por API más una base de datos vectorial propia, con la tubería de ingesta y recuperación diseñada para tu caso.
- RAG orquestado con automatización low-code (n8n): la ingesta, el troceado y la consulta al modelo se montan como un flujo visual, sin escribir una aplicación desde cero.
- Fine-tuning como alternativa: en lugar de recuperar documentos en cada consulta, se reentrena el modelo con ejemplos propios.
- RAG soberano, on-premise: modelo, índice y datos viven enteros dentro de la infraestructura de la empresa, sin salir hacia ningún proveedor externo.
RAG nativo en Microsoft 365 Copilot
Microsoft 365 Copilot ya hace, para quien tiene la suite instalada, una forma de RAG sin que nadie tenga que diseñarla: cuando preguntas algo dentro de Word, Teams o el propio Copilot Chat, el sistema busca en los documentos de SharePoint, OneDrive y Teams a los que tienes permiso de acceso a través de Microsoft Graph, y construye la respuesta a partir de esos fragmentos. La ventaja es la velocidad de arranque: si la documentación de la empresa ya vive ordenada dentro de SharePoint, no hay que montar nada adicional para empezar a preguntarle. El límite aparece en el alcance: solo busca donde ya tienes permiso de lectura y dentro del ecosistema Microsoft, así que documentos en un CRM externo, un ERP o un repositorio fuera de la suite quedan fuera salvo que se conecten con conectores adicionales. En coste, conviene mirar la cifra correcta —la desglosamos con detalle en nuestro artículo sobre precios de Microsoft 365 Copilot—: hay dos SKU distintos. El complemento Copilot Business (hasta 300 usuarios, sobre planes Business Basic, Standard o Premium) tiene un precio de lista de 21,00 $ / 18,20 € por usuario y mes con compromiso anual (18,00 $ / 15,60 € en la promoción vigente hasta el 30 de septiembre de 2026), o 25,20 $ / 21,84 € facturando mes a mes sin compromiso anual. La versión completa de Microsoft 365 Copilot, que se puede añadir tanto a planes Enterprise como a planes Business, cuesta 26,00 € / 30,00 $ por usuario y mes pagando anualmente, o 27,30 € / 31,50 $ por usuario y mes si se factura mensualmente manteniendo el compromiso anual. La diferencia entre ambos SKU no depende de la suite base, sino de cuál de los dos se contrata: el complemento Business está limitado a 300 usuarios (el mínimo de compra de 300 licencias que existía al principio se eliminó en enero de 2024), mientras que la versión completa no tiene ese tope. Microsoft, además, sigue vendiendo Business Standard y Premium sin Copilot integrado, para quien todavía no lo necesita. Puedes ver cómo planteamos una auditoría de este camino en consultoría de adopción de Microsoft Copilot.
Plataforma SaaS vertical «chat con tus documentos»
Es la opción más rápida de probar: servicios ya construidos (asistentes documentales de nicho, herramientas de «sube un PDF y pregúntale») permiten cargar un lote de documentos y empezar a preguntar sobre ellos el mismo día, sin ningún desarrollo. Para validar si RAG aporta valor antes de comprometer presupuesto en una arquitectura propia, es un punto de partida razonable. La contrapartida es doble. Primero, el control: tus documentos —incluidos, con frecuencia, datos de clientes o de empleados— salen hacia la infraestructura de un tercero que hay que documentar como encargado del tratamiento, y cada plataforma tiene sus propias condiciones sobre cuánto tiempo conserva esos datos y si los usa para entrenar sus propios modelos, algo que conviene leer en el contrato y no dar por hecho. Segundo, el techo: estas plataformas suelen estar pensadas para un caso de uso genérico, y en cuanto necesitas heredar permisos granulares por documento, conectar fuentes distintas de un PDF suelto o auditar de dónde sale cada respuesta con el detalle que exige un proceso regulado, la plataforma vertical empieza a quedarse corta.
RAG a medida: modelo por API más base de datos vectorial propia
Es la arquitectura de referencia que describimos en detalle en nuestra guía práctica de RAG paso a paso: los documentos se procesan, se trocean, se convierten en vectores con un modelo de embeddings y se guardan en una base de datos vectorial propia; cuando llega una pregunta, el sistema recupera los fragmentos más relevantes y se los pasa al modelo de lenguaje junto con la pregunta para que genere la respuesta. La ventaja es el control total: decides qué entra en el índice, cómo se heredan los permisos, qué modelo de embeddings usas y dónde vive cada pieza de la infraestructura. También es la opción con más margen para optimizar la calidad de las respuestas con el tiempo, porque cada componente del pipeline se puede medir y ajustar por separado. El coste es el esfuerzo de diseño y mantenimiento: requiere un equipo técnico con experiencia real en recuperación de información, más allá de saber llamar a la API de un modelo, y los plazos de puesta en marcha son más largos que los de una plataforma ya construida (los factores que alargan ese calendario los detallamos en nuestro artículo sobre plazos de un proyecto RAG). Es, en general, la opción que mejor encaja cuando el volumen de documentos es alto, las fuentes son heterogéneas o el proceso maneja datos que exigen un control de acceso fino.
RAG orquestado con automatización low-code (n8n)
Es un punto intermedio entre el desarrollo a medida y una plataforma cerrada. n8n es una herramienta de automatización fair-code (licenciada bajo la Sustainable Use License: el código está disponible para verlo y modificarlo, pero no es open source según la definición de la OSI, porque limita su uso comercial y su redistribución), que incorpora desde hace años nodos nativos de IA y de LangChain (agentes, memoria de conversación, conexión a bases de datos vectoriales). Eso permite montar visualmente la tubería completa de un RAG: leer los documentos de una carpeta o un sistema de gestión documental, trocearlos, generar los embeddings, guardarlos en un índice vectorial y responder preguntas combinando la recuperación con la llamada al modelo, todo con nodos conectados en un editor visual en lugar de código escrito desde cero. Autoalojado, el dato no tiene por qué salir nunca de la infraestructura de la empresa, y el coste deja de depender del volumen de preguntas para depender del servidor. La contrapartida es que sigue exigiendo alguien que entienda de arquitectura de recuperación (qué tamaño de fragmento usar, cómo heredar permisos, cómo evaluar la calidad), aunque el trabajo de conectar cada pieza sea mucho menor que escribirlo todo desde cero. Puedes ver este enfoque en automatización con n8n e IA para empresas.
Fine-tuning como alternativa a RAG
No es, en sentido estricto, una forma de dar acceso a documentos: es la alternativa que compite por el mismo presupuesto y por la misma pregunta de fondo, cómo conseguir que el modelo responda con el conocimiento de la empresa. En lugar de recuperar fragmentos de documentos en cada consulta, el fine-tuning reentrena el modelo con ejemplos propios para que interiorice un estilo, un vocabulario o un patrón de respuesta. Sirve bien cuando lo que hay que fijar es un formato o un tono (cómo redacta un informe, qué estructura sigue una respuesta tipo), pero no es la herramienta adecuada para que el modelo conozca hechos concretos y cambiantes, como el estado de un expediente o el contenido de un contrato firmado la semana pasada: esos hechos hay que seguir recuperándolos en el momento de la consulta, porque memorizarlos de antemano los deja desactualizados en cuanto cambian. En la práctica, la mayoría de los proyectos que necesitan tono propio y hechos actualizados a la vez combinan un modelo afinado con una capa de recuperación por encima, más que elegir entre una opción y la otra.
RAG soberano, on-premise
Cuando el dato es especialmente sensible —historiales clínicos, expedientes con datos de menores, información clasificada por un contrato con la administración—, ninguna de las opciones anteriores resulta suficiente si implica que un solo fragmento de un documento salga hacia la infraestructura de un proveedor externo, por muy buenas que sean sus garantías contractuales. La respuesta en esos casos es levantar la pila completa dentro de la infraestructura de la empresa: un modelo de lenguaje desplegado en servidor propio (o en una nube privada), un índice vectorial también propio y una tubería de ingesta que nunca envía el documento original a un tercero. Es la opción más exigente en infraestructura y en capacidad técnica, y normalmente la más cara de mantener en el día a día, porque no hay proveedor que absorba las actualizaciones ni el escalado. A cambio, es la única que elimina por completo la pregunta de qué terceros tratan estos datos, porque la respuesta es ninguno.
Comparativa por criterios
La tabla resume los seis caminos por los criterios que, en nuestra experiencia implantando estos proyectos, más pesan en la decisión real: dónde vive el dato durante la consulta, cómo escala el coste, cuánto esfuerzo técnico exige ponerlo en marcha y para qué escenario encaja mejor.
| Opción | Dónde vive el dato | Coste | Esfuerzo técnico | Mejor para |
|---|---|---|---|---|
| Copilot M365 | Dentro del tenant de Microsoft 365 (SharePoint, OneDrive, Teams) | Licencia por usuario y mes (complemento Business o versión completa) | Bajo si la documentación ya vive en SharePoint | Empresas con la suite instalada y documentación ordenada |
| SaaS vertical «chat con documentos» | En la infraestructura del proveedor del servicio | Suscripción, normalmente por volumen de documentos o consultas | Muy bajo, sin desarrollo | Validar rápido si RAG aporta valor |
| RAG a medida | Donde decida la empresa (nube propia o de un proveedor elegido) | Alto coste inicial de diseño, bajo coste marginal | Alto: exige equipo técnico especializado | Volumen alto, fuentes heterogéneas, control de acceso fino |
| n8n (autoalojado) | En el servidor de la empresa o su nube elegida | Coste de servidor, fijo | Medio: visual, pero exige criterio técnico | Combinar ingesta, IA y sistemas ya conectados en n8n |
| Fine-tuning | El modelo entrenado vive donde se despliegue | Coste de reentrenamiento periódico, fijo | Medio-alto, exige conjuntos de ejemplos curados | Fijar tono o formato, no hechos cambiantes |
| RAG soberano on-premise | Enteramente dentro de la infraestructura de la empresa | El más alto en infraestructura y mantenimiento | El más alto de las seis opciones | Datos especialmente sensibles o regulados |
No hay una opción objetivamente superior: la pregunta útil no es qué camino es mejor, sino cuál encaja con la documentación que ya tienes, el volumen de consultas que esperas y el nivel de sensibilidad del dato que vas a exponer al modelo.
El criterio que casi siempre pesa más: quién puede leer tus documentos mientras el modelo responde
Más allá del precio de licencia, el criterio que con más frecuencia decide en empresas que manejan información sensible es quién trata esos documentos mientras dura la consulta: datos de clientes, de empleados, expedientes regulados. El RGPD obliga al responsable del tratamiento a poder documentar en todo momento qué terceros procesan datos personales y en qué condiciones (art. 5.2, 28 y 30.1 del Reglamento (UE) 2016/679), y esa obligación se vuelve más sencilla de acreditar cuantos menos terceros intervienen en la cadena. Por eso, en proyectos que manejan historiales clínicos, expedientes de menores o información contractual sensible, muchas organizaciones descartan de entrada las plataformas SaaS verticales y se inclinan por n8n autoalojado, un RAG a medida en infraestructura propia o, en los casos más exigentes, la opción soberana on-premise.
Si además el sistema conversa directamente con personas (un chatbot de atención al cliente, un asistente abierto a toda la plantilla), entra en juego otra obligación distinta a la del tratamiento de datos: la transparencia del artículo 50 del Reglamento (UE) 2024/1689, modificado por el Reglamento (UE) 2026/1744 (el «Ómnibus digital sobre IA», en vigor desde el 27 de julio de 2026). Esa obligación exige informar a la persona de que está interactuando con un sistema de IA (art. 50.1), y es exigible desde el 2 de agosto de 2026 sin periodo transitorio. El único aplazamiento del artículo 50 —hasta el 2 de diciembre de 2026— cubre el marcado técnico del contenido sintético (art. 50.2), y solo para proveedores de sistemas generativos ya comercializados antes del 2 de agosto de 2026. No es una obligación exclusiva de los proyectos con RAG: afecta a cualquier chatbot, lo construyas o no con recuperación de documentos. Conviene tenerla en cuenta al diseñar la interfaz de conversación, además de la tubería de datos que hay detrás.
Qué mirar antes de decidir, más allá de la demo comercial
Las demos de estas seis opciones están diseñadas para lucir bien con un puñado de documentos limpios y una pregunta fácil. Estos son los criterios que usamos con nuestros clientes para acotar la decisión antes de mirar un producto concreto:
- Elige Copilot M365 si la documentación relevante ya vive ordenada en SharePoint, OneDrive o Teams, y lo que necesitas es que el modelo la busque, sin tener que procesar fuentes externas.
- Elige una plataforma SaaS vertical si quieres validar en días si RAG aporta valor a un caso de uso concreto, antes de comprometer presupuesto en algo más permanente.
- Elige RAG a medida si el volumen de documentos es alto, las fuentes son heterogéneas o necesitas heredar permisos de acceso con un nivel de detalle que ninguna plataforma genérica ofrece.
- Elige n8n si quieres montar la tubería completa de forma visual, combinarla con automatizaciones que ya tienes en marcha y mantener el dato dentro de tu propia infraestructura sin escribir una aplicación desde cero.
- Elige fine-tuning si lo que necesitas fijar es un tono o un formato de respuesta, no hechos que cambian con el tiempo.
- Elige la opción soberana on-premise si el dato que va a tratar el sistema es tan sensible que ningún tercero, por bien documentado que esté el contrato, resulta aceptable.
Por qué en la práctica casi ningún proyecto usa un solo camino
En los proyectos que implantamos, es habitual que una empresa mantenga Copilot para las búsquedas generales sobre su documentación en SharePoint, y añada un RAG a medida (o montado con n8n) para un caso de uso concreto que Copilot no cubre bien: un asistente para un departamento con fuentes fuera de Microsoft 365, o un proceso que necesita citar la fuente exacta de cada respuesta con un nivel de detalle que Copilot Chat no expone. Ver estas seis opciones como un mapa de caminos complementarios, y no como una elección única, evita el error más caro: comprometerse con una sola plataforma antes de saber qué exige de verdad cada caso de uso dentro de la empresa. Los errores concretos que más se repiten al montar la parte técnica, elijas el camino que elijas, los recogemos en los errores más caros en un proyecto RAG.
Preguntas frecuentes
¿Microsoft 365 Copilot ya hace RAG con mis documentos sin que tenga que montar nada más?
Para búsquedas dentro del propio ecosistema de Microsoft 365, sí: Copilot recupera fragmentos de SharePoint, OneDrive y Teams a través de Microsoft Graph y los usa para construir la respuesta, sin que haya que diseñar ninguna tubería adicional. Lo que no resuelve por sí solo es el acceso a fuentes fuera de ese ecosistema (un CRM, un ERP, un repositorio documental externo) ni el nivel de personalización sobre cómo se trocean o se citan los documentos que sí permite un RAG a medida.
¿Puedo combinar RAG y fine-tuning en el mismo proyecto?
Sí, y en la práctica es habitual cuando el proyecto necesita a la vez un tono o formato de respuesta propio y acceso a información que cambia con el tiempo. El fine-tuning fija cómo responde el modelo; el RAG le da acceso a los hechos concretos que debe usar en cada consulta. Son capas complementarias que suelen convivir bien en el mismo proyecto, aunque para muchos casos empezar solo con RAG ya cubre la necesidad sin el coste añadido de reentrenar el modelo.
¿Necesito una base de datos vectorial sí o sí para montar RAG con mis datos?
No siempre. Copilot M365 y la mayoría de plataformas SaaS verticales gestionan el índice vectorial por ti, sin que tengas que elegirlo ni mantenerlo. Solo entra en juego como decisión propia cuando construyes un RAG a medida o lo orquestas con una herramienta como n8n: ahí sí tienes que elegir qué motor de base de datos vectorial usar, cómo trocear los documentos y cómo mantener el índice actualizado, decisiones que en las opciones ya construidas vienen resueltas de fábrica.
¿Cuál de estas opciones es la más barata para empezar?
Depende de si ya pagas la licencia correspondiente. Si la empresa ya tiene Microsoft 365 con un plan compatible, añadir el complemento de Copilot suele ser la vía más barata para empezar porque no hay coste de desarrollo. Si no hay ninguna suite de base, una plataforma SaaS vertical de bajo coste mensual suele ser más barata al principio que montar un RAG a medida, aunque ese coste crece con el volumen de documentos o consultas de un modo que un desarrollo propio o un n8n autoalojado no sufre a largo plazo.
Fuentes consultadas
- Reglamento (UE) 2016/679 — RGPD (EUR-Lex): base normativa sobre responsabilidad del tratamiento y encargados del tratamiento.
- Reglamento (UE) 2026/1744 — Ómnibus digital sobre IA (EUR-Lex): modifica el calendario y las obligaciones del Reglamento (UE) 2024/1689, incluida la transparencia del artículo 50.
- Microsoft Learn — License Options for Microsoft 365 Copilot: planes y requisitos de licencia vigentes para el complemento de Copilot.
- n8n — documentación oficial y Sustainable Use License: especificaciones técnicas de despliegue, nodos y licencia.
Este artículo es orientativo y no sustituye un análisis individualizado de los sistemas y datos de tu empresa.
Si quieres decidir con datos concretos de tu operación, y no solo con este mapa general, el equipo de RAG y búsqueda interna con IA de Summum IA puede analizar tu documentación actual y proponer el camino que mejor encaje, ya sea Copilot, un desarrollo a medida o una automatización con n8n.