Blog

O gargalo que os agentes de IA ainda não resolviam

Agentes de observabilidade são rápidos: consultam alertas, correlacionam logs com traces e produzem uma hipótese de causa raiz em minutos. O problema sempre esteve na etapa seguinte — a verificação. O engenheiro lê o resumo textual gerado pelo agente, abre o navegador, faz login na ferramenta de observabilidade, navega até o trace waterfall, confere o mapa de serviços e compara manualmente o que o agente disse com o que está na tela.

O agente economizou o tempo de consulta. Mas não economizou o tempo gasto alternando abas, carregando contexto na memória e re-executando queries em outra ferramenta. Esse trabalho ainda era responsabilidade do humano.

A AWS anunciou os MCP Apps para o Amazon OpenSearch Service justamente para fechar essa lacuna.

O que são os MCP Apps

Os MCP Apps estendem o Protocolo de Contexto de Modelo (MCP) com um padrão de resposta dupla. Quando o agente de IA chama uma ferramenta MCP App, a resposta contém duas partes: um resumo textual estruturado e uma visualização interativa — como um trace waterfall, uma topologia de serviços ou uma visão de padrões de log — renderizada diretamente na janela de chat do assistente, ao lado da resposta em texto.

O resultado é direto: o engenheiro faz a pergunta ao agente, o agente consulta o Amazon OpenSearch Service e a resposta chega com texto explicativo e o widget de dashboard correspondente. A verificação acontece no mesmo thread onde a pergunta foi feita, sem abrir uma aba separada no navegador ou re-executar queries manualmente.

Como a arquitetura funciona

A solução envolve três componentes trabalhando em conjunto: um servidor MCP local, o ambiente de desenvolvimento (IDE) e a aplicação OpenSearch UI.

Um servidor MCP roda localmente na máquina do engenheiro. Ele atua como ponte segura entre o IDE e a aplicação OpenSearch UI, expondo ferramentas de observabilidade que o agente pode invocar. Cada chamada de ferramenta passa pelo servidor MCP até o endpoint do OpenSearch UI, executa a consulta e retorna a resposta dupla ao IDE.

O OpenSearch UI é a interface serverless de observabilidade unificada que funciona com domínios OpenSearch, coleções serverless, CloudWatch e Amazon Managed Service for Prometheus. O fluxo de uma requisição segue o caminho:

• O IDE ou cliente de IA (Claude, VS Code, Cursor, etc.) envia uma chamada de ferramenta
• O servidor MCP local recebe a chamada, autentica com as credenciais AWS configuradas e encaminha a requisição ao endpoint do OpenSearch UI como chamada HTTP
• O OpenSearch UI executa a consulta nas fontes de dados conectadas e retorna tanto o resumo textual estruturado quanto o artefato de visualização renderizado
• O servidor MCP empacota os dois em uma única resposta MCP; o IDE detecta o payload de visualização e o renderiza como widget interativo no thread da conversa

O controle permanece com a equipe: o servidor roda localmente, os dados ficam na conta AWS do cliente, e as credenciais e políticas são gerenciadas pela própria organização.

Por que os resultados são determinísticos

Um ponto importante destacado pela AWS é que o OpenSearch MCP App gera a visualização executando código diretamente contra as mesmas fontes de dados que alimentam os dashboards. Isso significa que o resultado renderizado é determinístico — não é uma interpretação do modelo de linguagem, mas o resultado real da query exibido como gráfico, trace waterfall ou mapa de serviços. O engenheiro está vendo o dado, não uma paráfrase dele.

Ferramentas disponíveis nos MCP Apps

O conjunto de ferramentas cobre toda a jornada de investigação de um incidente, organizadas em categorias que se encadeiam naturalmente.

Ferramentas principais de investigação

Uma investigação típica começa com as ferramentas de triagem e resposta, que surfaceiam alertas ativos, correlacionam alertas relacionados entre fontes de dados e apresentam distribuições de severidade para que o agente possa priorizar o problema. Depois de identificar o serviço afetado, as ferramentas de investigação de logs buscam padrões de erro e agrupam entradas similares para isolar a assinatura da falha. As ferramentas de investigação de traces localizam o trace distribuído específico, exibem a hierarquia de spans com o detalhamento de latência e identificam onde a falha se originou.

Ferramentas de contexto e visualização

Para quantificar o impacto, as ferramentas de investigação de métricas executam queries PromQL e realizam análise de limiar, enquanto as ferramentas de desempenho de serviço fornecem métricas RED — Taxa (Rate), Erros (Errors) e Duração (Duration) — no nível do serviço. As ferramentas de topologia renderizam o mapa de serviços como grafo de dependências, mostrando volume de chamadas e taxas de erro entre as arestas para dimensionar o impacto. As ferramentas de visualização dinâmica geram gráficos de linha, barra, área e métrica a partir de consultas especificadas, e as ferramentas de conjuntos de dados e correlações suportam junções entre sinais e resumos de dados.

Ferramentas especializadas

As ferramentas de observabilidade de IA e agentes rastreiam chamadas de Modelos de Linguagem de Grande Escala (LLM) e renderizam mapas de trace de agentes para equipes que estão construindo seus próprios fluxos de IA. As ferramentas de saúde do stack reportam status do cluster e alocação de shards. As ferramentas de pontuação de instrumentação detectam lacunas na qualidade da telemetria para que as equipes possam melhorar sua cobertura de observabilidade.

O ciclo de investigação com MCP Apps na prática

Com os MCP Apps, uma investigação de plantão passa a funcionar assim: o engenheiro pergunta ao agente “O que está causando o pico de erros no checkout?”. O agente investiga consultando logs, correlacionando com traces e verificando o mapa de serviços. A resposta dupla chega contendo texto e visualizações interativas — visão de alertas, trace waterfall e mapa de serviços — renderizadas no mesmo thread. O engenheiro revisa inline, seleciona detalhes de spans para confirmar o escopo do impacto e instrui o agente a redigir o resumo do incidente ou acionar uma remediação. O engenheiro nunca sai do IDE. Investigação, verificação e resolução acontecem em uma única conversa.

Como configurar o servidor MCP

A AWS documenta o processo de configuração em quatro etapas principais.

Pré-requisitos

Antes de começar, é necessário ter: uma aplicação OpenSearch UI com um workspace de Observabilidade conectado a pelo menos uma fonte de dados (domínios Amazon OpenSearch Service, coleções serverless ou Amazon Managed Service for Prometheus); um IDE compatível (Claude Desktop, VS Code GitHub Copilot, Goose, ChatGPT ou Cursor); Node.js 22 ou superior instalado localmente; e credenciais AWS configuradas com as permissões es:ESHttpGet e es:ESHttpPost.

Passo 1: Baixar e extrair o servidor MCP

Acesse a página de download do servidor MCP de observabilidade do OpenSearch, baixe o arquivo .zip e extraia o conteúdo. O diretório extraído contém um arquivo server/server.js. Anote o caminho completo para esse arquivo.

Passo 2: Adicionar o servidor MCP ao IDE

Cada IDE suportado possui um arquivo de configuração MCP. Abra a configuração do seu IDE e adicione o seguinte bloco:

{
  "mcpServers": {
    "opensearch-observability-stack-mcp": {
      "command": "node",
      "args": ["/path/to/opensearch-observability-stack-mcp/server/server.js"],
      "env": {
        "OS_UI_ENDPOINT": "application-foo-bar.us-west-2.opensearch.amazonaws.com",
        "AWS_REGION": "us-west-2",
        "AWS_PROFILE": "my-profile"
      }
    }
  }
}

Substitua os valores de exemplo pelo endpoint do seu OpenSearch UI, pela região AWS e pelo perfil configurado. Para encontrar o endpoint do OpenSearch UI, acesse o console do Amazon OpenSearch Service, vá em Applications, selecione sua aplicação OpenSearch UI e copie a URL da aplicação (por exemplo, application-abc123.us-west-2.opensearch.amazonaws.com).

Passo 3: Verificar a conexão

Após salvar a configuração, reinicie o IDE ou recarregue a lista de servidores MCP. Em seguida, insira o seguinte prompt no IDE:

List available observability data sources

Se o agente retornar as fontes de dados conectadas (domínios Amazon OpenSearch Service, coleções serverless ou workspaces do Amazon Managed Service for Prometheus), o servidor MCP está configurado corretamente. Em caso de erro, verifique se as credenciais AWS estão ativas e se a política do Gerenciamento de Identidade e Acesso (IAM) inclui as ações es:ESHttpGet e es:ESHttpPost para o ARN da aplicação OpenSearch UI.

Para testar sem dados de produção, a AWS sugere implantar a aplicação de demonstração OpenTelemetry para gerar traces, logs e métricas de exemplo no domínio Amazon OpenSearch Service.

Limpeza

Para remover a configuração, basta abrir as configurações MCP do IDE, excluir a entrada opensearch-observability-stack-mcp e deletar o diretório do servidor MCP extraído da máquina local. Essa configuração não provisiona recursos na nuvem, portanto não é necessária limpeza no lado AWS.

O que muda na prática

A diferença central pode ser resumida assim: sem os MCP Apps, o agente retorna texto e o engenheiro precisa abrir o navegador, fazer login, navegar e verificar manualmente em plataformas externas — um processo que pode levar minutos. Com os MCP Apps, o agente retorna texto junto com a visualização interativa para revisão inline, e a verificação é comprimida para segundos, no mesmo thread da conversa.

Além disso, sem os MCP Apps o agente raciocina apenas sobre seu próprio output. Com os MCP Apps, o agente também lê os resultados dos apps como contexto estruturado adicional, melhorando a qualidade do raciocínio nas etapas seguintes da investigação.

Conclusão

Com os MCP Apps, a AWS fecha a lacuna de verificação na observabilidade agêntica. O agente de IA investiga e a prova interativa chega no mesmo thread — sem troca de contexto, sem logins separados, sem re-execução de queries. Para engenheiros de plantão, isso pode significar resoluções mais rápidas. Para organizações que rodam observabilidade agêntica localmente, o recurso oferece a simplicidade operacional desejada sem abrir mão da precisão.

