User's blog

Blog

  • 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/)

  • Amazon SageMaker Studio agora suporta Kiro e Cursor como IDEs remotas

    Integração entre IDEs locais e infraestrutura em nuvem

    A AWS anunciou uma novidade importante para quem trabalha com ciência de dados e desenvolvimento de modelos de inteligência artificial: agora é possível conectar remotamente as IDEs (Ambientes de Desenvolvimento Integrado) Kiro e Cursor diretamente ao Amazon SageMaker Studio.

    Essa capacidade oferece aos cientistas de dados, engenheiros de aprendizado de máquina e desenvolvedores a oportunidade de aproveitar as características locais de suas ferramentas favoritas — como desenvolvimento orientado por especificações, programação conversacional e geração automática de recursos — enquanto acessam simultaneamente toda a potência computacional escalável do Amazon SageMaker Studio na nuvem.

    Como funciona a integração

    A conexão entre Kiro, Cursor e SageMaker Studio é realizada através da extensão AWS Toolkit, eliminando a necessidade de alternar constantemente entre o editor local e a infraestrutura em nuvem. Dessa forma, é possível manter fluxos de trabalho de desenvolvimento orientados por agentes dentro de um único ambiente, integrando todos os seus serviços de análise e inteligência artificial e aprendizado de máquina da AWS.

    Ambientes de desenvolvimento disponíveis

    O Amazon SageMaker Studio oferecia anteriormente um conjunto abrangente de ambientes de desenvolvimento interativos totalmente gerenciados, incluindo JupyterLab, Code Editor baseado em Code-OSS (Software Livre) e VS Code como IDE remota. A partir de agora, esses ambientes se expandem para incluir as configurações customizadas de Kiro e Cursor — com todas as especificações, arquivos de direcionamento e hooks — enquanto você acessa seus recursos computacionais e dados no SageMaker.

    Autenticação e segurança

    A autenticação pode ser realizada de duas formas: através da extensão AWS Toolkit diretamente no Kiro ou Cursor, ou pela interface web do SageMaker Studio. Após a autenticação, você consegue conectar a qualquer um de seus ambientes de desenvolvimento do SageMaker Studio em poucos cliques.

    Um aspecto importante é que você mantém os mesmos limites de segurança que os ambientes baseados em web do SageMaker Studio oferecem. Isso significa que o desenvolvimento de modelos de inteligência artificial e análise de dados em sua IDE local de preferência — seja Kiro ou Cursor — acontece dentro do mesmo contexto de segurança e conformidade da plataforma.

    Próximos passos

    Para obter mais detalhes sobre como configurar essa integração e explorar todas as funcionalidades disponíveis, consulte a documentação do SageMaker.

    Fonte

    Amazon SageMaker Studio launches support for Kiro and Cursor IDEs as remote IDEs (https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-sagemaker-studio-kiro-cursor/)

  • Construindo IA Responsiva à Idade e Sensível ao Contexto com Amazon Bedrock Guardrails

    O Desafio da Segurança em Aplicações de IA Generativa

    Quando aplicações de IA generativa atendem a grupos diversificados de usuários, surge um desafio crítico que afeta tanto a segurança quanto a confiabilidade: garantir que cada resposta gerada seja apropriada, precisa e segura para o usuário específico. O conteúdo adequado para adultos pode ser inadequado ou confuso para crianças, enquanto explicações voltadas para iniciantes podem ser insuficientes para especialistas do domínio.

    À medida que a adoção de IA se expande por diferentes setores, a necessidade de adaptar respostas conforme a idade, papel profissional e nível de conhecimento do usuário se tornou essencial em ambientes de produção. Muitas organizações tentam resolver esse problema por meio de engenharia de prompts ou lógica no nível da aplicação, mas essas abordagens enfrentam limitações significativas.

    Por Que Controles de Segurança Baseados em Prompts Não São Suficientes

    Os controles de segurança implementados apenas no prompt podem ser contornados por técnicas de manipulação que induzem os modelos a ignorar as instruções de segurança. Conforme os requisitos de personalização crescem, o código da aplicação fica cada vez mais complexo e frágil. A governança se torna inconsistente quando múltiplas aplicações de IA estão em uso.

    Além disso, os riscos de conteúdo inseguro, informações alucinadas e respostas inadequadas se amplificam significativamente quando sistemas de IA interagem com usuários vulneráveis ou operam em domínios sensíveis como educação e saúde. A falta de políticas de segurança centralizadas e obrigatórias cria ineficiências operacionais e riscos de conformidade regulatória.

    A Solução: Guardrails no Coração da Arquitetura

    Para enfrentar esses desafios, a AWS desenvolveu uma abordagem baseada em guardrails que coloca a segurança no centro da arquitetura. Essa solução é totalmente serverless e utiliza Amazon Bedrock Guardrails junto com outros serviços AWS para alinhar-se com as necessidades modernas de segurança e conformidade em IA.

    A arquitetura oferece três componentes principais: seleção dinâmica de guardrails baseada no contexto do usuário, aplicação centralizada de políticas por meio dos guardrails, e APIs seguras com autenticação.

    Capacidades Principais da Solução

    O design serverless permite às organizações entregar respostas de IA personalizadas e seguras sem código complexo, de forma eficiente, segura e em escala. A solução é capaz de:

    • Adaptar respostas de IA de forma inteligente com base na idade, papel profissional e setor do usuário
    • Aplicar políticas de segurança no momento da inferência, prevenindo contornos por manipulação de prompts
    • Oferecer cinco guardrails especializados para diferentes segmentos de usuários: crianças, adolescentes, profissionais de saúde, pacientes e adultos em geral
    • Melhorar a eficiência operacional com governança centralizada e intervenção manual mínima
    • Escalar de acordo com o crescimento de usuários e requisitos de segurança em evolução

    Essa abordagem ajuda organizações a implantar sistemas de IA responsáveis, a se alinhar com requisitos de conformidade para populações vulneráveis, e a manter respostas apropriadas e confiáveis em toda a diversidade de grupos de usuários, sem comprometer desempenho ou governança.

    Visão Geral da Arquitetura

    Componentes Principais

    A solução utiliza Amazon Bedrock, Amazon Bedrock Guardrails, AWS Lambda e Amazon API Gateway como serviços essenciais para geração inteligente de respostas, aplicação centralizada de políticas e acesso seguro. Componentes de suporte como Amazon Cognito, Amazon DynamoDB, AWS WAF e Amazon CloudWatch possibilitam autenticação de usuários, gerenciamento de perfis, segurança e registros abrangentes.

    O Diferencial: Seleção Dinâmica de Guardrails

    O que torna esta abordagem única é a seleção dinâmica de guardrails. O Amazon Bedrock e os Bedrock Guardrails se adaptam automaticamente com base no contexto autenticado do usuário (idade, papel profissional, setor) para aplicar políticas de segurança apropriadas no momento da inferência. Essa abordagem baseada em guardrails funciona junto com medidas de segurança baseadas em prompts para oferecer proteção em camadas.

    A solução oferece cinco guardrails especializados:

    • Proteção Infantil: Compatível com a Lei de Proteção da Privacidade Online das Crianças (Children’s Online Privacy Protection Act – COPPA)
    • Educacional para Adolescentes: Conteúdo apropriado à idade
    • Profissional de Saúde: Conteúdo clínico habilitado
    • Paciente de Saúde: Aconselhamento médico bloqueado
    • Geral para Adultos: Proteção padrão

    Esses guardrails oferecem uma camada de aplicação de políticas autoritária que governa o que o modelo de IA pode dizer, operando independentemente da lógica da aplicação. A solução utiliza escalabilidade serverless, aplica políticas de segurança e adapta respostas com base no contexto do usuário, tornando-a bem adequada para implantações de IA corporativa que atendem populações diversas.

    Estratégia de Segurança em IA Multicontexto

    Como a Solução Funciona

    O fluxo da solução envolve várias etapas bem definidas:

    1. Requisição e Interface do Usuário

    • O usuário acessa a interface web de demonstração local (executada em localhost:8080 para fins de demonstração)
    • Insere uma consulta na interface
    • Seleciona seu perfil (Criança, Adolescente, Adulto, Profissional de Saúde)
    • A interface web prepara uma requisição autenticada com o contexto do usuário

    2. Autenticação do Usuário

    • O Amazon Cognito autentica usuários através de um pool de usuários e gera tokens Tokens de Web JSON (JWT – JSON Web Token)
    • Esses tokens contêm a ID do usuário e a declaração de autenticação
    • Os tokens seguros são passados com as requisições de API

    3. Camada de Segurança AWS WAF

    • O AWS WAF aplica limite de taxa de 2.000 requisições por minuto por IP (ajustável conforme necessário)
    • Bloqueia ameaças web comuns e requisições maliciosas segundo padrões de Projeto de Segurança de Aplicação Web Aberta (OWASP – Open Web Application Security Project)
    • Valida o formato da requisição e bloqueia tráfego suspeito

    4. Processamento pelo API Gateway

    • O Amazon API Gateway valida tokens JWT do Cognito
    • Encaminha requisições autenticadas para funções AWS Lambda
    • Gerencia requisições de Compartilhamento de Recursos entre Origens (CORS – Cross-Origin Resource Sharing)

    5. Execução da Função Lambda

    • O Lambda sanitiza e valida as entradas do usuário
    • Consulta o DynamoDB para recuperar perfis de usuário (idade, papel profissional, setor)
    • Analisa dados demográficos para determinar o guardrail apropriado
    • Prepara entradas de log de auditoria

    6. Seleção Dinâmica de Guardrail

    O Lambda avalia a idade, papel profissional e setor do usuário e seleciona automaticamente entre cinco guardrails especializados:

    • Idade menor que 13 anos → Guardrail de Proteção Infantil (compatível com COPPA)
    • Idade entre 13 e 17 anos → Guardrail Educacional para Adolescentes (conteúdo apropriado à idade)
    • Profissional de Saúde → Guardrail de Profissional de Saúde (conteúdo clínico habilitado)
    • Paciente de Saúde → Guardrail de Paciente (aconselhamento médico bloqueado)
    • Padrão/Adulto → Guardrail Geral para Adultos (proteção padrão)

    Cada requisição deve passar por um guardrail — não há possibilidade de contorno.

    7. Processamento Bedrock com Proteção por Guardrail

    • O Lambda invoca um modelo de fundação no Amazon Bedrock
    • O guardrail selecionado filtra tanto a entrada quanto a saída
    • Políticas customizadas, restrições de tópicos e detecção de Informações de Identificação Pessoal (PII – Personally Identifiable Information) são aplicadas
    • A IA gera respostas filtradas para segurança e apropriadas ao contexto

    8. Processamento de Resposta e Registro de Auditoria

    • Respostas seguras são entregues com metadados dos guardrails
    • Conteúdo inadequado dispara mensagens de segurança específicas do contexto
    • Interações são registradas no Amazon CloudWatch para conformidade
    • Interações dos guardrails são armazenadas em tabelas de auditoria no DynamoDB

    9. Entrega de Resposta ao Usuário

    • O Lambda retorna respostas processadas através do Amazon API Gateway
    • O sistema entrega respostas diretamente aos usuários
    • A interface web de demonstração exibe respostas protegidas e apropriadas ao contexto

    Exemplos de Adaptação de Respostas

    Exemplo 1: Pergunta sobre DNA

    Para a pergunta “O que é DNA?”, o sistema gera respostas diferentes conforme o contexto do usuário:

    Estudante Adolescente (13 anos): “O DNA é como um livro de receitas que diz ao seu corpo como crescer e como você vai parecer! É feito de quatro letras especiais (A, T, G, C) que criam instruções para tudo sobre você.”

    Profissional de Saúde (35 anos): “O DNA consiste de sequências de nucleotídeos que codificam informações genéticas através de complementaridade de pares de bases. A estrutura da dupla hélice contém regiões de codificação (éxons) e sequências regulatórias que controlam a expressão gênica e síntese de proteínas.”

    Adulto Geral (28 anos): “O DNA é uma molécula que contém instruções genéticas para o desenvolvimento e funcionamento de organismos vivos. Tem estrutura de dupla hélice e determina características hereditárias.”

    Exemplo 2: Pergunta sobre Equações Quadráticas

    A mesma pergunta “Como resolver equações quadráticas?” recebe respostas apropriadas à idade:

    Estudante Adolescente (13 anos): Explicação simples, passo a passo, com exemplos básicos e linguagem amigável adequada ao nível de ensino médio.

    Professor de Matemática (39 anos): Abordagem pedagógica abrangente, incluindo múltiplos métodos de solução, estratégias de ensino e conceitos matemáticos avançados.

    Implementação da Solução

    Pré-requisitos

    Antes de implantar a solução, certifique-se de que você tem:

    • Uma conta AWS
    • Permissões AWS apropriadas para Lambda, Amazon Bedrock, Cognito, AWS WAF, DynamoDB, API Gateway e CloudWatch
    • Terraform instalado e configurado

    Passos de Implementação

    1. Clonar o Repositório

    git clone https://github.com/aws-samples/sample-age-responsive-context-aware-ai-bedrock-guardrails.git

    2. Implantar Infraestrutura usando Terraform

    cd sample-age-responsive-context-aware-ai-bedrock-guardrails
