🏠Início 📚Certificações 📱Aplicativos Móveis

🎓Informações do exame

✍️Blog 📊Progresso 📅Calendário 💬Suporte

Política de Privacidade Termos de Uso Fale Conosco Política de Cookies Aviso Legal Acessibilidade DMCA / Direitos Autorais

Pular para o conteúdo

AIP-C01Guia

Guia

AWS Certified Generative AI Developer - Professional

Última revisão: maio de 2026

Uma referência rápida dos padrões arquiteturais que o exame AIP-C01 avalia. Leia de cima a baixo ou pule para uma seção.

Seções

Integração de Modelo de Base, Gerenciamento de Dados e Conformidade31 entradas
Implementação e Integração33 entradas
Segurança, Proteção e Governança de IA24 entradas
Eficiência Operacional e Otimização13 entradas
Testes, Validação e Resolução de Problemas12 entradas

Integração de Modelo de Base, Gerenciamento de Dados e Conformidade

Escolha um modelo de base Bedrock para um caso de uso.

Raciocínio de contexto longo + uso de ferramentas → Claude (Sonnet/Opus). Chat otimizado para custo → Claude Haiku ou Titan Text Lite. Código → Claude ou Llama. Embeddings → Titan Embeddings V2 ou Cohere Embed. Geração de imagens → Titan Image, Stable Diffusion ou Nova Canvas. Pesos abertos com controle de auto-hospedagem → Llama, Mistral ou Importação de Modelo Personalizado.

Por quê: Nenhum modelo é o melhor em termos de custo, latência, capacidade e termos de licença. Correlacione a classe do modelo com o gargalo.

A fonte da KB consiste em FAQs curtas e autocontidas ou descrições de produtos (~100–500 palavras cada).

Fragmentação de tamanho fixo com tamanho de token padrão (300) e sobreposição (20%).

Por quê: Unidades autocontidas não se beneficiam da fragmentação com reconhecimento de limite. O tamanho fixo é o mais simples e barato.

Documentos têm mudanças naturais de tópico dentro dos parágrafos; divisões de tamanho fixo quebram frases no meio do pensamento.

Fragmentação semântica. Bases de Conhecimento do Bedrock agrupam frases consecutivas cujos embeddings são próximos, dividindo em limites de significado.

Por quê: Preserva ideias coerentes dentro de um fragmento → recuperação mais limpa, maior qualidade de resposta.

Manuais técnicos longos com referências cruzadas entre seções; perguntas exigem síntese em todo o documento.

Fragmentação hierárquica. O Bedrock constrói fragmentos pai (grandes) + filho (pequenos); recupera em embeddings de filho, retorna contexto de pai.

Por quê: Pequenos fragmentos fornecem recuperação precisa; o contexto pai preserva referências cruzadas e detalhes circundantes.

Os arquivos de origem já estão fragmentados ou cada arquivo é intencionalmente uma unidade lógica.

Nenhuma estratégia de fragmentação. Cada arquivo se torna um fragmento na KB.

A fonte PDF contém texto + diagramas; os usuários fazem perguntas que exigem a compreensão dos diagramas.

Ative a análise avançada da KB do Bedrock com um modelo de base (Claude/Nova) como analisador. Diagramas e tabelas são descritos via visão, depois incorporados.

Por quê: A análise padrão é apenas texto. A análise multimodal converte conteúdo visual em texto descritivo antes da incorporação.

Escolha Titan Embeddings G1 vs V2.

A V2 suporta dimensões configuráveis (256/512/1024) e supera a G1 em benchmarks multilíngues. A G1 é fixa em 1536. Escolha a V2 para casos de uso com restrição de armazenamento ou não-ingleses; a G1 apenas para compatibilidade legada.

Catálogo de produtos de 500K: títulos curtos (50 palavras) + especificações longas (500 palavras). Otimize a qualidade e o custo da pesquisa.

Incorpore cada item uma vez (campos combinados ou separados). Use Titan Embeddings V2 com dimensões reduzidas (256 ou 512) para custo; incorpore consulta e documento com o mesmo modelo.

Por quê: A mistura de modelos de embedding ou a omissão da normalização quebra a pesquisa de similaridade. Dimensões menores reduzem o custo de armazenamento e consulta com perda marginal de qualidade.

Escolha um armazenamento vetorial para Bases de Conhecimento do Bedrock.

Configuração padrão / mais rápida → Amazon OpenSearch Serverless (gerenciamento automático). Sub-ms com atualizações frequentes de esquema + junções relacionais → Aurora PostgreSQL com pgvector. Cliente Pinecone / MongoDB Atlas / Redis existente → mantenha-o. KB pequena (<10K documentos) otimizada para custo → Aurora pgvector ou Neptune Analytics.

Por quê: OpenSearch Serverless é o padrão mais fácil. Aurora pgvector ganha quando você precisa de transações ou junções em metadados.

A KB retorna documentos semanticamente relevantes, mas são de versões desatualizadas/regiões erradas.

Adicione metadados aos arquivos de origem (`version`, `region`, `effective_date`) e aplique filtros de metadados no momento da consulta via `retrievalConfiguration.vectorSearchConfiguration.filter`.

Por quê: A similaridade vetorial pura ignora a atualidade e a autoridade. A filtragem de metadados restringe o conjunto de candidatos antes da classificação.

O RAG perde consultas que contêm identificadores exatos (SKUs, códigos de erro, números de regulamentação) porque a pesquisa semântica sobrevaloriza o texto de significado semelhante.

Ative a pesquisa híbrida na KB (semântica + palavra-chave/BM25). Combina similaridade vetorial com correspondência lexical para IDs, códigos e nomes próprios.

Top-k=5 recupera 5 fragmentos, mas o mais relevante é frequentemente classificado em 3º ou 4º lugar.

