Fundamentos do Amazon Bedrock: APIs, Acesso a Modelos, Preços, Tipos de Inferência e Avaliações

Amazon Bedrock é o serviço que o exame AIF-C01 nomeia mais do que qualquer outro, e também é o serviço que muda mais rápido. Essa combinação é perigosa: decorar uma lista de modelos ou um preço por token é uma estratégia de estudo com validade de semanas, enquanto decorar mecanismos, como on-demand, batch, provisioned throughput, service tiers e perfis de inferência cross-Region realmente se comportam, continua correta por anos. Esta lição foi construída em torno dessa divisão. Cada número abaixo está preso a uma fonte da AWS de primeira parte em outubro de 2026, e qualquer coisa que a AWS não confirma é sinalizada em vez de ensinada.

Ao final desta lição você será capaz de:

• explicar o que "totalmente gerenciado, serverless, API única" significa operacionalmente e nomear os dois endpoints do Bedrock;
• enunciar as regras de acesso a modelos de 2026, incluindo o formulário Anthropic que a maioria dos candidatos esquece;
• escolher entre on-demand, batch e provisioned throughput, e entre os quatro service tiers, usando preço, latência, compromisso e suporte a recursos;
• escolher o perfil de inferência certo para custo versus residência de dados e prever o que o CloudTrail vai registrar;
• percorrer uma árvore de decisão de seleção de modelo e defender uma escolha com preços por token verificados;
• nomear os quatro caminhos de customization e dizer qual deles exige provisioned throughput;
• selecionar avaliação automática, humana ou LLM-as-a-judge para uma métrica dada;
• defender o veredito comparativo entre Bedrock, SageMaker auto-hospedado, um serviço de IA pré-construído e construir você mesmo.

---

1. O que o Amazon Bedrock é

1.1 A definição que a AWS usa

Amazon Bedrock é um serviço totalmente gerenciado e serverless que te dá uma única API para invocar modelos de fundação de muitos provedores. Três palavras carregam toda a proposta de valor:

• Totalmente gerenciado: a AWS roda a infraestrutura, o scaling e o hospedagem do modelo; você nunca vê uma instância, uma URL de endpoint ou uma GPU.
• Serverless: você paga por token (on-demand e batch) ou por hora (provisioned throughput); não existe conta de capacidade ociosa, a menos que você compre uma deliberadamente.
• API única: um formato de requisição, um SDK, um conjunto de ações de IAM; trocar de Anthropic Claude para Amazon Nova é uma mudança de modelId, não uma reescrita.

Essa última propriedade é a frase mais examinável desta lição. Uma questão que diz "sem reescrever a lógica da aplicação" está apontando para a API unificada, e cada outra opção nessa questão (roteamento cross-Region, provisioned throughput, model import) é um mecanismo completamente diferente.

1.2 O catálogo de provedores

A AWS lista 100+ modelos de fundação sem publicar uma contagem exata. A lista de provedores de primeira parte verificada em outubro de 2026 é:

📚 Você sabia? DeepSeek é oficialmente suportado: DeepSeek V3.2, V3.1 e R1 aparecem todos na página Models at a glance da AWS, e o V3.2 roda tanto no bedrock-runtime quanto no endpoint compatível com OpenAI bedrock-mantle. Candidatos que pulam o catálogo atual costumam assumir que o DeepSeek só está disponível por meio de um marketplace ou de um stack auto-hospedado; no exame, "Amazon Bedrock não hospeda DeepSeek" é um distrator por construção.

1.3 Os dois endpoints

O Bedrock expõe dois endpoints de serviço, e o exame testa quais operações vivem em cada um:

A distinção importa na prática: o bedrock-mantle existe para que uma aplicação escrita para o SDK OpenAI ou Anthropic possa apontar para o Bedrock com uma mudança de base URL e chave, enquanto o bedrock-runtime é a casa do Converse: a API que te dá ferramentas, Guardrails e paridade multi-provedor em um único formato de requisição.

1.4 Arquitetura: uma API, muitos modelos

1.5 O que a AWS promete sobre seus dados

