# Design Doc: Governança de Modelos Frontier no Bedrock com GPT, Claude e Nova

Este documento propõe uma arquitetura de AI Gateway para orquestrar e governar múltiplos modelos frontier — OpenAI GPT-5.5/GPT-4.5, Anthropic Claude, Amazon Nova e modelos especializados — dentro do Amazon Bedrock. O design cobre roteamento inteligente, guardrails, prompt registry, logging de inferência, IAM por tenant, data residency e política de fallback, com foco em auditabilidade e controle de custos em ambientes enterprise.

- URL: https://fernando.moretes.com/studies/design-doc-bedrock-openai-frontier-model-governance

- Markdown: https://fernando.moretes.com/studies/design-doc-bedrock-openai-frontier-model-governance/study.md?lang=pt

- Type: Design Doc / RFC

- Company: AI Platform (cenário)

- Domain: IA / Governança

- Date: 2026-06-01

- Tags: bedrock, ai-gateway, guardrails, multi-model, governance, iam, data-residency, llmops

- Reading time: 11 min

---

Com a chegada dos modelos OpenAI no Amazon Bedrock e a maturidade crescente do Claude e do Amazon Nova, plataformas enterprise enfrentam um problema real de governança: como rotear, auditar, controlar custos e garantir conformidade quando o portfólio de modelos disponíveis cresce mais rápido do que a capacidade operacional de gerenciá-los. Este RFC propõe um AI Gateway que trata essa complexidade como um problema de plataforma — não de aplicação.

## O Problema: Proliferação de Modelos Sem Plano de Controle

Durante os últimos 18 meses, cada equipe de produto passou a consumir LLMs de forma independente. Uma squad usa Claude 3.5 Sonnet diretamente via SDK da Anthropic. Outra chama GPT-4o via Azure OpenAI. Uma terceira experimentou Amazon Titan e agora quer migrar para Nova Pro. O resultado é previsível: nenhuma visibilidade centralizada de custo, nenhuma auditoria consolidada de prompts, nenhuma política de fallback quando um provedor sofre degradação, e — o mais crítico em ambientes regulados — nenhuma garantia de que dados sensíveis não estão cruzando fronteiras de jurisdição que violam LGPD, GDPR ou requisitos de residência de dados contratuais.

O Amazon Bedrock endereça parte desse problema ao consolidar múltiplos provedores sob uma única API e infraestrutura AWS. Com o anúncio recente de modelos OpenAI disponíveis no Bedrock (GPT-4.5, GPT-4.1 e variantes), a plataforma passa a ser um ponto de agregação legítimo para a maioria dos casos de uso enterprise. Mas o Bedrock por si só não resolve governança: ele oferece os primitivos (Guardrails, Model Invocation Logging, IAM, VPC endpoints), mas a responsabilidade de compor esses primitivos em uma arquitetura coerente é do arquiteto.

O problema central que este documento endereça é: **como construir um plano de controle unificado sobre múltiplos modelos frontier dentro do Bedrock, que seja auditável, seguro por design, consciente de custo e operacionalmente sustentável?** A resposta não é um produto — é uma arquitetura.

## Objetivos e Não-Objetivos

- ✅ OBJETIVO: Roteamento inteligente entre modelos (GPT-5.5, GPT-4.5, Claude 3.7, Nova Pro/Lite, modelos especializados) com política declarativa por caso de uso
- ✅ OBJETIVO: Guardrails centralizados (PII, toxicidade, jailbreak, grounding) aplicados antes e depois de cada inferência, independente do modelo
- ✅ OBJETIVO: Prompt Registry versionado com rastreabilidade de qual versão de prompt gerou qual output
- ✅ OBJETIVO: IAM por tenant com isolamento de credenciais e policies de acesso a modelos específicos por workload
- ✅ OBJETIVO: Data residency garantida — dados de clientes regulados processados exclusivamente em regiões aprovadas
- ✅ OBJETIVO: Token budget enforcement por tenant/use-case com alertas e hard stops

## Ficha Técnica