Aumente `numberOfResults` para 20 e, em seguida, ative um modelo de reranking (Cohere Rerank ou Amazon Rerank) para reordenar por relevância para a consulta original.

Por quê: Similaridade de embedding ≠ relevância da tarefa. Rerankers de cross-encoder veem consulta + fragmento juntos e pontuam precisamente.

As perguntas do usuário são conversacionais, multiparte ou contêm pronomes/continuações; a qualidade da recuperação da KB diminui.

Ative a reformulação de consultas da KB do Bedrock. O modelo reescreve consultas complexas em várias subconsultas focadas antes da recuperação.

Documentos de origem S3 são atualizados frequentemente; a KB deve sempre refletir as versões mais recentes sem sincronização manual.

Configure a fonte de dados da KB para sincronização automatizada via notificações de eventos S3 → EventBridge → StartIngestionJob, ou use a sincronização agendada da KB. Evite depender do botão manual "Sincronizar" do console.

O modelo de QA de documentos longos alucina em perguntas cujas respostas estão no meio do documento.

Não passe documentos completos no prompt — fragmente + recupere via RAG para que apenas os fragmentos relevantes cheguem ao modelo. Se o documento completo for obrigatório, use um modelo com forte recall de contexto longo (Claude Sonnet 200K) e coloque a pergunta após o documento.

Por quê: A maioria dos LLMs exibe degradação de recall "perdido no meio". O RAG evita isso; o posicionamento ajuda quando o RAG não está disponível.

Escolha a personalização mais barata que atenda ao padrão de qualidade.

Tente na ordem: (1) engenharia de prompt, (2) RAG com KB, (3) fine-tuning, (4) pré-treinamento contínuo, (5) Importação de Modelo Personalizado. Pare no primeiro que atender ao padrão.

Por quê: O esforço e o custo contínuo aumentam a cada etapa. Fine-tuning + Provisioned Throughput é muito mais caro que RAG.

Ajuste um modelo Bedrock com exemplos de tarefas rotulados.

Arquivo JSONL no S3 com um exemplo por linha: `{"prompt": "...", "completion": "..."}` (ou equivalente em formato de chat para a família de modelos).

Por quê: Cada família de modelos (Titan, Claude, Llama) tem um esquema específico; verifique a documentação de fine-tuning do modelo antes de formatar.

Adapte um modelo de base a um vocabulário especializado (jurídico, médico, científico) usando muitos textos de domínio não rotulados.

Pré-treinamento contínuo no corpus de domínio não rotulado. Diferente do fine-tuning de instruções (que precisa de pares prompt-completion).

Por quê: O pré-treinamento contínuo atualiza a compreensão da linguagem; o fine-tuning de instruções ensina o comportamento da tarefa. Formato de dados diferente, objetivo diferente.

Os dados de interação do cliente para fine-tuning contêm nomes, e-mails, números de telefone.

Limpe ou tokenize PII antes de fazer upload do conjunto de dados de treinamento para o S3. Uma vez que os pesos absorvem PII, a filtragem de saída não pode mascará-lo de forma confiável.

Por quê: O modelo ajustado pode regurgitar fragmentos de dados de treinamento. A limpeza na camada de dados é a única mitigação duradoura.

Traga um modelo Llama ou Mistral auto-ajustado e sirva-o através da API unificada do Bedrock.

Importação de Modelo Personalizado. Faça upload dos pesos para o S3, registre com o Bedrock, invoque via tempo de execução do Bedrock com IAM e registro unificados.

Por quê: Permite reutilizar Guardrails, KBs e Agentes do Bedrock em pesos próprios sem levantar endpoints SageMaker.

Sirva um modelo Bedrock ajustado em produção.

Compre o Provisioned Throughput. Modelos personalizados (ajustados, pré-treinados continuamente, importados) não podem ser invocados sob demanda.

Aplicativo Claude de alto tráfego atinge cotas por região durante os picos; precisa de maior throughput sem comprar Provisioned Throughput.

Perfis de inferência entre regiões. O Bedrock roteia invocações entre várias regiões de forma transparente para aumentar as cotas efetivas de TPM/RPM.

Por quê: As cotas sob demanda de região única são limitadas durante picos; os perfis entre regiões multiplicam aproximadamente as cotas sem alterações no código do aplicativo, além de usar o ARN do perfil de inferência.

Usuários da APAC veem latência significativamente maior do que usuários dos EUA/UE em um aplicativo Bedrock implantado em us-east-1.

Implante endpoints regionais do Bedrock em ap-northeast-1 / ap-southeast-1 / ap-south-1 (onde o modelo está GA). Roteie usuários via política de latência ou geolocalização do Route 53.

Por quê: O round-trip do LLM domina para contextos longos; o RTT trans-Pacífico sozinho é de 150–250 ms.

Aplicativo regulamentado pelo HIPAA precisa resumir PHI com o Bedrock.

Use apenas modelos de base elegíveis para HIPAA (conforme a lista de Serviços Elegíveis para HIPAA). Assine um BAA com a AWS. Criptografe prompts/respostas com chaves KMS gerenciadas pelo cliente. Desative o registro de invocação de modelo ou restrinja-o a um bucket S3 privado com acesso restrito.

Decidir quais dados podem fluir para o Bedrock com base na sensibilidade (público / confidencial / restrito).

Público → irrestrito. Confidencial → somente via endpoints VPC + CMK + registro de invocação em buckets privados. Restrito (segredos comerciais, PHI/PCI regulamentados) → bloqueie completamente do Bedrock ou use regime de conformidade elegível para Bedrock + redija antes de invocar.

Organização multi-conta deseja que a Conta A compartilhe um modelo Bedrock personalizado com a Conta B sem copiar os pesos.

