Author: Make.com Service User

Introdução: Da Demonstração ao Valor em Produção

Construir agentes de IA prontos para ambientes corporativos exige mais do que simplesmente conectar um modelo de linguagem a APIs existentes. A diferença entre um protótipo que impressiona em uma demonstração e um agente que realmente entrega valor em produção está fundamentada em práticas de engenharia disciplinadas, arquitetura robusta e melhorias contínuas.

A AWS desenvolveu o Amazon Bedrock AgentCore, uma plataforma agentic que oferece os serviços necessários para criar, implantar e gerenciar agentes de IA em escala. Este artigo explora nove práticas essenciais que os times podem aplicar imediatamente ao desenvolvê-los.

1. Comece Pequeno e Defina o Sucesso com Clareza

A primeira pergunta que as equipes devem responder não é “o que este agente pode fazer?”, mas “qual problema estamos resolvendo?”. Muitas vezes, times começam construindo agentes que tentam lidar com todos os cenários possíveis, resultando em complexidade excessiva, ciclos de iteração lentos e agentes que não se destacam em nada específico.

A abordagem recomendada é trabalhar de forma invertida, partindo de um caso de uso específico. Se o objetivo é construir um assistente financeiro, comece com as três tarefas mais comuns dos analistas. Para um assistente de RH, foque nas cinco perguntas de funcionários mais frequentes. Garanta que essas funcionalidades funcionem de forma confiável antes de expandir o escopo.

O planejamento inicial deve gerar quatro entregas concretas:

• Definição clara do que o agente deve e não deve fazer
• Tom e personalidade — decidindo entre formal ou conversacional, como cumprimentar usuários e o que fazer quando encontrar questões fora do escopo
• Definições inequívocas para cada ferramenta, parâmetro e fonte de conhecimento
• Conjunto de dados de referência contendo interações esperadas, casos comuns e casos extremos

Construir um prototipo com esse escopo limitado e testá-lo com usuários reais revelará problemas imprevistos — seja na análise de datas, no tratamento de abreviações ou na invocação de ferramentas incorretas quando as perguntas são formuladas de forma inesperada. Identificar essas questões em um prototipo pode custar algumas semanas; descobri-las em produção pode comprometer credibilidade e confiança.

2. Implemente Observabilidade desde o Primeiro Dia

Um dos maiores erros que times cometem é tratar observabilidade como algo a ser adicionado depois. Quando a necessidade de observabilidade se torna evidente, o agente já está em produção, dificultando a depuração efetiva.

Desde a primeira consulta de teste, é necessário visibilidade no que o agente está fazendo. O AgentCore emite rastreamentos OpenTelemetry (Telemetria Aberta) automaticamente, capturando invocações de modelos, chamadas de ferramentas e etapas de raciocínio. Quando uma consulta leva doze segundos, é possível identificar se o atraso veio do modelo de linguagem, de uma consulta ao banco de dados ou de uma chamada para uma API externa.

A estratégia de observabilidade deve incluir três camadas:

• Depuração em nível de rastreamento durante o desenvolvimento, permitindo visualizar cada etapa da conversa
• Dashboards de produção usando o AgentCore Observability para rastrear uso de tokens, percentis de latência, taxas de erro e padrões de invocação de ferramentas
• Exportação de dados para sistemas de observabilidade existentes como Datadog, Dynatrace, LangSmith ou Langfuse

Observabilidade serve diferentes necessidades conforme o papel. Desenvolvedores a utilizam para depuração, respondendo perguntas como por que o agente alucinava ou qual versão de prompt tem melhor desempenho. Times de plataforma a utilizam para governança, monitorando gastos por time, quais agentes causam aumentos de custo e o que aconteceu em um incidente específico.

3. Estabeleça uma Estratégia Deliberada de Ferramentas

Ferramentas são o mecanismo pelo qual agentes acessam o mundo real. Elas buscam dados em bancos de dados, chamam APIs externas, pesquisam documentação e executam lógica de negócios. A qualidade das definições de ferramentas impacta diretamente o desempenho do agente.

Na definição de uma ferramenta, clareza é mais importante que brevidade. Considere duas descrições para a mesma função:

Inadequada: “Obtém dados de receita”

Adequada: “Recupera dados de receita trimestral para uma região especificada e período. Retorna valores em milhões USD. Requer código de região (EMEA, APAC, AMER) e trimestre no formato AAAA-QN (ex: 2024-Q3).”

A primeira descrição força o agente a adivinhar quais entradas são válidas e como interpretar saídas. A segunda remove ambiguidades. Multiplicado por vinte ferramentas, a diferença torna-se dramática.

A estratégia de ferramentas deve abordar quatro áreas:

• Tratamento de erros e resiliência: Ferramentas falham, APIs retornam erros, timeouts acontecem. Defina o comportamento esperado para cada modo de falha
• Reutilização via Protocolo MCP (Model Context Protocol): Muitos provedores já oferecem servidores MCP para ferramentas como Slack, Google Drive, Salesforce e GitHub. Use-os em vez de construir integrações personalizadas
• Catálogo centralizado de ferramentas: Times não devem construir o mesmo conector de banco de dados cinco vezes. Mantenha um catálogo aprovado de ferramentas revisadas por segurança e testadas em produção
• Exemplos de código com cada ferramenta: Documentação sozinha não é suficiente. Forneça exemplos funcionais que os desenvolvedores possam copiar e adaptar

O AgentCore Gateway resolve o problema prático de proliferação de ferramentas. À medida que se constroem mais agentes, acumulam-se dezenas de ferramentas — algumas expostas por servidores MCP, outras por AWS Lambda, outras ainda pelo Amazon API Gateway. Sem o AgentCore Gateway, cada time de agentes reimplementa autenticação, gerencia endpoints separados e carrega todas as definições de ferramentas nos prompts, mesmo quando poucas são relevantes.

O Gateway oferece um ponto de entrada único para ferramentas onde quer que residam, com capacidade de busca semântica que permite aos agentes encontrar a ferramenta certa baseado no que estão tentando alcançar, autenticação abrangente e controle de quais agentes podem acessar quais ferramentas.

4. Automatize Avaliação Desde o Início

É necessário saber se um agente está melhorando ou piorando a cada alteração. Avaliação automatizada fornece esse ciclo de feedback. Comece definindo o que “bom” significa para o caso de uso específico. As métricas variam conforme a indústria e tarefa:

• Um agente de atendimento ao cliente pode ser medido por taxa de resolução e satisfação
• Um agente de análise financeira pode ser medido por precisão de cálculo e qualidade de citações
• Um assistente de RH pode ser medido por precisão de políticas e completude de resposta

Equilibre métricas técnicas com métricas de negócio. Latência de resposta importa, mas apenas se as respostas forem corretas. Custo de tokens importa, mas apenas se usuários encontrarem valor no agente.

