A AWS anunciou que o Amazon SageMaker Feature Store passou a oferecer suporte ao SageMaker Python SDK v3. A atualização chega acompanhada de duas capacidades relevantes: integração com controles de acesso do Lake Formation e suporte à configuração de propriedades de tabelas Apache Iceberg.
Para quem não conhece, o Feature Store é um repositório totalmente gerenciado pela AWS para armazenar, compartilhar e gerenciar features — ou seja, as variáveis e atributos utilizados no treinamento de modelos de aprendizado de máquina (ML). Com essa atualização, cientistas de dados passam a contar com interfaces mais modernas e modulares para administrar seus grupos de features.
Principais capacidades da atualização
SDK v3 com fluxos de trabalho simplificados
Com o SDK v3, a AWS promete fluxos de trabalho mais diretos e com menos código repetitivo (boilerplate) para o gerenciamento de grupos de features. A proposta é tornar o dia a dia do cientista de dados mais produtivo, aproveitando as interfaces modernas e modulares da nova versão do SDK.
Controle de acesso com Lake Formation
A integração com o Lake Formation permite que equipes apliquem controles de acesso em nível de coluna e de linha sobre os dados armazenados no offline store. Essa configuração é feita por meio de uma opção disponível no momento de criação do grupo de features. Na prática, isso significa que é possível restringir quais usuários ou processos têm acesso a determinados campos ou registros dos dados de features — um recurso importante para cenários com dados sensíveis ou regulados. Para saber mais sobre essa funcionalidade, a AWS disponibiliza a documentação de controles de acesso do Lake Formation.
Propriedades de tabelas Iceberg
O suporte ao Apache Iceberg permite que cientistas de dados configurem propriedades adicionais das tabelas diretamente pelo SDK — como compactação de dados e expiração de snapshots. Essas configurações têm impacto direto na performance de consultas e na otimização do espaço de armazenamento offline. A documentação de gerenciamento de metadados Iceberg traz os detalhes para quem quiser explorar essa funcionalidade.
Por que isso importa
O ponto central dessa atualização é a consolidação: antes, gerenciar controle de acesso e otimização de armazenamento poderia exigir ferramentas separadas. Agora, a AWS centraliza essas operações dentro do próprio SDK v3, reduzindo a complexidade operacional para as equipes de dados.
Disponibilidade e como começar
As novas capacidades estão disponíveis em todas as regiões da AWS onde o Amazon SageMaker Feature Store já está presente. Para utilizá-las, basta instalar a versão SageMaker Python SDK v3.8.0 ou superior.
O problema clássico do ovo e da galinha no processamento de documentos
Quem já trabalhou com Processamento Inteligente de Documentos (IDP) conhece bem o dilema inicial: antes de extrair informações de documentos, você precisa de um schema que defina o que deve ser extraído. Mas como criar esses schemas quando você tem milhares de documentos sem saber quais tipos existem na coleção? Fazer isso manualmente, em escala, consome tempo e recursos consideráveis, tornando difícil justificar o investimento em iniciativas de IDP.
Para resolver exatamente esse problema, a AWS apresentou a funcionalidade de descoberta multi-documento no IDP Accelerator. Ela atua como uma etapa de pré-processamento automatizada, analisando documentos desconhecidos, agrupando-os por tipo e gerando schemas prontos para uso.
O que é o IDP Accelerator
O IDP Accelerator é uma solução escalável, serverless e de código aberto para processamento automatizado de documentos e extração de informações. Para configurá-lo para tipos específicos de documentos, é necessário um arquivo de configuração que define as classes e os campos a serem extraídos. Um exemplo mínimo está disponível no repositório GitHub do IDP Accelerator.
O IDP Accelerator já contava com um Módulo de Descoberta capaz de gerar uma configuração de classe a partir de um único documento de exemplo. O problema é que esse recurso exige que o usuário já conheça as classes de documentos e consiga identificar um exemplo representativo para cada uma. A nova funcionalidade multi-documento remove esse pré-requisito, acelerando o caminho para aplicar o IDP Accelerator a coleções de documentos sem rótulo.
Como a solução funciona
A nova funcionalidade está integrada ao Módulo de Descoberta existente como uma capacidade “Múltiplos Documentos”, ao lado da opção “Documento Único” já disponível. A orquestração é feita por uma máquina de estados do AWS Step Functions e por funções do AWS Lambda para computação serverless.
Os documentos são processados a partir de um bucket do Amazon Simple Storage Service (Amazon S3) ou de um arquivo Zip enviado diretamente. Os modelos disponíveis pelo Amazon Bedrock geram os schemas, que são automaticamente integrados ao arquivo de configuração do IDP Accelerator.
O fluxo completo acontece em três grandes etapas: geração de embeddings, agrupamento de documentos e geração agêntica de schemas — com uma etapa adicional de análise e reflexão ao final.
Detalhes técnicos do pipeline
Geração de embeddings
O processo começa convertendo cada documento em um embedding vetorial — uma representação numérica das características visuais do documento. Para documentos com múltiplas páginas, apenas a primeira página é utilizada.
A solução usa embeddings visuais em vez de texto extraído por OCR (Reconhecimento Óptico de Caracteres). A razão é que embeddings visuais capturam layout, formatação e pistas estruturais que distinguem tipos de documentos mesmo quando o conteúdo textual é semelhante. O modelo padrão adotado é o Cohere Embed v4, disponível pelo Amazon Bedrock. A etapa de embedding já trata automaticamente questões como compressão de imagem, lógica de retry e controle de taxa de requisições.
Agrupamento de documentos
Com os embeddings gerados, a solução precisa descobrir quantos tipos de documentos existem na coleção. Para isso, utiliza o silhouette score (pontuação de silhueta), uma métrica que mede o quão bem separados estão os grupos entre si e o quão compactos são os documentos dentro de cada grupo.
Usando o algoritmo k-means, o sistema testa valores de k (número de grupos) de 2 a 20 por padrão e seleciona o agrupamento com a maior pontuação de silhueta. Para garantir grupos significativos, cada cluster precisa ter pelo menos dois documentos. Se necessário, o limite superior de k é reduzido abaixo de 20 para satisfazer essa restrição.
Validação da abordagem de embeddings e clustering
Para validar a abordagem, a AWS realizou experimentos com o Cohere Embed v4 sobre um subconjunto do dataset OCR-benchmark, disponível no bucket de conjunto de testes implantado com o stack CloudFormation do IDP Accelerator. Esse subconjunto contém 293 documentos distribuídos em 9 tipos: cheque bancário, contrato de locação comercial, extrato de cartão de crédito, nota de entrega, inspeção de equipamento, glossário, formulário de petição, imóvel e escala de turnos.
O objetivo era verificar se o k-means conseguia identificar corretamente esses agrupamentos usando o modelo de embedding. O resultado foi expressivo: a maior pontuação de silhueta ocorreu exatamente em k=9, correspondendo ao número real de tipos de documentos no dataset.
Para visualizar os resultados, foi gerado um gráfico t-SNE (Incorporação de Vizinhos Estocásticos Distribuídos em t — t-SNE), uma técnica de visualização que reduz dados de alta dimensionalidade para um espaço bidimensional preservando as relações entre os pontos. O gráfico mostrou os clusters claramente separados, cada um correspondendo a um tipo de documento.
O agrupamento atingiu um Índice Rand Ajustado (ARI) e uma Informação Mútua Normalizada (NMI) perfeitos, ambos com valor 1.0. O ARI mede o quão bem o agrupamento corresponde aos grupos reais, enquanto o NMI quantifica a informação compartilhada entre os clusters previstos e os reais. Cada cluster mapeou um-para-um para uma classe de documento real com 100% de pureza.
Esses resultados demonstram que embeddings multimodais de alta qualidade permitem classificação de documentos totalmente não supervisionada — sem nenhum dado de treinamento rotulado. Vale ressaltar, porém, que o desempenho nesse dataset de benchmark não garante resultados similares em outras coleções de documentos, pois as características específicas de cada dataset influenciam diretamente a qualidade dos resultados.
Geração agêntica de schemas
Após a identificação dos clusters, o pipeline entra na fase agêntica. Para cada cluster, um Strands Agent é invocado para determinar o tipo de documento e gerar um schema. A escolha pelo Strands Agents se deve à abordagem orientada pelo modelo, que oferece ao LLM a flexibilidade de raciocinar autonomamente sobre cada schema.
O agente precisa visualizar documentos em diferentes posições dentro do cluster para capturar toda a variedade antes de gerar o schema — por exemplo, um documento próximo ao centro, um na periferia e um a distância intermediária. Uma abordagem determinística e fixa de amostragem não funcionaria aqui, pois a qualidade do agrupamento depende fortemente dos documentos específicos de cada coleção.
Para isso, o agente conta com duas ferramentas especializadas:
Ferramenta de Análise de Cluster — Recupera IDs de documentos ordenados por distância do centróide do cluster, permitindo que o agente amostre estrategicamente ao longo do espectro de variação dentro do cluster.
Ferramenta de Visualização de Documento — Busca e comprime imagens de documentos para inspeção visual, tratando automaticamente as restrições de tamanho para a janela de contexto do modelo.
O prompt de sistema do agente incorpora conhecimento de domínio sobre convenções de JSON Schema e requisitos da configuração do IDP Accelerator. O agente é instruído a:
Amostrar documentos estrategicamente, parando cedo se já tiver cobertura suficiente.
Gerar JSON Schemas com metadados adequados, definições de tipo e descrições.
Incluir anotações específicas do IDP Accelerator como x-aws-idp-document-type e x-aws-idp-evaluation-method. O campo x-aws-idp-evaluation-method é utilizado pela extensão de avaliação baseada no Stickler.
Criar definições reutilizáveis ($defs) para estruturas comuns como endereços, itens de linha e informações fiscais.
Aplicar métodos de avaliação adequados conforme o tipo de campo: EXACT para strings, NUMERIC_EXACT para números e LLM para objetos complexos ou aninhados.
Os agentes rodam em paralelo, então não é necessário esperar que um cluster termine para o próximo começar.
Análise e reflexão dos schemas
Após cada agente gerar seu schema de forma independente, uma etapa de análise avalia a diferenciação entre os resultados. Ela verifica se os agrupamentos descobertos estão bem separados ou se há sobreposições, e se os schemas gerados são completos e consistentes. O sistema identifica redundâncias ou duplicações entre tipos de documentos e apresenta recomendações concretas, como mesclar clusters ou refinar definições de campos. O resultado final é um relatório de qualidade com uma visão geral legível das classes identificadas, visível nos detalhes do job de descoberta no IDP Accelerator.
Como executar a descoberta multi-documento
Passo 1: Criar uma nova configuração
Acesse a seção de Configuração no console do IDP Accelerator e selecione Visualizar/Editar Configuração. Escolha Schema de Documento > Limpar Tudo para criar uma configuração vazia. Em seguida, selecione Salvar como Versão, forneça um nome descritivo e confirme.
Passo 2: Executar a descoberta multi-documento
Com a configuração criada, acesse a seção de Descoberta e selecione a opção Múltiplos Documentos. Escolha a versão de configuração recém-criada e configure a fonte de documentos: selecione Caminho S3 ou Upload Zip, escolha o bucket de origem e especifique o prefixo S3 onde os documentos estão armazenados. Os documentos precisam estar em um dos buckets existentes do IDP Accelerator (Discovery Bucket, Test Bucket ou Input Bucket) para usar a opção de bucket de origem. Clique em Iniciar Descoberta para acionar a máquina de estados.
Passo 3: Monitorar o job e visualizar os resultados
Uma nova entrada aparecerá na tabela de jobs de Descoberta Multi-Documento, mostrando o status de execução, a etapa atual e metadados. Após a conclusão, acesse os detalhes do job para visualizar o Relatório de Qualidade. As classes descobertas e seus schemas JSON são automaticamente integrados ao arquivo de configuração.
Boas práticas para melhores resultados
Antes de executar o job de descoberta multi-documento em larga escala, vale considerar algumas recomendações:
Como o workflow processa apenas a primeira página de cada PDF, certifique-se de que os arquivos de entrada sejam documentos individuais. Pacotes com múltiplos documentos ainda não são suportados.
Após obter os resultados iniciais, revise o relatório de qualidade com cuidado para identificar problemas como clusters sobrepostos ou distribuições desiguais de documentos antes de finalizar os schemas.
Se a qualidade dos schemas for inconsistente entre clusters, verifique se a coleção tem uma distribuição muito desigual de tipos de documentos. Executar o job em um subconjunto mais balanceado pode ajudar o agente a produzir clusters e schemas mais confiáveis.
Próximos passos após a descoberta
O que fazer depois depende do que o workflow encontrou nos documentos:
Schemas limpos e baixa sobreposição no relatório: o caminho está livre para executar o IDP em escala. Os schemas já estão automaticamente adicionados ao campo de classes do arquivo de configuração do IDP Accelerator.
Relatório indicou clusters sobrepostos: revise as recomendações e use-as para refinar os schemas gerados, o que pode incluir mesclar schemas similares em uma única classe ou ajustar definições de campos para reduzir sobreposição.
Qualidade inconsistente entre clusters: verifique a distribuição dos tipos de documentos na coleção e considere executar o job em um subconjunto mais balanceado.
Conclusão
A funcionalidade de descoberta multi-documento resolve um desafio clássico no processamento de documentos: você precisa de schemas para processar documentos, mas precisa processar documentos para construir schemas. A solução combina embeddings visuais, agrupamento automático e geração agêntica de schemas com LLMs multimodais, transformando uma coleção opaca de documentos desconhecidos em classes e schemas estruturados, prontos para revisão humana.
A AWS anunciou a disponibilidade da revisão de código em repositório completo, uma nova capacidade do AWS Security Agent. O recurso realiza uma análise de segurança profunda e sensível ao contexto de toda a base de código de uma aplicação — e representa uma mudança significativa em relação às abordagens tradicionais de análise estática.
Por que isso é diferente das ferramentas tradicionais
Ferramentas convencionais de análise estática funcionam comparando o código contra padrões conhecidos de vulnerabilidades. O novo recurso do AWS Security Agent vai além: ele raciocina sobre a arquitetura da aplicação, os limites de confiança e os fluxos de dados para identificar vulnerabilidades sistêmicas que ferramentas baseadas em padrões simplesmente não conseguem detectar.
Em termos práticos, isso significa que o scanner consegue enxergar problemas que só aparecem quando se analisa o sistema como um todo — e não apenas trechos isolados de código.
Correções vinculadas ao arquivo e à linha exata
Quando uma vulnerabilidade é identificada, o AWS Security Agent não apenas aponta o problema: ele gera uma correção de código específica, vinculada ao arquivo e à linha exata onde o problema foi encontrado. Isso permite que as equipes identifiquem e corrijam vulnerabilidades de segurança com muito mais agilidade do que antes.
Disponibilidade e custo durante o preview
O recurso está disponível em todas as regiões da AWS onde o AWS Security Agent já opera. Durante o período de preview, ele está disponível sem custo adicional para clientes existentes do AWS Security Agent.
A AWS destaca que está priorizando o acesso antecipado gratuito para clientes, com o objetivo de dar aos defensores a oportunidade de fortalecer suas bases de código e compartilhar aprendizados que beneficiem toda a indústria.
O contexto mais amplo: IA e cibersegurança
A própria AWS reconhece que as capacidades de cibersegurança baseadas em IA estão evoluindo rapidamente. O AWS Security Agent já é capaz de encontrar vulnerabilidades e construir exploits funcionais em uma escala e velocidade sem precedentes. Esse cenário reforça a importância de colocar essas ferramentas nas mãos dos defensores antes que agentes maliciosos as utilizem.
Análise de segurança que raciocina como um pesquisador humano
A AWS anunciou a disponibilidade em prévia de uma nova capacidade do AWS Security Agent: a revisão completa de repositório de código. A funcionalidade realiza uma análise de segurança profunda e contextual de toda a base de código de uma aplicação, indo muito além do que as ferramentas tradicionais de Teste Estático de Segurança de Aplicação (SAST) conseguem fazer.
O diferencial central está na abordagem: em vez de simplesmente comparar trechos de código contra uma lista de padrões conhecidos de vulnerabilidade, o sistema constrói um modelo de segurança da aplicação inteira — mapeando pontos de entrada, fronteiras de confiança, fluxos de dados e lógica de autorização — e raciocina sobre o comportamento real do sistema, da mesma forma que um pesquisador de segurança experiente faria, mas operando na velocidade de uma máquina.
O problema que a ferramenta resolve
Times de desenvolvimento enfrentam uma tensão constante: as ferramentas SAST tradicionais são rápidas e confiáveis para capturar padrões conhecidos — como uma injeção de SQL, uma saída sem escape ou uma credencial codificada diretamente no código. Mas aplicações modernas são sistemas complexos, compostos por serviços, APIs, fronteiras de confiança e lógica de autorização distribuída.
As vulnerabilidades mais perigosas raramente são violações de uma única linha. Elas costumam ser lacunas sistêmicas: uma função de validação que cobre quatro de cinco casos, um endpoint que não tem a anotação de autorização que todos os seus vizinhos têm, ou uma codificação aplicada em um contexto mas esquecida em outro. Revisões manuais de segurança conseguem encontrar esses problemas, mas são caras, lentas e não acompanham o ritmo do desenvolvimento moderno.
A revisão completa de repositório foi construída exatamente para fechar essa lacuna — funcionando como um pesquisador de segurança automatizado que lê e raciocina sobre todo o repositório, e não apenas sobre linhas ou arquivos isolados.
Como funciona: quatro etapas de análise
A funcionalidade opera em quatro estágios que espelham a forma como um engenheiro de segurança experiente conduz uma avaliação.
1. Criação do perfil da aplicação
O scanner começa lendo o repositório completo e construindo um modelo de segurança da aplicação. Esse modelo inclui pontos de entrada, fronteiras de confiança, fluxos de dados, invariantes de autorização e as defesas já existentes. Todos os arquivos-fonte são considerados, tornando as decisões de cobertura explícitas em vez de implícitas. O resultado é uma compreensão estruturada do que a aplicação faz e onde está sua superfície de ataque.
2. Busca por vulnerabilidades
Um orquestrador lê o perfil de segurança, raciocina sobre a superfície de ataque e despacha agentes especializados para os componentes de maior risco. Cada agente recebe uma missão com escopo definido — módulos específicos, contexto de ameaça e perguntas adversariais. Os agentes têm liberdade para seguir importações e chamadores além do escopo inicial quando uma pista os leva nessa direção.
3. Triagem e deduplicação
Os candidatos a vulnerabilidade são deduplicados (mesmo ponto de injeção, mesma causa raiz) e o ruído de baixa confiança é filtrado antes da fase de validação.
4. Validação independente
Para cada candidato, um validador independente relê o código-fonte e traça a cadeia de ataque completa. O validador argumenta nos dois sentidos: busca razões pelas quais o achado pode não ser uma vulnerabilidade (controles compensatórios, design intencional) e razões pelas quais é uma (caminhos alternativos de ataque, casos extremos). Um achado só é descartado quando as evidências contra ele são tão sólidas quanto as que o promoveram.
Esse processo gera achados com seções estruturadas de Verificado e Não foi possível verificar, para que o time saiba exatamente o que o scanner confirmou no código e o que depende do ambiente de implantação.
O que torna essa abordagem diferente
A revisão completa de repositório se diferencia da análise estática tradicional em dois aspectos fundamentais: ela raciocina sobre o comportamento real da aplicação em vez de comparar padrões conhecidos, e apresenta os achados com evidências estruturadas que tornam a incerteza explícita — não escondida.
Raciocínio contextual, não correspondência de padrões
Como o scanner constrói um modelo de segurança antes de buscar vulnerabilidades, ele raciocina sobre o comportamento real da aplicação. Um exemplo concreto citado pela AWS ilustra bem isso: havia uma vulnerabilidade de injeção de SQL em uma stored procedure. Uma ferramenta SAST tradicional sinalizaria a chamada específica de EXECUTE IMMEDIATE. O scanner foi mais fundo — identificou que a função central de validação não bloqueia aspas simples em nenhum dos cinco perfis de regex, listou todos os cinco perfis pelo nome, explicou por que aspas simples importam para o banco de dados específico, e apontou que outra stored procedure ignora completamente a função de validação. Em vez de uma correção pontual em um único local, o achado levou a uma remediação abrangente da lacuna sistêmica.
Em outro caso, o scanner encontrou uma vulnerabilidade de XSS (Cross-Site Scripting) onde um valor era adicionado a um campo sem codificação HTML. O mesmo valor era corretamente codificado com Encode.forHtml() em um contexto diferente dentro do mesmo arquivo. Ferramentas de correspondência de padrões não percebem isso porque a função de codificação está presente — mas a vulnerabilidade é a inconsistência, e detectá-la exige compreender o comportamento da aplicação em diferentes caminhos de código.
Achados validados com incerteza transparente
Cada achado é estruturado para facilitar a triagem pelo time de desenvolvimento:
Problema: O que o código faz de errado, com referências específicas de arquivo e linha.
Impacto: O que um atacante ganha, com detalhes sobre o contexto de implantação.
Verificado e não foi possível verificar: O que o scanner confirmou diretamente no código versus o que depende do ambiente (segmentação de rede, comportamento em tempo de execução).
Remediação: Sugestões concretas de correção com mudanças específicas de código, não orientações genéricas.
Severidade e confiança: Calibrados de forma independente. A severidade reflete o impacto se a vulnerabilidade for explorável; a confiança reflete quanto da cadeia de ataque foi verificada no código.
Como se encaixa no fluxo de trabalho de segurança
A revisão completa de repositório foi projetada para complementar — não substituir — as ferramentas de segurança já existentes. A AWS sugere três cenários de uso principais:
Antes de revisões de segurança: Executar a análise antes de agendar um teste de penetração ou revisão de segurança. Isso faz com que os problemas óbvios e semi-óbvios já sejam resolvidos, liberando o time de segurança para focar nas questões sutis de design que exigem julgamento humano.
Ao integrar código adquirido ou open source: A funcionalidade é especialmente valiosa quando o time herda código por meio de aquisições, dependências de fornecedores ou componentes open source. O scanner constrói um modelo de segurança do zero, sem precisar de conhecimento institucional da base de código.
Durante revisões de arquitetura: Como o scanner raciocina sobre fronteiras de confiança, fluxos de dados e invariantes de autorização, seus achados frequentemente revelam problemas arquiteturais — não apenas bugs de implementação. Revisar os resultados junto com os modelos de ameaça ajuda a validar suposições sobre como os componentes interagem.
Para quem quiser começar, a AWS disponibilizou um guia de início rápido para configurar e executar a revisão completa de repositório com o AWS Security Agent.
Disponibilidade e preço
A revisão completa de repositório está disponível hoje em prévia, sem custo adicional para clientes do AWS Security Agent. Durante o período de prévia, a AWS está priorizando o acesso antecipado gratuito para que os times possam fortalecer suas bases de código e compartilhar aprendizados que beneficiem toda a indústria.
A nuvem e a inteligência artificial estão transformando indústrias e sociedades em ritmo acelerado — da pesquisa científica à experiência do cliente, passando pela otimização de processos e serviços públicos. Nesse contexto, a Amazon Web Services (AWS) publicou um posicionamento detalhado sobre como aborda a soberania de IA, tema que vem ganhando espaço crescente nas discussões regulatórias e estratégicas em todo o mundo.
Em 2022, a AWS formalizou seu compromisso com controle e escolha por meio do AWS Digital Sovereignty Pledge — uma promessa de oferecer aos clientes o conjunto mais avançado de controles de soberania disponível na nuvem. Com a aceleração da adoção de IA, a empresa passou a trabalhar ativamente para ajudar clientes a adotar inovação em IA sem abrir mão dos requisitos de soberania.
O ponto de partida da abordagem da AWS é reconhecer que soberania digital — e soberania de IA — significa coisas diferentes para diferentes partes interessadas. Cada país e região tem requisitos próprios, em constante evolução, sem uma orientação uniforme sobre quais cargas de trabalho ou setores precisam estar em conformidade. Ainda assim, a empresa identificou temas recorrentes: soberania de dados (incluindo residência de dados e restrições de acesso por operadores) e soberania operacional (incluindo resiliência, sobrevivência e independência). A soberania de IA adiciona uma camada a essas bases, incorporando considerações como a preservação de normas culturais, valores e idiomas locais nas saídas dos modelos.
Controle e escolha em toda a pilha de IA
Para a AWS, garantir soberania de IA exige controle e escolha em toda a pilha tecnológica — uma infraestrutura abrangente que combina computação, redes, gerenciamento de dados, controles de segurança, serviços de aplicação especializados e talentos. Isso inclui a capacidade de fazer escolhas deliberadas sobre localização, dependências, serviços e parceiros, alinhadas às necessidades específicas de cada cliente, aos requisitos regulatórios e aos objetivos de inovação.
No campo do hardware, os clientes podem escolher entre uma ampla gama de chips otimizados para IA — incluindo silicon desenvolvido pela própria AWS e chips da NVIDIA, AMD e Intel — para selecionar o componente mais adequado para cada carga de trabalho.
Opções de implantação para diferentes necessidades
Para clientes que precisam de implantações dedicadas para cargas de trabalho de missão crítica em IA, as AWS AI Factories são uma opção relevante. Trata-se de implantações fisicamente isoladas e exclusivas para o cliente, que combinam infraestrutura de IA de última geração — incluindo aceleradores AWS Trainium, GPUs NVIDIA, redes e armazenamento dedicados. As AI Factories atendem às necessidades de soberania de IA ao entregar capacidades de IA on-premises para treinamento, ajuste fino e inferência em tempo real de forma segura.
Portfólio de serviços de IA
O portfólio de IA da AWS cobre desde modelos de base (FMs) via Amazon Bedrock, passando por ofertas de aprendizado de máquina como o Amazon SageMaker, serviços de aplicação como o Amazon Q, e ferramentas para desenvolvedores como o Kiro. O objetivo declarado é dar aos clientes controle sobre seus dados e liberdade de escolha em como implantam IA.
Com o Amazon Bedrock, os clientes podem escolher entre centenas de modelos de provedores como AI21 Labs, Anthropic, Amazon, Cohere, Mistral AI e OpenAI. Eles podem avaliar e selecionar os FMs mais adequados às suas necessidades, escolher onde implantá-los e fazer ajuste fino dos modelos de forma privada com seus próprios dados. Um ponto importante destacado pela AWS: nenhum dado inserido ou gerado pelo Amazon Bedrock é utilizado para treinar o Amazon Nova ou qualquer modelo de terceiros.
Apoio às estratégias nacionais de IA
Estratégias de IA bem-sucedidas exigem a construção de um ambiente holístico — que nutra talentos locais, apoie startups, desenvolva aplicações específicas para cada setor e fomente parcerias público-privadas. A nuvem transformou a IA de uma tecnologia exclusiva, que exigia investimentos massivos, em uma ferramenta acessível para inovação em todos os setores e tamanhos de organização.
Embora a infraestrutura técnica receba grande parte da atenção nas discussões sobre soberania de IA, as dimensões culturais e estratégicas dos modelos de base nacionais são igualmente críticas. Esses modelos não são apenas ferramentas computacionais — eles podem codificar elementos de conhecimento cultural, nuances linguísticas e contexto social, tornando a relevância local uma consideração de design, não um detalhe secundário.
Modelos treinados localmente podem refletir currículos educacionais nacionais e valores culturais, além de compreender sistemas jurídicos locais, práticas de negócios e estruturas regulatórias. Modelos treinados em idiomas locais, dialetos e contextos culturais apoiam a diversidade linguística e ajudam línguas sub-representadas a ganhar espaço em produtos e serviços de IA.
Para personalizar modelos, os clientes podem usar o Amazon SageMaker AI para especialização por domínio, voz e avaliação de modelos quanto à precisão. Dois exemplos práticos ilustram essa capacidade:
O primeiro Modelo de Linguagem de Grande Escala (LLM) grego disponível, lançado em março de 2024, foi o Meltemi — construído sobre o Mistral-7B, rodando em infraestrutura AWS e continuamente pré-treinado para ampliar sua proficiência no idioma grego usando um conjunto de dados de 28,5 bilhões de tokens em grego. O Meltemi está disponível no HuggingFace.
O SEA-LION — uma família de LLMs multilíngues e de código aberto para o Sudeste Asiático — foi treinado inteiramente na AWS com clusters de GPU gerenciados. A equipe concluiu um modelo de 3 bilhões de parâmetros em apenas 3 meses, um cronograma 60% mais rápido do que projetos comparáveis em infraestrutura on-premises.
Controle verificável sobre o acesso aos dados
Soberania não se resume a onde os dados residem — trata-se de quem pode acessá-los e em que condições. No contexto de IA, a restrição de acesso vai além da infraestrutura e passa a cobrir as entradas e saídas do modelo, os processos de treinamento e os ambientes operacionais onde a IA é executada. Diferentemente da infraestrutura tradicional, as cargas de trabalho de IA introduzem novas superfícies de acesso: o próprio modelo, os dados usados para treiná-lo e o pipeline de inferência pelo qual passam dados sensíveis.
Para garantir a confidencialidade e a integridade dos dados dos clientes, todas as instâncias modernas do Amazon Elastic Compute Cloud (Amazon EC2) — incluindo as que oferecem aceleradores de IA como AWS Inferentia e AWS Trainium — são respaldadas pelas capacidades de segurança do AWS Nitro System. Por design, não existe mecanismo que permita a qualquer funcionário da AWS acessar dados de clientes em instâncias EC2 baseadas no Nitro. O NCC Group, empresa independente de cibersegurança, validou o design do Nitro System.
À medida que agentes de IA passam a executar ações em sistemas em nome dos usuários, controlar quem e o que pode acessar recursos — e garantir supervisão humana adequada — torna-se fundamental. O AWS Identity and Access Management (IAM) garante que apenas usuários e aplicações autorizados possam acessar recursos de IA, por meio de permissões granulares e trilhas de auditoria abrangentes. Para agentes de IA e cargas de trabalho automatizadas, o Amazon Bedrock AgentCore Identity fornece gerenciamento de identidade e credenciais, para que os agentes operem com as permissões certas — e nada além disso.
Transparência e certificações
A transparência é apresentada como um pilar central do compromisso de soberania digital da AWS. A empresa fornece medidas técnicas, controles operacionais e proteções contratuais que dão aos clientes controle sobre onde localizam seus dados, quem pode acessá-los e como são utilizados.
Entre as iniciativas de transparência, a AWS menciona a atualização de seus Termos de Serviço para refletir os compromissos de proteção técnica (como o AWS Nitro System), além de fornecer comprometimentos detalhados sobre como lida com solicitações de terceiros para dados de clientes. Um blog sobre o CLOUD Act foi disponibilizado para ajudar clientes a tomar decisões informadas sobre soberania.
A empresa também suporta mais de 140 padrões de segurança e certificações de conformidade que seus clientes e parceiros podem herdar para cumprir leis e regulamentações locais.
Compromisso contínuo com a soberania
A mensagem central da AWS é que o compromisso com soberania não é estático — à medida que a nuvem e a IA evoluem, a empresa declara que continuará oferecendo os controles e recursos de soberania mais avançados disponíveis. O objetivo é garantir que os clientes possam aproveitar o poder transformador da IA sem abrir mão de capacidades, desempenho, inovação, segurança e escala.
Para organizações brasileiras que lidam com dados sensíveis, operam em setores regulados ou simplesmente querem entender melhor como a soberania de IA se aplica às suas operações, o posicionamento detalhado da AWS oferece um mapa útil das ferramentas e compromissos disponíveis na plataforma.
Expansão regional das instâncias G6 no SageMaker Studio
A AWS anunciou a disponibilidade geral das instâncias Amazon EC2 G6 nos notebooks do SageMaker Studio em duas novas regiões: Oriente Médio (Dubai) e Ásia-Pacífico (Malásia). Para equipes que operam nessas localidades, isso representa acesso direto a hardware de alto desempenho para cargas de trabalho de inteligência artificial e aprendizado de máquina, sem necessidade de rotear para outras regiões.
O que são as instâncias G6?
As instâncias G6 são equipadas com até 8 GPUs NVIDIA L4 Tensor Core, cada uma com 24 GB de memória, e processadores AMD EPYC de terceira geração. Em termos práticos, isso significa uma capacidade de processamento paralelo significativa para tarefas que exigem alto poder computacional em IA.
Um ponto de destaque técnico: as instâncias G6 oferecem desempenho 2x superior para inferência de aprendizado profundo em comparação com as instâncias EC2 G4dn. Para times que já utilizam G4dn e buscam mais eficiência sem migrar para arquiteturas completamente diferentes, essa é uma evolução direta e relevante.
Casos de uso suportados
Segundo a AWS, as instâncias G6 no SageMaker Studio são indicadas para uma variedade de cenários práticos, incluindo:
Teste interativo de implantação de modelos
Treinamento interativo de modelos
Fine-tuning e inferência de IA generativa
Processamento de linguagem natural (PLN)
Tradução de idiomas
Visão computacional
Motores de recomendação
O ambiente de notebooks do SageMaker Studio permite que essas atividades sejam realizadas de forma interativa, o que facilita iterações rápidas durante o desenvolvimento e a experimentação de modelos.
Como começar
Para quem deseja configurar e utilizar as instâncias G6 no SageMaker Studio, a AWS disponibiliza guias de desenvolvedor com instruções detalhadas para os ambientes JupyterLab e CodeEditor dentro do SageMaker Studio. Para consultar os valores dessas instâncias, as informações de preço estão disponíveis na página de preços do SageMaker.
Para quem quer fortalecer a postura de segurança da organização na Amazon Web Services (AWS), mas não sabe por onde começar, a AWS disponibiliza os Security Activation Days — workshops virtuais gratuitos e práticos, pensados para que os participantes saiam de cada sessão com experiência real nos serviços de segurança da plataforma.
O que esperar dos eventos
Cada Security Activation Day é um workshop virtual com duração de 3 a 6 horas. Durante a sessão, os participantes trabalham diretamente com os serviços de segurança da AWS em cenários do mundo real. A dinâmica combina apresentações, demonstrações e atividades práticas guiadas por especialistas de segurança da AWS — seja no próprio ambiente do participante ou em um sandbox (ambiente isolado de testes) fornecido pela AWS.
Os temas variam e cobrem o espectro completo de serviços de segurança, identidade e governança da AWS, incluindo:
Detecção de ameaças e resposta a incidentes
Gerenciamento de identidade e acesso
Proteção de rede e aplicações
Proteção de dados
Governança e conformidade
O objetivo é que cada participante saia com conhecimento aplicável imediatamente às suas cargas de trabalho — não com uma lista de tarefas para pesquisar depois.
Para quem é indicado
Os Security Activation Days são voltados para quem constrói e opera ambientes na nuvem: engenheiros de segurança, arquitetos de nuvem e times de DevOps que querem se aprofundar em capacidades específicas de segurança da AWS. Tanto quem está avaliando um serviço pela primeira vez quanto quem já o implantou e quer operacionalizá-lo melhor encontra valor nessas sessões.
O que os participantes dizem
Com mais de 6.400 participantes em mais de 90 eventos realizados até agora em 2026, os Security Activation Days mantêm uma avaliação média de 4,8 em 5. O formato prático é o principal diferencial apontado pelos participantes: não há substituto para configurar um serviço de verdade e ver os resultados em tempo real.
Como se inscrever
Os eventos acontecem ao longo do ano, em todos os fusos horários, com novas sessões sendo adicionadas regularmente. Para encontrar uma sessão e começar a aprender na prática, acesse a página de inscrições e comece a construir hoje mesmo.
O problema com APIs de busca tradicionais em fluxos de agentes
Se você está construindo agentes de IA para pesquisa, verificação de fatos ou inteligência competitiva, a qualidade da informação em tempo real é determinante. O problema é que a maioria das APIs de busca genéricas não foi projetada para esse tipo de fluxo: elas retornam páginas cheias de HTML e snippets curtos otimizados para navegação humana, não dados estruturados que um agente possa consumir diretamente. O resultado prático é que os desenvolvedores acabam precisando construir camadas adicionais — crawlers customizados, parsers e lógica de ranqueamento — só para transformar esse conteúdo em algo utilizável dentro do workflow do agente.
É exatamente essa lacuna que a integração entre o Strands Agents SDK e a Exa busca resolver, oferecendo uma camada de busca e recuperação de conteúdo nativa para IA, construída diretamente na interface de ferramentas do SDK.
O que é o Strands Agents SDK
O Strands Agents SDK é um framework open source da AWS para construção de agentes de IA com uma abordagem orientada ao modelo. Em vez de escrever workflows com cada passo codificado manualmente, o desenvolvedor fornece um modelo, um prompt de sistema e uma lista de ferramentas. O próprio modelo decide o que fazer a seguir: quais ferramentas chamar, em que ordem e quando a tarefa está concluída.
No centro do SDK está o chamado agent loop. A cada iteração, o modelo recebe todo o histórico da conversa — incluindo cada chamada de ferramenta anterior e seu resultado. Se o modelo precisar de mais informações, ele solicita uma ferramenta; o Strands Agents a executa e devolve o resultado. O loop continua até que o modelo produza uma resposta final. Essa acumulação de contexto ao longo das iterações é o que permite que agentes resolvam tarefas de múltiplos passos que vão além do que uma única chamada a um Modelo de Linguagem de Grande Escala (LLM) consegue fazer.
O SDK já vem com mais de 40 ferramentas pré-construídas cobrindo operações de arquivo, execução de shell, busca na web, APIs da AWS, memória, execução de código e muito mais. Ele também suporta o Protocolo de Contexto de Modelo (MCP — Model Context Protocol), então ferramentas expostas por servidores MCP ficam disponíveis para o agente sem trabalho adicional de integração. Adicionar novas ferramentas — incluindo as da Exa — segue o mesmo padrão: basta incluí-las na lista tools=[] e o modelo aprende a usá-las a partir das suas assinaturas.
O que é a Exa e por que ela é diferente
A Exa é uma engine de busca em escala web construída especificamente para LLMs e agentes de IA. Diferente de buscadores tradicionais, a Exa entende o significado de uma consulta, não apenas suas palavras-chave. Uma busca como “startups construindo soluções climáticas” retorna startups reais do setor climático, mesmo que essas páginas nunca usem exatamente essa frase — o modelo faz a correspondência por similaridade semântica, não por sobreposição de strings.
Os resultados chegam como conteúdo limpo e estruturado, sem anúncios ou ruído de Otimização para Mecanismos de Busca (SEO — Search Engine Optimization), prontos para serem consumidos diretamente por um LLM.
As duas ferramentas da integração
A integração com a Exa está disponível através do pacote strands-agents-tools e expõe duas capacidades ao agente:
exa_search: realiza buscas na web com suporte a múltiplos modos — auto, fast, instant e deep — e permite filtrar resultados por categoria (notícias, artigos acadêmicos, repositórios GitHub, PDFs, perfis de pessoas, relatórios financeiros), domínio, data e conteúdo textual. Também é possível solicitar conteúdo e resumos junto com os resultados em uma única chamada.
exa_get_contents: recupera o conteúdo completo de URLs que o agente já descobriu — seja de uma busca anterior ou do próprio raciocínio do modelo. A ferramenta verifica primeiro um cache de conteúdo para acelerar requisições repetidas; se o conteúdo não estiver em cache ou se o agente precisar da versão mais atual, ela pode fazer live crawling automaticamente.
Os quatro modos de busca do exa_search são:
Instant (~200ms): para aplicações em tempo real como autocomplete, sugestões ao vivo e agentes de voz.
Fast (~450ms): otimizado para velocidade, adequado para fluxos agenticos onde o agente faz dezenas de chamadas de busca sequenciais.
Auto (~1s) — Recomendado: latência balanceada com resultados de alta qualidade. Ponto de partida indicado para a maioria dos casos de uso.
Deep (~3-6s): executa buscas paralelas em variações da consulta para cobertura máxima. Ideal para tarefas de pesquisa onde completude importa mais que velocidade.
Configuração em poucas linhas
Para usar a integração, são necessários Python 3.10 ou superior, uma conta AWS com acesso ao Amazon Bedrock e uma chave de API da Exa. A instalação dos pacotes é feita com:
pip install strands-agents strands-agents-tools
Com os pacotes instalados, o processo tem três passos. Primeiro, configure a chave de API da Exa como variável de ambiente:
export EXA_API_KEY="your_exa_api_key_here"
Depois, importe e registre as ferramentas no agente:
from strands import Agent
from strands_tools.exa import exa_search, exa_get_contents
agent = Agent(tools=[exa_search, exa_get_contents])
Com as ferramentas registradas, o agente já pode intercalar busca e extração de conteúdo naturalmente como parte do seu fluxo de raciocínio:
response = agent(
"Search for the most recent trends in AI agents and provide a concise summary of key developments")
Exemplo prático: o assistente de pesquisa profunda
Para demonstrar como as duas ferramentas funcionam em conjunto, a AWS apresenta um assistente de pesquisa profunda que executa um fluxo de múltiplos passos. Dado um tema de pesquisa, o agente realiza quatro buscas direcionadas em diferentes tipos de fonte, extrai o conteúdo completo dos resultados mais promissores e sintetiza tudo em um relatório estruturado — tudo dentro de uma única invocação do agente, com múltiplas chamadas de ferramentas acontecendo no loop de raciocínio.
A configuração do agente usa o Claude Sonnet via Amazon Bedrock:
from strands import Agent
from strands.models.bedrock import BedrockModel
from strands_tools.exa import exa_search, exa_get_contents
def create_research_agent() -> Agent:
model = BedrockModel(
model_id="us.anthropic.claude-sonnet-4-6",
region_name="us-west-2",
max_tokens=20000,
)
return Agent(
model=model,
system_prompt=load_system_prompt(),
tools=[exa_search, exa_get_contents],
)
O fluxo de seis etapas
Um prompt de sistema define o fluxo de pesquisa, guiando o agente por seis etapas. Cada etapa instrui o agente a chamar as ferramentas da Exa com parâmetros diferentes, ajustados para o tipo de conteúdo buscado:
Etapa 1 — Visão geral: uma varredura ampla usando o modo auto para construir entendimento fundacional sobre o tema, com até 5 resultados e resumos contextuais.
Etapa 2 — Notícias recentes: foco em fontes de notícias com filtro de data para os últimos 30 dias, com limite de cache de 24 horas para garantir frescor.
Etapa 3 — Artigos acadêmicos: busca na categoria research paper com extração estruturada via esquema JSON para capturar descobertas principais, metodologia e conclusões de cada artigo.
Etapa 4 — Projetos no GitHub: implementações open source são encontradas pela categoria github, com destaque para os trechos mais relevantes do repositório.
Etapa 5 — Mergulho profundo: o agente muda de descoberta para extração. As duas ou três URLs mais promissoras das etapas anteriores têm seu conteúdo completo recuperado com exa_get_contents, usando live crawling forçado (max_age_hours: 0) e rastreamento de subpáginas para referências, citações e metodologia.
Etapa 6 — Síntese: nenhuma ferramenta é chamada. Tudo o que foi coletado nas etapas anteriores alimenta a geração de um relatório estruturado com sumário executivo, visão geral do tema, desenvolvimentos recentes, pesquisas-chave, ferramentas e implementações, e lista completa de fontes com URLs.
O design central do exemplo é que diferentes tipos de fonte requerem parâmetros diferentes — mas não ferramentas diferentes. As mesmas duas ferramentas da Exa são reutilizadas em todo o fluxo com configurações variadas a cada etapa.
Por que esse fluxo multi-etapas é superior a uma busca simples
Respostas fundamentadas: cada afirmação no relatório final rastreia de volta a uma URL de origem, reduzindo alucinações.
Uso eficiente de tokens: resumos gerados no momento da busca e extração mantêm o conteúdo conciso, para que o LLM trabalhe com conhecimento destilado em vez de dumps brutos de páginas.
Profundidade autônoma: o agente itera entre tipos de fonte (notícias, artigos, repositórios de código, páginas completas) sem direcionamento humano, cobrindo um terreno que uma única busca não conseguiria.
Rastreabilidade com Amazon Bedrock AgentCore Observability
Um pipeline de seis etapas com múltiplas chamadas de ferramentas é difícil de depurar sem rastreamento estruturado. O Amazon Bedrock AgentCore Observability, construído sobre o OpenTelemetry, instrumenta toda a execução do agente com mudanças mínimas de código. Cada chamada de ferramenta e cada invocação de LLM se torna um span com relações pai-filho.
No dashboard de Observabilidade de IA Generativa (GenAI — Generative AI) do CloudWatch, cada execução de pesquisa aparece como um trace completo. É possível inspecionar parâmetros de chamada por invocação de exa_search ou exa_get_contents (verificando se o agente usou a categoria, intervalo de datas e limites de conteúdo corretos em cada etapa), latência por etapa e consumo de tokens por invocação de LLM.
Fluxos agenticos são não-determinísticos: a mesma consulta pode produzir resultados de busca diferentes, seleções de URL diferentes para o mergulho profundo e saídas de síntese diferentes. Os dados de trace transformam a depuração de adivinhação em inspeção.
Boas práticas para usar as ferramentas da Exa
A AWS destaca algumas recomendações para otimizar qualidade, latência e custo ao integrar as ferramentas da Exa em agentes. Para mais detalhes sobre tipos de busca, modos de conteúdo e filtragem avançada, a documentação de boas práticas da Exa é o recurso indicado:
Comece com auto e ajuste conforme necessário: o modo auto funciona bem para a maioria das consultas. Mude para deep em tarefas de pesquisa onde perder uma fonte relevante tem custo alto, e para fast ou instant quando o agente faz muitas buscas sequenciais e a latência acumulada importa mais que a completude por consulta.
Controle o tamanho do conteúdo para gerenciar o orçamento de tokens: defina maxCharacters no campo highlights (o padrão é 4.000 caracteres) para evitar que respostas muito longas consumam tokens desnecessariamente.
Limpeza de recursos
Este exemplo não cria nenhum recurso persistente na AWS. Se não precisar mais da chave de API da Exa, basta revogá-la pelo painel da Exa.
Conclusão
A combinação entre o Strands Agents SDK e a Exa oferece um caminho para construir agentes de IA fundamentados em informações web atuais e precisas. A busca semântica da Exa, o filtro por categoria, os resumos com esquemas JSON e o live crawling são expostos através de apenas duas ferramentas e algumas linhas de configuração.
Como o assistente de pesquisa profunda demonstra, é possível construir um agente multi-etapas que busca em notícias, artigos acadêmicos e repositórios de código, extrai conteúdo completo dos melhores resultados e sintetiza tudo em um relatório fundamentado — tudo guiado por um único prompt de sistema. O agente direciona tipos de fonte com filtros de categoria, controla recência com intervalos de data, formata saída com esquemas JSON e gerencia frescor com live crawling. O fluxo completo é rastreável pelo Amazon Bedrock AgentCore Observability, transformando comportamento não-determinístico em spans inspecionáveis e depuráveis.
A AWS anunciou a disponibilidade geral do Claude Platform on AWS, um serviço que oferece acesso direto à plataforma nativa da Anthropic — a mesma experiência disponível quando se contrata o Claude diretamente — mas tudo operando pela conta AWS já existente do cliente. Nenhum contrato separado, nenhuma credencial adicional, nenhum relacionamento de cobrança paralelo.
Vale destacar: a AWS é o primeiro provedor de nuvem a disponibilizar esse acesso integrado à experiência nativa do Claude Platform.
O que está incluído na experiência nativa
Com o Claude Platform on AWS, as equipes têm acesso ao mesmo conjunto de APIs e funcionalidades disponíveis diretamente pela Anthropic. Isso inclui:
A proposta central do serviço é eliminar a fricção operacional de gerenciar um relacionamento separado com a Anthropic. A integração se apoia em três pilares do ecossistema AWS:
Autenticação: as equipes utilizam as próprias credenciais AWS IAM para acessar o Claude Platform. Sem contas extras ou chaves de API independentes para administrar.
Faturamento: o consumo é cobrado pelo AWS Marketplace em modelo por uso (consumption basis), permitindo acompanhar os gastos com IA junto aos demais serviços AWS no mesmo painel.
Auditoria: toda a atividade é registrada no AWS CloudTrail, possibilitando monitorar, auditar e investigar o uso de IA da mesma forma que qualquer outro serviço AWS.
Um ponto importante de arquitetura: o Claude Platform on AWS é operado pela Anthropic, e as requisições e dados são processados fora do perímetro de segurança da AWS. Isso o torna adequado para equipes que não possuem requisitos específicos de residência de dados por região. O serviço complementa os modelos Claude disponíveis no Amazon Bedrock — são abordagens distintas para cenários distintos.
Como começar: três passos até a primeira chamada de API
O Claude Platform on AWS pode ser ativado pelo AWS Marketplace. Para instruções detalhadas, a documentação oficial orienta sobre como configurar a conta. Após a ativação, o caminho até a primeira chamada de API envolve três etapas.
Passo 1: Criar um workspace
Um workspace permite separar projetos, ambientes ou times, mantendo cobrança e administração centralizadas. Ele também funciona como o recurso principal de Gerenciamento de Identidade e Acesso (IAM) da AWS para o Claude Platform on AWS. O acesso a workspaces específicos é concedido ou negado por meio de políticas IAM usando o ARN do workspace — a documentação de políticas IAM traz exemplos práticos.
O serviço suporta dois métodos de autenticação: IAM com AWS Signature Version 4 e chaves de API. A recomendação é usar credenciais IAM temporárias para ambientes que exigem maior nível de segurança, e chaves de API para exploração e testes iniciais.
Após gerar uma chave de API no console, as variáveis de ambiente necessárias são configuradas assim:
# Your API key
export ANTHROPIC_API_KEY=<YOUR API KEY HERE>
# Your regional endpoint for Claude Platform on AWS
export ANTHROPIC_BASE_URL=https://aws-external-anthropic.<YOUR REGION HERE>.api.aws
# Your workspace ID (find in Claude Platform on AWS Console → Workspaces)
export ANTHROPIC_WORKSPACE_ID=<YOUR WORKSPACE ID HERE>
Passo 3: Fazer a primeira chamada de API
Com as variáveis configuradas, basta instalar os SDKs do cliente Anthropic e realizar chamadas de API:
A Anthropic disponibiliza notebooks de introdução com mais exemplos de código para quem quiser explorar além do básico.
Usando na prática com Claude Code e Claude Cowork
Com a configuração concluída, é possível apontar o Claude Code, o Claude Cowork ou qualquer outro cliente de API para o workspace usando as variáveis de ambiente ou configurações adequadas:
export ANTHROPIC_API_KEY=<YOUR API KEY HERE>
export ANTHROPIC_BASE_URL=https://aws-external-anthropic.<YOUR REGION HERE>.api.aws
# For Claude Cowork, set the "anthropic-workspace-id" in your inference configuration.
# For Claude Code use the following:
export ANTHROPIC_CUSTOM_HEADERS='{"anthropic-workspace-id":"<YOUR WORKSPACE ID HERE>"}'
# For the Anthropic SDK
export ANTHROPIC_WORKSPACE_ID=<YOUR WORKSPACE ID HERE>
Uma vez conectados, os clientes passam a contar com funcionalidades como busca na web, conectores MCP, agent skills, execução de código e upload de arquivos — tudo pelo Claude Platform on AWS.
Monitoramento, auditoria e custos
O uso pode ser acompanhado diretamente no Claude Console, com detalhamentos por workspace, principal IAM da AWS e período de tempo.
No ambiente AWS, o CloudTrail registra todas as requisições ao Claude Platform on AWS — sejam elas originadas do SDK da Anthropic, do Claude Code ou do Cowork. Operações de workspace são registradas como eventos de gerenciamento por padrão, e o registro de eventos de dados pode ser habilitado para capturar a atividade de inferência. Mais detalhes sobre tipos de eventos e configuração de logging estão disponíveis na documentação de monitoramento e logging.
Como o faturamento passa pelo AWS Marketplace, os custos aparecem no AWS Cost Explorer junto aos demais serviços de nuvem. A alocação de gastos por equipe ou projeto pode ser feita com resource tags.
Disponibilidade por região
O Claude Platform on AWS está disponível nas seguintes regiões: US East (N. Virginia), US East (Ohio), US West (Oregon), Canada (Central), South America (São Paulo), Europe (Dublin), Europe (London), Europe (Frankfurt), Europe (Milan), Europe (Zurich), Europe (Paris), Europe (Stockholm), Asia Pacific (Tokyo), Asia Pacific (Seoul), Asia Pacific (Jakarta), Asia Pacific (Sydney) e Asia Pacific (Melbourne).
Conclusão
O Claude Platform on AWS representa uma integração relevante para equipes que já operam na AWS e querem adotar as APIs nativas da Anthropic sem abrir mão da governança, auditoria e faturamento centralizados que o ambiente AWS oferece. A combinação com o Amazon Bedrock — que permanece como opção para quem precisa de residência de dados por região — amplia as possibilidades de escolha conforme o perfil de cada organização.
Se você trabalha com documentação técnica industrial — aeroespacial, automotiva, manufatura pesada — sabe bem como esses arquivos são: especificações escritas misturadas com desenhos de engenharia, diagramas CAD, fotografias de inspeção, gráficos de análise térmica e curvas de fadiga. O conteúdo relevante muitas vezes não está em nenhum parágrafo de texto. Está dentro de um gráfico de contorno térmico, numa tabela desenhada dentro de um desenho técnico, ou num fluxograma com anotações visuais.
Sistemas de recuperação de informação baseados apenas em texto tratam esses documentos extraindo o texto via Reconhecimento Óptico de Caracteres (OCR) e indexando as strings resultantes. Funciona razoavelmente quando a resposta está escrita em prosa, mas falha quando a informação está codificada visualmente — relações espaciais em diagramas, padrões em imagens de inspeção, valores quantitativos em gráficos e tabelas desenhadas.
É exatamente esse gap que o Amazon Nova Multimodal Embeddings se propõe a fechar, mapeando texto, imagens e páginas de documentos num mesmo espaço vetorial compartilhado. Uma consulta em texto pode recuperar um diagrama de engenharia, e uma consulta por imagem pode recuperar uma especificação escrita — porque ambas as modalidades compartilham o mesmo sistema de coordenadas vetoriais.
O que é o Amazon Nova Multimodal Embeddings
O Amazon Nova Multimodal Embeddings está disponível no Amazon Bedrock e gera embeddings para texto, imagens e documentos de múltiplas páginas. As três modalidades — texto, imagem e documento — são projetadas num único espaço vetorial compartilhado, o que permite calcular similaridade de cosseno diretamente entre um embedding de texto e um embedding de imagem.
O modelo oferece dimensões configuráveis: 256, 384, 1024 ou 3072. Dimensões maiores capturam mais detalhes semânticos, mas exigem mais armazenamento e processamento nas buscas por similaridade. No estudo publicado pela AWS, foram utilizadas 1024 dimensões como equilíbrio prático entre qualidade de recuperação e custo.
O modelo também suporta um nível de detalhe chamado DOCUMENT_IMAGE, um modo de processamento projetado para páginas com conteúdo misto — gráficos, tabelas e diagramas anotados. Para cargas de recuperação, o modelo aceita um parâmetro purpose configurado como GENERIC_INDEX (para documentos sendo indexados) ou GENERIC_RETRIEVAL (para consultas). Essa abordagem de embedding assimétrico melhora o espaço vetorial para recuperação sem exigir formatação manual das consultas.
Arquitetura da solução: dois pipelines em paralelo
Para demonstrar o valor da abordagem multimodal, a AWS construiu dois pipelines de recuperação paralelos sobre o mesmo conjunto de dados, comparando a qualidade de geração de respostas entre eles.
O conjunto de dados contém 15 imagens técnicas independentes (diagramas CAD, relatórios de inspeção, gráficos de teste, especificações de materiais, fluxogramas de processo) e cinco PDFs de múltiplas páginas (procedimentos de montagem, relatórios de teste a quente, avisos de mudança de engenharia, certificações de material e relatórios de não conformidade). Todos os documentos contêm dados sintéticos de manufatura aeroespacial.
Pipeline A — Multimodal: cada imagem é embeddada diretamente e cada página de PDF é processada como imagem de documento usando o Amazon Nova Multimodal Embeddings, sendo então ingerida num índice do Amazon S3 Vectors.
Pipeline B — Baseline somente texto: cada imagem e página de PDF é enviada ao Amazon Nova 2 Lite para extração de texto via OCR, o texto extraído é embeddado usando o Amazon Nova Multimodal Embeddings (entrada apenas de texto) e ingerido num índice separado no Amazon S3 Vectors.
Os documentos de origem percorrem dois caminhos paralelos: o Pipeline A embeda imagens diretamente com o Amazon Nova Multimodal Embeddings, enquanto o Pipeline B extrai texto via OCR antes de embeddar. Ambos armazenam vetores no Amazon S3 Vectors. No momento da consulta, o contexto recuperado alimenta o Amazon Nova 2 Lite para geração de respostas, e um juiz baseado em Modelo de Linguagem Grande (LLM) pontua cada resposta em relação ao gabarito.
A seguir, três documentos de exemplo do conjunto de dados: um diagrama CAD de montagem de bico, um relatório de inspeção de solda e uma curva de fadiga S-N do Inconel 718 — cada tipo apresentando informações difíceis de capturar apenas por extração de texto.
O código completo está disponível no notebook de referência no GitHub. Os pré-requisitos incluem uma conta AWS com acesso ao Amazon Bedrock na região us-east-1, acesso habilitado para os modelos amazon.nova-2-multimodal-embeddings-v1:0 e us.amazon.nova-2-lite-v1:0, e permissões de Gerenciamento de Identidade e Acesso (IAM) para as APIs do Amazon Bedrock InvokeModel, Amazon S3 e Amazon S3 Vectors.
Gerando embeddings multimodais
Gerar um embedding para uma imagem técnica requer uma única chamada InvokeModel ao Amazon Bedrock. A requisição especifica os bytes da imagem, a dimensão desejada do embedding e o nível de detalhe. Para imagens independentes como diagramas CAD, usa-se STANDARD_IMAGE. Para páginas de PDF com conteúdo misto, DOCUMENT_IMAGE produz resultados melhores:
O Amazon S3 Vectors fornece uma camada gerenciada de armazenamento e consulta vetorial. É necessário criar um bucket de vetores e um índice configurado para similaridade de cosseno, depois ingerir os embeddings em lotes de 50:
s3vectors = boto3.client("s3vectors", region_name="us-east-1")
# Create vector bucket and index
s3vectors.create_vector_bucket(vectorBucketName="manufacturing-vectors")
s3vectors.create_index(
vectorBucketName="manufacturing-vectors",
indexName="manufacturing-multimodal",
dataType="float32",
dimension=1024,
distanceMetric="cosine",
)
# Ingest a batch of embeddings with metadata
vectors = [
{
"key": "img-nozzle_assembly_diagram",
"data": {"float32": embedding},
"metadata": {
"source_file": "nozzle_assembly_diagram.png",
"type": "image",
},
}
]
s3vectors.put_vectors(
vectorBucketName="manufacturing-vectors",
indexName="manufacturing-multimodal",
vectors=vectors,
)
Consultando o índice
No momento da consulta, gera-se um embedding de texto com o purpose GENERIC_RETRIEVAL e chama-se query_vectors para recuperar os documentos mais similares. O purpose GENERIC_RETRIEVAL instrui o modelo a otimizar o embedding para correspondência consulta-documento:
query = "What is the torque specification for the chamber flange bolts?"
request_body = {
"taskType": "SINGLE_EMBEDDING",
"singleEmbeddingParams": {
"embeddingPurpose": "GENERIC_RETRIEVAL",
"embeddingDimension": 1024,
"text": {"truncationMode": "END", "value": query},
},
}
response = bedrock_runtime.invoke_model(
modelId=MODEL_ID,
body=json.dumps(request_body),
accept="application/json",
contentType="application/json",
)
query_embedding = json.loads(response["body"].read())["embeddings"][0]["embedding"]
results = s3vectors.query_vectors(
vectorBucketName="manufacturing-vectors",
indexName="manufacturing-multimodal",
queryVector={"float32": query_embedding},
topK=5,
returnDistance=True,
returnMetadata=True,
)
for v in results["vectors"]:
print(f" {v['key']} (distance: {v['distance']:.4f})")
Essa consulta recupera a imagem de especificações de torque e o diagrama de padrão de parafusos de flange como os principais resultados — ambos contêm a resposta. Um sistema baseado apenas em texto dependeria da extração OCR ter capturado corretamente os valores de torque do desenho técnico, o que nem sempre é confiável para diagramas técnicos complexos.
Metodologia de avaliação
A avaliação foi realizada em duas etapas: qualidade de recuperação (o sistema encontra os documentos corretos?) e qualidade de geração (um modelo de linguagem consegue produzir uma resposta correta a partir do contexto recuperado?).
Avaliação de recuperação
Para cada consulta, gera-se um embedding de texto com purpose GENERIC_RETRIEVAL, consulta-se o índice multimodal no S3 Vectors e comparam-se os documentos retornados com os IDs de documentos relevantes do gabarito. Três métricas são calculadas em K=3, 5 e 10:
Recall@K: fração de documentos relevantes encontrados nos K primeiros resultados
Média da Posição Recíproca (MRR): mede quão alto o primeiro resultado relevante aparece
Ganho Cumulativo Descontado Normalizado (NDCG@K): dá mais crédito quando documentos relevantes aparecem mais alto na lista
Avaliação de geração com LLM-as-Judge
Para a avaliação de geração, ambos os pipelines recuperam os cinco principais resultados para cada consulta. O pipeline multimodal passa as imagens recuperadas diretamente ao Amazon Nova 2 Lite como contexto multimodal. O pipeline somente texto passa o texto extraído por OCR como contexto em string. Cada resposta gerada é pontuada em relação ao gabarito usando o Anthropic Claude Sonnet 4.5 como juiz LLM, numa escala de 1 a 5.
Resultados: a diferença é expressiva
Métricas de recuperação multimodal
O pipeline multimodal alcança 90% de recall em K=5, o que significa que ele encontra a maioria dos documentos relevantes dentro dos cinco primeiros resultados, subindo para 96% em K=10. Um MRR de 0,92 indica que o primeiro resultado relevante tipicamente aparece na posição 1. As duas consultas onde o recall fica abaixo de 1,0 em K=10 envolvem documentos com informação relevante dividida entre um PDF e uma imagem independente.
Os resultados de geração mostram uma diferença muito significativa entre os dois pipelines:
Pipeline
Nota média do juiz
Normalizado (0–1)
Multimodal (MME)
4,88 / 5
0,977
Somente texto (OCR)
2,00 / 5
0,400
O pipeline multimodal obteve pontuação superior em 88% das consultas (23 de 26), com média de 4,88 de 5. O pipeline somente texto atingiu média 2,00, com 17 das 26 consultas recebendo nota 1 (completamente errado). Conteúdo visual como gráficos de contorno de análise térmica, curvas de fadiga, diagramas de fluxo de processo e rótulos de callout em CAD apresentaram as maiores melhorias.
Esses resultados demonstram que a qualidade da recuperação afeta diretamente a qualidade das respostas. Quando o sistema recupera os documentos corretos mas passa apenas o texto OCR ao gerador, perde a informação visual da qual a resposta depende. O pipeline multimodal evita essa conversão com perda de informação passando as imagens originais a um gerador multimodal.
Complexidade de implementação e custo
Além da acurácia, o pipeline multimodal é mais simples de construir e mais barato de operar. O pipeline somente texto exige duas chamadas de modelo por documento (uma para extração de texto OCR e outra para embedding de texto), além de engenharia de prompt para lidar com layouts variados de documentos. O pipeline multimodal requer uma única chamada de embedding por documento, sem etapa intermediária de extração — reduzindo tanto a complexidade de implementação quanto o custo de ingestão por documento em aproximadamente metade.
Limpeza de recursos
Para evitar custos contínuos, é recomendado deletar os índices e o bucket do S3 Vectors após concluir a avaliação. O notebook de referência no GitHub inclui os comandos de limpeza (comentados por segurança). O trecho abaixo mostra como deletar os índices e o bucket de vetores:
A inferência de embedding no Amazon Bedrock é cobrada por requisição, sem infraestrutura persistente para gerenciar.
Conclusão
Embeddings multimodais fecham uma lacuna de recuperação que sistemas somente texto não conseguem endereçar em coleções de documentos com conteúdo visual significativo. No conjunto de dados de manufatura aeroespacial deste estudo, o pipeline multimodal alcançou 90% de recall em K=5 (96% em K=10) e qualidade de geração quase perfeita (4,88/5), enquanto o pipeline somente texto ficou em 2,00/5 porque o OCR não conseguiu capturar de forma confiável as informações de diagramas de engenharia, gráficos térmicos e fluxogramas de processo.
Com o Amazon Nova Multimodal Embeddings no Amazon Bedrock, essa capacidade pode ser construída sem gerenciar infraestrutura de modelos de embedding. O Amazon S3 Vectors fornece uma camada de armazenamento e consulta vetorial que não requer gerenciamento de cluster ou planejamento de capacidade. Para experimentar, basta clonar o código de exemplo no GitHub e executá-lo no Amazon SageMaker AI ou no ambiente local. O pipeline pode ser adaptado para documentos de manufatura próprios substituindo o conjunto de dados e as consultas de exemplo.
