Um assistente que responde perguntas usando os documentos e dados da própria empresa é, hoje, um dos usos mais procurados de IA generativa. Políticas internas, contratos, manuais técnicos, histórico de atendimento: tudo isso pode virar resposta em segundos. A pergunta que vem logo depois é a mais importante: como fazer isso sem expor informação e sem perder o controle do custo? Neste artigo, mostramos uma arquitetura de referência no Amazon Bedrock e os cuidados que fazem diferença.
Por que construir na AWS
Para empresas que já têm dados na AWS, construir o assistente no mesmo ambiente traz vantagens práticas:
- O dado fica onde já está. Os documentos continuam no Amazon S3 e os dados estruturados no lakehouse ou no Amazon Redshift, sob as mesmas regras de acesso e auditoria.
- Escolha de modelo sem trocar de plataforma. O Bedrock oferece modelos de diferentes fornecedores na mesma API. Dá para usar um modelo maior onde a qualidade importa e um menor onde o volume é alto, e trocar quando surgir uma opção melhor.
- Segurança integrada. IAM, AWS KMS, VPC e CloudTrail funcionam para a IA do mesmo jeito que para o resto do ambiente. Segundo a AWS, o conteúdo enviado ao Bedrock não é usado para treinar os modelos base.
- Pagamento pelo uso. Não é preciso manter infraestrutura de GPU ligada para começar.
A arquitetura de referência
Fontes e preparo. Os documentos ficam em buckets do S3 organizados por área e nível de sensibilidade. Cada documento recebe metadados, como área, confidencialidade e data de vigência. Esse passo parece burocrático, mas é ele que permite filtrar depois.
Indexação. As Knowledge Bases do Amazon Bedrock leem os documentos, dividem em trechos, geram os vetores e mantêm o índice atualizado. Os metadados de cada documento acompanham os trechos.
Consulta. Quando a pessoa faz uma pergunta, a aplicação identifica quem está perguntando e aplica filtros de metadados na busca. Um analista de compras só recebe trechos de documentos que ele poderia abrir. O modelo gera a resposta a partir desses trechos e cita as fontes.
Proteção. Os Guardrails do Bedrock verificam a entrada e a saída: bloqueiam temas fora do escopo, mascaram dados pessoais e reduzem respostas sem base nos documentos.
Registro. O log de invocações do Bedrock pode ser enviado ao Amazon CloudWatch ou ao S3, guardando perguntas, respostas e fontes usadas, com retenção definida. É esse registro que permite investigar uma resposta errada e medir a qualidade ao longo do tempo.
Os cuidados que mais fazem diferença
Permissão é tarefa da busca, não do modelo. Pedir ao modelo que "não revele informações confidenciais" não é controle de acesso. O filtro precisa acontecer antes, na busca, com base em quem pergunta.
Documento ruim gera resposta ruim. Três versões da mesma política, sem data de vigência, produzem respostas contraditórias. Vale revisar e marcar o que está vigente antes de indexar.
Teste com perguntas reais. Antes de liberar o assistente, monte um conjunto de perguntas com as respostas esperadas e rode a cada mudança de prompt, modelo ou base. Sem isso, não há como saber se uma alteração melhorou ou piorou o resultado.
Custo sob controle. O custo cresce com o tamanho do contexto enviado ao modelo. Trechos bem divididos, poucos trechos por consulta e o modelo certo para cada tarefa costumam reduzir a conta sem perder qualidade.
Por onde começar
Um bom primeiro projeto tem escopo fechado: uma área, um conjunto de documentos que alguém conhece bem e um grupo de usuários que vai usar de verdade. Com isso, dá para validar a arquitetura, ajustar os filtros e medir o ganho antes de expandir para outras áreas.
Conclusão
Construir um assistente com os dados da empresa no Amazon Bedrock é tecnicamente acessível. O que separa um projeto seguro de um risco é o cuidado com o que vem antes do modelo: documentos organizados, metadados, filtros de permissão, guardrails e registro. Com essa base, o assistente deixa de ser um experimento e passa a ser uma ferramenta em que as pessoas confiam.