./deploy.sh

    Para uma visão abrangente de cada configuração de guardrail, incluindo filtros de conteúdo, restrições de tópicos, tratamento de PII e filtros customizados, consulte os Detalhes de Configuração de Guardrail no repositório de código.

    Testando a Solução

    A solução inclui uma demonstração baseada em web para teste imediato. Para implantações corporativas em produção, você pode hospedar a interface usando AWS Amplify, Amazon S3 com Amazon CloudFront, ou serviços de container como Amazon Elastic Container Service (ECS) e Amazon Elastic Kubernetes Service (EKS).

    Demo Interativa Web:

    cd web-demo
./start_demo.sh

    Abra o navegador e acesse http://localhost:8080. Você pode:

    • Selecionar diferentes perfis de usuário (Criança, Adolescente, Adulto, Papéis de Saúde)
    • Enviar consultas e observar respostas sensíveis ao contexto
    • Visualizar aplicação de guardrails em tempo real
    • Monitorar adaptação de respostas conforme o contexto do usuário

    Teste de API:

    Para teste programático, gere um token JWT:

    cd utils
python3 generate_jwt.py student-123

    Teste o endpoint de API:

    curl -X POST "$(cd ../terraform && terraform output -raw api_url)" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer " \
  -d '{"query": "What is DNA?"}'

    Para cenários detalhados de teste do Amazon Bedrock Guardrails, exemplos de API e procedimentos de validação, consulte o arquivo TESTING_GUIDE.md no repositório clonado.

    Estimativa de Custos

    O custo de executar esta solução depende dos padrões e escala de uso. Para um cenário de uso moderado (1.000 requisições de API por dia), a estimativa mensal fica entre $73 e $320, dependendo do volume de uso e seleção de modelo.

    Os custos reais variam com base no volume de requisições, seleção de modelo, transferência de dados e preços regionais. Use o Calculador de Preços AWS para estimativas customizadas.

    Considerações para Otimização de Custos

    • Tagging de Custos: Implemente tags de alocação de custos AWS nos recursos para rastrear despesas por departamento, projeto ou centro de custos
    • Implantações Multi-Conta: Para implantações corporativas em múltiplas contas AWS, considere usar AWS Organizations com cobrança consolidada e AWS Cost Explorer para visibilidade centralizada
    • Capacidade Reservada: Para cargas de trabalho previsíveis, considere Amazon Bedrock Provisioned Throughput para reduzir custos de inferência
    • Otimização do DynamoDB: Use preço sob demanda para cargas variáveis ou capacidade provisionada com autoscaling para padrões previsíveis
    • Otimização do Lambda: Dimensione apropriadamente a alocação de memória e use AWS Lambda Power Tuning para melhorar a relação custo-desempenho
    • Retenção de Logs CloudWatch: Configure períodos de retenção apropriados para equilibrar necessidades de conformidade com custos de armazenamento

    Limpeza de Recursos

    Para evitar encargos contínuos, remova os recursos AWS criados quando não forem mais necessários:

    cd sample-age-responsive-context-aware-ai-bedrock-guardrails