- **Cenário:** Plataforma de IA enterprise multi-tenant (cenário composto)
- **Modelos no escopo:** GPT-4.5, GPT-4.1 (OpenAI via Bedrock), Claude 3.7 Sonnet, Claude 3.5 Haiku, Amazon Nova Pro, Nova Lite, Nova Micro
- **Plataforma base:** Amazon Bedrock (us-east-1, sa-east-1 para dados brasileiros)
- **Escala estimada:** ~50M tokens/dia, 15 tenants, 40+ use cases distintos
- **Requisitos regulatórios:** LGPD, GDPR, SOC 2 Type II, residência de dados contratual
- **Stack de controle:** API Gateway, Lambda, DynamoDB, S3, CloudWatch, Bedrock Guardrails, AWS IAM, Secrets Manager, EventBridge
- **Status do documento:** RFC — Proposto, aguardando revisão de segurança e aprovação de arquitetura

## Design Proposto: O AI Gateway como Plano de Controle

A arquitetura central é um **AI Gateway** — uma camada de serviço que fica entre os consumidores (aplicações, agentes, pipelines) e os modelos no Bedrock. Não é um proxy burro: ele executa lógica de negócio de governança antes, durante e depois de cada chamada de inferência.

**Camada de Entrada e Autenticação**

Todo tráfego entra via Amazon API Gateway com autenticação por JWT (Cognito) ou API Key vinculada a um `tenant_id`. O primeiro passo é a resolução do contexto do tenant: o Gateway Lambda consulta o DynamoDB (`tenant-config` table) para obter o perfil do tenant — quais modelos estão habilitados, qual é o token budget mensal, qual região de dados é permitida, e qual é a política de fallback configurada. Isso elimina lógica de autorização espalhada pelas aplicações.

**Prompt Registry e Versionamento**

Prompts não são strings inline no código da aplicação. Eles são artefatos versionados armazenados no S3 com metadados no DynamoDB: `prompt_id`, `version`, `model_affinity` (quais modelos foram testados com esse prompt), `eval_score`, `author`, `approved_at`. O Gateway resolve o prompt pelo ID e versão antes de montar o payload de inferência. Isso garante que o log de auditoria sempre referencia `prompt_id:version`, não o texto raw — o que é crítico para investigações pós-incidente e para demonstrar controle em auditorias.

**Guardrails em Duas Fases**

O Bedrock Guardrails é invocado em duas fases: pré-inferência (validação do input — PII detection, topic blocking, prompt injection patterns) e pós-inferência (validação do output — grounding check, toxicidade, leakage de dados internos). A configuração de guardrails é por `guardrail_profile` associado ao use case, não ao tenant — porque o mesmo tenant pode ter use cases com tolerâncias diferentes (um chatbot público tem guardrails mais restritivos que uma ferramenta interna de análise de código). Guardrails que bloqueiam retornam um evento estruturado para o EventBridge, que aciona alertas e, em casos de violação grave, suspende o use case automaticamente.

**Roteamento e Fallback**

A política de roteamento é declarativa, armazenada por use case no DynamoDB: modelo primário, modelo de fallback, critério de fallback (latência > X ms, erro 5xx, ou custo por token acima de threshold). O Gateway implementa um circuit breaker simples: após N falhas consecutivas no modelo primário, ele abre o circuito e roteia para o fallback pelo período de cooldown configurado. O log registra qual modelo efetivamente serviu cada request — crítico para debugging e para análise de custo real vs. planejado.

**Token Budget e Cost Control**

Cada tenant tem um budget mensal de tokens (configurável por model tier — tokens de Nova Micro custam menos que tokens de GPT-4.5). O Gateway mantém um contador incremental no DynamoDB com TTL mensal. Quando o uso atinge 80% do budget, um evento é publicado no EventBridge para notificação. A 100%, o Gateway retorna 429 com header `X-Budget-Exhausted: true`. Hard stops são não-negociáveis — não existe override sem aprovação explícita registrada no audit log.

**Logging de Inferência**

O Bedrock Model Invocation Logging está habilitado no nível da conta, com logs entregues ao S3 e indexados no CloudWatch Logs Insights. O Gateway enriquece esses logs com metadados que o Bedrock não captura nativamente: `tenant_id`, `use_case_id`, `prompt_id:version`, `guardrail_result`, `routing_decision` (primary vs. fallback), e `budget_remaining`. O schema é fixo e versionado — mudanças no schema de log passam por revisão porque quebrar queries de auditoria é um risco operacional real.

## Arquitetura: AI Gateway sobre Amazon Bedrock

Fluxo completo de uma requisição de inferência: do consumidor até o modelo frontier, passando pelo plano de controle de governança.

### 👤 Consumers

- Application Tenant App / Agent (user)
- Data Pipeline Batch / Streaming (user)

### 🔐 Auth & Ingress

