User's blog

Blog

  • Boas Práticas para Tópicos Multi-Dataset no Amazon QuickSight com Chat por IA

    O problema que os Tópicos Multi-Dataset resolvem

    A maioria das perguntas de negócio reais envolve mais de uma tabela. Um varejista que quer entender a receita líquida por categoria de produto precisa cruzar uma tabela de vendas, uma de devoluções e uma de dimensão de produtos — cada uma em um dataset separado. Até pouco tempo atrás, unir esses dados exigia que um engenheiro de dados fizesse o pré-join e entregasse um único dataset ao Amazon QuickSight antes de qualquer analista poder fazer uma pergunta.

    A AWS anunciou os Tópicos Multi-Dataset no Amazon QuickSight para mudar essa dinâmica. Agora, equipes de analytics podem reunir múltiplos datasets em um único Tópico de duas formas: definindo chaves de relacionamento explícitas ou equipando o motor de Inteligência Artificial (IA) generativa com contexto semântico suficiente para que ele escreva o SQL por conta própria.

    Esse post foca no segundo caminho: SQL gerado por IA via Chat. Para entender as diferenças em relação à experiência legada de Tópicos, a AWS recomenda consultar o post Construindo uma camada semântica unificada com Tópicos Multi-Dataset no Amazon QuickSight.

    Como o Chat difere dos relacionamentos definidos

    Antes de entrar nas boas práticas, é importante entender a diferença arquitetural entre os dois modos de Tópicos Multi-Dataset no QuickSight:

    • Relacionamentos explícitos: O QuickSight constrói um grafo lógico de joins e executa inner joins em tempo de consulta. O grafo deve ser um Grafo Acíclico Dirigido (DAG — Directed Acyclic Graph), suporta até 12 datasets e produz resultados determinísticos. Ideal para cenários de relatórios governados.
    • SQL gerado por IA (Chat): A IA lê a camada semântica do Tópico — instruções, descrições e sinônimos — e gera o SQL para responder a pergunta. Não há grafo de joins pré-definido. A IA opera sobre intenção, não sobre estrutura. Isso permite outer joins, unions, subqueries, self-joins e comparações entre granularidades diferentes.

    Os relacionamentos definidos funcionam como trilhos de segurança: impedem joins incorretos. A orientação semântica funciona como guia: direciona a IA para o SQL correto e contextualmente apropriado. As duas abordagens têm valor — e podem ser combinadas em um Tópico híbrido.

    Para as boas práticas de relacionamentos definidos, a AWS disponibilizou dois posts complementares: Boas práticas de modelagem de dados para relacionamentos multi-dataset no Amazon QuickSight e Padrões de modelagem de dados para relacionamentos multi-dataset no Amazon QuickSight.

    A Pilha de Orientação Semântica (Semantic Guidance Stack)

    O motor de IA do QuickSight Chat utiliza sete camadas de metadados ao gerar SQL. Entender cada camada é a base para escrever metadados eficazes:

    • Instruções no nível do dataset: definem a granularidade, o propósito, as chaves e as regras de negócio de cada dataset individualmente.
    • Instruções no nível do Tópico: definem a lógica entre datasets, regras de desambiguação e comportamentos padrão de join.
    • Sinônimos de campos: mapeiam o vocabulário de negócio para os nomes técnicos dos campos.
    • Descrições de campos: explicam a semântica da coluna, unidades, nulabilidade e intervalos válidos.
    • Exclusões de colunas: removem ruído como chaves internas, timestamps de ETL (Extração, Transformação e Carga) e campos depreciados.
    • Campos calculados e filtros nomeados: pré-constroem métricas de negócio comuns que a IA pode referenciar diretamente.

    Cada camada reduz a incerteza da IA sobre os dados. Quanto mais precisamente cada camada for preenchida, mais estreito fica o espaço de interpretações possíveis de SQL — e mais precisos ficam os resultados gerados.

    As 8 Boas Práticas

    1. Escreva instruções no nível do dataset como um dicionário de dados

    As instruções de dataset são o primeiro ponto de contato da IA com cada tabela. Uma instrução eficaz deve incluir: propósito e granularidade da tabela, chave primária, dicas de chave estrangeira em linguagem natural, regras de negócio, casos extremos conhecidos e regras de agregação.

    Exemplo de instrução ruim: “Esta é a tabela de dados de vendas. Ela contém informações de vendas.”

    Exemplo de instrução boa:

    "SALES_FACT contém uma linha por item de pedido. Chave primária: order_line_id (inteiro, nunca nulo).
