Blog

  • AWS HealthOmics apresenta fluxos de trabalho conectados à VPC

    Novidade na AWS HealthOmics: fluxos de trabalho com conexão VPC

    A AWS HealthOmics anunciou a introdução de fluxos de trabalho conectados à VPC (Nuvem Privada Virtual), permitindo que seus clientes executem pipelines de bioinformática com acesso a recursos da AWS distribuídos em diferentes regiões e também a recursos disponíveis na internet pública, tudo através de uma Nuvem Privada Virtual configurada pelo cliente.

    O que muda para os clientes de ciências da vida

    Esta evolução oferece um alívio significativo aos profissionais que trabalham com dados bioinformáticos: não é mais necessário migrar dados e dependências para a mesma região da AWS onde o fluxo de trabalho será executado. Isso simplifica bastante os processos operacionais e reduz o tempo gasto em preparação de dados.

    O HealthOmics é um serviço elegível para HIPAA que ajuda a acelerar descobertas científicas em escala, com fluxos de trabalho bioinformáticos totalmente gerenciados. Com essa nova capacidade, pesquisadores e cientistas conseguem desenvolver e testar pipelines de forma mais rápida.

    Flexibilidade de configuração e acesso a dados

    A solução permite que os clientes estruturem fluxos de trabalho capazes de acessar conjuntos de dados disponibilizados publicamente na internet e, simultaneamente, recursos da AWS distribuídos em diferentes regiões, sem necessidade de alterar o código do fluxo de trabalho ou fazer migrações de dados entre regiões.

    Para isso, foram introduzidas as APIs de Configuração, que permitem especificar uma VPC configurada para acessar recursos na internet pública. O HealthOmics consegue enviar e receber tráfego de rede através dessa configuração, facilitando a utilização de diferentes topologias de rede conforme cada caso de uso necessitar. As dependências de internet pública podem ser adicionadas ou removidas a qualquer momento.

    Um diferencial importante é que as configurações de rede são aplicadas no nível de execução individual do fluxo de trabalho, não globalmente. Isso significa que você pode ativar a conexão VPC apenas para os fluxos que realmente precisam dela, mantendo outros em configurações diferentes.

    Disponibilidade regional

    Os fluxos de trabalho conectados à VPC estão disponíveis em todas as regiões onde o AWS HealthOmics opera atualmente: US East (N. Virginia), US West (Oregon), Europa (Frankfurt, Irlanda, Londres), Israel (Tel Aviv), Ásia Pacífico (Singapura) e Ásia Pacífico (Seul).

    Próximos passos

    Para aprender mais sobre como conectar seus fluxos de trabalho à sua VPC, consulte a documentação do HealthOmics.

    Fonte

    AWS HealthOmics introduces VPC-connected workflows (https://aws.amazon.com/about-aws/whats-new/2026/03/aws-healthomics-vpc-connected-workflows/)

  • Assistente de IA Conversacional para Recomendações Personalizadas de Filmes na AWS

    O Desafio das Recomendações de Conteúdo Moderno

    Os sistemas de recomendação formam a base das plataformas modernas de streaming, moldando como os usuários descobrem conteúdo. Abordagens tradicionais baseadas em aprendizado de máquina — como filtragem colaborativa ou baseada em conteúdo — preveem preferências usando padrões históricos. No entanto, frequentemente perdem de vista necessidades dependentes de contexto: hora do dia, estado emocional ou ambiente social. Um usuário que acabou de assistir “Shawshank Redemption” pode receber sugestões de mais dramas carcerários, quando na verdade deseja algo leve para relaxar.

    Uma abordagem híbrida supera essa lacuna ao combinar a capacidade de reconhecimento de padrões do aprendizado de máquina tradicional com o entendimento contextual e as habilidades conversacionais da IA generativa. A IA agente vai além, engajando usuários por meio de diálogo dinâmico e raciocínio sobre contexto de visualização. Esses agentes de recomendação sintetizam informações de múltiplas fontes — sinopses, avaliações, histórico de visualizações — e incorporam feedback do usuário em tempo real. É como conversar com um curador de conteúdo especializado que compreende tanto a obra quanto as preferências individuais.

    Imagem original — fonte: AWS

    Dois Casos de Uso Principais

    A solução apresentada pela AWS demonstra duas aplicações práticas. Em primeiro lugar, imagine dizer ao agente de IA que você quer algo divertido após um longo dia e receber recomendações que correspondam ao seu estado emocional, não apenas ao que já assistiu. Em segundo, imagine pausar um filme para perguntar “quem é esse ator?” ou “resuma o que acaba de acontecer?” e obter uma resposta instantânea.

    Construir esse assistente conversacional exige orquestração de processamento de voz em tempo real, gerenciamento de contexto, invocação de ferramentas e respostas curadas. Esse é um desafio complexo que pode ser simplificado com ferramentas de IA agente, como Strands Agents SDK, Amazon Bedrock AgentCore e Amazon Nova Sonic 2.0. O sistema utiliza um Protocolo de Contexto de Modelo (MCP) para entregar um concierge de entretenimento pessoal que compreende preferências do usuário via diálogo natural. Os exemplos de código da aplicação estão disponíveis em um repositório GitHub.

    Arquitetura da Solução

    A solução se concentra em dois fluxos principais: recomendação de filmes e análise de cenas de filmes.

    Fluxo de Interação do Usuário

    O usuário se autentica em uma interface web hospedada como site estático no Amazon S3 e entregue via Amazon CloudFront com Amazon Cognito. Uma conexão WebSocket é estabelecida do cliente para o servidor hospedado no AWS Fargate, exposto usando um endpoint CloudFront. As comunicações de sessão entre cliente e servidores ocorrem através dessa conexão.

    O servidor Fargate valida a conexão recebida e instancia uma sessão com Amazon Nova Sonic 2.0 para comunicações de streaming bidirecional. Comandos de voz do usuário são enviados ao modelo através da conexão WebSocket estabelecida. O contêiner Fargate usa um protocolo Smithy de streaming RPC bidirecional para comunicação com o modelo Nova Sonic.

    Imagem original — fonte: AWS

    As respostas do modelo são processadas pelo contêiner. O contêiner AWS Fargate gerencia eventos de ferramentas do Nova Sonic e inicia um fluxo de trabalho agente usando o servidor MCP para processar solicitações do usuário. O Amazon Bedrock AgentCore Gateway transforma funções AWS Lambda em ferramentas compatíveis com MCP para o agente.

    O Lambda utiliza modelos de compreensão Amazon Nova (micro, lite, pro) para processamento, com OpenSearch e S3 Vector funcionando como camadas de busca semântica e armazenamento. Os resultados retornam ao servidor via Amazon Bedrock AgentCore Gateway. O Fargate envia a resposta ao Amazon Nova Sonic para formular a resposta de voz final, que é transmitida à interface web pela conexão WebSocket.

    Interface de Usuário com Fala Natural

    O Amazon Nova Sonic 2.0 é um modelo de fala para fala que oferece conversas de voz em tempo real com latência baixa, humanamente naturais. Isso proporciona uma experiência com trocas fluidas que se parecem genuinamente conversacionais, transformando interações de IA de sessões rígidas de perguntas e respostas em diálogos dinâmicos e produtivos. Com suporte assíncrono para conclusão de tarefas, é possível manter diálogo fluido enquanto se processam tarefas complexas em background durante conversas ativas.

    O Nova Sonic 2.0 suporta nativamente entradas de texto e fala em streaming, oferecendo flexibilidade em como interagir com o assistente. Você pode definir a personalidade do assistente fornecendo um prompt de sistema no início da conversa. A capacidade de controlar a personalidade do assistente garante que as respostas permaneçam alinhadas à marca e dentro de limites apropriados, ajudando a proteger a reputação do serviço.

    Fluxo de Pré-processamento

    Os dados de catálogo, cenas de filmes e scripts são processados offline para gerar insights que alimentam os fluxos de personalização e análise de cena. Para demonstrar o recurso de personalização, a AWS criou 500 filmes de exemplo representando um catálogo. Os metadados — título, gênero, descrição — são convertidos em embeddings, representações numéricas que capturam significado. Isso habilita busca semântica, onde consultas são combinadas por significado em vez de palavras-chave exatas. Outros metadados, incluindo membros do elenco e datas de lançamento, são armazenados como atributos no mesmo índice dentro de um cluster Amazon OpenSearch Service com S3 Vector como camada de armazenamento.

    Para habilitar análise de cena com alta precisão, o processamento se divide em dois passos. Primeiro, a AWS utiliza Amazon Bedrock Data Automation para extrair insights-chave do conteúdo de vídeo. Os insights incluem resumo em nível de capítulo e timecodes correspondentes, transcrições, segmentos de áudio e mais. Adicionalmente, a funcionalidade de reconhecimento de celebridades no Amazon Rekognition identifica celebridades em capítulos. Segundo, os embeddings gerados de scripts de filmes extraídos via Amazon Bedrock Data Automation são usados para busca de similaridade semântica, servindo como base para o agente encontrar momentos semanticamente similares dentro do script.

    Fluxo de Recomendação de Filmes

    Imagem original — fonte: AWS

    Quando um usuário solicita recomendação de filme, o Amazon Nova Sonic reconhece a intenção e dispara a ferramenta apropriada. Uma função Lambda é acionada via AgentCore Gateway para processar a solicitação. A função primeiro recupera a afinidade do usuário de uma tabela DynamoDB para melhor compreender o perfil do usuário — preferências, gostos e padrões de visualização. Por exemplo, se o usuário assistiu à série Harry Potter, o sistema poderia atribuir maior afinidade a gêneros fantasia e aventura.

    Combinando afinidade do usuário e consulta, a solicitação é processada através de múltiplas chamadas de modelo de linguagem em sequência. Primeiro, um modelo classifica o tipo de busca baseado na intenção da consulta — recomendações genéricas, busca direta de filme, citações de filme ou algo completamente não relacionado. O Amazon Nova Micro é usado para essa tarefa dado seu benefício de desempenho de preço. A seguir, a consulta do usuário é enviada a outro modelo para ser reescrita, fornecendo uma consulta de busca mais rica e relevante para busca semântica contra dados de catálogo. Por exemplo, “estou procurando alguns filmes divertidos, o que recomenda?” seria reescrito para “filmes divertidos e entertaining que oferecem humor, excitação ou narrativa agradável”. Através de testes internos, a AWS descobriu que usar Amazon Nova Lite produzia respostas estruturadas de forma mais otimizada em custo.

    A saída de reescrita de consulta e prompts de classificação de intenção são usados como parâmetros para uma consulta Amazon OpenSearch Service. A consulta reescrita é convertida em um vetor de 1024 dimensões usando embeddings Nova para busca semântica. Adicionalmente, a consulta incorpora boosting de recência e popularidade para elevar shows mais recentes e com melhor desempenho nos rankings de recomendação. Os resultados retornam 30 filmes relevantes. Finalmente, o Amazon Rerank re-ordena os filmes recomendados baseado nos resultados de busca e na consulta do usuário reescrita para retornar os três filmes mais relevantes.

    Fluxo de Análise de Cena

    Semelhante ao fluxo de recomendação, a análise de cena utiliza os mesmos componentes. Imagine ter que fazer pausa e perder alguns minutos do seu show favorito — esse assistente forneceria um resumo. Também pode fornecer análise detalhada de uma cena, incluindo atores e o que está acontecendo.

    Quando o usuário pausa o filme para fazer pergunta, a aplicação captura metadados relevantes como timecode atual e título do filme, armazenando essas informações em uma tabela Amazon DynamoDB. Por exemplo, se o usuário pergunta “pode me dizer o que está acontecendo nessa cena?”, a aplicação referencia o log de visualização do usuário para localizar o estado mais recente e o filme sendo assistido.

    A análise de cena é tratada por ferramenta disparada pelo Amazon Nova Sonic baseado em compreensão contextual do diálogo do usuário. A solicitação é processada através de múltiplas chamadas de modelo de linguagem em sequência. Primeiro, Amazon Nova Micro classifica a intenção da análise de cena baseado na consulta do usuário. Baseado na funcionalidade de classificação de intenção, o fluxo de trabalho apropriado é disparado. Usando o log de visualização recuperado, o sistema extrai resumo de capítulo, transcrição e celebridades conhecidas correspondentes aos timecodes. Os insights de filme, incluindo detalhes de cena e scripts de filme, são processados via Amazon Bedrock Data Automation e armazenados em coleção Amazon OpenSearch Serverless para busca semântica e filtros.

    Os detalhes de cena extraídos são usados para encontrar os segmentos mais semanticamente similares do script de filme, e o detalhe do script fornece compreensão de cena enriquecida. O Amazon Nova Micro então resume as informações de cena anterior. A resposta é transformada em fala natural pelo Amazon Nova Sonic e transmitida ao usuário para completar a interação.

    Conclusão

    A solução apresentada demonstra um agente conversacional de IA que compreende e responde em interação de voz natural, ajudando usuários a descobrir filmes e séries de forma personalizada, enquanto fornece insights em tempo real durante visualização. O sistema analisa padrões individuais de visualização e histórico para criar perfis personalizados que impulsionam recomendações relevantes. Um usuário que assiste muitos filmes de ação pode receber recomendações relacionadas a ação quando pergunta sobre “filmes divertidos”.

    A capacidade do Nova Sonic 2.0 de entender linguagem natural, executar buscas de base de conhecimento semântica, gerenciar playlists e manter contexto através de conversas multi-turno representa um avanço significativo — de recomendações baseadas em feedback implícito para coleta explícita e conversacional de preferências. Isso cria uma experiência mais envolvente e intuitiva que pode impulsionar maior engajamento do usuário e retenção de serviço.

    Fonte

    Deliver hyper-personalized viewer experiences with an agentic AI movie assistant using Amazon Bedrock AgentCore and Amazon Nova Sonic 2.0 (https://aws.amazon.com/blogs/machine-learning/deliver-hyper-personalized-viewer-experiences-with-an-agentic-ai-movie-assistant-using-amazon-bedrock-agentcore-and-amazon-nova-sonic-2-0/)

  • AWS Security Hub agora disponível nas Regiões AWS GovCloud (US)

    Expansão do AWS Security Hub para Ambientes Governamentais

    O AWS Security Hub, solução unificada de segurança em nuvem da AWS, foi disponibilizado nas regiões AWS GovCloud (US-East) e AWS GovCloud (US-West). Essa expansão permite que organizações que operam em ambientes governamentais acessem uma plataforma robusta para priorizar questões de segurança críticas, responder rapidamente a incidentes e reduzir riscos de segurança em escala.

    Como o Security Hub Detecta e Prioriza Riscos

    O serviço funciona através da correlação e enriquecimento de sinais de segurança originários de múltiplas fontes: Amazon GuardDuty, Amazon Inspector e AWS Security Hub Gerenciamento de Postura de Segurança em Nuvem (CSPM). Essa integração permite que os riscos ativos sejam identificados e priorizados rapidamente no ambiente de nuvem.

    A entrega de análises de risco em tempo real e tendências avançadas transforma sinais de segurança correlacionados em insights práticos. Visualizações aprimoradas e enriquecimento contextual facilitam a interpretação desses dados por equipes de segurança.

    Capacidades Principais do Serviço

    O AWS Security Hub oferece um conjunto abrangente de funcionalidades para organizações que precisam de conformidade com requisitos governamentais:

    • Implantação centralizada: É possível ativar o Security Hub para contas individuais ou em toda a organização com gerenciamento centralizado
    • Inventário de segurança: Inclui achados de exposição e um inventário de recursos focado em segurança
    • Visualização de caminhos de ataque: O serviço mapeia automaticamente como potenciais ameaças, vulnerabilidades e configurações incorretas poderiam ser encadeadas por adversários para comprometer recursos críticos
    • Fluxos de trabalho automatizados: Resposta automatizada para eventos de segurança

    Modelo de Preços Simplificado

    A AWS consolidou o modelo de preços do Security Hub, combinando as cobranças de múltiplos serviços de segurança da AWS em uma única estrutura. Essa abordagem oferece maior previsibilidade de custos e simplifica o gerenciamento financeiro das soluções de segurança.

    Próximos Passos

    Para começar com o AWS Security Hub, é possível acessar o console do AWS Security Hub ou consultar a página do produto. Para conhecer a lista completa de regiões AWS onde o Security Hub está disponível, consulte a lista de serviços regionais da AWS.

    Fonte

    AWS Security Hub is now available in AWS GovCloud (US) Regions (https://aws.amazon.com/about-aws/whats-new/2026/03/aws-security-hub-govcloud-us-regions/)

  • Detecção de Erupções Solares com Redes LSTM no SageMaker AI e Dados ESA STIX

    Detecção de Erupções Solares através de Aprendizado Profundo

    O monitoramento eficaz de erupções solares demanda análise sofisticada de emissões de raios-X em múltiplos espectros de energia. A detecção de anomalias baseada em aprendizado de máquina constitui uma ferramenta poderosa para identificar padrões significativos que possam indicar atividade solar notável. Pela identificação de assinaturas de radiação distintas, características fundamentais de eventos solares podem ser detectadas, analisadas e compreendidas de forma abrangente. Esses padrões detectados são essenciais para diversas aplicações, incluindo previsão de clima espacial, investigações de física solar e planejamento de operações de satélites.

    Nos últimos anos, as capacidades de monitoramento solar expandiram dramaticamente, gerando volumes sem precedentes de dados de medições de raios-X. Conforme essa quantidade de dados continua crescendo, os métodos analíticos devem evoluir para processar eficientemente esses conjuntos massivos enquanto capturam até mesmo as variações mais sutis no comportamento solar. Arquiteturas avançadas de aprendizado profundo, particularmente as redes de Memória de Longo Prazo (LSTM — Long Short-Term Memory), surgiram como soluções altamente capazes para esses desafios.

    Visão Geral da Solução

    A AWS apresenta uma implementação de redes neurais LSTM para detecção de anomalias em dados de raios-X multicanal coletados pelo instrumento Espectrômetro/Telescópio para Imagens de Raios-X (STIX — Spectrometer/Telescope for Imaging X-rays). A análise enfatiza a detecção de padrões anormais em diversas faixas de energia: baixa (4–10 keV), média (10–25 keV) e alta (25+ keV). Essa abordagem multicanal facilita monitoramento compreensivo da atividade solar e possibilita identificação robusta de potenciais eventos de erupção através de análise sofisticada de padrões de emissão de raios-X.

    O post demonstra como usar o Amazon SageMaker AI para construir e implantar um modelo de aprendizado profundo destinado a detectar erupções solares utilizando dados do instrumento STIX da Agência Espacial Europeia. O SageMaker AI emprega a Floresta de Cortes Aleatórios (RCF — Random Cut Forest), um algoritmo de aprendizado não supervisionado que detecta pontos de dados anormais através da atribuição de pontuações de anomalia baseadas na densidade e dispersão dos pontos de dados.

    Conceitos Fundamentais

    Canais de Energia de Raios-X em Observações Solares

    As emissões de raios-X nos dados STIX são medidas em múltiplas faixas de energia, categorizadas em canais baixo (4–10 keV), médio (10–25 keV) e alto (25+ keV). Essa abordagem multicanal permite monitoramento abrangente da atividade solar em diferentes níveis de energia. As faixas de energia fornecem informações cruciais sobre diversos aspectos das erupções solares, desde sua iniciação até intensidade máxima. Ao analisar padrões nesses canais, é possível identificar diferentes fases da evolução de erupções solares e caracterizar sua intensidade.

    Canais de energia mais elevados tipicamente indicam atividade de erupção mais intensa, enquanto canais de energia inferior podem capturar eventos precursores ou fenômenos pós-erupção. Essa abordagem multi-espectral permite detecção precoce do início da erupção e avaliação precisa da magnitude e duração da erupção.

    Redes LSTM e Dependências Temporais

    As redes LSTM diferem de redes neurais tradicionais por manterem um estado de memória interna que permite capturar dependências de longo prazo em dados de séries temporais. Essa qualidade única as posiciona como uma variante de Redes Neurais Recorrentes (RNN — Recurrent Neural Network). A capacidade das LSTM é particularmente valiosa para detecção de erupções solares, onde padrões podem se desenvolver ao longo de períodos estendidos.

    Uma arquitetura LSTM opera através de um sistema sofisticado de portões (gates) e estados. Em seu núcleo, o portão de entrada controla o fluxo de novas informações na rede, determinando quais pontos de dados são significativos o suficiente para serem armazenados. Trabalhando em conjunto, o portão de esquecimento avalia informações existentes e decide quais elementos devem ser descartados, prevenindo acúmulo de dados irrelevantes. Essas decisões se refletem no estado da célula, que serve como memória de longo prazo da rede, mantendo informações cruciais durante o processamento da sequência. O portão de saída então regula qual informação desse estado de célula deve ser apresentada como saída a cada passo de tempo. Essa arquitetura sofisticada permite ao modelo aprender relacionamentos intrincados entre diferentes canais de energia enquanto mantém coerência temporal na análise.

    Análise de Séries Temporais e Detecção de Anomalias

    O sistema de detecção de anomalias processa dados de séries temporais multidimensionais, onde cada dimensão corresponde a um canal de energia diferente. O modelo LSTM aprende padrões normais nos dados de emissão de raios-X e identifica desvios que poderiam indicar eventos de erupção solar. Essas anomalias podem representar aumentos súbitos de intensidade, padrões espectrais incomuns ou outras assinaturas de atividade solar.

    Para detecção confiável de erupções, o LSTM analisa características temporais e espectrais dos dados de raios-X entre canais. A análise temporal identifica mudanças súbitas ou padrões incomuns na intensidade de emissão ao longo do tempo. A análise espectral examina a relação entre diferentes canais de energia, pois erupções solares frequentemente produzem padrões característicos em múltiplas faixas de energia. A combinação de reconhecimento de padrões baseado em LSTM e análise multicanal cria um framework robusto para detecção automatizada de erupções solares.

    Arquitetura da Solução

    A arquitetura da solução implementa detecção de anomalias para dados do STIX do Solar Orbiter da ESA utilizando o algoritmo LSTM. A solução emprega a abordagem “Bring Your Own Script” (BYOS) com o Amazon SageMaker AI, permitindo utilizar scripts de treinamento customizados enquanto se aproveita a infraestrutura gerenciada do SageMaker AI.

    Com BYOS, é possível utilizar frameworks ML preferidos (neste caso, PyTorch), manter controle sobre a lógica de treinamento, continuar usando a infraestrutura de treinamento do SageMaker AI e suas capacidades de escalabilidade, e implantar o modelo LSTM customizado sem necessidade de gerenciar contêineres. Para usar essa abordagem, você faz upload do script Python para o SageMaker AI e o especifica como ponto de entrada ao criar um trabalho de treinamento.

    O pipeline de dados inicia com medições brutas do STIX (Espectrômetro/Telescópio para Imagens de Raios-X) armazenadas em formato FITS. Essas observações passam por processamento inicial em um ambiente JupyterLab, que serve como plataforma principal de desenvolvimento e análise. O ambiente hospeda notebooks Python customizados que lidam com a conversão de dados FITS para CSV e executam algoritmos avançados de detecção.

    No coração do sistema situa-se o pipeline de processamento de redes neurais. O workflow começa com preparação de dados no JupyterLab, seguido pelo treinamento do modelo customizado CrossChannelLSTM implementado em PyTorch. Esse modelo processa emissões de raios-X em múltiplas faixas de energia (4–10 keV, 10–25 keV e 25+ keV). Após a fase de treinamento, o sistema analisa sequências temporais para identificar potenciais assinaturas de erupção solar através de detecção de anomalias. O pipeline culmina na geração de visualizações abrangentes, englobando gráficos de análise temporal, diagramas de evolução de energia e exibições de correlação entre canais.

    Implementação e Configuração

    Pré-requisitos

    Antes de implementar o sistema de detecção de erupções solares, certifique-se de possuir as seguintes ferramentas e dependências instaladas:

    Requisitos da AWS:

    • Uma conta da AWS com permissões apropriadas
    • Função IAM com políticas de acesso apropriadas ao SageMaker AI e Amazon S3 (Simple Storage Service)
    • Bucket Amazon S3 para armazenar dados e artefatos de modelo
    • Acesso ao console Amazon SageMaker AI

    Serviços AWS Necessários:

    • Amazon SageMaker AI (recomendado: instância JupyterLab ml.m5.2xlarge)
    • Amazon S3
    • AWS IAM Identity Center

    Ambiente de Desenvolvimento:

    • Python 3.7 ou posterior
    • Pacotes Python essenciais incluídos no script Python fornecido e arquivo de requisitos
    • Para o ambiente JupyterLab: notebooks Amazon SageMaker AI Studio
    • Acesso a dados STIX em formato FITS
    • RAM suficiente para processar grandes conjuntos de dados (mínimo recomendado: 16GB)
    • Suporte GPU recomendado para treinamento mais rápido do modelo
    • Compreensão básica de programação Python e conceitos de aprendizado profundo

    Custos Estimados:

    • Instância SageMaker AI ml.m5.4xlarge: aproximadamente USD 0,922 por hora
    • Armazenamento S3: aproximadamente USD 0,023 por GB por mês
    • Custo total estimado para executar essa solução: aproximadamente USD 10–15 para algumas horas de experimentação

    Configurando a Solução

    O processo de configuração envolve configurar o ambiente Python do Amazon SageMaker AI, onde toda análise de dados e treinamento de modelo é executado. No console do Amazon SageMaker AI, abra a página de detalhes do domínio SageMaker AI. Abra JupyterLab e crie uma nova instância de notebook Python para este projeto.

    Quando o ambiente estiver pronto, abra um terminal no JupyterLab do Amazon SageMaker AI para clonar o repositório do projeto utilizando os seguintes comandos:

    git clone https://github.com/aws-samples/sample-SageMaker-ai-lstm-anomaly-detection-solar-orbiter.git
    cd sample-SageMaker-ai-lstm-anomaly-detection-solar-orbiter

    Instale as bibliotecas Python necessárias:

    pip install -r requirements.txt

    Este processo configura as dependências necessárias para executar análise de detecção de anomalias nos dados do sensor Solar Orbiter.

    Executando a Detecção de Anomalias

    Atualize as variáveis bucket_name e file_name no script com seu bucket S3 e nomes de arquivo de dados. Execute o script no JupyterLab como notebook Jupyter ou como script Python:

    python ESA_SolOrb_AD.py

    Upon execution, the notebook or script performs a series of automated tasks to analyze the solar X-ray data. Upon execution, o notebook ou script realiza uma série de tarefas automatizadas para analisar os dados de raios-X solar. Começa carregando e pré-processando o arquivo FITS, convertendo para formato CSV e normalizando os dados entre canais de energia. Em seguida, treina o modelo CrossChannelLSTM usando PyTorch, estabelecendo a fundação para o sistema de detecção de anomalias. Quando o modelo está operacional, processa os dados de raios-X multicanal para identificar potenciais eventos de erupção solar através de análise de padrões em diferentes faixas de energia (4–10 keV, 10–25 keV e 25+ keV).

    Estrutura e Configuração do Código

    A implementação Python centra-se em um pipeline de detecção de erupções solares, estruturado no script principal. Em seu núcleo estão duas classes principais: CrossChannelLSTM e CrossChannelDataset, que juntas orquestram o workflow desde ingestão de dados até visualização. Essas classes trabalham em conjunto para processar dados STIX de raios-X e identificar potenciais eventos de erupção solar.

    O método explore_ql_lightcurve lida com a ingestão de dados inicial e pré-processamento, convertendo arquivos FITS para formato CSV e garantindo que as medições de raios-X estejam adequadamente formatadas para análise. O método plot_lightcurve cria visualizações iniciais dos dados em diferentes canais de energia. O método print_channel_stats oferece análise estatística para cada faixa de energia.

    A classe CrossChannelLSTM implementa a arquitetura de rede neural, com múltiplas camadas LSTM e regularização dropout. A classe CrossChannelDataset gerencia preparação de dados e sequenciamento para o modelo. O método detect_cross_channel_anomalies então utiliza esse modelo treinado para identificar padrões incomuns nas emissões de raios-X entre diferentes faixas de energia.

    Para visualização, os métodos plot_cross_channel_anomalies e plot_flare_anomalies criam gráficos detalhados destacando anomalias detectadas, padrões de evolução temporal e distribuições de faixas de energia. Essas visualizações incluem análise de séries temporais, diagramas de evolução temporal-energética e gráficos de correlação entre canais. Juntos, esses componentes criam um pipeline compreensivo para processar dados de raios-X multicanal e identificar potenciais eventos de erupção solar que justificam investigação adicional.

    Parâmetros de Configuração

    Os parâmetros de arquitetura do modelo LSTM e treinamento influenciam significativamente a detecção de eventos de erupção solar. Os seguintes parâmetros podem ser modificados:

    Parâmetros de Arquitetura do Modelo:

    • hidden_size: Tamanho das camadas ocultas LSTM (padrão: 128–256)
    • num_layers: Número de camadas LSTM (padrão: 2–3)
    • dropout_rate: Taxa de regularização dropout (padrão: 0,2)
    • sequence_length: Comprimento das sequências de entrada (padrão: 30–50)

    Parâmetros de Treinamento:

    • batch_size: Número de sequências por lote de treinamento (padrão: 32)
    • num_epochs: Número de iterações de treinamento (padrão: 15–20)
    • learning_rate: Taxa de atualização de parâmetros do modelo (padrão: 0,001)
    • threshold_multiplier: Sensibilidade de detecção de anomalias (padrão: 1,5)

    Para desempenho aprimorado em configurações de hardware padrão, recomenda-se: hidden_size=256, num_layers=3, dropout_rate=0.2, sequence_length=30, batch_size=32, num_epochs=20.

    Os requisitos de hardware podem impactar significativamente o tempo de treinamento e desempenho do modelo. Aceleração GPU é recomendada para treinamento mais rápido, embora execução apenas com CPU seja suportada. As especificações mínimas recomendadas incluem 16 GB RAM e 4 cores CPU.

    Dados e Resultados

    Fonte de Dados

    O script utiliza dados públicos do STIX (Espectrômetro/Telescópio para Imagens de Raios-X) do Solar Orbiter da ESA em formato FITS. Os dados contêm medições de raios-X em múltiplos canais de energia, variando de 4 keV até mais de 25 keV. Os arquivos FITS incluem: dados de séries temporais para cada canal de energia, informações de faixa de energia (4–10 keV, 10–25 keV, 25+ keV), índices de controle e informações de cronometragem, dados de erro de medição e contagens de disparo entre canais.

    Os dados são organizados em uma estrutura hierárquica dentro do arquivo FITS, com unidades de dados de cabeçalho separadas (HDUs) contendo diferentes aspectos das medições. O script converte esses dados para formato CSV com colunas para timestamps, contagens por canal de energia e medições de erro associadas. Ao preparar seus próprios dados para análise, certifique-se de que seguem as especificações de formato de dados STIX e contêm medições completas em todos os canais de energia. O sistema espera dados de séries temporais contínuos com taxas de amostragem consistentes para detecção confiável de anomalias.

    Análise de Resultados

    O sistema de detecção de anomalias baseado em LSTM gera visualizações compreensivas em múltiplos canais de energia. A análise abrange cinco faixas de energia distintas variando de 4,0 keV até 84,0 keV, com cada canal revelando diferentes aspectos da atividade solar. O canal 0 (4,0–10,0 keV) mostra atividade de linha de base em torno de 10³ centissegundos com picos significativos chegando a 10⁶ centissegundos. O canal 1 (10,0–15,0 keV) exibe padrões similares porém com contagens de linha de base ligeiramente menores. O canal 2 (15,0–25,0 keV) demonstra distinção mais clara entre períodos de fundo e eventos. O canal 3 (25,0–50,0 keV) mostra assinaturas fortes de eventos com ruído de fundo menor. O canal 4 (50,0–84,0 keV) captura as emissões de energia mais alta com razão sinal-ruído muito clara.

    O sistema identificou 238 pontos anormais ao longo do conjunto de dados, primariamente agrupados em torno de três eventos principais em aproximadamente 2 milhões, 3 milhões e 5 milhões de centissegundos na série temporal. Esses eventos são particularmente notáveis conforme aparecem simultaneamente em múltiplos canais de energia, sugerindo atividade significativa de erupção solar. O painel inferior mostra o Erro de Predição LSTM com limiar de anomalia de 0,0112. Pontos excedendo esse limiar (marcados em vermelho) correspondem a mudanças súbitas de intensidade em múltiplos canais. Os maiores erros de predição coincidem com o início de eventos principais, onde o modelo identifica mudanças rápidas em emissões de raios-X.

    Limpeza de Recursos

    Após executar a análise e salvar os gráficos para S3, execute as seguintes etapas de limpeza para gerenciar recursos do sistema: feche qualquer figura matplotlib aberta para liberar memória com plt.close('all'). Limpe quaisquer arquivos temporários criados durante geração de gráficos. Se executando no JupyterLab, você pode desligar kernels não utilizados através do painel Running Terminals and Kernels para liberar recursos do sistema.

    Considere remover qualquer arquivo FITS grande que foi convertido para CSV se não mais necessário para análise. Se você modificou o código para salvar resultados intermediários, certifique-se de que esses arquivos temporários também sejam removidos se não mais necessários.

    Se usando JupyterLab e desejando evitar cobranças adicionais, limpe recursos de instância de notebook Amazon SageMaker AI executando o notebook Python JupyterLab LSTM e delete qualquer endpoint SageMaker AI criado. Você também pode deletar seus dados S3. Aqui estão alguns comandos Python para fazer isso:

    Deletar endpoints SageMaker AI:

    import boto3
    sagemaker = boto3.client('sagemaker')
    sagemaker.delete_endpoint(EndpointName='solar-flare-endpoint')

    Parar instância de notebook SageMaker AI:

    sagemaker.stop_notebook_instance(NotebookInstanceName='solar-flare-notebook')

    Deletar dados de treinamento e artefatos do S3:

    s3 = boto3.client('s3')
    s3.delete_object(Bucket='your-bucket', Key='solar-flare-data/')

    Economia de custo estimada: aproximadamente USD 22 por dia ao parar a instância ml.m5.4xlarge.

    Conclusão

    Este artigo demonstrou como redes neurais LSTM podem detectar efetivamente anomalias em dados de raios-X solares do instrumento STIX do Solar Orbiter da ESA. Ao analisar padrões em múltiplos canais de energia variando de 4,0 até 84,0 keV, foi demonstrado como aprendizado profundo pode aprimorar nossa compreensão de eventos de erupção solar e suas características. O modelo customizado CrossChannelLSTM processa com sucesso dados complexos e multidimensionais de raios-X, identificando 405 eventos anormais em diferentes faixas de energia. Os resultados mostram detecção clara de eventos solares maiores, particularmente visíveis em torno da marca de 2 milhões de centissegundos onde se observam aumentos significativos de intensidade em todos os canais de energia.

    A capacidade do sistema detectar anomalias simultaneamente em múltiplos canais oferece validação forte de eventos genuínos de erupção solar, em contraste com artefatos instrumentais ou ruído. Através de processamento eficiente em lotes e manipulação de dados normalizada, é possível analisar dados de observação solar em larga escala efetivamente, e a abordagem de visualização possibilita identificação rápida de potenciais eventos de erupção solar que justifiquem investigação adicional.

    Embora essa solução se concentre em análise de dados STIX, a abordagem possui aplicações amplas throughout física solar e previsão de clima espacial. A mesma arquitetura poderia ser adaptada para diversos tipos de observações solares, monitoramento de clima espacial e outras análises de dados astronômicos de séries temporais. Essa integração de aprendizado profundo com física solar cria uma plataforma robusta e escalável para análise de clima espacial, que está se tornando cada vez mais valiosa conforme dependemos mais de tecnologias baseadas no espaço.

    Olhando para frente, essa solução abre muitas possibilidades para aprimoramento e expansão. Detecção de erupções em tempo real poderia ser implementada para monitoramento solar ao vivo, fornecendo alertas imediatos durante eventos significativos. O sistema pode ser aprimorado incorporando faixas de comprimento de onda adicionais e dados de sensores, e serviços de alertas automatizados podem ser desenvolvidos para fornecer notificação imediata de erupções solares detectadas. Desenvolvimentos futuros podem incluir extensão da análise para incorporar capacidades preditivas para previsão de erupções solares e criação de métricas customizadas adaptadas a requisitos específicos de monitoramento de clima espacial.

    O código e detalhes de implementação estão disponíveis no repositório GitHub, para que você possa adaptar e aprimorar a solução para suas necessidades específicas de pesquisa em física solar. Para operações de clima espacial, a combinação de aprendizado profundo e análise multicanal possui forte potencial para desempenhar um papel cada vez mais crucial na compreensão e previsão de atividade solar.

    Para aprender mais sobre os serviços da AWS utilizados nessa solução, consulte o Guia para começar com Amazon SageMaker AI, Treinar um Modelo com Amazon SageMaker e o Guia do Desenvolvedor Amazon SageMaker AI.

    Fonte

    Build a solar flare detection system on SageMaker AI LSTM networks and ESA STIX data (https://aws.amazon.com/blogs/machine-learning/build-a-solar-flare-detection-system-on-sagemaker-ai-lstm-networks-and-esa-stix-data/)

  • CloudWatch agora centraliza logs de múltiplas contas e regiões com base na origem dos dados

    Centralização de logs com flexibilidade por origem de dados

    A AWS anunciou uma expansão significativa nas capacidades de centralização do CloudWatch. O serviço agora permite que clientes centralizem logs com base na origem e tipo dos dados, além da abordagem anterior que se limitava aos nomes dos grupos de logs.

    Esta melhoria facilita a cópia de dados de logs de múltiplas contas AWS e regiões para uma única conta de destino, usando regras de centralização mais inteligentes e dinâmicas. A descoberta de origem e tipo de dados acontece automaticamente para logs de serviços AWS (como CloudTrail, VPC e EKS) e, para aplicações customizadas, baseada em tags atribuídas aos grupos de logs.

    Como funciona a seleção por origem de dados

    A grande vantagem dessa funcionalidade é a simplificação na gestão de logs em ambientes complexos. Equipes não precisam mais manter listas atualizadas de nomes de grupos de logs para criar regras de centralização. Em vez disso, definem critérios baseados na origem dos dados.

    Por exemplo, uma equipe de segurança central pode criar uma regra única que automaticamente centraliza todos os logs provenientes de CloudTrail e VPC em toda a organização — sem necessidade de conhecer ou gerenciar os nomes individuais de cada grupo de logs espalhado pelas contas.

    Tipos de logs suportados

    A seleção por origem funciona com categorias importantes como:

    • VPC Flow Logs
    • EKS Audit Logs
    • CloudTrail Logs

    Como começar

    Para aproveitar essa funcionalidade, basta criar ou modificar uma regra de centralização no console do CloudWatch ou via AWS CLI e AWS SDKs. O processo envolve especificar os critérios de seleção de origem de dados na configuração da regra de centralização.

    A seleção por origem de dados está disponível em todas as regiões comerciais AWS onde a centralização de logs do CloudWatch já opera. A precificação padrão do CloudWatch Logs continua aplicável para ingestão, armazenamento e transferência de dados.

    Quando usar essa funcionalidade

    Organizações com arquiteturas distribuídas em múltiplas contas e regiões são as maiores beneficiárias. Especialmente úteis para:

    • Equipes de segurança que precisam centralizar registros de auditoria
    • Operações que consolidam logs para análise e compliance
    • Ambientes que escalam dinamicamente com novos grupos de logs criados frequentemente

    Para mais detalhes técnicos, consulte a documentação oficial de centralização do CloudWatch Logs.

    Fonte

    Amazon CloudWatch now supports multi-account and region log centralization based on data source (https://aws.amazon.com/about-aws/whats-new/2026/03/cloudwatch-centralization-datasource/)

  • CloudTroop Weekly #005 — 2026-w13





    CloudTroop Weekly #005 — 2026-w13

    29 de março de 2026

    Resumo da Semana

    A semana foi dominada por dois eixos: infraestrutura para IA em produção e segurança de acesso na AWS. No lado de IA, SageMaker ganhou GPU reservada para inferência, o Bedrock passou a suportar fine-tuning com APIs compatíveis OpenAI e o Amazon Nova chegou a 0,03% de alucinações — número que abre portas para setores regulados. Em segurança, políticas IAM e controle de visibilidade no console voltaram ao centro do debate. O EKS subiu o patamar com SLA 99,99% e nova camada 8XL. Semana densa, com impacto direto em arquitetura, custo e compliance.

    O que muda na prática

    • GPU reservada no SageMaker traz previsibilidade de custo e disponibilidade para endpoints de inferência em produção — fim da roleta de capacidade em picos de demanda.
    • EKS agora oferece SLA de 99,99% com camada 8XL: contratos de disponibilidade para workloads críticos em Kubernetes precisam ser revistos à luz dessa nova garantia.
    • Controle de visibilidade de serviços e regiões no Console AWS permite reduzir superfície de ataque sem custo adicional — mudança operacional que reforça menor privilégio de forma imediata.

    Ações da semana

    • Revise as políticas IAM do seu ambiente multi-conta e mapeie quais usuários enxergam serviços e regiões desnecessários no Console — o artigo do rank 4 traz o passo a passo.
    • Se você opera endpoints de inferência com picos previsíveis, avalie agora a capacidade reservada de GPU no SageMaker e compare com o custo atual sob demanda antes do próximo ciclo de orçamento.

    Top 10 da Semana

    1

    Políticas de IAM: como e quando usá-las na sua estratégia

    Dominar os tipos de políticas IAM é base para qualquer estratégia de segurança multi-conta e afeta diretamente decisões de arquitetura e compliance.

    Para quem: Arquitetos de segurança, engenheiros cloud e times de plataforma que gerenciam ambientes multi-conta na AWS.

    Segurança IAM

    2

    Amazon EKS: SLA 99.99% e nova camada 8XL para clusters

    O novo SLA e a camada 8XL mudam o patamar de confiabilidade do EKS para workloads críticos, impactando decisões de arquitetura e contratos de disponibilidade.

    Para quem: Engenheiros de plataforma e arquitetos que operam clusters Kubernetes de grande escala em produção.

    Kubernetes Containers

    3

    IA Agentic em Serviços Financeiros: 7 princípios de segurança

    Com IA autônoma avançando em setores regulados, os sete princípios apresentados oferecem um framework prático para conformidade e accountability que vai além do setor financeiro.

    Para quem: Arquitetos de segurança e líderes técnicos que estão avaliando ou implantando sistemas de IA agentic em ambientes regulados.

    IA Segurança

    4

    AWS Console: controle de visibilidade de serviços e regiões

    Limitar o que usuários enxergam no console reduz superfície de ataque, simplifica onboarding e reforça o princípio do menor privilégio sem custo adicional.

    Para quem: Administradores de nuvem e times de segurança que gerenciam acesso de múltiplos usuários ao AWS Management Console.

    Segurança Governança

    5

    Eliminando alucinações em LLMs com Amazon Nova: 0,03% de erro

    Uma taxa de alucinação de 0,03% via fine-tuning não-generativo abre caminho real para uso de LLMs em saúde e finanças, onde confiabilidade é requisito regulatório.

    Para quem: Cientistas de dados e arquitetos de IA que desenvolvem soluções para setores regulados como saúde, finanças e jurídico.

    IA Confiabilidade

    6

    Aprendizado por Reforço no Bedrock com APIs compatíveis OpenAI

    Suporte a RFT com APIs OpenAI-compatíveis reduz a barreira de entrada para customização avançada de modelos, permitindo reaproveitamento de pipelines existentes.

    Para quem: Engenheiros de ML e times de produto que já usam APIs OpenAI e querem customizar modelos em escala empresarial na AWS.

    IA MLOps

    7

    AWS Neuron DRA: alocação dinâmica de GPUs no EKS

    Separar decisões de infraestrutura de aceleradores das preocupações de ML no Kubernetes reduz fricção operacional e otimiza custos de instâncias Trainium.

    Para quem: Engenheiros de MLOps e plataforma que orquestram workloads de treinamento e inferência de IA em clusters EKS.

    IA Infraestrutura

    8

    SageMaker: capacidade de GPU reservada para inferência

    Reservar GPU para endpoints de inferência traz previsibilidade de custo e disponibilidade, resolvendo um dos maiores pontos de dor em produção de modelos.

    Para quem: Times de MLOps e engenheiros de infraestrutura que gerenciam endpoints de inferência com picos de demanda previsíveis.

    MLOps Custos

    9

    Agent Plugin para AWS Serverless acelera dev com IA

    Integrar assistentes de codificação com IA diretamente ao fluxo serverless reduz erros de configuração e acelera o ciclo de desenvolvimento de funções e APIs.

    Para quem: Desenvolvedores serverless que usam ferramentas como Cursor ou Claude Code e querem produtividade maior no ciclo de build e deploy.

    Serverless Produtividade

    10

    CloudWatch Logs Infrequent Access ganha OpenSearch PPL e SQL

    Consultar logs arquivados com SQL e PPL sem mover dados para outro serviço reduz custo de análise e simplifica investigações de segurança e compliance.

    Para quem: Engenheiros de operações e times de segurança que analisam logs históricos e precisam equilibrar custo e capacidade analítica.

    Observabilidade Custos


  • CloudWatch Logs expande capacidades de análise com suporte a OpenSearch PPL e SQL na classe Infrequent Access

    Novas capacidades de análise no CloudWatch Logs

    A AWS anunciou expansão das funcionalidades de análise e proteção de dados para a classe de ingestão Infrequent Access (Logs IA) do CloudWatch Logs. Com as novidades, o serviço agora suporta proteção de dados, Piped Processing Language (PPL) do OpenSearch e SQL do OpenSearch. Essas melhorias permitem que as organizações realizem análises mais flexíveis e protejam dados sensíveis ao consolidar logs de forma econômica e nativa na plataforma.

    O que é Logs IA e para quem serve

    A classe Infrequent Access foi projetada especificamente para consolidar logs que são consultados ocasionalmente, como investigações forenses ou análises pontuais. Antes dessa atualização, Logs IA oferecia consultas através da Logs Insights Query Language, exportação para S3 e criptografia — tudo com preço menor por GB em comparação à classe Standard.

    Casos de uso ideais

    A classe é particularmente valiosa para troubleshooting ad-hoc e análise forense em logs que não são acessados regularmente, permitindo reduzir custos sem comprometer a capacidade de investigar problemas quando necessário.

    Capacidades recém-adicionadas

    Consultas avançadas com OpenSearch SQL e PPL

    Com o lançamento, os clientes podem agora executar consultas usando OpenSearch SQL e Piped Processing Language (PPL) do OpenSearch. Isso expande significativamente as possibilidades de análise, permitindo que equipes trabalhem com linguagens de consulta mais sofisticadas e familiares, caso já utilizem OpenSearch em seus ambientes.

    Proteção e mascaramento de dados sensíveis

    A funcionalidade de data protection permite que as organizações detectem e mascararem automaticamente informações sensíveis dentro dos logs. Esse recurso auxilia na conformidade com requisitos de segurança e regulamentações de proteção de dados, um passo importante para qualquer empresa que trabalha com informações críticas.

    Próximos passos

    Para quem deseja explorar essas capacidades, a AWS disponibiliza documentação detalhada sobre preços do CloudWatch Logs IA e um guia de usuário. Para conferir disponibilidade regional do recurso, consulte o AWS Builder Center através deste link.

    Fonte

    Amazon CloudWatch Logs now supports data protection, OpenSearch PPL and OpenSearch SQL for the Infrequent Access ingestion class (https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-cloudwatch-infrequent-access-log-class/)

  • AWS Management Console agora permite controlar a visibilidade de serviços e regiões

    Nova funcionalidade de personalização no AWS Management Console

    A AWS anunciou a disponibilidade geral de uma funcionalidade importante para administradores de contas: as configurações de Serviços Visíveis (Visible Services) e Regiões Visíveis (Visible Regions) no AWS Management Console.

    Essa novidade permite que você customize quais serviços e regiões aparecem no Console de Gerenciamento para os usuários autorizados em sua conta. Na prática, isso significa facilitar a navegação dos seus usuários, permitindo que eles vejam apenas o que realmente precisam usar, reduzindo confusão e tornando o ambiente mais intuitivo.

    Como funciona a configuração

    As configurações podem ser ajustadas diretamente no AWS Management Console. Para isso, basta acessar a seção de Configurações Unificadas (Unified Settings) dentro da aba de Configurações da Conta (Account Settings).

    Além da interface gráfica, a AWS oferece formas de configurar essas opções programaticamente. É possível usar a funcionalidade de Personalização da Experiência do Usuário (User Experience Customization — UXC) através de várias ferramentas:

    • Interface de Linha de Comando da AWS (AWS Command Line Interface — CLI)
    • Kits de Desenvolvimento de Software da AWS (AWS Software Development Kits — SDKs)
    • Kit de Desenvolvimento em Nuvem da AWS (AWS Cloud Development Kit — CDK)
    • AWS CloudFormation

    Disponibilidade e custos

    As configurações de Serviços Visíveis e Regiões Visíveis estão disponíveis em todas as Regiões Comerciais da AWS, e não há custo adicional para usar essa funcionalidade.

    Próximos passos

    Para explorar essa nova capacidade em detalhes, a AWS disponibiliza documentação completa. Você pode consultar a documentação sobre Personalização da Experiência do Usuário e o guia de API para implementar essas configurações em suas operações.

    Fonte

    AWS Management Console now supports settings to control service and Region visibility (https://aws.amazon.com/about-aws/whats-new/2026/03/account-customizations-console/)

  • Preparando-se para IA Agentic: Uma Abordagem para Serviços Financeiros

    O Desafio da IA Agentic em Instituições Financeiras

    A implementação de sistemas de inteligência artificial com capacidade autônoma—conhecida como IA agentic—em serviços financeiros apresenta um duplo desafio. Instituições precisam navegar um ambiente regulatório em constante evolução, conformando-se a estruturas como SR 11-7 nos EUA, SS1/23 no Reino Unido e diretrizes do Banco Central Europeu, enquanto lidam simultaneamente com considerações únicas de segurança introduzidas por esses sistemas autônomos.

    Diferentemente de sistemas de software tradicionais, a IA agentic pode tomar decisões autônomas e executar ações que impactam clientes, operações e reputação institucional. Essa autonomia exige uma abordagem de segurança que vai além dos controles convencionais. Organizações que seguem estruturas estabelecidas como ISO 27001 e Estrutura de Cibersegurança do NIST possuem fundação sólida, mas precisam aumentar seus controles tradicionais com medidas específicas para IA.

    Por Que Controles Tradicionais Não são Suficientes

    A natureza não-determinística dos sistemas de IA, sua capacidade de atuar com autonomia significativa e a complexidade das interações entre múltiplos agentes introduzem novas dimensões de risco que devem ser cuidadosamente gerenciadas. Em serviços financeiros, é essencial ter clareza na explicabilidade e accountability para gestão eficaz de risco em modelos.

    Quando agentes de IA tomam decisões ou executam ações em nome da organização, é necessário ter visibilidade clara sobre o que foi feito, por que foi feito e quem—ou o quê—foi responsável. Essa transparência ajuda a manter confiança, cumprir obrigações regulatórias e implementar IA de forma responsável, alinhado com as práticas de IA Responsável da AWS.

    Dois Pilares Essenciais: Observabilidade e Controle de Acesso

    A abordagem proposta pela AWS se concentra em dois habilitadores críticos: observabilidade abrangente dos fluxos de trabalho agentic e controle fino sobre permissões de acesso às ferramentas dos agentes. Juntas, essas capacidades fornecem a fundação para explicabilidade e criam um ambiente de controle que facilita accountability.

    O documento apresenta sete princípios de design que servem a um propósito duplo: orientar arquitetos de solução durante o design de sistemas de IA e fornecer aos times de gestão de risco um framework para identificar fatores críticos de risco.

    Sete Princípios de Design para IA Agentic Segura

    1. Homologia Segurança Humano-IA

    O primeiro princípio estabelece que é necessário compreender os controles humanos e determinar sua aplicabilidade aos agentes e fluxos de trabalho agentic, documentando as personas dos agentes. Isso inclui implementar identidades de agentes além de permissões tradicionais baseadas em papéis e atributos, com logging e monitoramento comportamental.

    Ações críticas devem ter supervisão (agentic ou humana), o escopo do agente deve ser definido nos fluxos de trabalho, e é preciso considerar gerenciamento de mudanças e incidentes, segregação de deveres do agente para ações e uso de ferramentas, verificação maker-checker, logging e monitoramento comportamental.

    2. Arquitetura Modular de Fluxo de Trabalho Agentic

    Usar sub-agentes especializados em fluxos de trabalho reduz o escopo de permissões que cada agente requer, aumenta modularidade e reusabilidade, simplifica manutenção e melhora observabilidade e explicabilidade. Permissões granulares são anexadas aos sub-agentes, focando estreitamente suas responsabilidades.

    3. Logging e Rastreamento de Fluxo de Trabalho e Agentes

    Implementar logging e rastreamento abrangentes para acompanhar decisões, ações, fluxos de atividade, contexto específico do chamador e etapas de raciocínio habilita melhor explicabilidade. Monitorar interações entre agentes, compartilhamento de contexto e comportamentos emergentes permite visibilidade holística das operações e dinâmicas do fluxo de trabalho multi-agente.

    4. Privilégio Mínimo Segregado para IA

    Aplicar o princípio do menor privilégio e segregação de deveres em fluxos de trabalho automatizados através de limites operacionais claramente definidos para agentes de IA. Esses limites devem ser suportados por controles de autorização, vinculados às permissões do chamador com suporte a verificação contextual, e apoiados por circuit breakers como supervisão humana.

    5. Integração de Governança

    Integrar observabilidade de agentes em frameworks de governança existentes através de alinhamento com processos estabelecidos de gerenciamento de risco e conformidade, implementando frameworks de avaliação padronizados e test harnesses que medem desempenho do agente, conformidade e alinhamento com valor de negócio.

    6. Controles Operacionais Agentic

    Fornecer guardrails amigáveis ao negócio para definir e gerenciar políticas de comportamento de agentes, mantendo controles abrangentes de custo através de monitoramento e otimização da utilização de recursos em níveis individual e de fluxo de trabalho. Usuários de negócio conseguem gerenciar restrições de agentes.

    7. Gestão de Risco e Conformidade

    Integrar rastreamento abrangente de atividades com frameworks de governança existentes para apoiar requisitos de auditoria, conformidade regulatória, e alinhamento com processos estabelecidos de gerenciamento de risco. Isso garante supervisão minuciosa e conformidade em todas as atividades de agentes dentro da estrutura de governança existente da organização.

    Implementação Prática dos Princípios

    Monitorando e Compreendendo Comportamento de Agentes IA

    Para implementar os princípios de homologia segurança humano-IA e logging/rastreamento, é necessário primeiro documentar fluxos de trabalho de agentes e personas, implementando rastreamento abrangente que capture entradas, etapas de raciocínio, saídas e uso de ferramentas.

    A Observabilidade do Amazon Bedrock AgentCore oferece soluções específicas para rastreamento, debug, identificação e monitoramento de desempenho de agentes em ambientes de produção. Essa visibilidade fornece dados para compreender como agentes interagem com sistemas financeiros críticos.

    Uma estratégia de tagging para agentes melhora visibilidade, usando nomes de papéis descritivos para casos de uso pretendidos. Esses tags devem ser antecipados para uso em permissões agentic downstream e fluxos de trabalho upstream.

    Dashboards operacionais, implementados com Amazon CloudWatch, devem fornecer visão da saúde operacional dos agentes, rastreando métricas-chave como conclusões bem-sucedidas, falhas, latência e utilização de recursos.

    Integrar telemetria de agentes com sistemas de monitoramento existentes usando padrões comuns como OpenTelemetry, com Distribuição AWS para OpenTelemetry, permite que instituições financeiras mantenham seus investimentos em ferramentas de monitoramento enquanto estendem visibilidade para atividades de agentes.

    É essencial estabelecer verificações padronizadas no servidor (lado da ferramenta) aplicando controles de acesso consistentes para agentes usando ferramentas, seguindo as práticas recomendadas de segurança AWS para integração de ferramentas. Validação e verificações de sanitização devem estar em lugar em entradas no ponto de uso da ferramenta para detectar comportamento não intencional.

    Gerenciando Mudanças em Ambientes de IA Agentic

    Adaptar processos de gerenciamento de mudanças para acomodar a natureza dinâmica dos agentes de IA mantendo controles apropriados. Revisar processos de aprovação integrados em pipelines de deploy de agentes e adaptá-los à natureza iterativa de pequenas melhorias incrementais.

    Implementar pausas human-in-the-loop em operações agentic permite supervisão adequada. Monitorar contínuamente traços de agentes em um test harness usando ferramentas como Amazon CloudWatch e AWS X-Ray para observar mudanças em padrões de comportamento de agentes que possam indicar drift de execução ou aprendizado inesperado.

    Implementando Privilégio Mínimo para Agentes de IA

    Definir limites de permissão granular para ações de agente implementando controles de permissão refinados para limitar permissões àquelas necessárias para funções de agente, usando por exemplo a Política do Amazon Bedrock AgentCore.

    Considerar segregação de deveres para agentes segregando funções e permissões de acesso a ferramentas para reduzir escopo de impacto de ações não intencionais. Garantir que ações dirigidas por prompt de usuário e ações agente-para-agente sejam separadamente identificáveis.

    Implantar monitoramento de autorização usando ferramentas como Observabilidade do Amazon Bedrock AgentCore que monitora continuamente padrões de autorização de agentes e sinaliza tentativas de acesso anômalas.

    Manter trilhas de auditoria abrangentes de ações de agentes que afetam sistemas de produção e dados sensíveis. Essas trilhas devem ser imutáveis e integradas com sistemas existentes de relatório de conformidade, garantindo que ações agente-para-agente e a fonte original e linhagem da requisição sejam preservadas.

    Implementando Guardrails e Controles Comportamentais

    Recomenda-se adotar uma abordagem crawl, walk, run para implementação de controle, começando com o conjunto mínimo necessário de controles e evoluindo ao longo do tempo com feedback do monitoramento.

    Interfaces amigáveis permitem definir políticas de comportamento de agente e regras de conformidade. Através dessas interfaces, times de risco e conformidade conseguem gerenciar guardrails de agentes diretamente sem intervenção técnica.

    Sistemas automatizados validam ações de agentes contra políticas definidas em tempo real. Por exemplo, usar Amazon Bedrock Guardrails para implementar filtragem de conteúdo, detecção de informações pessoalmente identificáveis (PII), e validação de respostas antes que saídas de agentes atinjam sistemas de produção.

    Fluxos de trabalho de revisão implementam pontos de controle para ações críticas de agentes com caminhos de escalação claros. Definir gatilhos para revisão humana e manter mecanismos de coleta de feedback para melhoria contínua.

    Detectando e Recuperando de Falhas em Agentes IA

    Implantar monitoramento abrangente de saúde e desempenho para agentes de IA que detecte tanto falhas hard quanto degradação de desempenho. A Observabilidade do Amazon Bedrock AgentCore oferece capacidades especializadas para compreender saúde de agentes além de métricas de aplicação tradicional.

    Desenvolver e testar procedimentos automatizados de recuperação e modificação comportamental manual para diferentes tipos de falhas de agentes. Esses procedimentos devem incluir circuit breakers apropriados e caminhos de escalação humana para cenários que requerem julgamento.

    Implementar monitoramento para degradação sutil em qualidade de raciocínio de agentes que pode não disparar alertas de falha tradicionais.

    Garantindo Desempenho Consistente de Agentes Através de Ambientes

    Implementar agentes modulares e reusáveis com baselines de desempenho estabelecidos para operações de agentes através de ambientes de desenvolvimento, teste e produção. Monitorar desvios que possam indicar problemas específicos de ambiente.

    Práticas de teste canary para monitoramento de comportamento de agentes e teste de resiliência implementam teste de release em pequena escala com observabilidade abrangente para detectar mudanças de comportamento inesperadas antes de deploy completo e em runtime.

    Usar teste positivo onde entradas válidas produzem saídas esperadas e teste negativo onde entradas inadequadas ainda alcançam a saída desejada. Testar resiliência de agentes sob várias condições de falha. Usar change control para testes canary para garantir rastreamento ao longo do tempo conforme testes expandem e amadurecem.

    Gerenciando Interações de Fluxo de Trabalho Multi-Agente

    Implementar monitoramento para padrões de colaboração de agentes, monitorando comunicações agente-para-agente dentro de fluxos de trabalho pré-definidos e dinâmicos, compartilhamento de contexto e comportamentos coletivos. Rastrear padrões de interação para identificar riscos potenciais ou ineficiências.

    Implantar testes de rastreamento comportamental para identificar padrões ou resultados inesperados surgindo de interações multi-agente. Estabelecer baselines para comportamento colaborativo normal e alertar sobre desvios, incluindo cenários extremos em testes.

    Registrar logs não-repudiáveis e abrangentes de interações de agentes, incluindo trocas de contexto, handoffs e saídas. Garantir que ações agente-para-agente, fonte original e linhagem da requisição sejam preservadas.

    Otimizando Utilização de Recursos e Custos de Agentes IA

    Implantar monitoramento para padrões de consumo de recursos de agentes, incluindo compute, memória, uso de API e custos usando Amazon CloudWatch. Isso habilita otimização de alocação de recursos e gerenciamento de custos.

    Definir e monitorar indicadores-chave de desempenho específicos para operações de agentes, como eficiência de desempenho de etapas de raciocínio, padrões de uso de ferramentas e tempos de conclusão.

    Implantar detecção de anomalia para métricas de desempenho de agentes para identificar problemas potenciais antes que impactem operações de negócio.

    Conclusão

    A adoção de IA agentic em serviços financeiros requer cuidadosamente balancear inovação com controle. Os sete princípios de design apresentados fornecem um framework para implementar sistemas de agentes de IA explicáveis, governáveis e em geral responsáveis que se alinhem com requisitos de segurança e conformidade existentes.

    Tratando agentes de IA com o mesmo rigor de segurança aplicado a funcionários humanos—através de controle de acesso robusto, permissões baseadas em papel e atributo, e monitoramento abrangente—organizações conseguem implementar seguramente esses sistemas mantendo conformidade com frameworks regulatórios-chave.

    As soluções de propósito específico disponíveis da AWS fornecem fundação técnica, mas sucesso também requer políticas claras e mecanismos de supervisão humana. Instituições financeiras que estabelecerem essas capacidades fundamentais de segurança e governança estarão bem posicionadas para aproveitar IA agentic enquanto contribuem para segurança, explicabilidade e conformidade com padrões de indústria de seus sistemas.

    Para perguntas e feedback, você pode acessar a comunidade de segurança, identidade e conformidade da AWS ou contatar o suporte AWS.

    Fonte

    Preparing for agentic AI: A financial services approach (https://aws.amazon.com/blogs/security/preparing-for-agentic-ai-a-financial-services-approach/)

  • Aurora DSQL: Conector para Ruby Simplifica Desenvolvimento de Aplicações

    Um Novo Conector para Facilitar o Desenvolvimento com Ruby

    A AWS anunciou o lançamento do Conector Aurora DSQL para Ruby (gem pg), uma ferramenta que simplifica significativamente a construção de aplicações Ruby no Aurora DSQL. Este conector representa um avanço importante para desenvolvedores que trabalham com a linguagem Ruby, trazendo segurança e praticidade para a autenticação em bancos de dados na nuvem.

    Segurança e Autenticação Automáticas

    A proposta central do conector é eliminar os riscos de segurança relacionados ao gerenciamento tradicional de senhas geradas pelo usuário. Em vez disso, o conector gera automaticamente tokens para cada conexão, garantindo que sempre sejam utilizados tokens válidos. Ao mesmo tempo, mantém total compatibilidade com os recursos existentes da gem pg, permitindo que aplicações legadas funcionem sem necessidade de alterações significativas.

    Funcionalidades Principais

    O conector está equipado para lidar com várias responsabilidades técnicas críticas: geração automática de tokens do IAM (Gerenciamento de Identidade e Acesso), configuração de SSL e gerenciamento de pool de conexões. Essa abordagem permite que os desenvolvedores escalem suas aplicações — desde scripts simples até cargas de trabalho em produção — sem precisar modificar sua estratégia de autenticação durante o processo de crescimento.

    Recursos Avançados e Flexibilidade

    Além das capacidades essenciais, o conector oferece funcionalidades opcionais importantes. Inclui retry com controle de concorrência otimista (OCC) com backoff exponencial, suporte a provedores de credenciais IAM customizados e integração com perfis AWS. Esses recursos conferem aos desenvolvedores a flexibilidade necessária para gerenciar suas credenciais AWS de diferentes maneiras e lidar eficientemente com falhas transientes.

    Primeiros Passos

    Para começar a utilizar o conector, desenvolvedores podem consultar a documentação dos Conectores para Aurora DSQL. Exemplos práticos de código estão disponíveis no repositório GitHub do conector Ruby. Aqueles que desejam explorar o Aurora DSQL sem custos imediatos podem aproveitar a camada gratuita da AWS Free Tier. Para uma compreensão mais aprofundada sobre o Aurora DSQL, a página dedicada do serviço oferece informações completas.

    Implicações Práticas

    Este conector representa um esforço da AWS em reduzir a complexidade operacional para desenvolvedores Ruby. A automação de tarefas críticas como geração de tokens e configuração SSL, combinada com a manutenção de compatibilidade com ferramentas existentes, posiciona a solução como uma opção atrativa para equipes que buscam modernizar sua infraestrutura de autenticação sem reescrever códigos legados.

    Fonte

    Aurora DSQL launches connector that simplifies building Ruby applications (https://aws.amazon.com/about-aws/whats-new/2026/03/aurora-dsql-connector-for-ruby/)