A Runity mostrou como está desenvolvendo um assistente RAG corporativo para Confluence e GitLab

Runiti compartilhou como transforma um protótipo interno em um assistente RAG corporativo para trabalhar com documentação e código. O sistema busca simultaneamente em Confluence e GitLab, respeita direitos de acesso e opera em um circuito fechado sem enviar dados corporativos para serviços externos.

Da ideia à implementação

O projeto nasceu de uma dor muito prática. No início de 2025, a equipe precisava simultaneamente entender o antigo site do Rucentra e o rebranding do Reg.ru: descobrir o que já estava implementado, onde ficava a documentação atual e quais trechos de código eram responsáveis por funções específicas.

A busca manual levava horas: Confluence continha várias versões do mesmo documento, e no GitLab era preciso navegar por branches e código legado escrito em JavaScript desatualizado. As primeiras redes neurais locais aprovadas pela segurança da informação já ajudaram a acelerar o trabalho. Segundo a equipe, as especificações técnicas para desenvolvedores foram preparadas em poucos dias em vez de longa marcação manual e análise.

Depois disso, a empresa decidiu não se limitar a experimentos isolados e construiu um produto separado que poderia ser integrado ao fluxo de trabalho diário de desenvolvedores e arquitetos. O protótipo, que começou como uma iniciativa pessoal, posteriormente se tornou parte do Centro de Inteligência Híbrida da Runiti — uma divisão interna focada em pilotos de IA e cenários aplicados com resultados mensuráveis.

Acesso e segurança

A pergunta principal da equipe de segurança era previsível: quem exatamente veria os documentos corporativos através de tal assistente. A equipe resolveu isso não com uma política separada no topo do modelo, mas no nível da arquitetura. O bot não armazena uma matriz de permissões internamente.

Os usuários adicionam seus próprios tokens pessoais de Confluence e GitLab, após o que o sistema verifica o acesso a cada documento encontrado via API. Se não há acesso, esse fragmento simplesmente não entra no contexto do modelo. Essencialmente, a decisão sobre acesso é tomada não pelo LLM, mas pelo código.

Isso reduz o risco de vazamento de dados e mantém os dados corporativos dentro do circuito fechado deles. O compromisso aqui é um: verificações de acesso síncronas diminuem a resposta. Mas a equipe afirma que mesmo nesta forma, uma tarefa que anteriormente levava várias horas agora se encaixa em cinco a sete minutos.

Após refinamentos adicionais, logging e correções de interface, o projeto recebeu aprovação de segurança e foi para implementação.

"Se um processo pode ser descrito como uma sequência de ações — ele

pode ser automatizado."

Stack e cenários

Internamente, o sistema funciona de acordo com um esquema RAG clássico: a consulta é convertida em um embedding, então Qdrant seleciona documentos semanticamente semelhantes de Confluence e GitLab, após o que a camada de segurança filtra tudo o que é desnecessário, e o modelo gera uma resposta com links para fontes específicas. Essa abordagem foi escolhida em vez de fine-tuning: a equipe valoriza o contexto atual no momento da consulta mais do que retreinar o modelo em dados corporativos. O stack usa Python, Temporal, Qdrant, PostgreSQL, Next.

js, LangGraph e modelos Qwen implantados localmente, enquanto os dados no banco de dados vetorial são atualmente atualizados através de reconstruções noturnas. Em vez de um assistente universal, Runiti criou quatro modos especializados. Essa abordagem não veio de uma arquitetura abstrata, mas de solicitações de diferentes papéis dentro da empresa: desenvolvedores precisam de um assistente de código, arquitetos precisam de entrada rápida na paisagem atual, e gerentes precisam de uma maneira de coletar automaticamente um radar técnico do stack e dependências nos repositórios.

Isso também simplifica o desenvolvimento do produto: cenários individuais são mais fáceis de testar, medir e refinar sem tentar resolver todas as tarefas com um único prompt.

• um chatbot geral para perguntas sobre documentos internos e onboarding rápido de projeto;
• um agente de radar técnico que percorre repositórios e coleta uma visão de linguagens e bibliotecas;
• um agente para planejamento arquitetônico que ajuda a entender a paisagem atual antes de lançar um novo projeto;
• um parceiro de programação que conhece a base de código interna e os requisitos da equipe.

O custo de tal solução está longe de ser um "brinquedo para experimentos." Para um modo corporativo com múltiplos usuários, a equipe estima uma necessidade de aproximadamente quatro GPUs de nível A100 com 24 GB de memória, o que custa 160–200 mil rublos por mês apenas em computação. Se você não tem suas próprias GPUs, o limiar de entrada para um pequeno setup local começa em aproximadamente 500 mil rublos, e o desenvolvimento ainda requer um backend, frontend, ML e engenheiro de dados.

O que isso significa

O caso da Runiti mostra que os assistentes de IA corporativos estão rapidamente se movendo da ideia de "apenas coloque um chatbot" para produtos internos completos com RAG, verificação de acesso e sua própria infraestrutura. Na prática, o que vence não é a retórica de IA mais alta, mas uma combinação de busca sólida, acesso seguro, dados atuais e cenários que realmente economizam horas de trabalho da equipe. Para o mercado, este é ainda outro sinal: a IA corporativa está cada vez mais se tornando de um piloto em um produto de engenharia com custos claros e zonas de responsabilidade.