Web Search do Bedrock no GovCloud: um ADR sobre grounding regulado

O problema que me trouxe aqui é antigo: sistemas de decisão assistida por LLM em domínio regulado precisam de procedência, não de fluência. Quando um analista pergunta "qual é o limite atual dessa cota" ou "esse produto ainda está autorizado", uma resposta sem link auditável é passivo, não ativo.

Até agora eu resolvia isso com uma das duas soluções feias. A primeira: um índice próprio, crawler, normalização, embeddings, reindexação, que ninguém quer operar e que envelhece em dias. A segunda: uma API de busca de terceiro chamada de dentro de uma Lambda, o que significa egress para fora da conta, segredo em rotação, allowlist de saída e o loop de tool-call escrito à mão. Eu mantive exatamente esse desenho por meses no meu próprio pipeline de conteúdo, com SigV4 artesanal, e ele quebrava por motivos que não tinham nada a ver com o problema de negócio.

As forças que pesam nesta decisão, em ordem de dureza: (1) o dado da consulta não pode sair da fronteira do provedor sem controle explícito, em GovCloud isso é requisito, não preferência; (2) toda afirmação exibida ao usuário precisa carregar fonte; (3) o custo é por query e não é desprezível; (4) o time não deve operar índice nem crawler; (5) a autorização precisa ser central, aplicável por Organization e por Região, com trilha de auditoria. A chegada do tool no GovCloud endereça (1) e (4), mas (2), (3) e (5) continuam sendo trabalho meu.

Antes de decidir, vale precisar o objeto. Web Search é um tool server-side exposto apenas pela Responses API no endpoint bedrock-mantle, não existe em bedrock-runtime, nem em Converse, nem em InvokeModel. Você adiciona {"type": "web_search"} ao array tools usando a própria biblioteca cliente da OpenAI com uma API key do Bedrock, e o modelo decide se chama. Isso amarra a decisão a uma família de modelos: na documentação, os suportados no GovCloud (US-West) são openai.gpt-5.6-terra, openai.gpt-5.6-luna e openai.gpt-5.4; nas Regiões comerciais entram também gpt-5.6-sol e gpt-5.5. Não há Claude, Nova ou Mistral nesse caminho.

Internamente são duas operações, e essa distinção é o coração do ADR. Search devolve título, URL e snippet a partir do índice web e do knowledge graph mantidos pela Amazon, e não faz chamada de saída. Fetch recupera o conteúdo de uma URL específica: com external_web_access=false ele lê só o cache do Bedrock; com true ele consulta o cache e vai à web externa apenas em cache miss.

A recuperação é estritamente regional, cada Região opera seu próprio tier de search e fetch, e consultas, fetches, índice e resultados não trafegam entre Regiões. us-gov-west-1 é uma dessas Regiões, ao lado de us-east-1, us-east-2 e us-west-2. O volume de contexto por chamada de Search se controla com search_context_size: low até 5 observações, medium até 11 (default), high até 25, orçamento compartilhado entre múltiplas queries da mesma chamada. Esse parâmetro não limita quantas chamadas de Search o modelo faz por turno.

Decisão: adotar a opção A: Web Search nativo em modo cache-only, com o parâmetro explícito e a permissão negada por SCP. A configuração é deliberadamente redundante, porque parâmetro e permissão falham de formas diferentes.

No código, todo chamador manda tools=[{"type":"web_search","external_web_access":false,"search_context_size":"low"}]. low é o default do meu wrapper; medium é opt-in por rota de pesquisa; high exige justificativa, porque 25 observações por chamada inflam o input em algo na ordem de 10 mil tokens por turno.

No perímetro, um SCP nega bedrock-websearch:ExternalWebAccess em toda a Organization. Note que a granularidade de IAM aqui é curta: os três actions (InvokeSearch, InvokeFetch, ExternalWebAccess) só suportam Resource: "*", e a única condition key é a global aws:RequestedRegion. Logo, o "restringir por Região" que o anúncio menciona é literalmente um StringEquals em aws:RequestedRegion, e eu o uso para fixar us-gov-west-1 no perímetro regulado, o que também é a única forma de impedir que uma chamada mal roteada seja atendida por outro tier regional.