./cleanup.sh

    Principais Benefícios e Resultados

    Esta solução demonstra uma abordagem baseada em guardrails para construir aplicações de IA sensíveis ao contexto. Os principais benefícios incluem:

    • Segurança Sensível ao Contexto: Diferentes grupos de usuários são protegidos por guardrails específicos sem necessidade de implantar modelos ou aplicações separados
    • Governança Centralizada: Os guardrails aplicam políticas de segurança, restrições de tópicos e controles de alucinação no nível da infraestrutura, em vez de depender apenas de lógica de prompts
    • Filtragem de Conteúdo Gerenciada: Os guardrails oferecem filtros de conteúdo integrados para discurso de ódio, insultos, conteúdo sexual, violência, má conduta e ataques de injeção de prompts, sem necessidade de implementação customizada
    • Personalização Inteligente: Adapta complexidade e apropriação de conteúdo conforme contexto do usuário, entregando explicações apropriadas à idade para crianças e detalhes clínicos para profissionais de saúde
    • Risco Reduzido de Contorno: Políticas são aplicadas no momento da inferência e não podem ser sobrescritas por entrada do usuário
    • Flexibilidade Operacional: Novos segmentos de usuários ou atualizações de política podem ser introduzidos atualizando guardrails em vez de modificar código da aplicação
    • Prontidão Corporativa: Os guardrails oferecem controle de versão, registros de auditoria e suporte à conformidade com clara separação de responsabilidades para manutenção de longo prazo

    Conclusão

    A AWS apresentou uma abordagem totalmente serverless baseada em guardrails para entregar respostas de IA sensíveis à idade e contextualizadas. A solução demonstra como serviços AWS trabalham em conjunto para selecionar dinamicamente guardrails especializados com base no contexto do usuário, aplicar políticas de segurança e entregar respostas personalizadas. A arquitetura foi implantada usando Terraform, tornando-a repetível e pronta para produção.

    Por meio de seleção dinâmica de guardrails e aplicação centralizada de políticas, essa solução personaliza respostas de IA para cada segmento de usuário — desde proteção compatível com COPPA para crianças até conteúdo clínico para profissionais de saúde — mantendo segurança corporativa e escalabilidade. Organizações que atendem populações diversas podem se beneficiar de risco reduzido de contorno, governança centralizada e flexibilidade operacional ao atualizar políticas sem modificar código da aplicação.

    Para começar, clone o repositório e siga as instruções de implantação. Teste a solução usando a demonstração web interativa para ver como respostas se adaptam conforme o contexto do usuário. Para aprender mais sobre Amazon Bedrock Guardrails, visite a documentação do Amazon Bedrock Guardrails.

    Fonte

    Building age-responsive, context-aware AI with Amazon Bedrock Guardrails (https://aws.amazon.com/blogs/machine-learning/building-age-responsive-context-aware-ai-with-amazon-bedrock-guardrails/)

  • Aceleração do Ajuste Fino de Modelos de Linguagem com Dados Não Estruturados usando SageMaker Unified Studio e S3

    Contexto da Integração

    No ano anterior, a AWS anunciou uma integração significativa entre o Amazon SageMaker Unified Studio e os buckets de propósito geral do Amazon S3. Essa conexão simplifica bastante a forma como equipes trabalham com dados não estruturados armazenados no Amazon Simple Storage Service (Amazon S3) para casos de uso em aprendizado de máquina (ML) e análise de dados.

    Este artigo demonstra como conectar buckets S3 ao Amazon SageMaker Catalog para realizar o ajuste fino do modelo Llama 3.2 11B Vision Instruct voltado para tarefas de resposta a perguntas visuais (VQA, sigla em inglês para Visual Question Answering). O fluxo prático mostra como fornecer ao modelo de linguagem uma imagem e uma pergunta para obter uma resposta — por exemplo, identificar a data de uma transação em um recibo itemizado.

    Preparação Inicial e Desempenho Base

    A AWS disponibiliza o modelo Llama 3.2 11B Vision Instruct através do Amazon SageMaker JumpStart. Fora da caixa, esse modelo base alcança uma pontuação ANLS (Similaridade de Levenshtein Normalizada Média — Average Normalized Levenshtein Similarity) de 85,3% no conjunto de dados DocVQA. O ANLS é uma métrica empregada para avaliar o desempenho de modelos em tarefas de resposta a perguntas visuais, medindo a similitude entre a resposta predita e a resposta esperada.

    Embora 85,3% demonstre um desempenho inicial sólido, esse nível pode não ser suficiente para tarefas que exigem maior precisão. Para elevar o desempenho através do ajuste fino, utiliza-se o conjunto de dados DocVQA do Hugging Face, que contém 39.500 linhas de dados de treinamento, cada uma com uma imagem, uma pergunta e a resposta correspondente esperada.

    Estratégia de Experimentação

    O processo envolve a criação de três versões de modelos ajustados utilizando diferentes tamanhos de conjuntos de dados: 1.000, 5.000 e 10.000 imagens. Cada variação é avaliada usando o Amazon SageMaker com suporte a MLflow gerenciado e sem servidor para rastreamento de experimentos e medição de melhorias de acurácia. Todo o fluxo de ingestão de dados, desenvolvimento de modelo e avaliação de métricas é orquestrado pelo Amazon SageMaker Unified Studio.

    Arquitetura da Solução

    A arquitetura construída realiza a ingestão de dados, pré-processamento, treinamento do modelo e avaliação utilizando o Amazon SageMaker Unified Studio. O processo segue estas etapas principais:

    • Criar e configurar um papel de acesso IAM que concede permissões de leitura a um bucket S3 preexistente contendo o conjunto de dados DocVQA bruto e não processado
    • O projeto produtor de dados usa o papel de acesso para descobrir e adicionar o conjunto de dados ao catálogo do projeto
    • O projeto produtor enriquece o conjunto de dados com metadados opcionais e o publica no SageMaker Catalog
    • O projeto consumidor de dados se inscreve no conjunto de dados publicado, disponibilizando-o para a equipe de desenvolvimento de modelos de aprendizado de máquina
    • O projeto consumidor pré-processa os dados e os transforma em três conjuntos de treinamento de tamanhos variados (1k, 5k e 10k imagens)
    • Cada conjunto é utilizado para ajustar o modelo base de linguagem, com o MLflow rastreando experimentos e resultados de avaliação em relação à métrica ANLS

    Pré-requisitos Necessários

    Para preparar uma organização visando usar essa nova integração entre o Amazon SageMaker Unified Studio e buckets S3 de propósito geral, é necessário completar alguns passos em um domínio baseado em Identity Center:

    • Criar uma conta AWS
    • Criar um domínio Amazon SageMaker Unified Studio através de configuração rápida
    • Criar dois projetos dentro do domínio: um para a função de produtor de dados e outro para consumidor de dados
    • Garantir que o projeto consumidor tenha acesso a uma aplicação MLflow gerenciada sem servidor em execução
    • Pré-popular um bucket Amazon S3 com o conjunto de dados bruto
    • Solicitar aumento de cota de serviço para utilizar instâncias de computação p4de.24xlarge em trabalhos de treinamento

    Fluxo de Implementação

    Descoberta e Catalogação de Dados

    Um projeto no Amazon SageMaker Unified Studio funciona como um limite dentro de um domínio onde equipes podem colaborar em casos de uso comerciais. Para trazer dados do S3 para um projeto, é necessário primeiro adicionar acesso aos dados e depois adicioná-los ao projeto. Nesta demonstração, utiliza-se um papel de acesso para facilitar esse processo.

    Após criar o papel de acesso conforme documentado, no projeto produtor de dados, navega-se até Dados → Adicionar dados → Adicionar localização S3, fornecendo o nome do bucket e o prefixo contendo os dados brutos. O papel de acesso necessário aparece em um menu suspenso para seleção.

    Dependendo das necessidades organizacionais, é possível enriquecer ainda mais esse ativo de dados através de junções com outras fontes, aplicação de transformações específicas do negócio, implementação de verificações de qualidade ou criação de características derivadas. Para este exemplo, trabalha-se com o conjunto de dados em sua forma atual para manter o foco na integração.

    Em seguida, publica-se o bucket no SageMaker Catalog, adicionando opcionalmente metadados de negócio como um arquivo README e termos de glossário. Após a publicação através do menu Ações, o ativo de dados fica pronto para ser consumido por outros projetos.

    Consumo e Desenvolvimento do Modelo

    Mudando para a perspectiva do projeto consumidor, é possível agora se inscrever no ativo de dados recém-publicado. Com a inscrição concluída, inicia-se o trabalho com os dados dentro de um ambiente JupyterLab gerenciado no Amazon SageMaker Unified Studio.

    No projeto de desenvolvimento de ML, navegando até Computação → Espaços → Criar espaço e selecionando JupyterLab como tipo de aplicação, inicia-se um novo ambiente de desenvolvimento interativo. Considera-se importante definir o Tempo de Inatividade para 6 horas, permitindo que notebooks rodem completamente sem erros, e o Armazenamento do Espaço para 100 GB para acomodar a ingestão completa do conjunto de dados durante o ajuste fino.

    Acesso aos Dados e Preparação

    Com o espaço em execução, carrega-se o notebook de demonstração. A integração utiliza Amazon S3 Access Grants para facilitar o acesso seguro aos dados sem gerenciamento complexo de permissões.

    Os dados podem ser acessados através da Interface de Linha de Comando AWS (AWS CLI), SDKs AWS e API REST do S3. Adicionalmente, é possível usar plugins Python e Java para chamar o serviço. O notebook utiliza a abordagem AWS CLI para obter credenciais temporárias de acesso ao plano de controle S3 e sincronizar os dados localmente.

    Com o conjunto de dados agora acessível localmente, é necessário transformá-lo no formato requerido para ajuste fino. Criam-se três conjuntos de dados com tamanhos variados, cada um contendo um diretório de treinamento e validação com subdiretórios de imagens e arquivo metadata.jsonl com exemplos de treinamento:

    {"file_name": "images/img_0.jpg", "prompt": "what is the date mentioned in this letter?", "completion": "1/8/93"}
{"file_name": "images/img_1.jpg", "prompt": "what is the contact person name mentioned in letter?", "completion": "P. Carter"}

    Ajuste Fino e Rastreamento de Experimentos

    Com os artefatos enviados para o S3, procede-se ao ajuste fino do modelo através do SageMaker JumpStart para acessar o modelo Llama 3.2 11B Vision Instruct pré-treinado. Criam-se três variantes ajustadas distintas para avaliação.

    Um função de treinamento parametrizada facilita essa execução, manipulando múltiplos aspectos importantes: seleção do modelo com a versão mais recente disponível no JumpStart, obtenção automática de hiperparâmetros padrão usando a API retrieve_default() no SDK SageMaker, configuração de tamanho de lote (batch size) ajustado para 1 por dispositivo dadas as limitações de memória do modelo grande, e utilização de instâncias ml.p4de.24xlarge para trabalhos de treinamento.

    A integração automática com MLflow registra hiperparâmetros, nomes de trabalhos e metadados de treinamento para rastreamento de experimentos, enquanto cada modelo treinado é automaticamente implantado em um ponto de acesso (endpoint) SageMaker para inferência. O processo de treinamento leva algumas horas usando esse tipo de instância.

    Avaliação de Resultados

    Os modelos ajustados são avaliados utilizando a métrica ANLS, que avalia saídas baseadas em texto medindo a similitude entre respostas preditas e esperadas, mesmo com pequenos erros ou variações. Essa métrica é particularmente útil em tarefas de resposta a perguntas visuais por conseguir lidar com pequenas variações nas respostas.

    O MLflow rastreia experimentos e resultados para comparação direta. O fluxo de avaliação inclui funções para codificação de imagens para inferência do modelo, formatação de carga útil, cálculo de ANLS e registro de resultados. Uma função pipeline de treinamento orquestra o fluxo completo com execuções MLflow aninhadas para melhor organização de experimentos.

    Resultados Alcançados

    Após executar o pipeline completo três vezes para os três tamanhos de conjunto de dados diferentes, revisa-se os resultados da métrica ANLS no MLflow. Os dados evidenciam uma relação positiva entre o tamanho do conjunto de dados de treinamento e a pontuação ANLS:

    • Modelo docvqa-1000: 0.886
    • Modelo docvqa-5000: 0.894
    • Modelo docvqa-10000: 0.902
    • Modelo Base: 0.853

    O modelo docvqa-10000 alcançou a maior pontuação ANLS de 0.902, representando um aumento de 4,9 pontos percentuais em relação ao modelo base (0.902 − 0.853 = 0.049). Essa melhoria valida a abordagem para tarefas de resposta a perguntas visuais.

    Benefícios Principais

    A integração entre o Amazon SageMaker Unified Studio e buckets S3 de propósito geral oferece diversos benefícios:

    • Descoberta e catalogação simplificadas de dados através de uma interface unificada
    • Acesso seguro aos dados através de S3 Access Grants sem necessidade de gerenciamento complexo de permissões
    • Colaboração tranquila entre produtores e consumidores de dados em diferentes projetos
    • Rastreamento de experimentos de ponta a ponta com integração gerenciada do MLflow

    As organizações podem agora aproveitar seus ativos de dados S3 existentes de forma mais eficaz para cargas de trabalho de aprendizado de máquina, mantendo controles de governança e segurança.

    Próximos Passos

    Para aprofundar a exploração dessa abordagem, considere investigar técnicas adicionais de pré-processamento de dados, experimentar diferentes arquiteturas de modelos disponíveis através do SageMaker JumpStart, ou aumentar a escala para conjuntos de dados maiores conforme os requisitos de seu caso de uso exigirem.

    O código de solução completo está disponível em um repositório GitHub para referência e implementação prática.

    Fonte

    Accelerating LLM fine-tuning with unstructured data using SageMaker Unified Studio and S3 (https://aws.amazon.com/blogs/machine-learning/accelerating-llm-fine-tuning-with-unstructured-data-using-sagemaker-unified-studio-and-s3/)

  • Amazon Polly com Streaming Bidirecional: Síntese de Voz em Tempo Real para IA Conversacional

    Construindo Experiências Conversacionais Naturais

    Para criar interações de conversação genuinamente naturais, é fundamental contar com síntese de voz que acompanhe o ritmo das trocas em tempo real. A AWS anunciou uma solução inovadora: a nova API de Streaming Bidirecional para o Amazon Polly, que possibilita síntese de texto para voz (TTS) simplificada e em tempo real, permitindo enviar texto e receber áudio simultaneamente.

    Este novo recurso foi desenvolvido especificamente para aplicações de IA conversacional que geram texto ou áudio incrementalmente — como as respostas de modelos de linguagem de grande escala (LLMs) — onde o usuário precisa começar a sintetizar áudio antes mesmo que o texto completo esteja disponível.

    O Amazon Polly já oferecia suporte para transmissão de áudio sintetizado de volta ao usuário. A inovação agora vai além, focando em comunicação bidirecional sobre HTTP/2, que traz ganhos significativos em velocidade, redução de latência e simplificação da implementação.

    O Desafio da Síntese de Voz Tradicional

    As APIs convencionais de conversão de texto para voz seguem um padrão simples: requisição e resposta. Isso obriga o desenvolvedor a ter o texto completo disponível antes de fazer a requisição de síntese. Embora o Amazon Polly transmita áudio de volta de forma incremental, o gargalo estava no lado da entrada — não era possível começar a enviar texto até que ele estivesse totalmente pronto.

    Em aplicações conversacionais alimentadas por LLMs, onde o texto é gerado token por token, isso significava aguardar a resposta completa do modelo antes de iniciar a síntese. Imagine um assistente virtual: o modelo de linguagem gera tokens progressivamente durante vários segundos, e com TTS tradicional, o usuário tinha que esperar por:

    • O LLM terminar de gerar a resposta completa
    • O serviço de TTS sintetizar todo o texto
    • O áudio ser baixado antes da reprodução começar

    A nova API de streaming bidirecional do Amazon Polly foi projetada especificamente para eliminar esses gargalos.

    O Que Mudou: Streaming Bidirecional

    A API StartSpeechSynthesisStream introduz uma abordagem fundamentalmente diferente:

    • Enviar texto incrementalmente: Transmita texto para o Amazon Polly conforme fica disponível — sem necessidade de aguardar sentenças ou parágrafos completos.
    • Receber áudio imediatamente: Obtenha bytes de áudio sintetizados em tempo real conforme são gerados.
    • Controlar o tempo de síntese: Use configuração de flush para disparar síntese imediata do texto em buffer.
    • Comunicação true duplex: Envie e receba simultaneamente através de uma única conexão.

    Componentes-chave da Arquitetura

    A API funciona através de eventos estruturados que trafegam em ambas as direções:

    Componente Direção Finalidade
    TextEvent Entrada (Cliente → Amazon Polly) Enviar texto a ser sintetizado
    CloseStreamEvent Entrada (Cliente → Amazon Polly) Sinalizar fim da entrada de texto
    AudioEvent Saída (Amazon Polly → Cliente) Receber chunks de áudio sintetizado
    StreamClosedEvent Saída (Amazon Polly → Cliente) Confirmação de conclusão do stream

    Comparação: Antes e Depois

    Implementação Tradicional (Separação de Arquivo)

    Alcançar TTS com baixa latência costumava exigir implementações no nível da aplicação:

    • Lógica customizada de separação de texto no servidor
    • Múltiplas chamadas paralelas à API do Amazon Polly
    • Remontagem complexa de áudio

    Nova Abordagem: Streaming Bidirecional Nativo

    Os benefícios agora são diretos:

    • Nenhuma lógica de separação necessária
    • Uma única conexão persistente
    • Streaming nativo em ambas as direções
    • Redução significativa da complexidade infraestrutural

    Resultados de Performance

    Para medir o impacto real, a AWS comparou a API tradicional SynthesizeSpeech com a nova API StartSpeechSynthesisStream usando as mesmas condições:

    • 7.045 caracteres de prosa (970 palavras)
    • Voz Matthew com mecanismo Generative
    • Saída em MP3 a 24kHz na região us-west-2

    Metodologia de Teste

    Ambos os testes simularam um LLM gerando tokens a aproximadamente 30ms por palavra. No teste da API tradicional, palavras foram agrupadas até um limite de sentença, e então a sentença completa foi enviada como uma requisição SynthesizeSpeech, aguardando a resposta de áudio completa antes de continuar. O teste de streaming bidirecional enviou cada palavra conforme chegava, permitindo que o Amazon Polly começasse a síntese antes que o texto estivesse completo.

    Métrica SynthesizeSpeech Tradicional Streaming Bidirecional Melhoria
    Tempo total de processamento 115.226 ms (~115s) 70.071 ms (~70s) 39% mais rápido
    Chamadas à API 27 1 27x menos chamadas
    Sentenças enviadas 27 (sequencial) 27 (transmitidas como tokens chegam) —
    Total de bytes de áudio 2.354.292 2.324.636 —

    A vantagem arquitetural é clara: a API bidirecional permite enviar texto de entrada e receber áudio sintetizado simultaneamente por uma única conexão. Em vez de aguardar cada sentença se acumular antes de solicitar síntese, o texto flui para o Amazon Polly palavra por palavra conforme o LLM o produz. Para IA conversacional, isso significa que o Polly recebe e processa texto incrementalmente durante toda a geração, não tudo de uma vez após o modelo terminar. O resultado é menos tempo em espera pela síntese após a geração ser concluída — a latência de ponta a ponta do prompt até a entrega completa do áudio se reduz significativamente.

    Implementação Técnica

    Começando a Usar

    A API de streaming bidirecional está disponível nos AWS SDKs para Java 2.x, JavaScript v3, .NET v4, C++, Go v2, Kotlin, PHP v3, Ruby v3, Rust e Swift. Suporte para CLIs (AWS Command Line Interface v1 e v2, PowerShell v4 e v5), Python e .NET v3 ainda não estão disponíveis.

    Um exemplo básico de inicialização:

    // Criar o cliente Polly assíncrono
    
PollyAsyncClient pollyClient = PollyAsyncClient.builder()
    
    .region(Region.US_WEST_2)
    
    .credentialsProvider(DefaultCredentialsProvider.create())
    
    .build();
    

    // Criar a requisição de stream
    
StartSpeechSynthesisStreamRequest request = StartSpeechSynthesisStreamRequest.builder()
    
    .voiceId(VoiceId.JOANNA)
    
    .engine(Engine.GENERATIVE)
    
    .outputFormat(OutputFormat.MP3)
    
    .sampleRate("24000")
    
    .build();
    

    Fonte
    

    Introducing Amazon Polly Bidirectional Streaming: Real-time speech synthesis for conversational AI (https://aws.amazon.com/blogs/machine-learning/introducing-amazon-polly-bidirectional-streaming-real-time-speech-synthesis-for-conversational-ai/)

  • Inferência com IA Generativa na Região da Nova Zelândia: Como o Amazon Bedrock Expande sua Cobertura no Pacífico Asiático

    Inferência de IA generativa chega à Nova Zelândia

    A AWS ampliou seus serviços de IA generativa ao anunciar a disponibilidade do Amazon Bedrock na região do Pacífico Asiático, especificamente em Auckland (ap-southeast-6). Essa expansão responde a uma demanda crescente de clientes neozelandeses que buscavam acessar modelos de fundação diretamente de sua região local, sem necessidade de roteamento complexo ou latência adicional.

    Com esse lançamento, clientes em Auckland ganham acesso imediato aos modelos Anthropic Claude (incluindo Opus 4.5, Opus 4.6, Sonnet 4.5, Sonnet 4.6 e Haiku 4.5) e aos modelos Amazon Nova 2 Lite. A grande novidade é que essa capacidade agora funciona através de roteamento entre regiões diretamente da Nova Zelândia, eliminando a necessidade de chamadas de API de fora do país.

    Como funciona o roteamento entre regiões

    O conceito de roteamento entre regiões (cross-region inference) é central para entender como o serviço opera. Trata-se de um recurso do Amazon Bedrock que distribui o processamento de inferência entre múltiplas regiões AWS para alcançar maior throughput em larga escala.

    O fluxo de requisições

    Quando você invoca um perfil de inferência entre regiões, o Amazon Bedrock roteia sua requisição da região de origem (onde você faz a chamada de API) para uma região de destino (onde o processamento de inferência ocorre). Todo dado transmitido durante essas operações permanece exclusivamente na rede privada AWS, sem passar pela internet pública. Além disso, todos os dados são criptografados em trânsito entre as regiões.

    Todas as requisições de inferência entre regiões são registradas no AWS CloudTrail na região de origem. Se você configurar o registro de invocação de modelos, os logs são publicados no Amazon CloudWatch Logs ou Amazon Simple Storage Service (S3), sempre na mesma região.

    Dois tipos de perfis de roteamento

    A AWS oferece duas abordagens diferentes para roteamento entre regiões:

    • Roteamento geográfico (AU): Roteia requisições dentro de um limite geográfico específico. No caso do perfil AU com Auckland como origem, as requisições são roteadas para Auckland, Sydney e Melbourne. Essa abordagem é ideal para organizações com requisitos de residência de dados que precisam manter o processamento de inferência dentro da Austrália e Nova Zelândia.
    • Roteamento global: Roteia requisições para todas as regiões AWS comerciais suportadas no mundo, fornecendo o throughput mais alto disponível. Essa opção é apropriada para organizações sem requisitos rigorosos de residência de dados.

    A Nova Zelândia como região de origem

    Com este lançamento, Auckland torna-se uma nova região de origem para ambos os perfis de roteamento entre regiões: o geográfico AU e o global. Isso significa que você pode fazer chamadas de API do Amazon Bedrock diretamente da região neozelandesa, com as requisições sendo roteadas para as regiões de destino onde os modelos de fundação processam a inferência.

    Configuração do roteamento geográfico AU

    O perfil AU agora abrange três regiões distribuídas pela Austrália e Nova Zelândia. A estrutura de roteamento funciona da seguinte forma:

    • De Auckland (ap-southeast-6): Requisições podem ser roteadas para Auckland, Sydney (ap-southeast-2) e Melbourne (ap-southeast-4)
    • De Sydney (ap-southeast-2): Requisições continuam sendo roteadas apenas para Sydney ou Melbourne
    • De Melbourne (ap-southeast-4): Requisições continuam sendo roteadas apenas para Sydney ou Melbourne

    Um detalhe importante: os perfis de roteamento AU que já existiam para Sydney e Melbourne continuam funcionando apenas entre essas duas cidades. A adição de Auckland não altera os destinos existentes para clientes nessas regiões. No entanto, requisições originando de Auckland têm três regiões de destino disponíveis, permitindo maior distribuição de carga.

    Roteamento global a partir da Nova Zelândia

    Para organizações sem requisitos rigorosos de residência de dados, o roteamento global oferece acesso à capacidade de inferência em todas as regiões AWS comerciais suportadas. Essa abordagem entrega dois benefícios principais:

    • Maior throughput: O roteamento inteligente distribui o tráfego dinamicamente entre todas as regiões suportadas, reduzindo a probabilidade de limitação durante picos de demanda
    • Resiliência integrada: Requisições são automaticamente roteadas para regiões com capacidade disponível, ajudando suas aplicações a manter continuidade operacional à medida que padrões de demanda mudam

    Modelos suportados e IDs de perfis de inferência

    O roteamento entre regiões a partir da Nova Zelândia oferece suporte a modelos de fundação de múltiplos fornecedores. Os modelos Anthropic Claude mais recentes incluem Opus 4.6, Sonnet 4.6, Sonnet 4.5 e Haiku 4.5, disponíveis através tanto do roteamento AU quanto global.

    Para usar um perfil de roteamento entre regiões, você substitui o ID do modelo de fundação original adicionando um prefixo geográfico (au.) ou global (global.). Por exemplo, o modelo anthropic.claude-sonnet-4-6 torna-se au.anthropic.claude-sonnet-4-6 ou global.anthropic.claude-sonnet-4-6.

    Para obter a lista completa e atualizada de modelos suportados e IDs de perfis de inferência, consulte a documentação sobre Regiões suportadas e modelos para perfis de inferência.

    Os perfis de roteamento entre regiões funcionam com as APIs InvokeModel, InvokeModelWithResponseStream, Converse e ConverseStream. A API Converse é especialmente útil pois oferece um formato consistente de requisição e resposta entre diferentes modelos de fundação, facilitando a troca entre modelos sem reescrever código de integração.

    Configuração de permissões de acesso

    Para invocar modelos de fundação através do roteamento geográfico AU a partir de Auckland, sua política de AWS Identity and Access Management (IAM) precisa de dois elementos:

    • Permissão para acessar o perfil de inferência na região de origem
    • Permissão para acessar o modelo de fundação em todas as regiões de destino do perfil AU

    Aqui está um exemplo de política IAM que concede permissão para invocar o Anthropic Claude Sonnet 4.6 através do roteamento geográfico AU a partir de Auckland:

    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAuCrisInferenceProfile",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": "arn:aws:bedrock:ap-southeast-6::inference-profile/au.anthropic.claude-sonnet-4-6"
    },
    {
      "Sid": "AllowFoundationModelViaAuCris",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": [
        "arn:aws:bedrock:ap-southeast-2::foundation-model/anthropic.claude-sonnet-4-6",
        "arn:aws:bedrock:ap-southeast-4::foundation-model/anthropic.claude-sonnet-4-6",
        "arn:aws:bedrock:ap-southeast-6::foundation-model/anthropic.claude-sonnet-4-6"
      ],
      "Condition": {
        "StringLike": {
          "bedrock:InferenceProfileArn": "arn:aws:bedrock:ap-southeast-6::inference-profile/au.anthropic.claude-sonnet-4-6"
        }
      }
    }
  ]
}

    A primeira declaração permite invocar o perfil de inferência AU a partir da região de origem Auckland. A segunda declaração permite que o modelo de fundação seja invocado nas três regiões de destino, mas apenas quando a requisição é roteada através do perfil de inferência AU. Isso segue o princípio do menor privilégio, impedindo invocação direta do modelo nessas regiões.

    O mesmo padrão de duas declarações aplica-se a qualquer modelo no perfil de roteamento AU. Simplesmente substitua o ID do modelo nos ARNs de recurso. Para políticas IAM de roteamento global e padrões avançados de segurança, consulte a documentação sobre Segurança do roteamento entre regiões do Amazon Bedrock.

    Segurança e conformidade

    O roteamento entre regiões é projetado com segurança como núcleo central. Todas as requisições viajam exclusivamente pela Rede Global AWS com criptografia ponta a ponta, e seus dados em repouso permanecem na região de origem.

    Considerações com Service Control Policies

    Para organizações que usam Service Control Policies (SCP) para restringir acesso a regiões AWS específicas, há pontos importantes a considerar ao chamar a partir de Auckland (ap-southeast-6):

    • O roteamento geográfico AU requer que você permita ap-southeast-2, ap-southeast-4 e ap-southeast-6 para ações do Amazon Bedrock em suas SCPs, pois o perfil AU de Auckland roteia para todas as três regiões ANZ
    • O roteamento global requer adicionalmente que você permita um valor de região não especificado para ações do Amazon Bedrock, já que regiões de destino são determinadas dinamicamente

    A seguir, um exemplo de SCP que restringe serviços à região Auckland, com exceções para Amazon Bedrock e serviços globais como IAM:

    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonBedrockServicesOutsideAuckland",
      "Effect": "Deny",
      "NotAction": [
        "bedrock:*",
        "iam:*",
        "organizations:*",
        "support:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["ap-southeast-6"]
        }
      }
    },
    {
      "Sid": "DenyBedrockOutsideANZRegions",
      "Effect": "Deny",
      "Action": "bedrock:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "ap-southeast-2",
            "ap-southeast-4",
            "ap-southeast-6"
          ]
        }
      }
    },
    {
      "Sid": "DenyDirectBedrockInDestinationRegions",
      "Effect": "Deny",
      "Action": "bedrock:*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": [
            "ap-southeast-2",
            "ap-southeast-4"
          ]
        },
        "Null": {
          "bedrock:InferenceProfileArn": "true"
        }
      }
    }
  ]
}

    Nessa política de exemplo: a primeira declaração restringe todos os serviços à região Auckland, exceto Amazon Bedrock e serviços globais como IAM, AWS Organizations e AWS Support. A segunda declaração restringe Amazon Bedrock às três regiões ANZ, necessária para que o roteamento AU rotear requisições de Auckland para Sydney e Melbourne. A terceira utiliza a condição Null em bedrock:InferenceProfileArn para negar qualquer requisição do Amazon Bedrock em Sydney ou Melbourne que não seja roteada através de um perfil de roteamento entre regiões.

    Auditoria e monitoramento

    AWS CloudTrail registra todas as chamadas de inferência entre regiões na região de origem. O campo additionalEventData.inferenceRegion registra onde cada requisição foi processada, permitindo que você audite exatamente onde a inferência ocorreu.

    Para monitoramento operacional em tempo real, Amazon CloudWatch fornece métricas para requisições de inferência entre regiões em sua região de origem. As métricas principais incluem:

    • InvocationCount: Número total de requisições de inferência
    • InvocationLatency: Tempo de resposta ponta a ponta incluindo roteamento entre regiões
    • InvocationClientErrors: Requisições falhadas, incluindo limitação (picos indicam que você está se aproximando dos limites de quota)
    • InputTokenCount e OutputTokenCount: Consumo de tokens para rastreamento de quota

    Gerenciamento de quotas

    As quotas de serviço do Amazon Bedrock são gerenciadas no nível da região de origem. Aumentos de quota solicitados a partir da região Auckland (ap-southeast-6) aplicam-se apenas a requisições originando de Auckland.

    As quotas são medidas em duas dimensões:

    • Tokens por minuto (TPM): Número máximo de tokens (entrada + saída) processados por minuto
    • Requisições por minuto (RPM): Número máximo de requisições de inferência por minuto

    Ao calcular sua quota necessária, leve em conta a taxa de consumo de tokens. Para Anthropic Claude Opus 4.6, Sonnet 4.6 e Sonnet 4.5, tokens de saída consomem cinco vezes mais quota que tokens de entrada (taxa 5:1). Para Claude Haiku 4.5 e modelos Amazon Nova, a taxa é 1:1.

    A fórmula de consumo de quota é: Consumo de quota = Tokens de entrada + Tokens de cache de escrita + (Tokens de saída × Taxa de consumo)

    Para solicitar aumentos de quota, navegue até o console de Quotas de Serviço AWS em sua região de origem, selecione Amazon Bedrock e procure pela quota de roteamento entre regiões relevante para seu modelo.

    Primeiros passos

    Para começar a usar roteamento entre regiões a partir da Nova Zelândia, siga estes passos:

    • Entre no console do Amazon Bedrock na região Auckland (ap-southeast-6)
    • Configure permissões de IAM e SCP usando os exemplos de política fornecidos
    • Faça sua primeira chamada de API usando o ID de perfil de inferência au.
    • Solicite aumentos de quota através do console de Quotas de Serviço com base em sua carga de trabalho esperada

    Conclusão

    A expansão do Amazon Bedrock para Auckland representa um marco importante na disponibilidade de IA generativa no Pacífico Asiático. Os pontos principais dessa novidade são:

    • Auckland torna-se agora uma região de origem para roteamento entre regiões, permitindo que clientes neozelandeses façam chamadas de API do Amazon Bedrock localmente
    • O roteamento geográfico AU mantém dados dentro da zona ANZ, com requisições de Auckland roteadas para três destinos (Auckland, Sydney e Melbourne)
    • O roteamento global expande o acesso a modelos, oferecendo o throughput mais alto disponível ao rotear requisições para regiões AWS comerciais em todo o mundo
    • As configurações de roteamento existentes para Sydney e Melbourne permanecem inalteradas, garantindo continuidade para clientes australianos

    Para mais informações, consulte documentação do Amazon Bedrock, o Guia do Usuário de Roteamento Entre Regiões, Regiões suportadas e modelos para perfis de inferência e Segurança do roteamento entre regiões do Amazon Bedrock.

    Fonte

    Run Generative AI inference with Amazon Bedrock in Asia Pacific (New Zealand) (https://aws.amazon.com/blogs/machine-learning/run-generative-ai-inference-with-amazon-bedrock-in-asia-pacific-new-zealand/)

  • Amazon ECS Managed Instances agora suporta workloads FIPS-certified em instâncias Graviton e GPU no AWS GovCloud

    Conformidade FIPS em Amazon ECS Managed Instances

    A partir de março de 2026, a AWS disponibilizou suporte para workloads compatíveis com FIPS (Padrão Federal de Processamento de Informações) em Amazon ECS Managed Instances nas regiões AWS GovCloud (US). Este recurso permite que clientes com requisitos de conformidade federal executem cargas de trabalho utilizando módulos criptográficos validados por FIPS em um amplo espectro de tipos de instâncias.

    O que é FIPS e por que importa

    FIPS é um padrão de segurança conjunto entre Estados Unidos e Canadá que especifica os requisitos de segurança para módulos criptográficos que protegem informações sensíveis. Para organizações que trabalham com dados governamentais ou operações que exigem conformidade com regulamentações federais, a certificação FIPS é essencial.

    Como funciona a conformidade nas regiões GovCloud

    Nas regiões AWS GovCloud (US), Amazon ECS Managed Instances habilita automaticamente a conformidade FIPS por padrão. O mecanismo de funcionamento envolve:

    • Comunicação através de endpoints compatíveis com FIPS
    • Utilização de módulos criptográficos apropriadamente configurados
    • Inicialização do kernel subjacente em modo FIPS

    Tipos de instâncias suportadas

    Clientes com requisitos de conformidade federal podem executar workloads com módulos criptográficos validados por FIPS em uma variedade de tipos de instância, incluindo:

    • Instâncias baseadas em Graviton
    • Instâncias aceleradas por GPU
    • Instâncias otimizadas para rede
    • Instâncias de desempenho variável (burstable performance)

    Como começar

    Para iniciar o uso de ECS Managed Instances, é possível utilizar diversos caminhos:

    • AWS Console (interface web)
    • Amazon ECS MCP Server
    • ECS Express Mode
    • Ferramentas de infraestrutura como código (IaC) de sua preferência

    Você pode habilitar o recurso em um novo cluster Amazon ECS ou em um cluster existente. Vale observar que será cobrado o gerenciamento da computação provisionada, além dos custos regulares de Amazon EC2.

    Próximas etapas

    Para aprender mais sobre FIPS, consulte os materiais disponibilizados pela AWS sobre FIPS na AWS e conformidade FIPS para AWS Fargate. Para informações completas sobre ECS Managed Instances, você pode acessar a página do recurso, a documentação técnica e o blog de lançamento da AWS.

    Fonte

    Amazon ECS Managed Instances now supports FIPS-certified workloads on Graviton and GPU accelerated instances in AWS GovCloud (US) Regions (https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-ecs-mi-supports-fips-graviron-gpu/)

  • SageMaker Unified Studio agora se conecta com o Cursor IDE para desenvolvimento com IA

    Uma ponte entre seu IDE local e a infraestrutura em nuvem

    A AWS anunciou um recurso que promete mudar a forma como desenvolvedores trabalham com machine learning e análise de dados. Agora é possível conectar o Cursor IDE diretamente ao Amazon SageMaker Unified Studio usando a extensão AWS Toolkit. Essa integração elimina a necessidade de alternar constantemente entre seu ambiente local e a infraestrutura em nuvem, mantendo você dentro de um único e coeso espaço de desenvolvimento.

    Cientistas de dados, engenheiros de aprendizado de máquina e desenvolvedores podem agora aproveitar todos os recursos do Cursor — incluindo sua conclusão de código alimentada por IA, edição por linguagem natural e edição de múltiplos arquivos — enquanto acessam os recursos computacionais escaláveis do Amazon SageMaker.

    O que essa integração oferece

    Continuidade no seu fluxo de trabalho

    Ao conectar o Cursor ao SageMaker Unified Studio, você preserva sua configuração personalizada do IDE local — com suas regras customizadas, extensões preferidas e preferências de modelos de IA — enquanto acessa simultaneamente seus recursos computacionais e dados armazenados no Amazon SageMaker. Tudo isso acontece em um único ambiente integrado, consolidando seus serviços de análise e IA/ML da AWS.

    Segurança em primeiro lugar

    Como o Cursor é construído sobre Code-OSS (Software de Código Aberto), a autenticação ocorre de forma segura através do AWS IAM via extensão AWS Toolkit. Isso garante acesso controlado a todos os seus domínios e projetos dentro do SageMaker Unified Studio, mantendo o padrão de segurança de nível empresarial que suas operações exigem.

    Capacidades ampliadas para seus projetos

    O SageMaker Unified Studio, parte da próxima geração do Amazon SageMaker, oferece um conjunto completo de ambientes integrados de desenvolvimento totalmente gerenciados. Você já podia usar JupyterLab e Code Editor baseado em Code-OSS. Agora, essa cobertura se estende ao seu Cursor local totalmente customizado, abrindo possibilidades de um único ponto de acesso para:

    • Processamento e transformação de dados
    • Análise SQL através de serviços como Amazon EMR, AWS Glue e Amazon Athena
    • Fluxos de trabalho de aprendizado de máquina

    Tudo isso com suporte a criptografia gerenciada pelo cliente e integração com AWS IAM para atender aos requisitos mais exigentes de segurança empresarial.

    Disponibilidade e próximos passos

    Esse recurso está disponível em todas as regiões da AWS onde o Amazon SageMaker Unified Studio opera. Se você deseja começar a usar essa integração, a documentação de suporte para IDE local oferece guias completos de configuração. Você também pode consultar a lista de regiões da AWS onde o SageMaker Unified Studio está disponível para verificar se a solução já está em sua região.

    Fonte

    Amazon SageMaker Unified Studio launches support for remote connection from Cursor IDE (https://aws.amazon.com/about-aws/whats-new/2026/03/sagemaker-unified-studio-cursor-ide/)

  • Implantação de Agentes de Voz com Pipecat e Amazon Bedrock AgentCore Runtime – Parte 1

    Introdução aos Desafios de Agentes de Voz em Tempo Real

    Implantar agentes de voz inteligentes que mantêm conversas naturais e semelhantes às humanas é uma tarefa complexa. Esses sistemas precisam transmitir áudio para usuários em múltiplos canais — aplicações web, móveis e telefônicas — mantendo responsividade mesmo sob tráfego pesado e condições de conectividade instáveis. Pequenos atrasos podem interromper o fluxo conversacional, fazendo o agente parecer não responsivo ou pouco confiável.

    Para casos de uso como atendimento ao cliente, assistentes virtuais e campanhas de outbound, manter um fluxo conversacional natural é essencial para a experiência do usuário. A série de artigos sobre este tema explora como arquiteturas de streaming ajudam a resolver esses desafios usando agentes de voz Pipecat no Amazon Bedrock AgentCore Runtime.

    Nesta primeira parte, você aprenderá como implantar agentes de voz Pipecat no AgentCore Runtime usando diferentes abordagens de transporte de rede — incluindo WebSockets, WebRTC e integração telefônica — com orientações práticas de implantação e exemplos de código.

    Benefícios do AgentCore Runtime para Agentes de Voz

    Implantação de agentes de voz em tempo real apresenta desafios significativos: é necessário garantir streaming com baixa latência, isolamento rigoroso para segurança e capacidade de escalar dinamicamente conforme o volume de conversas varia de forma imprevisível. Sem uma arquitetura bem projetada, você pode enfrentar jitter de áudio, limitações de escalabilidade, custos inflacionados por sobre-provisionamento e maior complexidade operacional.

    Para compreender melhor as arquiteturas de agentes de voz, incluindo abordagens em cascata (conversão de fala para texto → modelo de linguagem → conversão de texto para fala) e processamento direto entre falas, consulte o artigo anterior sobre construção de assistentes de voz em tempo real com Amazon Nova Sonic comparado a arquiteturas em cascata.

    O Amazon Bedrock AgentCore Runtime resolve esses desafios fornecendo um ambiente seguro e serverless para escalar agentes de IA dinâmicos. Cada sessão de conversa é executada em microVMs isoladas para segurança. O serviço faz auto-scaling para picos de tráfego e mantém sessões contínuas por até 8 horas, sendo ideal para interações de voz longas com múltiplas voltas. Cobra apenas pelos recursos efetivamente utilizados, minimizando custos associados a infraestrutura ociosa.

    O Pipecat, um framework para construir pipelines de IA de voz em tempo real, funciona no AgentCore Runtime com configuração mínima. Você empacota seu pipeline de voz Pipecat como um container e o implanta diretamente no AgentCore Runtime. O runtime suporta streaming bidirecional para áudio em tempo real e oferece observabilidade integrada para rastrear o raciocínio do agente e chamadas a ferramentas. Uma consideração importante: o AgentCore Runtime requer containers ARM64 (Graviton), então certifique-se de que suas imagens Docker foram compiladas para o sistema linux/arm64.

    Arquiteturas de Streaming para Agentes de Voz no AgentCore Runtime

    Este artigo pressupõe familiaridade com arquiteturas comuns de agentes de voz, especificamente a abordagem de modelos em cascata, onde você conecta modelos de conversão de fala para texto (STT – Conversão de Fala para Texto) e texto para fala (TTS – Conversão de Texto para Fala) em um pipeline, e a abordagem de processamento direto entre falas, como Amazon Nova Sonic. Se você é novo nesses conceitos, comece com os artigos anteriores sobre as duas abordagens fundamentais: cascata e processamento direto entre falas antes de prosseguir.

    Na construção de agentes de voz, a latência é uma consideração crítica que determina o quão natural e confiável é uma conversa por voz. As conversas exigem respostas quase instantâneas, tipicamente em menos de um segundo de ponta a ponta, para manter um ritmo fluido e semelhante ao humano. Para alcançar baixa latência, você precisa considerar streaming bidirecional em múltiplos caminhos:

    • Cliente para Agente: Seus agentes de voz serão executados em dispositivos e aplicações variadas, desde navegadores web e apps móveis até hardware de borda, cada um com condições de rede únicas.
    • Agente para Modelo: Seus agentes de voz dependem de streaming bidirecional para interagir com modelos de fala. A maioria dos modelos de fala expõe APIs WebSocket em tempo real, que seu runtime de agente ou framework de orquestração pode consumir para entrada de áudio e saída de texto ou fala.
    • Telefonia: Para chamadas tradicionais de entrada ou saída tratadas através de centros de contato ou sistemas telefônicos, seu agente de voz também deve ser integrado com um provedor de telefonia. Isso é tipicamente realizado através de transferência de handoff e/ou Protocolo de Interconexão de Sessão (SIP – Protocolo de Iniciação de Sessão), onde o stream de áudio ativo é transferido do sistema telefônico para seu runtime de agente para processamento.

    A seleção do modelo desempenha um papel fundamental para alcançar responsividade natural. Escolha modelos como Amazon Nova Sonic (ou Amazon Nova Lite em uma abordagem de pipeline em cascata) que são otimizados para latência e oferecem tempo rápido até o primeiro token (TTFT – Time-to-First-Token).

    Abordagens de Transporte de Rede

    Nesta primeira parte, nos concentramos na conexão Cliente para Agente e em como minimizar a latência de primeira volta de rede entre seu dispositivo de borda e seu agente de voz. A seguir, exploramos quatro abordagens de transporte de rede, considerando performance, resiliência e facilidade de implementação:

    • WebSockets: Aplicações web e móveis conectam-se diretamente aos agentes de voz via WebSockets. Performance consistente adequada, implementação simples, ideal para prototipagem e casos de uso leves.
    • WebRTC com TURN: Aplicações web e móveis conectam-se aos agentes via WebRTC com assistência de servidores de retransmissão (Traversal Using Relays around NAT – TURN). Performance excelente, implementação média, adequado para casos de produção com latência reduzida via conexão direta do cliente ao runtime com retransmissão via servidores TURN.
    • WebRTC Gerenciado: Aplicações web e móveis conectam-se aos agentes através de infraestrutura avançada e distribuída globalmente via WebRTC. Performance excelente com distribuição global, implementação simples, adequado para casos de produção com otimização de latência terceirizada para provedores especializados com rede distribuída globalmente e retransmissão de mídia. Oferece capacidades adicionais como observabilidade e chamadas multi-participante.
    • Telefonia: Agentes de voz são acessados através de chamadas telefônicas tradicionais. Performance excelente, implementação média, adequado para centros de contato e casos de telefonia. Latência pode depender do provedor de telefonia.

    Implementação com WebSockets

    Você pode começar com WebSockets como a abordagem mais simples: suporta nativamente a maioria dos clientes e o AgentCore Runtime. Implante agentes de voz Pipecat no AgentCore Runtime usando conexões WebSocket persistentes e bidirecionais para streaming de áudio entre dispositivos cliente e sua lógica de agente.

    A conexão segue um fluxo simples de três etapas:

    • Cliente solicita um endpoint WebSocket: O cliente primeiro envia uma solicitação POST para um servidor intermediário (/server) para obter um endpoint seguro de conexão WebSocket.
    • Servidor intermediário manipula autenticação AWS: O servidor intermediário na interface pré-construída Pipecat usa o AWS SDK para gerar uma URL pré-assinada AWS SigV4 com credenciais incorporadas como parâmetro de consulta.
    • Cliente estabelece conexão direta: Usando a URL pré-assinada autenticada, o cliente conecta-se diretamente ao agente no AgentCore Runtime e transmite áudio bidirecional, contornando o servidor intermediário para comunicações subsequentes.

    Você usa o transporte WebSocket do Pipecat para expor um endpoint no caminho /ws conforme exigido pelo AgentCore Runtime. A arquitetura separa gerenciamento de credenciais da lógica do agente, permitindo acesso seguro do cliente sem expor credenciais AWS diretamente a aplicações de navegador.

    Para saber mais, experimente o exemplo de código Pipecat no AgentCore usando transporte WebSockets.

    Implementação com WebRTC e Assistência TURN

    Embora WebSockets funcione bem para implantações simples, WebRTC pode oferecer performance melhorada. É projetado para enviar áudio usando um caminho de rede rápido e leve que minimiza atraso. Geralmente usa UDP por sua baixa latência e experiência mais suave em tempo real, oferecendo resiliência melhorada através de condições variáveis de conectividade. Se UDP não estiver disponível, WebRTC retorna automaticamente para TCP, que é mais confiável mas pode introduzir pequenos atrasos — menos ideal para voz, mas útil quando a conectividade é restrita.

    Essa confiabilidade vem dos servidores de Estabelecimento Interativo de Conectividade (ICE – Interactive Connectivity Establishment), que negociam caminhos diretos ponto-a-ponto através de NATs e firewalls, retrocedendo para retransmissão de mídia via servidores Traversal Using Relays around NAT (TURN) quando conexões diretas não podem ser estabelecidas.

    O Pipecat suporta SmallWebRTCTransport para conexões WebRTC ponto-a-ponto diretas entre clientes e agentes no AgentCore Runtime. Comparado a arquiteturas WebRTC abrangentes que exigem servidores de mídia dedicados (como Unidades de Encaminhamento Seletivo), esse transporte leve pode ser executado diretamente dentro do AgentCore Runtime, eliminando a necessidade de gerenciamento complexo de servidores de mídia.

    Nesse cenário, o fluxo de conexão funciona da seguinte forma:

    • Sinalização: O cliente envia uma oferta de Protocolo de Descrição de Sessão (SDP – Session Description Protocol) para o servidor intermediário, que a encaminha para o endpoint /invoke/ no AgentCore Runtime. O manipulador @app.entrypoint do agente processa a oferta e retorna uma resposta SDP contendo capacidades de mídia e candidatos de rede.
    • Estabelecimento de Conectividade: Para estabelecer uma conexão direta, tanto o cliente quanto o agente usam o protocolo ICE (Interactive Connectivity Establishment) para descobrir o caminho de rede ideal.

    O AgentCore Runtime suporta conexões retransmitidas via TURN. O protocolo tenta conectividade nesta ordem: conexão direta ponto-a-ponto (não suportada no AgentCore Runtime, pois o ambiente runtime não pode ser atribuído a um endereço IP público), conexão assistida por STUN (requer tráfego UDP bidirecional, não suportado atualmente), e retransmissão via TURN (recomendada).

    Para aprender mais, experimente o exemplo de código Pipecat no AgentCore usando transporte WebRTC.

    Configuração do AgentCore Runtime com VPC para Conectividade WebRTC

    O exemplo de código demonstra um agente de voz simples usando WebRTC. Primeiro, você configura variáveis de ambiente ICE_SERVER_URLS em ambos: 1) o servidor intermediário na interface pré-construída Pipecat (/server) e 2) o ambiente runtime (/agent). Isso permite tráfego bidirecional entre eles.

    Em seguida, você implanta seus agentes no AgentCore Runtime com VPC configurado para permitir transporte UDP para servidores TURN. Para segurança, você expõe o runtime para uma subnet VPC privada, com um NAT Gateway em uma subnet pública para rotear acesso à internet.

    Imagem original — fonte: Aws

    Com essa abordagem, você pode configurar servidores ICE para conectividade WebRTC completa, com suporte a STUN e UDP com fallback para TCP. Por exemplo, você pode configurar TURN gerenciado por Cloudflare da seguinte forma:

    # Configure agent/.env and server/.env
