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

O problema que travava empresas na resolução de entidades em escala

Quem trabalha com dados corporativos sabe o quanto a resolução de entidades pode ser um gargalo operacional sério. Até agora, o AWS Entity Resolution exigia que qualquer adição de novos registros — mesmo que fosse apenas um único dado novo — acionasse o reprocessamento completo de toda a base histórica. Na prática, isso significava esperar até 2 dias para concluir o processo e arcar com custos que podiam chegar a milhares de dólares por ciclo.

Para empresas que trabalham com volumes massivos de dados em constante atualização, esse modelo se tornava inviável. Muitas organizações eram forçadas a buscar soluções alternativas, geralmente mais caras e complexas, apenas para contornar essa limitação.

O que muda com os workflows incrementais de ML

A AWS anunciou a disponibilidade geral (GA — General Availability) dos workflows de correspondência incremental baseados em Aprendizado de Máquina (ML — Machine Learning) no AWS Entity Resolution. A mudança é fundamental: em vez de reprocessar tudo, o serviço agora processa apenas os registros novos adicionados desde a última execução do workflow.

Os ganhos de eficiência são expressivos:

• 1 milhão de registros incrementais processados em menos de 1 hora — uma redução de 95% no tempo de processamento em comparação com o modelo anterior.
• Redução significativa nos custos de infraestrutura.
• Suporte a cargas incrementais de até 50 milhões de registros sobre bases históricas contendo até 1 bilhão de registros.

Com isso, o AWS Entity Resolution passa a ser viável para cargas de trabalho corporativas contínuas e em grande escala — cenários que antes eram economicamente inviáveis com a abordagem de reprocessamento total.

Disponibilidade e como começar

Os workflows incrementais de ML já estão disponíveis em todas as regiões da AWS onde o AWS Entity Resolution está presente. Para quem quiser começar a usar o recurso, a AWS disponibiliza um guia do usuário com as instruções para criação de um workflow de correspondência incremental com ML. Informações gerais sobre o serviço podem ser encontradas na página oficial do produto.

Fonte

AWS Entity Resolution launches support for incremental Machine Learning based matching workflows (https://aws.amazon.com/about-aws/whats-new/2026/05/aws-entity-resolution-ml/)

O que mudou no Amazon Quick

A AWS anunciou uma atualização relevante para o Amazon Quick: agora é possível gerar dashboards completos simplesmente descrevendo o que você quer, em linguagem natural. A funcionalidade se chama Generate Analysis e representa uma mudança significativa na forma como analistas e times de dados constroem seus painéis de visualização.

Como o Generate Analysis funciona

O fluxo é direto: o usuário descreve o dashboard que deseja criar, seleciona até três conjuntos de dados e revisa um plano editável antes de confirmar a geração. A partir daí, o Amazon Quick produz automaticamente:

• Planilhas organizadas com visuais selecionados de acordo com os dados fornecidos
• Controles de filtro para explorar diferentes dimensões da informação
• Campos calculados prontos, como crescimento ano a ano e comparações mês a mês

Um exemplo prático dado pela própria AWS: ao descrever “crie um dashboard de desempenho de vendas com tendências de receita, comparações regionais e crescimento mês a mês”, o sistema entrega um painel já estruturado e pronto para refinamento.

O impacto no dia a dia de quem trabalha com dados

O que antes demandava horas de configuração manual agora pode ser concluído em minutos. Isso é especialmente relevante para equipes que precisam iterar rapidamente sobre análises ou que não têm um analista dedicado para montar cada painel do zero.

O resultado gerado é totalmente compatível com os fluxos de trabalho já existentes no Amazon Quick, incluindo publicação, incorporação em outras aplicações, pipelines de Integração Contínua/Entrega Contínua (CI/CD) e edição visual sem código.

Disponibilidade e acesso

No lançamento, o Generate Analysis está disponível para usuários com assinatura Enterprise ou plano Author Pro. Além disso, usuários Author têm acesso promocional à funcionalidade até dezembro de 2026 como parte do Amazon Quick Enterprise, desde que a organização não tenha restringido o acesso.

O recurso já está em disponibilidade geral (GA) em todas as regiões AWS onde o Amazon Quick está disponível.

Como começar

Para experimentar, basta abrir qualquer conjunto de dados no Amazon Quick e selecionar a opção Generate analysis. Para se aprofundar, a AWS disponibiliza documentação detalhada sobre como gerar uma análise com prompts em linguagem natural no Guia do Usuário do Amazon Quick.

Fonte

Amazon Quick generates dashboards from natural language prompts (https://aws.amazon.com/about-aws/whats-new/2026/05/amazon-quick-generates-analyses-from-natural-language-prompts/)