O conjunto de dados de avaliação deve incluir múltiplas formulações da mesma pergunta, casos extremos onde o agente deveria se recusar a responder ou escalar para um humano, e consultas ambíguas com múltiplas interpretações válidas.

5. Decomponha Complexidade com Sistemas Multi-Agentes

Quando um agente único tenta lidar com muitas responsabilidades, fica difícil de manter. Os prompts crescem em complexidade, a lógica de seleção de ferramentas falha e o desempenho se degrada. A solução é decompor o problema em múltiplos agentes especializados que colaboram.

Pense em organizar um time. Não se contrata uma pessoa para lidar com vendas, engenharia, suporte e finanças. Contratam-se especialistas que coordenam seu trabalho. O mesmo princípio aplica-se a agentes. Em vez de um agente tratando trinta tarefas diferentes, construa três agentes que cada um trata dez tarefas relacionadas.

Cada agente tem instruções mais claras, conjuntos de ferramentas mais simples e lógica mais focada. Padrões sequenciais funcionam quando tarefas têm uma ordem natural. Padrões hierárquicos funcionam quando é necessário roteamento inteligente. Padrões ponto-a-ponto funcionam quando agentes precisam colaborar dinamicamente sem um coordenador central.

O desafio chave em sistemas multi-agentes é manter contexto através de passagens de trabalho. Quando um agente passa trabalho para outro, o segundo agente precisa saber o que já aconteceu. O AgentCore Memory oferece contexto compartilhado que múltiplos agentes podem acessar dentro de uma sessão.

6. Dimensione Seguramente com Personalização

Passar de um protótipo que funciona para um desenvolvedor para um sistema em produção servindo milhares de usuários introduz novos requisitos de isolamento, segurança e personalização.

Isolamento de sessão vem em primeiro lugar. A conversa do usuário A não pode vazar para a sessão do usuário B sob qualquer circunstância. O AgentCore Runtime executa cada sessão em sua própria máquina virtual isolada com computação e memória dedicadas. Quando a sessão termina, a máquina virtual é encerrada e nenhum estado compartilhado existe entre usuários.

Personalização requer memória que persista entre sessões. O AgentCore Memory oferece memória de curto prazo para histórico de conversas e memória de longo prazo para fatos, preferências e interações passadas, tudo organizado por usuário para manter contexto privado.

Segurança e controle de acesso devem ser impostos antes que ferramentas executem. Usuários devem acessar apenas dados para os quais têm permissão. Quando um usuário interage com um agente, primeiro autentica-se através de um provedor de identidade, seja Amazon Cognito, Microsoft Entra ID ou Okta. O AgentCore Identity recebe o token de autenticação e extrai claims OAuth customizados que definem permissões e atributos do usuário.

O AgentCore Policy valida se um usuário específico tem permissão para invocar uma ferramenta específica com parâmetros específicos. Se um analista júnior tentar acessar dados de remuneração executiva, a solicitação é negada antes de alcançar qualquer banco de dados.

7. Combine Agentes com Código Determinístico

Uma das decisões arquiteturais mais importantes é saber quando confiar em comportamento agentic e quando usar código tradicional. Agentes são poderosos, mas não são apropriados para todas as tarefas.

Reserve agentes para tarefas que exigem raciocínio sobre entradas ambíguas — entender consultas em linguagem natural, determinar quais ferramentas invocar e interpretar resultados em contexto. Use código tradicional para cálculos, validações e lógica baseada em regras. O crescimento de receita é uma fórmula. Validação de datas segue padrões. Regras de negócio são declarações condicionais. Não é necessário um modelo de linguagem para calcular “subtrair Q2 de Q3 e dividir por Q2”. Escreva uma função Python que executa em milissegundos sem custo adicional.

A arquitetura correta tem agentes orquestrando funções de código. Quando um usuário pergunta “Qual foi nosso crescimento na EMEA neste trimestre?”, o agente usa raciocínio para entender a intenção e determinar qual dados buscar. Chama uma função determinística para executar o cálculo. Depois usa raciocínio novamente para explicar o resultado em linguagem natural.

8. Estabeleça Práticas de Teste Contínuo

Implantação em produção não é a linha de chegada. É a linha de saída. Agentes operam em um ambiente em constante mudança. Comportamento de usuários evolui. Lógica de negócio muda. Modelo pode sofrer deriva. Teste contínuo é necessário para detectar essas mudanças antes que impactem usuários.

Construa um pipeline de teste contínuo que execute em cada atualização. Mantenha um conjunto de testes com consultas representativas cobrindo casos comuns e casos extremos. Quando um prompt muda, uma ferramenta é adicionada ou modelos são trocados, o pipeline executa o conjunto de testes e avalia os resultados.

O AgentCore Evaluations simplifica a mecânica de executar essas avaliações, oferecendo modos de avaliação sob demanda e avaliações online que monitoram tráfego de produção continuamente.

9. Construa Capacidade Organizacional com Pensamento de Plataforma

O primeiro agente em produção é uma conquista. Mas o valor em nível empresarial vem do dimensionamento dessa capacidade pela organização. Isso requer pensamento de plataforma, não apenas pensamento de projeto.

Estabeleça um time de plataforma para estabelecer padrões e oferecer infraestrutura compartilhada. Quando um novo time quer construir um agente, começa com o toolkit de plataforma. Implemente monitoramento centralizado mostrando agentes, sessões e custos. Quando uso de tokens aumenta inesperadamente, líderes de plataforma podem ver imediatamente.

Promova colaboração entre times para que aprendam uns com os outros. Três times não devem construir três versões de um conector de banco de dados. Em vez disso, devem compartilhar ferramentas através do AgentCore Gateway, compartilhar estratégias de avaliação e hospedar sessões regulares onde times demonstram seus agentes e discutem desafios.

O padrão de dimensionamento organizacional é um processo de rastejar, caminhar, correr:

• Fase rastejar: Implante o primeiro agente internamente para um pequeno grupo piloto. Foco em aprendizado e iteração. Falhas são baratas
• Fase caminhar: Implante para um grupo controlado de usuários externos. Mais usuários, mais feedback, mais casos extremos descobertos
• Fase correr: Dimensione o agente para usuários externos com confiança. Capacidades de plataforma permitem que outros times construam seus próprios agentes mais rapidamente

Componentes do Amazon Bedrock AgentCore

Para implementar essas práticas, a AWS oferece um conjunto integrado de serviços:

• AgentCore Runtime hospeda agentes e ferramentas em ambientes isolados
• AgentCore Memory permite interações personalizadas
• AgentCore Identity e AgentCore Policy ajudam a fazer cumprir segurança
• AgentCore Observability oferece visibilidade
• AgentCore Evaluations permite avaliação contínua de qualidade
• AgentCore Gateway unifica comunicação entre agentes e ferramentas usando protocolos padrão
• AgentCore Browser oferece um navegador seguro baseado em nuvem que permite agentes interagir com websites
• AgentCore Code Interpreter permite agentes escrever e executar código mais seguramente em ambientes sandbox