Compartilhamento de modelo personalizado via AWS RAM. O proprietário compartilha o ARN do modelo personalizado; as contas consumidoras o invocam através do tempo de execução padrão do Bedrock com entidades IAM entre contas na política de recursos.

Por quê: Evita custos de fine-tuning redundantes e centraliza o ciclo de vida do modelo. O RAM controla quem pode consumir o recurso compartilhado.

Precisa de um modelo de terceiros de nicho (por exemplo, LLM especializado em saúde) que não está no catálogo padrão do Bedrock.

Amazon Bedrock Marketplace. Assine o modelo no catálogo do Marketplace, implante em um endpoint do Bedrock, invoque via API de tempo de execução padrão.

Por quê: Unifica faturamento de terceiros, IAM, KMS e observabilidade com modelos Bedrock próprios.

Aplicativo de pesquisa de alto volume re-incorpora os mesmos documentos a cada atualização de consulta; o custo de embedding domina.

Pré-calcule embeddings na ingestão de documentos, armazene o vetor no DynamoDB ou OpenSearch indexado por id do documento + hash de conteúdo. Re-incorpore apenas quando o hash de conteúdo mudar.

Por quê: Incorporar o mesmo texto repetidamente é o custo evitável mais comum. O cache com hash é um salto O(1).

Direito ao esquecimento do GDPR em um modelo ajustado: o usuário solicita a exclusão de seus PII dos dados de treinamento.

Exclua registros do corpus de treinamento, então ajuste um novo modelo base do zero. Não é possível limpar dados de pesos existentes de forma confiável — a filtragem de saída não é suficiente.

Por quê: Uma vez que os pesos absorvem os dados de treinamento, o mascaramento na inferência não é confiável. O caminho defensável é o retreinamento completo sem os registros afetados.

KB compartilhada atende a várias equipes; cada equipe deve ver apenas seus próprios documentos.

Marque cada fragmento com metadados `tenant_id` / `team_id` / `clearance` na ingestão. No momento da consulta, defina `retrievalConfiguration.vectorSearchConfiguration.filter` para os valores permitidos do chamador da sessão IAM ou contexto do aplicativo.

Por quê: A similaridade vetorial ignora o controle de acesso; a filtragem de metadados é a única isolamento durável por locatário em uma KB compartilhada.

Cliente da UE exige que prompts e embeddings da KB nunca saiam de eu-west-1.

Implante Bedrock + KB + bucket de origem S3 em eu-west-1. Fixe invocações via ARN de perfil de inferência com escopo para eu-west-1; SCP `aws:RequestedRegion` negando outras regiões para `bedrock:*`.

Implementação e Integração

Fluxo de trabalho de várias etapas que precisa de raciocínio de LLM, chamadas para APIs/bancos de dados externos e síntese.

Amazon Bedrock Agent. Defina instruções, grupos de ação (Lambda + esquema OpenAPI) e uma KB opcional. O agente planeja, invoca ferramentas e une os resultados.

Por quê: Evita a necessidade de escrever o loop de orquestração você mesmo. Possui rastreamento integrado, memória de sessão e ganchos de retorno de controle.

O Bedrock Agent deve chamar três APIs internas (CRM, inventário, pagamentos).

Defina um grupo de ações por API. Cada grupo de ações tem um esquema OpenAPI descrevendo suas operações e uma função Lambda (ou endpoint de retorno de controle) que executa as chamadas.

O Agente deve realizar operações de alto risco (exclusão de conta, grandes reembolsos) somente após confirmação humana/comercial.

Configure o grupo de ações com Retorno de Controle (RoC). O Bedrock retorna a ação proposta ao aplicativo em vez de invocá-la; o aplicativo controla a execução por trás da aprovação e reenvia os resultados.

Por quê: Mantém as etapas de alto risco fora do tempo de execução do agente para que possam ser auditadas ou confirmadas por humanos antes de serem executadas.

O Agente deve lembrar o contexto em várias interações dentro de uma sessão de usuário.

Use os atributos de sessão e os atributos de sessão de prompt integrados do agente. Passe `sessionId` para InvokeAgent — o Bedrock retém o estado da conversa para o tempo limite de inatividade configurado.

O Agente deve lembrar fatos sobre um usuário que retorna entre sessões (preferências, histórico) e resumir trocas mais antigas.

Ative a memória do Agente Bedrock. O agente persiste o histórico de sessão resumido por `memoryId` e o reproduz como contexto em invocações futuras.

O fluxo de trabalho precisa de agentes especializados (pesquisa, código, faturamento) coordenados por um planejador de alto nível.

Colaboração multi-agente do Bedrock Agents: defina um agente supervisor e vários agentes colaboradores. O supervisor delega subtarefas com base nas descrições dos colaboradores e sintetiza os resultados.

Precisa de um pipeline de várias etapas: extrair → classificar → rotear → resumir, com ramificações condicionais.

Amazon Bedrock Prompt Flows. Fluxo de trabalho visual com nós de prompt, nós de condição, nós de KB, nós de Lambda; versionado e invocável como uma única API.

Por quê: Substitui as Step Functions manuais para pipelines de prompt e expõe um único ponto de entrada.

SaaS multi-locatário: prompts de sistema por locatário, preferências de modelo e versionamento.

Gerenciamento de Prompt do Amazon Bedrock. Armazene prompts como ativos versionados e parametrizados; referencie por ARN em tempo de execução; A/B diferentes versões por locatário.

O aplicativo deve funcionar com Claude, Llama, Titan e Cohere com uma única superfície de API estilo chat.

Use a API Converse do Bedrock. Formato de lista de mensagens unificado, uso de ferramentas e prompts de sistema em todas as famílias de modelos. Evite o JSON de InvokeModel específico do modelo quando a portabilidade for importante.

