RAG vs LLM público: cuándo cada uno en tu empresa

Una empresa argentina que está evaluando cómo aplicar IA suele toparse rápido con una decisión técnica que se viste de simple pero no lo es: ¿conviene poner los datos sensibles directamente en los prompts de un modelo público como GPT o Claude, o conviene armar una arquitectura RAG que mantenga los datos en infraestructura propia y mande al modelo solo lo necesario? La respuesta corta es “depende”. La respuesta útil requiere entender qué problema resuelve cada arquitectura y cuáles son los trade-offs reales en costo, control y compliance.

Dos arquitecturas, dos problemas distintos

Empecemos por las definiciones, sin marketing.

LLM público con datos sensibles en el prompt: tu empresa toma un modelo proveído por OpenAI, Anthropic, Google o similar, y en cada llamada incluye en el contexto los datos relevantes para que el modelo procese. Esos datos viajan a la infraestructura del proveedor, son procesados ahí, y la respuesta vuelve. Funciona muy bien para casos puntuales, conversacionales, o cuando los datos no son particularmente sensibles.

Retrieval Augmented Generation (RAG): tu empresa indexa sus documentos en una base de conocimiento que vive en infraestructura propia (o en cloud bajo control propio). Cuando hay una consulta, primero se busca en esa base los fragmentos relevantes, y solo esos fragmentos se mandan al modelo de lenguaje (que puede ser público o auto-hospedado) para generar la respuesta. El documento entero nunca sale; solo el extracto relevante para esa consulta específica.

Las dos arquitecturas no son intercambiables. Son herramientas para problemas distintos.

Qué resuelve un LLM público bien usado

Un LLM público resuelve bien problemas donde el contexto cambia constantemente, el dato es público o poco sensible, y el volumen es manejable.

Casos donde funciona muy bien: asistencia a escritura (mails, propuestas, presentaciones donde el contenido no es particularmente confidencial), traducción y revisión de textos, análisis de información pública (resumen de noticias, lectura de informes públicos), generación de código que no incluye lógica propietaria sensible, brainstorming y exploración de ideas.

Casos donde funciona aceptablemente: clasificación de tickets de atención al cliente, primera respuesta a consultas estándar, generación de actas de reuniones internas. En estos casos hay dato sensible pero el riesgo de exposición es bajo y manejable si vos confiás en el contrato de privacidad con el proveedor.

Lo que un LLM público no resuelve bien por sí solo: cualquier flujo donde necesités basar la respuesta en una base de conocimiento grande, dinámica y propietaria. Si tu pregunta es “qué dice nuestra base de contratos sobre X cláusula”, pegarle a un LLM público todos tus contratos en cada consulta es ineficiente, caro, y un problema de soberanía de datos.

Qué resuelve RAG sobre documentación privada

RAG resuelve el problema de hacer interrogable una base de conocimiento propia que es demasiado grande para meter en cada prompt y demasiado sensible para subir a un servicio externo sin control.

Casos donde funciona muy bien. Asistencia interna sobre manuales y procedimientos: el equipo pregunta en lenguaje natural y obtiene respuestas con cita textual del documento fuente. Consulta de base de contratos: “qué dice nuestra última versión de contrato tipo sobre cláusulas de confidencialidad”. Preguntas sobre normativa interna: “qué política aplica si un cliente pide devolución después de 30 días”. Acceso estructurado a histórico: “qué decisiones tomó el directorio sobre X tema en los últimos dos años, según las actas”.

En todos esos casos, la diferencia entre RAG y LLM público es enorme. Con RAG, los documentos nunca salen del control de la empresa. Solo viajan al modelo los fragmentos relevantes para la consulta específica, y muchas veces puede usarse un modelo auto-hospedado para mantener todo dentro del perímetro. Para profundizar en cómo se implementa esto, implementación RAG detalla las fases y entregables.

Costos: comparativa realista a 12 meses

Hagamos una comparativa cuantitativa honesta. Supongamos una empresa argentina que necesita responder 10.000 consultas mensuales a partir de una base de 1.000 documentos internos. Veamos cuánto cuesta cada arquitectura a 12 meses.

Opción A: LLM público con contexto completo en cada consulta. Asumamos que cada documento promedio son 5.000 tokens y que en cada consulta mandás los 10 documentos más relevantes (50.000 tokens de contexto). A precios 2026 de un modelo de gama media: aproximadamente USD 0,15 por consulta de input + USD 0,03 por output. Total: USD 0,18 por consulta. 10.000 consultas mensuales: USD 1.800/mes. Anual: USD 21.600. Sin costo inicial.

Opción B: RAG sobre infraestructura propia. Costo de implementación inicial: USD 18.000 (caso medio). Costo operativo: tu base de conocimiento vive en una base vectorial que cuesta USD 80/mes. Cada consulta busca y devuelve solo los fragmentos relevantes (digamos 3.000 tokens de contexto en lugar de 50.000). Costo por consulta: USD 0,012. 10.000 consultas mensuales: USD 120/mes. Anual operativo: USD 2.400. Total año uno: USD 20.400 (incluyendo implementación).