Conclusão

Construir agentes de IA prontos para produção requer mais que conectar um modelo de fundação a APIs. Exige práticas de engenharia disciplinadas por todo o ciclo de vida: começar pequeno com um problema claramente definido, instrumentar tudo desde o primeiro dia, construir estratégia deliberada de ferramentas, automatizar avaliação, decompor complexidade com arquiteturas multi-agentes, dimensionar com segurança e personalização, combinar agentes com código determinístico, testar continuamente e construir capacidade organizacional com pensamento de plataforma.

A diferença entre agentes que impressionam em demonstrações e agentes que entregam valor de negócio está na execução consistente dessas fundamentações. Para aprender mais, verifique a documentação do Amazon Bedrock AgentCore e comece com exemplos de código e workshops práticos para começar e aprofundar seu conhecimento sobre AgentCore.

Fonte

AI agents in enterprises: Best practices with Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/ai-agents-in-enterprises-best-practices-with-amazon-bedrock-agentcore/)

Simplificando Gerenciamento de Arquivos na Nuvem com IA

Muitas organizações enfrentam desafios significativos ao gerenciar uploads de arquivos entre diferentes sistemas de armazenamento em nuvem, mantendo simultaneamente altos padrões de segurança e conformidade regulatória. Embora o Google Drive ofereça APIs para integração, a maioria das empresas não dispõe de especialistas técnicos capazes de interagir diretamente com essas interfaces programáticas complexas.

O problema real vai além da simples disponibilidade de APIs: as organizações precisam de uma forma intuitiva e acessível para que seus usuários realizem uploads de arquivos utilizando linguagem natural, sem necessidade de conhecimento especializado em sistemas subjacentes ou em especificações técnicas de programação.

Apresentando o Amazon Quick Suite

A AWS disponibiliza o Amazon Quick Suite, uma plataforma de IA empresarial que oferece capacidades avançadas alimentadas por IA generativa, focadas em produtividade no ambiente corporativo e inteligência de negócios. Esta plataforma integra pesquisa assistida por IA, recursos de inteligência de negócios e automação em um único espaço de trabalho, possibilitando desde responder perguntas e gerar conteúdo até analisar dados e fornecer insights estratégicos.

Para expandir suas funcionalidades além da simples busca de dados, o Amazon Quick Suite oferece conectores de ações — componentes poderosos que permitem interação com sistemas empresariais externos. Através desses conectores, os usuários conseguem executar ações e acessar informações de diversas ferramentas corporativas sem precisar sair da interface do Quick Suite.

Tipos de Conectores Disponíveis

A plataforma suporta três categorias principais de conectores: conectores para serviços externos, conectores para serviços AWS e conectores personalizados. Os conectores para serviços externos fornecem integrações prontas para uso com aplicações empresariais comuns, permitindo que as organizações implementem rapidamente funcionalidades padrão.

No entanto, quando surgem necessidades especializadas — como integração com Google Drive ou construção de fluxos de trabalho personalizados para upload de arquivos — o Amazon Quick Suite disponibiliza conectores personalizados. Essa abordagem permite que as organizações executem tarefas complexas através de simples comandos conversacionais, criando um espaço de trabalho unificado ao conectar várias ferramentas através de especificações OpenAPI, eliminando a necessidade de alternar constantemente entre interfaces diferentes.

Esta estratégia reduz significativamente as barreiras técnicas para as organizações, garantindo simultaneamente que mantenham controle completo sobre segurança e permissões de acesso.

Arquitetura da Solução

A proposta em questão demonstra como construir uma solução segura de upload de arquivos, integrando Google Drive com os conectores personalizados do Amazon Quick Suite usando Amazon API Gateway e AWS Lambda.

Essa abordagem resolve desafios comuns enfrentados pelas organizações ao gerenciar operações de arquivo entre sistemas de armazenamento em nuvem: manutenção de conformidade de segurança, gerenciamento de permissões de usuário e redução de barreiras técnicas para os usuários finais.

Componentes Principais

A solução integra diversos serviços AWS funcionando de forma coordenada:

• A interface de chat é construída usando o agente de chat do Amazon Quick Suite
• A autenticação de usuário é gerenciada pelo AWS IAM Identity Center, enquanto a autorização é tratada pelo Amazon Quick Suite e Amazon Cognito
• Ações relevantes são identificadas com base em consultas em linguagem natural dos usuários através dos conectores de ações do Amazon Quick Suite
• A plataforma utiliza as especificações OpenAPI configuradas de terceiros para determinar dinamicamente quais operações de API executar, atendendo à solicitação do usuário
• As chamadas de API são autorizadas usando um autorizador do Amazon Cognito, que emprega identidade federada do Google para autorização
• As APIs são implementadas através de API Gateway e funções Lambda
• A função Lambda contém a lógica para verificar se o usuário autorizado possui as permissões necessárias para fazer upload de arquivo na pasta mencionada na consulta, e chama o serviço Google usando credenciais de conta de serviço armazenadas no AWS Secrets Manager para realizar o upload do arquivo para Google Drive

Caso de Uso Prático

Embora este artigo se concentre no caso de uso de upload de arquivo para Google Drive, a mesma abordagem pode ser aplicada para fazer upload de arquivos para outros sistemas de armazenamento empresarial, como Amazon Simple Storage Service (Amazon S3), Box, Dropbox, SharePoint e outras plataformas semelhantes.

Um exemplo prático envolve fabricantes que utilizam o Amazon Quick Suite para fazer upload de arquivos de texto em uma unidade compartilhada no Google Drive. Esse tipo de integração permite que colaboradores executem operações de arquivo através de conversas naturais, sem necessidade de conhecimento técnico profundo.

Configuração Técnica Detalhada

Preparação do Ambiente Google

Para que a integração funcione adequadamente, é necessário primeiro configurar o ambiente Google Workspace. Isso envolve habilitar as APIs Google Drive e Admin SDK, criar uma conta de serviço com uma chave privada em formato JSON para acesso programático, e configurar delegação em todo o domínio. A delegação deve estar associada à ID do cliente da conta de serviço com escopos OAuth específicos que permitam acesso aos dados organizacionais no Google Drive.

Para fins de validação, cria-se dois usuários de teste no Google Workspace: um com permissão de gerenciador de conteúdo em uma unidade compartilhada (permitindo gerenciamento completo de arquivos) e outro sem nenhuma permissão. Essa configuração possibilita validar que a solução enforça corretamente os controles de acesso com base nas permissões do Google Drive.

Preparação do Ambiente AWS