O Chatbot deve exibir as respostas token por token para reduzir a latência percebida.

ConverseStream (ou InvokeModelWithResponseStream). Emparelhe com API Gateway WebSocket ou assinaturas AppSync para distribuir tokens ao navegador.

Chat de suporte ao cliente em tempo real: streaming de resposta, 500 usuários concorrentes, histórico de conversas.

Navegador ↔ API Gateway WebSocket ↔ Lambda ↔ Bedrock ConverseStream. Persista a conversa no DynamoDB indexada por `sessionId` e recarregue a cada turno.

Por quê: WebSocket evita polling HTTP; o armazenamento de sessão do DynamoDB sobrevive à natureza sem estado do Lambda.

Precisa que o modelo decida quando chamar funções (consulta de banco de dados, calculadora, API).

Use o uso de ferramentas da API Converse (`toolConfig`) — declare ferramentas com nome + esquema JSON; o modelo emite blocos `toolUse`; o aplicativo executa e retorna `toolResult`. Funciona com Claude, Llama, Mistral, Cohere Command R.

Novo ticket em sistema de terceiros → análise automática do Bedrock (sentimento, urgência, categoria) → roteamento.

Webhook → API Gateway → EventBridge → destino Lambda → Bedrock. O EventBridge desacopla produtores de consumidores e fornece retentativas + DLQ gratuitamente.

Vários microsserviços enviam solicitações de geração do Bedrock; os consumidores não precisam de resultados imediatamente.

Produtores → SQS → Lambda (ou ECS) consumidor → Bedrock InvokeModel → armazene o resultado em S3/DynamoDB. O SQS suaviza picos e retenta falhas dentro das cotas de serviço.

Gerar descrições para 100.000 SKUs diariamente; tolerante à latência; deseja o menor custo.

Amazon Bedrock Batch Inference. Envie o JSONL de entrada no S3, o Bedrock executa o trabalho com custo por token até 50% menor em comparação com sob demanda, escreve o JSONL de saída.

Por quê: O processamento em lote troca latência por custo. Use-o sempre que os resultados não forem necessários em tempo real.

API Gateway na frente de Lambda + Bedrock retorna 504 Gateway Timeout em gerações longas.

O tempo limite de integração REST do API Gateway é limitado a 29 segundos. Mude para o padrão assíncrono (retorne o ID do trabalho, consulte via segundo endpoint) ou para API Gateway WebSocket + ConverseStream para que tokens parciais fluam antes da janela de tempo limite.

Gerar descrições de produtos a partir de uma imagem de produto + texto breve.

Use um modelo com capacidade de visão no Bedrock (Claude 3+ Sonnet, Nova) via API Converse com blocos de conteúdo `image` ao lado do texto.

Tradução de mensagens em sub-segundos para o inglês com alta qualidade.

Modelo de base (Claude Haiku ou Llama pequeno) via Bedrock para nuance, OU Amazon Translate para velocidade/custo quando a tradução literal é suficiente. Bedrock para contexto-aware; Translate para transacional.

Mudar gradualmente o tráfego de produção do Modelo A para o Modelo B com capacidade de interrupção.

Sinalizador de recurso do AWS AppConfig contendo o identificador do modelo ativo e a divisão de tráfego. Lambda lê o sinalizador por invocação, roteia de acordo. Reversão instantânea via rollback de implantação do AppConfig.

Decidir entre Bedrock e SageMaker JumpStart para hospedar um modelo de base.

Bedrock quando você deseja inferência gerenciada, API unificada, KB/Agents/Guardrails. SageMaker JumpStart quando você precisa de um endpoint hospedado em VPC privada com controle total de rede/IAM ou modelo de pesos abertos não disponível no Bedrock.

Escolha o estilo de definição do grupo de ações: especificação OpenAPI 3.0 vs esquema de função.

OpenAPI quando a API subjacente já possui uma especificação OpenAPI 3.0 ou você precisa de semântica HTTP completa (caminhos, métodos, tipos de parâmetros). Esquema de função para ações inline/leves definidas via declarações de propriedades JSON simples.

Por quê: OpenAPI é canônico para APIs REST existentes. O esquema de função é mais rápido para novos auxiliares internos do agente.

O Agente deve realizar cálculos precisos, análises estatísticas ou executar pequenos trechos de Python para responder a perguntas.

Ative o interpretador de código dos Bedrock Agents. O agente executa Python em um sandbox gerenciado; os resultados fluem de volta para a síntese da resposta.

Por quê: LLMs são pouco confiáveis em matemática exata; um tempo de execução em sandbox fornece resultados numéricos determinísticos sem escrever grupos de ações personalizados.

Os prompts padrão do agente produzem respostas prolixas; é preciso otimizar o prompt de orquestração para produção.

Configure substituições de modelo de prompt no agente para cada etapa (pré-processamento, orquestração, geração de resposta da KB, pós-processamento). As substituições são versionadas com o agente.

Iterar em um agente em desenvolvimento enquanto o tráfego de produção permanece em uma versão estável.

Use versões e aliases do agente. `DRAFT` para edições ativas; publique versões numeradas; roteie via aliases (`prod` → versão 7, `dev` → DRAFT). Promova atualizando o alias.

O Agente seleciona o grupo de ações errado; é necessário depurar o raciocínio passo a passo.

Ative o rastreamento em InvokeAgent (`enableTrace: true`). O fluxo de resposta inclui blocos `preProcessingTrace`, `orchestrationTrace`, `postProcessingTrace` e `failureTrace` mostrando a lógica do modelo, a seleção de ferramentas e as entradas.

Construir um Bedrock Flow para "extrair entidades → consultar KB → resumir → e-mail".