Granularidade: um item = um produto em um pedido.
Receita = quantity * unit_price - discount_amount. Sempre SUM receita.
Excluir linhas onde order_status = 'VOID' de todos os cálculos de receita."

    2. Escreva instruções no nível do Tópico para lógica entre datasets

    As instruções de Tópico dizem à IA como as tabelas se relacionam entre si, qual dataset tem precedência quando os termos são ambíguos e como tratar computações entre datasets. Devem incluir: relacionamentos conceituais, regras de desambiguação, comportamento padrão de join, resolução de múltiplos fatos e definições de negócio que abrangem datasets.

    Importante: as instruções de Tópico devem adicionar contexto entre datasets, nunca redefinir semânticas já especificadas no nível do dataset.

    3. Projete sinônimos para como os usuários realmente falam

    Sinônimos fazem a ponte entre como os usuários expressam perguntas e o que o esquema técnico chama de cada coisa. A estratégia de cobertura deve organizar os sinônimos em quatro níveis: linguagem executiva (nomes de KPIs), linguagem de analistas (definições de métricas), jargão do domínio e abreviações e acrônimos.

    A recomendação da AWS é ter entre 3 e 7 sinônimos por coluna consultada com frequência. Menos de 3 deixa lacunas de vocabulário; mais de 10 arrisca introduzir termos ambíguos.

    4. Enriqueça descrições de campos e tipos semânticos

    As descrições de campos dão à IA uma compreensão precisa do significado, unidade, restrições e uso pretendido de cada coluna. Cada descrição deve incluir: definição precisa, unidade ou formato, nulabilidade, valores válidos ou enumerados e comportamento de agregação.

    5. Guie o comportamento de join sem definir relacionamentos

    Tópicos orientados por Chat permitem especificar a semântica de join inteiramente por instruções em linguagem natural. A AWS descreve cinco técnicas:

    • Dicas implícitas de join: declare o tipo e a condição de join como regra em linguagem natural.
    • Instruções de alinhamento de granularidade: quando dois fatos têm granularidades diferentes, instrua a IA a fazer o rollup antes do join.
    • Instruções de union: quando duas tabelas têm o mesmo esquema e representam o mesmo tipo de entidade, instrua a IA a usar UNION ALL.
    • Instruções de subquery: para padrões de negação (“clientes que nunca compraram”), instrua a IA a usar NOT EXISTS ou LEFT JOIN / IS NULL.
    • Instruções de join condicional: alguns datasets só são relevantes para perguntas específicas — instrua a IA a incluí-los condicionalmente.

    6. Trate padrões complexos via instruções semânticas

    Tópicos orientados por Chat desbloqueiam padrões analíticos que os relacionamentos definidos não suportam:

    • Outer joins: instrua a IA a usar LEFT JOIN para preservar registros sem correspondência (ex: produtos sem vendas).
    • Relacionamentos muitos-para-muitos: instrua a IA a navegar pela tabela de bridge (ex: ENROLLMENTS entre STUDENTS e COURSES).
    • Hierarquias recursivas: instrua a IA a fazer self-join para representar hierarquias como funcionário/gestor.
    • Dimensões com múltiplos papéis (role-playing): instrua a IA sobre qual chave usar para cada papel (ex: DATE_DIM usada para data do pedido, data de envio e data de entrega).
    • Comparações entre granularidades: instrua a IA a fazer o rollup antes de comparar (ex: vendas diárias vs. metas mensais).
    • Relacionamentos circulares: diferente dos relacionamentos definidos, o Chat não rejeita grafos com ciclos — a IA navega pelo caminho mais apropriado para a pergunta.

    7. Reduza ruído e melhore a precisão das respostas

    Um achado contraintuitivo: menos campos visíveis produzem respostas mais precisas. A IA processa cada coluna no escopo ao formular o SQL. Colunas técnicas, chaves substitutas, timestamps de ETL e campos depreciados adicionam ruído. A recomendação é excluir: chaves substitutas internas, metadados de ETL, campos depreciados e campos de alta cardinalidade com baixo valor analítico.

    8. Teste, valide e itere o modelo semântico

    Um modelo semântico nunca está pronto na primeira versão. A AWS recomenda criar um banco de perguntas com 15 a 25 questões por dataset principal, organizadas em cinco níveis de complexidade crescente:

    • Nível 1: dataset único, métrica única — testa agregação básica e filtro de data.
    • Nível 2: dataset único, múltiplas dimensões — testa GROUP BY com múltiplas dimensões.
    • Nível 3: entre datasets, granularidade compatível — testa join e cálculo de divisão.
    • Nível 4: entre datasets, granularidade incompatível — testa alinhamento de granularidade e lógica de rollup.
    • Nível 5: padrões complexos — testa LEFT JOIN e agregação segura com NULL.

    Os pontos de validação incluem: tipo correto de join, granularidade correta de agregação, seleção correta do dataset, lógica de filtro e tratamento de valores NULL.

    Framework de Decisão: qual abordagem escolher?

    O Amazon QuickSight oferece três abordagens para Tópicos Multi-Dataset: relacionamentos definidos, orientação semântica (Chat) e um híbrido das duas. A escolha depende do caso de uso, perfil do usuário e requisitos de governança:

    • Esquema estrela estável, ambiente regulado: relacionamentos definidos — semântica de inner join aplicada, resultados determinísticos.
    • Analytics exploratório, perguntas ad-hoc: semântico apenas (Chat) — máxima flexibilidade.
    • Outer joins, unions ou subqueries necessários: semântico apenas (Chat) — relacionamentos definidos suportam apenas inner joins.
    • Hierarquias recursivas ou self-joins: semântico apenas (Chat).
    • Usuários não técnicos precisando de proteções: híbrido — grafo de join explícito mais metadados.
    • Power users, máxima flexibilidade: semântico apenas (Chat).

    Considerações práticas adicionais

    A AWS destaca alguns pontos importantes para quem for implementar essa abordagem:

    • Concisão nas instruções: prefira listas de regras em formato de tópicos a parágrafos em prosa. Cada regra deve ser uma afirmação independente e analisável.
    • Ordem de precedência: quando instruções de Tópico e de dataset conflitam, as de Tópico têm precedência. Use isso de forma previsível.
    • Performance: mantenha Tópicos focados em um domínio (analytics de varejo, RH, finanças). Evite criar um Tópico único para todo o data warehouse. Datasets com SPICE (in-memory) geralmente produzem respostas mais rápidas que fontes em Direct Query.
    • Segurança em nível de linha (RLS — Row-Level Security): é aplicada no nível do dataset, independentemente de como a IA faz joins ou unions. Um gestor regional restrito aos dados de sua região nunca verá dados de outras regiões, independentemente da pergunta feita no Chat.
    • Quando dividir em múltiplos Tópicos: considere dividir quando há comunidades de usuários diferentes com vocabulários distintos, datasets de domínios de negócio diferentes ou quando a complexidade das instruções do Tópico cresce além de 30 regras.

    Conclusão

    A transição de grafos de relacionamento explícitos para orientação semântica representa uma abordagem fundamentalmente diferente para analytics multi-dataset: em vez de definir cada caminho de join antecipadamente, você descreve a granularidade dos dados, o vocabulário, as regras de negócio e os casos extremos — e a IA traduz a intenção do usuário em SQL correto em tempo de consulta.

    Isso desbloqueia capacidades que relacionamentos pré-definidos não suportam: outer joins que preservam registros sem correspondência, unions que combinam tabelas paralelas, self-joins que percorrem hierarquias recursivas e comparações entre granularidades que exigem rollups em tempo de execução. A restrição é semântica, não estrutural: quanto mais precisamente você descreve seus dados, mais confiavelmente a IA entrega resultados corretos.

    Fonte

    Multi-dataset Topic best practices for Amazon Quick Chat (https://aws.amazon.com/blogs/machine-learning/multi-dataset-topic-best-practices-for-amazon-quick-chat/)

  • Camada Semântica Unificada no Amazon QuickSight: como os Tópicos Multi-Dataset funcionam

    O que mudou no QuickSight com os Tópicos Multi-Dataset

    O Amazon Quick é descrito pela AWS como um serviço de inteligência unificada com recursos de BI (Inteligência de Negócios), consulta em linguagem natural, relatórios e insights baseados em aprendizado de máquina. Dentro desse ecossistema, os Tópicos funcionam como a camada semântica que permite a usuários de negócio fazerem perguntas em linguagem natural e receberem respostas diretas a partir dos dados.

    Até recentemente, cada Tópico no QuickSight estava associado a um único dataset — uma tabela desnormalizada e achatada. Isso funcionava bem para casos simples, mas criava limitações sérias para quem trabalha com dados modelados em esquemas relacionais normalizados, como o modelo estrela (star schema). Com a chegada dos Tópicos Multi-Dataset (atualmente em prévia pública), a AWS expande esse modelo: agora é possível adicionar até 12 datasets a um único Tópico e definir relacionamentos entre eles.

    O motor de Consulta em Linguagem Natural (NLQ — Natural Language Query) passa a percorrer esses relacionamentos automaticamente ao responder perguntas. Ele interpreta a intenção do usuário, identifica quais datasets contêm as colunas relevantes, constrói os JOINs SQL adequados com base nos relacionamentos definidos e retorna uma resposta unificada — tudo sem que o usuário precise entender o schema subjacente.

    Como os Tópicos Multi-Dataset funcionam na prática

    A arquitetura da funcionalidade é organizada em quatro camadas principais:

    1. Fontes de dados

    Os datasets normalizados se conectam ao QuickSight a partir das fontes suportadas. Durante a prévia privada, os Tópicos Multi-Dataset suportavam apenas datasets no SPICE (Motor de Cálculo Super-rápido, Paralelo e em Memória — Super-fast, Parallel, In-memory Calculation Engine). A prévia pública expande o suporte para consulta direta (Direct Query) contra Amazon Redshift, Amazon Athena, Amazon S3 Tables, Snowflake e Databricks. Um ponto importante: não é possível combinar datasets SPICE e Direct Query dentro de um mesmo Tópico.

    2. Enriquecimento de datasets

    Cada dataset é enriquecido de forma independente com metadados semânticos que melhoram a precisão do NLQ. Esse enriquecimento inclui descrições de colunas, sinônimos (termos alternativos que os usuários de negócio costumam usar), tipos semânticos (Cidade, Estado, Moeda, Data), campos calculados e exclusões de campos. O motor NLQ usa esses metadados para mapear termos em linguagem natural às colunas corretas.

    Também é possível trazer datasets já enriquecidos por meio de catálogos do AWS Glue (AWS Glue Data Catalog) e do Databricks Unity Catalog. Por exemplo: quando um usuário pergunta sobre “headcount”, o motor associa esse termo ao sinônimo definido para a coluna correspondente.

    3. Tópico Multi-Dataset

    O Tópico funciona como o contêiner unificado que reúne os datasets. Ele armazena os datasets (até 12 em prévia), os relacionamentos entre eles (chaves de junção definidas em um arquivo JSON), instruções personalizadas em linguagem natural que orientam o motor de IA na interpretação de termos específicos do negócio, e as permissões de acesso — proprietários podem modificar o Tópico, enquanto visualizadores podem fazer perguntas e usá-lo em análises.

    4. Consumo

    Os usuários interagem com o Tópico por duas superfícies principais: o chat, onde fazem perguntas em linguagem natural, e as planilhas de análise, onde os autores constroem visuais usando campos de múltiplos datasets. Campos calculados podem referenciar colunas de datasets diferentes, e o motor cuida da lógica de JOIN subjacente.

    Como o chat processa perguntas entre datasets

    Quando um usuário faz uma pergunta que abrange múltiplos datasets, o motor NLQ executa quatro etapas:

    • Interpretação de intenção: identifica quais colunas correspondem aos termos usados pelo usuário, com base em nomes de colunas, descrições e sinônimos do enriquecimento.
    • Travessia de relacionamentos: determina o caminho de junção mais curto entre os datasets identificados, seguindo o grafo de relacionamentos definido.
    • Geração de SQL: constrói uma query SQL com as cláusulas JOIN, agregações e GROUP BY adequadas.
    • Apresentação do resultado: retorna a resposta como visualização ou tabela, com o SQL gerado disponível para inspeção.

    Para ilustrar, considere a pergunta: “Mostre o total de vendas por segmento de cliente e região da loja.” O motor mapearia “total de vendas” para SUM(SALES_FACT.SALE_AMOUNT), “segmento de cliente” para CUSTOMER_DIM.SEGMENT e “região da loja” para STORE_DIM.REGION. Em seguida, identificaria os relacionamentos necessários e produziria o seguinte SQL:

    SELECT c.SEGMENT AS customer_segment,
       s.REGION AS store_region,
       SUM(f.SALE_AMOUNT) AS total_sales
FROM SALES_FACT f
JOIN CUSTOMER_DIM c ON f.CUSTOMER_ID = c.CUSTOMER_ID
JOIN STORE_DIM s ON f.STORE_ID = s.STORE_ID
GROUP BY c.SEGMENT, s.REGION
ORDER BY total_sales DESC

    O usuário pode inspecionar o SQL gerado por meio do recurso de Explicação, verificando quais datasets e junções foram utilizados.

    Implementação passo a passo: cenário de analytics de varejo

    A AWS demonstra a funcionalidade com um cenário de varejo para a empresa fictícia AnyCompany, usando cinco datasets modelados em esquema estrela:

    • SALES_FACT: dados de vendas no nível de transação, com valores, quantidades, datas e chaves estrangeiras.
    • RETURN_FACT: registros de devoluções de produtos com quantidades, motivos e datas.
    • CUSTOMER_DIM: atributos de clientes, incluindo nome, segmento, nível de fidelidade e região geográfica.
    • PRODUCT_DIM: catálogo de produtos com categoria, marca, custo e fornecedor.
    • STORE_DIM: localizações de lojas com cidade, estado, metragem, número de funcionários e metas de receita.

    Pré-requisitos

    • Conta AWS com Amazon QuickSight Enterprise Edition habilitado.
    • Perfil de Autor ou Administrador no QuickSight.
    • Datasets representando um esquema estrela, carregados no SPICE ou acessíveis por uma fonte Direct Query suportada.
    • Permissões para criar Tópicos e gerenciar datasets.
    • Familiaridade com conceitos básicos de modelagem de dados (esquema estrela, tabelas fato e dimensão, chaves de junção).

    Enriquecendo cada dataset

    O enriquecimento é o que conecta os nomes técnicos das colunas ao vocabulário real dos usuários de negócio. Uma coluna chamada TXN_DT não significa nada para um analista de marketing que pergunta sobre “data de compra” — mas com sinônimos e descrições bem definidos, o motor NLQ consegue fazer essa associação.

    Para cada dataset, o processo no console do QuickSight envolve: acessar o dataset, escolher editar, selecionar a aba de saída e, para cada coluna, adicionar descrições, sinônimos e tipos semânticos. Campos internos ou não utilizados — como chaves substitutas, timestamps de auditoria e flags de ETL (Extração, Transformação e Carregamento) — devem ser excluídos. Por fim, salve e publique. Para instruções detalhadas, a AWS disponibiliza a documentação de enriquecimento de datasets.

    Como exemplo, o dataset STORE_DIM pode ser enriquecido assim:

    • STORE_ID: identificador único de cada loja — sinônimos: Store Number, Store Code, Shop ID — tipo: Identificador.
    • LOCATION: cidade onde a loja está localizada — sinônimos: City, Store City, Town, Area — tipo: Cidade.
    • REGION: estado dos EUA onde a loja opera — sinônimos: State, Territory, Market — tipo: Estado.
    • EMPLOYEE_COUNT: número de funcionários na loja — sinônimos: Headcount, Staff Count, Team Size — tipo: Contagem.

    Criando um Tópico com múltiplos datasets

    Com os datasets enriquecidos, o próximo passo é criar um Tópico que os combine em uma única camada semântica. No console do QuickSight, navegue até a aba Tópicos, escolha criar um novo Tópico, dê um nome (por exemplo, “Retail Sales Analytics”), adicione uma descrição e selecione todos os datasets relevantes.

    Definindo relacionamentos entre datasets

    Os relacionamentos informam ao motor NLQ como juntar os datasets quando uma pergunta abrange múltiplas tabelas. Eles são definidos por meio de um arquivo JSON com as chaves de junção entre pares de datasets. No editor do Tópico, acesse a aba Relacionamentos e faça o upload do arquivo. O JSON a seguir representa a configuração do esquema estrela do cenário de exemplo:

    {
  "datasetPairs": [
    {
      "datasetLeft": {
        "datasetName": "SALES_FACT",
        "joinColumnNames": ["CUSTOMER_ID"]
      },
      "datasetRight": {
        "datasetName": "CUSTOMER_DIM",
        "joinColumnNames": ["CUSTOMER_ID"]
      }
    },
    {
      "datasetLeft": {
        "datasetName": "SALES_FACT",
        "joinColumnNames": ["PRODUCT_ID"]
      },
      "datasetRight": {
        "datasetName": "PRODUCT_DIM",
        "joinColumnNames": ["PRODUCT_ID"]
      }
    },
    {
      "datasetLeft": {
        "datasetName": "SALES_FACT",
        "joinColumnNames": ["STORE_ID"]
      },
      "datasetRight": {
        "datasetName": "STORE_DIM",
        "joinColumnNames": ["STORE_ID"]
      }
    },
    {
      "datasetLeft": {
        "datasetName": "RETURN_FACT",
        "joinColumnNames": ["PRODUCT_ID"]
      },
      "datasetRight": {
        "datasetName": "PRODUCT_DIM",
        "joinColumnNames": ["PRODUCT_ID"]
      }
    }
  ]
}

    A recomendação da AWS é modelar os datasets em esquema estrela, com uma ou mais tabelas fato centrais conectadas a tabelas dimensão compartilhadas. Junções circulares e relacionamentos muitos-para-muitos devem ser evitados.

    Adicionando instruções personalizadas

    As instruções personalizadas funcionam como regras de negócio persistentes que o motor NLQ aplica a todas as perguntas. Sem elas, o motor interpreta os termos de forma literal — por exemplo, “este ano” seria interpretado como ano calendário. Se a organização usa ano fiscal iniciando em abril, é necessária uma instrução específica para sobrescrever esse comportamento padrão.

    Exemplos de instruções úteis:

    • “O ano fiscal começa em 1º de abril. Interprete ‘este ano’ usando os limites do ano fiscal.”
    • “Clientes ativos são aqueles com pelo menos uma compra nos últimos 90 dias.”
    • “Quando ‘vendas’ for mencionado sem qualificação, use net_sales_amount como padrão.”
    • “Taxa de devolução = contagem de itens devolvidos (RETURN_FACT) / total de itens vendidos (SALES_FACT), em percentual.”

    Publicando e compartilhando o Tópico

    Após configurar o Tópico, ele pode ser publicado e compartilhado com usuários de negócio. As permissões são definidas em dois níveis: Proprietário (pode perguntar, modificar e usar em análises) e Visualizador (pode perguntar e usar em análises, mas não modificar a configuração). O QuickSight mantém os controles de segurança em nível de linha (RLS — Row-Level Security) e em nível de coluna (CLS — Column-Level Security) definidos nos datasets, preservando os controles de acesso mesmo através da camada semântica do Tópico.

    Usando o Tópico em análises e no chat

    Em planilhas de análise, os autores podem criar uma análise a partir do Tópico, selecionar campos de múltiplos datasets e criar campos calculados que referenciam colunas de datasets diferentes.

    No chat NLQ, o Tópico fica disponível automaticamente como contexto. Exemplos de perguntas que o motor consegue responder usando os relacionamentos definidos:

    • “Resumir o tópico?”
    • “Análise de devoluções”
    • “Mostrar tendência da taxa de devolução como % da quantidade?”

    O SQL gerado pelo chat demonstra os JOINs entre múltiplos datasets em ação — e pode ser inspecionado pelo usuário para verificação.

    Limpeza de recursos

    Para evitar cobranças contínuas após experimentar a funcionalidade, a AWS recomenda excluir os recursos criados, como perfis do AWS Identity and Access Management (IAM), fontes de dados do QuickSight e políticas associadas.

    Conclusão

    Os Tópicos Multi-Dataset representam uma evolução importante no QuickSight: agora é possível construir uma camada semântica unificada sobre múltiplos datasets normalizados sem precisar pré-juntar ou duplicar dados. Ao definir relacionamentos via chaves de junção, enriquecer cada dataset com metadados semânticos e adicionar instruções personalizadas, o motor NLQ ganha o contexto necessário para responder perguntas cruzadas entre datasets com precisão.

    O modelo em esquema estrela é preservado, a duplicação de dados é reduzida e os administradores passam a ter uma superfície centralizada para gerenciar definições de negócio. Os usuários finais recebem respostas mais ricas pelo chat e pelas análises — sem precisar entender JOINs ou SQL.

    Para explorar a funcionalidade, a AWS disponibiliza a documentação oficial sobre Tópicos no QuickSight. Para discussões adicionais, a Comunidade Amazon QuickSight é um bom ponto de partida. Para um olhar aprofundado sobre diferentes cenários de modelagem, vale conferir o post Melhores Práticas de Modelagem de Dados para Relacionamentos Multi-Dataset no Amazon QuickSight.

    Fonte

    Build a unified semantic layer across datasets with multi-dataset Topics in Amazon Quick (https://aws.amazon.com/blogs/machine-learning/build-a-unified-semantic-layer-across-datasets-with-multi-dataset-topics-in-amazon-quick/)

  • Como garantir retenção zero de dados no Amazon Bedrock com Bedrock Projects e políticas de controle de serviço

    Por que o controle de retenção de dados no Bedrock ficou mais crítico

    Com a chegada de modelos que exigem compartilhamento de dados com provedores terceiros — como o Claude Fable 5 — a AWS reforçou os mecanismos disponíveis para que organizações controlem com precisão o que acontece com seus prompts e respostas após cada chamada de inferência. O Amazon Bedrock já oferecia controle sobre retenção de dados, mas agora a necessidade de aplicar essas políticas de forma centralizada e auditável ficou ainda mais evidente.

    Este artigo explica como os modos de retenção funcionam, quais ferramentas estão disponíveis para gerenciá-los e como verificar que as configurações estão funcionando corretamente — informações essenciais para times de segurança e engenharia que operam no Bedrock.

    Entendendo os modos de retenção de dados

    O Bedrock oferece quatro modos de retenção que determinam o que acontece com os dados após cada requisição de inferência. Consulte a documentação oficial do Amazon Bedrock para verificar quais modelos exigem retenção ou compartilhamento de dados.

    • none: Retenção zero. Prompts e respostas são processados e descartados imediatamente. Nenhum dado é compartilhado com o provedor do modelo.
    • default: Sem configuração explícita de compartilhamento. Alguns modelos podem reter dados por até 30 dias para verificações de segurança e confiança. Permite APIs que exigem retenção por natureza (como a Batch API e a Responses API com store=true). Modelos que suportam retenção zero continuam operando sem retenção.
    • inherit: Sem configuração explícita — herda o modo do escopo superior (projeto herda da conta, conta herda do padrão do serviço). Este é o padrão para novas contas.
    • provider_data_share: Dados são compartilhados com o provedor do modelo e retidos por até 30 dias para fins de segurança e confiança.

    Nota importante: Para combater a disseminação de material de abuso sexual infantil (CSAM), o Amazon Bedrock usa mecanismos automatizados de identificação nesse tipo de conteúdo nas entradas e saídas dos modelos. Conteúdos sinalizados podem ser armazenados e revisados mesmo quando o modo está configurado como none.

    O modo como teto, não como piso

    Um conceito fundamental: o modo configurado é o limite máximo de retenção que você aceita, não o que toda requisição vai usar. Configurar uma conta como provider_data_share não significa que todas as requisições passarão a reter e compartilhar dados.

    Modelos que suportam retenção zero continuarão operando com retenção zero, independentemente do modo da conta. Pense nisso como um teto de permissões:

    • Conta em provider_data_share + modelo Claude Sonnet (suporta none) → retenção zero, o Sonnet não exige compartilhamento
    • Conta em provider_data_share + Claude Fable 5 (exige provider_data_share) → dados retidos por até 30 dias e possivelmente compartilhados
    • Conta em none + Claude Sonnet → retenção zero
    • Conta em none + Claude Fable 5 → bloqueado; o teto da conta está abaixo do que o modelo exige

    Além disso, provider_data_share não é herdado de um modelo — é um opt-in explícito configurado no nível da conta ou do projeto. Se a conta estiver em inherit ou default, nenhum modelo acionará o compartilhamento de dados com o provedor.

    Ferramentas disponíveis para gerenciar retenção

    A AWS disponibiliza múltiplas camadas de controle que podem ser usadas de forma independente ou combinadas para uma defesa em profundidade:

    • Console do Amazon Bedrock: configuração por conta e por região, com visibilidade imediata do modo atual.
    • Amazon Bedrock Projects: isolamento de cargas de trabalho com necessidades diferentes de retenção dentro da mesma conta, para modelos compatíveis.
    • Políticas de Controle de Serviço (SCPs): aplicação em toda a organização, impedindo qualquer conta de habilitar o compartilhamento de dados.
    • Políticas do IAM: controle granular por conta ou por principal, incluindo a conta de gerenciamento (que SCPs não cobrem).

    Usando o Amazon Bedrock Projects para controle granular

    Nem toda carga de trabalho dentro de uma conta tem os mesmos requisitos de retenção. Com o Amazon Bedrock Projects — disponível no endpoint bedrock-mantle — é possível isolar o tráfego que pode aceitar retenção daquele que não pode, mesmo dentro da mesma conta.

    Por exemplo, uma organização pode ter:

    • Um projeto de pesquisa onde a equipe precisa de acesso aos modelos mais recentes (incluindo os que exigem provider_data_share) para experimentação.
    • Um projeto de produção que lida com dados de clientes onde retenção zero é obrigatória.

    Com o Bedrock Projects, é possível configurar provider_data_share no projeto de pesquisa e manter o projeto de produção bloqueado em none. Cada projeto aplica seu próprio teto de retenção de forma independente.

    A lógica de resolução do modo efetivo segue a hierarquia: projeto → conta → padrão do serviço. O primeiro valor não-inherit encontrado nessa cadeia é o modo aplicado.

    Importante: O Bedrock Projects só está disponível no endpoint bedrock-mantle, com modelos acessados via APIs compatíveis com OpenAI (Responses, Chat Completions) e a API Anthropic Messages no endpoint mantle. Verifique a disponibilidade por modelo e endpoint antes de planejar sua arquitetura.

    Isolamento no endpoint bedrock-runtime

    Se você usa o endpoint bedrock-runtime (APIs Invoke e Converse), o controle por projeto não está disponível — o modo de retenção da conta se aplica a todas as requisições. Para alcançar isolamento nesse endpoint, a recomendação da AWS é usar contas AWS separadas, organizadas em Unidades Organizacionais (OUs) do AWS Organizations com SCPs aplicadas seletivamente.

    Organization Root
├── OU: Zero-Retention (SCP attached — blocks provider_data_share)
│   ├── Account: Production-App-A
│   └── Account: Production-App-B
└── OU: Research (no SCP — allows provider_data_share)
    └── Account: ML-Experimentation

    Usando SCPs para aplicação em toda a organização

    Para organizações que precisam de uma garantia absoluta de que nenhuma conta pode habilitar o compartilhamento de dados — independentemente de quem tem acesso administrativo — as SCPs oferecem o mecanismo de aplicação mais forte.

    Uma SCP é uma barreira definida no nível organizacional. Ela se sobrepõe a todos os principais da organização, incluindo administradores de conta e usuários root. Mesmo com permissões de administrador completo, um deny de SCP não pode ser sobrescrito por uma política do AWS Identity and Access Management (IAM).

    As SCPs cobrem tanto o plano de controle do Amazon Bedrock (bedrock:PutAccountDataRetention) quanto o endpoint mantle (bedrock-mantle:PutAccountDataRetention, bedrock-mantle:CreateProject, bedrock-mantle:UpdateProject).

    A política SCP para retenção zero

    Atenção: Novas contas têm o modo padrão inherit, não none. Antes de anexar a SCP, é necessário configurar explicitamente cada conta para none:

    aws bedrock put-account-data-retention --region us-east-1 --mode none

    Para centenas ou milhares de contas, consulte o artigo do AWS re:Post Automate Bedrock Zero Data Retention Across All Accounts in Your Organization para aprender como escalar esse processo.

    A política SCP que restringe a retenção somente ao modo none:

    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RESTRICTBEDROCKDATARETENTION",
      "Effect": "Deny",
      "Action": [
        "bedrock:PutAccountDataRetention"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "bedrock:DataRetentionMode": "none"
        }
      }
    }
  ]
}

    O bloco Condition usa StringNotEquals, o que significa que o deny é acionado para qualquer valor diferente de none. Com essa política em vigor: ninguém pode habilitar o compartilhamento de dados com provedores de modelos; modelos que exigem provider_data_share (como Claude Fable 5 e Claude Mythos 5) ficam permanentemente indisponíveis; todos os outros modelos continuam funcionando normalmente.

    Bloqueando também as configurações por projeto

    O endpoint bedrock-mantle suporta configurações de retenção por projeto. Sem cobertura adicional na SCP, alguém poderia criar ou atualizar um projeto com provider_data_share, contornando a restrição no nível da conta. Para evitar isso, estenda a SCP:

    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RESTRICTBEDROCKDATARETENTION",
      "Effect": "Deny",
      "Action": [
        "bedrock:PutAccountDataRetention",
        "bedrock-mantle:PutAccountDataRetention",
        "bedrock-mantle:CreateProject",
        "bedrock-mantle:UpdateProject"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "bedrock:DataRetentionMode": "none"
        }
      }
    }
  ]
}

    O endpoint bedrock-runtime não precisa dos bloqueios de projeto porque projetos não existem nesse endpoint — apenas a ação bedrock:PutAccountDataRetention já é suficiente para cobri-lo.

    Retenção de dados e inferência entre regiões

    Ao usar perfis de inferência entre regiões (cross-Region inference profiles), o modo de retenção é avaliado na região de origem da requisição — a região onde a chamada de API é feita. Não é necessário configurar o modo em cada região de destino.

    Porém, há um ponto de atenção: embora a verificação do modo ocorra na região de origem, os dados podem ser retidos na região de destino onde a inferência é processada. Isso é relevante para organizações que monitoram onde os dados retidos residem geograficamente.

    Uma vantagem importante das SCPs nesse contexto: uma única SCP anexada à OU raiz bloqueia provider_data_share em todas as regiões automaticamente, sem necessidade de configuração por região.

    Verificando suas configurações

    A AWS oferece três formas de verificar as configurações de retenção: o console do Amazon Bedrock, a Interface de Linha de Comando da AWS (AWS CLI) (versão 2.35+) e a API bedrock-mantle.

    Verificar o modo atual da conta

    Via AWS CLI:

    aws bedrock get-account-data-retention --region us-east-1

    Resposta esperada:

    {
  "mode": "none",
  "updatedAt": "2026-07-01T01:58:34.684Z"
}

    Via API bedrock-mantle (usando uma chave de API do Bedrock):

    curl https://bedrock-mantle.us-east-1.api.aws/v1/data_retention \
  -H "x-api-key: $BEDROCK_API_KEY"

    Verificar o modo efetivo de um modelo específico

    curl https://bedrock-mantle.us-east-1.api.aws/v1/models/anthropic.claude-fable-5 \
  -H "x-api-key: $BEDROCK_API_KEY"

    Resposta:

    {
  "id": "anthropic.claude-fable-5",
  "status": "available",
  "data_retention": {
    "mode": "provider_data_share",
    "source": "account",
    "allowed_modes": ["provider_data_share"]
  }
}

    Se o modelo aparecer com "status": "unavailable", o campo status_reason explicará o conflito de modo de retenção.

    Confirmar que a SCP está funcionando

    Tente definir o modo como provider_data_share:

    aws bedrock put-account-data-retention \
  --region us-east-1 \
  --mode provider_data_share

    Se a SCP estiver funcionando, você receberá um erro de acesso negado:

    An error occurred (AccessDeniedException) when calling the PutAccountDataRetention operation: User: arn:aws:iam::123456789012:user/admin is not authorized to perform: bedrock:PutAccountDataRetention with an explicit deny in a service control policy

    Se a requisição for bem-sucedida, a SCP não está funcionando. Reverta imediatamente com --mode none e verifique: se a SCP está anexada à OU raiz (não a uma OU filha), a sintaxe da política e as condition keys, e lembre-se de que a conta de gerenciamento do AWS Organizations é isenta de SCPs — use uma política IAM para cobri-la.

    Gerenciando retenção no nível do projeto

    O gerenciamento de retenção por projeto é feito exclusivamente via API bedrock-mantle — não há comando AWS CLI para configurações no nível do projeto.

    # Definir um projeto como provider_data_share
