Gobernar fuentes, permisos y vigencia

La recuperación no puede compensar un corpus sin gobierno. Si el índice mezcla borradores, copias, versiones retiradas y documentos con permisos distintos, un mejor embedding solo encontrará con más eficacia información que quizá no debería utilizar.

La fuente de verdad de un sistema RAG no es «todo lo que hemos podido indexar». Es un conjunto de fuentes cuyo propietario, autoridad, versión, alcance y acceso pueden explicarse.

Crea un catálogo de fuentes

Antes de ingerir contenido, registra cada origen o familia documental. Como mínimo:

• identificador canónico;
• propietario;
• autoridad editorial;
• repositorio de origen;
• estado: borrador, aprobado, retirado;
• versión;
• fecha o condición de vigencia;
• ámbito: producto, país, departamento o cliente;
• grupos autorizados;
• clasificación de sensibilidad;
• frecuencia de revisión;
• evento que activa sincronización;
• regla de retirada.

El propietario no es un campo administrativo ornamental. Es quien debe poder resolver contradicciones, aprobar una nueva versión y responder cuando el sistema recupera información que parece incorrecta.

Distingue autoridad de popularidad

La fuente más consultada, más reciente o más parecida semánticamente no es necesariamente la que prevalece. Una wiki interna puede explicar un procedimiento mejor que una norma corporativa, pero quizá no tenga autoridad para sustituirla.

Define reglas de precedencia cuando existan fuentes solapadas. Por ejemplo:

política aprobada vigente > procedimiento operativo vigente > guía interna > borrador

No conviertas esta jerarquía en una regla universal. Debe reflejar cómo gobierna realmente el conocimiento la organización.

Cuando dos fuentes de igual autoridad se contradigan, no pidas al modelo que elija «la más razonable». La contradicción es un dato que debe hacerse visible y escalarse.

Conserva los permisos del origen

Indexar contenido crea una nueva superficie de acceso. El índice no puede convertirse en un atajo para saltarse el repositorio original.

Los permisos necesarios deben viajar con el contenido o existir en un mecanismo de autorización equivalente. La recuperación debe restringir candidatos antes de enviar pasajes al modelo. Ocultar después un resultado no resuelve el problema: para entonces el contenido ya habría entrado en el contexto.

La implementación concreta puede usar grupos, listas de control de acceso, filtros por tenant u otros mecanismos. Lo importante es el principio: la identidad del usuario y su autorización forman parte del proceso de recuperación, no solo de la interfaz.

Modela el ámbito junto con el contenido

Una misma política puede tener versiones por país, producto, cliente o periodo. Si esas dimensiones no se almacenan como metadatos, el buscador puede combinar fragmentos incompatibles.

Incluye metadatos que permitan filtrar y explicar:

• producto;
• región;
• versión;
• fecha de efecto;
• estado editorial;
• organización o tenant;
• clasificación;
• idioma cuando afecte a la aplicabilidad;
• documento sustituido o documento sucesor.

El sistema debe poder responder qué versión utilizó y por qué estaba vigente para esa consulta.

Diseña la retirada como una operación de primer nivel

Añadir documentos suele recibir más atención que retirarlos. En producción, una política derogada o un permiso revocado son casos críticos.

Define qué ocurre cuando una fuente:

• se elimina;
• cambia de versión;
• pierde vigencia;
• modifica permisos;
• se fusiona con otra;
• queda suspendida;
• no puede sincronizarse.

La retirada debe alcanzar índice, cachés y otros derivados que puedan seguir exponiendo el contenido. Conserva una traza de qué se retiró, cuándo y por qué, sin dejar el contenido activo accidentalmente.

Trata la sincronización fallida como estado visible

Un pipeline de ingestión puede fallar a mitad de una actualización. No marques una fuente como actualizada porque el job empezó. Registra estados como pendiente, en proceso, sincronizada, fallida o retirada y conserva última sincronización correcta.

Si una nueva versión no se ha indexado, el sistema debe saber que existe un desfase. Según el riesgo, puede seguir utilizando la versión anterior con advertencia, bloquear respuestas afectadas o escalar el caso.

Ejemplo: manuales por producto y región

Una empresa mantiene manuales para tres versiones de un producto y dos regiones. Un usuario pregunta por la configuración de la versión 4 en España.

El filtro de contexto debe evitar recuperar instrucciones de la versión 3 o del manual para otra región. Si la versión 4 aún no tiene manual español aprobado, el sistema no debe mezclar pasajes hasta fabricar una respuesta plausible. Puede señalar la ausencia y ofrecer la fuente global si la política de la organización permite usarla como alternativa.

Separa el gobierno del contenido del mecanismo de búsqueda

El catálogo de fuentes debe existir aunque mañana cambies de motor vectorial, proveedor de embeddings o interfaz. Esa independencia evita que una decisión de gobierno quede escondida dentro de una configuración de infraestructura.

La política debería poder responder, fuera del buscador, qué documentos están autorizados para un determinado caso. El índice materializa esa política para hacerla consultable con eficiencia; no debería inventarla.

Esto facilita también las migraciones. Si cambias de tecnología, puedes reconstruir el índice a partir del catálogo canónico y verificar que el nuevo sistema conserva los mismos permisos, versiones y reglas de retirada.

Prueba combinaciones de identidad y contenido

No pruebes solo «usuario autorizado» y «usuario no autorizado». Incluye:

• usuario que cambia de grupo;
• documento que cambia de clasificación;
• dos tenants con nombres de documentos similares;
• versión nueva con permisos distintos;
• documento público que enlaza a uno restringido;
• usuario autorizado al documento pero no al sistema que contiene un anexo.

El objetivo es comprobar el comportamiento del conjunto, no una única consulta feliz.

Ejercicio: catálogo de gobierno

Toma diez fuentes del caso del curso y crea una tabla con:

• ID canónico;
• título;
• propietario;
• autoridad;
• estado;
• versión;
• vigencia;
• ámbito;
• grupos autorizados;
• sensibilidad;
• precedencia;
• evento de actualización;
• regla de retirada;
• última sincronización;
• prueba de acceso prevista.

Incluye al menos una fuente obsoleta, una con permisos restringidos y dos que se contradigan. Define qué respuesta esperas en cada caso.

Antes de continuar

El corpus queda preparado para diseño técnico cuando cada fuente puede responder cuatro preguntas: quién responde por ella, quién puede verla, cuándo es aplicable y cómo se retira. A partir de ahí sí tiene sentido preparar documentos y fragmentos para recuperación.