- API Gateway REST + JWT/API Key (edge)
- Cognito Tenant Identity (security)

### 🧠 AI Gateway Control Plane

- Gateway Lambda Orchestrator (compute)
- Tenant Config DynamoDB (data)
- Prompt Registry S3 + DynamoDB (storage)
- Budget Counter DynamoDB (TTL) (data)
- Routing Engine Policy + Circuit Breaker (compute)

### 🛡️ Guardrails

- Bedrock Guardrails PII / Toxicity / Grounding (security)
- EventBridge Violation Events (messaging)

### 🤖 Bedrock Model Layer

- Amazon Nova Pro Primary: General (ai)
- Amazon Nova Lite Fallback: Cost-opt (ai)
- Claude 3.7 Sonnet Primary: Reasoning (ai)
- Claude 3.5 Haiku Fallback: Latency-opt (ai)
- GPT-4.5 (OpenAI) via Bedrock (ai)
- GPT-4.1 (OpenAI) Fallback tier (ai)

### 📋 Audit & Observability

- Invocation Logs S3 + CloudWatch (storage)
- Log Enricher Lambda tenant/prompt/routing meta (compute)
- CloudWatch Insights Audit Queries (data)

### Fluxos

- app -> apigw: HTTPS + JWT
- pipeline -> apigw: HTTPS + API Key
- apigw -> cognito: Validar token
- apigw -> gw_lambda: Request + tenant_id
- gw_lambda -> tenant_cfg: Resolver perfil
- gw_lambda -> prompt_reg: Buscar prompt v.
- gw_lambda -> budget_ctr: Checar/incrementar
- gw_lambda -> guardrails: Pré-inferência
- gw_lambda -> router: Política de roteamento
- router -> nova_pro: Primary
- router -> nova_lite: Fallback
- router -> claude_sonnet: Primary
- router -> claude_haiku: Fallback
- router -> gpt45: Primary
- router -> gpt41: Fallback
- gw_lambda -> guardrails: Pós-inferência
- guardrails -> eb_violations: Violação detectada
- nova_pro -> inv_log: Bedrock log nativo
- claude_sonnet -> inv_log
- gpt45 -> inv_log
- inv_log -> audit_enricher: Enriquecer metadados
- audit_enricher -> cw_insights

## Data Residency e Isolamento por Tenant

Este é o aspecto mais frequentemente subestimado em arquiteturas de AI Gateway. Quando um cliente tem dados classificados como PII brasileiro sob LGPD, ou dados de saúde sob regulação setorial, a garantia de que esses dados não saem da região `sa-east-1` não pode ser uma promessa verbal — precisa ser arquitetural e auditável.

**Estratégia de Residência por Tenant**

O perfil do tenant no DynamoDB inclui um campo `allowed_regions: ["sa-east-1"]` e `allowed_models` que é a intersecção dos modelos disponíveis nessa região com os modelos habilitados para o tenant. O Gateway rejeita requests que tentariam rotear dados de um tenant restrito para uma região não aprovada — e esse reject é logado como evento de violação de política, não como erro silencioso.

O Amazon Bedrock hoje disponibiliza modelos em múltiplas regiões, mas o portfólio varia. Nova Pro e Claude 3.5 Haiku estão disponíveis em `sa-east-1`. GPT-4.5 via Bedrock está disponível inicialmente em `us-east-1`. Isso significa que tenants com restrição de residência brasileira **não podem usar GPT-4.5 neste momento** — e o Gateway deve enforçar isso automaticamente, não depender de disciplina do desenvolvedor.

**Isolamento de Credenciais**

Cada tenant tem uma IAM Role dedicada com política de acesso restrita aos modelos permitidos. O Gateway assume essa role via STS `AssumeRole` antes de invocar o Bedrock, garantindo que o log de CloudTrail registre a role do tenant — não a role genérica do Gateway. Isso é essencial para auditoria: em uma investigação, você precisa saber exatamente qual tenant invocou qual modelo, não apenas que o Gateway fez uma chamada.

Secrets Manager armazena as configurações de role ARN por tenant. Rotação de credenciais é automática. O acesso ao Bedrock é exclusivamente via VPC Endpoint — não existe caminho de dados que atravesse a internet pública, independente do modelo.

**Evals e Qualidade**