No lado da AWS, criam-se usuários correspondentes no IAM Identity Center que combinam com os usuários de teste criados no Google Workspace. Organiza-se esses usuários em um grupo do IAM Identity Center para facilitar gerenciamento de permissões em escala empresarial, com opção de conectar a um provedor de identidade externo para provisionamento automatizado de usuários.

As credenciais da conta de serviço Google são armazenadas de forma segura no Secrets Manager, com políticas de Gerenciamento de Identidade e Acesso (Controle de Identidade e Acesso — IAM) restringindo o acesso apenas à função Lambda que realiza uploads de arquivo. Essa abordagem protege credenciais sensíveis, permite que a função Lambda autentique com as APIs do Google Drive e suporta uploads seguros em nome de usuários autorizados, seguindo práticas recomendadas de segurança da AWS para gerenciamento de segredos de aplicação.

Configuração do Amazon Quick Suite e Autenticação

Cria-se uma conta Amazon Quick Suite na edição Enterprise (requisito necessário para configurar ações personalizadas). A autenticação é configurada através do IAM Identity Center, e o grupo criado anteriormente é adicionado como grupo de administradores, com posterior verificação de que ambos os usuários conseguem acessar a plataforma com sucesso.

O Amazon Cognito é configurado para gerenciar identidades de usuário, com a criação de um pool de usuários e aplicativo cliente do tipo máquina-para-máquina. Um domínio Cognito é criado e configurado com interface hospedada, e o Google é adicionado como um provedor de identidade federada usando credenciais OAuth do Google Workspace. Os escopos autorizados são configurados como profile, email e openid, com mapeamento dos atributos do pool de usuários Cognito para os atributos correspondentes do Google.

Implementação da Função Lambda e API Gateway

A função Lambda é implantada com código que valida permissões de usuário, interage com a API do Google Drive e faz upload de arquivos para a pasta designada. As variáveis de ambiente são configuradas com a ID do pool de usuários Cognito, a região AWS, e o nome (ARN) do segredo do Secrets Manager contendo as credenciais da conta de serviço Google.

A API REST é criada usando a especificação OpenAPI, com a configuração apropriada de região e ARN da função Lambda. Um estágio é criado para a API com configurações apropriadas ao ambiente, e um autorizador Cognito é configurado, vinculado ao pool de usuários Cognito criado anteriormente, com escopos de autorização definidos como openid, email, profile e aws.cognito.signin.user.admin.

A política baseada em recursos da função Lambda é modificada para conceder permissão de invocação ao API Gateway para o método POST. A API é então implantada no estágio criado, e a URL do endpoint é registrada para uso posterior na configuração do Amazon Quick Suite.

Criação do Conector Personalizado do Amazon Quick Suite

Localiza-se o arquivo de esquema OpenAPI no repositório fornecido e substituem-se os valores de espaço reservado pela URL do API Gateway com o estágio, nome do domínio Cognito, região, ID do pool de usuários e ID do cliente de aplicativo Cognito.

Acessa-se a conta Quick Suite como um dos usuários de teste e navega-se até a seção de integrações para criar uma nova ação usando o tipo de conector personalizado com especificação OpenAPI. O arquivo de esquema modificado é enviado, e a integração é criada com método de autenticação de usuário, configurando a URL base do API Gateway (incluindo o nome do estágio), ID do cliente Cognito, segredo do cliente Cognito, URL de token Cognito e URL de autorização Cognito.

A integração é então compartilhada com o grupo do IAM Identity Center contendo os dois usuários de teste.

Agentes de Chat e Validação de Acesso

Criam-se agentes de chat personalizado ou utiliza-se o assistente padrão do Quick Suite, vinculando o conector de ação criado. O agente é compartilhado com os usuários de teste com as permissões apropriadas.

Para validação, testa-se a solução em dois cenários: primeiro, como um usuário com permissão de gerenciador de conteúdo, que consegue fazer upload bem-sucedido de arquivo para a unidade compartilhada; segundo, como um usuário sem permissão, que recebe mensagem de erro informando falta de acesso. Esses testes confirmam que a solução enforça corretamente os controles de acesso baseados nas permissões do Google Drive.

Benefícios e Casos de Aplicação

Essa abordagem oferece diversos benefícios significativos. Melhora a experiência do usuário ao permitir upload de arquivos para Google Drive através de prompts em linguagem natural, sem exigir conhecimento especializado sobre APIs subjacentes e sistemas complexos.

A segurança e conformidade são aprimoradas através da imposição de controles de acesso, permitindo apenas que usuários com permissões necessárias façam upload de arquivos para unidades compartilhadas, com permissões de arquivo gerenciadas através do Google Drive e do pool de usuários Cognito.

A complexidade operacional diminui ao abstrair integrações técnicas complexas com serviços de armazenamento em nuvem de terceiros, permitindo que as organizações focarem em entregar capacidades valiosas aos usuários.

Próximos Passos

Para implementar essa solução, as organizações podem consultar o repositório do GitHub fornecido pela AWS, que contém guias passo a passo completos, arquivos de configuração, código de exemplo e esquemas OpenAPI necessários para a implementação.

Após implantação, recomenda-se testar a solução com os cenários descritos para validar que os controles de acesso funcionam conforme esperado e que a experiência de usuário atende às expectativas organizacionais.

Conclusão

A integração do Google Drive com o Amazon Quick Suite através de conectores personalizados com especificações OpenAPI representa uma evolução importante na forma como as organizações podem simplificar operações de gerenciamento de arquivo. Ao combinar as capacidades de IA generativa do Amazon Quick Suite com serviços de nuvem enterprise como API Gateway, Lambda, Amazon Cognito e Secrets Manager, as empresas conseguem oferecer experiências de usuário intuitivas, mantendo altos padrões de segurança e conformidade.

A solução demonstra claramente que o futuro do gerenciamento de arquivo corporativo passa pela combinação de IA em linguagem natural com integrações seguras e controladas de terceiros, reduzindo barreiras técnicas enquanto mantém segurança robusta.

Fonte