Dois compromissos aparecem na visão geral da documentação do Bedrock e ambos têm formato de exame:

1. Entradas e saídas não são compartilhadas com provedores de modelo de terceiros.
2. Entradas e saídas não são usadas para treinar os modelos de fundação base. Fine-tuning, em contraste, treina uma cópia privada do modelo que pertence à sua conta: que é exatamente por que um modelo customizado é seu e por que ele é cobrado de forma diferente.

📚 Você sabia? A garantia de "não usada para treinar modelos base" é precisamente por que o fine-tuning é descrito como a criação de um modelo customizado privado: seu JSONL rotulado vai para o S3, um job de treino produz um checkpoint que só a sua conta pode invocar, e o FM base que outros clientes usam permanece intacto. O fato companion que os candidatos perdem é que invocar um modelo com supervised fine-tuning exige Provisioned Throughput, on-demand não vai rodá-lo, enquanto Custom Model Import (traga seus próprios pesos) pode rodar on-demand.

1.6 Quatro coisas que o Bedrock não é

Confusões que produzem opções erradas mais vezes do que qualquer outro fato sobre o Bedrock:

---

2. Acesso a modelos: o que realmente desbloqueia uma invocação

O acesso a modelo costumava ser um opt-in por clique para cada modelo. Em 2026 o fluxo é mais simples, com uma exceção que ainda derruba candidatos:

Depois da etapa 4, InvokeModel/Converse funcionam; antes dela, você recebe um erro de acesso que parece um problema de IAM e não é um.

---

3. A superfície da API: Invoke, Converse e os endpoints de compatibilidade

3.1 Famílias de operações

3.2 Parâmetros de inferência do Converse: exatamente quatro

A InferenceConfiguration base da API Converse contém quatro parâmetros e mais nada:

Controles específicos do modelo (por exemplo topK ou o budget de thinking de um provedor) vão para additionalModelRequestFields, que é repassado ao modelo. Uma opção que alega que o Converse expõe cinco ou seis parâmetros base de primeira classe está testando se você conhece a fronteira entre a API portátil e o escape hatch específico do provedor.

3.3 Streaming

O streaming usa InvokeModelWithResponseStream (família Invoke) ou ConverseStream (família Converse), com a ação de IAM bedrock:InvokeModelWithResponseStream. Se um dado modelo pode fazer streaming é descobrível programaticamente: GetFoundationModel retorna responseStreamingSupported. Se uma questão pergunta "como você confirma o suporte a streaming antes de prometê-lo na interface?", essa flag é a resposta.

3.4 Tool use e escolha forçada de ferramenta

toolChoice tem exatamente três valores:

Essa terceira linha é um micro-fato clássico de exame: forçar uma ferramenta nomeada não é universal, e uma opção que generaliza isso para todo modelo do Bedrock está errada.

3.5 Saída estruturada

Duas rotas existem para JSON conforme a um schema:

1. Tool use forçado (toolChoice: {any: {}} ou {tool: {name:...}}): a rota de longa data, porque restringir o modelo ao JSON schema de uma ferramenta é estrutural em vez de consultivo.
2. Saída estruturada nativa: adicionada ao Converse/ConverseStream em 2026-02-04 via outputConfig.textFormat.type = "json_schema" junto com toolSpec.strict.

A lacuna de confiabilidade é grande e publicada pela AWS: um teste comunitário de 102 amostras no AWS Builder Center encontrou "retorne JSON válido" apenas com prompt funcionando em cerca de 70 to 80% das vezes contra 99%+ com tool use forçado. Transforme isso em um número operacional: 10.000 documentos de fatura com 70 to 80% de sucesso sem ferramenta significam cerca de 2.500 análises e tentativas de novo com falha; a 99% significam cerca de 100.

Exemplo resolvido 1, escolhendo o mecanismo certo para 10.000 extrações estruturadas. O trabalho precisa de JSON estrito, sem interatividade, e resultados até de manhã. Resposta: Converse on-demand ou no tier Flex com outputConfig.textFormat.type = "json_schema", porque a inferência batch não suporta saída estruturada nem tool calling, e ela também não roda modelos provisionados. Duas armadilhas separadas, uma questão.