O Prompt Registry inclui scores de avaliação por modelo: antes de promover uma versão de prompt para produção, ela passa por um pipeline de evals automatizado que testa contra um conjunto de casos de referência e registra métricas de qualidade (accuracy, hallucination rate, latência p95) por modelo. Isso permite decisões de roteamento baseadas em evidência — não em preferência de fornecedor. Se Claude 3.7 tem eval score superior para o use case de extração de cláusulas contratuais, ele é o primário para esse use case, independente de custo por token.

## Alternativas Arquiteturais Consideradas

### AI Gateway customizado (este design)

**Pros**
- Controle total sobre lógica de roteamento, budget e auditoria
- Integração nativa com IAM, CloudTrail, VPC Endpoints
- Sem dependência de vendor adicional no critical path

**Cons**
- Custo de desenvolvimento e manutenção do Gateway
- Responsabilidade de evolução do circuit breaker e retry logic

**Verdict:** Recomendado para ambientes enterprise com requisitos regulatórios

### LiteLLM / Portkey como proxy OSS

**Pros**
- Rápido para começar, suporte multi-model nativo
- Comunidade ativa, menos código para manter

**Cons**
- Integração com IAM por tenant requer customização significativa
- Auditoria e data residency não são first-class features
- Mais um componente a operar e patchear

**Verdict:** Adequado para MVPs sem requisitos regulatórios; não recomendado para este cenário

### Amazon Bedrock Agents como orquestrador

**Pros**
- Gerenciado pela AWS, integração nativa com Guardrails e Knowledge Bases
- Reduz código de orquestração

**Cons**
- Roteamento multi-model não é o caso de uso principal do Bedrock Agents
- Menor flexibilidade para budget enforcement e lógica de tenant customizada
- Custo por step de agente pode ser proibitivo em alto volume

**Verdict:** Complementar para use cases de agentes; não substitui o Gateway de governança

### Acesso direto ao Bedrock por aplicação

**Pros**
- Simplicidade inicial, sem latência adicional do Gateway

**Cons**
- Sem governança centralizada — o estado atual que estamos resolvendo
- Impossível auditar, controlar custo ou enforçar data residency de forma confiável
- Cada aplicação reimplementa (mal) autenticação, retry e logging

**Verdict:** Rejeitado — é o problema, não a solução

## Decisão: Bedrock como Plano Unificado de Inferência

**Status:** proposed

**Contexto**

Com modelos OpenAI agora disponíveis no Bedrock, existe a opção de consolidar todo o tráfego de inferência no Bedrock (eliminando integrações diretas com OpenAI API e Anthropic API) ou manter integrações diretas para alguns modelos.

**Decisão**

Consolidar todo tráfego de inferência no Amazon Bedrock. Integrações diretas com OpenAI API ou Anthropic API são proibidas para workloads de produção. Exceção: modelos não disponíveis no Bedrock podem usar integração direta com aprovação explícita de arquitetura e com o mesmo Gateway como intermediário.

**Consequências**
- ✅ Billing consolidado na AWS — um único ponto de custo e auditoria financeira
- ✅ VPC Endpoints disponíveis para todos os modelos — data residency enforçável
- ✅ CloudTrail cobre todas as invocações — auditoria unificada
- ⚠️ Dependência de disponibilidade de modelos no Bedrock — novos modelos OpenAI podem demorar para chegar
- ⚠️ Possível latência adicional vs. chamada direta à API do provedor — a medir e documentar

## Plano de Rollout

1. **Semana 1-2: Fundação e Tenant Config** — Provisionar infraestrutura base: API Gateway, Lambda do Gateway, DynamoDB tables (tenant-config, prompt-registry, budget-counters), VPC Endpoints para Bedrock. Migrar 1 tenant piloto (não-regulado) para o Gateway. Validar fluxo end-to-end com Nova Lite.

2. **Semana 3-4: Prompt Registry e Logging** — Implementar Prompt Registry com S3 + DynamoDB. Migrar prompts existentes para o registry com versionamento. Habilitar Model Invocation Logging no Bedrock. Implementar Log Enricher Lambda. Validar que audit queries no CloudWatch Insights retornam tenant_id e prompt_id:version corretamente.

3. **Semana 5-6: Guardrails e Violação de Política** — Configurar Bedrock Guardrails por use case profile. Implementar fluxo de violação: Guardrails → EventBridge → SNS → alertas. Testar com casos de PII, toxicidade e prompt injection. Documentar taxa de falsos positivos por profile e ajustar thresholds.

