Runity mostró cómo está desarrollando un asistente RAG corporativo para Confluence y GitLab

Runiti compartió cómo transforma un prototipo interno en un asistente RAG corporativo para trabajar con documentación y código. El sistema busca simultáneamente en Confluence y GitLab, respeta derechos de acceso y opera en un circuito cerrado sin enviar datos corporativos a servicios externos.

De la idea a la implementación

El proyecto surgió de un problema muy práctico. A principios de 2025, el equipo necesitaba entender simultáneamente el antiguo sitio de Rucentra y el cambio de marca de Reg.ru: descubrir qué ya estaba implementado, dónde se encontraba la documentación actual y qué fragmentos de código eran responsables de funciones específicas.

La búsqueda manual tomaba horas: Confluence contenía varias versiones del mismo documento, y en GitLab había que navegar a través de ramas y código heredado escrito en JavaScript obsoleto. Las primeras redes neuronales locales que aprobó la seguridad de la información ya ayudaron a acelerar el trabajo. Según el equipo, las especificaciones técnicas para desarrolladores se prepararon en unos días en lugar de un largo marcado manual y análisis.

Después de eso, la empresa decidió no limitarse a experimentos aislados y construyó un producto separado que podría integrarse en el flujo de trabajo diario de desarrolladores y arquitectos. El prototipo, que comenzó como una iniciativa personal, luego se convirtió en parte del Centro de Inteligencia Híbrida de Runiti — una división interna enfocada en pilotos de IA y escenarios aplicados con resultados medibles.

Acceso y seguridad

La pregunta principal del equipo de seguridad era predecible: ¿quién exactamente vería los documentos corporativos a través de tal asistente? El equipo resolvió esto no con una política separada sobre el modelo, sino a nivel de arquitectura. El bot no almacena una matriz de permisos internamente.

Los usuarios agregan sus propios tokens personales de Confluence y GitLab, después de lo cual el sistema verifica el acceso a cada documento encontrado a través de la API. Si no hay acceso, ese fragmento simplemente no entra en el contexto del modelo. Esencialmente, la decisión sobre acceso la toma no la LLM, sino el código.

Esto reduce el riesgo de fuga de datos y mantiene los datos corporativos dentro de su circuito cerrado. El compromiso aquí es uno: las comprobaciones de acceso síncronas ralentizan la respuesta. Pero el equipo afirma que incluso de esta forma, una tarea que anteriormente tomaba varias horas ahora cabe en cinco a siete minutos.

Después de refinamientos adicionales, registro y correcciones de interfaz, el proyecto recibió aprobación de seguridad y fue a implementación.

"Si un proceso puede describirse como una secuencia de acciones —

puede ser automatizado."

Stack y escenarios

Internamente, el sistema funciona según un esquema RAG clásico: la consulta se convierte en un embedding, luego Qdrant selecciona documentos semánticamente similares de Confluence y GitLab, después de lo cual la capa de seguridad filtra todo lo innecesario, y el modelo genera una respuesta con enlaces a fuentes específicas. Este enfoque se eligió en lugar de fine-tuning: el equipo valora el contexto actual en el momento de la consulta más que reentrena el modelo en datos corporativos. El stack utiliza Python, Temporal, Qdrant, PostgreSQL, Next.

js, LangGraph y modelos Qwen implementados localmente, mientras que los datos en la base de datos vectorial se actualizan actualmente a través de reconstrucciones nocturnas. En lugar de un asistente universal, Runiti creó cuatro modos especializados. Este enfoque no provino de una arquitectura abstracta, sino de solicitudes de diferentes roles dentro de la empresa: los desarrolladores necesitan un asistente de código, los arquitectos necesitan una entrada rápida en el panorama actual, y los gerentes necesitan una forma de recopilar automáticamente un radar técnico del stack y las dependencias en los repositorios.

Esto también simplifica el desarrollo del producto: los escenarios individuales son más fáciles de probar, medir y refinar sin intentar resolver todas las tareas con un único prompt.

• un chatbot general para preguntas sobre documentos internos e incorporación rápida de proyectos;
• un agente de radar técnico que recorre repositorios y recopila una visión de lenguajes y bibliotecas;
• un agente para planificación arquitectónica que ayuda a entender el panorama actual antes de lanzar un nuevo proyecto;
• un socio de programación que conoce la base de código interna y los requisitos del equipo.

El costo de tal solución está lejos de ser un "juguete para experimentos." Para un modo corporativo con múltiples usuarios, el equipo estima una necesidad de aproximadamente cuatro GPU de nivel A100 con 24 GB de memoria, lo que cuesta 160–200 mil rublos por mes solo en computación. Si no tiene sus propias GPU, el umbral de entrada para una pequeña configuración local comienza en aproximadamente 500 mil rublos, y el desarrollo aún requiere un backend, frontend, ML e ingeniero de datos.

Lo que significa

El caso de Runiti muestra que los asistentes de IA corporativos se están moviendo rápidamente de la idea de "simplemente instalar un chatbot" a productos internos completos con RAG, verificación de acceso e infraestructura propia. En la práctica, lo que gana no es la retórica de IA más ruidosa, sino una combinación de búsqueda sólida, acceso seguro, datos actuales y escenarios que realmente ahorran horas de trabajo del equipo. Para el mercado, esta es otra señal más: la IA corporativa se está convirtiendo cada vez más de un piloto en un producto de ingeniería con costos claros y zonas de responsabilidad.