Um assistente de conhecimento que nunca sai do seu edifício.

Todos já estiveram naquela reunião. Alguém faz a demonstração de uma IA a responder a perguntas sobre as políticas da própria empresa, em linguagem corrente, com citações, e a sala inclina-se para a frente. Depois alguém faz a segunda pergunta: então carregamos os nossos contratos para onde, exatamente? E a sala recosta-se.

As duas reações estão certas. A necessidade é real: o conhecimento de uma empresa vive em contratos, tickets, wikis, processos e código, e quase nada disso é respondível sem um humano a escavar. O bloqueio também é real: esse mesmo conhecimento é a coisa mais sensível que a empresa possui, e «enviem-no para uma API» não é uma frase que o departamento jurídico vá assinar. A parte que quase ninguém na sala sabe é que as duas coisas já não estão em conflito. O pipeline inteiro que torna os documentos respondíveis pode correr numa máquina, num rack, sob uma jurisdição, sem nada sair dela.

O que é realmente um assistente de conhecimento

Retire a adoração das siglas e o mecanismo é simples. Os seus documentos são divididos em passagens e codificados em embeddings, impressões digitais numéricas do significado. Essas impressões vivem numa vector database. Quando alguém faz uma pergunta, a pergunta é codificada da mesma forma, a base encontra as passagens cujo significado está mais próximo, e o modelo responde a partir dessas passagens, citando o que usou. O setor chama-lhe retrieval-augmented generation. O importante é o que isso implica: o modelo não memoriza o seu arquivo. O pipeline consulta-o, ao vivo, em cada pergunta.

O que significa que o pipeline é a superfície sensível. Não apenas o modelo: os documentos que entram, os embeddings feitos a partir deles, cada pergunta que alguém faz, cada resposta que volta, e os logs de tudo isso. Decida onde o pipeline vive e decidiu onde vive o conhecimento da sua empresa.

O pipeline é o problema de privacidade

Percorra a receita padrão da cloud para esta funcionalidade e conte os terceiros. Os documentos são codificados através de uma embeddings API alojada. Os vetores vão para um serviço gerido de vector database. As perguntas são encaminhadas por outra API para um modelo alojado. Os logs acumulam-se em cada paragem, sob a política de retenção de cada fornecedor. Quatro entidades externas, cada uma delas uma resposta que agora deve ao auditor.

Organizações que nunca carregariam um contrato passam de bom grado o mesmo contrato por uma embeddings API, porque «são só vetores». Os embeddings não são números anónimos. São uma codificação, com perdas, do significado do texto, construída especificamente para que esse significado possa ser pesquisado. Uma vector database preenchida a partir do seu arquivo é o seu arquivo, transformado. Trate a sua jurisdição, a sua tenancy e os seus controlos de acesso exatamente como trata os próprios documentos, porque funcionalmente é isso que ela é.

Assim que se vê o pipeline inteiro, a resposta single-tenant deixa de ser uma preferência e passa a ser o desenho. Uma máquina guarda os documentos, os embeddings, o modelo, as perguntas, as respostas e os logs. A lista de terceiros que veem um token tem uma entrada: ninguém. Quando o auditor perguntar quem mais pode ver isto, essa é a resposta inteira, e é uma tarde melhor do que um diagrama de fluxo de dados com cinco logótipos em cima.

O que significa a camada managed

Dimensionamos a GPU ao modelo e ao corpus com honestidade (a lógica de emparelhamento na página de GPU Servers é a versão pública dessa conversa), instalamos e afinamos a stack de serving por trás de um endpoint compatível com OpenAI, montamos o modelo de embeddings e a vector database ao lado, e mantemos o conjunto a funcionar. O trabalho de integração da sua equipa tem dois pontos: apontar a ingestão aos seus documentos, e chamar o endpoint. As batalhas de compatibilidade, a fixação de drivers, os trade-offs de quantização acontecem no nosso tempo, que é todo o sentido do acordo. O nosso serviço GPU managed define o âmbito do trabalho de engenharia.

Para quem isto é realmente

Os setores ordenam-se a si próprios pelo que receiam. Equipas jurídicas, porque o sigilo profissional é existencial e um contrato não pode tocar numa API de terceiros. Saúde, porque um incidente de notificação obrigatória é o pesadelo e o contexto do doente passa pelos prompts. Fintech e seguros, porque a pergunta do regulador tem de ter uma resposta com um nome em cima. Setor público, porque a soberania é cada vez mais um requisito de contratação e não uma preferência. E equipas de produto que constroem sobre pesos abertos, porque uma base de conhecimento que treina o modelo de outra pessoa é um fosso com um buraco. Receios diferentes, uma arquitetura.

E o limite honesto, porque é hábito da casa: se o seu corpus é pequeno, de baixo volume e genuinamente não sensível, uma API alojada é muitas vezes a resposta razoável e dizemo-lo quando perguntarem. Este artigo é para o arquivo que não pode ir para um terceiro. Para esse arquivo, a pergunta nunca foi se o assistente vale a pena. Foi se os documentos estavam seguros, e a resposta é deixar de os enviar para onde quer que seja.

“Os embeddings não são números anónimos. São os seus documentos, codificados.”