Nas roles de aplicação eu não uso AmazonBedrockFullAccess. Uso uma policy própria com InvokeSearch e InvokeFetch sob a condition de Região, porque quero que a ausência de ExternalWebAccess seja uma decisão registrada e não um efeito colateral de qual policy gerenciada alguém anexou.

CloudTrail com data events habilitado para bedrock-websearch é parte da decisão, não um follow-up: sem isso, negações não são reportadas em lugar algum.

Custo. A cobrança é por query, uma query é um pedido de busca. A página do AgentCore lista US$ 7 por 1.000 queries para a variante dele; análises independentes colocam o tool built-in perto de US$ 12 por 1.000 (confirme a taxa vigente para sua Região na página de preços do Bedrock antes de modelar). O detalhe que quebra orçamento não é o preço unitário: é que search_context_size limita observações por chamada, mas não limita quantas chamadas de Search o modelo faz no turno. Um turno multi-hop que reformula a query duas vezes custa três queries. A US$ 0,012 por query, 50 mil turnos/mês a 3 queries dão US$ 1.800/mês só de busca, antes da inferência, e antes do input inflado pelas observações. Modele por turno, não por query, e ponha um teto diário de tokens e de queries no seu próprio wrapper, do lado da aplicação, porque o IAM não conta chamadas.

Idempotência. A chamada não é idempotente: um retry re-executa as buscas e cobra de novo. Meu retry é max_attempts=2 com jitter e um cache de resultado com chave sha256(prompt + modelId + toolConfig), TTL de horas. Timeout do lado do chamador precisa acomodar hops seriais dentro de uma única chamada, no meu gerador de artigos eu opero com 300 s de teto.

Auditoria. Por design, o CloudTrail não expõe o texto da query, as URLs nem os resultados brutos: o texto é tratado como prompt de inferência. Você tem quem chamou, quando, de onde, fetchMode, urlCount, failedUrlCount e fetchedSources. Se o seu regulador quer saber o que o agente consultou, essa resposta não está no CloudTrail, está no ledger de citações que você gravar a partir das anotações url_citation.

A ilusão do ReadOnly. AmazonBedrockExternalWebSearchReadOnly e AmazonBedrockExternalWebSearchFullAccess têm hoje permissões efetivas idênticas, a versão "ReadOnly" não restringe recuperação externa. Se sua revisão de segurança aprova por nome de policy, ela aprovou acesso à web externa achando que aprovou leitura.

A ilusão de restringir fontes por IAM. Negar InvokeSearch e manter InvokeFetch não confina o modelo às suas fontes: Fetch se aplica a qualquer URL que o modelo produza, inclusive uma que veio do prompt do usuário ou da memória paramétrica dele. Controle de fonte, se for requisito, tem de morar na aplicação, validando cada URL citada contra uma allowlist antes de exibir.

Injeção de prompt via conteúdo recuperado. Snippet e página buscada são entrada não confiável entrando no mesmo contexto que a instrução. Em carga regulada eu trato observação de Search como dado, nunca como comando, e mantenho o filtro de injeção antes e depois do turno, a mesma disciplina que aplico em qualquer RAG.

Frescor que engana. Em cache-only o frescor é o do índice e do cache da Amazon, não o da origem. Para preço, cota e prazo regulatório eu não confio no que voltou sem conferir a data na própria resposta, e escrevo em volta do que não puder confirmar.

Acoplamento de modelo. O tool só existe na Responses API sobre bedrock-mantle, em modelos GPT. Se amanhã a decisão de modelo mudar para Claude ou Nova, o grounding muda de caminho junto, por isso mantive a opção C viva no registro, e não como nota de rodapé.