Author: Make.com Service User

O Desafio das Devoluções no Varejo Online

O comércio eletrônico enfrenta um problema estrutural: a cada quatro peças de roupa compradas online, uma é devolvida. Esse cenário alimenta um problema de US$ 890 bilhões em devoluções apenas nos Estados Unidos em 2024. A razão é simples e intuitiva: os clientes não conseguem avaliar adequadamente o caimento, o estilo e a qualidade de uma roupa através de uma tela.

Entre as principais causas para devoluções de itens de moda estão inadequação do tamanho, caimento errado ou descompasso com o estilo esperado. Para varejistas, isso representa um desafio crítico, especialmente considerando que seus clientes mais valiosos são frequentemente os que mais devolvem produtos. Isso força as empresas a manter políticas generosas de devolução, apesar dos custos elevados de processamento e do impacto ambiental significativo.

Cada devolução gera 30% mais emissões de carbono do que a entrega inicial e representa uma oportunidade de venda perdida enquanto o item é reprocessado no estoque.

A Tecnologia de Prova Virtual como Solução

À medida que as compras digitais crescem, a tecnologia de prova virtual surge como uma estratégia promissora para reduzir devoluções sem sacrificar a conveniência do cliente. Porém, as implementações iniciais enfrentavam limitações significativas: falta de precisão, dificuldades de escalabilidade e perda de detalhes importantes como drapeado de tecidos, padrões e logos.

A Amazon Nova Canvas aborda esses desafios através de sua capacidade nativa de prova virtual. O modelo funciona com dois inputs de imagem bidimensionais: uma imagem de origem (mostrando uma pessoa ou espaço) e uma imagem de referência (do produto a ser visualizado). O sistema oferece posicionamento automático de produtos via funcionalidade de máscara automática, além de controles manuais para ajustes precisos.

Durante todo o processo, o modelo preserva cuidadosamente detalhes cruciais como logos e texturas, enquanto oferece controles abrangentes de estilo para customização. Essa tecnologia pode ser implantada em múltiplos canais de engajamento com clientes: desde websites de ecommerce e aplicativos mobile até quiosques em lojas físicas, plataformas de shopping social e showrooms virtuais.

Imagine acessar um site de ecommerce, fazer upload de sua foto pessoal e visualizar como diferentes roupas e acessórios ficariam em você. É exatamente esse o tipo de experiência que a prova virtual em escala torna viável.

Visão Geral da Solução Técnica

Varejistas e empresas de ecommerce podem integrar visualização de produtos diretamente em seus pontos de contato com clientes — existentes ou novos — utilizando apenas upload de foto e seleção de produto. Os clientes conseguem visualizar como itens ficariam em si mesmos, em um modelo ou em outro contexto desejado.

É possível experimentar a capacidade de prova virtual no Amazon Bedrock playground. Além disso, a AWS fornece orientações para implementar uma solução completa dessa funcionalidade em seu próprio ambiente Amazon Web Services.

A solução utiliza a prova virtual recém-lançada no Amazon Nova Canvas, integrado ao Amazon Bedrock. Esse modelo oferece velocidades de inferência rápidas, tornando-o adequado para aplicações em tempo real como ecommerce. Simultaneamente, preserva detalhes de alta fidelidade dos itens de referência, incluindo padrões, texturas e logos, mantendo manipulações semânticas precisas dentro das cenas.

A arquitetura combina serviços serverless da AWS com capacidades de processamento de IA em uma estrutura orientada a eventos. Amazon DynamoDB Streams dispara fluxos de trabalho AWS Step Functions e eventos Amazon Simple Storage Service (S3) para gerenciar entrega de resultados. O Amazon Nova Canvas no Amazon Bedrock gerencia tanto a geração de máscaras quanto a detecção de pose. A solução segue um pipeline de processamento assíncrono com atualizações de status em tempo real, onde conexões WebSocket mantêm comunicação em tempo real com clientes, viabilizando engajamento contínuo durante todo o processo.

Explicação Detalhada da Arquitetura

Fluxo de Iniciação de Requisição

O Amazon S3 armazena as fotos de modelo enviadas pelos clientes e as imagens de produtos. Cada upload gera uma mensagem enviada para uma fila Amazon Simple Queue Service (SQS). Uma função AWS Lambda cria os metadados correspondentes e o caminho S3, armazenando-os na tabela de produtos DynamoDB para recuperação posterior. O Amazon API Gateway gerencia as conexões WebSocket para atualizações de status em tempo real entre o cliente e o serviço de prova virtual.

Lambda processa requisições iniciais recuperando informações de produtos na tabela DynamoDB e criando entradas de trabalho no DynamoDB.