curl -X POST https://bedrock-mantle.us-east-1.api.aws/v1/organization/projects/proj_abc123 \
  -H "x-api-key: $BEDROCK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "data_retention": { "mode": "provider_data_share" } }'

# Definir um projeto como none (retenção zero)
curl -X POST https://bedrock-mantle.us-east-1.api.aws/v1/organization/projects/proj_abc123 \
  -H "x-api-key: $BEDROCK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "data_retention": { "mode": "none" } }'

# Verificar a configuração atual de um projeto
curl -X POST https://bedrock-mantle.us-east-1.api.aws/v1/organization/projects/proj_abc123 \
  -H "x-api-key: $BEDROCK_API_KEY"

    Recursos adicionais

    Fonte

    Enforce zero data retention on Amazon Bedrock with Bedrock Projects and service control policies (https://aws.amazon.com/blogs/security/enforce-zero-data-retention-on-amazon-bedrock-with-bedrock-projects-and-service-control-policies/)

  • Amazon GameLift Streams ganha acesso seguro via terminal para sessões de stream

    Diagnóstico em tempo real sem complicação de infraestrutura

    A AWS anunciou uma novidade relevante para equipes que trabalham com o Amazon GameLift Streams: o serviço agora conta com o Stream Session Admin Shell, um recurso que oferece acesso seguro via terminal diretamente ao ambiente de execução de uma sessão de stream ativa.

    Na prática, isso significa que desenvolvedores e operadores podem se conectar ao ambiente em tempo real para fazer diagnósticos — sem precisar configurar chaves SSH (Secure Shell), abrir portas de rede ou lidar com credenciais de infraestrutura. Uma mão na roda para quem precisa investigar problemas em sessões ao vivo sem interromper o fluxo do usuário final.

    O que é possível fazer com o Admin Shell

    Uma vez conectado ao terminal da sessão, a equipe técnica pode realizar diversas ações de inspeção e diagnóstico, como:

    • Inspecionar logs da aplicação em tempo real
    • Consultar os processos em execução
    • Verificar a utilização da GPU (Unidade de Processamento Gráfico)
    • Examinar o estado atual da aplicação

    O nível de acesso concedido pelo terminal é equivalente ao que as próprias aplicações do Amazon GameLift Streams possuem — nem mais, nem menos. Isso garante um escopo controlado e seguro para as operações de diagnóstico.

    Como funciona na prática

    Para se conectar, o processo é direto: basta chamar a nova API CreateStreamSessionAdminShell informando os identificadores do grupo de stream e da sessão desejada. A API retorna as credenciais necessárias, que devem ser usadas em conjunto com o plugin SSM Session Manager da Interface de Linha de Comando (CLI) da AWS.

    O terminal é automaticamente encerrado quando a sessão de stream chega ao fim — sem necessidade de desconexão manual ou limpeza adicional.

    Compatibilidade e disponibilidade

    O Stream Session Admin Shell é compatível com os seguintes ambientes de execução:

    • Linux (Ubuntu 22.04)
    • Proton
    • Windows Server 2022

    O recurso está disponível sem custo adicional em todas as regiões da AWS onde o Amazon GameLift Streams já é oferecido. Para conferir a lista completa de regiões suportadas, a AWS disponibiliza a tabela de regiões da AWS.

    Documentação e próximos passos

    Para quem quiser se aprofundar ou já começar a usar o recurso, a AWS disponibilizou o guia do desenvolvedor do Stream Session Admin Shell e a referência da API CreateStreamSessionAdminShell com todos os detalhes técnicos necessários.

    Fonte

    Amazon GameLift Streams introduces secure terminal access for stream sessions (https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-gamelift-streams-terminal-access/)

  • AWS Security Hub agora monitora recursos do Microsoft Azure

    Gerenciamento de segurança unificado entre AWS e Azure

    A AWS anunciou uma expansão significativa do AWS Security Hub: o serviço agora é capaz de monitorar recursos do Microsoft Azure, unificando a gestão de segurança para equipes que operam workloads nos dois provedores de nuvem ao mesmo tempo.

    Até então, times de segurança que trabalhavam com AWS e Azure precisavam operar ferramentas separadas para cada ambiente — o que dificultava a priorização de riscos de forma integrada e tornava a resposta a incidentes mais fragmentada. Com essa atualização, o Security Hub passa a oferecer uma experiência unificada para detectar e responder a riscos nos dois ambientes a partir de um único console.

    O que o Security Hub monitora no Azure

    O serviço realiza a descoberta automática de recursos do Azure, avaliando-os em busca de más configurações, exposição à internet e vulnerabilidades de software. Os recursos cobertos incluem:

    • Azure Virtual Machines (VMs)
    • Azure Container Registry (ACR) — imagens de contêiner
    • Azure Function Apps
    • Identidades do Azure

    Além da descoberta, o Security Hub realiza verificações de postura contra padrões de segurança reconhecidos, incluindo o CIS Benchmarks™ para Microsoft Azure Foundations. O resultado é um inventário unificado de recursos, análise de risco e exposição, e resposta automatizada por meio das integrações já existentes com o Amazon EventBridge.

    Uma visão consolidada de riscos

    Findings da AWS e do Azure aparecem na mesma visualização priorizada, com os mesmos formatos e fluxos de automação. Isso significa que as equipes de segurança podem operar a partir de um único console, sem precisar alternar entre ferramentas diferentes para cada nuvem.

    Período de avaliação gratuita e preços

    O Security Hub oferece um período de avaliação gratuita independente de 30 dias para monitoramento de recursos do Azure, que se inicia assim que a integração com o Microsoft Azure é criada. Após o período de trial, o preço cobrado para monitorar recursos do Azure é o mesmo aplicado a recursos equivalentes na AWS.

    Disponibilidade e integrações independentes

    A integração com o Azure pode ser criada a partir de todas as regiões da AWS onde o Security Hub está disponível, com exceção de: Middle East (UAE), Middle East (Bahrain), Asia Pacific (Taipei) e Asia Pacific (New Zealand).

    Vale destacar que também é possível criar integrações com o Microsoft Azure de forma independente, tanto para o AWS Security Hub CSPM — Gerenciamento de Postura de Segurança em Nuvem (CSPM) — quanto para o Amazon Inspector, voltado ao gerenciamento de vulnerabilidades, sem necessidade de usar o Security Hub completo.

    Para conhecer os detalhes de cobrança e a documentação técnica completa, consulte a página de preços do AWS Security Hub e a documentação oficial do AWS Security Hub.

    Fonte

    AWS Security Hub extends unified security management to Microsoft Azure (https://aws.amazon.com/about-aws/whats-new/2026/06/aws-security-hub-supports-monitoring-microsoft-azure/)

  • Amazon S3 Vectors agora está disponível nas regiões AWS GovCloud (EUA)

    Expansão do S3 Vectors para ambientes governamentais

    A AWS anunciou que o Amazon S3 Vectors agora está disponível nas regiões AWS GovCloud (US-East) e AWS GovCloud (US-West). Essa expansão é relevante para organizações governamentais e parceiros que operam nessas regiões e precisam de armazenamento vetorial de alta escala para suas aplicações de inteligência artificial.

    O que é o Amazon S3 Vectors?

    O Amazon S3 Vectors é um serviço de armazenamento vetorial desenvolvido especificamente para cargas de trabalho de IA. Ele foi projetado para suportar casos de uso como:

    • Agentes de IA — aplicações autônomas que precisam consultar bases de conhecimento em tempo real
    • Inferência — execução de modelos de machine learning em produção
    • Geração Aumentada por Recuperação (RAG) — técnica que combina busca semântica com modelos de linguagem para gerar respostas mais precisas
    • Busca semântica — pesquisa baseada em significado, e não apenas em palavras-chave exatas

    O serviço foi construído para operar na escala de bilhões de vetores, o que o posiciona como uma solução robusta para aplicações de IA em larga escala.

    Sem necessidade de provisionar infraestrutura

    Um dos pontos centrais do Amazon S3 Vectors é a sua proposta de simplicidade operacional. O serviço oferece as mesmas características de elasticidade, durabilidade e disponibilidade já conhecidas do Amazon S3 tradicional — mas com um conjunto dedicado de APIs voltadas especificamente para operações vetoriais: armazenar, acessar e consultar vetores sem precisar provisionar ou gerenciar infraestrutura.

    Isso significa que equipes de engenharia podem focar no desenvolvimento das aplicações de IA sem se preocupar com a camada de infraestrutura subjacente ao armazenamento vetorial.

    Saiba mais e explore os recursos

    Para conferir a lista completa de regiões onde o Amazon S3 Vectors está disponível, consulte a página de regiões e endpoints da AWS. Para aprofundar o conhecimento sobre o serviço, a AWS disponibiliza a página do produto, a documentação oficial e a página de preços do Amazon S3.

    Fonte

    Amazon S3 Vectors is now available in AWS GovCloud (US) Regions (https://aws.amazon.com/about-aws/whats-new/2026/07/s3-vectors-available-aws-govcloud-regions/)

  • Como redatar automaticamente Informações Pessoais Identificáveis (PII) em imagens com o Amazon Nova

    O desafio de proteger dados pessoais em imagens

    Compartilhar dados entre times internos, parceiros externos ou usá-los para treinar modelos de Aprendizado de Máquina (ML) é uma prática comum no dia a dia das empresas. O problema surge quando esses dados contêm Informações Pessoais Identificáveis (PII) — e as obrigações legais sob regulações como o Regulamento Geral de Proteção de Dados (GDPR) e o Padrão de Segurança de Dados da Indústria de Cartões de Pagamento (PCI DSS) entram em cena. Sem a redação adequada, o risco é real: penalidades regulatórias, danos à reputação e perda de confiança dos clientes.

    Redatar PII em imagens do mundo real é particularmente desafiador. Ao contrário de texto estruturado, informações sensíveis em imagens aparecem nos lugares mais inesperados: um rosto parcialmente visível na borda do quadro, um rosto refletido na lataria polida de um carro, uma placa de rua que — combinada com outros elementos visuais — permite identificar uma localização, ou um documento sobre uma mesa em uma foto panorâmica que revela nomes, endereços ou números de identificação. Esses casos-limite costumam derrotar ferramentas de mascaramento de propósito único.

    Foi pensando nesses cenários complexos que a AWS publicou uma arquitetura de referência usando o Amazon Nova como orquestrador inteligente de um pipeline completo de redação de PII em imagens.

    O papel do Amazon Nova como coordenador do pipeline

    O Amazon Nova é uma família de modelos de fundação com capacidades avançadas de compreensão visual. Diferente de ferramentas especializadas em uma única tarefa, o Nova interpreta o conteúdo da imagem de forma holística — raciocina sobre o que constitui PII em contexto, incluindo os casos sutis e incomuns descritos acima, e coordena todo o pipeline de redação do início ao fim.

    A solução apresentada pela AWS é um pipeline de múltiplas etapas dirigido pelo Amazon Nova, que usa seu raciocínio visual contextual para coordenar ferramentas complementares:

    • O Segment Anything Model (SAM 3), modelo open-source da Meta, implantado no Amazon SageMaker AI para segmentação em nível de pixel.
    • O Amazon Textract para Reconhecimento Óptico de Caracteres (OCR).

    O pipeline foi projetado para oferecer redação de PII abrangente e em conformidade regulatória, mesmo para casos desafiadores como impressões digitais, carteiras de identidade ou placas de veículos em orientações arbitrárias.

    Componentes principais da solução

    Amazon Nova 2 Lite

    O Amazon Nova 2 Lite é um modelo de fundação multimodal rápido e com boa relação custo-benefício, capaz de processar texto, imagens, vídeos e documentos. Disponível no Amazon Bedrock, ele atua como o coordenador central de toda a solução — tomando decisões em cada etapa e direcionando os serviços especializados para alcançar resultados abrangentes.

    Segment Anything Model (SAM 3)

    O SAM 3 é um modelo de segmentação open-source que detecta, segmenta e rastreia objetos em imagens a partir de prompts textuais e visuais. Nessa solução, ele age como um instrumento de precisão dirigido pelo Nova: quando o Nova identifica elementos visuais de PII, delega ao SAM 3 a tarefa de produzir os contornos exatos para a redação.

    Imagem original — fonte: Aws

    Amazon Textract

    O Amazon Textract é um serviço de ML que extrai automaticamente texto, escrita manual, elementos de layout e dados de formatos como PDFs, imagens, tabelas e formulários. No pipeline, ele funciona como a capacidade de OCR do Nova: quando o Nova determina que uma imagem contém PII textual, direciona o Textract para extrair todo o conteúdo textual junto com suas coordenadas.

    Quais tipos de PII o pipeline detecta?

    Os itens de PII mais comuns encontrados em imagens incluem, mas não se limitam a:

    • Nome
    • Número de identificação (como número de carteira de motorista)
    • Endereço
    • Número de telefone
    • Informações de ativos (como endereço de Controle de Acesso à Mídia — MAC)
    • Número de identificação de propriedade (como Número de Identificação do Veículo — VIN)
    • Características pessoais, como imagens faciais
    • Dados biométricos, como impressões digitais

    Esses itens se dividem em duas modalidades: textual (nome, número de identificação, endereço, telefone, informações de ativos e número de propriedade) e visual (características pessoais e dados biométricos). O Nova coordena um fluxo de trabalho com acesso a dois subprocessos, cada um identificando as coordenadas de pixel dos itens de PII de cada modalidade.

    Arquitetura da solução

    O pipeline funciona de forma serverless e automatizada, com o Nova dirigindo cada decisão do fluxo. Veja como cada etapa se encaixa:

    Imagem original — fonte: Aws

    1. Upload e disparo do fluxo

    Quando uma imagem é carregada na pasta input/ do Amazon S3, uma notificação de evento aciona uma regra no Amazon EventBridge, que inicia o fluxo de trabalho no AWS Step Functions.

    2. Validação e triagem inicial de PII

    O fluxo valida primeiro se o tipo de arquivo é compatível com os formatos suportados pelo Amazon Bedrock. Em seguida, o Nova 2 Lite realiza uma avaliação inicial da imagem, atuando como primeira linha de inteligência para determinar se há PII presente. Se o Nova concluir que não há PII, o fluxo encerra antecipadamente e a imagem é movida para a pasta noPII/ do S3, pronta para uso sem processamento adicional.

    Essa saída antecipada é um diferencial importante de custo: a maioria das imagens corporativas não contém PII, e o Nova evita chamadas desnecessárias ao Textract e ao SAM 3 para esses casos.

    3. Detecção visual de PII

    Quando o Nova 2 Lite identifica PII em potencial, ele classifica o tipo detectado — textual, visual ou ambos — e decide o roteamento para os subprocessos. O processo visual foca em elementos como rostos e placas de veículos. Sob a direção do Nova, o SAM 3, implantado no SageMaker AI, é acionado para localizar esses elementos e produzir máscaras de segmentação pixel a pixel.

    Uma máscara de segmentação é um contorno em nível de pixel que traça o formato exato de um objeto na imagem — diferente de uma caixa delimitadora retangular, ela segue os contornos reais do item detectado. Isso permite redatar apenas os pixels sensíveis sem obscurecer o conteúdo ao redor, preservando o valor da imagem para usos como treinamento de modelos de ML.

    4. Detecção textual de PII

    O processo textual usa o raciocínio multimodal do Nova em conjunto com o Amazon Textract. Primeiro, o Textract identifica a localização em nível de pixel do texto na imagem e extrai seu conteúdo, fornecendo coordenadas de caixa delimitadora alinhada ao eixo e coordenadas de polígono para cada elemento de texto detectado. O Nova 2 Lite então avalia cada elemento extraído, junto com a imagem bruta, para determinar quais contêm PII.

    É aqui que a inteligência contextual do Nova se torna crítica: alguns elementos de texto, considerados isoladamente, podem não parecer PII, mas o Nova consegue raciocinar sobre o contexto visual ao redor para reconhecer sua natureza sensível. Por exemplo, o nome de uma rua e um número de residência em dois locais distintos da imagem não constituem PII separadamente — mas como ambos aparecem na mesma imagem, o endereço completo fica visível e deve ser redatado.

    5. Redação e verificação final

    Após a conclusão dos subprocessos, as coordenadas identificadas são passadas para a etapa de redação. Uma função AWS Lambda mescla as coordenadas retornadas pelos processos em um conjunto unificado de localizações de PII. A função Lambda RedactPII então obscurece as regiões identificadas na imagem original usando a biblioteca Pillow (PIL) em Python e armazena a imagem redatada na pasta redacted/ do S3.

    Como etapa final de garantia de qualidade, o Nova 2 Lite realiza uma revisão abrangente da imagem redatada para verificar se todo o PII detectado foi removido. Se o Nova determinar que a imagem está limpa, ela é movida para a pasta noPII/. Se ainda detectar PII, a imagem é movida para uma pasta de quarentena para revisão manual.

    Imagem original — fonte: Aws
    Imagem original — fonte: Aws

    Pré-requisitos para implementar a solução

    Para seguir com essa solução, a AWS recomenda que você tenha:

    É importante estar ciente de que a solução gera cobranças na AWS, incluindo armazenamento no S3, invocações do Lambda, transições de estado no Step Functions, hospedagem de endpoint no SageMaker AI, chamadas de API no Amazon Bedrock e chamadas de API no Amazon Textract. Verifique os preços desses serviços na sua região AWS antes de criar os recursos correspondentes.

    Por que essa abordagem se destaca?

    A solução é ideal para cenários de pré-processamento de imagens individuais ou em lote onde alta precisão de redação é necessária. A forte relação custo-benefício, a baixa latência e o raciocínio multimodal avançado do Nova 2 Lite tornam essa arquitetura adequada para coordenar o fluxo de trabalho sem que a organização precise de expertise profunda em ML ou de ajuste fino de modelos especializados.

    Para começar, a AWS recomenda explorar os modelos Amazon Nova no console do Amazon Bedrock e consultar a documentação do Amazon Nova, a documentação do Amazon Textract e a documentação do Amazon SageMaker AI para implantar os serviços complementares usados no pipeline.

    Fonte

    Automatically redact PII in images with Amazon Nova (https://aws.amazon.com/blogs/machine-learning/automatically-redact-pii-in-images-with-amazon-nova/)

  • AWS Certificate Manager passa a suportar o protocolo ACME para certificados públicos

    O que mudou no ACM

    A AWS anunciou que o Gerenciador de Certificados da AWS (ACM — AWS Certificate Manager) agora oferece suporte ao protocolo ACME (Ambiente de Gerenciamento de Certificados Automatizado). Com essa novidade, é possível provisionar um endpoint de servidor ACME totalmente gerenciado, que emite certificados TLS públicos com validade de 45 dias diretamente pela Amazon Trust Services.

    A integração funciona com qualquer cliente compatível com ACMEv2, incluindo ferramentas amplamente utilizadas no mercado como Certbot, cert-manager para Kubernetes e acme.sh.

    Por que isso importa agora

    O Fórum CA/Browser — entidade que define padrões para emissão de certificados digitais — determinou que o tempo de vida máximo de certificados públicos será de 47 dias a partir de 2029. Na prática, isso torna o gerenciamento manual de certificados completamente inviável: renovações frequentes feitas à mão geram risco operacional, erros humanos e indisponibilidades.

    O suporte ao ACME no ACM oferece aos times de desenvolvimento um caminho padronizado para automatizar completamente a emissão e a renovação de certificados, sem depender de processos manuais.

    Controles de governança para administradores de PKI

    Para quem cuida da infraestrutura de chaves públicas (PKI — Public Key Infrastructure), a AWS disponibilizou controles centralizados de governança nos endpoints ACME gerenciados. Entre as capacidades disponíveis estão:

    • Definição de escopos de domínio, restringindo quais certificados cada cliente pode emitir
    • Aplicação de políticas sobre o uso de certificados wildcard
    • Delegação de requisições de certificados para times de aplicação sem a necessidade de distribuir credenciais de DNS

    A validação de domínio é realizada uma única vez no nível do endpoint. A partir daí, os responsáveis pelas aplicações utilizam clientes ACME padrão para solicitar seus certificados normalmente.

    Visibilidade e auditoria

    Toda a atividade gerada pelos endpoints ACME fica visível no console do ACM, com registro completo via AWS CloudTrail e métricas disponíveis no Amazon CloudWatch, garantindo rastreabilidade e conformidade.

    Disponibilidade e próximos passos

    O suporte ao ACME no ACM já está disponível em todas as regiões comerciais da AWS. Para detalhes sobre preços, consulte a página de preços do ACM. Para começar a usar, a AWS recomenda visitar o post no blog AWS News ou acessar diretamente a documentação oficial.

    Fonte

    AWS Certificate Manager now supports the ACME protocol for public certificates (https://aws.amazon.com/about-aws/whats-new/2026/07/aws-certificate-manager-acme/)

  • Amazon Cognito agora suporta limites de taxa de API provisionados por autoatendimento

    O que mudou no Amazon Cognito

    A AWS anunciou uma novidade relevante para quem trabalha com autenticação e gerenciamento de usuários: o Amazon Cognito agora permite ajustar os limites de taxa (rate limits) das suas APIs de forma autônoma, sem precisar abrir um chamado manual para revisão.

    Como funcionava antes

    Até então, quando uma equipe precisava aumentar os limites de operações por segundo nos seus user pools do Cognito — seja por conta de um lançamento, uma campanha ou um pico de tráfego esperado — o caminho era solicitar o aumento via Service Quotas, onde cada pedido passava por revisão manual da AWS. Isso exigia planejamento antecipado e tornava o processo lento e pouco flexível para cenários dinâmicos.

    O que mudou com o novo modelo

    Com o novo modelo de autoatendimento, os times podem aumentar ou diminuir os limites de taxa de API do Cognito sob demanda, de forma imediata. As alterações entram em vigor assim que são aplicadas, o que representa um ganho significativo de agilidade operacional.

    O Cognito já possui limites padrão para o número máximo de operações por segundo que podem ser executadas nos user pools em cada região da AWS. Com esse novo recurso, é possível adquirir e ajustar limites adicionais nas categorias de API ajustáveis, tanto para cima quanto para baixo, respeitando o limite máximo definido para a conta.

    Como acessar o novo recurso

    O ajuste pode ser feito de duas formas:

    • Pelo console do Amazon Cognito, de forma visual e direta
    • Pelas novas operações da API de provisionamento de limites, para quem prefere automação e integração via código

    Disponibilidade e precificação

    Os limites provisionados por autoatendimento estão disponíveis para as categorias de API ajustáveis em todas as regiões da AWS onde o Amazon Cognito está presente. Por se tratar de um recurso adicional (add-on), há cobrança específica — os detalhes de preço podem ser consultados na página de preços do Amazon Cognito.

    Para começar a utilizar o recurso e entender como configurar os limites na prática, a AWS disponibiliza o guia do desenvolvedor com as instruções completas.

    Fonte

    Amazon Cognito now supports self-service provisioned API rate limits (https://aws.amazon.com/about-aws/whats-new/2026/07/cognito-provisioned-limits)

  • Como aplicar autorização de menor privilégio em cadeias de agentes de IA com Cedar

    O problema: escopo de autorização que se expande silenciosamente

    Quem está construindo sistemas de IA com múltiplos agentes precisa lidar com um risco pouco discutido: à medida que agentes delegam tarefas entre si em cadeia, o escopo de autorização pode se expandir silenciosamente — mesmo quando há políticas de controle de acesso baseado em papel (RBAC) em vigor. Um agente pode acabar agindo além do que o usuário humano que iniciou a cadeia realmente autorizou.

    O OWASP Top 10 para Aplicações Agênticas classifica esse risco como ASI03: Abuso de Identidade e Privilégio. Para endereçar esse problema de forma prática, a AWS publicou uma implementação de referência que usa um modelo de três camadas de políticas construído com Cedar, linguagem open source de políticas de autorização, implantado na AWS.

    Visão geral da implementação de referência

    A implementação usa OAuth 2.0 para autenticação e Cedar para autorização. Um provedor de identidade confiável autentica o usuário originador, e as políticas Cedar aplicam a autorização em três camadas usando as claims verificadas do token.

    Para aplicar a autorização em cada salto da cadeia de delegação, a solução utiliza duas funções AWS Lambda em sequência:

    • Uma função adaptadora do Protocolo de Contexto de Modelo (MCP) normaliza as requisições de entrada e assina criptograficamente o contexto do usuário originador, impedindo adulterações downstream.
    • Uma função avaliadora Cedar executa as três camadas de política de forma sequencial, parando na primeira negação.

    As três camadas do modelo de avaliação Cedar são:

    • Camada 1 (Agente → Ferramenta): verifica se o agente invocador tem pontuação de confiança suficiente (escala de 1 a 5), pertence ao namespace correto e está no estágio de ciclo de vida de produção.
    • Camada 2 (Agente → Agente): verifica se o número de saltos de delegação está dentro do limite máximo de cinco e se as tarefas solicitadas são um subconjunto das capacidades registradas do agente de destino.
    • Camada 3 (Autorização do usuário originador): verifica se o humano que iniciou a cadeia tem o papel exigido (por exemplo, admin), completou autenticação multifator (MFA) e está dentro da profundidade de delegação permitida.

    Arquitetura: autenticação antes da autorização

    O Cedar avalia a autorização, mas não estabelece identidade. Antes que as políticas possam verificar atributos como context.originating_user.role ou context.originating_user.mfa_verified, uma camada de autenticação confiável precisa estabelecer a identidade do usuário e produzir claims verificáveis.

    Imagem original — fonte: Aws

    O fluxo de autenticação (passos 1 a 3) funciona da seguinte forma: o usuário originador se autentica em um provedor de identidade compatível com OIDC — na implementação de referência, o Amazon Cognito com MFA via TOTP. O provedor emite um Token Web JSON (JWT) assinado contendo claims como sub, role, amr e session_id. O usuário passa o JWT e a requisição de tarefa ao agente de IA (cliente MCP), que carrega o contexto do usuário originador no envelope _meta do MCP.

    O pipeline de autorização (passos 4 a 10) segue esta sequência:

    Integridade do contexto ao longo dos saltos de delegação

    Dois mecanismos trabalham juntos para proteger a identidade ao longo dos saltos:

    • HMAC-SHA256 garante integridade e autenticidade. Todo avaliador downstream verifica essa assinatura antes de confiar no contexto.
    • OAuth 2.0 Token Exchange (RFC 8693) define o escopo de delegação usando o padrão on-behalf-of (OBO). Quando o orquestrador delega a um agente downstream, ele troca o token original por um token OBO com escopo reduzido, registrando quem está agindo em nome de quem e com qual autoridade.

    O OAuth rastreia quem age em nome de quem e com qual escopo. O HMAC verifica que o contexto não foi adulterado e veio de uma fonte confiável. Para implantações corporativas, a recomendação é usar os dois mecanismos em conjunto.

    Definindo o esquema Cedar e as políticas

    O esquema define dois tipos de entidade (Agent e Tool) e duas ações (invoke_tool e delegate_task) no namespace AgentAuthz. Importante: não existe entidade User. A identidade do usuário originador é carregada no registro de contexto passado junto a cada requisição de autorização.

    {
  "AgentAuthz": {
    "entityTypes": {
      "Agent": {
        "shape": {
          "type": "Record",
          "attributes": {
            "trust_level": { "type": "Long", "required": true },
            "namespace": { "type": "String", "required": true },
            "registered_capabilities": {
              "type": "Set",
              "element": { "type": "String" },
              "required": true
            },
            "lifecycle_stage": { "type": "String", "required": true }
          }
        }
      },
      "Tool": {
        "shape": {
          "type": "Record",
          "attributes": {
            "namespace": { "type": "String", "required": true },
            "risk_level": { "type": "String", "required": true }
          }
        }
      }
    },
    "actions": {
      "invoke_tool": {
        "appliesTo": {
          "principalTypes": ["Agent"],
          "resourceTypes": ["Tool"]
        }
      },
      "delegate_task": {
        "appliesTo": {
          "principalTypes": ["Agent"],
          "resourceTypes": ["Agent"]
        }
      }
    }
  }
}

    Topologia de agentes e ferramentas

    A implementação de referência registra três agentes: orchestrator (nível de confiança 5, namespace orchestration, capacidades: delegate_task e route_request), finance-agent (nível 3, namespace payments, capacidades: process_payment e refund) e data-bot (nível 4, namespace data, capacidades: query_records e delete_records). As ferramentas registradas são process_payment (risco médio), delete_records (risco alto) e query_records (risco baixo).

    Políticas das três camadas

    Camada 1 (agente → ferramenta): permite que o finance-agent invoque a ferramenta process_payment apenas quando o nível de confiança for pelo menos 3, o namespace for payments e o estágio de ciclo de vida for production.

    // L1-001: Finance agent can invoke payment tools
permit(
  principal == AgentAuthz::Agent::"finance-agent",
  action == AgentAuthz::Action::"invoke_tool",
  resource == AgentAuthz::Tool::"process_payment"
)
when {
  principal.trust_level >= 3 &&
  principal.namespace == "payments" &&
  principal.lifecycle_stage == "production"
};

    Camada 2 (agente → agente): o orquestrador delega tarefas ao data-bot apenas quando a cadeia tem no máximo três saltos e as capacidades solicitadas são subconjunto das capacidades registradas do data-bot. Uma política forbid separada (L2-004) impõe um limite absoluto de cinco saltos para todo o sistema.

    // L2-002: Orchestrator can delegate to data agent
permit(
  principal == AgentAuthz::Agent::"orchestrator",
  action == AgentAuthz::Action::"delegate_task",
  resource == AgentAuthz::Agent::"data-bot"
)
when {
  context.delegation_depth <= 3 &&
  context.target_capabilities.containsAll(context.requested_capabilities)
};

    Camada 3 (autorização do usuário originador): o data-bot invoca a ferramenta delete_records apenas quando o usuário originador tem papel admin, MFA verificado e a cadeia tem no máximo dois saltos. Sem essa camada, um agente com as capacidades certas poderia invocar ferramentas destrutivas independentemente de quem iniciou a requisição.

    // L3-001: High-risk tool (delete_records) requires admin + MFA
permit(
  principal == AgentAuthz::Agent::"data-bot",
  action == AgentAuthz::Action::"invoke_tool",
  resource == AgentAuthz::Tool::"delete_records"
)
when {
  context.originating_user.role == "admin" &&
  context.originating_user.mfa_verified == true &&
  context.delegation_depth <= 2
};

    Implantação com AWS CDK

    Antes de começar, clone o repositório:

    git clone https://github.com/aws-samples/sample-cedar-agentic-ai-authorization.git
cd sample-cedar-agentic-ai-authorization

    Os pré-requisitos são: conta AWS com o AWS Cloud Development Kit (AWS CDK) inicializado na região alvo, Python 3.12 ou superior, Node.js 20 ou superior, CLI do AWS CDK (npm install -g aws-cdk) e credenciais AWS com permissões de AWS Identity and Access Management (IAM) com escopo para Lambda, API Gateway, Verified Permissions, Secrets Manager, Amazon Virtual Private Cloud (Amazon VPC) e CloudWatch.

    A implementação implanta cinco stacks do CloudFormation: KmsStack, VerifiedPermissionsStack, LambdaStack, SecurityLakeStack e MonitoringStack. Os comandos de implantação seguem a ordem de dependência:

    cdk deploy KmsStack -c account_id=YOUR_ACCOUNT_ID -c guardrail_id=YOUR_GUARDRAIL_ID
cdk deploy VerifiedPermissionsStack -c account_id=YOUR_ACCOUNT_ID -c guardrail_id=YOUR_GUARDRAIL_ID
cdk deploy LambdaStack -c account_id=YOUR_ACCOUNT_ID -c guardrail_id=YOUR_GUARDRAIL_ID
cdk deploy SecurityLakeStack -c account_id=YOUR_ACCOUNT_ID -c guardrail_id=YOUR_GUARDRAIL_ID
cdk deploy MonitoringStack -c account_id=YOUR_ACCOUNT_ID -c guardrail_id=YOUR_GUARDRAIL_ID

    Cenários de teste

    Três cenários de ponta a ponta validam o modelo de avaliação:

    • Cenário A — Aplicação da Camada 3: um usuário com papel support (sem MFA) solicita exclusão de registros via orchestrator e data-bot. L1 e L2 permitem, mas L3 nega porque o papel é support e o MFA não está verificado. Resultado geral: NEGADO.
    • Cenário B — Requisição admin autorizada: um usuário admin com MFA solicita a mesma operação. As três camadas permitem. Resultado geral: PERMITIDO.
    • Cenário C — Limite de profundidade de delegação: um admin com MFA solicita a mesma operação, mas a cadeia tem seis saltos. L1 permite, L2 nega (seis saltos excedem o limite de cinco). L3 nem é avaliada. Resultado geral: NEGADO.

    Alinhamento com os princípios de segurança para IA agêntica

    O Escritório do CISO da AWS publicou os quatro princípios de segurança para sistemas de IA agêntica. A solução mapeia diretamente para cada um deles: testes baseados em propriedades com Hypothesis para fuzzing de entradas adversariais; controles tradicionais como AWS WAF, isolamento via Amazon VPC, criptografia com AWS Key Management Service (AWS KMS) e MFA; avaliação Cedar determinística rodando fora do loop de raciocínio do agente em uma função Lambda separada; e atributos trust_level e lifecycle_stage que calibram as capacidades dos agentes com base em evidências de auditoria do Amazon CloudWatch.

    Escalando para ambientes multi-conta

    Para implantações corporativas, a recomendação é implantar o policy store Cedar em uma conta de segurança centralizada e usar funções IAM cross-account para que as contas de carga de trabalho chamem verifiedpermissions:IsAuthorized. As políticas de controle de serviço (SCPs) do AWS Organizations podem impedir que contas de carga de trabalho criem seus próprios policy stores.

    Para implantações em produção, a implementação pode ser estendida com escalação com humano no loop para negações borderline, isolamento de políticas Cedar multi-tenant e recarga dinâmica de políticas via Amazon Simple Storage Service (Amazon S3) para desligamentos de emergência de ferramentas.

    Limpeza dos recursos

    cdk destroy MonitoringStack SecurityLakeStack
cdk destroy LambdaStack
cdk destroy VerifiedPermissionsStack
cdk destroy KmsStack
aws logs delete-log-group --log-group-name /cedar-evaluator/audit # if RETAIN policy

    Conclusão

    Sistemas de IA multi-agente precisam de fronteiras de autorização em cada salto de delegação. O modelo de três camadas Cedar com autenticação OAuth 2.0 fornece essa proteção mantendo o acesso de menor privilégio. A combinação de um provedor de identidade confiável (autenticação) com avaliação de políticas Cedar (autorização) cria uma fronteira de autorização em torno de cada invocação de ferramenta, verificando a capacidade do agente (L1), o caminho de delegação (L2) e a autoridade do usuário originador (L3). O padrão funciona com qualquer provedor de identidade compatível com OIDC e uma plataforma de computação capaz de chamar o Amazon Verified Permissions. A implementação de referência está disponível para clonagem e adaptação às necessidades de cada organização. Para mais detalhes, consulte a documentação da linguagem de políticas Cedar e o Guia do Usuário do Amazon Verified Permissions.

    Fonte

    Enforce least-privilege authorization in multi-agent AI chains using Cedar (https://aws.amazon.com/blogs/security/enforce-least-privilege-authorization-in-multi-agent-ai-chains-using-cedar/)