Blog

O que muda com o MLflow 3.10 no SageMaker

A AWS anunciou que os Amazon SageMaker AI MLflow Apps passam a suportar o MLflow na versão 3.10. A atualização expande as capacidades de desenvolvimento de IA generativa e torna o rastreamento de experimentos mais completo e integrado ao ciclo de produção.

A nova versão se apoia nas bases estabelecidas pelo MLflow 3.0 — especialmente nas funcionalidades de rastreamento e observabilidade — e avança com foco em fluxos de trabalho agênticos e aplicações de IA generativa.

Novidades do MLflow 3.10

IA generativa e rastreamento de fluxos complexos

Um dos destaques desta versão é o rastreamento aprimorado para fluxos de trabalho com múltiplas interações (multi-turn workflows), algo comum em aplicações que utilizam agentes de linguagem. A integração com frameworks e bibliotecas populares de Modelos de Linguagem de Grande Escala (LLM) também foi aprimorada, assim como o registro de interações e invocações de modelos generativos.

Nova API de avaliação para IA generativa

A avaliação de modelos recebeu uma atualização significativa com a chegada da API mlflow.genai.evaluation(). Ela oferece uma interface programática para medir e acompanhar sistematicamente a qualidade de aplicações de IA generativa ao longo de todo o ciclo de desenvolvimento até a produção. A API inclui métricas integradas que cobrem relevância, fidelidade, correção e segurança — todas compatíveis com os fluxos de trabalho do SageMaker AI.

Observabilidade e dashboards

As melhorias de observabilidade incluem filtragem e busca de rastreamentos com maior granularidade, além de captura mais rica de metadados para depuração e análise de causa raiz. Os dashboards de desempenho pré-configurados exibem métricas de carga de trabalho — distribuições de latência, contagem de requisições, pontuações de qualidade e uso de tokens — sem necessidade de configuração manual de gráficos. Isso dá às equipes em produção uma visão clara dos custos operacionais.

Além disso, os workspaces do MLflow oferecem uma forma estruturada de organizar artefatos entre times e projetos, facilitando a governança em escala.

Como começar com o SageMaker AI MLflow App v3.10

Para novos usuários, criar um SageMaker AI MLflow App é direto: basta acessar o console do SageMaker Studio, o Interface de Linha de Comando da AWS (AWS CLI) ou a API. A configuração padrão já provisiona automaticamente o MLflow 3.10, dando acesso imediato a todos os novos recursos.

Pré-requisitos

Para começar, são necessários:

• Uma conta AWS com faturamento habilitado
• Um domínio do Amazon SageMaker Studio AI. Para criar um domínio, consulte o guia de configuração do Amazon SageMaker AI

Com o domínio em mãos, basta acessar o console do Amazon SageMaker AI Studio, selecionar a aplicação MLflow e clicar em Create MLflow App, informando um nome para a aplicação. O papel do Gerenciamento de Identidade e Acesso da AWS (IAM) e o bucket do Amazon Simple Storage Service (Amazon S3) já vêm pré-configurados com os padrões do domínio do SageMaker AI Studio, sendo necessário ajustá-los apenas em configurações avançadas, se necessário.

Após a criação, o sistema fornece um Nome de Recurso da Amazon (ARN) do MLflow App, que será usado para conectar o ambiente de desenvolvimento ao rastreador.

Instalação dos pacotes

Para começar a rastrear experimentos, é necessário instalar o MLflow e o plugin SageMaker MLflow no ambiente de trabalho. Os ambientes suportados incluem o SageMaker Studio managed Jupyter Lab, o SageMaker Studio Code Editor, um ambiente de desenvolvimento integrado (IDE) local ou qualquer outro ambiente compatível com os SageMaker AI MLflow Apps.

A instalação via pip é feita com o seguinte comando:

pip install mlflow==3.10.1 sagemaker-mlflow==0.3.0

Conectando ao SageMaker AI MLflow App

Para conectar o código ao app recém-criado e começar a registrar experimentos, parâmetros e modelos, basta substituir o Nome de Recurso da Amazon (ARN) pelo ARN do seu MLflow App no trecho abaixo:

import mlflow

# Connect to your SageMaker MLflow App
mlflow_app_arn = "<your-mlflow-app-arn>"
mlflow.set_tracking_uri(mlflow_app_arn)

# Set your experiment
mlflow.set_experiment("your_genai_experiment")

# Your existing code continues to work with enhanced capabilities
# New features are automatically available

Migração de ambientes existentes

Quem já possui um MLflow Tracking Server ou App hospedado no SageMaker ou em outro ambiente pode migrar para um novo app na versão 3.10 seguindo as instruções do post Migrate MLflow tracking servers to Amazon SageMaker AI with serverless MLflow.

Disponibilidade e próximos passos

O MLflow v3.10 também está disponível no Amazon SageMaker AI serverless model customization e no SageMaker Unified Studio, ampliando as opções de uso em diferentes fluxos de trabalho.

Para começar, basta acessar o Amazon SageMaker AI Studio e criar o primeiro MLflow App. Feedbacks podem ser enviados pelo AWS re:Post para SageMaker ou pelos canais habituais de suporte AWS.

Fonte

