RAG empresarial: cómo construir un asistente de IA que responde con citas verificables

¿Qué es un RAG empresarial?

Un RAG empresarial (Retrieval-Augmented Generation) es un sistema en el que un modelo de lenguaje no responde de memoria. Primero recupera fragmentos de los documentos de la organización y después redacta apoyándose en ellos. El modelo pone la redacción. La organización pone los hechos.

Esa separación es lo que hace que el patrón sirva en un entorno regulado: cada afirmación generada se puede rastrear hasta el documento del que sale, y quien firma puede comprobarla antes de firmar.

¿Qué pasa cuando un asistente de IA se equivoca ante un juez?

En la mayoría de los productos con IA, una respuesta inventada es una molestia. El usuario la detecta, la ignora y sigue.

En un informe pericial, no. Un informe pericial lo firma un profesional que, si el asunto llega a juicio, comparece y responde de lo que ha escrito. En el proceso civil, el perito promete decir verdad y actuar con la mayor objetividad posible, tomando en consideración tanto lo que pueda favorecer como lo que sea susceptible de causar perjuicio a cualquiera de las partes (artículo 335 de la Ley de Enjuiciamiento Civil). No hay una casilla para "esto lo escribió el modelo".

Lo mismo vale para una presentación ante un organismo oficial y para lo que sale de un canal de denuncias. El error no se queda en la pantalla: entra en un expediente que alguien va a leer con la intención expresa de encontrarlo.

Ahí está la restricción de diseño. No es "que el asistente sea útil". Es que el profesional pueda verificar cada frase antes de asumirla como suya. Todo lo demás sale de esa condición.

¿Por dónde se empieza: por el modelo o por los datos?

Por los datos. La elección del modelo es la decisión menos determinante de un RAG empresarial y la más fácil de revertir. Las tres que sí condicionan el resto son:

1. Dónde corre la inferencia, porque decide a qué jurisdicción viajan los datos.
2. Qué llega al modelo, porque un dato personal que sale de la organización ya no vuelve.
3. Qué puede afirmar el modelo sin fuente, porque de eso depende que el resultado sea verificable o solo verosímil.

Son las tres que aplicamos en Perizial, el SaaS de gestión del gabinete pericial, y en Tramitia, la plataforma de trámites y presentaciones oficiales. El recorrido completo está descrito en cómo se construyen nuestras plataformas.

Decisión 1: ¿dónde corre la inferencia?

La inferencia de nuestras plataformas corre en Vertex AI, sobre modelos Gemini, en la región europe-southwest1 (Madrid). Datos y modelo permanecen dentro de la Unión Europea.

La residencia de datos no es una promesa comercial que se escribe en una web: es la región en la que está desplegado el proyecto, y se comprueba abriendo la consola. Cuando un cliente de un sector regulado pregunta dónde se procesan sus datos, la respuesta tiene que ser el nombre de una región, no el nombre de un compromiso.

Cuántos proveedores caben en un pipeline

Cada proveedor que se añade a la cadena — un servicio de embeddings aquí, una base vectorial gestionada allá, un reranker en un tercer sitio — es un encargado del tratamiento más en el registro de actividades, un contrato más que firmar y una transferencia más que justificar.

Por eso el nuestro es corto: Google Cloud de punta a punta. No es una postura técnica, es una consecuencia del dominio. Cuando el cliente es un gabinete pericial o un equipo que presenta documentación ante un organismo, la pregunta "¿quién más ve esto?" llega siempre. La respuesta más fácil de sostener es la que cabe en una línea.

Decisión 2: ¿qué datos personales llegan al modelo?

Ninguno que sea identificable. La anonimización ocurre antes de la llamada al modelo, no después. Lo que sale hacia la inferencia ya va despersonalizado.

El orden importa más de lo que parece. Anonimizar la respuesta es cosmética: el dato ya viajó. Anonimizar la entrada es la única versión que cambia algo.

Y el proceso es fail-closed: si la anonimización falla, la petición no sale. No existe una ruta degradada en la que, ante un error, el sistema decida enviar el documento tal cual y arreglarlo luego. Un sistema que en caso de fallo hace la cosa insegura acabará haciéndola.

En la misma línea, los documentos que entran por la ingesta no se persisten después del parseo. Se procesan y se descartan. El expediente conserva lo que necesita para sostenerse; el PDF original de un tercero no tiene por qué quedarse a vivir en nuestra infraestructura.

Decisión 3: ¿puede el modelo afirmar algo sin citar la fuente?

No. Sin fuente no hay afirmación. Cada frase que el sistema genera va acompañada del fragmento del expediente del que sale, y el profesional puede abrirlo y leerlo antes de aceptarla.