Use Amazon Quick Suite custom action connectors to upload text files to Google Drive using OpenAPI specification (https://aws.amazon.com/blogs/machine-learning/use-amazon-quick-suite-custom-action-connectors-to-upload-text-files-to-google-drive-using-openapi-specification/)

Os desafios reais da análise de dados clínicos

Pesquisadores e epidemiologistas em saúde lidam com um paradoxo bem conhecido: possuem profundo conhecimento sobre padrões de doenças, cuidados ao paciente e resultados clínicos, mas enfrentam obstáculos técnicos enormes antes de responder uma única pergunta de pesquisa. A realidade é que essas profissionais gastam semanas navegando infraestruturas complexas de dados, escrevendo código repetitivo e resolvendo barreiras técnicas que pouco têm a ver com seu trabalho principal.

Este gargalo não é apenas uma inconveniência — ele atrasa decisões baseadas em evidências e pode impactar diretamente o cuidado ao paciente. Centros acadêmicos, laboratórios de pesquisa, instalações clínicas e organizações comerciais de saúde produzem volumes enormes de dados clínicos que deveriam ser explorados muito mais rapidamente.

Principais obstáculos na análise acelerada de dados em saúde

Dois desafios centrais travam a velocidade de pesquisa clínica:

Navegação em dados clínicos complexos: Os catálogos de dados em saúde usam terminologias médicas especializadas e sistemas de codificação que exigem expertise de domínio para serem compreendidos. Descobrir quais tabelas contêm coortes de pacientes específicas e entender como códigos de condições se mapeiam entre diferentes sistemas de classificação é uma barreira considerável antes que qualquer análise comece.

Preparação técnica para análise: Após localizar os dados, analistas de saúde passam tempo significativo escrevendo scripts Python ou PySpark para extrair coortes de pacientes, calcular métricas clínicas e executar análises estatísticas. Este ônus técnico é particularmente agudo porque pesquisadores clínicos são especialistas em epidemiologia ou bioestatística, não em engenharia de software.

A solução: SageMaker Data Agent com IA agnóstica

Em 21 de novembro de 2025, a AWS introduziu uma capacidade integrada no Amazon SageMaker que muda fundamentalmente essa equação. O SageMaker Data Agent funciona como um assistente de pesquisa inteligente dentro do Amazon SageMaker Unified Studio, com capacidade de compreender seu ambiente de dados específico e seus objetivos clínicos.

Quando um pesquisador faz uma pergunta como “Compare padrões de comorbidade entre coortes de pacientes diabéticos e hipertensos”, o agente de dados não apenas gera fragmentos de código. Ele pensa o problema de forma sistemática: cria um plano de análise com múltiplas etapas, identifica as tabelas clínicas relevantes, determina os métodos estatísticos apropriados, gera código validado na linguagem otimizada (SQL, Python ou PySpark) e executa cada passo com pontos de controle integrados para supervisão humana.

Como o Data Agent resolve os desafios

Navegação inteligente de dados clínicos: O SageMaker Data Agent está integrado ao AWS Glue Data Catalog e mapeia todo o seu panorama de dados de saúde. O agente compreende suas tabelas clínicas reais — demografias de pacientes, diagnósticos, encontros, condições, medicações, imunizações, procedimentos — pelos seus nomes verdadeiros e relacionamentos. Reconhece relacionamentos temporais entre encontros, entende como códigos de diagnóstico se estruturam e navega as hierarquias complexas de dados clínicos sem exigir memorização de esquemas de banco de dados.

Redução do esforço técnico: O agente transforma perguntas clínicas em linguagem natural em código analítico pronto para produção. Gera código otimizado em SQL para extração eficiente de coortes de pacientes, Python para análise estatística e PySpark para processamento de dados em larga escala — tudo sem exigir que o pesquisador dominie cada linguagem. Além disso, cria um plano de análise estruturado com múltiplas etapas que reflete como pesquisadores clínicos experientes abordam problemas: definição de coorte, depois características basais, depois comparação estatística e, por fim, visualização. Cada etapa inclui pontos de validação para o usuário revisar o processo do agente, assegurando validade clínica, tratamento apropriado de dados faltantes e uso de métodos estatisticamente apropriados.

Esta abordagem agnóstica desloca o tempo do pesquisador de preparação técnica para interpretação clínica — exatamente o inverso do que acontecia antes.

Segurança e governança integradas

O SageMaker Data Agent foi arquitetado para respeitar controles de segurança existentes. Ele opera de forma segura dentro de seu ambiente AWS, respeitando políticas de AWS Identity and Access Management (IAM) e limites de dados organizacionais. Isso ajuda sua organização a manter controles de segurança enquanto acelera análise clínica, assegurando conformidade com regulamentos de proteção de dados e governança.

Cenário de uso: análise de coorte clínica

Imagine uma epidemiologista em um centro médico acadêmico conduzindo análise detalhada de condições clínicas como sinusite, diabetes e hipertensão através de comparação de coortes e análise de sobrevida. Seu fluxo de trabalho tradicional envolve navegar múltiplos sistemas desconectados para localizar conjuntos de dados, aguardar aprovações de acesso, compreender esquemas de dados complexos e escrever código extenso em Python e PySpark — um processo de múltiplas semanas onde a maioria do tempo vai para preparação de dados em vez de análise clínica real.

Este gargalo limita pesquisadores a apenas 2-3 estudos abrangentes por trimestre, atrasando diretamente a geração de insights analíticos.

Dois modos de interação para flexibilidade

Painel do Agente para análise clínica abrangente: Ideal para projetos de pesquisa de ponta a ponta. Este modo divide perguntas complexas de saúde em etapas analíticas estruturadas com pontos de revisão intermediários, mantendo supervisão humana ao longo de todo o processo.

Assistência integrada para tarefas focadas: Ideal para pesquisadores experientes que desejam ajuda direcionada com desafios de codificação específicos, correção de erros ou melhorias de código, mantendo controle total de seu fluxo de trabalho.

Como começar: guia prático

Pré-requisitos e configuração

Para este exemplo, usa-se Synthea — uma ferramenta que gera dados sintéticos de pacientes em formato CSV, contendo informações sobre pacientes, condições, imunizações, alergias, encontros e procedimentos. A Synthea é um gerador sintético de pacientes de código aberto que modela o histórico médico de pacientes sintéticos. Nenhum dado humano real é usado neste processo.

Como parte da configuração do SageMaker, abra o console do SageMaker e escolha “Get started” para criar um domínio baseado em IAM e um projeto denominado ClinicalDataProject. Para instruções sobre como configurar um domínio baseado em IAM e criar um projeto, consulte a documentação sobre domínios e projetos baseados em IAM.

Explorando dados clínicos com SQL

Após configurar o ambiente, você pode visualizar dados usando SQL simples. No console do SageMaker, escolha “Open” e depois o projeto que criou. Será redirecionado para a página de visão geral do SageMaker Unified Studio. Escolha “Data” no painel de navegação e expanda AwsDataCatalog para visualizar os dados catalogados aos quais você tem acesso em sua conta.

Para este caso de uso, crie cada uma das tabelas (pacientes, condições, imunizações, alergias, encontros e procedimentos) sob sagemaker_sample_db usando os arquivos CSV gerados anteriormente. Antes de realizar a análise clínica complexa, execute uma consulta básica na tabela de condições:

select * from "AwsDataCatalog"."sagemaker_sample_db"."conditions" limit 10

Criando um notebook para análise detalhada

Para análise aprofundada, crie um notebook. Escolha “Notebooks” no painel de navegação e selecione “Create notebook”. Depois de criar o notebook, você pode interagir com os dados de duas formas:

• Codificar diretamente dentro de células do notebook usando a interface de prompt integrado. Por exemplo, digite “Code to find patient records in conditions table who suffer from Sinusitis” (Código para encontrar registros de pacientes na tabela de condições que sofrem de Sinusite), escolha “Generate code” e execute a célula para exibir os resultados.
• Usar o painel Data Agent, que suporta tarefas analíticas abrangentes dividindo-as em etapas estruturadas, cada uma com código gerado que se baseia em resultados anteriores.

Análise detalhada de dados clínicos com Data Agent

No painel Data Agent, insira a consulta: “Find top 20 conditions and perform a detailed analysis of patients with immunizations suffering from those conditions” (Encontre as 20 principais condições e realize análise detalhada de pacientes com imunizações sofrendo dessas condições) e gere o código.

O SageMaker Data Agent verifica o estado atual do notebook para compreender com quais dados você está trabalhando. Identifica as tabelas de condições, imunizações e pacientes no banco de dados sagemaker_sample_db. Prepara um plano abrangente e o lista para que você revise. Você pode revisar o plano, fazer alterações necessárias se needed e depois escolher “Run step-by-step”.

O agente escreve o código nas células do notebook. Você pode revisar o código e depois escolher “Accept and run”. Se algumas etapas falharem na execução, escolha “Fix with AI” para prosseguir. Quando a consulta for concluída, os resultados serão exibidos com visualizações incluindo análise demográfica de pacientes imunizados com as 20 principais condições, análise de prevalência de condições e análise temporal do aparecimento de condições.

Comparação de coorte e análise de sobrevida

Com a sinusite viral identificada como a condição principal, você pode realizar comparação de coorte e análise de sobrevida. Insira a seguinte consulta no painel Data Agent:

“Build two cohorts 1/ Cohort for Male patients who are suffering from viral sinusitis 2/ Cohort for Female patients who are suffering from viral sinusitis. Run a detailed cohort comparison and survival analysis.” (Construa duas coortes 1/ Coorte para pacientes do sexo masculino sofrendo de sinusite viral 2/ Coorte para pacientes do sexo feminino sofrendo de sinusite viral. Execute comparação detalhada de coorte e análise de sobrevida.)

O SageMaker Data Agent prepara um plano abrangente para criação de coorte, análise de comparação de coorte e análise de sobrevida. Revise o plano e escolha “Run step-by-step”. O resultado inclui gráficos de comparação demográfica entre coortes, curvas de Kaplan-Meier e gráficos cumulativos de eventos.

Limpeza de recursos

Para remover recursos criados durante este processo: primeiro, delete o projeto SageMaker Unified Studio navegando até o console, selecionando seu projeto da lista e escolhendo “Delete”. Segundo, remova recursos do AWS Glue Data Catalog abrindo o console do AWS Glue, navegando até “Databases” e deletando o banco de dados de exemplo. Terceiro, delete buckets S3 e dados abrindo o console do Amazon S3, localizando o bucket onde dados de saúde estão armazenados, esvaziando o conteúdo e deletando o bucket.

Por que isso importa para pesquisa em saúde

Com o SageMaker Data Agent alimentado por IA agnóstica, você vê seus conjuntos de dados acessíveis ao fazer login, valida qualidade de dados com visualizações rápidas e realiza análise através de prompts em linguagem natural — reduzindo esforço de codificação manual. O agente acelera sua capacidade de pesquisa, ajudando padrões de tratamento a serem identificados mais cedo.

Ao deslocar a vasta maioria do seu tempo de preparação de dados para análise real, o SageMaker Data Agent entrega descobertas de pesquisa mais eficientemente enquanto reduz custos de infraestrutura. As análises são documentadas em notebooks reproduzíveis que podem ser validadas e auditadas por stakeholders clínicos, suportando transparência enquanto acelera o caminho de dados para análise impactante.

Fonte

Agentic AI for healthcare data analysis with Amazon SageMaker Data Agent (https://aws.amazon.com/blogs/machine-learning/agentic-ai-for-healthcare-data-analysis-with-amazon-sagemaker-data-agent/)

Novos modelos de IA para casos de uso empresariais

A AWS anunciou recentemente a disponibilidade de três novos modelos de fundação no Amazon SageMaker JumpStart, expandindo significativamente o portfólio de soluções de inteligência artificial disponíveis aos clientes da plataforma. O anúncio traz o DeepSeek OCR, MiniMax M2.1 e Qwen3-VL-8B-Instruct, modelos especializados que abrangem capacidades em inteligência de documentos, codificação multilíngue, raciocínio multimodal avançado e compreensão visão-linguagem.

Esses três modelos foram desenvolvidos para resolver diferentes desafios de inteligência artificial em ambientes corporativos, oferecendo capacidades especializadas que permitem aos clientes construir aplicações sofisticadas sobre a infraestrutura da AWS.

Capacidades técnicas de cada modelo

DeepSeek OCR: Processamento inteligente de documentos

O modelo DeepSeek OCR explora a compressão de elementos visuais e textuais, direcionado especialmente para processamento de documentos. Sua funcionalidade permite extrair informações estruturadas de formulários, faturas, diagramas e documentos complexos com layouts de texto denso, facilitando a automação de processos documentais em escala.

MiniMax M2.1: Desenvolvimento de software e automação

O MiniMax M2.1 foi otimizado para codificação, uso de ferramentas, seguimento de instruções e planejamento em múltiplos passos. O modelo automatiza desenvolvimento de software multilíngue e executa fluxos de trabalho de escritório complexos e com múltiplas etapas, permitindo que desenvolvedores criem aplicações autônomas mais sofisticadas.

Qwen3-VL-8B-Instruct: Compreensão avançada multimodal

O Qwen3-VL-8B-Instruct oferece compreensão e geração superior de texto, percepção visual mais profunda e capacidade de raciocínio, comprimento de contexto estendido, e compreensão aprimorada de dinâmicas espaciais e de vídeo, além de capacidades mais fortes de interação com agentes.

Como começar

O SageMaker JumpStart permite que clientes da AWS implantem qualquer um desses modelos com apenas alguns cliques, endereçando casos de uso específicos de inteligência artificial. Para começar a usar esses modelos, basta acessar o catálogo de modelos do SageMaker JumpStart no console do SageMaker ou utilizar o SDK em Python do SageMaker para implantar os modelos na sua conta AWS.

Para obter mais informações sobre como implantar e usar modelos de fundação no SageMaker JumpStart, consulte a documentação do Amazon SageMaker JumpStart.

Fonte

DeepSeek OCR, MiniMax M2.1, and Qwen3-VL-8B-Instruct models are now available on SageMaker JumpStart (https://aws.amazon.com/about-aws/whats-new/2026/01/new-models-on-sagemaker-jumpstart)

Resolvendo desafios de escalabilidade em aplicações de IA

Construir aplicações de inteligência artificial com o Amazon Bedrock frequentemente apresenta desafios significativos relacionados ao throughput, impactando diretamente a capacidade de escala dos seus sistemas. A inferência global cross-region na região af-south-1 da AWS modifica esse cenário.

Agora é possível invocar modelos a partir da região de Cape Town enquanto o Amazon Bedrock automaticamente roteia requisições para regiões que possuem capacidade disponível. O resultado é que suas aplicações mantêm tempos de resposta consistentes, seus usuários experimentam confiabilidade, e seus logs centralizados no Amazon CloudWatch e AWS CloudTrail permanecem organizados em um único local.

Acesso aos modelos Claude 4.5 com maior throughput

A inferência cross-region global com os modelos Anthropic Claude Sonnet 4.5, Haiku 4.5 e Opus 4.5 no Amazon Bedrock agora está disponível na região de Cape Town. Clientes sul-africanos podem utilizar perfis de inferência global para acessar esses modelos com throughput melhorado e maior resiliência.

A inferência cross-region global roteia requisições para regiões comerciais suportadas em todo o mundo, otimizando recursos e possibilitando maior throughput — particularmente valioso durante períodos de pico. O recurso é compatível com cache de prompts do Amazon Bedrock, inferência em lote, Guardrails do Amazon Bedrock, Bases de Conhecimento do Amazon Bedrock e muito mais.

Compreendendo a inferência cross-region

A inferência cross-region é um recurso poderoso que organizações podem utilizar para distribuir processamento de inferência perfeitamente entre múltiplas regiões. Essa capacidade permite alcançar maior throughput ao construir em escala, permitindo que aplicações de IA generativa permaneçam responsivas e confiáveis mesmo sob carga pesada.

Um perfil de inferência no Amazon Bedrock define um modelo de fundação (FM) e uma ou mais regiões para as quais pode rotear requisições de invocação. Os perfis de inferência funcionam em torno de dois conceitos principais:

• Região de Origem: A região de onde a requisição de API é feita
• Região de Destino: Uma região para a qual o Amazon Bedrock pode rotear a requisição para inferência

A inferência cross-region opera através da rede segura da AWS com criptografia de ponta a ponta tanto para dados em trânsito quanto em repouso. Quando um cliente submete uma requisição de inferência a partir de uma região de origem, a inferência cross-region roteia inteligentemente a requisição para uma das regiões de destino configuradas no perfil de inferência através da rede gerenciada pelo Bedrock.

Uma distinção importante: enquanto o processamento de inferência (o cálculo transitório) pode ocorrer em outra região, dados em repouso — incluindo logs, bases de conhecimento e configurações armazenadas — foram projetados para permanecer em sua região de origem. As requisições viajam pela Rede Global da AWS gerenciada pelo Bedrock. Os dados transmitidos durante a inferência cross-region são criptografados e permanecem dentro da rede segura da AWS.

Dois modelos de inferência cross-region

A AWS oferece dois tipos de perfis de inferência cross-region:

• Inferência cross-region geográfica: O Amazon Bedrock seleciona automaticamente a região comercial ótima dentro de uma geografia definida (Estados Unidos, Europa, Austrália e Japão) para processar sua requisição de inferência. Recomendado para casos de uso com requisitos de residência de dados.
• Inferência cross-region global: A inferência cross-region global aprimoura ainda mais esse recurso ao permitir o roteamento de requisições de inferência para regiões comerciais suportadas em todo o mundo, otimizando recursos disponíveis e possibilitando maior throughput de modelo. Recomendado para casos de uso sem requisitos rígidos de residência de dados.

Monitoramento e registro centralizado

Com a inferência cross-region global a partir de af-south-1, suas requisições podem ser processadas em qualquer lugar na infraestrutura global da AWS. No entanto, seus logs do Amazon CloudWatch e AWS CloudTrail são registrados em af-south-1, simplificando o monitoramento ao manter seus registros em um único local.

Segurança de dados e conformidade regulatória

Segurança e conformidade representam uma responsabilidade compartilhada entre a AWS e cada cliente. A inferência cross-region global foi projetada para manter a segurança de dados. Dados transmitidos durante a inferência cross-region são criptografados pelo Amazon Bedrock e permanecem dentro da rede segura da AWS.

Informações sensíveis permanecem protegidas durante todo o processo de inferência, independentemente da região que processa a requisição. Os clientes são responsáveis por configurar suas aplicações e políticas de Gerenciamento de Identidade e Acesso da AWS (IAM) apropriadamente e por avaliar se a inferência cross-region global atende seus requisitos específicos de segurança e conformidade.

Como a inferência cross-region global roteia requisições para regiões comerciais suportadas mundialmente, você deve avaliar se essa abordagem está alinhada com suas obrigações regulatórias, incluindo a Lei de Proteção de Informações Pessoais (POPIA) e outros requisitos específicos do setor. Recomenda-se consultar suas equipes de compliance e jurídica para determinar a abordagem apropriada para seus casos de uso específicos.

Implementando a inferência cross-region global

Para utilizar a inferência cross-region global com modelos Claude 4.5, desenvolvedores devem completar os seguintes passos principais:

• Usar o ID do perfil de inferência global — Ao fazer chamadas de API para o Amazon Bedrock, especifique o ID do perfil de inferência do modelo Claude 4.5 global (por exemplo, global.anthropic.claude-opus-4-5-20251101-v1:0). Funciona com as APIs InvokeModel e Converse.
• Configurar permissões IAM — Conceda permissões IAM para acessar o perfil de inferência e FMs nas regiões de destino potenciais. Na próxima seção, fornecemos mais detalhes. Você também pode consultar mais informações sobre pré-requisitos para perfis de inferência.

Implementar a inferência cross-region global com modelos Claude 4.5 é simples, exigindo apenas algumas alterações no código de sua aplicação existente. O seguinte é um exemplo de como atualizar seu código em Python:

import boto3
import json

# Connect to Bedrock from your deployed region
bedrock = boto3.client('bedrock-runtime', region_name='af-south-1')

# Use global cross-Region inference inference profile for Opus 4.5 model
model_id = "global.anthropic.claude-opus-4-5-20251101-v1:0"

# Make request - Global CRIS automatically routes to optimal AWS Region globally
response = bedrock.converse(
    messages=[
        {
            "role": "user",
            "content": [{"text": "Explain cloud computing in 2 sentences."}]
        }
    ],
    modelId=model_id,
)

print("Response:", response['output']['message']['content'][0]['text'])
print("Token usage:", response['usage'])
print("Total tokens:", response['usage']['totalTokens'])

Se estiver utilizando a API InvokeModel do Amazon Bedrock, você pode rapidamente alternar entre diferentes modelos mudando o ID do modelo, como mostrado em exemplos de código para invocar modelos.

Requisitos de política IAM para inferência cross-region global

A inferência cross-region global requer três permissões específicas porque o mecanismo de roteamento se estende por múltiplos escopos: seu perfil de inferência regional, a definição de FM em sua região de origem e a definição de FM em nível global. Sem essas três, o serviço não consegue resolver o modelo, validar seu acesso e rotear requisições entre regiões.

O acesso a modelos Anthropic requer uma submissão de caso de uso antes de invocar um modelo. Essa submissão pode ser completada no nível da conta individual ou centralmente através da conta de gerenciamento da organização. Para submeter seu caso de uso, use a API PutUseCaseForModelAccess ou selecione um modelo Anthropic no catálogo de modelos no Console de Gerenciamento da AWS para Amazon Bedrock.

Permissões do AWS Marketplace são necessárias para ativar modelos e podem ser limitadas a IDs de produto específicos quando suportado. A seguinte política IAM fornece controle granular:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "GrantGlobalCrisInferenceProfileRegionAccess",
    "Effect": "Allow",
    "Action": "bedrock:InvokeModel",
    "Resource": [
      "arn:aws:bedrock:af-south-1::inference-profile/global."
    ],
    "Condition": {
      "StringEquals": {
        "aws:RequestedRegion": "af-south-1"
      }
    }
  }, {
    "Sid": "GrantGlobalCrisInferenceProfileInRegionModelAccess",
    "Effect": "Allow",
    "Action": "bedrock:InvokeModel",
    "Resource": [
      "arn:aws:bedrock:af-south-1::foundation-model/"
    ],
    "Condition": {
      "StringEquals": {
        "aws:RequestedRegion": "af-south-1",
        "bedrock:InferenceProfileArn": "arn:aws:bedrock:af-south-1::inference-profile/global."
      }
    }
  }, {
    "Sid": "GrantGlobalCrisInferenceProfileGlobalModelAccess",
    "Effect": "Allow",
    "Action": "bedrock:InvokeModel",
    "Resource": [
      "arn:aws:bedrock:::foundation-model/ "
    ],
    "Condition": {
      "StringEquals": {
        "aws:RequestedRegion": "unspecified",
        "bedrock:InferenceProfileArn": "arn:aws:bedrock:af-south-1::inference-profile/global."
      }
    }
  } ]
}

