Tabla de contenidos
- Introducción
- La pregunta que nadie se hace: dónde están realmente tus datos
- La pregunta que cuesta dinero: cuál es el coste real
- RAG sigue siendo una ventaja real
- Conclusión
Introducción
Llevas meses construyendo un producto. Tienes usuarios, tienes tracción. Y alguien te dice que con RAG puedes automatizar búsquedas, reducir carga de soporte y hacer accesible información que antes requería intermediarios.
Suena genial. Y probablemente es verdad.
Pero antes de escribir la primera línea de código, hay dos preguntas que casi ningún founder se hace. Y la respuesta a ambas puede determinar si RAG es una ventaja real o un agujero negro de costes y complejidad legal.
La primera es sobre dónde van tus datos. La segunda es sobre cuánto cuesta implementarlo de verdad.
No son preguntas técnicas menores. Son decisiones arquitectónicas que, si las tomas mal, pueden cobrar un precio muy alto cuando ya estés en producción.
La pregunta que nadie se hace: dónde están realmente tus datos
RAG coge tus documentos, los trocea, los convierte en vectores y los almacena. Dependiendo de cómo esté construido el sistema, esos documentos pueden estar pasando por servidores externos, APIs de terceros o modelos en la nube que no controlas.
Esto no es un detalle técnico menor. Es una obligación legal.
El RGPD exige que sepas exactamente dónde están tus datos, quién tiene acceso a ellos y bajo qué condiciones. Si estás procesando datos de clientes: contratos, facturas, información personal, historial de transacciones... y los mandas a una API externa sin las garantías adecuadas, estás asumiendo un riesgo legal que puede ser muy caro.
Pero hay más. El problema no es solo que los datos pasen por terceros. Es que cuando pasan por múltiples servicios en una cadena RAG, pierdes visibilidad y control sobre cómo se procesan.
Un ejemplo concreto
Un gestor administrativo de comunidades quiere que sus clientes consulten información de su comunidad: estados de cuenta, saldos pendientes, reparaciones aprobadas. Sus documentos tienen datos económicos de decenas de comunidades distintas.
Si construyes un sistema RAG sin un filtrado estricto por comunidad, un propietario puede acabar viendo datos que no le corresponden. Un usuario accede al chatbot, pregunta sobre su saldo, y el sistema recupera documentos que contienen información de otras comunidades.
¿Qué pasó? Que la base de datos vectorial no estaba confinada por contexto de acceso. La arquitectura era insegura desde el diseño.
Esto no es un problema de IA. Es un problema de arquitectura que tienes que resolver antes de escribir la primera línea de código.
Cómo evitarlo
Necesitas responder estas preguntas antes de empezar:
¿Dónde se procesan tus documentos? Si usas una API externa para generar embeddings, esos documentos están siendo procesados en servidores que no controlas. Algunos proveedores aceptan contratos de procesamiento de datos (Data Processing Agreements), otros no.
¿Cómo se almacenan los vectores? Las bases de datos vectoriales pueden estar en la nube de un proveedor o en tu propia infraestructura. Si están en la nube, tienes que verificar dónde y bajo qué condiciones de privacidad.
¿Hay filtrado de acceso en cada recuperación? Cuando el sistema recupera documentos, necesita saber quién está haciendo la pregunta y qué tiene permiso de ver. Si ese filtrado no existe, tienes un problema de seguridad.
¿Cuál es tu plan de retención de datos? Los documentos se quedan en la base de datos vectorial indefinidamente. ¿Sabes cómo los vas a eliminar cuando un cliente te pida que lo hagas? (Porque te lo va a pedir, y el RGPD te obliga a hacerlo).
La respuesta a cada una de estas preguntas tendría que estar clara en tu arquitectura antes de gastar un solo euro en desarrollo.
La pregunta que cuesta dinero: cuál es el coste real
Un sistema RAG no es una llamada simple a una API de un modelo generativo. Es una cadena de tareas, y cada una tiene unos costes asociados que debes conocer y calcular antes de que sea demasiado tarde.
Muchos founders ven el coste de una llamada a ChatGPT (un céntimo) y piensan que RAG será barato. Es un error.
Cómo se acumulan los costes
Primero pagas por generar los embeddings. Convertir tus documentos en vectores tiene coste por token. Si tienes 20.000 documentos y cada uno tiene 2.000 palabras en promedio, estamos hablando de 40 millones de tokens procesados una sola vez.
Con modelos actuales, eso puede costar entre 50 y 200 euros. Una sola vez.
Pero aquí está el problema: cuando un documento cambia, tienes que volver a procesarlo. Si añades 100 documentos nuevos cada semana, esos costes se acumulan.
Luego pagas por almacenar los vectores en una base de datos vectorial. Cada vector ocupa espacio. Las bases de datos vectoriales cobran por almacenamiento, por queries, a veces por ambas cosas. Dependiendo del proveedor y del volumen, esto puede ser desde 50 euros al mes hasta cientos.
Cada vez que un usuario hace una pregunta, el sistema recupera fragmentos relevantes y los incluye como contexto en la llamada al modelo generativo. Esto aumenta el número de tokens en esa llamada. Un embedding pequeño, una retrieval, un prompt con contexto recuperado, una generación... cada paso acumula tokens.
Si tu chatbot recibe 1.000 preguntas al mes, y cada una generan 5.000 tokens de procesamiento total, estamos hablando de 5 millones de tokens al mes. Eso es dinero real.
Un cálculo realista
Digamos que tu startup tiene un MVP con RAG para consultas de clientes.
- 500 documentos (contratos, facturas, documentación del producto)
- 100 usuarios activos al mes
- 500 queries mensuales
Costes iniciales:
- Generar embeddings de 500 documentos: 10 euros
Costes mensuales:
- Almacenamiento vectorial: 30 euros
- Retrieval y queries (500 queries × 3.000 tokens promedio): 1,50 euros
- Embeddings nuevos (20 documentos nuevos/mes): 0,50 euros
Total mensual: 32 euros
Parece barato. Pero ahora escala:
- 5.000 documentos (10x)
- 2.000 queries mensuales (4x)
Nuevos costes mensuales:
- Almacenamiento vectorial: 100 euros
- Queries: 12 euros
- Nuevos embeddings: 2 euros
Total mensual: 114 euros
Todavía es manejable. Pero el problema es que estos costes escalan con tu negocio, y si no los has presupuestado, aparecen sin avisar.
Lo que muchos founders olvidan
No cuentan los tokens del system prompt. Si tienes un prompt del sistema que le explica al modelo quién es tu chatbot, qué puede hacer y cómo debe comportarse, esos tokens se envían en cada query. Un system prompt de 500 palabras son 600-700 tokens. En 2.000 queries mensuales, eso es 1,2 millones de tokens solo en prompts del sistema.
No cuentan los reintentos. A veces el modelo falla o devuelve una respuesta incompleta. Tienes que reintentar. Cada reintento es dinero.
No cuentan el mantenimiento de la base de datos vectorial. Ocasionalmente necesitas reindexar, deduplicar, limpiar documentos obsoletos. Eso requiere trabajo y cuesta dinero.
No cuentan los cambios en los precios de los proveedores. Los costes de APIs de IA han bajado, pero también pueden subir.
RAG sigue siendo una ventaja real
A pesar de todo esto, RAG no es una mala idea. Automatiza consultas repetitivas, reduce carga de soporte, hace accesible información que antes requería intermediarios.
Pero como cualquier decisión técnica con impacto en el negocio, merece una evaluación exhaustiva antes de implementarse.
Eso significa sentarse con una hoja de cálculo y escribir:
En la columna de datos: ¿qué datos van a fluir por RAG? ¿Hay datos sensibles? ¿Dónde se procesan? ¿Quién tiene acceso?
En la columna de costes: ¿cuántos documentos tienes? ¿Cuántos usuarios activos? ¿Cuántas queries esperas? ¿Cuál es el coste mensual estimado?
En la columna de arquitectura: ¿cómo filtraré acceso por usuario? ¿Dónde almaceno los vectores? ¿Cuál es mi plan de retención de datos?
Si puedes responder esas preguntas de forma clara y documentada, RAG probablemente tenga sentido en tu roadmap.
Si no puedes, quizás todavía no estés listo para implementarlo.
Conclusión
RAG está en todas partes. En blogs, en podcasts, en conversaciones de founders. Y es fácil dejarse llevar por el entusiasmo.
Pero la diferencia entre un RAG que genera valor y uno que es un agujero negro de costes y complejidad está en hacerse dos preguntas antes de empezar:
¿Dónde van mis datos y tengo certeza de que estoy cumpliendo la ley?
¿Cuánto cuesta realmente esto cuando lo uso en producción?
Si tienes dudas sobre cualquiera de estas preguntas, es probable que no estés listo. Y está bien. Es mejor reconocerlo pronto que descubrirlo en producción con dinero real en juego.
Si quieres una evaluación técnica detallada de si RAG es la solución correcta para tu producto, podemos hablar sin compromisos. Tengo una guía que te ayuda a evaluar esto en menos de una semana.