Esto no convierte al modelo en infalible, y decir lo contrario sería mentir: un modelo con fuentes impecables puede seguir redactando mal una conclusión. Lo que hace la cita obligatoria es algo más modesto y más útil: convierte un error invisible en un error comprobable. Si la afirmación no se sostiene, la fuente citada lo enseña en dos segundos.

De ahí salen tres reglas prácticas:

• "No lo sé" es una respuesta de primera clase. Si el expediente no contiene la respuesta, el sistema lo dice. Un asistente que nunca dice "no lo sé" no es más capaz: es menos honesto.
• La cita tiene que verificarse de un vistazo. Citar "el documento 7" no sirve de nada si el documento 7 tiene ochenta páginas. La unidad de cita debe ser lo bastante pequeña para comprobarse leyendo, no buscando.
• El que firma decide. El modelo entrega un borrador con sus fuentes al lado. El perito revisa, corrige y firma. La responsabilidad no se delega porque no se puede delegar.

¿Qué separa una demo de RAG de un RAG en producción?

Una demo de RAG se monta en una tarde y funciona. Los problemas aparecen después, y casi siempre en los mismos cuatro sitios.

El troceado rompe la cita antes de que exista

Si el documento se parte por longitud en lugar de por estructura, un fragmento acaba conteniendo el final de una cláusula y el principio de otra. El sistema recupera algo relevante, cita algo incoherente, y el profesional deja de fiarse de las citas. A partir de ahí la función está muerta, aunque el código funcione.

Recuperar el documento correcto no es recuperar el párrafo correcto

Traer el expediente adecuado no basta. Una póliza y su suplemento dicen cosas distintas sobre la misma cobertura, y el sistema tiene que devolver el fragmento que aplica, no el que más se parece a la pregunta.

La paráfrasis se aleja de la fuente

El modelo reformula y, al reformular, introduce un matiz que la fuente no dice. La cita sigue ahí, apuntando a un texto que ya no dice exactamente eso. Es el fallo más difícil de detectar, porque el resultado parece correcto.

La evaluación se hace con las preguntas de quien lo construyó

Quien construye el sistema prueba las preguntas que se le ocurren, que son justo las que el sistema contesta bien. Las preguntas reales las hace un perito con un expediente delante, y no se parecen.

¿Cómo se comprueba que un RAG cita bien?

La pregunta a responder no es "¿la respuesta suena bien?", sino "¿el fragmento citado sostiene la afirmación?". Son dos preguntas distintas y solo la segunda se puede auditar.

En la práctica hay que evaluar tres cosas por separado, porque fallan por separado:

1. Recuperación. ¿Estaba el fragmento correcto entre los que se trajeron? Si no está, no hay nada que el modelo pueda hacer bien.
2. Fidelidad. ¿Cada afirmación de la respuesta se sostiene con el fragmento que cita? Se comprueba frase a frase, no respuesta a respuesta.
3. Abstención. Cuando la respuesta no está en el expediente, ¿el sistema lo dice? Este caso hay que provocarlo a propósito, con preguntas cuya respuesta se sabe que no está.

Y las preguntas de prueba tienen que venir del dominio. Un peritaje de daños por agua, una designación judicial y un expediente de trámite generan preguntas que no se le ocurren a nadie que no esté dentro.

¿Por dónde empezar si tu dominio también se lee en un juzgado?

Por el documento, no por el modelo. Antes de escribir una línea de código, responde a tres preguntas sobre tus propios expedientes:

• ¿Cuál es la unidad mínima de texto que alguien de tu equipo aceptaría como prueba de una afirmación? Esa es tu unidad de cita.
• ¿Qué campos de tus documentos son datos personales y en qué punto exacto del pipeline dejan de serlo? Si no lo sabes con precisión, ese es el trabajo.
• ¿Quién firma el resultado y qué necesita ver para atreverse a firmarlo?

Nosotros llegamos a estas respuestas construyendo Perizial, el software de gestión de expedientes periciales que está en producción con clientes de pago, y Tramitia, el copiloto de redacción de trámites oficiales que cita siempre la fuente. El paso a paso de la arquitectura está en cómo se construyen nuestras plataformas, y el trabajo de IA sobre datos que no pueden salir de la UE vive en la línea de ingeniería.

Si prefieres ver el dominio antes que la arquitectura, el ciclo del expediente pericial cuenta de dónde salen estas restricciones. Y si el dominio es el de un canal de denuncias, las propiedades que un registro digital necesita para resistir un examen judicial están en canal de denuncias y Ley 2/2023.