A política compreende três partes. A primeira declaração concede acesso ao perfil de inferência regional em af-south-1, para que usuários possam invocar o perfil de inferência cross-region global especificado a partir da África do Sul. A segunda declaração fornece acesso ao recurso regional de FM, que o serviço precisa para compreender qual modelo está sendo solicitado no contexto regional. A terceira declaração concede acesso ao recurso de FM global, que permite que o roteamento cross-region funcione.

Ao implementar essas políticas, verifique que os três ARNs estejam inclusos:

• O ARN do perfil de inferência regional segue o padrão arn:aws:bedrock:af-south-1::inference-profile/global.. Isso concede acesso ao perfil de inferência global em sua região de origem.
• O FM regional usa arn:aws:bedrock:af-south-1::foundation-model/. Isso concede acesso à definição de modelo em af-south-1.
• O FM global requer arn:aws:bedrock:::foundation-model/. Isso concede acesso ao modelo entre regiões — observe que esse ARN intencionalmente omite os segmentos de região e conta para permitir roteamento cross-region.

Nota importante sobre Políticas de Controle de Serviço (SCPs): Se sua organização usa SCPs específicas por região, verifique que "aws:RequestedRegion": "unspecified" não está incluída na lista de regiões negadas, porque requisições de inferência cross-region global utilizam esse valor de região. Organizações que utilizam SCPs restritivas que negam múltiplas regiões exceto aquelas especificamente aprovadas precisarão permitir explicitamente esse valor para habilitar a funcionalidade de inferência cross-region global.