📚 Você sabia? A instrução de JSON só com prompt falha por um motivo estrutural: o modelo está amostrando, não validando. Pedir educadamente no system prompt muda a probabilidade de chaves aparecerem; isso não cria uma restrição. Tool use forçado e a saída json_schema funcionam porque tornam a saída inválida impossível por construção em vez de improvável, e é exatamente por isso que a própria orientação de confiabilidade da AWS trata "só diga JSON no prompt" como uma resposta distratora em toda questão de saída estruturada.

3.6 Anatomia da requisição: onde cada controle vive

Duas leituras desse payload importam no exame: a superfície portátil (system, messages, inferenceConfig, toolConfig, guardrailIdentifier) é a mesma para todo provedor, e é isso que faz a troca de provedor ser uma mudança de uma linha; e additionalModelRequestFields é o escape hatch deliberado para qualquer coisa específica do provedor, e é por isso que a lista de parâmetros base continua em quatro, não importa quantos controles um dado modelo exponha.

---

4. Preços: quatro mecanismos e quatro service tiers

A precificação do Bedrock não é um modelo único: é um par ortogonal de escolhas: como você compra capacidade (on-demand / batch / provisioned) e qual service tier você aceita (priority / standard / flex / reserved).

4.1 Os três mecanismos de capacidade

4.2 Os quatro service tiers (o segundo eixo)

serviceTier é definido por requisição e se aplica a tráfego on-demand:

As condições de entrada do tier Reserved publicadas pela AWS (fonte secundária: AWS Builder Center) são ≥ 100K tokens de entrada por minuto e ≥ 10K tokens de saída por minuto, um compromisso de 1 ou 3 meses, 99,5% de uptime com transbordo para o Standard.

4.3 Exemplo resolvido 2: aritmética pura de on-demand

O próprio exemplo da AWS: Amazon Titan Text Lite a $0.0003 por 1K tokens de entrada e $0.0004 por 1K tokens de saída.

$$\frac{2{,}000}{1{,}000}\times \$0.0003 + \frac{1{,}000}{1{,}000}\times \$0.0004 = \$0.001 \text{ per call}$$

A 1.000 chamadas por hora isso dá $1.00 por hora. O segundo exemplo da AWS, AI21 Jurassic-2 Mid a $0.0125 por 1K tokens nos dois sentidos, para 10.000 de entrada / 2.000 de saída:

$$\frac{10{,}000}{1{,}000}\times \$0.0125 + \frac{2{,}000}{1{,}000}\times \$0.0125 = \$0.15 \text{ per request}$$

4.4 Exemplo resolvido 3: batch economiza exatamente 50%

Claude 3.5 Sonnet (Public Extended Access): $6.00 entrada / $30.00 saída por 1M de tokens on-demand, $3.00 / $15.00 no batch. Um job de 10M de entrada + 2M de saída:

A entrega é tipicamente dentro de 24 horas, e o job não pode usar tool calling nem saída estruturada.

4.5 Exemplo resolvido 4: provisioned throughput queima quer você use quer não

A aritmética documentada da AWS para um model unit a $16.20/hora:

$$1 \times \$16.20 \times 24 \text{ h} \times 31 \text{ d} = \$12{,}052.80 \text{ per month}$$

Taxas horárias publicadas para Cohere Command por model unit: $49.50 (sem compromisso), $39.60 (1 mês, −20%), $23.77 (6 meses, −52%). Llama 2 13B/70B provisionado: $21.18 (1 mês) e $13.08 (6 meses). A regra de decisão: provisioned só vence quando o custo das horas ociosas é menor do que a economia de capacidade e por token que você realmente captura: para Claude, Nova e a maioria dos modelos modernos a AWS não publica taxas horárias de modo algum e pede que você contate o time da conta.

4.6 Exemplo resolvido 5: aritmética dos service tiers

DeepSeek V3.1 em ap-southeast-2 é precificado a $0.5974 de entrada / $1.7304 de saída por 1M de tokens no tier Standard. Aplicando os modificadores documentados:

