Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
Incorporar documentos da wiki interna para criar um assistente de IA corporativo é algo que pode ser feito em meio dia. O verdadeiro problema estoura na manhã de segunda-feira seguinte. É o momento em que um desenvolvedor estagiário pergunta no chat de IA: "Qual é o critério de cálculo de bônus dos executivos este ano?" e o sistema resume com todo o cuidado os documentos confidenciais do departamento financeiro.
Qualquer engenheiro de plataforma com 3 a 7 anos de experiência construindo bases de conhecimento corporativas percebe esse problema intuitivamente. A maioria das arquiteturas de RAG divide os documentos, os converte em vetores de embedding e joga fora todo o sistema de controle de acesso do documento original. Isso acontece porque as regras de controle de acesso vinculadas ao Okta ou Azure AD desaparecem completamente dentro do banco de dados vetorial. Se esse vazio de permissões não for bloqueado no nível do pipeline de infraestrutura — e não no código da aplicação —, a base de conhecimento privada se torna, na prática, um canal de vazamento de informações internas.
A discrepância de permissões entre o sistema de autenticação corporativo e o armazenamento vetorial deve ser resolvida com um pipeline de sincronização de metadados em intervalos regulares, e não com consultas em tempo real. O método de chamar a API do IdP para consultar permissões a cada chegada de consulta aumenta a latência de busca em mais de 200 milissegundos e esgota rapidamente o limite de taxa (Rate Limit) de chamadas por segundo do IdP.
É necessário executar um lote usando Airflow ou Celery que atualize a lista de grupos proprietários dos documentos a cada hora em um campo de matriz de metadados do registro vetorial. Usando o Qdrant como exemplo, um campo allowed_groups é colocado em cada payload de bloco, e os IDs de grupo do Okta são inseridos diretamente nele.
json { "chunk_id": "doc_9281_chunk_04", "text": "Orçamento de transição de infraestrutura de servidores para o segundo semestre de 2026...", "allowed_groups": ["group_devops_lead", "group_finance_managers"] }
Quando as permissões do documento mudam, o evento de alteração do documento original é detectado e apenas os metadados no banco de dados vetorial são atualizados de forma isolada. Como não há necessidade de recalcular todos os embeddings, nenhum custo de computação adicional é gerado. Quando um usuário faz uma pergunta, a declaração (claim) groups extraída do JWT é injetada obrigatoriamente como parâmetro de filtro de busca. Colocar um sidecar do Open Policy Agent (OPA) na frente do banco de dados vetorial permite recusar imediatamente a solicitação com um erro HTTP 403 quando o filtro de grupo autorizado do usuário estiver ausente na consulta enviada pelo cliente. De acordo com um relatório de auditoria de segurança de RAG publicado em 2024 pelo grupo de pesquisa de segurança Bishop Fox de São Francisco, 78% dos incidentes de testes de intrusão em LLMs corporativos ocorreram devido à omissão de filtros de metadados. Forçar filtros no portal de infraestrutura poupa mais de 8 horas de trabalho semanais dedicadas a verificações manuais de permissões.
Se o assistente de IA tiver permissão para resumir automaticamente documentos internos ou atualizar o contexto, a fila de espera de aprovação ficará congestionada rapidamente. Se os pedidos de revisão de segurança forem enviados para caixas de entrada de e-mail ou tickets de backlog, a confirmação leva em média 72 horas. Se esse atraso for negligenciado, os engenheiros acabarão vendo o assistente interno responder com especificações de API legadas de meses atrás.
A aprovação de conhecimento deve ser tratada como um PR (Pull Request) em um repositório Git, da mesma forma que o sistema de revisão de código interno. Quando o agente de IA sugere uma nova alteração de conhecimento, ele deve criar um branch em formato de arquivo Markdown para gerar um PR.
O arquivo CODEOWNERS na raiz do repositório é lido para designar automaticamente a equipe de engenharia responsável pelo caminho do documento alterado.
`
/docs/architecture/payment/ @team-fintech-core
/docs/infrastructure/k8s/ @team-platform-infra
/docs/security/auth/ @team-infosec
`
O webhook de PR gerado pelo agente é conectado ao canal dedicado do Slack da equipe responsável, exibindo o diff antes e depois da alteração junto com um botão de aprovação. Quando um membro da equipe clica no botão de aprovação no Slack, a API do GitHub entra em ação para mesclar o branch, e o pipeline de implantação é executado imediatamente para re-incorporar apenas o bloco de documento correspondente no banco de dados vetorial. Alinhar o fluxo de modificação da base de conhecimento com o ciclo de desenvolvimento habitual reduz o tempo de gargalo de aprovação para menos de 4 horas.
Ao coletar documentos de infraestrutura, chaves de acesso da AWS ou strings de conexão de bancos de dados de staging deixadas por engano por engenheiros como exemplos de configuração acabam sendo capturadas. Se isso for enviado diretamente para o modelo de embedding, credenciais corporativas permanecerão nos logs de cache de provedores de LLM externos SaaS, ficando totalmente vulneráveis a ataques de injeção de prompt que roubam o contexto de recuperação aumentada. De acordo com a análise de vazamento de dados em nuvem da empresa de cibersegurança Wiz em 2023, strings de credenciais válidas foram encontradas em cerca de 12% dos documentos internos em ambientes corporativos.
Um middleware de proxy de mascaramento baseado em expressões regulares de alta velocidade deve ser obrigatoriamente colocado no primeiro portal do pipeline de embedding. A estrutura que faz o texto passar por um container de proxy baseado em Rust antes de enviá-lo para o tiktoken do Python ou para os scripts de divisão em blocos é a mais estável.
`python
import re
PATTERNS = {
"AWS_KEY": r"(?<![A-Z0-9])[A-Z0-9]{20}(?![A-Z0-9])",
"BEARER_TOKEN": r"Bearer\s+[a-zA-Z0-9_-.=]+",
"SLACK_TOKEN": r"xox[baprs]-[0-9]{10,13}-[0-9]{10,13}-[a-zA-Z0-9]{24,32}",
"GENERIC_SECRET": r'(?i)(password|secret|api_key|access_token)\s*[:=]\s*["\x27]?([^"\x27\s]+)["\x27]?'
}
def scrub_sensitive_data(text: str) -> str:
cleaned = text
for name, pattern in PATTERNS.items():
cleaned = re.sub(pattern, f"[REDACTED_{name}]", cleaned)
return cleaned
`
Se esse filtro for firmemente integrado antes do modelo de embedding, mesmo que um engenheiro de infraestrutura escreva por engano o token de um servidor de produção real na wiki original, apenas a string [REDACTED_SECRET] entrará no banco de dados vetorial e no contexto do modelo de linguagem. Manter o estado onde mesmo um usuário com permissões só consegue ver segredos se acessar diretamente o repositório GitHub original ou o Vault é a única forma de bloquear a ameaça de vazamento de credenciais no nível de infraestrutura.