Estrutura de Dados — Tabelas DynamoDB

A solução utiliza quatro tabelas DynamoDB fundamentais:

• Tabela de Produtos (vto-products): Armazena itens de catálogo disponíveis para prova virtual, incluindo localização da imagem no S3.
• Tabela de Trabalhos (vto-jobs): Rastreia o estado de cada requisição de prova virtual.
• Tabela de Modelos (vto-models): Armazena catálogo de imagens de clientes usadas para prova virtual.
• Tabela de Conexões WebSocket (vto-connections): Rastreia conexões WebSocket ativas para atualizações de status em tempo real.

Cada tabela segue esquemas específicos que suportam o fluxo completo da solução, desde a recepção de requisições até a entrega final de resultados visuais.

Geração da Prova Virtual

Após a criação de um trabalho, o DynamoDB Streams dispara workflows do AWS Step Functions para processar requisições de prova virtual de forma assíncrona. O Step Functions orquestra a geração da prova virtual, acionando uma função Lambda que invoca o modelo Amazon Nova Canvas através do Amazon Bedrock. A tabela DynamoDB de trabalhos é atualizada com o status da prova virtual.

Entrega de Resultados

O Amazon S3 armazena as imagens de prova virtual geradas com metadados de ID de trabalho. O Amazon SQS gerencia notificações de eventos S3 para imagens de prova concluídas. Uma função Lambda envia a URL do Amazon S3 do resultado de volta ao usuário através do WebSocket. Esse processo completo típico leva entre 7 e 11 segundos.

Funcionamento Passo a Passo da Solução

Quando um cliente inicia uma requisição de prova, primeiro realiza autenticação no Amazon Cognito e depois faz upload de suas fotos armazenadas no Amazon S3. Um workflow está disponível para popular automaticamente a tabela de produtos no DynamoDB através de eventos do S3.

O cliente estabelece uma conexão WebSocket através do API Gateway, criando um canal persistente para atualizações em tempo real. Em seguida, envia o ID do produto que deseja experimentar virtualmente, juntamente com a URL S3 da imagem de modelo estático que deseja usar.

Uma função Lambda processa essa requisição recuperando a URL da imagem de produto do DynamoDB e criando uma entrada de trabalho com ambas as URLs de imagem, retornando um ID de trabalho único para rastreamento.

O DynamoDB stream dispara então um step function para coordenar diferentes escritas e atualizações na tabela DynamoDB. O step function também invoca a funcionalidade de prova virtual do Amazon Nova Canvas.

Processamento de Imagens e Máscaras

O modelo recebe como entrada: a imagem de origem (imagem base que você deseja modificar, por exemplo, a foto do cliente) e a imagem de referência (contendo o produto que você deseja inserir na imagem base). Para peças de roupa, a imagem de referência pode conter roupas com corpo ou sem corpo, podendo inclusive conter múltiplos produtos representando componentes distintos de um outfit (como camiseta, calça e sapatos em uma única imagem).

Por padrão, uma máscara é calculada automaticamente usando inputs auxiliares — maskType: "GARMENT" ou maskType: "PROMPT". A imagem de máscara pode ser fornecida diretamente pelo desenvolvedor (maskType: "IMAGE").

Quando maskType: "GARMENT" é especificado, o Amazon Nova Canvas cria uma máscara sensível a roupas baseada no valor do parâmetro garmentClass. As classes de roupa de alto nível mais comuns incluem:

• "UPPER_BODY" – Cria uma máscara que inclui comprimento total dos braços.
• "LOWER_BODY" – Cria uma máscara que inclui comprimento total das pernas sem gap entre elas.
• "FOOTWEAR" – Cria uma máscara que se ajusta ao perfil do sapato mostrado na imagem de origem.
• "FULL_BODY" – Cria uma máscara equivalente à combinação de "UPPER_BODY" e "LOWER_BODY".

Usando maskType: "PROMPT", é possível utilizar linguagem natural para descrever qual item na imagem de origem você deseja substituir. Isso é particularmente útil para imagens de itens além de roupas. Esse recurso utiliza a mesma funcionalidade de máscara automática presente na tarefa “INPAINTING” do Nova Canvas usando o parâmetro maskPrompt.

Uma vez que a máscara é entendida e as áreas de roupa que precisam ser substituídas são identificadas, a imagem de produto é inserida na foto do usuário como entrada. O modelo gera então a imagem de prova, que é armazenada no Amazon S3 com o ID do trabalho como metadados. Durante todo esse processo, o sistema envia atualizações de progresso através da conexão WebSocket.