Componha nós: nó de prompt (extrair), nó de base de conhecimento (consultar), nó de prompt (resumir), nó de Lambda (enviar e-mail via SES). Use nós de entrada/saída S3 para fluxos em lote; nós de condição para ramificação.

Escolha Bedrock Flows vs Step Functions para um pipeline GenAI de várias etapas.

Bedrock Flows quando as etapas são principalmente primitivos do Bedrock (prompts, KBs, agentes) — invocação de API única, sem cola IAM extra. Step Functions quando o fluxo de trabalho abrange muitos serviços AWS com retentativas, ramificações paralelas, tratamento complexo de erros ou esperas de longa duração.

Implementar um loop de chat onde o modelo chama ferramentas iterativamente e depois formula a resposta final.

Padrão: enviar mensagem do usuário → modelo retorna `toolUse` → aplicativo executa ferramenta → aplicativo envia `toolResult` de volta via Converse → loop até que o modelo retorne o texto final. Limite as iterações para evitar execuções descontroladas.

Por quê: O modelo decide quando tem informações suficientes para parar; o aplicativo deve conduzir o loop e impor um limite máximo de etapas.

O modelo precisa consultar cliente + pedido + inventário; chamadas de ferramenta sequenciais adicionam 3× latência.

Modelos que suportam o uso paralelo de ferramentas (Claude 3+, Nova) emitem múltiplos blocos `toolUse` em uma única vez. Execute-os concorrentemente no aplicativo e retorne todos os `toolResult`s antes da próxima inferência.

Persistir o estado do chat multi-turno em invocações Lambda sem estado com limpeza automática de sessões obsoletas.

Tabela DynamoDB indexada por `sessionId` armazenando `messages` + `lastActivity`. Defina o atributo TTL (`expiresAt`) para excluir automaticamente sessões com mais de 24 horas. Lambda lê/escreve a cada turno.

O chat tem ~1000 QPS; as leituras do DynamoDB por turno no histórico de sessão são um gargalo.

Coloque o ElastiCache para Redis na frente do DynamoDB. Armazene em cache as últimas N mensagens por sessão em um hash Redis; escreva no DynamoDB para durabilidade. Defina chaves TTL do Redis para limitar a memória.

Uma nova tentativa em uma chamada InvokeModel do Bedrock corre o risco de faturar duas vezes pela mesma solicitação lógica.

Gere uma chave de idempotência por solicitação lógica (por exemplo, UUID v5 de entrada + usuário). Armazene em cache a resposta indexada pela chave de idempotência no DynamoDB ou ElastiCache; retorne a resposta em cache na nova tentativa.

Por quê: O próprio Bedrock não é idempotente — a mesma entrada é faturada a cada chamada. O cache na camada do aplicativo é a única história de idempotência.

Execute duas versões de modelo de produção durante a migração sem mudar todos os usuários de uma vez.

Divida o ID do usuário em N buckets; roteie o bucket i para o modelo A ou modelo B com base em um sinalizador de recurso (AppConfig / Parameter Store). Monitore métricas lado a lado; mude a atribuição de bucket para avançar ou retroceder.

Segurança, Proteção e Governança de IA

Chatbot voltado para o cliente deve bloquear conteúdo prejudicial, tópicos negados, vazamento de PII.

Amazon Bedrock Guardrails. Configure tópicos negados, filtros de conteúdo (ódio, violência, sexual, insultos, má conduta), filtros de palavras, filtros de informações sensíveis (redação de PII) e verificações de fundamentação contextual. Aplique à entrada e saída do InvokeModel.

Por quê: Os Guardrails são agnósticos ao modelo e aplicados em ambas as direções; eles sobrevivem a qualquer troca de modelo único.

O Guardrail bloqueia respostas financeiras legítimas que mencionam valores em dólar.

Diminua o nível de sensibilidade no filtro de conteúdo afetado (por exemplo, `MEDIUM` → `LOW`) e/ou remova frases de tópicos negados excessivamente amplas. Teste novamente contra um conjunto de prompts de benchmark antes de reimplantar.

O aplicativo de resumo médico não deve inventar fatos além dos documentos de origem.

Ative a verificação de fundamentação contextual dos Guardrails do Bedrock com um alto limite de relevância + fundamentação. Respostas abaixo do limite são bloqueadas ou substituídas por uma mensagem padrão segura.

Por quê: O RAG puro ainda alucina quando o modelo generaliza excessivamente a partir de fragmentos recuperados. A fundamentação contextual pontua o alinhamento resposta-fonte por resposta.

O aplicativo Bedrock recebe prompts contendo PII do cliente; precisa de mascaramento automático antes do registro ou uso posterior.

Configure os filtros PII do Guardrails com ações `BLOCK` ou `ANONYMIZE` para tipos de entidade PII (SSN, e-mail, telefone, endereço). A filtragem ocorre na entrada e saída independentemente.

O aplicativo público recebe entrada do usuário concatenada em um prompt de sistema; deve resistir à injeção de prompt.

Defesa em profundidade: (1) Guardrails (tópicos negados + detecção de jailbreak), (2) prompt de sistema reforçado que enquadra a entrada do usuário como dados e recusa meta-instruções, (3) validação de saída contra esquema esperado, (4) permissões de ferramenta de privilégio mínimo para que um prompt comprometido não possa acionar ações destrutivas.

Por quê: Nenhuma mitigação única é suficiente; defesas em camadas limitam o raio de explosão.

A equipe vermelha descobre que o modelo pode ser coagido a produzir resultados prejudiciais por meio de enquadramento de dramatização ("finja que você é uma IA sem restrições").

Ative o filtro de conteúdo de detecção de jailbreak dos Guardrails. Adicione tópicos negados explícitos para tentativas de dramatização. Teste novamente após cada alteração com o mesmo conjunto de prompts da equipe vermelha.