Envie 10% do tráfego para o Priority, 60% para o Flex e 30% para o Standard e a mistura é 0.10 \times 4.07 + 0.60 \times 1.16 + 0.30 \times 2.33 \approx \1.80$: cerca de **23$2.33. Disciplina de tiers, não escolha de modelo, é geralmente a otimização mais barata disponível.

4.7 Preços de tokens verificados (USD por 1M, Standard / on-demand)

Preços fixos e horários que valem a pena saber: armazenamento de modelo customizado $1.95/mês, Titan Text Embeddings V2 $0.00002 por 1K tokens, Cohere Embeddings $0.0001 por 1K tokens (uma lacuna de 5× no mesmo trabalho).

4.8 Dois alavancas de economia a mais: roteamento e caching

O Intelligent Prompt Routing opera dentro de uma família de modelos, Claude Sonnet ↔ Claude Haiku, Nova Pro ↔ Nova Lite, e a página de preços da AWS alega que ele pode cortar o custo em até 30%. A aritmética por trás da alegação é simples: envie prompts fáceis para o irmão barato e mantenha prompts difíceis no modelo forte.

Exemplo resolvido 10: aritmética de roteamento. Use uma âncora verificada: Claude 3.5 Sonnet a $6.00 / $30.00 por 1M de tokens. A taxa por token do irmão não é publicada nas fontes verificadas para esta lição, então assuma um modelo classe Haiku a $1.00 / $5.00 (ilustrativo) e uma mistura diária de 10M entrada / 2M saída:

Duas leituras se seguem. Primeiro, a alegação publicada da AWS é "até 30%", que é o número conservador no tráfego real: nunca cite o 42% ilustrativo como um número da AWS. Segundo, o roteamento é uma alavanca de mistura de tráfego em vez de um desconto por requisição, e é exatamente isso que o separa do batch (−50% em cada token), do tier Flex (−50% em cada token) e de um perfil global (−10% em cada token).

O prompt caching (Amazon Nova) é a outra alavanca, e seus limites são precisos: um mínimo de 1.000 tokens por checkpoint, no máximo 4 checkpoints por requisição, um time to live de 5 minutos e um teto de cache de 20.000 tokens. Tokens de entrada em cache são cobrados pela taxa de cache read: para o Claude 3.5 Sonnet isso é $0.60 por 1M contra $6.00 sem cache (uma redução de 10×), enquanto um cache write custa $7.50 por 1M (um prêmio de 25%). Caching, portanto, só paga quando um checkpoint é lido repetidamente dentro do seu TTL.

Relacione cada mecanismo de preços à sua regra documentada:

---

5. Inferência cross-Region: perfis, preço e residência

5.1 Perfis geográficos versus globais

A inferência cross-Region é expressa através de inference profiles, e existem dois tipos:

5.2 O que o CloudTrail mostra

Requisições cross-Region podem ser roteadas para Regiões que não estão habilitadas manualmente na sua conta; os dados permanecem na rede da AWS e são criptografados em trânsito. O AWS CloudTrail registra onde o trabalho realmente aconteceu em additionalEventData.inferenceRegion, e é exatamente por isso que uma entrada do CloudTrail pode mostrar uma Região diferente da Região de origem da requisição sem implicar erro de faturamento. A precificação sempre usa a Região de origem, então não existe sobretaxa de roteamento.

5.3 Dois limites que os candidatos perdem

1. Inference profiles não suportam Provisioned Throughput. Capacidade reservada por model unit e roteamento cross-Region são mecanismos separados; você não pode combiná-los.
2. Application profiles existem para tagging de alocação de custo: um conceito separado dos perfis de roteamento, usado para atribuir gasto em vez de posicionar computação.

Exemplo resolvido 6: economia cross-Region. Um perfil geográfico como us.amazon.nova-lite-v1:0 mantém o processamento dentro dos Estados Unidos às tarifas standard. Um perfil global é cerca de 10% mais barato, mas pode executar em qualquer Região comercial. Para uma carga de trabalho financeira na UE, a escolha é decidida pela residência, não pelo preço: escolha o perfil geográfico (EU) e aceite a tarifa mais alta.