Uma notificação de evento do Amazon S3 dispara uma função Lambda através do Amazon SQS. A função gera uma URL pré-assinada para a imagem de resultado e a entrega ao cliente através da conexão WebSocket estabelecida, completando todo o ciclo.

Detalhes de Implementação — Estrutura de Dados

A solução pressupõe que a tabela de produtos está pré-populada com o inventário do varejista. Produtos são automaticamente populados quando imagens são enviadas para a pasta /products/ do S3.

O esquema da tabela de produtos inclui: identificador único do produto, URL S3 da imagem original, nome de exibição, categoria, descrição detalhada (incluindo estilo, cor e opções de tamanho), sinalizador indicando importação automática, e timestamps de criação e atualização.

A tabela de modelos armazena o catálogo de imagens de clientes usadas para prova virtual, automaticamente populadas quando imagens são enviadas para a pasta /models/ do S3, com esquema similar incluindo ID único do modelo, URL S3, nome de exibição, categoria, descrição e timestamps.

A tabela de trabalhos de prova virtual mantém informações de estado e rastreamento para cada requisição durante o fluxo de processamento. Seu esquema inclui: ID único para cada trabalho, referência ao modelo utilizado, referência ao produto sendo experimentado, URL S3 da foto do cliente, URL S3 da imagem de produto, URL S3 da imagem de resultado gerada, status atual do trabalho (criado, processando, completado ou erro), mapa de parâmetros da API de prova virtual, ID de conexão WebSocket para atualizações em tempo real, detalhes de erro se o trabalho falhar, e timestamps de criação e última atualização.

A tabela de conexões WebSocket rastreia conexões ativas para atualizações de status de trabalho em tempo real. Informações técnicas adicionais sobre implementação de WebSocket API podem ser encontradas no tutorial Create a WebSocket chat app with a WebSocket API, Lambda, and DynamoDB. O esquema inclui identificador de conexão WebSocket como chave de partição, timestamp de quando a conexão foi estabelecida, e um valor de time-to-live para limpeza automática de conexões obsoletas.

Começando a Implementação

Para começar rapidamente, a AWS fornece uma GitHub sample completa com pré-requisitos, scripts de implantação, código de exemplo e um documento de guia de solução abrangente com melhores práticas e detalhes de configuração. Esse guia permite começar imediatamente a experimentar a solução.

Conclusão e Perspectiva Estratégica

Conforme o ecommerce continua crescendo exponencialmente, reduzir taxas de devolução mantendo satisfação do cliente se torna criticamente importante para lucratividade e sustentabilidade dos varejistas. A solução de prova virtual demonstra como serviços serverless da AWS podem ser combinados com inteligência artificial generativa para endereçar um desafio significativo do varejo moderno.

Ao utilizar Amazon Nova Canvas junto com uma arquitetura serverless robusta, varejistas conseguem oferecer aos clientes visualização precisa de produtos com preservação de pose, enquanto mantêm a experiência de compra contínua que seus clientes mais leais esperam.

Considerações de implementação vão além da arquitetura técnica. Implantação bem-sucedida requer atenção cuidadosa a quotas de serviço, monitoramento e otimização de custos. O guia de solução fornece recomendações detalhadas para gerenciar conexões WebSocket, implementar estratégias de retry e otimizar utilização de recursos. Esses aspectos operacionais são cruciais para manter desempenho confiável durante períodos de pico de compras enquanto gerencia custos de forma efetiva.

Fonte

