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é.