Se sua organização determinar que a inferência cross-region global não é apropriada para certos cargas de trabalho por requisitos de residência de dados ou conformidade, você pode desabilitá-la de duas maneiras:

• Remover permissões IAM: Remova uma ou mais das três declarações de política IAM necessárias. Como a inferência cross-region global requer as três declarações para funcionar, remover uma delas causa requisições ao perfil de inferência global retornem um erro de acesso negado.
• Implementar uma política de negação explícita: Crie uma política de negação que segmente especificamente perfis de inferência cross-region global usando a condição "aws:RequestedRegion": "unspecified". Essa abordagem documenta claramente sua intenção de segurança, e a negação explícita tem precedência mesmo se políticas de permissão forem acidentalmente adicionadas depois.

Solicitando aumento de limites para inferência cross-region global

Ao utilizar perfis de inferência cross-region global a partir de af-south-1, você pode solicitar aumentos de cota através do Console de Cotas de Serviço da AWS. Como esse é um limite global, requisições devem ser feitas em sua região de origem (af-south-1).

Antes de solicitar um aumento, calcule sua cota necessária utilizando a taxa de redução para seu modelo. Para Sonnet 4.5 e Haiku 4.5, tokens de saída têm uma taxa de redução de cinco vezes — cada token de saída consome 5 tokens de sua cota — enquanto tokens de entrada mantêm uma proporção de 1:1. Seu consumo total de tokens por requisição é:

Contagem de tokens de entrada + Tokens de entrada de escrita em cache + (Contagem de tokens de saída x Taxa de redução)

Para solicitar um aumento de limite:

• Faça login no Console de Cotas de Serviço da AWS em af-south-1
• No painel de navegação, escolha Serviços da AWS
• Localize e escolha Amazon Bedrock
• Pesquise pelas cotas específicas de inferência cross-region global (por exemplo, Tokens de inferência de modelo cross-region global por minuto para Claude Sonnet 4.5 V1)
• Selecione a cota e escolha Solicitar aumento no nível da conta
• Digite seu valor de cota desejado e envie a solicitação

Próximos passos

A inferência cross-region global também traz a família de modelos Claude 4.5 para a região de Cape Town, oferecendo acesso às mesmas capacidades disponíveis em outras regiões. Você pode construir com Sonnet 4.5, Haiku 4.5 e Opus 4.5 a partir de sua região local enquanto a infraestrutura de roteamento gerencia a distribuição transparentemente.

Para começar, atualize suas aplicações para utilizar o ID do perfil de inferência global, configure permissões IAM apropriadas, e monitore o desempenho conforme suas aplicações utilizam a infraestrutura global da AWS. Visite o console do Amazon Bedrock e explore como a inferência cross-region global pode aprimorar suas aplicações de IA.

Para mais informações, consulte os seguintes recursos:

• Aumentar throughput com inferência cross-region
• Regiões e modelos suportados para perfis de inferência
• Usar um perfil de inferência em invocação de modelo

Fonte

Scale AI in South Africa using Amazon Bedrock global cross-Region inference with Anthropic Claude 4.5 models (https://aws.amazon.com/blogs/machine-learning/scale-ai-in-south-africa-using-amazon-bedrock-global-cross-region-inference-with-anthropic-claude-4-5-models/)