ICE_SERVER_URLS=stun:stun.cloudflare.com,turn:turn.cloudflare.com:53,turn:turn.cloudflare.com:3478,turn:turn.cloudflare.com:5349

    TURN Nativo da AWS com Amazon Kinesis Video Streams

    Como alternativa totalmente nativa da AWS a serviços TURN gerenciados, Amazon Kinesis Video Streams (KVS) gerencia infraestrutura TURN sem dependências de terceiros. Fornece credenciais TURN temporárias e com rotação automática via API GetIceServerConfig, evitando dependências de terceiros para travessia NAT.

    O fluxo funciona da seguinte forma:

    • Configuração única: Crie um canal de sinalização KVS. O canal é usado apenas para provisionamento de credenciais TURN — seu agente continua usando o transporte WebRTC do Pipecat para sinalização e mídia.
    • No momento da conexão: Seu agente chama GetSignalingChannelEndpoint para obter o endpoint HTTPS, depois chama GetIceServerConfig para recuperar credenciais TURN temporárias (URIs, nome de usuário, senha).
    • Configure a conexão par: Passe as credenciais retornadas para sua RTCPeerConnection como servidores ICE. O tráfego TURN flui através da infraestrutura gerenciada por KVS.

    Considerações ao usar TURN gerenciado por KVS:

    • É nativo da AWS sem dependência externa.
    • Gerenciamento de credenciais com rotação automática.
    • Configuração via criação de canal de sinalização e chamadas de API.
    • Ideal para implantações centradas em AWS.
    • Custo: Cada canal de sinalização ativo custa 0,03 dólares/mês. Em volume baixo a moderado, isso é negligenciável.
    • Limite de taxa: GetIceServerConfig é limitado a 5 transações por segundo por canal. Para implantações de alto volume excedendo 100.000 sessões por mês, implemente uma estratégia de pool de canais distribuindo requisições entre múltiplos canais.
    • Não há suporte PrivateLink: a VPC ainda requer egresso à internet via NAT Gateway para alcançar endpoints TURN do KVS.
    • Credenciais TURN são temporárias e com rotação automática, sem necessidade de gerenciar rotação.

    Para saber mais, experimente o exemplo de código usando TURN gerenciado por KVS.

    Implementação com WebRTC Gerenciado

    Embora WebRTC direto ofereça controle, provedores de WebRTC gerenciados comumente fornecem servidores TURN e Unidades de Encaminhamento Seletivo (SFUs – Selective Forwarding Units) distribuídas globalmente para facilitar conectividade confiável e roteamento de mídia com baixa latência. Também fornecem recursos adicionais como análises integradas e observabilidade, e suporte para salas multi-participante além de conversas 1:1 com agentes.

    Para agentes de voz em produção em escala, considere provedores gerenciados disponíveis no AWS Marketplace, como Daily. A Daily executa sua infraestrutura WebRTC distribuída globalmente na AWS oferecendo múltiplos modelos de implantação:

    • SaaS Totalmente Gerenciado: Você conecta à infraestrutura hospedada da Daily via endpoints de API pública. Ideal para implantação rápida e ambientes onde simplicidade operacional é priorizada. Nesse cenário, seu agente no AgentCore Runtime pode simplesmente conectar-se à infraestrutura WebRTC gerenciada via internet pública.
    • Implantação em VPC do Cliente: Você implanta os servidores de mídia da Daily diretamente em sua VPC para controle completo de rede e conformidade com requisitos rigorosos de residência de dados. Nesse cenário, você configura AgentCore Runtime para VPC conforme descrito acima.
    • SaaS com AWS PrivateLink: Você conecta à infraestrutura hospedada da Daily e configura AWS PrivateLink para que o tráfego flua através de endpoints VPC diretamente para a infraestrutura gerenciada da Daily sem atravessar a internet pública, reduzindo latência mantendo isolamento de rede. Nesse cenário, você configura AgentCore Runtime para VPC conforme descrito acima.

    Para saber mais, entre em contato com sua equipe de conta AWS para explorar Daily no AWS Marketplace ou experimente o exemplo de código usando transporte Daily na opção SaaS totalmente gerenciada.

    Integração com Provedores de Telefonia

    Enquanto WebRTC se destaca para canais web e móvel, a transferência telefônica permite integração tradicional da Rede Telefônica Pública Comutada (PSTN – Public Switched Telephone Network) para centros de contato, substituição de IVR e campanhas de outbound. Para conversa em tempo real, seu runtime de agente deve manter um stream de áudio persistente e bidirecional com seus modelos de fala, lógica de negócio e provedor de telefonia.

    Esses provedores oferecem serviços de voz gerenciados que lidam com a complexidade da infraestrutura telefônica tradicional através de APIs simples. Dependendo das capacidades do provedor de telefonia, você se integra a eles usando Protocolo de Iniciação de Sessão (SIP – Session Initiation Protocol) ou protocolos de streaming WebSocket ou WebRTC.

    Os transportes e serializadores do Pipecat fornecem conectores para implementação. Para saber mais, consulte o Guia Pipecat sobre Telefonia e o Guia de Integração de Telefonia para Aplicações de Voz Alimentadas por IA.

    Conclusão

    O AgentCore Runtime fornece infraestrutura segura e serverless para escalar agentes de voz confiáveis. Neste artigo, você aprendeu como baixa latência é crítica para conversas naturais e considerações-chave para diferentes modos de transporte: WebSockets, WebRTC com assistência TURN, WebRTC gerenciado e integrações telefônicas, com base em seus requisitos de latência, confiabilidade e uso.

    Ao avaliar opções de transporte, comece simples com WebSockets para prototipagem rápida, depois considere WebRTC com AgentCore em modo VPC ou provedores gerenciados para implantações em produção. Se seus agentes de voz pretendem lidar com casos de telefonia ou centros de contato, considere integrações disponíveis com provedores de telefonia para sua implementação.

    Na Parte 2 desta série, você explorará considerações adicionais além do transporte de rede: cobrindo estratégias de streaming através de comunicação agente-para-modelo, execução de ferramentas, memória e recuperação para alcançar latência ótima de ponta a ponta.

    Comece Agora

    Acesse os exemplos de código e workshop prático:

    Para equipes que preferem mais controle de infraestrutura, a Orientação para Construir Agentes de Voz na AWS no Amazon ECS também está disponível como opção de implantação containerizada.

    Recursos Adicionais

    Fonte

    Deploy voice agents with Pipecat and Amazon Bedrock AgentCore Runtime – Part 1 (https://aws.amazon.com/blogs/machine-learning/deploy-voice-agents-with-pipecat-and-amazon-bedrock-agentcore-runtime-part-1/)