Para começar, consulte a documentação oficial: Observabilidade agêntica com MCP Apps no Guia do Desenvolvedor do Amazon OpenSearch Service.

Fonte

Agentic observability with Amazon OpenSearch Service MCP Apps (https://aws.amazon.com/blogs/machine-learning/agentic-observability-with-amazon-opensearch-service-mcp-apps/)

O problema que essa solução resolve

Preparar relatórios semanais de negócio ainda é uma tarefa manual e repetitiva na maioria das empresas. Times releem os mesmos documentos, reformatam métricas, copiam resumos para o Slack e, ao final, líderes precisam confiar que cada número e recomendação vem de uma fonte confiável. A AWS apresentou uma abordagem que conecta o Amazon Quick Desktop ao Amazon FSx for NetApp ONTAP para automatizar esse ciclo sem abrir mão da governança sobre os arquivos.

A proposta é direta: os documentos permanecem no sistema de armazenamento gerenciado que a equipe já utiliza, o acesso é controlado por permissões existentes, e o assistente de IA só enxerga o conteúdo que foi explicitamente aprovado para o fluxo de relatórios.

Visão geral da arquitetura

O fluxo de trabalho é composto por cinco elementos principais: o Amazon Quick Desktop, uma skill (habilidade personalizada) chamada Weekly Business Reporting Assistant, o Amazon FSx for NetApp ONTAP armazenando os documentos-fonte, um ponto de acesso do Serviço de Armazenamento Simples da Amazon (Amazon S3) controlando o acesso à pasta aprovada, e a integração com o Slack para distribuição revisada dos resumos.

Os arquivos de negócio ficam no FSx for ONTAP — revisões semanais, planos operacionais, resumos de forecast, registros de riscos e templates executivos. O ponto de acesso S3 expõe apenas a pasta aprovada para o Amazon Quick, que indexa esse conteúdo em uma base de conhecimento chamada Business Reporting Archive. A partir daí, usuários trabalham no Quick Desktop com a skill de relatórios para gerar artefatos citados e resumos para o Slack — todos sujeitos a revisão humana antes de serem compartilhados.

O Amazon Quick Desktop também constrói um grafo de conhecimento pessoal na visão “My context”, conectando pessoas, projetos, eventos, itens de ação e documentos de fontes conectadas. A Business Reporting Archive permanece como fonte governada para fatos e citações dos relatórios.

Pré-requisitos

Para implementar esse fluxo, a AWS lista os seguintes requisitos de infraestrutura e acesso:

• Conta AWS com acesso a uma região onde Amazon Quick, FSx for ONTAP e pontos de acesso S3 para FSx for ONTAP sejam suportados.
• Assinatura Amazon Quick Enterprise com permissões para criar integrações S3, bases de conhecimento e espaços.
• Aplicação Amazon Quick Desktop instalada para os usuários do fluxo de relatórios.
• Sistema de arquivos FSx for ONTAP rodando NetApp ONTAP 9.17.1 ou superior, com volume montado e junction path configurado (por exemplo, /business-reporting).
• Ponto de acesso S3 vinculado ao volume FSx for ONTAP, na mesma região e conta AWS.
• Permissões de Gerenciamento de Identidade e Acesso da AWS (IAM) para conceder ao Amazon Quick acesso de leitura com privilégio mínimo.
• Workspace do Slack com canal aprovado e permissões para configurar o conector de ação do Slack.

Implementação passo a passo

Passo 1: Preparar o conteúdo-fonte

A recomendação é começar com um escopo de pasta restrito para que os usuários possam verificar as citações contra um conjunto conhecido de arquivos. No volume FSx for ONTAP montado, cria-se ou escolhe-se uma pasta aprovada como /business-reporting, organizada em subpastas:

/business-reporting/
  weekly-reviews/
  operating-plans/
  forecasts/
  risk-registers/
  executive-templates/

Devem ser incluídas as últimas 8 a 12 revisões semanais, o plano operacional atual, o resumo de forecast vigente, o registro de riscos e o template padrão de relatório. Rascunhos, arquivos obsoletos e documentos restritos ficam fora dessa pasta antes da indexação.

Passo 2: Criar o ponto de acesso S3

Um ponto de acesso S3 é vinculado ao volume FSx for ONTAP para que o Amazon Quick possa ler o conteúdo aprovado por um caminho compatível com S3. No console do Amazon FSx, seleciona-se o volume montado, acessa-se a opção “Create S3 access point” e configura-se nome, usuário e configurações de rede conforme o modelo de governança da organização. O alias e o Nome de Recurso da Amazon (ARN) do ponto de acesso devem ser registrados — o alias é usado no URI S3 e o ARN nas políticas IAM.

Passo 3: Conceder acesso de leitura ao Amazon Quick

A política IAM deve conceder apenas as permissões necessárias para listar e ler o prefixo aprovado. A AWS disponibiliza o seguinte modelo como ponto de partida:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListApprovedReportingPrefix",
      "Effect": "Allow",
      "Action": ["s3:ListBucket", "s3:GetBucketLocation"],
      "Resource": "<access-point-arn>"
    },
    {
      "Sid": "ReadApprovedReportingObjects",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "<approved-prefix-object-arn>"
    }
  ]
}

Os placeholders devem ser substituídos pelos valores reais da região, ID de conta, nome do ponto de acesso e prefixo aprovado. A política é então vinculada à função de serviço que o Amazon Quick usa para a integração S3, garantindo que o acesso fique restrito ao prefixo de relatórios.

Passo 4: Criar a integração S3 e a base de conhecimento