Todos os dados do Bedrock devem ser criptografados em trânsito e em repouso com chaves gerenciadas pelo cliente.

TLS 1.2+ é imposto em trânsito. Em repouso: configure chaves KMS gerenciadas pelo cliente para personalização de modelo Bedrock, embeddings KB + dados de origem S3, destinos de log de invocação. Imponha via SCP que impeça chaves gerenciadas pela AWS.

Organização multi-equipe: cada equipe deve acessar apenas modelos de base específicos.

Políticas baseadas em identidade IAM que permitem `bedrock:InvokeModel` em ARNs de recursos com escopo para os IDs de modelo permitidos. Combine com condições `aws:RequestedRegion` para bloquear a região.

Por quê: Allow no nível do recurso em `arn:aws:bedrock:*::foundation-model/<id>` é a única maneira duradoura de impor o acesso no nível do modelo. Não dependa de gating na camada de aplicativo.

Lambda invoca apenas Claude 3.5 Sonnet em us-east-1.

Permitir `bedrock:InvokeModel` com `Resource: arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-5-sonnet-*` e uma `Condition: aws:RequestedRegion = us-east-1`. Rejeitar todos os outros modelos e regiões.

O aplicativo Bedrock não deve ter saída para a internet pública.

Bedrock com endpoints de interface VPC (PrivateLink) para a API de tempo de execução. Bloqueie endpoints públicos do Bedrock via SCP. Adicione uma política de endpoint que limita as ações ao conjunto aprovado.

O regulador exige um registro de auditoria completo de cada invocação de modelo Bedrock: prompt, resposta, versão do modelo, carimbo de data/hora.

Ative o registro de invocação de modelo Bedrock para o CloudWatch Logs ou S3. Captura prompt completo + resposta + ID do modelo + carimbo de data/hora. Emparelhe com o CloudTrail para a camada de metadados de chamada de API (quem/quando/de onde).

Por quê: O CloudTrail captura apenas metadados; o registro de invocação captura conteúdo. A conformidade geralmente exige ambos.

Determinar a parcela de responsabilidade de segurança da empresa para uma implantação do Bedrock.

Matriz de Escopo de Segurança de IA Generativa da AWS. Escopo 1 (SaaS de consumidor) → Escopo 5 (modelo auto-treinado em dados privados). O Bedrock com modelos de base sob demanda é tipicamente Escopo 2; KB/Agente + RAG empurra para o Escopo 3; fine-tuning Escopo 4; Importação de Modelo Personalizado Escopo 5.

Proteja o endpoint da API GenAI atrás do API Gateway contra abusos.

AWS WAF com regras baseadas em taxa (por IP), conjunto de regras gerenciadas de controle de bot e uma regra personalizada de correspondência de strings em frases suspeitas de jailbreak. Bloqueie padrões comuns de DDoS de LLM (inundações de prompts longos).

Encontre PII ou outros dados sensíveis em corpora de origem S3 antes que entrem em uma KB ou trabalho de fine-tuning.

Trabalho de descoberta agendado do Amazon Macie nos buckets S3 relevantes. Os resultados vão para o Security Hub / EventBridge para redação de acompanhamento.

Detectar imagens geradas por IA downstream para proveniência de conteúdo.

Use o Titan Image Generator (ou Nova Canvas) — as saídas incluem uma marca d'água invisível. Verifique com a API de detecção de marca d'água do Bedrock.

O chatbot de marketing não deve nomear concorrentes e não deve fazer afirmações infundadas.

Tópicos negados dos Guardrails: lista explícita de nomes de concorrentes + "alegações de produtos não verificadas" em nível de tópico. Adicione um filtro de palavras para afirmações absolutas ("garantido", "melhor", "100%").

Aplicar um Guardrail do Bedrock a saídas de um modelo não-Bedrock (por exemplo, endpoint SageMaker auto-hospedado).

Chame a API `ApplyGuardrail` autônoma com o texto + id do guardrail + versão. Retorna se o conteúdo foi bloqueado ou modificado, com quais filtros foram acionados.

Por quê: Desacopla os guardrails do modelo. Use como uma pré-verificação na entrada do usuário ou pós-verificação em qualquer saída do modelo.

Uma única política de Guardrail deve ser aplicada em us-east-1, eu-west-1 e ap-southeast-1.

Recrie o mesmo guardrail (mesma configuração) em cada região. Os Guardrails são recursos regionais; use IaC (CloudFormation / CDK / Terraform) para manter as configurações sincronizadas.

Por quê: Não há replicação entre regiões gerenciada para guardrails. IaC é a única história de consistência duradoura.

Um invasor envenena documentos em uma KB pública para que o agente vaze o prompt do sistema ou dados ao recuperá-los.

Trate o conteúdo da KB recuperado como não confiável: ative os Guardrails nas entradas E saídas, sanitize os fragmentos recuperados via detecção de injeção de prompt ou correspondência de padrões, imponha o menor privilégio nos grupos de ações do agente para que um prompt comprometido não possa escalar.

Por quê: A injeção indireta ignora a filtragem de entrada — o prompt malicioso chega via contexto recuperado, não a mensagem do usuário.

Precisa de acesso ao modelo por usuário em um aplicativo multi-locatário com uma única função de backend.

Passe atributos de usuário como tags de sessão durante AssumeRole. Referencie-os via condições `aws:PrincipalTag/<key>` na política de identidade do Bedrock para controlar `bedrock:InvokeModel` por usuário.

Escolha o destino para o registro de invocação do Bedrock.

CloudWatch Logs para prompts/respostas curtas, consultas rápidas do Logs Insights, aplicativos de menor escala. S3 para alto volume, grandes payloads (rastreamentos de KB + agente), retenção de longo prazo, análise downstream Athena/Glue. Use S3 se qualquer resposta única puder exceder 256 KB.