📚 Você sabia? O desconto de ~10% do perfil global e a regra do "preço vem da Região de origem" apontam para direções opostas e ambas são verdadeiras: sua fatura é calculada com a lista de preços da sua Região de origem, mas as taxas do pool global são publicadas cerca de 10% mais baixas, então rotear globalmente economiza dinheiro sem uma linha de sobretaxa. Enquanto isso, o Intelligent Prompt Routing, um recurso completamente diferente, pode cortar o custo em até 30% roteando dentro de uma família de modelos (Claude Sonnet ↔ Claude Haiku, Nova Pro ↔ Nova Lite). Três alavancas de economia separadas, três mecanismos diferentes: batch (−50%), tier Flex (−50%), perfil global (−10%), roteamento de prompts (até −30%).

---

6. Escolhendo um modelo: a árvore de decisão que a AWS realmente ensina

6.1 A árvore de decisão

6.2 Matriz verificada provedor × modelo

6.3 Exemplo resolvido 7: mesmo trabalho, custo de embedding 5×

Um blog da AWS calculou uma ingestão RAG de um documento de 5M de tokens mais 0,5M de tokens de query = 5,5M de tokens:

Mesmo corpus, mesmo trabalho, diferença de 5×, e é por isso que a escolha do modelo de embedding, não apenas a escolha do LLM, pertence a uma questão de custo.

Atualizações de 2026 (em outubro de 2026)

As seções 6.1 to 6.3 ensinam um processo de decisão que sobrevive ao carrossel do catálogo; este subseção registra o que realmente virou entre o fim de 2025 e outubro de 2026, para que uma lista de modelos velha nunca se torne uma resposta errada. Cada linha abaixo foi verificada contra um post AWS What's New, uma página de documentação da AWS, a página de preços do Bedrock ou um blog da AWS: nada aqui vem de um rastreador de terceiros.

Mudanças de catálogo (verificadas):

Mudanças de capacidade (verificadas):

O que não mudou: cada mecanismo desta lição se comporta como escrito: a única API Converse e seus quatro parâmetros base, batch a 50% sem tool calling e sem saída estruturada, provisioned throughput cobrado por hora por model unit, a escada de tiers +75% / default / −50% / 1 ou 3 meses, perfis geográficos para residência contra perfis globais a ~10%, e os três modos de avaliação sobre um dataset em S3. O catálogo é a parte que se move; a mecânica é a parte sobre a qual você é avaliado.

📚 Você sabia? A política de ciclo de vida transforma o conselho desta lição de "não decore a lista de modelos" em uma regra de faturamento: porque um modelo Legacy recusa pedidos novos de Provisioned Throughput, uma equipe que prende a capacidade a um modelo no dia antes dele sair do Active pode ficar exatamente travada da seção de compromisso que a seção 4.5 diz que cargas de trabalho fine-tuned e de estado estável precisam: enquanto seus model units existentes continuam rodando. É por isso que uma opção de exame que nomeia um modelo específico como "disponível" ou "indisponível" é quase sempre um distrator, e por isso que as respostas duráveis são mecanismos: acesso padrão ativado, permissões de Marketplace no primeiro habilitamento, o formulário FTU da Anthropic, uma forma de pagamento válida.

---

7. Customization: quatro caminhos e a regra do provisioned throughput

Exemplo resolvido 8: custo do fine-tuning, o próprio exemplo de imagem da AWS. Amazon Titan Image Generator a $0.005 por imagem, 500 steps, batch size 64:

$$\$0.005 \times 500 \times 64 = \$160.00$$

mais $1.95/mês de armazenamento de modelo customizado e 1 hora de inferência customizada a $21.00 dá $182.95 no primeiro mês.

7.1 Prompt caching (Amazon Nova)

---

8. Avaliações: três modos, uma localização de dataset

8.1 Os três modos

Tipos de tarefa automáticos: Geração geral, Sumarização, Q&A, Classificação de texto. Modelos juiz disponíveis: Nova Pro / 2 Lite / Micro / Premier, Claude 3.5 Sonnet v1/v2, Claude Opus 4.7/4.8, Claude Sonnet 4.0/4.5, Llama 3.1 70B, Mistral Large.