A 12 meses, en este escenario, los costos son parecidos. La diferencia importante es lo que pasa después. Año dos de RAG: USD 2.400 más mantenimiento (USD 3.000). Total: USD 5.400. Año dos de LLM público: USD 21.600. La curva diverge fuerte.

Si tu volumen es bajo (menos de 1.000 consultas mensuales), LLM público gana cómodo. Si tu volumen es alto, RAG gana en operativo después del primer año. El punto de quiebre orientativo está entre 3.000 y 5.000 consultas mensuales.

Para más detalle sobre rangos de costos, cuánto cuesta implementar IA en una PyME argentina tiene los benchmarks completos.

Control y soberanía de datos: el factor decisivo

El cálculo de costos asume que las dos opciones son igualmente válidas desde la perspectiva de control de datos. Para muchas empresas argentinas, no lo son.

Si trabajás bajo regulación sectorial estricta —fintech argentinas bajo BCRA Comunicación A 7724, estudios jurídicos bajo secreto profesional, salud bajo Ley 25.326— el control sobre dónde están los datos y quién los puede leer es prioritario sobre el costo. RAG con infraestructura propia mantiene los datos dentro del perímetro. LLM público los expone al proveedor (con todas las garantías contractuales, pero los expone).

Para profundizar en cómo se aplica este criterio a sectores específicos, secreto profesional en estudios jurídicos cubre la dimensión legal-contable y fintech bajo BCRA cubre la dimensión financiera.

Hay un punto técnico importante. Los planes empresariales de los principales proveedores (OpenAI Enterprise, Anthropic Claude for Work) tienen cláusulas explícitas de no entrenamiento sobre tus datos y de retención limitada. Esos planes son significativamente mejores que las versiones de consumidor desde la perspectiva de protección. Pero “no usado para entrenamiento” no es lo mismo que “no almacenado”: los datos se almacenan en infraestructura del proveedor por períodos de tiempo definidos. Para datos sensibles bajo regulación, eso puede no alcanzar.

Arquitecturas híbridas: cuándo tienen sentido

En la práctica, la mayoría de empresas que implementan IA en serio terminan con arquitecturas híbridas. RAG se usa para todo lo que toca documentación interna sensible. LLM público se usa para todo lo que requiere generación abierta sobre input específico no sensible. La línea entre los dos la define una política de clasificación de datos que la empresa establece desde el principio.

Una arquitectura híbrida típica. La consulta entra al sistema. Un primer clasificador (puede ser una regla simple o un modelo chico) decide: ¿esta consulta requiere acceso a documentación interna sensible? Si la respuesta es sí, va a la rama RAG que busca en la base privada y genera con un modelo bajo control. Si la respuesta es no, va a la rama LLM público directo con el contexto de la consulta. El usuario recibe la respuesta sin saber por qué rama pasó, pero los datos siguieron la política correcta.

Para empresas con clasificación de datos seria, el clasificador puede ser explícito sobre qué tipo de dato cada empleado puede consultar, qué tipo de consulta requiere aprobación, qué tipo de respuesta requiere log de auditoría. Eso es gobernanza viva, no teatro de cumplimiento.

Cómo elegir en una decisión concreta

Cerramos con una matriz simple de cuatro preguntas para decidir.

¿Tus datos están sujetos a regulación sectorial específica (fintech, salud, legal)? Si sí, RAG con control propio gana, salvo casos puntuales.

¿Tu base de conocimiento interna es grande y dinámica (más de 200 documentos que se actualizan)? Si sí, RAG es la única arquitectura escalable.

¿Tu volumen de uso esperado es alto (más de 3.000 consultas mensuales)? Si sí, RAG gana económicamente después del primer año.

¿Necesitás trazabilidad y auditoría completas de qué se consultó y qué se respondió? Si sí, RAG facilita mucho más esa función que LLM público, donde la traza está parcialmente fuera de tu control.

Si todas las respuestas son “no”, probablemente LLM público con buenos contratos empresariales sea suficiente. Si dos o más son “sí”, probablemente convenga RAG. Si estás entre los dos casos, escribime a r@patron.ar con el contexto: tipo de datos, volumen esperado, restricciones regulatorias. Una conversación de treinta minutos suele alcanzar para decidir.

Para fuentes técnicas, el paper original sobre RAG de Lewis et al. introduce la arquitectura, y la documentación de privacidad enterprise de OpenAI y la política de uso de Anthropic describen los términos comerciales actuales de cada proveedor. Para arquitecturas concretas sobre stacks open-source, LlamaIndex y LangChain son las dos referencias técnicas más adoptadas.