Streamlining generative AI development with MLflow v3.10 on Amazon SageMaker AI (https://aws.amazon.com/blogs/machine-learning/streamlining-generative-ai-development-with-mlflow-v3-10-on-amazon-sagemaker-ai/)

O problema: a fronteira invisível da automação web

Agentes de IA que automatizam fluxos de trabalho em navegadores operam dentro da camada web — o Modelo de Objeto de Documento (DOM) exposto pelo Playwright e pelo Protocolo Chrome DevTools (CDP). O AgentCore Browser já fornecia um ambiente de navegador seguro e isolado para isso, funcionando bem na grande maioria dos cenários: navegar páginas, preencher formulários, clicar em elementos e extrair conteúdo.

Mas essa camada web tem um limite rígido. Qualquer coisa que o sistema operacional renderiza — caixas de diálogo nativas, prompts de segurança, seletores de certificado, menus de contexto, até as configurações do próprio Chrome — fica completamente fora do DOM. O CDP não consegue enxergar esses elementos, e o Playwright não consegue interagir com eles.

Os exemplos práticos deixam o problema bem claro:

• Quando uma aplicação web chama window.print() e um diálogo de impressão do sistema aparece, o Playwright não tem DOM para interagir.
• Quando um fluxo de trabalho exige um atalho de teclado ou um menu de contexto acionado com o botão direito, o CDP não tem mecanismo para emitir esses comandos no nível do SO.
• Quando uma sessão encontra um diálogo de privacidade do macOS, um prompt do Windows Security ou um seletor de certificado, esses elementos são invisíveis para a camada de automação web.

Esses cenários costumam aparecer em produção — acionados por estados específicos da aplicação, configurações do SO ou permissões de usuário — e não em ambientes de teste, onde o conteúdo web é previsível o suficiente para ser validado. O problema se agrava ainda mais para agentes com visão computacional: a arquitetura captura um screenshot, envia para um modelo, recebe coordenadas ou instruções de volta e executa. Esse ciclo funciona bem para conteúdo web, mas quebra no momento em que uma interface nativa aparece. O agente consegue ver o que precisa fazer, mas não tem como agir.

A solução: OS Level Actions para o AgentCore Browser

A AWS anunciou as OS Level Actions para o AgentCore Browser. Essa nova capacidade desbloqueia esses cenários ao expor controle direto do SO por meio da API InvokeBrowser, permitindo que agentes interajam com qualquer conteúdo visível na tela — não apenas o que está acessível pela camada web do navegador.

Ao combinar screenshots do desktop completo com controle de mouse e teclado no nível do SO, os agentes passam a conseguir observar interfaces nativas, raciocinar sobre elas e agir dentro da mesma sessão.

Como as OS Level Actions funcionam

As OS Level Actions estão disponíveis para configurações de navegador novas e existentes, sem necessidade de configuração adicional. Após uma sessão estar ativa, as ações são disparadas pela API InvokeBrowser. Cada chamada carrega exatamente uma ação, identificada pelo seu tipo e argumentos, e retorna um status SUCCESS ou FAILED. A sessão ativa é identificada pelo cabeçalho x-amzn-browser-session-id, que vincula cada ação em nível de SO à sessão de navegador correta.

O padrão de interação esperado é um ciclo de ação → screenshot → reação:

• O agente envia uma ação — clique de mouse, tecla pressionada ou atalho — usando o InvokeBrowser.
• O AgentCore executa a ação no desktop completo do SO e retorna SUCCESS ou FAILED.
• O agente solicita um screenshot para observar o estado atual da tela.
• O AgentCore captura o desktop completo — incluindo caixas de diálogo nativas, modais do SO e elementos fora da janela do navegador — e retorna uma imagem PNG codificada em base64.
• O agente raciocina sobre o screenshot, enviando-o a um modelo de visão para determinar o que aconteceu e o que fazer a seguir.
• O agente envia a próxima ação com base no que observou, continuando o ciclo.

Ações suportadas

As OS Level Actions são organizadas em três categorias: controle de mouse, entrada de teclado e captura visual. Ao todo, são oito ações com seus respectivos campos e restrições.

Ações de mouse

As ações de mouse cobrem toda a gama de interações com o ponteiro: clicar, mover, arrastar e rolar.

• mouseClick: os campos de coordenadas são opcionais. Se omitidos, o clique ocorre na posição atual do cursor, com botão esquerdo e clique único. O parâmetro clickCount aceita valores de 1 a 10.
• mouseMove: move o cursor para as coordenadas especificadas.
• mouseDrag: exige as quatro coordenadas (início e fim). O botão padrão é o esquerdo.
• mouseScroll: aceita posição e valores delta para ambos os eixos. deltaY negativo rola para baixo; o intervalo aceito vai de -1000 a 1000.

Um menu de contexto acionado com o botão direito, por exemplo, é um único mouseClick com o botão definido como RIGHT nas coordenadas alvo. Vale observar que alguns itens de menu de contexto podem não funcionar como esperado por conta do ambiente virtualizado em que a sessão de navegador roda.

Ações de teclado

As três ações de teclado cobrem diferentes níveis de entrada:

• keyType: para digitar texto. Envia caracteres diretamente e aceita strings de até 10.000 caracteres.
• keyPress: para teclas individuais que precisam ser pressionadas repetidamente — como tab para avançar por campos de formulário ou escape para fechar um modal. O parâmetro presses aceita de 1 a 100, com padrão 1.
• keyShortcut: para combinações de teclas — passe um array com os nomes das teclas e o AgentCore as pressiona simultaneamente. Aceita até cinco teclas. Os nomes das teclas devem ser em minúsculas.

As teclas suportadas incluem caracteres únicos (a–z, 0–9) e teclas nomeadas como enter, tab, space, backspace, delete, escape, ctrl, alt e shift. Para selecionar todo o texto, por exemplo, usa-se keyShortcut com ["ctrl", "a"]:

{
  "action": {
    "keyShortcut": {
      "keys": ["ctrl", "a"]
    }
  }
}

Screenshot

A ação de screenshot captura o desktop completo do SO e retorna uma imagem PNG codificada em base64 na resposta. É a única ação que retorna dados — as demais retornam apenas um status (SUCCESS ou FAILED) e um campo de erro em caso de falha.

{
  "action": {
    "screenshot": {
      "format": "PNG"
    }
  }
}

Como começar: passo a passo prático

Os exemplos a seguir percorrem o ciclo ação → screenshot → reação, acompanhando o notebook de referência. Para o notebook completo com as oito ações demonstradas de ponta a ponta, vale começar por lá.

Configurar clientes e criar um navegador

São necessários dois clientes: um de plano de controle (bedrock-agentcore-control) para gerenciar recursos de navegador, e um de plano de dados (bedrock-agentcore) para disparar ações durante uma sessão.

import boto3
import time

browser_boto3 = boto3.client('bedrock-agentcore-control', region_name='us-west-2')
BROWSER_NAME = "browser_with_os_actions"

Antes de iniciar uma sessão, é necessário um perfil de execução do Gerenciamento de Identidade e Acesso da AWS (IAM) e um recurso de navegador. O perfil de execução requer as permissões bedrock-agentcore:InvokeBrowser, bedrock-agentcore:StartBrowserSession e bedrock-agentcore:StopBrowserSession. O notebook de referência inclui um helper que cria esse perfil automaticamente:

from helpers.utils import create_agentcore_execution_role, SAMPLE_ROLE_NAME

execution_role_arn = create_agentcore_execution_role(SAMPLE_ROLE_NAME)

Com o perfil criado, cria-se um navegador personalizado:

created_browser = browser_boto3.create_browser(
    name=BROWSER_NAME,
    executionRoleArn=execution_role_arn,
    networkConfiguration={
        'networkMode': 'PUBLIC'
    }
)
browser_id = created_browser['browserId']
print(f"Browser ID: {browser_id}")

Iniciar uma sessão de navegador

Com o recurso de navegador criado, inicia-se uma sessão. O viewPort define a resolução da tela — isso determina o espaço de coordenadas para ações de mouse e as dimensões dos screenshots capturados. O sessionTimeoutSeconds controla por quanto tempo a sessão permanece ativa antes de ser encerrada automaticamente.

from helpers.browser import get_credentials, invoke, start_session, stop_session

creds, default_region = get_credentials()
BEDROCK_AGENTCORE_DP_ENDPOINT = f"https://bedrock-agentcore.{default_region}.amazonaws.com/"

sid = start_session(BEDROCK_AGENTCORE_DP_ENDPOINT, browser_id, region=default_region, credentials=creds)

# Aguarda a inicialização da sessão — ajuste conforme necessário para seu ambiente
time.sleep(3)

Invocar uma ação em nível de SO

Com a sessão em execução, as ações em nível de SO são disparadas pelo helper invoke. Cada chamada recebe uma única ação — neste caso, um clique esquerdo nas coordenadas (600, 370) da tela:

r = invoke(
    BEDROCK_AGENTCORE_DP_ENDPOINT,
    sid,
    {"mouseClick": {"x": 600, "y": 370, "button": "LEFT"}},
    region=default_region,
    credentials=creds,
    browser_id=browser_id
)
print(f"Mouse click status: {r.status_code}, action: {r.json()['result']}")

A resposta indica se a ação foi bem-sucedida ou falhou. As coordenadas mapeiam para pixels da tela — se o viewport da sessão for 1920×1080, os valores válidos de x vão de 0 a 1919 e de y de 0 a 1079. Coordenadas fora das dimensões da tela retornam uma ValidationException.

Capturar um screenshot

Após cada ação, o agente precisa observar o que aconteceu. A ação de screenshot captura o desktop completo e retorna a imagem como PNG codificado em base64:

import base64
from IPython.display import Image, display

r = invoke(
    BEDROCK_AGENTCORE_DP_ENDPOINT,
    sid,
    {"screenshot": {"format": "PNG"}},
    region=default_region,
    credentials=creds,
    browser_id=browser_id
)
img_bytes = base64.b64decode(r.json()['result']['screenshot']['data'])
display(Image(img_bytes))

Essa é a etapa de observação no ciclo. O agente envia o screenshot para um modelo de visão, que raciocina sobre o que está na tela e retorna a próxima ação a ser tomada. O ciclo se repete até o fluxo de trabalho ser concluído.

Juntando tudo: descartando um diálogo de impressão

Aqui está o ciclo ação → screenshot → reação na prática. Suponha que o agente navegue até uma página que aciona window.print() e um diálogo de impressão nativo apareça. O agente não consegue interagir com ele via CDP, mas consegue com as OS Level Actions.

Primeiro, o agente captura um screenshot para ver o estado atual da tela:

r = invoke(
    BEDROCK_AGENTCORE_DP_ENDPOINT,
    sid,
    {"screenshot": {"format": "PNG"}},
    region=default_region,
    credentials=creds,
    browser_id=browser_id
)
# Envia o screenshot para um modelo de visão para identificar o diálogo e localizar o botão Cancelar.
# A integração com o modelo de visão depende da arquitetura do seu agente — veja a API
# InvokeModel do Bedrock para enviar imagens ao Claude ou outros modelos.
# O modelo retorna coordenadas, ex.: {"x": 410, "y": 535}

O modelo de visão identifica o diálogo de impressão e retorna as coordenadas do botão Cancelar. O agente o seleciona:

r = invoke(
    BEDROCK_AGENTCORE_DP_ENDPOINT,
    sid,
    {"mouseClick": {"x": 410, "y": 535, "button": "LEFT"}},
    region=default_region,
    credentials=creds,
    browser_id=browser_id
)
print(f"Click status: {r.status_code}, action: {r.json()['result']}")

O agente captura outro screenshot para confirmar que o diálogo foi fechado, e o fluxo de trabalho continua.

Encerrar a sessão e limpar recursos

Quando o fluxo de trabalho termina, encerra-se a sessão e limpam-se os recursos:

stop_session(BEDROCK_AGENTCORE_DP_ENDPOINT, sid, browser_id, region=default_region, credentials=creds)

Para deletar o recurso de navegador e o perfil IAM:

browser_boto3.delete_browser(browserId=browser_id)
print(f"Browser {browser_id} deleted")

from helpers.utils import delete_agentcore_execution_role, SAMPLE_ROLE_NAME
delete_agentcore_execution_role(SAMPLE_ROLE_NAME)

O notebook de referência percorre as oito ações suportadas com uma sessão de navegador ao vivo, incluindo arrastar com o mouse, rolar, entrada de teclado e combinações de atalhos.

Conclusão

Quando a AWS lançou o Amazon Bedrock AgentCore Browser, ele ofereceu aos agentes de IA um ambiente de navegador totalmente gerenciado e baseado em nuvem para interagir com sites — navegando páginas, extraindo conteúdo e automatizando fluxos de trabalho em escala por meio do Playwright e do CDP.

As OS Level Actions estendem essa capacidade além da camada web para elementos de interface visíveis na tela. Caixas de diálogo nativas, prompts de segurança, atalhos de teclado e elementos do próprio navegador deixam de ser bloqueadores. Os agentes agora conseguem observar, raciocinar e agir sobre o desktop completo do SO dentro da mesma sessão.

Combinadas com as capacidades existentes do AgentCore Browser — como entendimento visual e integração com frameworks como Playwright e Amazon Nova Act — as OS Level Actions fecham a última lacuna na cobertura de automação de navegadores.

Para começar a construir:

• Consulte o Amazon Bedrock AgentCore Developer Guide
• Experimente o notebook de referência para um passo a passo prático
• Para contexto mais amplo sobre automação de navegadores, veja a documentação do Amazon Bedrock AgentCore Browser

Fonte

Introducing OS Level Actions in Amazon Bedrock AgentCore Browser (https://aws.amazon.com/blogs/machine-learning/introducing-os-level-actions-in-amazon-bedrock-agentcore-browser/)

O problema: comunicação direta fora dos canais aprovados

Em plataformas de corretagem — marketplaces que conectam compradores e vendedores — existe um risco constante: as partes trocam informações de contato dentro do sistema de mensagens e passam a negociar diretamente, fora da plataforma. Isso representa perda de receita imediata, erosão do valor do serviço e danos duradouros às relações com parceiros.

O desafio é que mensagens legítimas precisam continuar existindo. Detalhes de entrega como “deixe ao lado da porta dos fundos” ou “entregue somente após as 16h” são informações válidas. O problema está quando telefones, nomes de empresas, endereços de e-mail ou endereços físicos são compartilhados — mesmo que de forma disfarçada.

A AWS publicou um artigo técnico detalhando como usar os Modelos Fundacionais Amazon Nova no Amazon Bedrock para identificar essas tentativas, tanto as óbvias quanto as sofisticadas, além de extrair análise de sentimento e pontos de melhoria do serviço.

Por que expressões regulares (regex) não são suficientes

A primeira solução que vem à mente para detectar padrões de texto é o uso de Expressões Regulares (regex). E de fato, regex funciona bem para padrões estruturados: números de telefone no formato XXX-XXX-XXXX, endereços de e-mail no formato nome@empresa.com. Para esses casos, um padrão como \d{3}-\d{3}-\d{4} resolve o problema.

O problema começa quando as pessoas passam a disfarçar as informações intencionalmente. Um exemplo simples: a mensagem “555inches 555inches 5555inches” claramente tenta mascarar um número de telefone usando “inches” (polegadas) como separador. Um regex específico consegue capturar esse padrão — mas e quando o método de disfarce muda? E se alguém usar emojis, palavras por extenso, leetspeak (substituição de letras por números e símbolos), ou combinar vários métodos ao mesmo tempo?

Além disso, regex é completamente incapaz de realizar análise de sentimento, entender contexto ou identificar intenções. Para esses cenários mais complexos e dinâmicos, a recomendação da AWS é usar IA generativa com o Amazon Bedrock.

Amazon Bedrock: IA generativa como solução

O Amazon Bedrock é um serviço totalmente gerenciado e sem servidor que oferece acesso a uma variedade de modelos fundacionais de alto desempenho. Ele permite experimentar, personalizar e integrar capacidades de IA generativa em aplicações usando os serviços familiares da AWS.

Para começar a usar os modelos e testar prompts, é necessário ter:

• Uma conta AWS ativa
• Permissões IAM adequadas
• Familiaridade com o Console de Gerenciamento da AWS
• Noções básicas de engenharia de prompts

O ambiente de testes é o playground do Amazon Bedrock, disponível diretamente no console da AWS. Usando o modelo Amazon Nova 2 Lite no modo Single Prompt, é possível ajustar parâmetros de inferência como o comprimento da resposta (até 1.000 tokens) e a temperatura (para saídas mais consistentes).

Detecção na prática: do simples ao complexo

Caso 1: número de telefone disfarçado com emojis

Considere a mensagem: “I can get that done for you directly :five: :five: :five:-:five: :five: :five:-:zero: :one: :one: :one:”. Um prompt simples já é suficiente para que o modelo identifique o número:

“Analise o feedback de clientes sobre pedidos de entrega para uma corretagem e identifique se o fornecedor forneceu números de telefone. O texto pode conter emojis para disfarçar o conteúdo original.”

O modelo Nova 2 Lite decodifica os emojis corretamente e conclui que se trata de um número de telefone disfarçado.

Caso 2: múltiplos métodos de disfarce simultâneos

O cenário mais desafiador envolve uma mensagem com vários tipos de ofuscação ao mesmo tempo — emojis, leetspeak, medidas falsas e informações espalhadas pelo texto. O exemplo usado no artigo original contém:

• Nome de empresa disfarçado: Am@z0n, Inc.
• Telefone com unidades de medida falsas: 321inches 555inches 0177inches
• E-mail explícito: tylerh@anycompany.com
• E-mail sem arroba: jesseatanycompany.com
• Telefone com reticências: 123...555....0123
• Telefone com emojis de números
• Endereço físico completo
• Nome completo e características físicas pessoais

Para esse caso, o prompt precisa instruir o modelo a agir como um detetive, identificando informações de contato em todas as categorias — telefone, nome de empresa, e-mail, endereço, nome pessoal e características físicas — enquanto ignora medidas de frete legítimas. O prompt também solicita que as descobertas sejam agrupadas por categoria em formato JSON, com nível de confiança (escala de 1 a 5) e justificativa para cada item.

O resultado retornado pelo modelo identificou corretamente: 3 números de telefone, 2 nomes de empresas, 2 endereços de e-mail, 1 endereço físico, 1 nome pessoal e características físicas — tudo estruturado em JSON pronto para ser consumido por sistemas downstream.

Otimizando o prompt com a ferramenta nativa do Bedrock

O Amazon Bedrock oferece uma ferramenta de otimização de prompts que reescreve automaticamente os prompts para obter resultados mais adequados ao modelo e ao caso de uso. O prompt otimizado é estruturado em seções distintas — Tarefa, Instruções e Formato de Saída — o que produz respostas mais consistentes e organizadas.

Após desenvolver e validar os prompts, é importante testá-los em escala usando o Amazon Bedrock Evaluations, além de considerar fatores como custo, throughput e os endpoints e cotas disponíveis.

Além da detecção: análise de sentimento e itens de ação

Detectar violações de política é apenas o primeiro passo. O artigo também demonstra como usar o Amazon Bedrock para extrair inteligência adicional das mensagens, seguindo as boas práticas de prompting para os modelos Amazon Nova.

Análise de sentimento

Um prompt estruturado analisa o sentimento expresso pelo fornecedor em relação ao serviço ou aplicativo da corretagem, classificando-o como Positivo, Neutro ou Negativo, com nível de confiança e justificativa em no máximo 20 palavras. O retorno é em JSON:

{
  "Sentiment": "Negative",
  "Confidence": 90,
  "Reason": "Words 'sucks' and 'cannot save' indicate clear dissatisfaction with the app."
}

Identificação de itens de ação

Um terceiro prompt analisa se há itens pendentes que exigem investigação da corretagem — como problemas técnicos reportados pelos usuários. O resultado é usado para criar tickets de suporte automaticamente:

{
  "Action": "Investigate brokerage app issue",
  "Confidence": 95,
  "Reason": "User reports inability to save stage updates, indicating a functional problem."
}

Gerenciamento de prompts em produção

Os três prompts finais — violações de política, análise de sentimento e itens de ação — são armazenados no Amazon Bedrock Prompt Management com controle de versão. Essa abordagem permite que equipes de desenvolvimento atualizem os prompts sem interromper a orquestração de mensagens já em produção, além de facilitar o reuso dos prompts em múltiplos processos.

Resultados e conclusão

Em testes com uma amostra de 10 mensagens reais de corretagem, a abordagem com IA generativa atingiu 100% de precisão na identificação de informações de contato ofuscadas — um resultado que métodos baseados em regex não conseguiriam alcançar com a mesma flexibilidade.

A comparação entre as duas abordagens deixa claro o diferencial da IA generativa:

• Compreensão contextual: detecta informações disfarçadas levando em conta o contexto da mensagem
• Adaptabilidade: identifica novas técnicas de evasão sem necessidade de atualizações manuais constantes
• Análise multidimensional: avalia sentimento, itens de ação e violações de política em uma única solução
• Pontuação de confiança: permite tomadas de decisão mais precisas e graduadas
• Processamento de linguagem natural: interpreta variações como leetspeak e referências dependentes de contexto

Próximos passos sugeridos pela AWS

Após desenvolver os prompts, a AWS recomenda integrá-los aos fluxos de trabalho existentes via Amazon Bedrock API — o que permite chamadas de inferência em tempo real para múltiplos casos de uso. Para detalhes de implementação, a documentação indica o padrão fazendo requisições ao Amazon Bedrock via Amazon API Gateway.

Para implementações mais complexas, que envolvem múltiplas inferências de modelo, o AWS Step Functions pode orquestrar essas interações com coordenação de processos paralelos, tratamento de erros e retentativas automáticas. Veja mais em construindo aplicações de IA generativa com AWS Step Functions e Amazon Bedrock.

O Amazon EventBridge atua como roteador de eventos para orquestrar fluxos complexos entre serviços AWS, respondendo a eventos de negócio, mudanças de sistema e gatilhos baseados em tempo. Mais detalhes em construindo uma aplicação orientada a eventos com Amazon EventBridge.

Por fim, o Amazon Bedrock AgentCore permite criar sistemas de IA autônomos com processamento de dados em tempo real e protocolos de segurança integrados. Para começar, acesse como lançar e escalar agentes com segurança no Amazon Bedrock AgentCore.

Fonte

Intelligence-driven message defense and insights using Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/intelligence-driven-message-defense-and-insights-using-amazon-bedrock/)

O problema silencioso de agentes que degradam em produção

Agentes de IA costumam performar bem no lançamento. O problema é que essa qualidade não se mantém por conta própria. Modelos evoluem, o comportamento dos usuários muda, e prompts criados para um contexto específico acabam sendo reutilizados em situações que nunca foram previstas. A qualidade do agente vai caindo — e, na maioria das vezes, ninguém percebe até alguém reclamar.

O fluxo de correção tradicional é bem conhecido: um desenvolvedor lê os traces, formula uma hipótese, reescreve o prompt, testa alguns casos manualmente e publica a correção. Aí o ciclo recomeça — muitas vezes introduzindo um novo problema para outro usuário. É um processo baseado em intuição, não em evidências sistemáticas.

Até agora, o Amazon Bedrock AgentCore já oferecia as peças para depurar manualmente ou construir implementações customizadas: verificar pontuações de avaliação para detectar queda de qualidade, mergulhar nos traces para identificar a causa raiz e atualizar o agente com uma configuração melhorada. O desenvolvedor era o motor de performance — dependendo da própria intuição, sem respaldo sistemático de dados.

Times de ciência dedicados e benchmarks centralizados ajudam, mas não são uma solução prática nem ágil para a maioria das equipes de produto. E mesmo quando essa estrutura existe, ela tende a operar em ciclos semanais ou mensais, enquanto os agentes derivam em produção todos os dias.

O que a AWS anunciou: fechando o loop de qualidade

A AWS anunciou novas capacidades no AgentCore que completam o ciclo de observar, avaliar e melhorar a performance e a qualidade de agentes. São três componentes principais:

• Recomendações: analisam traces de produção e saídas de avaliação para otimizar o prompt de sistema ou as descrições de ferramentas, com base no avaliador especificado pela equipe.
• Avaliação em lote (Batch Evaluation): testa a recomendação contra um conjunto de dados de teste pré-definido e reporta pontuações agregadas, identificando regressões nos casos que já são conhecidos. Quando os cenários criados manualmente não são suficientes, também é possível simular um conjunto de dados usando um ator baseado em LLM que simula o papel de um usuário final.
• Testes A/B: executam uma comparação controlada entre versões do agente por meio do AgentCore Gateway, dividindo o tráfego real de produção na proporção configurada e reportando resultados com intervalos de confiança e significância estatística.

A lógica é direta: as recomendações propõem mudanças, a avaliação em lote e os testes A/B as validam — e juntos eles substituem o ciclo manual de ler traces, chutar correções e publicar no escuro.

“Avaliar e melhorar agentes continuamente é essencial para gerar valor orientado a dados. Processos que antes exigiam semanas de ajuste manual de prompts evoluíram para ciclos rápidos e repetíveis com o AgentCore. Ao derivar recomendações de melhoria a partir de dados de traces de produção e validar seu impacto por meio de testes A/B, as organizações podem otimizar a performance garantindo precisão e efetividade.” — Yoshiharu Okuda, NTT DATA

Como o loop funciona na prática

O fluxo descrito pela AWS se aplica a qualquer tipo de mudança — atualização de modelo, refatoração de prompt, atualização de conjunto de ferramentas ou upgrade de framework. O exemplo utilizado é o cenário de atualização de modelo, mas o padrão é o mesmo.

1. Rastreabilidade ponta a ponta

O AgentCore captura cada chamada de modelo, invocação de ferramenta e etapa de raciocínio como traces compatíveis com OpenTelemetry, gerenciados pelo AgentCore Observability. As avaliações pontuam esses traces automaticamente em dimensões como taxa de sucesso de objetivo, precisão na seleção de ferramentas, utilidade e segurança — usando avaliadores nativos, comparações com ground-truth ou pontuação customizada via LLM-as-judge.

2. Gerar uma recomendação

A equipe aponta a API de Recomendações para o grupo de logs do CloudWatch onde o agente grava seus traces. Em seguida, escolhe o sinal de recompensa — o avaliador que deseja otimizar, seja nativo do AgentCore ou customizado — e define o que otimizar: o prompt de sistema ou as descrições das ferramentas. O AgentCore analisa os traces considerando o sinal de recompensa fornecido e gera uma recomendação para melhorar a performance naquele critério. Para recomendações de descrição de ferramentas, o serviço aprimora apenas a descrição, sem tocar na implementação. O serviço propõe — a equipe decide o que levar adiante.

3. Empacotar a mudança como bundle de configuração

As configurações são empacotadas como bundles — snapshots imutáveis e versionados da configuração do agente, identificados pelo ARN do runtime: ID do modelo, prompt de sistema e descrições das ferramentas. O agente lê sua configuração ativa dinamicamente em tempo de execução via SDK do AgentCore, o que significa que trocar um prompt ou um modelo é uma mudança de configuração, não de código. Cria-se um bundle para a configuração atual e outro para a recomendação. Para mudanças que envolvam código, o caminho é publicar em um endpoint de runtime separado.

4. Validar offline: avaliação em lote

O agente é executado contra um conjunto de dados curado usando o novo bundle. As sessões resultantes são avaliadas em lote e as pontuações agregadas são comparadas com a linha de base. Isso identifica regressões nos casos de uso já mapeados. As equipes costumam integrar a avaliação em lote aos pipelines de Integração e Entrega Contínua (CI/CD) para garantir que nenhuma mudança de configuração chegue à produção sem passar pelos casos conhecidos.

5. Validar com tráfego real: testes A/B

O AgentCore Gateway é configurado para dividir o tráfego real de produção entre duas variantes — a versão atual como controle e a candidata como tratamento. As variantes podem ser diferentes versões de bundle no mesmo runtime (para mudanças apenas de configuração) ou diferentes targets no gateway apontando para endpoints de runtime separados (para mudanças que incluam código). A avaliação online pontua cada sessão com os avaliadores especificados. Os resultados incluem intervalos de confiança e p-values. Quando há dados suficientes para confiar na performance da nova versão, o teste é encerrado e a nova variante é promovida como padrão. Para reverter, basta pausar o teste — o agente volta à configuração anterior.

“O que levava semanas de iteração manual de prompts agora é um ciclo repetível com o AgentCore: gerar uma recomendação a partir de traces de produção, validá-la com tráfego real com significância estatística e publicar a configuração vencedora. Cada ciclo produz os dados de base para o próximo — o processo de melhoria se compõe.” — Masashi Shimizu, Nomura Research Institute

Exemplo prático: o Market Trends Agent

A AWS disponibilizou o Market Trends Agent no GitHub como exemplo de referência — um agente de inteligência de mercado construído para corretores de investimento, cobrindo dados de ações em tempo real, análise setorial, busca de notícias e perfis personalizados de corretores.

Para um agente que atende corretores com diferentes perfis de risco, interesses setoriais e estilos de conversa, a degradação de qualidade é difícil de detectar e ainda mais difícil de corrigir sem as ferramentas certas. O exemplo demonstra o loop completo: gerar uma recomendação que identifica onde o agente falha em personalizar conselhos para a estratégia declarada do corretor ou seleciona a ferramenta errada quando uma consulta abrange múltiplos setores; empacotar a mudança como uma versão de bundle de configuração; validar a correção com avaliação em lote sobre um conjunto curado de conversas; e então fazer um teste A/B da configuração contra sessões reais de corretores com confiança estatística antes de promovê-la para produção.

Para onde o AgentCore Optimization está evoluindo

O preview atual foi projetado para ser acionado pelo desenvolvedor: a equipe escolhe quando gerar uma recomendação, qual avaliador direcionar e se promove o resultado. A visão da AWS é um flywheel onde traces alimentam avaliações, avaliações identificam deriva, recomendações transformam esse sinal em uma mudança concreta, e os testes A/B provam que ela funciona. A configuração vencedora se torna a nova linha de base, e os traces que ela produz são a entrada para o próximo ciclo.

Com o tempo, o flywheel gira com menos esforço. As recomendações passarão a considerar múltiplos avaliadores simultaneamente, evidenciando trade-offs. Também expandirão a superfície de otimização para skills — propondo novas ou refinando as existentes com base no uso em produção. A análise de traces agrupará falhas de produção em padrões que podem ser endereçados antes que se multipliquem. Alarmes de monitoramento poderão disparar automaticamente uma recomendação e validação quando um avaliador cair abaixo de um limiar, entregando o resultado em uma fila de revisão. A equipe decide o que vai para produção — e o sistema faz o trabalho pesado para chegar lá.

Disponibilidade e como começar

As capacidades estão disponíveis em preview hoje pelo Amazon Bedrock AgentCore nas regiões AWS onde o AgentCore Evaluations está disponível. Durante o preview, o AgentCore Optimization tem como alvo prompts de sistema e descrições de ferramentas para agentes publicados no AgentCore Runtime e que utilizam o AgentCore Observability e o AgentCore Evaluations.

Para começar, acesse pelo console ou CLI do AgentCore. Leia a documentação oficial e siga os tutoriais passo a passo disponíveis aqui.

Fonte

Introducing the agent quality loop: AgentCore Optimization now in preview (https://aws.amazon.com/blogs/machine-learning/introducing-the-agent-quality-loop-agentcore-optimization-now-in-preview/)

O desafio real da customização de modelos de IA

Toda organização tem acesso aos mesmos modelos de fundação disponíveis no mercado. A vantagem competitiva de verdade vem de customizá-los com dados proprietários e expertise de domínio. O problema é que chegar lá é complexo — mesmo para equipes experientes.

Dominar técnicas como Ajuste Fino Supervisionado (SFT), Otimização Direta de Preferências (DPO) e Aprendizado por Reforço com Recompensas Verificáveis (RLVR) exige muito conhecimento especializado. Além disso, é preciso navegar por APIs fragmentadas, formatos de dados específicos por modelo, projetar avaliações rigorosas e gerenciar ciclos de experimentos que podem durar meses.

Para endereçar esse problema, o Amazon SageMaker AI passou a oferecer uma experiência agêntica que muda esse cenário. Os desenvolvedores descrevem seu caso de uso em linguagem natural e o agente de codificação por IA conduz todo o processo — desde a definição do caso de uso e preparação dos dados, passando pela seleção da técnica, avaliação e chegando ao deploy.

O que são as Agent Skills para customização de modelos

O elemento central dessa experiência são as Agent Skills para customização de modelos. Trata-se de conjuntos de instruções modulares e pré-construídos que codificam expertise profunda da AWS e de ciência de dados em todo o ciclo de customização.

Quando o desenvolvedor descreve seu caso de uso, o agente de IA ativa as Skills relevantes, que o orientam por etapas como preparação e validação de dados, seleção de técnica, configuração de hiperparâmetros, avaliação do modelo e implantação. As Skills fornecem conhecimento especializado sobre as APIs do SageMaker AI, fluxos de trabalho de Aprendizado de Máquina (ML), boas práticas e padrões comuns — gerando notebooks prontos para execução em cada etapa.

Um ponto importante: as Skills são totalmente customizáveis. Equipes podem modificá-las para refletir seus próprios fluxos de trabalho, padrões de governança e preferências de ferramentas, criando boas práticas organizacionais reproduzíveis — um desafio recorrente com assistentes de codificação de propósito geral.

Amazon Kiro no SageMaker AI Studio JupyterLab

O JupyterLab no SageMaker AI inclui suporte integrado a ambientes de desenvolvimento agêntico via Protocolo de Comunicação entre Agentes (ACP). Por padrão, o Kiro, agente de desenvolvimento de software da Amazon, vem pré-configurado no painel de chat, oferecendo completação de código com IA, assistência para debugging e suporte interativo de codificação diretamente no JupyterLab.

Quando o desenvolvedor utiliza agentes de codificação no JupyterLab do SageMaker AI, o espaço carrega automaticamente as Skills de customização de modelos relevantes no contexto do agente. Além disso, é possível configurar outros agentes compatíveis com o Protocolo de Comunicação entre Agentes (ACP), como o Claude Code, oferecendo flexibilidade para trabalhar com as ferramentas que melhor se encaixam no fluxo de trabalho de cada equipe. Também é possível usar acesso remoto ao próprio IDE fora do JupyterLab.

Pré-requisitos para começar

Antes de iniciar, a AWS lista os seguintes requisitos:

• Uma conta AWS
• Acesso ou capacidade de criar um domínio SageMaker AI — via configuração rápida ou configuração manual
• Uma role AWS IAM com as permissões necessárias
• Um bucket do Amazon Simple Storage Service (Amazon S3)
• Acesso a um espaço de computação do SageMaker AI Studio JupyterLab — sem requisito mínimo de tipo de instância
• Imagem SageMaker AI Distribution versão 4.1 ou superior
• A política gerenciada AmazonSageMakerFullAccess associada à role de execução do domínio, além da política inline para acesso a Lambda, S3 e Bedrock
• A trust policy da role de execução deve permitir que os três serviços assumam a role: sagemaker.amazonaws.com, lambda.amazonaws.com e bedrock.amazonaws.com

As nove Skills do ciclo de customização

As Agent Skills do SageMaker AI são construídas em conformidade com o formato aberto Agent Skills. Os workflows de customização guiados por agente são alimentados por nove Skills modulares que cobrem todo o ciclo de customização:

• Especificação do Caso de Uso: descoberta estruturada para definir o problema de negócio, usuários e critérios de sucesso
• Descoberta de Planejamento: gera um plano de customização dinâmico e com múltiplas etapas, adaptado ao caso de uso
• Configuração de Fine-tuning: seleciona o modelo base no SageMaker AI Hub e recomenda a técnica (SFT, DPO ou RLVR)
• Avaliação de Dataset: valida o formato e o esquema do dataset antes do treinamento
• Transformação de Dataset: converte entre formatos de dados de ML (OpenAI chat, SageMaker AI, Hugging Face, Amazon Nova)
• Fine-tuning: gera notebooks de treinamento para fine-tuning serverless no SageMaker AI
• Avaliação de Modelo: configura avaliação com LLM-as-Judge, incluindo métricas integradas e customizadas
• Deploy de Modelo: determina o caminho de implantação (endpoint SageMaker AI ou Bedrock) e gera o código correspondente

O agente de codificação — seja Kiro, Claude Code, Cursor ou outro — fornece a interface conversacional, enquanto as Skills do SageMaker AI orquestram o workflow. Ao interagir com o agente, ele ativa as Skills relevantes, permitindo chamar APIs do SageMaker AI, acessar fontes de dados no S3 e interagir com registros de modelos via servidores MCP fornecidos pela AWS. Notebooks Jupyter são gerados automaticamente para cada etapa do processo.

Técnicas de fine-tuning suportadas

As Skills de customização de modelos suportam atualmente três técnicas de fine-tuning, recomendando a mais adequada durante a fase de planejamento:

• SFT (Ajuste Fino Supervisionado): treina com pares de entrada/saída — ideal para comportamento específico de tarefas como seguimento de instruções, conformidade de formato e respostas adaptadas ao domínio
• DPO (Otimização Direta de Preferências): treina com saídas preferidas versus rejeitadas — melhor para alinhar tom, estilo e preferências subjetivas ao julgamento humano
• RLVR (Aprendizado por Reforço com Recompensas Verificáveis): treina usando funções de recompensa baseadas em código — adequado para tarefas onde a correção pode ser verificada programaticamente

Solução de exemplo: modelo de raciocínio clínico

Para demonstrar o funcionamento, o artigo da AWS apresenta um caso de uso onde um Modelo de Linguagem Pequeno (SLM) é ajustado com o dataset FreedomIntelligence/medical-o1-reasoning-SFT para construir um modelo de raciocínio clínico capaz de percorrer casos médicos passo a passo antes de fornecer um diagnóstico. Isso demonstra como o fine-tuning pode especializar um modelo de propósito geral para tarefas de raciocínio específicas de domínio.

O SageMaker AI também disponibiliza uma biblioteca de datasets de exemplo para quem quiser experimentar outros casos de uso com SFT, DPO e RLVR como ponto de partida.

Configurando o Claude Code no JupyterLab

O SageMaker AI Studio suporta a adição de outros agentes de codificação usando o Protocolo de Controle de Agentes (ACP). Exemplos de agentes compatíveis incluem Claude (via claude-agent-acp), OpenCode (via CLI opencode >= 1.0.0), Gemini (via CLI gemini >= 0.34.0) e Codex (via codex-acp). Consulte o guia do usuário do JupyterLab para mais detalhes sobre os passos de instalação.

Para usar o Claude Code, o processo envolve instalar a ferramenta CLI no terminal do SageMaker AI Studio JupyterLab com o comando:

npm install -g @zed-industries/claude-agent-acp

Em seguida, reiniciar o espaço com o comando restart-jupyter-server ou via interface do Studio, autenticar-se com o agente e selecioná-lo no dropdown do painel de chat (@Claude).

O Claude Code pode ser usado com a maioria das assinaturas Anthropic, inclusive configurado para usar Claude via Amazon Bedrock. Para isso, basta seguir os pré-requisitos no guia do Claude Code, habilitar o acesso ao modelo no Bedrock e criar o seguinte arquivo de configuração:

~/.claude/settings.json:
{
  "env": {
    "CLAUDE_CODE_USE_BEDROCK": "1"
  }
}

Como funciona na prática: do planejamento ao deploy

Fase de planejamento

Ao receber o prompt do usuário, o agente não começa a executar tarefas imediatamente. Ele entra em uma fase de planejamento onde identifica e ativa as Skills necessárias para completar o trabalho, gerando um workflow que o usuário pode revisar e modificar. A partir do prompt inicial, o agente reconhece os domínios de Skills relevantes e faz perguntas direcionadas sobre a prontidão do dataset e detalhes do caso de uso antes de gerar qualquer código.

Fine-tuning no SageMaker AI

Com múltiplas famílias de modelos e técnicas disponíveis, o agente analisa a estrutura do dataset e os requisitos da tarefa para fornecer recomendações personalizadas de modelo e técnica. O SageMaker AI suporta customização serverless para as famílias Amazon Nova, GPT-OSS, Llama, Qwen e DeepSeek. No exemplo do artigo, o modelo Qwen3-0.6B foi escolhido por ser econômico para treinar e implantar, sendo suficiente para tarefas específicas de domínio como raciocínio médico.

O agente gera um notebook de treinamento que utiliza um job de treinamento serverless do SageMaker AI, com métricas de treinamento e validação rastreadas pelo SageMaker AI MLflow Apps integrado.

Avaliação

Após o treinamento, o agente recomenda uma abordagem de avaliação baseada no caso de uso — ou o usuário pode especificar as métricas desejadas, como acurácia em perguntas de raciocínio médico ou melhoria do score de recompensa em relação ao modelo base. O agente então gera um notebook que executa a avaliação e reporta os resultados. Os resultados de avaliação também são distribuídos para o MLflow para comparações antes de avançar para o deploy.

Deploy

Na etapa final, o agente orienta sobre as opções de implantação disponíveis no SageMaker AI e no Bedrock via Bedrock Custom Model Import, dependendo dos requisitos de latência, escalabilidade e integração. Em seguida, gera um notebook que provisiona o endpoint e executa uma requisição de inferência de exemplo para validar se o modelo está pronto para servir previsões.

Customizando as Skills

As Skills incluídas no SageMaker AI cobrem os workflows mais comuns de fine-tuning, mas também é possível customizar Skills existentes ou criar novas para atender aos padrões e ferramentas da organização. Por exemplo, é possível estender a Skill de avaliação de modelos para incluir métricas específicas do domínio ou adicionar uma nova Skill para um target de deploy customizado.

As Skills são definidas em arquivos markdown simples no diretório ~/.kiro/skills, tornando-as fáceis de criar, versionar e compartilhar entre equipes.

Conclusão

A experiência agêntica de customização de modelos no Amazon SageMaker AI está disponível hoje. A partir de um único prompt em linguagem natural, o agente planeja o workflow, configura e executa um job de fine-tuning, avalia os resultados com métricas adequadas ao caso de uso e realiza o deploy do modelo ajustado.

Para começar, basta lançar um espaço JupyterLab no SageMaker Studio com Kiro e Agent Skills pré-configurados — ou trazer as mesmas Skills para o IDE preferido a partir do repositório no GitHub. Consulte também a documentação oficial para entender como a customização serverless de modelos com Agent Skills pode acelerar o caminho da ideia até modelos em produção.

O que antes exigia meses de trabalho especializado em ML agora pode ser concluído em dias. A expertise está codificada, o workflow é guiado e o código gerado pertence integralmente ao desenvolvedor.

Fonte

Agent-guided workflows to accelerate model customization in Amazon SageMaker AI (https://aws.amazon.com/blogs/machine-learning/agent-guided-workflows-to-accelerate-model-customization-in-amazon-sagemaker-ai/)

Criar dashboards ficou muito mais rápido no Amazon QuickSight

Montar um dashboard significativo sempre exigiu tempo — e bastante paciência. Mesmo profissionais experientes em Inteligência de Negócios (BI) costumam gastar horas configurando visuais, filtros e campos calculados do zero. A AWS anunciou uma nova capacidade no Amazon QuickSight que muda esse cenário: agora é possível gerar análises completas com múltiplas abas a partir de um simples prompt em linguagem natural.

A ideia é direta — você descreve o que quer ver, e o QuickSight constrói a estrutura do dashboard por você. O resultado é uma análise pronta para uso, com visuais adequados ao tipo de dado, controles de filtro para que outras pessoas possam explorar por diferentes dimensões, e campos calculados como crescimento ano a ano e comparações mês a mês.

Para quem essa funcionalidade foi pensada

A AWS descreve casos de uso bem práticos para essa novidade. Analistas de dados que precisam montar relatórios operacionais recorrentes, gerentes de programa preparando revisões para lideranças, ou engenheiros explorando um dataset pela primeira vez — todos se beneficiam da possibilidade de descrever o que precisam em vez de configurar tudo manualmente.

Durante o período de acesso antecipado, usuários de operações, engenharia e ciência de dados relataram redução de 90% ou mais no tempo de criação de dashboards. Um dos participantes comentou que criar aquele dashboard teria levado pelo menos um dia inteiro, mas com a funcionalidade levou cinco minutos.

Como o processo funciona na prática

Pré-requisitos

Para usar a funcionalidade, é necessário ter uma conta AWS ativa e uma assinatura do Amazon QuickSight na edição Enterprise.

Seleção dos datasets

O ponto de partida é escolher os dados que serão analisados. No QuickSight, os dados ficam organizados em datasets, que se conectam a fontes como Amazon Redshift, Amazon Simple Storage Service (Amazon S3) ou arquivos enviados diretamente. É possível selecionar entre um e três datasets por análise — útil quando os dados estão distribuídos em tabelas diferentes, como pedidos em um dataset e produtos em outro.

Descrevendo o que você quer

Com os datasets selecionados, o próximo passo é escrever um prompt em linguagem natural descrevendo os insights desejados. O QuickSight recomenda que o prompt inclua as perguntas de negócio relevantes, as métricas de interesse e como as informações devem ser organizadas entre as abas.

O próprio artigo da AWS traz um exemplo ilustrativo de prompt:

“Crie um dashboard operacional mostrando tendências de volume de pedidos, KPIs de receita, desempenho de entrega comparando datas estimadas e reais, e breakdown de categoria de produto por receita e contagem de pedidos. Inclua campos calculados para receita total, valor médio de pedido e crescimento mês a mês de pedidos.”

Análise automática dos dados

Após o envio do prompt, o QuickSight examina a estrutura do dataset e as estatísticas das colunas. O progresso é exibido em tempo real: análise das colunas, análise das estatísticas e criação do plano de análise. Caso o usuário navegue para outra tela, é possível acompanhar o status pela aba Analyses → Generations e retornar à tela de progresso quando quiser.

Revisão e edição do plano

Antes de gerar o dashboard de fato, o QuickSight apresenta um plano estruturado da análise em uma visualização de dois painéis. O painel esquerdo exibe o prompt original e um resumo dos datasets selecionados. O painel direito mostra a estrutura proposta: controles de filtro, abas e os visuais planejados para cada uma delas.

Nesse momento, o usuário pode gerar imediatamente ou optar por editar o plano — ajustando nomes de abas, adicionando ou removendo visuais, ou reorganizando o layout. Esse passo de revisão é importante porque mantém o controle nas mãos de quem está criando a análise.

Geração da análise

Ao confirmar a geração, o QuickSight cria cada componente em sequência — campos calculados, filtros e cada aba — com atualizações de progresso em tempo real. O resultado é uma análise nativa do QuickSight, compatível com os fluxos de publicação existentes, padrões de incorporação em aplicações, pipelines de Integração Contínua e Entrega Contínua (CI/CD), e edição manual na superfície de análise. Cada visual pode ser refinado depois da geração. Não se trata de uma imagem estática — é uma análise interativa e conectada aos dados.

Publicação e compartilhamento

Quando a análise estiver satisfatória, basta publicá-la como dashboard com um único clique. A partir daí, é possível compartilhá-la com outros usuários, incorporá-la em aplicações ou agendar entregas por e-mail. O dashboard publicado mantém todas as abas, visuais, controles de filtro e campos calculados gerados. Os destinatários interagem com o dashboard sem ter acesso à análise subjacente.

Disponibilidade

A funcionalidade Generate Analysis está disponível para usuários com assinatura Enterprise ou Author Pro. Há também acesso promocional até dezembro de 2026 para organizações com Amazon QuickSight Enterprise que não tenham restringido o acesso.

As regiões AWS disponíveis no lançamento são: Leste dos EUA (Norte da Virgínia), Oeste dos EUA (Oregon), Ásia-Pacífico (Sydney), Ásia-Pacífico (Tóquio), Europa (Frankfurt), Europa (Irlanda) e Europa (Londres).

Vale a pena conhecer também

Para explorações pontuais e perguntas que surgem no dia a dia — fora dos dashboards recorrentes — a AWS indica o Dataset Q&A, que permite consultar dados diretamente em linguagem natural, sem precisar construir um dashboard completo.

Conclusão

A nova capacidade de geração de análises no Amazon QuickSight representa um avanço relevante para equipes que trabalham com dados. A IA assume o trabalho inicial de estruturação, e o profissional refina e publica. Para times que criam dashboards com frequência, a redução de tempo pode ser expressiva — e o acesso promocional até o final de 2026 é uma boa oportunidade para testar a funcionalidade sem custo adicional.

Fonte

Generate dashboards from natural language prompts in Amazon Quick (https://aws.amazon.com/blogs/machine-learning/generate-dashboards-from-natural-language-prompts-in-amazon-quick/)

Contexto: quando analytics e IA precisam andar juntos

Organizações ao redor do mundo estão cada vez mais buscando combinar análise de dados e Inteligência Artificial (IA) para acelerar decisões. Nesse cenário, a AWS posiciona o Amazon Quick como um serviço unificado de analytics com IA agêntica — reunindo visualização de dados, interação em linguagem natural e automação orientada por agentes em uma experiência única e governada. A proposta é que usuários de negócio consigam explorar dados, gerar insights e tomar ações sem precisar de expertise em aprendizado de máquina.

Ao mesmo tempo, arquiteturas modernas de dados estão migrando para data lakes escaláveis baseados em formatos de tabela abertos, como o Apache Iceberg. Esses formatos oferecem melhor desempenho, eficiência de custo e governança. O problema clássico, porém, é que analisar dados em grande escala normalmente exige movê-los para data warehouses ou sistemas OLAP — o que introduz latência, custo adicional e complexidade operacional.

Para resolver esse gargalo, a AWS anunciou uma novidade importante: o Amazon Quick agora suporta o Amazon S3 Tables (tabelas Apache Iceberg) como uma nova fonte de dados nativa.

O que muda com a integração S3 Tables no Amazon Quick

Com esse novo recurso, o Amazon Quick passa a permitir consultas e visualizações diretas de tabelas Apache Iceberg armazenadas em um bucket de tabelas do Amazon S3 — sem a necessidade de camadas intermediárias de consulta. Isso representa uma escolha arquitetural adicional para equipes que precisam reduzir movimentação de dados, melhorar desempenho e manter uma fonte única, governada e confiável.

O recurso suporta dois modos de operação: Direct Query e SPICE (Motor de Cálculo em Memória, Super-rápido e Paralelo — SPICE). O modo Direct Query é o foco principal dessa novidade, pois é ele que viabiliza o acesso em tempo quase real aos dados do data lake. O modo SPICE continua disponível para cenários que preferem atualizações programadas.

Benefícios principais

• Arquitetura simplificada: elimina a necessidade de data warehouses ou camadas OLAP separadas, reduzindo complexidade operacional e overhead de infraestrutura.
• Insights em tempo quase real: minimiza a movimentação de dados e dependências de pipelines, garantindo que dashboards e análises reflitam os dados mais recentes disponíveis.
• Escalabilidade: suporta consultas a conjuntos de dados de grande escala armazenados em buckets de tabelas S3 sem exigir curadoria, replicação ou restrições de tamanho.

Visão geral da solução

Para ilustrar o uso prático, a AWS apresenta um cenário fictício com a empresa AnyCompany Corp., uma organização global de serviços financeiros que processa transações de cartão em múltiplas regiões. Os dados de transação são gerados por fontes diversas: sistemas de ponto de venda, aplicativos de mobile banking, dispositivos de pagamento habilitados para Internet das Coisas (IoT) e gateways online.

Para atender às necessidades de detecção de fraude, monitoramento de taxas de aprovação e acesso rápido a insights acionáveis, a solução combina ingestão de dados em streaming, data lake em formato de tabela aberta e analytics com IA. Os eventos de transação são transmitidos via Amazon Kinesis Data Streams e entregues pelo Amazon Data Firehose em um bucket de tabelas S3 no formato Apache Iceberg.

Com o conector nativo de S3 Tables do Quick, usuários de negócio conseguem consultar o data lake em tempo quase real e analisar os dados usando linguagem natural — sem depender de processamento em lote.

Arquitetura da solução

A arquitetura é composta por quatro camadas principais: ingestão de dados, armazenamento, consulta e analytics. O destaque da novidade está nas camadas de consulta e analytics.

Os eventos de transação são ingeridos em tempo real via Amazon Kinesis Data Streams, formando uma camada de streaming escalável e de baixa latência. Esses eventos são entregues continuamente a um bucket de tabelas S3 no formato Apache Iceberg, criando um data lake de alta performance que suporta tanto cargas de trabalho de streaming quanto analíticas.

Enquanto dados poderiam ser consultados tradicionalmente via Amazon Athena, o Amazon Quick permite consultas diretas e em tempo quase real ao S3 Tables, além de análise com IA em linguagem natural. Usuários de negócio podem explorar datasets ao vivo, gerar visualizações e obter insights — como identificar regiões com altas taxas de fraude na última hora — sem necessidade de expertise técnica.

Pré-requisitos

Para implementar essa solução, é necessário ter o pipeline de streaming (ingestão e armazenamento) já configurado, com os dados disponíveis em um bucket de tabelas do Amazon S3. Também é necessária uma assinatura do Amazon Quick Enterprise.

Como configurar: passo a passo

Passo 1: Habilitar o acesso ao S3 Tables no Amazon Quick

O primeiro passo é configurar o Amazon Quick para acessar o S3 Tables, permitindo que os buckets de tabelas sejam descobertos automaticamente ao criar uma fonte de dados. Isso é feito nas configurações de conta do Quick, na seção de permissões para recursos AWS. Basta selecionar o Amazon S3 Tables, escolher o bucket de tabelas relevante e salvar as configurações. Esse passo adiciona as permissões necessárias à role do Amazon Quick para descobrir os dados do bucket especificado.

Passo 2: Criar uma fonte de dados no Amazon Quick usando S3 Tables

Com as permissões configuradas, o próximo passo é criar uma fonte de dados apontando para o bucket de tabelas desejado. No exemplo da AWS, o bucket s3table-datasamples contém duas tabelas: customer_dimension (dados fictícios de clientes bancários) e transaction_events (dados fictícios de transações de cartão de crédito em streaming). O processo envolve selecionar “Amazon S3 Tables (tabelas Apache Iceberg)” como tipo de fonte de dados e informar o ARN do bucket.

Passo 3: Construir um dataset no Amazon Quick

Com a fonte de dados criada, o próximo passo é construir um dataset. O fluxo consiste em selecionar o namespace da fonte de dados, escolher as tabelas desejadas e configurar os joins necessários. No exemplo, as tabelas customer_dimension e transaction_events são unidas pela coluna customer_id usando um Inner Join. Um detalhe importante: o modo Direct Query deve estar selecionado para aproveitar ao máximo o acesso em tempo quase real ao S3 Tables. O modo SPICE pode ser escolhido caso se prefira atualizações programadas.

Passo 4: Interagir com o dataset via chat do Amazon Quick

Após publicar o dataset, é possível iniciar conversas com os dados usando linguagem natural pelo assistente “My Assistant” do Amazon Quick. No exemplo apresentado, o usuário pergunta ao agente o total de transações ocorridas no mês atual e, em seguida, solicita um detalhamento por dia usando o timestamp de ingestão. O agente retorna as respostas automaticamente, sem necessidade de configuração técnica adicional.

Passo 5: Demonstrar a responsividade em tempo quase real com dados em streaming

Para validar a capacidade de tempo quase real, novos dados de transação são transmitidos usando uma função AWS Lambda como produtor para um Kinesis Data Stream, armazenando os dados no bucket de tabelas S3 no formato Apache Iceberg via Firehose. Ao consultar novamente o assistente com um prompt solicitando os dados mais recentes, o agente retorna os registros recém-ingeridos — sem necessidade de atualização manual do dataset. Para criar sua própria fonte de streaming, a AWS disponibiliza a documentação oficial e posts de referência com orientações detalhadas.

Quando usar Direct Query vs. SPICE

Vale destacar que o modo Direct Query é a escolha certa quando o cenário exige acesso a dados atualizados em tempo quase real, como em casos de monitoramento de fraude ou análise de transações recentes. Já o modo SPICE continua sendo uma opção adequada para cenários analíticos típicos que se baseiam em atualizações programadas e não exigem acesso em tempo quase real.

Conclusão

A integração do Amazon Quick com o Amazon S3 Tables representa um avanço significativo para arquiteturas modernas de dados. Ao permitir consultas diretas a tabelas Apache Iceberg no S3, a AWS elimina camadas intermediárias, reduz a movimentação de dados e preserva uma fonte única e governada de verdade. Combinado com a experiência de chat em linguagem natural do My Assistant, o resultado é uma plataforma unificada de analytics com IA onde dados, insights e ações se integram de forma fluida e em tempo quase real.

Para mais detalhes sobre o recurso, consulte a documentação oficial sobre criação de datasets usando Amazon S3 Tables. Para dúvidas e discussões adicionais, a comunidade do Amazon Quick está disponível para suporte.

Fonte

From data lake to AI-ready analytics: Introducing new data source with S3 Tables in Amazon Quick (https://aws.amazon.com/blogs/machine-learning/from-data-lake-to-ai-ready-analytics-introducing-direct-query-with-s3-tables-in-amazon-quick/)