RAG empresarial: cómo conectar IA generativa a documentos internos
Por Carlos Isidoro De Ayala Diaz ·
RAG empresarial: cómo conectar IA generativa a documentos internos con permisos, fuentes, pruebas y controles frente a filtraciones e instrucciones maliciosas.
Empieza por una pregunta de negocio y una fuente responsable
Un sistema RAG combina una búsqueda sobre fuentes externas con un modelo generativo. La aplicación recupera fragmentos relacionados con la consulta, los incorpora al contexto y solicita una respuesta. Este patrón permite trabajar con información propia y mostrar referencias, pero no convierte automáticamente cada documento en conocimiento fiable ni elimina los errores del modelo. Antes de elegir una base vectorial o un proveedor, la empresa debe concretar qué preguntas resolverá, quién las hará y qué decisión se tomará con la respuesta.
El primer inventario identifica fuentes, propietarios, formatos, fecha de actualización y sensibilidad. Una política aprobada y una presentación antigua pueden contener respuestas contradictorias; un PDF escaneado puede no extraerse bien; una hoja de cálculo puede perder la relación entre columnas al dividirse. Ingerir todo lo disponible aumenta ruido y exposición. Conviene empezar con un conjunto acotado cuya vigencia pueda comprobar una persona responsable, registrar cada versión y decidir qué materiales deben excluirse por confidencialidad, derechos o baja calidad.
También se define una alternativa sin IA y una línea base. Para localizar un procedimiento exacto quizá baste una búsqueda tradicional; para resumir varias fuentes puede ser útil la generación. Los criterios de aceptación separan recuperación y respuesta: si el documento correcto no aparece, el problema puede estar en el índice, los metadatos o la consulta; si aparece pero la respuesta lo interpreta mal, se revisan instrucciones, modelo y presentación. Esta separación evita ajustar frases al azar sin saber qué componente falla.
Aplica los permisos cuando recuperas cada documento
El asistente no debería mostrar más información que la persona que consulta podría abrir en el sistema de origen. Ese principio exige conservar identidad, grupos y permisos durante la indexación y comprobarlos en cada recuperación. Filtrar solo la interfaz o pedir al modelo que no revele datos no es un control de acceso. OWASP advierte que mezclar vectores con restricciones distintas puede causar acceso no autorizado y filtraciones. La arquitectura debe impedir que el fragmento llegue al contexto cuando el usuario no tiene permiso.
Hay que decidir cómo se actualizan altas, cambios y bajas. Si una persona cambia de departamento o un proveedor termina su contrato, el índice no puede mantener durante semanas una copia accesible con los permisos antiguos. Se documentan la frecuencia de sincronización, la retirada de documentos, el borrado de vectores y cachés y el comportamiento cuando el origen no está disponible. Las cuentas técnicas que leen repositorios usan permisos mínimos y credenciales propias; no heredan el acceso ilimitado de quien construyó el prototipo.
El flujo completo merece el mismo tratamiento que otra aplicación empresarial. Se revisa qué envía al proveedor del modelo, en qué región se procesa, qué se registra, cuánto tiempo se conserva y quién puede consultar conversaciones, fragmentos y trazas. Los prompts y respuestas pueden contener información sensible aunque el archivo original permanezca en la empresa. Los secretos, datos personales innecesarios y documentos fuera del caso de uso se excluyen antes de indexar. Las condiciones del proveedor y los costes recurrentes quedan separados del desarrollo.
Trata cada documento como entrada no confiable
Un documento puede incluir instrucciones dirigidas a una persona y también texto que intente influir en el modelo. La inyección indirecta aparece cuando el asistente recupera contenido malicioso desde un PDF, una web, un correo o una base de conocimiento y lo interpreta como una orden. Ocultar una frase, cambiar el color del texto o insertarla en metadatos no debería permitir que una fuente altere las reglas de la aplicación. La recuperación aporta datos; no debe conceder autoridad para cambiar permisos, enviar información o ejecutar una acción.
La defensa combina controles. Se validan origen, tipo y contenido antes de incorporar materiales; se preserva la procedencia; se separan instrucciones del sistema y fragmentos; se eliminan elementos activos o markup oculto cuando corresponde; y se limitan herramientas y destinos permitidos. Microsoft recomienda considerar prompts, documentos recuperados y resultados de herramientas como entradas no confiables, con autorización en cada lectura y escritura. Si el sistema puede actuar, cada herramienta necesita parámetros tipados, permisos mínimos y confirmación para operaciones sensibles.
La base de conocimiento también puede envenenarse mediante ediciones aparentemente normales. Por eso se registran quién incorporó o modificó una fuente, qué versión se indexó y qué respuestas dependen de ella. Un cambio necesita poder retirarse y volver a una versión conocida. Las alertas buscan cargas inesperadas, aumentos de documentos, cambios de origen y consultas que intentan extraer información ajena. Ningún filtro garantiza bloquear todas las manipulaciones; el alcance debe asumir fallos y reducir lo que una respuesta equivocada puede hacer.
Evalúa recuperación, respuesta y operación antes de producción
La prueba utiliza preguntas representativas, casos sin respuesta, términos ambiguos y consultas que requieren permisos diferentes. Cada ejemplo define fuentes esperadas, hechos imprescindibles, errores graves y respuesta aceptable cuando no existe evidencia. Se mide si recupera el documento correcto, si cita el fragmento utilizado, si distingue versiones y si reconoce límites. Una demostración preparada por quien desarrolló el sistema no sustituye una evaluación ciega con usuarios del proceso y documentos que no se usaron para ajustar el prototipo.
También se ejecutan pruebas adversarias: documentos con instrucciones ocultas, solicitudes para ignorar reglas, intentos de acceder a otra área, archivos retirados y contenido contradictorio. Se comprueba que una cita abra una fuente autorizada y que no revele el título o un extracto de un documento restringido. NIST propone gestionar riesgos generativos durante todo el ciclo de vida mediante gobierno, mapeo, medición y gestión. En un proyecto concreto esto se traduce en responsables, criterios, registros, revisión humana y un procedimiento para pausar o revertir.
El piloto registra calidad, latencia, consumo, incidencias y trabajo humano. Antes de ampliar se acuerdan límites de uso, soporte, actualización de fuentes, revisión de respuestas y aceptación de nuevas versiones del modelo. Élite Solutions Tech puede preparar desde Murcia un prototipo RAG para empresas regionales o nacionales y evaluar datos, integración, permisos y resultados. La propuesta concreta fuentes, usuarios, proveedor, pruebas y mantenimiento; no garantiza respuestas siempre correctas ni convierte una recomendación generada en una decisión autónoma.