Por quê: O CloudWatch Logs tem limites de tamanho por evento; o S3 não tem. Escolha pelo tamanho do payload e padrão de análise.

Proteger uma API de chat pública contra DDoS e abuso de token-flood em larga escala.

O AWS Shield Standard está ativado por padrão; ative o Shield Advanced em endpoints críticos para proteções L7 + suporte SRT 24/7. Combine com regras baseadas em taxa do WAF e CloudFront para absorção na borda.

O aplicativo de geração de imagens deve bloquear imagens sexualmente explícitas, violentas ou de ódio.

Filtros de conteúdo de imagem dos Guardrails do Bedrock na entrada (imagens carregadas) e saída (imagens geradas). Os filtros classificam o conteúdo visual com limiares ALTO/MÉDIO/BAIXO.

Fluxo de trabalho antes do ajuste fino de um modelo Bedrock em transcrições de suporte ao cliente.

Pipeline: S3 origem → trabalho de descoberta Macie para identificar PII → detecção + redação de PII do Comprehend (ou Glue com regex) → conjunto de dados limpo para um prefixo S3 separado → ajuste fino do Bedrock. Falhas do Macie acionam EventBridge → SNS para segurança de plantão.

Por quê: Uma vez que os dados entram nos pesos, a remoção requer retreinamento. A redação pré-voo é muito mais barata do que o retreinamento pós-incidente.

Eficiência Operacional e Otimização

Escolha entre on-demand e Provisioned Throughput.

Tráfego variável / desconhecido → on-demand. Alto volume constante com SLA de throughput garantido → Provisioned Throughput (unidades de modelo, compromisso de 1 ou 6 meses). Modelos personalizados (ajustados, importados) → Provisioned Throughput é obrigatório.

Por quê: On-demand é por token, sem compromisso. PT é por hora, capacidade dedicada, ~50% mais barato por token em alta utilização.

O aplicativo reutiliza o mesmo prompt de sistema de 4.000 tokens em todas as interações do usuário; apenas a mensagem do usuário muda.

Ative o cache de prompt do Bedrock. Marque o prefixo estático como cacheável; invocações subsequentes pulam o reprocessamento por ~5 minutos de TTL do cache, reduzindo o custo por chamada em ~90% nos tokens em cache.

Muitos usuários fazem perguntas semelhantes, mas não idênticas; deseja-se armazenar em cache as respostas em paráfrases.

Incorpore a consulta do usuário e procure vizinhos mais próximos em um cache vetorial (DynamoDB + ElastiCache ou OpenSearch) acima de um limite de similaridade. Acerto no cache → retorne a resposta armazenada. Falha no cache → invoque Bedrock e escreva de volta.

Por quê: Caches padrão de chave-valor perdem paráfrases. A similaridade semântica captura a intenção.

Reduza o custo por chamada em um aplicativo Bedrock.

Aperte o prompt do sistema, descarte exemplos redundantes de few-shot, defina `maxTokens` explícitos na saída, use sequências de parada para encerrar cedo. Escolha um modelo menor onde a qualidade permitir.

Por quê: O custo é aproximadamente proporcional ao total de tokens processados. Os tokens de saída são tipicamente precificados mais alto do que os tokens de entrada — limitar a saída tem alto impacto.

Conclusão de código: latência sub-segundo, custo equilibrado, alto volume de solicitações.

Claude Haiku (ou Nova Micro / Llama pequeno) no Bedrock. Evite Opus ou Llama grande para caminhos de conclusão de token sensíveis à latência.

A KB tem 500K documentos, mas apenas ~200 consultas/dia; minimize o custo.

Aurora PostgreSQL Serverless v2 com pgvector. Escala para ACUs próximas de zero em inatividade; o modelo de pagamento por consulta supera os pisos OCU do OpenSearch Serverless sempre ativo em baixas QPS.

A KB do OpenSearch Serverless tem latência de consulta de 800ms; precisa de <200ms.

Aumente o piso OCU na coleção de pesquisa (mais computação = mais vetores em cache). Reduza a dimensão do embedding, aumente o top-k estritamente, corte metadados, ative o cache de resultados na camada de aplicativo.

Trabalhos de ajuste fino de longa duração que toleram interrupção; minimize o custo.

Para ajuste fino do SageMaker, use o Managed Spot Training (até 90% de desconto). O ajuste fino nativo do Bedrock é apenas sob demanda — escolha o SageMaker JumpStart para treinamento personalizado elegível para spot quando o orçamento dominar.

Aloque os gastos do Bedrock entre equipes ou linhas de produtos.

Aplique tags de alocação de custos aos recursos do Bedrock (Provisioned Throughput, modelos personalizados, pilhas de aplicativos). Ative as tags em Faturamento → Tags de Alocação de Custos. Os relatórios detalham por tag.

Monitore a latência de invocação do Bedrock, o volume de tokens e os erros.

Métricas do CloudWatch em `AWS/Bedrock`: `InvocationLatency`, `InputTokenCount`, `OutputTokenCount`, `Invocations`, `InvocationClientErrors`, `InvocationServerErrors`, `InvocationThrottles`. Defina alarmes na latência p95 e nas taxas de erro.

~100 conversas/dia, FAQ simples; minimize o custo.

Bedrock sob demanda com o menor modelo competente (Titan Text Lite, Claude Haiku ou Nova Micro). Lambda + API Gateway HTTP API. Sem KB se o FAQ couber no prompt do sistema; pequena KB no Aurora pgvector se necessário.

Dimensionar o Provisioned Throughput para uma carga de trabalho Bedrock em estado estável.