LLM-as-a-judge chegou ao GA em 2025-03-20 e a AWS alega economia de custo de até 98% com turnaround em horas em vez de semanas. Ele também oferece bring-your-own-inference-response, então você pode pontuar saídas de modelos que nem estão hospedados no Bedrock.

8.2 Exemplo resolvido 9: qual avaliação, qual métrica

📚 Você sabia? O recurso bring-your-own-inference-response do LLM-as-a-judge silenciosamente torna o Bedrock Evaluations utilizável como uma camada de qualidade plataforma-fria: você submete respostas produzidas por qualquer modelo, inclusive rodando fora da AWS, e um juiz do Bedrock as pontua com uma explicação e um histograma de pontuação gravado em S3. É por isso que "a avaliação deve rodar no mesmo provedor que o modelo em teste" é um distrator: a AWS construiu explicitamente o oposto.

---

9. Veredito comparativo

---

10. Armadilhas do exame para esta lição

---

Casos Reais

As seções 1 to 10 constroem os mecanismos; as histórias de clientes publicadas pela AWS mostram a qual mecanismo uma equipe real de fato recorreu, e com quais números. Tudo abaixo é citado do estudo de caso da AWS ou do post do AWS Machine Learning Blog nomeado na coluna Fonte, recuperado em 6 de outubro de 2026. Todos esses números são alegações do cliente ou da AWS e não auditados, e onde uma fonte diz "até", leia-o como um teto, não como uma expectativa.

Os casos em uma olhada: serviços, números e fontes

Caso 1: Epilot: escolha o modelo com Bedrock Evaluations antes da produção. Software de energia de Colônia resume longas cadeias de e-mails de clientes para mais de 170 concessionárias. O pipeline é API → Amazon SQS → AWS Lambda → Amazon Bedrock (Claude Sonnet), e o modelo em si foi selecionado com Amazon Bedrock Evaluations (avaliações humanas entre versões de prompt) em vez de por preferência; um agente posterior grava registros com humanos verificando. Resultados: tempo de atendimento −87%, 55.000 resumos por mês com taxa de falha negligenciável, 80% dos usuários dizendo que simplifica o trabalho, um MVP em 2 meses, e dados processados mantidos em uma Região UE. Ângulo do exame: este são os modos de avaliação da seção 8 usados como um gate, e a questão de residência da seção 5 respondida de antemão em vez de depois do lançamento. Fonte: aws.amazon.com/solutions/case-studies/epilot-genai-case-study (indexado em julho de 2026).

Caso 2, Bynder: embeddings são um recurso de produto, não apenas uma linha de custo. A Bynder roda 175 milhões de ativos / 18 petabytes para 4.000 empresas, e a busca textual não consegue expressar "ache mais parecidos com este". Imagens e queries são vetorizadas com Amazon Titan Multimodal Embeddings no Bedrock para busca visual mais similaridade contextual. Resultados: tempo de busca −75% e cerca de +50% de resultados utilizáveis por busca. Ângulo do exame: a aritmética de embeddings da §6.3 é a mesma tabela de preços que torna o Titan Text Embeddings V2 5× mais barato que os embeddings da Cohere, e embeddings multimodais acrescentam um eixo de busca visual que um modelo de embedding só-texto não consegue precificar de modo algum. Fonte: aws.amazon.com/solutions/case-studies/bynder-bedrock-case-study (2025).

Caso 3, Nippon India: o ganho veio de engenharia de recuperação, não de um modelo maior. RAG ingênuo degradava conforme o volume de documentos crescia e produzia alucinações. O conjunto de correções: parse com FM-as-parser, reformulação de query, multi-query RAG, modelos reranker, GraphRAG e filtragem de metadados no Bedrock Knowledge Bases, mais Bedrock Guardrails e citações. Resultados: acurácia +>95%, alucinação −90 to 95%, geração de relatórios 2 dias → ~10 minutos. Ângulo do exame: a avaliação de RAG da §8 existe justamente para separar uma falha de recuperação de uma falha de geração, e a AWS observa que cada técnica acima é um recurso de produto GA, não código exclusivo de cliente. Fonte: AWS Machine Learning Blog, 29 jul 2025, aws.amazon.com/blogs/machine-learning/how-nippon-india-mutual-fund-improved-the-accuracy-of-ai-assistant-responses-using-advanced-rag-methods-on-amazon-bedrock.