4. **Semana 7-8: IAM por Tenant e Data Residency** — Criar IAM Roles por tenant com políticas de acesso a modelos específicos. Implementar STS AssumeRole no Gateway. Configurar restrições de região por tenant no DynamoDB. Testar que tenant com allowed_regions=[sa-east-1] não consegue invocar GPT-4.5 (us-east-1 only). Validar CloudTrail com role do tenant.

5. **Semana 9-10: Token Budget e Circuit Breaker** — Implementar budget counter com DynamoDB atomic increments e TTL. Configurar alertas de 80% e hard stop de 100%. Implementar circuit breaker no Router com estado em DynamoDB (N falhas → open circuit → cooldown). Testar failover automático entre modelos primário e fallback.

6. **Semana 11-12: Evals Pipeline e Migração de Tenants Regulados** — Implementar pipeline de evals automatizado para promoção de prompts. Migrar tenants com requisitos regulatórios (LGPD) para o Gateway. Executar revisão de segurança formal. Documentar runbook operacional. Go-live com todos os tenants.

> **Riscos e Mitigações:** **R1 — Latência adicional do Gateway (Alto):** Cada hop no Gateway (DynamoDB reads, STS AssumeRole, Guardrails pré/pós) adiciona latência. Estimativa: 50-150ms por request. Mitigação: cache de tenant config (TTL 5min), cache de prompt resolvido (TTL por versão), Guardrails em modo assíncrono para use cases tolerantes a latência. Medir p95 e p99 desde o dia 1.

**R2 — Disponibilidade de modelos OpenAI no Bedrock (Médio):** GPT-4.5 e GPT-4.1 estão em disponibilidade inicial no Bedrock. SLAs podem diferir da API direta da OpenAI. Mitigação: fallback obrigatório configurado para todos os use cases que usam GPT, com Claude como alternativa testada e com eval scores documentados.

**R3 — DynamoDB como SPOF do Gateway (Alto):** Budget counter, tenant config e circuit breaker state dependem do DynamoDB. Uma degradação no DynamoDB paralisa o Gateway. Mitigação: DynamoDB Global Tables com multi-region, read replicas, e modo de degradação graciosa (fail-open com log de auditoria) para tenant config reads — nunca para budget enforcement.

**R4 — Falsos Positivos nos Guardrails (Médio):** Guardrails muito restritivos bloqueiam requests legítimos, degradando UX. Mitigação: período de shadow mode (log sem bloquear) antes de ativar blocking mode. Revisão semanal de taxa de falsos positivos por profile nas primeiras 4 semanas.

**R5 — Prompt Registry como gargalo de deploy (Baixo-Médio):** Se o processo de aprovação de prompts for burocrático, equipes vão contorná-lo. Mitigação: pipeline de evals automatizado com aprovação automática quando score > threshold. Aprovação manual apenas para mudanças de alto risco (prompts de sistema, mudanças de persona).

**R6 — Custo do Gateway em si (Baixo):** Lambda + DynamoDB + API Gateway para 50M tokens/dia é estimado em < $500/mês — negligível vs. custo de inferência. Mas monitorar para evitar surpresas em picos.

## AWS Well-Architected: Avaliação por Pilar

- **security**: IAM por tenant com STS AssumeRole, VPC Endpoints para Bedrock, Guardrails em duas fases, Secrets Manager para credenciais, CloudTrail habilitado. Nenhum dado de inferência trafega pela internet pública.
- **reliability**: Circuit breaker com fallback automático, DynamoDB Global Tables, degradação graciosa para leituras de configuração. SLA do Gateway dependente do SLA do Bedrock — monitorar Service Health Dashboard.
- **performance**: Cache de tenant config e prompts reduz latência de controle. Guardrails assíncronos para use cases tolerantes. Roteamento para Nova Lite/Haiku em cenários de cost-opt reduz latência de inferência.
- **sustainability**: Roteamento para modelos menores (Nova Micro, Haiku) para use cases simples reduz consumo computacional. Token budget limita desperdício de inferência desnecessária.

## Métricas de Sucesso e Targets

- **Latência adicionada pelo Gateway (p95):** < 150ms — medir desde semana 1
- **Cobertura de auditoria:** 100% das invocações com tenant_id + prompt_id:version no log
- **Tempo para detectar violação de data residency:** < 1 minuto (EventBridge + SNS)
- **Taxa de falsos positivos nos Guardrails:** < 2% por use case após 4 semanas de tuning
- **Disponibilidade do Gateway:** 99.9% (excluindo janelas de manutenção planejadas)
- **Desvio de custo de inferência vs. budget:** < 5% de overage por tenant por mês
- **Tempo de promoção de prompt (evals → produção):** < 30 minutos para aprovação automática
- **Adoção do Gateway:** 100% dos tenants migrados até semana 12