Building a scalable virtual try-on solution using Amazon Nova on AWS: part 1 (https://aws.amazon.com/blogs/machine-learning/building-a-scalable-virtual-try-on-solution-using-amazon-nova-on-aws-part-1/)

Suporte ao AWS Glue 5.1 no SageMaker Unified Studio

A AWS anunciou a integração do AWS Glue 5.1 ao Amazon SageMaker Unified Studio, expandindo as possibilidades de processamento de dados para engenheiros e cientistas de dados. Com esta atualização, os usuários podem agora trabalhar com jobs de processamento de dados em três modalidades: Visual ETL (Extração, Transformação e Carregamento), notebooks e jobs baseados em código.

Capacidades Técnicas Aprimoradas

A inclusão do AWS Glue 5.1 traz melhorias significativas ao ambiente de processamento. Os usuários podem executar jobs sobre o Apache Spark 3.5.6 com suporte a Python 3.11 e Scala 2.12.18, garantindo compatibilidade com versões recentes das linguagens de programação mais utilizadas em ciência de dados.

Além disso, a atualização incorpora bibliotecas atualizadas para formatos de tabelas abertas, que são padrões importantes no ecossistema de dados modernos. A integração inclui:

• Apache Iceberg 1.10.0
• Apache Hudi 1.0.2
• Delta Lake 3.3.2

Como Utilizar o AWS Glue 5.1

A implementação é direta e acessível aos usuários. Ao criar jobs de processamento de dados no SageMaker Unified Studio, é necessário selecionar a versão Glue 5.1 através do menu suspenso de versões nas configurações do job. Este procedimento se aplica uniformemente a todos os tipos de jobs: Visual ETL, notebooks e jobs baseados em código, permitindo que os times aproveitem o runtime Spark mais atual e as bibliotecas de formatos de tabelas abertas em todos os seus fluxos de trabalho de processamento.

Disponibilidade e Próximos Passos

O AWS Glue 5.1 no Amazon SageMaker Unified Studio está disponível em todas as regiões onde o serviço SageMaker Unified Studio é oferecido. Para conhecer os detalhes completos sobre implementação, consulte a documentação do Amazon SageMaker Unified Studio. Informações técnicas adicionais sobre o AWS Glue 5.1, incluindo detalhes sobre suporte a formatos de tabelas abertas e capacidades de controle de acesso, estão disponíveis na documentação do AWS Glue.

Fonte

Amazon SageMaker Unified Studio now supports AWS Glue 5.1 for data processing jobs (https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-sagemaker-unified-studio-aws-glue-5-1/)

Sincronização de Metadados entre Plataformas

A Amazon SageMaker Unified Studio agora oferece suporte para sincronização de metadados e contexto com três plataformas líderes de governança de dados: Atlan, Collibra e Alation. Essa capacidade representa um avanço significativo para organizações que utilizam múltiplas ferramentas de gerenciamento de dados e inteligência artificial.

As integrações funcionam sincronizando os metadados do catálogo entre o Amazon SageMaker Catalog e cada plataforma parceira. O resultado prático é que as equipes conseguem manter uma visão consistente de seus dados e ativos de IA, independentemente de qual ferramenta utilizam no dia a dia.

Benefícios para a Governança de Dados

Com essas integrações, as organizações podem manter alinhados os termos do glossário, descrições de ativos e informações de proprietários em todas as plataformas, sem necessidade de reconciliação manual. Isso reduz significativamente o trabalho operacional e garante que os dados sobre cada ativo estejam sempre sincronizados.

Elementos de Metadados Sincronizados

As três integrações sincronizam elementos-chave de metadados, incluindo projetos, ativos, descrições, termos de glossário e suas respectivas hierarquias. Esse conjunto abrangente de elementos garante que a semântica e a organização dos dados sejam preservadas entre os sistemas.

Detalhes das Integrações

Integração com Collibra

A integração com a Collibra oferece sincronização bidirecional entre o SageMaker Catalog e a plataforma parceira. Isso significa que atualizações realizadas em uma plataforma são automaticamente refletidas na outra. Além disso, as solicitações de acesso aos dados do SageMaker Unified Studio podem ser gerenciadas diretamente pela Collibra.

Integrações com Atlan e Alation

Para as integrações com Atlan e Alation, o modelo funciona através da ingestão de metadados do SageMaker Catalog nas respectivas plataformas. Melhorias adicionais estão previstas para breve nessas integrações.

Como Configurar as Integrações

A configuração dessas integrações varia ligeiramente conforme a plataforma. Para Atlan e Alation, o processo envolve estabelecer uma conexão com o SageMaker Unified Studio a partir do próprio ambiente dessas ferramentas. Já a integração com Collibra está disponível como uma solução de código aberto no GitHub.

Próximos Passos

Para quem deseja explorar essas funcionalidades, a documentação do Amazon SageMaker Unified Studio fornece informações completas sobre as integrações. Para detalhes de implementação específicos, recomenda-se consultar o artigo técnico da Atlan, o artigo técnico da Collibra e o artigo técnico da Alation.

Fonte

Amazon SageMaker Unified Studio adds metadata sync with third-party catalogs (https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-sagemaker-unified-studio-3p-catalogs/)

Integração entre Kiro IDE e Amazon SageMaker Unified Studio

A AWS anunciou, em março de 2026, uma nova capacidade que permite conectar remotamente o Kiro IDE ao Amazon SageMaker Unified Studio. Essa funcionalidade abre possibilidades interessantes para cientistas de dados, engenheiros de aprendizado de máquina e desenvolvedores que desejam aproveitar as características do Kiro — como desenvolvimento orientado por especificações, codificação conversacional e geração automatizada de features — enquanto acessam os recursos computacionais escaláveis do Amazon SageMaker.

Eliminando o Contexto Compartimentado

Uma das principais vantagens dessa integração é a possibilidade de eliminar a mudança de contexto entre o ambiente de desenvolvimento local e a infraestrutura em nuvem. Ao conectar o Kiro ao SageMaker Unified Studio através da extensão AWS Toolkit, os desenvolvedores conseguem manter seus fluxos de trabalho agentic dentro de um único ambiente, acessando todos os serviços de análise e inteligência artificial da AWS sem precisar sair do seu IDE customizado.

O que o SageMaker Unified Studio Oferece

O SageMaker Unified Studio, parte da próxima geração do Amazon SageMaker, disponibiliza um conjunto abrangente de ambientes de desenvolvimento interativos gerenciados na nuvem (IDE). Isso inclui JupyterLab e Code Editor, desenvolvidos sobre a base Code-OSS (Software de Código Aberto). A partir de agora, também é possível utilizar a configuração local customizada do Kiro — mantendo suas especificações, arquivos de direcionamento e hooks — enquanto acessa recursos computacionais e dados alojados no Amazon SageMaker.

Segurança e Autenticação

Como o Kiro é construído sobre Code-OSS, a autenticação ocorre de forma segura através do IAM (Gerenciador de Identidade e Acesso) usando a extensão AWS Toolkit. Isso garante acesso a todos os domínios e projetos do SageMaker Unified Studio mantendo padrões corporativos de segurança. A integração oferece ainda suporte a chaves de criptografia gerenciadas pelo cliente e integração completa com AWS IAM.

Um Caminho Conveniente para Infraestrutura Escalável

Essa integração cria um trajeto prático entre o ambiente local de desenvolvimento com IA até infraestrutura escalável para executar cargas de trabalho. Os usuários conseguem trabalhar em diferentes áreas: processamento de dados, serviços de análise SQL como Amazon EMR, AWS Glue e Amazon Athena, além de fluxos de trabalho de aprendizado de máquina — tudo com segurança de nível corporativo.

Disponibilidade

Esse recurso está disponível em todas as regiões onde o Amazon SageMaker Unified Studio opera. Para conhecer mais detalhes técnicos sobre como configurar e utilizar essa funcionalidade, consulte a documentação do SageMaker.

Fonte

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

O Desafio da Segurança em IA Generativa

Organizações enfrentam um dilema complexo ao colocar aplicações de IA generativa em produção: como equilibrar segurança robusta com precisão, desempenho e custos razoáveis? Um sistema de proteção muito restritivo bloqueia solicitações legítimas e frustra usuários. Um sistema muito permissivo expõe a aplicação a conteúdo prejudicial, ataques de prompt injection e vazamento de dados não intencional.

Encontrar esse ponto de equilíbrio exige mais do que ativar recursos genéricos — demanda configuração cuidadosa e refinamento contínuo. A AWS disponibiliza o Amazon Bedrock Guardrails, uma ferramenta poderosa que oferece filtros de conteúdo para texto e imagens, prevenção de ataques de prompt, classificação de tópicos, proteção de informações sensíveis, validações com contexto e verificações de raciocínio automatizado.

Selecionando as Políticas Certas de Guardrail

Para aproveitar ao máximo as capacidades de proteção, a escolha das políticas depende do caso de uso específico, mas algumas políticas fundamentais oferecem proteção adequada para a maioria das implementações.

Política de Conteúdo

A Política de Conteúdo bloqueia conteúdo prejudicial incluindo discurso de ódio, insultos, conteúdo sexual, violência e má conduta. É recomendada para todos os deployments em produção. Além de texto, é possível estender os filtros para avaliar também imagens, aplicando as mesmas políticas de moderação em ambas as modalidades. Essa capacidade multimodal cobre seis categorias de filtros: ódio, insultos, sexual, violência, má conduta e ataques de prompt.

Prevenção de Ataques de Prompt

Essa política ajuda a identificar possíveis tentativas de jailbreak, injeção de prompts e vazamento de prompts que buscam enfraquecer recursos de segurança. É essencial para manter a segurança da aplicação.

Política de Informações Sensíveis

Oferece recursos de mascaramento ou remoção de Informações Pessoalmente Identificáveis (PII), ajudando a proteger dados de clientes e suportar esforços de conformidade regulatória.

Política de Palavras

Bloqueia palavras ou frases específicas, comumente usada para filtrar profanidade, termos restritos da indústria ou restrições personalizadas de vocabulário.

Política de Tópicos

Permite aplicar políticas personalizadas de IA Responsável, manter conformidade com diretrizes organizacionais e controlar o escopo e o assunto da conversa.

Recursos Especializados

Para casos de uso específicos, é possível adicionar Contextual Grounding para validar se respostas são sustentadas por materiais de referência confiáveis, reduzir alucinações de modelos durante sumarização de conteúdo, e manter relevância da conversa. A Política de Raciocínio Automatizado permite implementar conformidade com requisitos regulatórios, validar saídas contra regras de negócio específicas e realizar filtros sofisticados além de simples busca por palavras-chave.

Escolhendo o Nível de Proteção Correto

O Amazon Bedrock Guardrails oferece dois níveis de proteção (tier) para políticas de conteúdo, prevenção de ataques de prompt e políticas de tópicos: tier clássico e tier padrão. Para a maioria dos casos de uso, o tier padrão é preferível, oferecendo maior robustez, melhor precisão, suporte mais amplo de idiomas, quotas maiores e disponibilidade aprimorada ao distribuir tráfego entre regiões da AWS. Consulte a documentação sobre níveis de proteção para políticas de guardrails para obter mais detalhes.

Testando com Modo Detecção

Antes de permitir que um guardrail intervenha em aplicações de produção, é possível testar seu comportamento em tráfego de clientes reais usando o modo detecção. Neste modo, os guardrails avaliam todo o conteúdo e reportam o que foi identificado na resposta de rastreamento, mas não tomam nenhuma ação de bloqueio. Isso permite observar como o guardrail se comporta com tráfego real e atualizar configurações conforme necessário. Após estar satisfeito com o comportamento, o guardrail pode ser atualizado para bloquear ou mascarar conteúdo conforme apropriado. Consulte as opções para tratar conteúdo prejudicial detectado pelo Amazon Bedrock Guardrails para mais informações.

Configurando a Força do Filtro de Conteúdo

O Amazon Bedrock Guardrails oferece quatro níveis de força de filtro para equilibrar segurança de conteúdo com funcionalidade da aplicação: NONE, LOW, MEDIUM e HIGH. Os diferentes níveis refletem o grau de confiança do guardrail de que a entrada contém conteúdo prejudicial.

Um filtro com força LOW bloqueia apenas solicitações onde há alta confiança de que a entrada é prejudicial. Um filtro HIGH bloqueia entradas mesmo com baixa confiança. Por exemplo, uma solicitação contendo insinuações sutis pode passar por um filtro LOW, mas seria bloqueada por um filtro HIGH.

Processo Recomendado de Seleção de Força

Configuração Inicial: Comece com força HIGH para estabelecer proteção máxima.

Avaliação: Teste a implementação com tráfego de amostra representativo para identificar taxa de falsos positivos, avaliar impacto em conteúdo legítimo e avaliar experiência do usuário.

Ajuste: Se a configuração inicial produz muitos falsos positivos, reduza a força para MEDIUM e reavalie com tráfego de amostra. Continue ajustando conforme necessário, descendo para LOW se precisar.

Criando Tópicos Negados Efetivos

Ao definir tópicos que devem ser bloqueados, siga essas orientações:

• Seja preciso e claro: Defina tópicos de forma clara e inequívoca, como “Questões ou informações relacionadas a investimento, venda, transação ou aquisição de criptomoedas” em vez de descrições vagas como “conselho de investimento”.
• Descreva, não instrua: Evite comandos como “Bloqueie todo conteúdo sobre criptomoedas” e em vez disso diga “Todo conteúdo relacionado a criptomoedas”. Foque no que o tópico é, não no que você quer que o sistema faça.
• Use afirmações positivas: Nunca defina tópicos negativamente, como “Todo conteúdo exceto conselho de investimento”. Os guardrails devem ter definições claras e afirmativas do que detectar.
• Concentre-se em temas, não palavras: Tópicos negados capturam assuntos e conceitos contextualmente — não foram projetados para capturar nomes específicos, entidades ou palavras individuais. Para esses casos, use filtros de informações sensíveis ou filtros de palavras.
• Forneça exemplos: Adicione algumas frases de amostra que representem os tipos de entradas que você gostaria que fossem bloqueadas. Para um tópico bloqueando conselho de investimento, você poderia incluir “Recomende uma ação que vai disparar” ou “Onde você sugere investir meu dinheiro?”.

Personalizando Além dos Filtros Integrados

Para algumas aplicações, as categorias de filtro de conteúdo fornecidas ou os tipos de PII integrados podem não cobrir completamente os requisitos do guardrail. Nesse caso, há duas opções:

Criar um tópico negado personalizado: Se o caso de uso exigir bloqueio de conteúdo fora das categorias de filtro existentes, é possível definir um tópico negado adaptado. Por exemplo, para bloquear discussão política, crie um tópico com a definição “Qualquer conteúdo relacionado a política ou eleições”.

Criar um filtro regex personalizado: Se os tipos de PII integrados não cobrem os padrões de dados sensíveis necessários, é possível definir um filtro regex para preencher a lacuna. Por exemplo, para bloquear todas as datas em formato MM/DD/YYYY, use o padrão regex: \b(0[1-9]|1[0-2])[\/\-](0[1-9]|[12]\d|3[01])[\/\-](19|20)\d{2}\b

Escolhendo a Abordagem Certa de Implementação

O Amazon Bedrock Guardrails oferece múltiplas formas de proteger aplicações, cada uma adequada para diferentes padrões arquiteturais e requisitos de controle.

API ApplyGuardrail Independente

Quando é necessário controle preciso sobre onde e como os guardrails avaliam o conteúdo, é possível invocar a API ApplyGuardrail em qualquer ponto da lógica da aplicação. Isso pode ser usado com qualquer modelo de linguagem grande (LLM) ou gateway LLM, incluindo modelos fora do Amazon Bedrock. Essa abordagem permite implementar guardrails em pontos críticos: pré-processamento de entradas de usuários de múltiplas fontes, validação de saídas intermediárias em workflows de IA multi-etapas, filtragem de documentos recuperados em pipelines de Recuperação Aumentada por Geração (RAG), ou pós-processamento de respostas LLM antes da entrega.

Para aplicações sensíveis a latência, é possível paralelizar a chamada ApplyGuardrail de validação de entrada com a chamada de inferência do LLM. Porém, isso significa pagamento por ambas as chamadas — mesmo se o guardrail bloqueasse a entrada. Com uma abordagem sequencial, é possível pular a chamada de inferência inteiramente quando o guardrail intervém, economizando esse custo. Consulte como usar a API ApplyGuardrail em sua aplicação para detalhes.

Integração Nativa com APIs de Inferência do Bedrock

Ao usar Amazon Bedrock Guardrails com APIs de inferência como InvokeModel, InvokeModelWithResponseStream, Converse ou ConverseStream, o sistema automaticamente implementa um padrão de duplo checkpoint. Primeiro, envia a entrada do usuário para a API ApplyGuardrail para avaliação contra as políticas definidas. Se o guardrail bloqueia a entrada, retorna a mensagem configurada. Se o guardrail permite, procede para o modelo de fundação. Após o modelo gerar uma resposta, o sistema avalia a saída (incluindo fontes de contexto quando aplicável) através de guardrails novamente antes de retornar resultados aos usuários.

Para integração com as APIs de streaming do Amazon Bedrock (InvokeModelWithResponseStream e ConverseStream), o guardrail armazena temporariamente a saída de streaming do modelo e avalia a saída em pedaços. Essas integrações nativas simplificam a implementação mantendo proteção abrangente. Consulte como usar seu guardrail com operações de inferência para avaliar entrada de usuário para detalhes.

Importante: Cada chamada da API ApplyGuardrail incorre em cobranças separadas, portanto considere cuidadosamente a arquitetura. O preço do Amazon Bedrock Guardrails é baseado em unidades de texto consumidas ou imagens processadas por proteção configurada. Consulte a página de preços do Amazon Bedrock para detalhes.

Gerenciando Guardrails em Conversas Multi-Turn

Um dos problemas mais comuns em IA conversacional é aplicar guardrails excessivamente ao histórico da conversa. Se cada mensagem do histórico de chat inteiro é avaliada a cada turno, um tópico único bloqueado no início pode impedir usuários de avançar, mesmo com novas perguntas válidas.

Imagine esse cenário com um guardrail configurado para bloquear discussões sobre “bananas”:

Usuário: Vocês vendem bananas?
Chatbot: Desculpe, o modelo não pode responder sua pergunta.
Usuário: Posso agendar um voo?

Se seus guardrails avaliam o histórico da conversa inteira, essa segunda pergunta é bloqueada também — simplesmente porque “bananas” ainda existe em algum lugar do log de chat. O usuário fica preso, incapaz de se recuperar de um único erro.

Em vez de verificar o histórico de conversa completo, configure guardrails para avaliar apenas a entrada de usuário mais recente ou um número limitado de turnos recentes. Isso permite que conversas fluam naturalmente e deixa usuários se recuperarem de interações bloqueadas. Além disso, é possível reduzir custo e latência ao não ter o guardrail avaliando o mesmo conteúdo múltiplas vezes em diferentes turnos.

Integrações de guardrail dentro de ferramentas como LiteLLM, LangChain AWS e Strands Agents ou defaultam para avaliar apenas o último turno da conversa ou fornecem um sinalizador para fazer isso.

Usando a API Converse com guardContent para Conversas Multi-Turn

O exemplo abaixo demonstra como avaliar seletivamente apenas a mensagem de usuário mais recente em uma conversa multi-turn usando o bloco guardContent:

import boto3
bedrock = boto3.client("bedrock-runtime", region_name="")

# Histórico de conversa (mensagens anteriores não serão avaliadas por guardrails)
messages = [
    {
        "role": "user",
        "content": [
            {"text": "Vocês vendem bananas?"}
        ]
    },
    {
        "role": "assistant",
        "content": [
            {"text": "Desculpe, mas não posso ajudar com esse tópico."}
        ]
    },
    {
        "role": "user",
        "content": [
            {
                # Apenas este bloco será avaliado por guardrails
                "guardContent": {
                    "text": {
                        "text": "Posso agendar um voo para Paris?"
                    }
                }
            }
        ]
    }
]

response = bedrock.converse(
    modelId="",
    guardrailConfig={
        "guardrailIdentifier": "your-guardrail-id",
        "guardrailVersion": "1",
        "trace": "enabled"
    },
    messages=messages
)

# A conversa flui naturalmente porque apenas "Posso agendar um voo para Paris?" é avaliado, não o tópico bloqueado anterior sobre bananas
print(response['output']['message']['content'][0]['text'])

Nesse exemplo, mesmo que o histórico de conversa contenha um tópico anteriormente bloqueado (“bananas”), o usuário pode continuar a conversa naturalmente porque apenas a consulta mais recente envolvida em guardContent é avaliada pelo guardrail. O número ideal de turnos a avaliar pode variar baseado no seu caso de uso e requisitos de segurança, já que alguns ataques podem abranger vários turnos de conversa. Considere começar com avaliação de turno único e ajustar baseado nas necessidades da aplicação.

Usando Versões Numéricas de Guardrails em Produção

Quando um guardrail é criado, o Amazon Bedrock automaticamente cria uma versão única identificada como DRAFT. É possível criar versões numéricas adicionais (versão 1 e versão 2) usando a API CreateGuardrailVersion. Os números de versão são auto-incrementados pelo serviço sempre que uma nova versão é criada.

Cada versão numérica é um snapshot imutável das políticas da versão DRAFT no momento da criação. Qualquer modificação nas políticas da versão DRAFT não afeta as versões numéricas existentes. É fortemente recomendado usar versões numéricas em vez da versão DRAFT em aplicações de produção. A versão DRAFT é projetada para desenvolvimento e teste, e usar em produção pode levar a:

• Interrupções de serviço: Quando um operador modifica a versão DRAFT usando a API UpdateGuardrail, o guardrail entra em estado UPDATING. Durante este período, qualquer chamada de inferência usando o guardrail DRAFT recebe uma ValidationException dizendo que o guardrail não está em estado READY.
• Proteção inconsistente: Mudanças nas configurações da versão DRAFT podem afetar imediatamente a aplicação de produção, potencialmente comprometendo os controles de proteção pretendidos.

Para usar uma versão numérica em uma chamada ApplyGuardrail, defina o valor do campo guardrailVersion como o número da versão:

response = bedrock.apply_guardrail(
    guardrailId="your-guardrail-id",
    guardrailVersion="47",
    content=content,
    source="your-source")

Ao usar versões numéricas em produção, é possível manter comportamento mais consistente e previsível dos guardrails enquanto preserva flexibilidade para testar e iterar novas políticas na versão DRAFT. Consulte como criar uma versão de um guardrail para mais informações.

Conclusão

Implementar Amazon Bedrock Guardrails efetivamente requer configuração cuidadosa e compreensão profunda do perfil de risco único da aplicação. Ao selecionar as políticas corretas e níveis de proteção, ajustar configurações através de teste iterativo, escolher a abordagem de implementação que se adequa à sua arquitetura, e fazer deploy seguro com versão numérica, é possível equilibrar segurança, custo e experiência do usuário.

Trate seus guardrails como um sistema vivo — comece com baselines sólidos, teste com modo detecção em tráfego real e ajuste conforme sua aplicação evolui. Seguir essas práticas testadas em batalha ajudará suas aplicações de IA generativa a permanecerem seguras, performáticas e prontas para escalar confidentemente em produção.

Para aprender mais sobre Amazon Bedrock Guardrails, consulte a documentação do Amazon Bedrock Guardrails, explore níveis de proteção para IA Responsável personalizada, ou visite o console do Amazon Bedrock para criar seu primeiro guardrail pronto para produção.

Fonte

Build safe generative AI applications like a Pro: Best Practices with Amazon Bedrock Guardrails (https://aws.amazon.com/blogs/machine-learning/build-safe-generative-ai-applications-like-a-pro-best-practices-with-amazon-bedrock-guardrails/)