No console do Amazon Quick, cria-se uma integração S3 apontando para o alias do ponto de acesso (por exemplo, s3:///amzn-s3-demo-business-reporting/). A base de conhecimento recebe o nome “FSx ONTAP Business Reports” e seleciona apenas o prefixo aprovado. Após a sincronização, cria-se um espaço chamado “Business Reporting Archive” e adiciona-se essa base de conhecimento ao espaço. Se os arquivos exigirem permissões por usuário ou grupo, as configurações de Lista de Controle de Acesso (ACL) em nível de documento devem ser definidas antes da criação da base de conhecimento.

Passo 5: Configurar o Slack

A integração com o Slack no Amazon Quick é configurada pelo console, usando os escopos mínimos necessários de OAuth (por exemplo, chat:write restrito ao canal aprovado). O canal aprovado — como #finance-weekly — deve ser documentado junto com a definição de quem pode aprovar mensagens antes do envio. A recomendação é testar com uma mensagem de rascunho em canal não produtivo antes de usar o Slack no fluxo real de relatórios.

Passo 6: Criar a skill de relatórios

Uma skill personalizada é criada no Amazon Quick Desktop para carregar o espaço Business Reporting Archive e aplicar as regras do fluxo de relatórios. A skill é ativada por uma frase de gatilho e fornece um assistente reutilizável. Para mais detalhes sobre criação de skills, a AWS disponibiliza a documentação de criação de skills do Amazon Quick.

A especificação da skill define o gatilho, as dependências, e um fluxo de trabalho em quatro etapas: carregar o contexto do espaço, apresentar uma saudação com exemplos de perguntas, responder perguntas com citações estruturadas, e gerar artefatos como relatórios, apresentações e resumos para o Slack. As regras de segurança da skill determinam que o assistente só pode referenciar conteúdo do arquivo aprovado, nunca fabricar métricas, e sempre citar documento, seção e data.

O fluxo de trabalho completo da skill inclui as seguintes instruções condensadas:

Save this as a skill
Skill: "Weekly Business Reporting Assistant"
Trigger: weekly business reviews, operating plans, financial reports, WBR summaries, trend analysis, business reporting deliverables from the Business Reporting Archive
Depends on: quick_suite__spaces
Workflow:
1. [Deterministic] Load Space Context --- search_spaces("Business Reporting Archive") -> list_space_documents(space_id) to get full document list. On failure: "I couldn't load the Business Reporting Archive. Please check that the space is connected and accessible."
2. [Agentic] Greet and Suggest --- Show greeting with 4 example questions: - Top 5 changes since last week's operating review - Risks repeating across last 4 WBRs - One-page weekly report (highlights, risks, action items, asks, key metrics, decisions needed) - Six-slide PowerPoint deck for leadership from latest review + operating plan
3. [Agentic] Answer Questions --- Use query_topic or search_relevant_content to find relevant content. Respond using structured format: Executive Summary -> Key Highlights -> Risks/Issues -> Action Items/Asks -> Sources (with doc names + dates cited).
4. [Agentic] Generate Deliverables (if requested) --- Reports structured as: business unit, period covered, key metrics/highlights, risks/blockers, mitigation plans, requests/escalations. Response tone: Professional business. Always cite specific document name, section, and date. Safety: Only reference content from the archive. Never fabricate metrics. State gaps clearly.
Lessons Learned:
- Always load space context before greeting
- Always cite doc name + date
- Don't extrapolate metrics not in source docs
- Ask user when period is ambiguous, business unit unclear, or audience/format not specified
- If a metric isn't tracked, name what IS available
Name the skill Weekly Business Reporting Assistant and set a trigger phrase, such as weekly business report.

Passo 7: Usar o Amazon Quick Desktop como ambiente de trabalho

Com a skill criada, o usuário inicia uma conversa no Quick Desktop com a frase de gatilho — por exemplo, “I need help with business reporting”. A skill carrega o espaço Business Reporting Archive e apresenta exemplos de perguntas. A partir daí, o usuário pode solicitar análises de mudanças semana a semana, identificação de riscos recorrentes, criação de relatórios de uma página, geração de apresentações em PowerPoint e rascunhos de resumos para o Slack. Cada resposta inclui citações de documentos específicos com datas, e o envio ao Slack exige aprovação explícita do usuário antes do envio.

Testes recomendados do fluxo

A AWS sugere validar o fluxo completo com prompts que representem o trabalho real de relatórios semanais. A tabela a seguir resume os cenários de teste e o que observar em cada resposta:

• Pesquisa: “What are the top five changes since the prior operating review?” — Espera-se um resumo citado com documentos-fonte e datas.
• Análise de riscos: “What risks repeat across the last four weekly business reviews?” — Riscos agrupados com citações e sugestão de responsáveis quando disponíveis na fonte.
• Criação de relatório: “Create a one-page weekly report with highlights, risks, action items, asks, key metrics, and decisions needed.” — Relatório estruturado com afirmações citadas e lista de fontes.
• Criação de apresentação: “Create a six-slide PowerPoint deck for leadership from the latest review and operating plan.” — Deck ou esboço com título, resumo, destaques, riscos, decisões e fontes.
• Distribuição no Slack: “Create a six-bullet Slack summary and ask me before posting.” — Mensagem preparada para aprovação antes do envio.

Boas práticas de segurança e governança

A AWS recomenda uma abordagem gradual ao migrar do fluxo de exemplo para um fluxo compartilhado de relatórios. Começar com uma pasta aprovada e expandir somente após os usuários validarem a qualidade das citações. As permissões dos arquivos-fonte devem estar alinhadas com o modelo de governança existente no FSx for ONTAP, e as permissões IAM devem seguir o princípio de privilégio mínimo para a função que o Amazon Quick usa para ler o ponto de acesso S3.

ACLs em nível de documento devem ser usadas na integração S3 quando a base de conhecimento exigir controles de acesso por usuário ou grupo. Um canal dedicado no Slack deve ser usado para resumos de relatórios, com definição clara de quem pode aprovar postagens — especialmente para materiais de conselho, conteúdo regulatório, comunicações com investidores ou relatórios financeiros sensíveis. Os arquivos indexados devem ser revisados periodicamente e conteúdo obsoleto removido da pasta aprovada.

Resolução de problemas comuns

• Amazon Quick não consegue ler o caminho-fonte: Verificar o alias do ponto de acesso S3, o requisito de mesma região, o escopo de recursos da política IAM e as permissões da função de serviço do Amazon Quick.
• Sincronização da base de conhecimento falha: Confirmar que o prefixo aprovado existe, o ponto de acesso está vinculado a um volume FSx for ONTAP montado e o sistema de arquivos roda NetApp ONTAP 9.17.1 ou superior.
• Respostas sem citações: Confirmar que o espaço Business Reporting Archive está conectado no Amazon Quick Desktop e que os arquivos da base de conhecimento sincronizaram com sucesso.
• Respostas referenciando arquivos antigos: Verificar o status de sincronização da base de conhecimento e remover arquivos obsoletos da pasta aprovada.
• Falha no envio ao Slack: Confirmar autorização do conector Slack, acesso ao canal, escopos necessários e se o conector foi publicado para o usuário ou grupo.

Limpeza de recursos

Para evitar cobranças futuras ou caminhos de acesso desnecessários, a AWS orienta remover apenas os recursos criados ou modificados durante a implementação: excluir a skill Weekly Business Reporting Assistant, deletar a base de conhecimento Business Reporting Archive se criada apenas para esse fluxo, remover a integração S3 do Amazon Quick se nenhuma outra base de conhecimento a utilizar, excluir o ponto de acesso S3 se criado exclusivamente para esse fluxo, remover as declarações de política IAM adicionadas e excluir arquivos de exemplo da pasta aprovada se usados apenas para testes.

Conclusão

Essa solução da AWS entrega um fluxo de relatórios semanais governado, onde artefatos de negócio citados são gerados a partir de arquivos armazenados no Amazon FSx for NetApp ONTAP. O ponto de acesso S3 expõe apenas a pasta aprovada, e o Amazon Quick indexa esse conteúdo pela integração S3. Times de negócio podem pesquisar questões de relatórios, gerar documentos e visuais, e preparar resumos para o Slack em um único ambiente — sem mover os arquivos-fonte para fora do fluxo de armazenamento gerenciado.

Para executivos e partes interessadas, o padrão aumenta a confiança nas atualizações recorrentes. Para quem implementa, mantém o escopo inicial estreito o suficiente para validar governança, acesso e qualidade dos relatórios. A recomendação é começar com uma pasta aprovada, um caso de uso de relatório e um canal de distribuição revisado — e expandir após os usuários confiarem nas citações e na qualidade dos resultados.

Recursos adicionais

• Guia do Usuário do Amazon Quick
• Amazon Quick no desktop
• Documentação de criação de skills do Amazon Quick
• Integração Amazon S3 no Amazon Quick
• Criação de documentos e visuais com Amazon Quick
• Integração com Slack no Amazon Quick
• Guia do Usuário do Amazon FSx for NetApp ONTAP
• Acessando dados do FSx for ONTAP com pontos de acesso S3
• Restrições e limitações de pontos de acesso para FSx for ONTAP

Fonte

Governed reports with Amazon Quick Desktop and Amazon FSx for NetApp ONTAP (https://aws.amazon.com/blogs/machine-learning/governed-reports-with-amazon-quick-desktop-and-amazon-fsx-for-netapp-ontap/)

O problema do conhecimento que some

Toda organização acumula, ao longo dos anos, um tipo de conhecimento que não está em nenhum manual: são os processos que “todo mundo sabe como funciona”, as decisões que dependem da experiência de alguém específico, os atalhos que só os veteranos conhecem. Esse conjunto é chamado de conhecimento tribal — e ele some quando as pessoas saem da empresa.

A AWS publicou uma solução detalhada para enfrentar exatamente esse desafio: um sistema de gestão do conhecimento institucional alimentado por IA, construído sobre serviços AWS e capaz de entregar informações por voz ou texto através de um avatar interativo. O objetivo é transformar documentos acumulados em uma fonte de consulta acessível para qualquer colaborador, mesmo os sem perfil técnico.

Para quem essa solução é indicada

A proposta atende organizações de diversos setores. Indústrias manufatureiras podem usar o sistema para preservar procedimentos de produção e protocolos de manutenção antes que técnicos experientes se aposentem. Hospitais, empresas financeiras, companhias de energia e órgãos governamentais também são casos de uso listados explicitamente.

Do ponto de vista dos usuários finais, o sistema foi desenhado para ser acessado de três formas:

• Via navegador desktop para pesquisas mais detalhadas
• Por interação de voz, ideal para operações com as mãos ocupadas
• Por consultas em texto para referências rápidas

Arquitetura da solução

A solução combina uma série de serviços AWS em uma arquitetura modular e escalável. A interface principal é baseada em navegador e suporta tanto texto quanto voz, conectando-se a um sistema de avatar configurável — o que dá às organizações a liberdade de escolher ou trocar a tecnologia de avatar conforme necessário.

Nos bastidores, o Amazon Cognito cuida do gerenciamento de acesso e autenticação. O Amazon API Gateway controla e monitora o acesso aos componentes do sistema. O núcleo de processamento usa o Amazon Bedrock Knowledge Bases para Geração Aumentada por Recuperação (RAG — Retrieval Augmented Generation) gerenciada: os documentos ficam armazenados no Amazon S3, e o Bedrock cuida do fatiamento, da geração de embeddings (usando o Amazon Titan Text Embeddings) e da recuperação das informações relevantes. O armazenamento vetorial é feito pelo Amazon OpenSearch Serverless.

O Amazon DynamoDB atua como camada de cache de respostas, e funções AWS Lambda orquestram todo o fluxo de trabalho.

Atenção ao custo fixo: o vetor store do Amazon OpenSearch Serverless é criado na conta do cliente e cobrado por Unidade de Computação OpenSearch (OCU — OpenSearch Compute Unit), com um mínimo sempre ativo, independente do volume de consultas. Esse custo fixo fica na ordem de algumas centenas de dólares por mês e é o maior componente de custo base da solução. O cache inteligente reduz os custos variáveis de inferência em cima desse valor.

Por que essa solução se diferencia

A AWS aponta três diferenciais principais em relação a outras abordagens disponíveis:

1. Interação por voz com avatar

Em vez de um chatbot de texto, o sistema usa um avatar com IA e interação por voz. O usuário fala com o avatar e recebe respostas faladas — como perguntaria a um colega. Isso elimina praticamente toda a curva de aprendizado para usuários não técnicos. Ambientes como salas de treinamento, laboratórios de qualidade, salas de controle e escritórios de planejamento de manutenção se beneficiam especialmente da operação sem as mãos.

2. Simplicidade para quem produz conteúdo

Gerenciar o conteúdo não exige nenhuma expertise técnica. Os responsáveis pelo conhecimento simplesmente fazem upload dos documentos existentes no Amazon S3 — Word, PDF, texto simples, Markdown ou JSON. A sincronização de ingestão fragmenta e gera os embeddings de cada documento automaticamente, tornando-o consultável em seguida. Não é necessário reestruturar conteúdo, adicionar metadados ou construir pipelines de recuperação manualmente.

3. Deploy rápido com otimização de custo embutida

O protótipo completo pode ser implantado em horas via AWS CloudFormation. O cache DynamoDB reutiliza respostas para perguntas repetidas, reduzindo o custo variável de inferência de IA. Nos testes realizados, taxas de acerto do cache entre 50% e 70% foram alcançadas em cargas de trabalho com muitas perguntas repetidas — o que é exatamente o perfil de sistemas de conhecimento institucional.

Comparação com alternativas

Construir uma solução customizada no Amazon Bedrock oferece controle total da arquitetura, mas exige projetar e integrar independentemente o processamento de voz, renderização de avatar, cache e pipelines de recuperação — um trabalho que tipicamente leva semanas ou meses e demanda expertise profunda em múltiplos serviços AWS.

Agentes de chat baseados em texto, como o Amazon Q e interfaces customizadas de chat com Bedrock, oferecem um caminho mais rápido para recuperação de conhecimento digitado. Esta solução adiciona interação por voz e engajamento via avatar, o que melhora a adoção entre trabalhadores de linha de frente que se beneficiam do acesso sem as mãos.

Jornada de implementação

A implementação é dividida em três fases:

Fase 1: Organização da base de conhecimento

O processo começa com a organização do conhecimento institucional. Os documentos são enviados para o repositório Amazon S3, e o Amazon Bedrock Knowledge Bases os ingere a partir daí. Se os documentos de origem estiverem em outros sistemas ou formatos, é possível adicionar um job AWS Glue de ETL (Extração, Transformação e Carga) para convertê-los em um formato otimizado para IA antes do upload. Esse passo de ETL é uma integração opcional e separada — não é criado pelo deploy do CloudFormation.

Os formatos suportados são: Word, PDF, texto simples, Markdown e JSON. Para melhor desempenho de recuperação pela IA, os formatos recomendados são Markdown (.md) ou JSON estruturado. Para mais detalhes sobre transformação de dados com AWS Glue, consulte a documentação de ETL do AWS Glue.

Fase 2: Deploy da infraestrutura

O deploy central é feito via templates AWS CloudFormation, garantindo implantações consistentes e repetíveis. Essa fase inclui:

• Configuração do Amazon Cognito para autenticação e controle de acesso
• Configuração dos endpoints do API Gateway para comunicação entre componentes
• Criação dos repositórios S3 para armazenamento do conhecimento
• Implementação do DynamoDB para cache de respostas

Fase 3: Integração da IA

A fase final integra as capacidades de IA e o pipeline de processamento:

• Configuração do Amazon Bedrock para processamento do conhecimento e compreensão de consultas
• Configuração das funções Lambda para orquestração de requisições e tratamento de respostas
• Pipeline de processamento de áudio: Amazon Transcribe para converter voz em texto, e Amazon Polly para converter respostas em fala natural
• Integração do sistema de avatar para interações humanizadas

Modelos de fundação utilizados

A solução usa o Amazon Titan Text Embeddings (amazon.titan-embed-text-v1) para gerar os embeddings dos documentos no vetor store. Para geração de respostas, os modelos disponíveis são o Amazon Nova Pro (amazon.nova-pro-v1:0) e o Anthropic Claude 3 Sonnet (anthropic.claude-3-sonnet-20240229-v1:0).

O Amazon Bedrock oferece acesso automático aos modelos serverless da Amazon, então o Nova Pro e o Titan Text Embeddings estão disponíveis por padrão. Já os modelos Anthropic Claude não têm acesso automático em todas as regiões: antes da primeira requisição, é necessário completar o pedido de acesso ao modelo na console do Amazon Bedrock. Para mais informações, veja como o Amazon Bedrock fornece acesso automático a modelos de fundação serverless.

Passos para o deploy

A solução foi testada na região us-east-1, escolhida por ter a maior disponibilidade dos modelos de fundação e do streaming de avatar. Se o deploy for feito em outra região, é necessário confirmar a disponibilidade dos modelos e do provedor de avatar, e atualizar a região no código-fonte antes de começar.

O código-fonte da aplicação está disponível para clonagem no repositório público no GitHub. A aplicação fica na pasta bedkbauto/, nas subpastas src e web.

Em linhas gerais, o fluxo de deploy é:

• Criar um bucket S3 e fazer upload das pastas src e web
• Copiar a URL do arquivo setup.json na pasta src
• Acessar o console do CloudFormation e criar uma nova stack usando a URL do template
• Informar os parâmetros: nome da stack, e-mail (que receberá a senha temporária), nome de usuário e nome do bucket S3 criado
• Após a criação da stack, acessar a aba Outputs para obter a URL do frontend

O deploy requer conhecimento básico de navegação no Console AWS, entendimento de infraestrutura como código e familiaridade com gerenciamento de identidades — apenas para a equipe de TI ou DevOps na configuração inicial. Os usuários finais não precisam de nenhuma habilidade técnica.

Performance, escalabilidade e limitações

A arquitetura serverless escala horizontalmente de forma automática. Nos testes realizados, a configuração padrão suportou cerca de 50 a 100 usuários simultâneos com respostas em menos de um segundo para consultas em cache. Com aumento das cotas de serviço, a estimativa chega a 500–1.000 usuários simultâneos. Para uso enterprise acima de 5.000 usuários simultâneos, a mesma arquitetura funciona, mas exige solicitação proativa de aumento de cotas.

Respostas em cache retornam em menos de um segundo. Consultas novas à base de conhecimento levam cerca de 2 a 4 segundos, dependendo do modelo e do tamanho dos documentos. A interação por voz adiciona o tempo de processamento de fala.

Limitação importante: este é um design dependente de conectividade de nuvem. Cada consulta faz uma ida e volta até a AWS, e o avatar depende de streaming WebRTC/WebSocket em tempo real. Não há modo offline, operação em borda ou degradação gradual neste protótipo. Ele se encaixa em ambientes conectados (salas de treinamento, escritórios de engenharia, laboratórios, salas de controle, estações kiosk) — não em ambientes de chão de fábrica desconectados ou com conectividade intermitente.

Otimização de custos com cache inteligente

O cache DynamoDB é o principal mecanismo de redução de custos variáveis: perguntas já respondidas não acionam uma nova chamada ao modelo de fundação. Nos testes, para cargas onde 50–70% das perguntas eram repetidas, o custo de inferência caiu proporcionalmente. Esse ganho variável se soma ao custo fixo do OpenSearch Serverless — portanto, o planejamento de orçamento deve considerar ambos.

O cache atual faz correspondência exata do texto da consulta. Correspondência semântica baseada em embeddings seria uma melhoria natural, mas não está incluída neste protótipo.

Manutenção e evolução do sistema

O sistema foi projetado para crescer com a organização. O Amazon S3 é configurado com notificações de eventos: quando um documento é adicionado ou removido, uma função Lambda é acionada automaticamente para iniciar um job de ingestão no Bedrock Knowledge Bases, re-gerando os embeddings sem nenhuma intervenção manual. O conteúdo atualizado fica disponível para consulta logo após a conclusão dessa sincronização.

As respostas são geradas com base nos documentos verificados da organização, não no conhecimento geral de treinamento do modelo — o que reduz (mas não elimina) o risco de respostas incorretas. Para decisões de alta consequência ou segurança crítica, a recomendação é manter um humano no processo e tratar o sistema como suporte à decisão, não como fonte autoritativa.

Conclusão

A solução apresentada pela AWS endereça um problema real e custoso para organizações: o conhecimento institucional que se perde com a saída de colaboradores experientes. Ao combinar Amazon Bedrock, avatar interativo, processamento de voz e cache inteligente em uma arquitetura deployável em horas, a proposta reduz significativamente a barreira de entrada para organizações que precisam preservar e democratizar esse conhecimento.

Para quem quiser explorar na prática, o código está disponível no repositório de exemplo no GitHub para deploy em conta AWS própria.

Fonte

Democratizing institutional knowledge: Building an AI-powered knowledge management system with AWS (https://aws.amazon.com/blogs/machine-learning/democratizing-institutional-knowledge-building-an-ai-powered-knowledge-management-system-with-aws/)

Ray e HyperPod: uma integração que simplifica o trabalho com IA distribuída

A AWS anunciou novas capacidades do Ray no Amazon SageMaker HyperPod, integrando o framework open-source diretamente com a infraestrutura especializada para treinamento e serving de modelos de fundação. O Ray é um framework open-source amplamente utilizado por cientistas de dados para escalar workloads Python distribuídos em clusters de GPUs — do treinamento distribuído com Ray Train ao serving de modelos com Ray Serve.

No Kubernetes, clusters Ray são gerenciados pelo KubeRay, um operador open-source que cuida do ciclo de vida dos clusters por meio de recursos customizados (RayCluster, RayJob, RayService). O SageMaker HyperPod, por sua vez, oferece infraestrutura otimizada para aprendizado de máquina (ML) em larga escala no Amazon Elastic Kubernetes Service (EKS), com monitoramento de saúde dos nós e recuperação automática integrados.

Antes dessa integração, rodar Ray no Kubernetes exigia que cientistas de dados escrevessem manifestos YAML, gerenciassem rebuilds de imagens Docker a cada mudança de dependência, configurassem kubectl port-forward para acessar o Ray Dashboard e instalassem Prometheus e Grafana manualmente para observabilidade. Com o novo lançamento, tudo isso passa a ser gerenciado diretamente pelo SageMaker Studio.

O que muda na prática

A partir de agora, cientistas de dados conseguem, dentro do SageMaker Studio: criar e gerenciar clusters Ray, abrir o Ray Dashboard e dashboards de observabilidade no Amazon Managed Grafana, conectar workspaces JupyterLab ou Code Editor ao cluster, submeter jobs distribuídos e configurar detecção de jobs travados (hung job detection).

No nível de aplicação, os jobs de treinamento Ray ganham tolerância automática a falhas por meio do monitoramento de saúde dos nós do HyperPod, além de checkpointing em camadas para retomada mais rápida. A integração com o SageMaker JumpStart permite carregar pesos de modelos diretamente em endpoints Ray Serve, com offloading de KV cache para armazenamento em camadas no serving de requisições com contexto longo. Tudo isso funciona com o KubeRay open-source e as APIs padrão do Ray — scripts e workflows existentes rodam sem modificação.

Pré-requisitos

Para usar essas capacidades, é necessário ter um cluster Amazon SageMaker HyperPod com orquestração Amazon EKS com os seguintes componentes instalados:

• SageMaker Spaces EKS add-on: habilita workspaces JupyterLab e Code Editor no HyperPod que se conectam a clusters Ray para desenvolvimento interativo.
• HyperPod Observability EKS add-on: coleta métricas de workloads Ray e provisiona dashboards Grafana no Amazon Managed Grafana.
• KubeRay operator: gerencia RayCluster, RayJob e RayService como recursos nativos do Kubernetes.
• HyperPod Ray Endpoint Operator (Helm chart): gera endpoints públicos autenticados para acesso ao dashboard e submissão remota de jobs.

Também é necessário um domínio SageMaker Studio, que fornece a interface de console para criar clusters Ray, visualizar workloads, abrir dashboards e gerenciar HyperPod Spaces. Para instruções completas de configuração, consulte o guia de introdução ao Ray no HyperPod.

Experiência no SageMaker Studio

O SageMaker Studio agora oferece um ambiente completo de desenvolvimento Ray. Cientistas de dados podem criar, gerenciar e monitorar clusters Ray diretamente pelo console, sem escrever manifestos Kubernetes ou executar comandos kubectl. É possível conferir a experiência completa neste demo interativo.

Para criar um cluster, basta acessar o HyperPod no Studio, selecionar o cluster, ir até a aba Tasks e escolher o tipo RayCluster. O formulário de criação solicita nome do cluster, tipos de instância para o nó principal (head) e workers, quantidade de workers e imagem de container. Por padrão, os clusters utilizam a imagem SageMaker Distribution, que já vem com Ray instalado e é mantida pela AWS com atualizações regulares de segurança. É possível também especificar uma imagem customizada para workloads com dependências adicionais.

Para quem prefere kubectl ou precisa de customizações avançadas, um editor YAML inline no Studio expõe o manifesto Kubernetes completo. O operador KubeRay também se integra ao HyperPod task governance, permitindo que administradores definam cotas de computação e prioridades de agendamento para workloads Ray junto com outros jobs de treinamento.

Durante a criação, é recomendável habilitar os endpoints remotos para acessar o Ray Dashboard, submeter jobs e recuperar logs de qualquer lugar com acesso à internet, de forma segura e sem necessidade de kubectl port-forward local. Saiba mais em acesso ao Ray Dashboard.

Submissão remota de jobs

Para workloads de produção, é possível submeter jobs remotamente para clusters Ray a partir do Studio, do laptop ou de pipelines de Integração Contínua e Entrega Contínua (CI/CD), usando o pacote Python toolkit-for-ray-on-sagemaker-ai. O pacote cuida da resolução de endpoints e geração de credenciais para a API do EKS via autenticação IAM, permitindo o uso das APIs padrão de submissão de jobs do Ray com um resolvedor de endereços compatível com o SageMaker:

$ aws eks update-kubeconfig --name <eks-cluster-name> --region <region>
$ pip install toolkit-for-ray-on-sagemaker-ai
$ ray job submit --address sagemaker_ray://<ray-cluster-name>/<namespace> \
    --working-dir <your-code-directory> \
    --python your-code.py
# To list ray jobs
$ ray job list --address sagemaker_ray://<ray-cluster-name>/<namespace>

Desenvolvimento interativo com SageMaker Spaces

Cientistas de dados podem conectar um cluster Ray a um espaço HyperPod JupyterLab ou Code Editor diretamente pelo Studio. O espaço entra no cluster como um nó worker de zero-computação, dando ao notebook acesso nativo completo como Ray driver. O cluster é selecionado em uma lista durante a criação do espaço.

Após criar o espaço e conectá-lo ao cluster Ray, basta abrir o JupyterLab ou Code Editor no navegador e chamar ray.init(address="auto") para estar conectado ao cluster e executar workloads distribuídos como se estivesse no nó principal.

O parâmetro runtime_env do Ray permite injetar dependências Python em tempo de execução, sem precisar reconstruir imagens de container. Workers podem ser escalados para cima ou para baixo sem recriar o cluster. Por exemplo, um cientista de dados pode começar prototipando em um notebook com um único worker e depois escalar para quatro workers GPU alterando apenas uma linha no ScalingConfig. O treinamento roda de forma distribuída no cluster Ray enquanto o notebook permanece interativo para monitoramento de progresso, ajuste de hiperparâmetros ou inspeção de resultados intermediários. Saiba mais em IDEs e Notebooks com Ray.

Observabilidade pronta para uso

Configurar observabilidade do Ray no Kubernetes com Amazon Managed Service for Prometheus e Amazon Managed Grafana era um processo de múltiplas etapas: instalar Helm charts, criar PodMonitors e ServiceMonitors, configurar roles IAM para assinatura SigV4 e importar arquivos JSON de dashboards manualmente.

O HyperPod Observability EKS add-on agora cuida de tudo isso automaticamente. Ele descobre os pods do nó principal e workers do Ray, coleta suas métricas e provisiona quatro dashboards Grafana pré-construídos no Amazon Managed Grafana: Ray Core, Ray Data, Ray Train e Ray Serve — todos organizados em uma pasta Ray e com suporte a filtragem por cluster específico. Os dashboards aparecem junto com os dashboards de infraestrutura do HyperPod (GPU, EFA, task governance), centralizando métricas de workloads Ray e saúde do cluster em um único lugar.

Treinamento resiliente

O SageMaker HyperPod oferece três camadas de resiliência para workloads de treinamento Ray: recuperação automática de nós em caso de falha de hardware, detecção de jobs travados quando o treinamento para de progredir, e checkpointing em camadas para recuperação rápida em ambos os cenários.

Recuperação automática de nós

O SageMaker HyperPod monitora continuamente a saúde dos nós e pode substituir nós com falha automaticamente, permitindo que jobs de treinamento Ray rodem pelo tempo necessário sem reinicializações manuais. Quando um nó é substituído, o Ray reagenda os pods worker no novo nó saudável. Se o código de treinamento salva checkpoints periodicamente e inclui lógica para retomar do último checkpoint, o job continua de onde parou — sem nenhuma alteração no código existente. Basta configurar um número suficiente de tentativas no FailureConfig do RayJob para que os jobs se recuperem automaticamente. Saiba mais em recuperação automática de nós com Ray.

Detecção de jobs travados

Jobs de treinamento distribuído podem travar sem gerar erros. Um único pod falha — por partição de rede, problema de montagem de armazenamento ou falha de hardware — e todos os outros pods ficam bloqueados na próxima operação coletiva, aguardando indefinidamente. As GPUs permanecem alocadas com memória carregada, mas sem produzir computação útil. Como não há mensagem de erro ou crash, cientistas de dados frequentemente descobrem o problema horas depois ao verificar o progresso manualmente. Em escala, algumas horas de tempo travado não detectado em dezenas de GPUs representam custo desperdiçado significativo.

O SageMaker HyperPod EKS inclui agora um Job Monitoring Agent por nó que detecta essas condições automaticamente para workloads Ray Train, sem alterações no código. O agente monitora múltiplos sinais em nível de nó e de job para determinar quando um job travou, notificando o usuário pelo grupo de logs do Amazon CloudWatch do cluster e pelo dashboard Ray Train Grafana provisionado pelo HyperPod Observability add-on. Para regras de detecção customizadas, é possível usar a biblioteca toolkit-for-ray-on-sagemaker-ai para definir padrões de log e limites de timeout. Quando a ação configurada é cancel, o HyperPod encerra o processo worker travado e o FailureConfig integrado do Ray Train reinicia os workers a partir do último checkpoint. Saiba mais em HyperPod Hung Job Detection no Ray.

Checkpointing em camadas

A biblioteca amzn-sagemaker-checkpointing se integra ao checkpointing em camadas gerenciado pelo HyperPod, que grava checkpoints em disco local e os envia de forma assíncrona para o Amazon Simple Storage Service (S3). Quando um job é reiniciado, a biblioteca verifica primeiro o HyperPod Tiered Storage. Se o checkpoint ainda estiver disponível lá, a recuperação é mais rápida do que restaurar diretamente do S3. Para modelos grandes, isso pode reduzir significativamente o tempo de recuperação. Saiba mais em HyperPod Tiered Storage no Ray.

Inferência acelerada

O Ray Serve é o framework do Ray para implantar modelos de ML como endpoints escaláveis e prontos para produção, com suporte a composição de múltiplos modelos, autoscaling e engines de serving como vLLM. O SageMaker HyperPod suporta workloads Ray Serve no EKS, permitindo implantar e escalar endpoints de inferência no cluster HyperPod.

O SageMaker JumpStart oferece um catálogo de modelos pré-treinados. Com esse lançamento, a biblioteca toolkit-for-ray-on-sagemaker-ai passa a incluir um JumpStart model loader que baixa pesos de modelos do catálogo JumpStart e os implanta diretamente no Ray Serve no HyperPod — sem download manual de pesos, configuração de modelo ou setup de container.

Um desafio comum no serving de Modelos de Linguagem de Grande Escala (LLMs) é que a latência de inferência cresce com o comprimento do contexto. Cada novo token exige recalcular a atenção sobre todos os tokens anteriores, tornando documentos longos e conversas multi-turno lentos e custosos. O SageMaker HyperPod endereça isso com o Managed Tiered KV Cache. O cache em camadas armazena vetores de chave-valor de atenção na memória CPU de cada nó (L1) e no HyperPod Tiered Storage para compartilhamento entre instâncias (L2). Os deployments Ray Serve podem aproveitar essas capacidades com mudanças mínimas de código, reduzindo o tempo até o primeiro token em conversas multi-turno e workloads de documentos longos. Saiba mais em Inferência Ray Acelerada no SageMaker HyperPod.

Limpeza dos recursos

Para liberar capacidade de computação no cluster, basta excluir os clusters Ray criados durante os testes pela aba Tasks do SageMaker Studio. Se um cluster HyperPod foi criado, é possível excluir o cluster pelo console do Amazon SageMaker AI para evitar cobranças pelas instâncias de computação subjacentes. Os add-ons de pré-requisito instalados para testes podem ser desinstalados pelo console do EKS para liberar capacidade de computação.

Disponibilidade

Essa integração está disponível hoje em todas as regiões AWS onde o SageMaker HyperPod EKS é suportado. Tudo funciona com o KubeRay open-source e as APIs padrão do Ray, sem necessidade de modificar scripts existentes. Para começar, consulte a documentação do Amazon SageMaker HyperPod e o guia de introdução ao Ray no HyperPod. É possível também explorar o fluxo completo neste demo interativo. Para discutir como o Ray no HyperPod pode suportar seus workloads, entre em contato com um representante AWS.

Fonte

Introducing new Ray capabilities on SageMaker HyperPod (https://aws.amazon.com/blogs/machine-learning/introducing-new-ray-capabilities-on-sagemaker-hyperpod/)

O problema que ninguém estava resolvendo direito

À medida que as organizações ampliam o uso de agentes de Inteligência Artificial (IA), um gargalo silencioso vai se formando: encontrar o recurso certo na hora certa. Times criam servidores MCP (Model Context Protocol), implantam agentes e desenvolvem ferramentas especializadas — mas sem um catálogo centralizado, esses recursos ficam isolados em silos.

O resultado prático? Cada desenvolvedor precisa localizar manualmente o recurso, validá-lo, conectá-lo e manter essa conexão por conta própria. Pior ainda: configurar um agente para um cliente de IA não o torna disponível para outros clientes. Quando a equipe tinha apenas um punhado de ferramentas, isso era administrável. Com dezenas de agentes, servidores MCP, habilidades e APIs espalhados por registros públicos e ambientes corporativos privados, esse modelo simplesmente não escala.

AWS Agent Registry: o catálogo centralizado

Para endereçar esse problema dentro do ecossistema AWS, a empresa lançou o AWS Agent Registry — um catálogo centralizado e pesquisável para agentes, servidores MCP, ferramentas, habilidades de agentes e recursos personalizados. O serviço é construído em torno de dois conceitos centrais:

• Registros (Registries): um registro é um catálogo criado dentro de uma conta AWS, com suas próprias configurações de autorização e aprovação. É possível manter um único registro para toda a organização ou criar registros separados por tipo de recurso, ambiente ou equipe. Com o compartilhamento entre contas, um registro pode atender toda a organização AWS.
• Registros de Recursos (Registry Records): um record representa um recurso individual, capturando os metadados que descrevem o que ele é, o que faz e como acessá-lo.

Como funciona o fluxo de trabalho

O processo dentro do AWS Agent Registry segue uma lógica clara de quatro etapas:

• Criar um registro: um administrador cria o registro, configura as regras de aprovação e define a autorização usando o IAM (Identity and Access Management) da AWS ou um JWT (JSON Web Token) do provedor de identidade corporativo.
• Publicar registros: um publicador descreve seus servidores MCP, agentes ou ferramentas como records e os submete para aprovação.
• Curar e aprovar: um curador revisa os registros pendentes, aprova ou rejeita cada um, e pode deprecar registros que não estão mais em uso.
• Descobrir recursos aprovados: consumidores — sejam usuários humanos ou agentes de IA — pesquisam o registro para encontrar os recursos de que precisam.

O que torna o serviço adequado para ambientes corporativos

Alguns diferenciais do AWS Agent Registry merecem destaque para quem avalia adoção empresarial:

• Curadoria com fluxo de aprovação: garante que apenas recursos que atendem aos critérios de segurança, conformidade e qualidade da organização sejam descobertos. Administradores podem remover um registro a qualquer momento.
• Busca híbrida: combina compreensão semântica com correspondência por palavras-chave, de modo que tanto consultas em linguagem natural quanto buscas exatas por nome retornem resultados relevantes.
• Acesso nativo ao MCP: o registro está disponível em um endpoint remoto MCP, permitindo que qualquer cliente compatível com MCP pesquise e utilize recursos diretamente.
• Autorização flexível: controle de acesso via credenciais IAM ou JWTs do provedor de identidade corporativo.

O desafio dos múltiplos ambientes

O AWS Agent Registry resolve bem o problema de descoberta dentro do ambiente AWS. Mas a realidade das grandes empresas é outra: agentes e ferramentas estão implantados em múltiplas nuvens, infraestrutura on-premises, plataformas SaaS e aplicações corporativas — cada uma com seu próprio registro, convenção de nomenclatura e esquema de metadados.

Quando cada ambiente usa seu próprio formato para descrever recursos agênticos, integrar tudo exige conectores sob medida para cada par de registros que precisa interoperar. Uma especificação compartilhada muda esse cenário: se todos os registros descrevem recursos no mesmo formato e expõem a descoberta por um protocolo comum, o publicador descreve uma vez e o consumidor descobre em qualquer lugar.

ARD: a especificação aberta que entra em cena

É aqui que entra o ARD (Agentic Resource Discovery). Importante deixar claro: o ARD não é um produto e nem um registro único. É um padrão aberto, disponível sob a Licença Apache 2.0 em agenticresourcediscovery.org e no GitHub. A AWS contribuiu com feedback durante o desenvolvimento da especificação.

Uma boa analogia para entender o ARD é pensar no DNS (Domain Name System — Sistema de Nomes de Domínio): assim como o DNS permite a resolução de nomes entre redes distintas, o ARD habilita a federação entre registros distintos. Uma organização pode implantar agentes em múltiplos ambientes e o catálogo de cada ambiente expõe esses recursos por um protocolo comum, atrás de um endpoint. Para descoberta combinada, qualquer registro pode indexar os demais usando o entendimento desse protocolo compartilhado. Assim, registros locais podem se federar via ARD sem exigir acordos bilaterais ou conectores proprietários.

Como o ARD complementa o AWS Agent Registry

A AWS posiciona o ARD como um complemento natural ao modelo do AWS Agent Registry. Três perspectivas resumem bem essa relação:

• Federar sem migrar: organizações com infraestrutura agêntica distribuída entre nuvens, ambientes on-premises e SaaS podem expor esses recursos em um formato consistente. O ARD deve viabilizar a descoberta entre ambientes mantendo o controle local.
• Descobrir globalmente, controlar localmente: o design do ARD reflete o modelo de controle que os clientes AWS já conhecem — a organização que publica um catálogo controla o que está nele, quem pode ver e quando revogar o acesso. Os controles de acesso existentes do AWS Agent Registry permanecem como ponto de aplicação, com o ARD atuando como camada de interoperabilidade.
• Habilitar descoberta pública: com o ARD como protocolo compartilhado, qualquer organização pode publicar um catálogo em seu próprio domínio, tornando-o descobrível por qualquer cliente compatível com ARD — abrindo caminhos de descoberta entre organizações para clientes do Agent Registry.

Para saber mais

Para quem quer se aprofundar no tema, a AWS disponibiliza os seguintes recursos:

• Leia a especificação ARD para entender o modelo de catálogo e registro.
• Explore as implementações de referência no GitHub.
• Consulte a documentação do AWS Agent Registry.
• Leia mais sobre o lançamento em AWS Agent Registry agora em preview.

Fonte

Agentic Resource Discovery (ARD): An open specification for agent discovery (https://aws.amazon.com/blogs/machine-learning/agentic-resource-discovery-ard-an-open-specification-for-agent-discovery/)

O problema: pedidos por telefone ainda dominam em restaurantes

Em muitos restaurantes, uma fatia expressiva dos pedidos ainda chega por telefone. O problema é que essas ligações geralmente caem no colo de um funcionário que já está atendendo clientes no balcão. O resultado é previsível: cliente esperando na linha, pedido anotado à mão e o caos se intensificando nos horários de pico.

Criar um app ou site resolve para quem prefere pedir online, mas não ajuda em nada quem quer simplesmente ligar. A AWS publicou um guia técnico mostrando como resolver exatamente esse problema: um sistema de pedidos por voz que atende a ligação e conduz o pedido do início ao fim, sem app, sem site e sem login.

Como a solução funciona

O cliente liga para um número de telefone. Um atendente de IA cumprimenta, responde perguntas sobre o cardápio, encontra a unidade de retirada mais próxima e confirma o pedido em voz alta. Tudo por telefone, sem nenhuma etapa digital adicional.

A arquitetura usa três serviços principais trabalhando juntos:

• Amazon Connect para o canal de telefonia
• Amazon Lex V2 com Amazon Connect Agentic Voice para reconhecimento e síntese de voz em tempo real
• Amazon Connect AI Agents para orquestrar a conversa, conectado ao backend do restaurante via Protocolo de Contexto de Modelo (MCP) e Amazon Bedrock AgentCore

O design mantém três responsabilidades bem separadas: o Amazon Connect cuida da ligação, o agente de IA conduz a conversa e o backend armazena cardápio, carrinho, pedidos e localizações. Essa separação é intencional — o backend pode mudar sem que seja necessário mexer no agente.

Componentes implantados pela solução

A solução completa é implantada via Kit de Desenvolvimento em Nuvem da AWS (AWS CDK) em oito stacks. Os principais componentes são:

• Amazon Connect: fornece a telefonia de entrada, o fluxo de contato e o número de telefone que recebe as ligações.
• Amazon Lex V2: hospeda o bot de voz que o fluxo de contato conecta ao chamador, usando o Agentic Voice para fala e roteando cada turno ao agente de IA.
• Amazon Connect Agentic Voice: oferece Reconhecimento Automático de Fala Avançado (Advanced ASR) com detecção de fim de turno baseada em confiança, além de síntese de voz (TTS) expressiva, tudo nativamente no Amazon Connect.
• Amazon Connect AI Agents: o agente de orquestração alimentado pelo Anthropic Claude Haiku 4.5 no Amazon Bedrock.
• Amazon Connect AI Guardrails: mantém a conversa segura e dentro do tema com filtros de conteúdo, tópicos negados e filtragem de linguagem inapropriada.
• AgentCore Gateway: expõe as APIs do backend como ferramentas MCP que o agente pode descobrir e chamar pelo nome.
• Amazon AppIntegrations: registra o AgentCore Gateway como uma aplicação MCP que o agente de IA pode usar.
• Amazon API Gateway: expõe o backend com endpoints REST protegidos por Gerenciamento de Identidade e Acesso da AWS (IAM).
• AWS Lambda: executa a lógica de negócio para cardápios, carrinhos, pedidos e buscas de localização.
• Amazon DynamoDB: armazena perfis de clientes, pedidos, itens do cardápio, carrinhos e localizações.
• Amazon Location Service: fornece geocodificação e cálculo de rotas para recomendações de retirada.

O fluxo de uma ligação de ponta a ponta

Quando o cliente liga, o Amazon Connect atende e um fluxo de contato entra em ação. Esse fluxo executa uma sequência curta de passos: habilita o registro no Amazon CloudWatch, define a voz Agentic Voice para a chamada, captura o número de telefone do chamador e abre uma sessão do agente de IA. Em seguida, uma função Lambda injeta o número de telefone nessa sessão — assim o agente já sabe quem está ligando sem precisar perguntar. Por fim, o fluxo reproduz uma saudação e conecta o chamador ao bot do Amazon Lex V2, que assume o controle da conversa usando o Agentic Voice para ouvir e falar.

Quando o agente de IA termina, o bot devolve o controle ao fluxo de contato, que lê o resultado e encerra a chamada. O agente sinaliza o fim com um de dois resultados: Concluído, para um pedido finalizado, ou Escalonar, quando o chamador pede para falar com uma pessoa. Nessa solução ambos os resultados encerram a chamada, mas como tudo vive dentro do Amazon Connect, é possível configurar o caminho de escalonamento para transferir o chamador para um atendente humano com o contexto completo da conversa.

Reconhecimento de voz e naturalidade na conversa

O Amazon Connect Agentic Voice cuida da camada de fala nativamente dentro do Amazon Connect. Seu Advanced ASR reconhece fala com diferentes sotaques e tolera o ruído de fundo típico de uma linha telefônica. A detecção de fim de turno baseada em confiança identifica quando o chamador terminou de falar, em vez de aguardar um silêncio fixo — isso encurta a pausa entre o fim da fala do cliente e a resposta do agente, tornando a conversa mais natural. O chamador também pode interromper o agente, como acontece em ligações reais.

O agente de IA, alimentado pelo Anthropic Claude Haiku 4.5, tem um prompt de sistema escrito para voz: respostas curtas, preços falados de forma natural (como “cinco reais e noventa e nove”) e sem leitura de IDs internos. O agente cumprimenta, responde dúvidas sobre o cardápio, resolve a localização de retirada, monta o carrinho, lê o resumo para confirmação e registra o pedido.

Os limiares de confiança de fim de turno e de silêncio podem ser ajustados por intenção, para casos como a leitura de um número de cartão ou um endereço. A AWS disponibiliza um guia de boas práticas do Agentic Voice para esses ajustes.

Conectando o agente ao backend via MCP

O agente de IA nunca chama as funções Lambda do backend diretamente. O AgentCore Gateway fica no meio e apresenta os endpoints do backend como ferramentas MCP que o agente descobre e chama pelo nome — consultas ao cardápio, operações de carrinho, registro de pedido, histórico do cliente, geocodificação e busca de localização.

O gateway é registrado no assistente Amazon Connect AI Agents como uma aplicação MCP via Amazon AppIntegrations, e autoriza cada chamada com um Token Web JSON (JWT) validado contra a instância do Amazon Connect. Quando o agente chama uma ferramenta como PlaceOrder, o gateway transforma isso em uma requisição REST para o Amazon API Gateway, que roteia para a função Lambda correspondente.

Como o agente fala com ferramentas nomeadas e não com funções específicas, é possível trocar um handler do backend ou adicionar uma ferramenta sem alterar o agente. O mesmo backend também pode servir outros canais, pois todos registram pedidos nas mesmas ferramentas e dados.

Identificando o chamador sem login

Um chamador por telefone não faz login. O sistema usa o número de telefone como base de identidade: o fluxo de contato captura esse número e uma função Lambda o injeta na sessão do agente como atributo de sessão. O agente converte esse número em um ID de cliente e o usa em todas as chamadas de ferramentas da conversa.

Se o número não estiver disponível — porque o chamador bloqueou o identificador de chamadas — o agente gera um ID anônimo para a sessão e o pedido ainda é processado. Cada chamador tem um carrinho isolado, então ligações simultâneas nunca interferem umas nas outras.

Vale destacar: isso reconhece um chamador recorrente, mas não é verificação de identidade. O número de telefone não deve ser tratado como prova de quem está ligando. Uma implantação em produção que exija identidade verificada pode adicionar uma etapa como senha de uso único.

Mantendo a conversa segura com AI Guardrails

O agente de IA tem um Amazon Connect AI Guardrail configurado que mantém a conversa segura e dentro do tema. O guardrail aplica filtros de conteúdo para categorias como discurso de ódio, insultos, conteúdo sexual, violência e ataques de prompt. Ele bloqueia tópicos negados como discussões políticas e conselhos de investimento financeiro, e filtra linguagem inapropriada com uma lista gerenciada e uma lista personalizada.

Quando o chamador diz algo fora do tema ou inadequado, o guardrail intervém e o agente responde com uma mensagem padrão, como “Desculpe, só posso ajudar com pedidos do restaurante”, e redireciona a conversa.

Um ponto de atenção: filtros muito amplos podem bloquear turnos legítimos. Filtros de informações pessoais identificáveis, em particular, podem capturar o endereço ou CEP que o chamador precisa fornecer para encontrar uma unidade de retirada. Vale calibrar o guardrail contra o seu próprio prompt antes de subir para produção.

Armazenamento: cardápio, carrinhos e pedidos

Cinco tabelas do Amazon DynamoDB cobrem o fluxo de pedidos. A tabela Customers armazena perfis com nome, telefone e informações de fidelidade. A tabela Orders guarda o histórico de pedidos com a localização de retirada. A tabela Menu contém itens, preços e disponibilidade, que podem variar por unidade. A tabela Carts mantém carrinhos em andamento com um valor de tempo de expiração (TTL) para limpeza automática de carrinhos abandonados. A tabela Locations armazena detalhes dos restaurantes como coordenadas, horários e alíquotas de impostos.

O DynamoDB opera em modo sob demanda, então não há throughput para gerenciar.

Localização de retirada com Amazon Location Service

Um chamador por telefone não tem navegador para compartilhar localização. O agente pede um CEP ou um cruzamento de ruas e usa o Amazon Location Service para converter isso em coordenadas. A partir daí, o backend pode encontrar os restaurantes mais próximos, ranqueá-los por tempo de deslocamento em vez de distância em linha reta, ou geocodificar um endereço específico. Isso permite que o agente diga algo acionável como “a unidade mais próxima fica na Rua Principal, a cerca de cinco minutos daqui”.

Pré-requisitos e implantação

Para implantar a solução, são necessários:

• Uma conta AWS
• Acesso ao modelo Anthropic Claude Haiku 4.5 no console do Amazon Bedrock
• Cota de pelo menos um número de telefone do Amazon Connect, solicitada pelo console de Cotas de Serviço
• Node.js 18.x ou superior (24.x recomendado)
• Interface de Linha de Comando da AWS (AWS CLI) 2.x configurada com credenciais
• git para clonar o repositório
• AWS CDK inicializado na conta e região alvo

A solução completa está disponível no repositório de exemplo no GitHub. Após clonar o repositório, basta executar o script de implantação com um prefixo:

./scripts/deploy-all.sh --deploymentPrefix qsr-cn

O script executa uma verificação prévia e implanta cada stack do AWS CDK em ordem de dependência. Ao final, ele exibe o número para discagem. A AWS recomenda a região US East (Norte da Virgínia), us-east-1, como ponto de partida, pois todos os serviços necessários estão disponíveis lá.

Custos estimados

Segundo a AWS, em julho de 2026, executar essa solução com as configurações padrão na região US East (Norte da Virgínia) custa aproximadamente US$ 35 por mês para 1.000 pedidos por voz com média de cinco minutos cada. Os maiores itens de custo são os minutos de chamada de entrada no Amazon Connect, os tokens do Anthropic Claude Haiku 4.5 para orquestração e as requisições de fala do Amazon Lex V2. Não há cobranças fixas de computação, pois o Amazon Connect e os serviços de IA cobram por uso. A AWS recomenda configurar um orçamento no AWS Cost Explorer para acompanhar os gastos.

Limpeza dos recursos

Para evitar cobranças contínuas, a AWS disponibiliza um script de limpeza que remove os stacks em ordem inversa:

./scripts/cleanup-all.sh --force --deploymentPrefix qsr-cn

Atenção: a limpeza é destrutiva. Ela libera o número de telefone, apaga o histórico de pedidos no DynamoDB e remove a instância do Amazon Connect, o assistente, o agente de IA, o guardrail, o bot Lex e o AgentCore Gateway. Faça backup do que quiser preservar antes de executar. Ao final, confirme no console do AWS CloudFormation que todos os oito stacks foram removidos.

Recursos adicionais

• Boas práticas do Amazon Connect Agentic Voice
• Criar AI Guardrails para agentes de IA do Amazon Connect
• Primeiros passos com o Amazon Bedrock AgentCore
• Especificação do Model Context Protocol
• Guia do Administrador do Amazon Connect
• Guia do Desenvolvedor do Amazon Lex V2
• Documentação do Amazon Location Service

Fonte

Building a restaurant telephony AI host with Amazon Connect (https://aws.amazon.com/blogs/machine-learning/building-a-restaurant-telephony-ai-host-with-amazon-connect/)

O problema que a IA veio resolver

À medida que a produção de dados cresce em ritmo acelerado, a capacidade de padronizá-los não acompanha o mesmo ritmo. Metadados inconsistentes — com rótulos divergentes, identificadores fora do padrão e formatos incompatíveis entre fontes diferentes — criam um gargalo crítico que atrasa análises e dificulta o compartilhamento de dados entre organizações.

A harmonização de metadados, que consiste em padronizar rótulos, identificadores e formatos para que conjuntos de dados de origens distintas possam trabalhar juntos, ainda é feita majoritariamente de forma manual. A AWS publicou um post técnico detalhando como a inteligência artificial pode transformar esse processo, tornando-o escalável e compatível com os volumes de dados modernos.

Arquitetura da solução

A AWS descreve um fluxo centralizado de correção e harmonização de metadados construído sobre serviços gerenciados. Os componentes principais são:

• Amazon Bedrock para alinhamento de esquemas e geração de recomendações de correção com uso de Modelos de Linguagem de Grande Escala (LLM)
• Amazon Simple Storage Service (Amazon S3) para armazenamento de esquemas e resultados
• Amazon DynamoDB para rastreamento de jobs
• Amazon Cognito para autenticação
• Amazon Elastic Container Service (Amazon ECS) para processamento computacional

O fluxo opera de forma cíclica: os arquivos de metadados são enviados pelo usuário, passam por validação paralela em dois eixos — alinhamento de esquema e validação de campos individuais — e, quando problemas são detectados, o sistema gera recomendações direcionadas que são apresentadas ao usuário para aprovação final.

Etapas do processo de correção

Alinhamento de esquema

A primeira etapa compara os esquemas de dados de origem e destino, verificando se as colunas corretas existem e estão devidamente alinhadas. Problemas comuns incluem convenções de nomenclatura inconsistentes (sinônimos, erros de digitação, abreviações), colunas ausentes ou extras, e situações onde colunas precisam ser divididas ou combinadas.

Técnicas de correspondência aproximada de strings (fuzzy string matching) resolvem discrepâncias básicas de nomenclatura. Para casos mais complexos, os LLMs disponíveis no Amazon Bedrock trazem compreensão semântica ao problema: em vez de depender apenas de similaridade de texto, a abordagem baseada em LLM reconhece sinônimos específicos de um domínio, infere significado a partir das colunas vizinhas e detecta quando uma coluna de origem deve ser dividida em múltiplas colunas de destino — casos que sistemas baseados em regras simples não conseguem resolver.

Validação de campos de metadados

Essa etapa verifica se os valores individuais de cada campo estão em conformidade com os requisitos do esquema. As falhas são classificadas em três tipos:

• Validação de campos obrigatórios: identifica campos mandatórios que estão ausentes, vazios ou preenchidos apenas com espaços em branco.
• Validação de valores enumerados: compara o conteúdo dos campos com vocabulários controlados definidos no esquema. Valores fora da lista permitida geram um erro de validação.
• Validação de padrões: aplica correspondência por expressões regulares para verificar convenções de formatação — por exemplo, datas no formato AAAA-MM-DD ou identificadores com padrões alfanuméricos específicos.

Geração de recomendações de correção

Quando erros de validação são detectados, o sistema gera recomendações usando uma combinação em camadas de técnicas de Processamento de Linguagem Natural (PLN) e IA. A lógica prioriza métodos mais simples e baratos antes de acionar os LLMs, mantendo os custos de inferência previsíveis. As quatro técnicas utilizadas são:

• Similaridade semântica por embeddings: vetores de embedding permitem comparar valores de metadados semanticamente, identificando correspondências próximas com base em limiares de similaridade. Por exemplo, o sistema consegue mapear “Human” para “Homo sapiens” ou “NYC” para “New York City”. A AWS avaliou múltiplos modelos de embedding e selecionou o Amazon Titan por seu desempenho em tarefas gerais e biomédicas, disponibilidade comercial e compatibilidade com o Amazon Bedrock.
• Inferência contextual: o sistema recomenda correções identificando padrões e relações dentro do próprio conjunto de metadados, sem depender de grandes bases de dados externas. A implementação combina k-vizinhos mais próximos ponderados por distância com representações TF-IDF e análise de co-ocorrência por Informação Mútua Pontual (PMI). O resultado são recomendações estáveis e explicáveis, fundamentadas na estrutura interna dos dados.
• Correspondência fuzzy: algoritmos como a distância de Levenshtein detectam e corrigem inconsistências tipográficas ou de formatação — erros de digitação, espaçamento, diferenças de pontuação. Essa técnica é aplicada no início do fluxo para capturar inconsistências de baixo nível antes das camadas semânticas.
• Resolução por LLM (camada de fallback): quando os métodos anteriores não atingem um nível de confiança suficiente, o Amazon Bedrock é acionado como fallback. Os LLMs conseguem raciocinar sobre estruturas complexas de metadados e interpretar padrões ambíguos ou inéditos. Os resultados são então apresentados para revisão humana.

Abordagem 1: fluxo com supervisão humana

No modelo com supervisão humana (human-in-the-loop), o colaborador mantém controle total sobre as correções aplicadas. O fluxo funciona assim: o usuário faz o upload do arquivo de metadados pela interface web, o sistema executa a validação e harmonização automatizada, e as recomendações geradas pela IA são apresentadas na interface para revisão. O colaborador pode inspecionar cada entrada sinalizada, revisar as sugestões geradas automaticamente e aceitar, editar ou rejeitar cada uma delas. Após a revisão, o arquivo corrigido é reenviado para revalidação. Submissões bem-sucedidas são automaticamente confirmadas e propagadas.

Cada ciclo reduz o esforço manual enquanto preserva a responsabilidade do colaborador sobre o resultado final. A automação acelera as correções, mas o conhecimento de domínio do pesquisador permanece central no processo.

Abordagem 2: fluxo com agente autônomo

Para conjuntos de dados com centenas ou milhares de registros, a participação ativa do colaborador em cada ciclo de revisão ainda representa um esforço considerável. Para reduzir essa carga, a solução pode ser estendida com agentes autônomos.

Nesse modelo, um agente de metadados opera como um sistema autônomo ou semi-autônomo capaz de analisar, corrigir e validar registros de metadados. Ele usa tanto raciocínio determinístico (lógica baseada em regras) quanto não-determinístico (inferência por LLM via Amazon Bedrock). Por meio do Protocolo de Contexto de Modelo (MCP), o agente acessa ferramentas especializadas — o serviço remoto de processamento de metadados, validadores de esquema e módulos de similaridade por embedding.

O fluxo operacional do agente espelha a estrutura do fluxo humano, mas substitui as ações diretas do usuário por raciocínio autônomo:

Essa configuração permite escalar a curadoria de metadados em grandes volumes com intervenção humana mínima, mantendo um log auditável de todas as correções aplicadas.

Para dados de alto valor ou de domínios específicos, agentes especializados por organização podem ser implantados, com acesso a repositórios privados, logs de experimentos e publicações científicas internas. Isso permite dois níveis de adaptação: raciocínio local (inferência com base no dataset imediato e submissões anteriores) e enriquecimento contextual (uso de ontologias, protocolos e vocabulários controlados da organização).

Como implantar a solução

A AWS disponibilizou o código-fonte da solução no repositório no GitHub. Os pré-requisitos para implantação são:

• Node.js 18+ para o Kit de Desenvolvimento em Nuvem da AWS (AWS CDK) e desenvolvimento do frontend
• Python 3.11+
• Interface de Linha de Comando da AWS (AWS CLI) configurada com credenciais que tenham permissões para Amazon ECS, Amazon DynamoDB, Amazon S3, Amazon Cognito, Amazon Virtual Private Cloud (Amazon VPC), Gerenciamento de Identidade e Acesso da AWS (IAM), AWS CloudFormation, Amazon Elastic Container Registry (Amazon ECR) e Amazon CloudWatch
• AWS CDK Toolkit (npm install -g aws-cdk)
• Docker para construção das imagens de contêiner
• Make para execução dos comandos do Makefile
• Gerenciador de pacotes Python uv

O processo de implantação segue seis passos principais:

Passo 1: clonar o repositório e instalar dependências

git clone https://github.com/aws-samples/sample-intelligent-metadata-harmonization.git
cd metadata-harmonization

# Criar e ativar ambiente virtual Python
make createPythonEnvironment
source .venv/bin/activate

# Instalar todas as dependências
make install

Passo 2: configurar o deployment

cp config.yaml.example config.yaml

Edite o arquivo config.yaml com os dados da sua conta AWS:

appName: "metadata-harmonization-app"
env: "dev"
dev:
  profile: "your-aws-profile"
  deploymentName: "metadata-harmonization-dev"
  accountNumber: "123456789012" # Seu número de conta AWS com 12 dígitos
  region: "us-east-1"
  deploymentStage: "dev"
  removalPolicy: "destroy"
  logLevel: "INFO"
  targetPlatform: "linux/amd64"

Valide a configuração com make validateConfig.

Passo 3: implantar a infraestrutura

# Configuração inicial (apenas na primeira vez)
make bootstrap

# Implantar todos os recursos AWS
make deploy

Após o deploy, gere o arquivo .env local com os identificadores dos recursos:

make createLocalDotEnvFile

Passo 4: criar usuários no Amazon Cognito

Acesse o console do Amazon Cognito, selecione o user pool criado pelo deployment, vá até “Users” e crie os usuários necessários com e-mail e senha temporária.

Passo 5: executar a aplicação web localmente

# Executar API e frontend juntos (recomendado)
make runLocal

A interface web fica disponível em http://localhost:3000 e a documentação da API em http://localhost:8080/api/docs.

Passo 6: executar o agente de metadados

uv run metadata-agent validate data/synthetic_dataset/simple_test.csv --interactive

O agente se conecta à API via MCP, valida o dataset, recupera os relatórios de falha e aplica correções de forma autônoma.

Considerações de governança e segurança

A transição de prova de conceito para produção exige atenção a quatro áreas:

• Integridade dos dados e rastreamento de mudanças: organizações devem estabelecer frameworks claros para documentar e preservar as alterações de metadados, com políticas de retenção, trilhas de auditoria e controles de integridade adequados ao ambiente regulatório.
• Governança de arquitetura: é necessário definir se as correções geradas pela IA requerem aprovação antes de serem aplicadas ou se podem ser aplicadas automaticamente com revisão posterior. Essa decisão afeta a integridade dos dados e a capacidade de reversão.
• IA responsável e segurança de conteúdo: deployments em produção que usam inferência de LLM devem incorporar o Amazon Bedrock Guardrails para estabelecer limites no comportamento dos modelos e proteger contra ataques de injeção de prompt — especialmente quando valores de metadados de fontes externas são passados diretamente para os prompts dos modelos.
• Segurança: sistemas de IA que lidam com dados genômicos sensíveis devem atender aos mesmos padrões de segurança de sistemas tradicionais de pesquisa, incluindo controle de acesso baseado em papéis e proteção de dados em todo o pipeline de validação.

Para encerrar o ambiente e evitar cobranças contínuas, basta executar make destroy, que remove toda a stack do AWS CDK.

Conclusão

A solução de correção e harmonização de metadados com IA apresentada pela AWS endereça um desafio persistente em pesquisa biomédica: o tempo gasto em padronização de dados em vez de trabalho científico. As duas abordagens de implementação — com supervisão humana e com agentes autônomos — oferecem flexibilidade para organizações em diferentes estágios de adoção de IA. Equipes podem começar com correções supervisionadas para construir confiança no sistema e, gradualmente, migrar para abordagens mais automatizadas. A arquitetura nativa em nuvem escala com o volume de dados e o design modular permite customização para necessidades institucionais específicas.

Fonte

AI-powered metadata correction and harmonization (https://aws.amazon.com/blogs/machine-learning/ai-powered-metadata-correction-and-harmonization/)