Caso 4: Adobe: a escolha de chunking e embedding decide a acurácia do RAG. Milhares de desenvolvedores estavam recebendo resultados fracos de busca de documentação. A Adobe testou quatro estratégias de chunking no Bedrock Knowledge Bases: 400 tokens / 20% de sobreposição, 1.000 tokens, hierárquico e semântico: com Amazon Titan Text Embeddings V2 gravado no Amazon OpenSearch Service e lido através da Retrieve API. Resultado: +20% de acurácia de recuperação no próprio conjunto de testes da Adobe, com a estratégia mais simples (400 tokens / 20% de sobreposição) sendo a mais precisa. Ângulo do exame: uma questão de knowledge base que oferece "escolha um modelo maior" está respondendo o eixo errado; chunking, escolha de embedding e recuperação são os controles, e o benchmark roda no seu dataset. Fonte: AWS Machine Learning Blog, 11 jun 2025, aws.amazon.com/blogs/machine-learning/adobe-enhances-developer-productivity-using-amazon-bedrock-knowledge-bases.

Caso 5, Prime Focus Technologies: a latência decidiu o posicionamento antes do preço. O CLEAR mantém 14 milhões+ de ativos (Disney Star, CBS, Lionsgate) e cobre localização mais tagging ao vivo de cricket. Agentes Amazon Bedrock + AWS Lambda automatizaram os workflows; os resultados foram custo de localização −20 to 30%, acurácia +20 to 30% e turnaround −30 to 40%. O aviso documentado importa mais que os percentuais: a primeira tentativa usou APIs de LLM externas cuja latência era alta demais para tagging ao vivo, e a latência "caiu drasticamente" uma vez que a carga de trabalho rodou no Bedrock na AWS. Ângulo do exame: as questões de roteamento da §5 e a árvore de decisão da §6 começam ambas com quem está esperando, o posicionamento é resolvido antes de o preço ser comparado. Fonte: aws.amazon.com/solutions/case-studies/prime-focus-case-study (2025).

Caso 6: Alnylam: citações são o recurso de conformidade. A triagem de reclamações levava 3 to 4 dias e achar uma resposta interna levava 15+ minutos. Com Amazon Bedrock, Amazon S3 e uma camada de RAG, a equipe entregou um protótipo de intake-e-triagem em 3 meses sob restrições GxP, mais o assistente Slack AskALNY servindo 2.000 funcionários + 1.000 contratados que retorna respostas com links de origem. Resultados: triagem 3 to 4 dias → horas, busca 15 min → 30 s, e então 250+ casos de uso. Ângulo do exame: grounding mais citações é exatamente o objetivo 5.1.5 do guia de exame (detecção de alucinação e grounding), e uma resposta regulada sem link de origem não é uma resposta. Fonte: aws.amazon.com/solutions/case-studies/alnylam-case-study (2025).

Antes e depois, lado a lado

Reconstrua a arquitetura da Epilot e seus números publicados:

📚 Você sabia? A única taxa de prontidão para produção que a AWS publica é 65%: de mais de 1.000 implementações do Generative AI Innovation Center, 65% chegaram à produção em 2025, algumas em tão pouco quanto 45 dias, usando o framework Five V's (Value → Visualize → Validate → Verify → Venture). Esse número é o que fez a Epilot colocar a escolha do modelo atrás de um gate no Bedrock Evaluations, o que fez a Sun Finance rejeitar a tentativa 1 em vez de publicá-la, e o que faz cada caso acima citar um "antes" ao lado do "depois": os outros 35% é o que você evita fazendo baseline da métrica antes de construir.

---

Perguntas de Prática (Practice Questions)

---