> **Minha Perspectiva Senior:** O erro mais comum que vejo em plataformas de IA enterprise é tratar governança como um problema de compliance a ser resolvido depois — quando na verdade é um problema de plataforma que precisa ser resolvido antes. Se você deixar 15 equipes consumirem modelos diretamente por 6 meses, você vai ter 15 padrões diferentes de autenticação, 15 formas diferentes de logar (ou não logar) prompts, e zero capacidade de responder 'quais dados do cliente X foram enviados para qual modelo em qual data' — que é exatamente a pergunta que um auditor vai fazer.

Sobre a chegada dos modelos OpenAI no Bedrock: isso é genuinamente relevante para arquiteturas enterprise, não apenas marketing. Consolidar GPT-4.5, Claude e Nova sob uma única API, billing e modelo de segurança (VPC Endpoints, IAM, CloudTrail) elimina uma classe inteira de problemas de governança. Mas eu não migraria para isso sem validar latência e SLA na sua região e use case específico — a promessa de consolidação só vale se a performance for comparável.

O design que proponho aqui é deliberadamente mais pesado do que o mínimo necessário para um MVP. Para um produto com 2 tenants e sem requisitos regulatórios, LiteLLM + logging básico é suficiente. Mas para o cenário descrito — 15 tenants, LGPD, data residency contratual, auditoria SOC 2 — cada componente deste design tem uma razão de existir que você vai precisar justificar para um auditor, não para mim. O Prompt Registry parece overhead até o dia que você precisa provar que a versão 1.3 do prompt de extração de dados nunca foi usada com dados de clientes regulados. O STS AssumeRole por tenant parece paranoia até o CloudTrail salvar sua investigação.

Um ponto que eu enfatizaria para quem está implementando: o schema do log de auditoria é um contrato. Trate-o como tal. Versione-o, documente-o, e nunca faça breaking changes sem migração. Quebrar queries de auditoria em produção é o tipo de problema que aparece na pior hora possível.

## Veredicto

Este design é recomendado para aprovação com as seguintes condições: (1) validação de latência do Gateway em ambiente de staging antes da migração de tenants regulados — o target de p95 < 150ms precisa ser medido, não assumido; (2) revisão de segurança formal antes do go-live com tenants LGPD, cobrindo especificamente o fluxo de STS AssumeRole e a configuração de VPC Endpoints; (3) período obrigatório de shadow mode para Guardrails (mínimo 2 semanas por profile) antes de ativar blocking mode em produção.

A consolidação no Bedrock como plano unificado de inferência é a decisão arquitetural mais importante deste design, e ela é correta para o cenário descrito. A disponibilidade de modelos OpenAI no Bedrock remove o principal argumento contra essa consolidação. O AI Gateway como plano de controle sobre o Bedrock é o padrão que eu implementaria em qualquer plataforma enterprise com mais de 5 tenants ou com qualquer requisito regulatório — não porque é elegante, mas porque é o único design que permite responder perguntas de auditoria com evidência, não com suposição.

## Referências

- [AWS News Blog — OpenAI models on Amazon Bedrock](https://aws.amazon.com/blogs/aws/)
- [Amazon Bedrock — Product Page](https://aws.amazon.com/bedrock/)
- [Amazon Bedrock — Supported Foundation Models](https://docs.aws.amazon.com/bedrock/latest/userguide/models-supported.html)
- [Amazon Bedrock Guardrails — Documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html)
- [Amazon Bedrock Model Invocation Logging](https://docs.aws.amazon.com/bedrock/latest/userguide/model-invocation-logging.html)
- [AWS IAM — AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)
- [Amazon Bedrock VPC Endpoints](https://docs.aws.amazon.com/bedrock/latest/userguide/usingVPC.html)

## Fontes do caso

- [AWS News Blog — OpenAI models on Amazon Bedrock](https://aws.amazon.com/blogs/aws/)
- [Amazon Bedrock — AWS](https://aws.amazon.com/bedrock/)
- [Amazon Bedrock — Supported foundation models](https://docs.aws.amazon.com/bedrock/latest/userguide/models-supported.html)