Pergunte à IA da sua empresa onde está o contêiner
Imagina uma pergunta normal de trabalho: onde está agora o contêiner do cliente, quanto falta embarcar, o que o gerente prometeu na semana passada e se já existe uma nova fatura?
Numa empresa, a resposta começa no CRM, vai pro e-mail, depois pra uma planilha, depois alguém liga pro responsável pela logística. Vinte minutos mais tarde descobrem que a nota útil estava no cadastro do cliente de outro gerente.
Em outra empresa, a pessoa faz a mesma pergunta ao assistente corporativo e recebe cinco linhas úteis: status atual, quantidade restante, última promessa feita ao cliente e links pros documentos originais. Sem a biografia completa do contêiner desde o dia em que ele foi fabricado.
A diferença não está no modelo. Está no que o modelo consegue ver.
Vou te falar uma coisa: uma IA corporativa sem uma base interna preparada parece um funcionário novo que recebe a senha da pasta compartilhada e uma instrução, se vira. Ele vai achar alguma coisa. Pode até responder com confiança. Isso não quer dizer que encontrou a resposta certa.

RAG não organiza bagunça
Retrieval-augmented generation, ou RAG, é uma forma de encontrar o material relevante numa base de conhecimento e entregá-lo ao modelo de linguagem quando chega uma pergunta. O modelo não precisa decorar suas faturas, cadastros de clientes, procedimentos ou notas dos gerentes. Precisa encontrar a fonte certa, ler e mostrar de onde tirou a resposta.
Só tem um detalhe desagradável. Se a empresa guarda cinco versões do mesmo contrato, uma planilha chamada final_2_really_final.xlsx, três grafias pro mesmo cliente e metade dos arquivos sem data, o RAG não vai consertar isso por mágica.
Vai encontrar a bagunça mais rápido.
Então o primeiro trabalho com IA corporativa não é escolher o modelo. É preparar um conhecimento que o modelo consiga ler.
Três camadas em vez de um índice enorme
Na NF ELIT, a gente montou a busca por etapas. A base incluía documentos corporativos, materiais financeiros, dados de vendas, cadastros de clientes e notas dos gerentes. O documento não recebia um embedding e sumia no meio de uma pilha. Ele ganhava uma camada de navegação.
A primeira camada era a ficha do documento. Título, tipo, data, versão, responsável, cliente, processo relacionado, nível de acesso. Também tinha uma descrição curta em linguagem simples: o que existe ali dentro e quando alguém deveria usar aquilo.
A segunda camada era o mapa semântico. Um resumo curto, as seções principais, empresas, pessoas, pedidos, faturas e embarques mencionados no conteúdo. Nesse ponto o agente confere o próprio caminho: sim, é esse o documento que pode responder à pergunta, não o arquivo ao lado com um título parecido.
A terceira camada era a fonte original. Títulos, parágrafos, tabelas, linhas, páginas. Agora o agente pega o trecho exato ou lê o documento inteiro quando a pergunta é mais ampla.
Parece trabalho extra até você tentar buscar apenas em pequenos pedaços de texto. Um trecho curto responde bem a uma pergunta precisa, mas perde o sentido ao redor. Um trecho grande preserva o contexto e leva metade do documento pra resposta. A hierarquia resolve isso de um jeito normal: encontra o documento, confere o mapa, abre o trecho.
Às vezes importa a palavra exata. Às vezes importa o sentido
Um único tipo de busca não resolve uma base corporativa.
Se alguém pede o número de uma fatura, de um contêiner, de um BL, um código de produto ou uma frase exata do contrato, você precisa de busca textual. Identificador exato tem que bater exatamente.
Se a pergunta é "Por que esse cliente está atrasando a confirmação de novo?" ou "O que a gente costuma fazer quando acontece esse tipo de exceção?", você precisa de busca semântica por sentido.
Na prática, as duas buscas trabalham juntas. A busca híbrida usa um índice lexical pras palavras e identificadores exatos, embeddings pro sentido, depois combina e reordena os resultados. Isso importa muito em logística e finanças. O modelo pode entender o sentido de shipment. O número do contêiner ele precisa achar sem filosofia.
Também dá pra acrescentar o contexto do documento a cada trecho antes da indexação. Assim, um parágrafo dizendo "pagamento em 15 dias" não fica solto. Ele vem com uma nota curta dizendo a qual contrato de cliente e a qual versão pertence. A recuperação contextual é uma das abordagens atuais pra esse problema.
Isso reduz a quantidade de respostas bonitas montadas com o parágrafo de outra pessoa.
Os documentos precisam conhecer uns aos outros
A parte útil começa quando os documentos deixam de se comportar como arquivos separados.
Uma fatura está ligada ao cadastro do cliente. O cadastro está ligado ao gerente e às notas dele. Depois vêm pedidos, embarques, reclamações, análise do site do cliente, notícias públicas, e-mail. A carga tem suas próprias relações: contêiner, trailer, transportadora, datas, quantidade restante, documentos, exceções, status atual.
Essas relações não deveriam depender só de textos parecidos. Use identificadores estáveis como client_id, invoice_id, shipment_id, manager_id. Uma camada de grafo pode entrar por cima quando a pergunta realmente atravessa várias entidades e documentos. O Microsoft GraphRAG, por exemplo, trata documentos, unidades de texto, entidades e relações como objetos separados e conectados.
O grafo não está ali porque a palavra fica bonita na apresentação. Está ali quando a resposta não existe sem a relação.
Pensa nesta pergunta: "Quais faturas em aberto pertencem aos embarques deste cliente que atrasaram depois da última mensagem do gerente?" Um parágrafo não responde isso com segurança. O agente precisa seguir as relações, juntar várias fontes, comparar datas, depois escrever a resposta.
Não misture o arquivo e os dados vivos sem pensar
Essa é outra fronteira que muita gente perde.
Políticas, instruções, contratos, notas e materiais de referência funcionam bem como documentos indexados. Saldos atuais, valores, datas de chegada, localização do trailer e status do contêiner mudam com o tempo. Você não pode jogar isso uma vez num banco vetorial e chamar de verdade pra sempre.
Pra esses dados, o assistente deve consultar a fonte viva por API, SQL ou por uma ferramenta do sistema corporativo. O RAG explica o contexto. A API mostra o estado agora.
Na logística isso fica muito claro. Você conecta os dados da transportadora ou uma tracking API, e o gerente pergunta: "O que está acontecendo com a carga do Cliente X?" O assistente encontra o cadastro do cliente, os pedidos abertos e as notas recentes, depois consulta os status atualizados nas transportadoras. A resposta final deixa só as exceções e o próximo passo. O resto fica atrás da tela.
O usuário não precisa assistir a esse caminho. Precisa da resposta.
O que entra na base antes da primeira pergunta
Comece pelo material bruto que a empresa já tem: registros do CRM, pastas, PDFs, planilhas, procedimentos, e-mail, notas, transcrições de chamadas. Um agente ajuda a separar tudo por tema, identificar documentos, versões, entidades e possíveis relações. Os donos dos processos ainda precisam conferir o resultado.
Pra cada fonte, registre algumas coisas simples:
- Qual é o original e onde ele fica?
- Quem é o responsável pelo dado e quem pode ver?
- Com que frequência ele muda?
- O que deve ser preservado palavra por palavra e o que pode ser indexado por sentido?
- Como ele se liga a um cliente, pedido, funcionário ou embarque?
- Como o assistente vai mostrar a fonte e o horário da última atualização?
Depois você complementa a base onde fizer sentido: site do cliente, referências do setor, registros oficiais, notícias relevantes. Mantenha essa camada externa claramente separada dos fatos internos. Uma nota do gerente, um registro do CRM e uma matéria na internet não têm o mesmo peso.
E o mais importante: depois da ingestão, escreva perguntas reais de controle. Não pergunte "O que tem na base?" Pergunte "Mostre os pedidos abertos do cliente", "Por que o valor mudou?", "O que o gerente prometeu?", "Quais cargas estão sem movimento há mais de dois dias?"
Pra cada pergunta você já deve conhecer a fonte correta. Assim você testa a busca, não a beleza do texto.
Plataforma pronta ou camada própria
As plataformas comerciais já fazem parte desse trabalho.
O Bitrix24 guarda registros do CRM, tarefas, arquivos e chats, e consegue indexar o conteúdo dos documentos. O CoPilot resume conversas e sugere atualizações nos campos do CRM. Funciona quando a maior parte da atividade da empresa já está dentro do Bitrix24. Mas a busca do CRM ainda depende dos campos do cadastro, e a busca de documentos não transforma automaticamente arquivos, notas, status externos e relações entre entidades num único sistema confiável de conhecimento.
Os conectores do Microsoft 365 Copilot levam fontes externas pra busca respeitando as permissões da origem. O Atlassian Rovo conecta Jira, Confluence e aplicativos de terceiros pelo Teamwork Graph. O Salesforce Agentforce Data Library indexa artigos de conhecimento, arquivos enviados e fontes da web dentro dos fluxos de CRM. Glean, ServiceNow e outras camadas de busca corporativa trabalham no mesmo espaço geral.
A escolha é simples. Se a empresa já vive dentro de um ecossistema e as relações padrão servem pro trabalho, uma plataforma pronta encurta o caminho. Se os dados estão espalhados entre CRM, sistema financeiro, APIs de logística, pastas locais e processos próprios, uma camada feita pra empresa com APIs, índice de busca e agente costuma encaixar melhor.
Hoje dá pra montar um protótipo com pouco dinheiro. Eu não prometo que o sistema funcionando quase não exige configuração. Regras de acesso, versões dos documentos, atualizações, exclusões, perguntas de controle, revisão manual dos primeiros resultados, tudo isso continua.
O modelo ficou mais barato. A ordem dentro da empresa não ficou de graça.
O que o funcionário vê
Por fora, tudo deveria parecer simples. Você abre a interface normal e pergunta:
"Mostre o status atual dos pedidos deste cliente, as últimas promessas do gerente e qualquer carga com exceção."
Por dentro, o sistema encontra o cadastro do cliente, confere os documentos relacionados, lê as descrições curtas, escolhe os trechos certos, consulta os status atuais, aplica as permissões e monta uma resposta com fontes.
O funcionário não vê isso. Nem deveria.
Ele vê cinco linhas em que dá pra confiar.
É disso que a IA corporativa deveria cuidar.