Meça o pico de tokens de entrada + saída por segundo no tráfego sombra. O Bedrock publica o throughput por unidade de modelo; provisione `ceil(pico de TPS / TPS por unidade)` unidades. Valide com tráfego sombra antes de se comprometer.

Por quê: O subprovisionamento causa throttling; o superprovisionamento desperdiça o compromisso horário. O dimensionamento empírico no tráfego sombra é a única abordagem confiável.

Alocar custo do Bedrock por aplicativo ou equipe em uma conta compartilhada.

Crie perfis de inferência de aplicativo por aplicativo, anexe tags de alocação de custo (por exemplo, `application=chatbot-X`, `team=marketing`). Cada invocação referencia o ARN do perfil; o Cost Explorer detalha os gastos por tag.

Testes, Validação e Resolução de Problemas

Compare três modelos de base em uma tarefa de sumarização; deseja-se avaliação automatizada e reproduzível.

Trabalhos de Avaliação de Modelo do Amazon Bedrock (automáticos). Forneça um conjunto de dados de prompt; o Bedrock executa cada modelo e relata BLEU, ROUGE, BERTScore, além de toxicidade / precisão onde aplicável.

As pontuações ROUGE parecem altas, mas os leitores humanos dizem que os resumos perdem pontos chave.

Mude para avaliação baseada em humanos do Bedrock com métricas personalizadas (relevância, completude, fidelidade). Defina uma rubrica, encaminhe uma amostra para uma força de trabalho, agregue pontuações.

Por quê: Métricas de sobreposição lexical (BLEU, ROUGE) perdem a fidelidade semântica. A avaliação humana é a verdade fundamental para tarefas subjetivas.

Precisa de avaliação escalonada e reproduzível, mas a revisão apenas humana é muito lenta/cara.

Avaliação LLM-como-juiz do Bedrock. Um modelo forte pontua as respostas contra uma rubrica; os resultados se correlacionam bem com revisores humanos e são executados em minutos em vez de dias.

Os resumos de portfólio gerados devem corresponder exatamente aos números do documento de origem.

Restrinja a geração: baixa temperatura (0–0.2), instruções de prompt estritas ("cite números literalmente da fonte"), verificação de fundamentação contextual dos Guardrails na saída, regex/parser pós-geração que valida números em relação à fonte.

Por quê: Mesmo com RAG fundamentado, os modelos parafraseiam números. Múltiplas camadas (prompt + fundamentação + parser) capturam os casos residuais.

O RAG frequentemente retorna "Não tenho informações suficientes" mesmo para tópicos cobertos na KB.

Inspecione os rastreamentos de recuperação: pontuações de fragmentos, contagem de fragmentos recuperados, alinhamento consulta-fragmento. Correções comuns: ativar pesquisa híbrida, aumentar top-k, ajustar tamanho do fragmento, mudar para fragmentação semântica, ativar reformulação de consulta, diminuir o limite de relevância.

O agente retorna preços desatualizados mesmo após uma sincronização recente da KB; a fonte de dados é S3 com versionamento.

Confirme se o IngestionJob mais recente tem `status: COMPLETE` e `documentsModified` reflete os novos objetos. O versionamento significa que versões não atuais ainda podem ser indexadas se a fonte de dados não estiver restrita apenas a versões atuais — verifique o filtro da fonte de dados e ressincronize.

O agente de RH ocasionalmente revela informações salariais de outros funcionários quando perguntado de forma inteligente.

Ajuste as instruções do agente ("responda apenas sobre os dados do próprio usuário solicitante"), controle o grupo de ações via atributos de sessão que incluem o ID do usuário, restrinja o IAM na Lambda que suporta o grupo de ações para consultar apenas os registros do próprio usuário, adicione um tópico negado dos Guardrails para consultas salariais entre usuários.

As invocações do Bedrock têm picos intermitentes de latência p95.

Verifique `InvocationThrottles` (acessos ao limite de taxa) e `ModelLatency` no CloudWatch; ative o rastreamento AWS X-Ray na Lambda chamadora; inspecione o CloudWatch Logs Insights para chamadas de ferramenta lentas ou recuperação de KB. Mitigue via inferência entre regiões, modelo menor, cache de prompt ou loteamento.

Migrar do Claude v2 para o Claude 3.5 Sonnet sem regressões.

Execute um trabalho de avaliação do Bedrock comparando ambos em um conjunto de prompts representativo. Em seguida, tráfego sombra em produção: envie a mesma entrada para ambos, compare as saídas offline. Promova com o sinalizador de recurso AppConfig em 10% → 50% → 100%.

Executar Avaliação de Modelo do Bedrock como parte do CI/CD em cada alteração de configuração do modelo.

Use a API `CreateEvaluationJob`. Defina o conjunto de dados no S3, avaliadores (embutidos ou personalizados) e modelos de destino. Consulte o status do trabalho; promova em `COMPLETED` com métricas acima dos limites.

Por quê: A interface do usuário do Studio é para usos únicos; a API é o único caminho para portões de avaliação automatizados e repetíveis.

Evitar regressões de qualidade ao atualizar o modelo de base em produção.

Mantenha um conjunto de testes de regressão curado: 100–500 prompts representativos com saídas esperadas (ou rubricas). Execute via Bedrock Model Evaluation em cada troca de modelo. Bloqueie a promoção se as pontuações caírem > limite definido.

Meça se o modelo escolhe a ferramenta certa com os argumentos certos no chat de uso de ferramentas.

Crie um conjunto rotulado: prompt + blocos `toolUse` esperados. Execute via avaliador personalizado que compara o nome da ferramenta real vs esperado + argumentos JSON. Acompanhe precisão/recall por ferramenta.

Por quê: Métricas lexicais (BLEU) perdem se o agente invocou a ação correta. A precisão do uso da ferramenta é a métrica correta para cargas de trabalho de agente.