Author: Make.com Service User

O problema clássico de observabilidade em IA de fala auto-hospedada

Quem já operou modelos de inteligência artificial em infraestrutura própria conhece bem um limite frustrante: as métricas padrão de endpoint dizem que o serviço está de pé e quantas requisições foram atendidas, mas as perguntas que realmente importam para planejamento de capacidade e gestão de custos ficam escondidas dentro do contêiner do fornecedor. O que exatamente está sendo cobrado? Quais funcionalidades o tráfego está usando? O que o motor de inferência está fazendo em cada Unidade de Processamento Gráfico (GPU)?

A Deepgram anunciou duas inovações para fechar exatamente essa lacuna em deployments dos seus modelos de fala no Amazon SageMaker AI. As novidades chegam disponíveis hoje para quem utiliza os modelos de Reconhecimento de Fala para Texto (STT) e Síntese de Fala a partir de Texto (TTS) da Deepgram no SageMaker AI.

Como a Deepgram opera no Amazon SageMaker AI

Os modelos de fala da Deepgram estão disponíveis como pacotes de modelo no AWS Marketplace e são implantados como endpoints em tempo real no SageMaker AI, dentro da conta do próprio cliente. Essa arquitetura significa que o áudio e as transcrições ficam dentro da conta AWS do cliente, o que pode apoiar requisitos de residência de dados e conformidade regulatória — sem abrir mão de um plano de controle gerenciado para deploy, escalonamento e monitoramento.

O SageMaker AI já entrega observabilidade básica automaticamente: métricas de invocação como ConcurrentRequestsPerModel e FirstChunkLatency no CloudWatch, logs de contêiner no Amazon CloudWatch Logs e escalonamento automático via alarmes. Os pacotes de modelo do AWS Marketplace rodam com isolamento de rede — o contêiner não faz conexões de saída, o que é justamente o motivo pelo qual clientes com requisitos de segurança mais rígidos escolhem esse modelo de implantação.

O desafio é que esse mesmo isolamento costuma dificultar a telemetria do fornecedor: o contêiner não consegue enviar métricas para um coletor externo, e não há como enxergar o que acontece dentro dele. As duas novidades da Deepgram foram projetadas para funcionar dentro dessa restrição — nenhuma delas exige que o contêiner abra um caminho de rede, e ambas entregam os dados na própria conta CloudWatch do cliente.

Inovação 1 — Transparência de faturamento e uso com Deepgram Enhanced Metrics

As Deepgram Enhanced Metrics respondem duas perguntas que nenhuma métrica padrão de endpoint consegue responder: exatamente o que está sendo cobrado e como o tráfego utiliza as funcionalidades da Deepgram.

Como funciona: métricas que viajam pelo caminho de log

O contêiner da Deepgram escreve registros no formato Formato de Métrica Embarcada do CloudWatch (EMF) no stdout do contêiner. O SageMaker AI já encaminha a saída do contêiner para o grupo de logs do CloudWatch do endpoint, e o CloudWatch Logs extrai os registros EMF em métricas automaticamente.

Esse caminho via EMF traz vantagens práticas importantes:

• Nenhum agente, sidecar ou coletor adicional para implantar.
• Nenhuma permissão de Gerenciamento de Identidade e Acesso (IAM) adicional além do que o endpoint já possui para logging.
• Funciona sob o isolamento de rede do AWS Marketplace, porque as métricas trafegam pelo caminho de logging já existente entre o SageMaker e o CloudWatch.
• São métricas CloudWatch convencionais — aparecem no aws cloudwatch list-metrics e funcionam com dashboards, alarmes e operações matemáticas sobre métricas, sem nenhuma configuração adicional no endpoint.

Todas as dimensões são de baixa cardinalidade e não contêm Informações de Identificação Pessoal (PII): nenhuma transcrição, entrada de TTS ou identificador por requisição. As métricas são agregadas pelos endpoints da Deepgram na conta e região AWS do cliente — as dimensões cobrem categoria, modelo e transporte, mas não o nome do endpoint ou ID da instância.

Reconciliar a fatura do AWS Marketplace: o namespace Deepgram/SageMakerInference

O namespace de faturamento emite um registro por requisição concluída, cobrindo cada sessão de streaming, requisição de áudio pré-gravado e requisição de TTS. A métrica ConsumedUnits carrega os mesmos valores de unidades faturáveis que alimentam o faturamento medido do AWS Marketplace.

As métricas publicadas nesse namespace são:

• ConsumedUnits — Unidades de inferência faturáveis para a requisição. A soma em um período representa o volume total cobrado.
• AudioDurationSeconds — Duração do áudio processado (STT).
• CharCount — Caracteres sintetizados (TTS).

As dimensões são publicadas em três granularidades ([Category], [Category, Model] e [Category, Model, Transport]), permitindo responder tanto “quanto o STT em streaming custou este mês” quanto “quanto disso foi com o modelo nova-3”.

Exemplo de consulta para total de unidades consumidas por hora no STT em streaming:

aws cloudwatch get-metric-statistics \
  --namespace Deepgram/SageMakerInference \
  --metric-name ConsumedUnits \
  --dimensions Name=Category,Value=stt_streaming \
  --start-time $(date -u -d '24 hours ago' +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 3600 \
  --statistics Sum SampleCount \
  --region YOUR_AWS_REGION

O SampleCount representa o número de requisições faturadas. Por serem métricas CloudWatch convencionais, é possível construir um dashboard de faturamento para times financeiros ou configurar um alarme de orçamento sobre as unidades consumidas.

Entender como o endpoint é utilizado: o namespace Deepgram/SelfHosted

Um segundo fluxo de métricas, emitido pelo próprio servidor da API Deepgram, detalha o uso bruto por método, nível de modelo e funcionalidade habilitada — independente do faturamento. Ele responde perguntas de produto: quanto do tráfego é streaming versus pré-gravado, quais camadas de modelo processam mais áudio, e quais funcionalidades (diarização, formatação inteligente, redação, prompting por termos-chave) as aplicações realmente habilitam.

As métricas desse namespace incluem:

• AudioMs, Requests — Volume por streaming comparado a pré-gravado.
• TierAudioMs — Áudio processado por nível de modelo (ex: nova-3, flux).
• FeatureAudioMs, FeatureTokens — Utilização por funcionalidade habilitada (ex: diarize, smart_format, redact).
• TtsCharacters, Tokens, VoiceAgentMs — Volume de TTS, funcionalidades de inteligência e agente de voz.

Exemplo: quanto áudio rodou com diarização habilitada nas últimas 24 horas:

aws cloudwatch get-metric-statistics \
  --namespace Deepgram/SelfHosted \
  --metric-name FeatureAudioMs \
  --dimensions Name=Deployment,Value=sagemaker Name=Feature,Value=diarize \
  --start-time $(date -u -d '24 hours ago' +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 3600 \
  --statistics Sum \
  --region YOUR_AWS_REGION

O fluxo de uso está habilitado por padrão e pode ser desativado com uma variável de ambiente na configuração do endpoint (DEEPGRAM_API_01: emf.enabled=false). O fluxo de faturamento não pode ser desativado — ele faz parte do pipeline de medição.

Inovação 2 — Visibilidade em nível de engine e por GPU com Prometheus e OpenTelemetry

Os contêineres da Deepgram servem um endpoint de métricas Prometheus, e a observabilidade detalhada do SageMaker AI executa um Coletor OpenTelemetry gerenciado pela AWS em cada instância que sustenta o endpoint. Esse coletor faz o scrape do contêiner e exporta os resultados para o CloudWatch, além de exportar métricas por GPU e do host.

Com a observabilidade detalhada habilitada, três fontes de métricas publicam no armazenamento de métricas compatível com OpenTelemetry (OTel) do CloudWatch:

• GPU (exportador DCGM) — Métricas como DCGM_FI_DEV_GPU_UTIL e DCGM_FI_DEV_FB_USED. Em instâncias com múltiplas GPUs, cada GPU reporta separadamente — um dispositivo saturado não consegue se esconder por trás de um número de utilização somado ou médio.
• Host (node exporter) — Métricas padrão do node-exporter Prometheus, como node_cpu_seconds_total e node_memory_MemTotal_bytes, para cada instância.
• Engine Deepgram — O coletor faz scrape diretamente do endpoint Prometheus do contêiner Deepgram. Exemplos: engine_active_requests{kind="stream"} e engine_estimated_stream_capacity. São as mesmas métricas de API e Engine que os clientes self-hosted da Deepgram usam para planejamento de capacidade, agora disponíveis no SageMaker AI sem precisar rodar nenhum coletor próprio. Consulte o Guia de Métricas da Deepgram para a referência completa.

A métrica engine_estimated_stream_capacity é a estimativa do próprio motor Deepgram de quantos streams simultâneos a instância consegue sustentar. Comparar esse valor com engine_active_requests fornece um sinal de headroom reportado pelo engine para decisões de escalonamento.

Cada série carrega rótulos de recurso do SageMaker, incluindo aws.sagemaker.endpoint.name, o nome da variante e o ID da instância — o que permite filtrar por endpoint específico, isolar uma instância em uma frota escalada ou comparar GPUs dentro de uma mesma instância. Como o coletor roda no host, fora do contêiner do modelo, isso funciona mesmo sob o isolamento de rede do AWS Marketplace.

Como habilitar a observabilidade detalhada

A observabilidade detalhada vem habilitada por padrão em endpoints criados recentemente, publicando a cada 60 segundos. Para configurar explicitamente — por exemplo, em um endpoint criado antes do lançamento do recurso, ou para alterar a frequência de publicação — use o MetricsConfig na configuração do endpoint:

aws sagemaker create-endpoint-config \
  --endpoint-config-name YOUR_CONFIG_NAME \
  --production-variants file://production-variants.json \
  --metrics-config '{"EnableDetailedObservability": true, "MetricPublishFrequencyInSeconds": 60}' \
  --region YOUR_AWS_REGION

Para um endpoint já em serviço, basta criar uma nova configuração de endpoint e executar update-endpoint. A atualização é um deploy blue/green — o endpoint permanece em serviço durante a transição.

Consultas com PromQL a partir do CloudWatch, Grafana ou qualquer ferramenta compatível

As métricas ficam no armazenamento de métricas OTel do CloudWatch e são consultadas com PromQL. No editor PromQL do console do CloudWatch, é possível filtrar a utilização por GPU para um endpoint específico:

DCGM_FI_DEV_GPU_UTIL{"aws.sagemaker.endpoint.name"="YOUR_ENDPOINT_NAME"}

O CloudWatch também expõe uma API HTTP padrão compatível com Prometheus para essas métricas, autenticada com SigV4:

awscurl --service monitoring --region YOUR_AWS_REGION \
  "https://monitoring.YOUR_AWS_REGION.amazonaws.com/api/v1/query?query=engine_active_requests"

Para equipes que já padronizaram em Grafana ou outra stack de observabilidade nativa do Prometheus, é possível apontar as ferramentas existentes para a frota do SageMaker AI — sem uma stack de monitoramento paralela, sem pipeline de exportação.

Qual fluxo de métricas usar para cada situação

As duas inovações complementam as métricas nativas do SageMaker AI, sem substituí-las. O mapeamento de perguntas para o fluxo correto é o seguinte:

• O endpoint está saudável? As requisições estão com erro ou lentidão no início? → Métricas padrão do SageMaker (ConcurrentRequestsPerModel, FirstChunkLatency, Invocation5XXErrors).
• Qual será minha fatura no Marketplace e quais modelos a geraram? → Deepgram Enhanced Metrics (namespace Deepgram/SageMakerInference, nível de conta).
• Quais funcionalidades e camadas de modelo meu tráfego realmente usa? → Deepgram Enhanced Metrics (namespace Deepgram/SelfHosted, nível de conta).
• Qual é a saturação de cada GPU? Quanto de capacidade de stream resta em cada instância de um endpoint específico? → Prometheus/OTel via observabilidade detalhada (métricas DCGM e engine Deepgram, por endpoint/instância/GPU).

Como começar

As Deepgram Enhanced Metrics não exigem nenhuma configuração: elas fluem para a conta CloudWatch do cliente a partir do momento em que um endpoint Deepgram no SageMaker AI começa a servir tráfego. A observabilidade detalhada já vem habilitada por padrão em novos endpoints e requer apenas uma mudança na configuração do endpoint para ser adicionada aos existentes.

Para começar, os recursos disponíveis são:

• Implante a Deepgram a partir do AWS Marketplace e siga o guia Deploy Deepgram on Amazon SageMaker.
• Referência: Deepgram Enhanced Metrics, Prometheus & OpenTelemetry Metrics e o Guia de Métricas para a lista completa de métricas de API e Engine da Deepgram.
• Documentação AWS: Observabilidade detalhada para endpoints do SageMaker AI.

Vale destacar que rodar modelos Deepgram no SageMaker AI gera cobranças pela hospedagem do endpoint (incluindo instâncias GPU), pelos logs e métricas do Amazon CloudWatch e pelos recursos de rede associados. O trial de 14 dias dos modelos Deepgram não tem custo adicional, mas os custos de infraestrutura AWS se aplicam desde o início do deploy. Recomenda-se revisar a precificação do SageMaker AI e usar o AWS Cost Explorer para monitorar os gastos.

Conclusão

A Deepgram fecha uma lacuna que existia há muito tempo: a distância entre os contadores de requisição do serviço e a fatura do fornecedor. Com as Enhanced Metrics, os valores exatos que alimentam o faturamento do AWS Marketplace chegam diretamente na conta CloudWatch do cliente, sem infraestrutura adicional. O detalhamento de uso por funcionalidade também fica disponível no mesmo lugar.

Com o suporte a Prometheus e OpenTelemetry via observabilidade detalhada do SageMaker AI, as métricas de capacidade e carga do próprio motor Deepgram — junto com a utilização por GPU — ficam a uma consulta PromQL de distância, nas ferramentas que o time já utiliza. Essas capacidades seguem o investimento da Deepgram no SageMaker AI como opção preferencial de deploy para IA de fala auto-hospedada, após a introdução da Delegação Temporária IAM para acesso de suporte.

Fonte

Deepgram deepens Amazon SageMaker AI observability with Enhanced Metrics (https://aws.amazon.com/blogs/machine-learning/deepgram-deepens-amazon-sagemaker-ai-observability-with-enhanced-metrics/)

O que foi anunciado

A AWS anunciou suporte aos modelos OpenAI GPT-5.6 Terra e Luna no Amazon Bedrock com inferência geográfica restrita à Índia. Isso significa que organizações com requisitos de processamento local de dados — como instituições financeiras, empresas de saúde e órgãos do setor público — podem usar esses modelos em escala sem que nenhum dado saia do território indiano.

Ambos os modelos oferecem uma janela de contexto de 1 milhão de tokens, aceitam entrada de texto e imagem, e produzem saída em texto. Com essa capacidade, uma única requisição pode processar documentos longos, bases de código extensas ou cargas de trabalho mistas com texto e imagem.

Como funciona a inferência geográfica na Índia

O Amazon Bedrock já oferece inferência entre regiões (cross-Region inference) como mecanismo de capacidade: em vez de ficar limitado à capacidade de uma única região, as requisições são distribuídas automaticamente por um pool maior de computação. Isso ajuda a manter a taxa de transferência e o desempenho consistente, especialmente em picos de tráfego.

No caso da Índia, o roteamento acontece exclusivamente entre as regiões Ásia-Pacífico (Mumbai) ap-south-1 e Ásia-Pacífico (Hyderabad) ap-south-2. Você pode fazer chamadas a partir de qualquer uma das duas regiões como origem, e o Bedrock decide qual região de destino atende a requisição com base na capacidade disponível.

Para consultar a disponibilidade atualizada por modelo e região, a AWS disponibiliza a documentação de disponibilidade regional por modelos no Guia do Usuário do Amazon Bedrock.

Perfis de inferência geográfica

A inferência entre regiões funciona por meio de perfis de inferência. Você passa o ID do perfil como parâmetro de modelo na chamada de API, e ele define tanto o modelo quanto as regiões para as quais o Bedrock pode rotear a requisição. Os dois perfis disponíveis para a Índia são:

• in.openai.gpt-5.6-terra — para o GPT-5.6 Terra
• in.openai.gpt-5.6-luna — para o GPT-5.6 Luna

Com esses perfis, a cobrança e o consumo de cotas são contabilizados na conta da região de origem, independentemente de qual região de backend processou a requisição. Logs do Amazon CloudWatch e do AWS CloudTrail também são registrados apenas na região de origem, o que simplifica o monitoramento.

Endpoint recomendado: bedrock-runtime

Para novas aplicações, a AWS recomenda o uso do endpoint bedrock-runtime. Ele suporta as APIs nativas do Bedrock — InvokeModel e Converse — além das APIs compatíveis com OpenAI (Responses e Chat Completions) e a API Messages da Anthropic. É também nesse endpoint que recursos como Guardrails, roteamento inteligente de prompts e inferência entre regiões estão disponíveis.

Residência de dados e segurança

O perfil geográfico da Índia garante que a inferência permaneça dentro do país: as requisições só trafegam entre ap-south-1 e ap-south-2, com criptografia em trânsito pela rede da Amazon.

O Amazon Bedrock adota um modelo de segurança de dados com retenção zero (ZDR — Zero Data Retention): por padrão, entradas e saídas dos modelos não são armazenadas. No entanto, para determinados modelos, incluindo o GPT-5.6, conteúdo sinalizado pelos classificadores automáticos de detecção de abuso do Bedrock pode ser retido para análise offline. Para mais detalhes, consulte a documentação sobre detecção de abuso no Guia do Usuário do Amazon Bedrock.

Inferência global também disponível

Além dos perfis geográficos da Índia, o Bedrock oferece perfis de inferência global (prefixo global.) que roteiam requisições para regiões comerciais da AWS ao redor do mundo, maximizando a capacidade disponível. Esses perfis suportam os modelos GPT-5.6, incluindo Sol, Terra e Luna. Porém, se o seu workload tiver requisitos de processamento local de dados, use os perfis com prefixo in., que mantêm a inferência dentro da Índia. Para saber mais sobre inferência global, consulte o post Introdução à inferência entre regiões para modelos OpenAI GPT-5.6 no Amazon Bedrock.

Como chamar os modelos GPT-5.6

Via OpenAI Responses API

Os modelos GPT-5.6 no Amazon Bedrock suportam nativamente o formato da OpenAI Responses API. Se sua aplicação já utiliza o SDK da OpenAI, basta apontar o cliente para o endpoint do Bedrock em uma das regiões da Índia e passar o ID do perfil de inferência geográfica como parâmetro de modelo.

Para autenticação, o Bedrock aceita credenciais AWS padrão ou uma chave de API do Amazon Bedrock. Para produção, a recomendação é gerar chaves de curta duração programaticamente com o pacote aws-bedrock-token-generator. O exemplo abaixo usa o endpoint de Mumbai (ap-south-1) com o perfil geográfico do GPT-5.6 Terra:

from aws_bedrock_token_generator import provide_token
from openai import OpenAI

# Point the OpenAI SDK at the Amazon Bedrock OpenAI-compatible
# endpoint in the Asia Pacific (Mumbai) Region.
client = OpenAI(
    base_url="https://bedrock-runtime.ap-south-1.amazonaws.com/openai/v1",
    api_key=provide_token(region="ap-south-1"), # short-term Amazon Bedrock API key, valid up to 12 hours
)

# Geographic (India) inference profile ID for GPT-5.6 Terra.
model_id = "in.openai.gpt-5.6-terra" # "in.openai.gpt-5.6-luna" for luna

response = client.responses.create(
    model=model_id,
    input="Extract the payment due date and total amount from the invoice text that follows, and return them as JSON. <invoice text>",
    max_output_tokens=512,
)
print(response.output_text)

Controlando a profundidade de raciocínio

Para controlar a profundidade de raciocínio, utilize o parâmetro opcional reasoning, por exemplo reasoning={"effort": "low"}. Os modelos GPT-5.6 no Bedrock suportam os seguintes níveis de esforço: none, low, medium, high, xhigh e max. Para mais informações, consulte o post Introdução aos modelos OpenAI GPT-5.6 Sol, Terra e Luna no Amazon Bedrock. Omitir o parâmetro usa o padrão do modelo.

response = client.responses.create(
    model="in.openai.gpt-5.6-terra",
    input="Extract the payment due date and total amount from the invoice text that follows, and return them as JSON. <invoice text>",
    reasoning={"effort": "high"}, # none | low | medium | high | xhigh | max
    max_output_tokens=512,
)

Para a lista completa de parâmetros suportados, consulte a documentação dos modelos OpenAI no Guia do Usuário do Amazon Bedrock.

Conversas multi-turno com estado no servidor

Defina store=True para que o Bedrock retenha a resposta no servidor. Em seguida, referencie-a no próximo turno com previous_response_id. Assim, você envia apenas o novo turno, sem precisar reenviar o histórico completo da conversa:

first = client.responses.create(
    model="in.openai.gpt-5.6-terra",
    input="Remember this: my favorite number is 42. Reply with just 'stored'..",
    max_output_tokens=50,
    store=True,
)

second = client.responses.create(
    model="in.openai.gpt-5.6-terra",
    previous_response_id=first.id, # the model recalls the earlier turn
    input="what is my favourite number?",
    max_output_tokens=50,
    store=True,
)
print(second.output_text)

Importante: se você encadear com previous_response_id, a resposta referenciada deve ter sido criada com store=True. Encadear a partir de uma resposta não armazenada retorna erro.

Respostas em streaming

stream = client.responses.create(
    model="in.openai.gpt-5.6-terra",
    input="Draft a short status update for a delayed shipment, in a polite and direct tone.",
    max_output_tokens=512,
    stream=True,
)

for event in stream:
    if event.type == "response.output_text.delta":
        print(event.delta, end="")

Via Amazon Bedrock Converse API

Se você preferir o SDK da AWS com autenticação SigV4 em vez de uma chave de API, a Converse API do Amazon Bedrock também suporta os modelos GPT-5.6 com a mesma interface unificada disponível para outros modelos no Bedrock:

import boto3

# Standard AWS credentials (SigV4), no API key needed.
client = boto3.client("bedrock-runtime", region_name="ap-south-1")
model_id = "in.openai.gpt-5.6-terra" # India Geo inference profile

response = client.converse(
    modelId=model_id,
    messages=[
        {
            "role": "user",
            "content": [{"text": "Classify this support ticket as billing, technical, or account: <ticket text>"}],
        }
    ],
    inferenceConfig={"maxTokens": 512},
)
print(response["output"]["message"]["content"]

Cache de prompts

Quando os prompts compartilham um prefixo longo e estável — como instruções de sistema, trechos de base de conhecimento ou exemplos de few-shot — os modelos GPT-5.6 no Bedrock suportam cache de prompts. Leituras em cache são cobradas com 90% de desconto em relação aos tokens de entrada não cacheados, o que representa economia significativa em workloads de Geração Aumentada por Recuperação (RAG — Retrieval Augmented Generation) e agentes que repetem o mesmo contexto em muitos turnos. Mais detalhes estão disponíveis na documentação de cache de prompts do Amazon Bedrock.

O cache de prompts funciona com os perfis de inferência geográfica da Índia, mantendo a economia dentro do limite de residência de dados do país. Ele opera em dois modos: implícito (o Bedrock define os pontos de cache automaticamente, com prefixo mínimo de 1.024 tokens) e explícito (você marca o limite de cache manualmente, e o prefixo cacheado permanece ativo por pelo menos 30 minutos).

response = client.responses.create(
    model="in.openai.gpt-5.6-terra",
    prompt_cache_key="ticket-agent-ver123", # same key across all requests
    input=[
        {
            "type": "message",
            "role": "developer",
            "content": [{
                "type": "input_text",
                "text": SYSTEM_INSTRUCTIONS, # long, static: guidelines, KB excerpts (>= 1,024 tokens)
                "prompt_cache_breakpoint": {"mode": "explicit"},
            }],
        },
        {
            "type": "message",
            "role": "user",
            "content": [{
                "type": "input_text",
                "text": user_question, # changes on every request
            }],
        },
    ],
    extra_body={"prompt_cache_options": {"mode": "explicit"}},
)

Cada resposta informa o que o cache fez, em usage.input_tokens_details:

details = response.usage.input_tokens_details
print(f"cached: {details.cached_tokens}, written: {details.cache_write_tokens}")

Na primeira chamada, cache_write_tokens será preenchido à medida que o prefixo é armazenado. Nas chamadas seguintes, os mesmos tokens retornam como cached_tokens, cobrados à taxa de leitura de cache.

Permissões do IAM para inferência geográfica na Índia

Para permitir que uma função do Gerenciamento de Identidade e Acesso da AWS (IAM — Identity and Access Management) invoque os modelos GPT-5.6 pelo perfil de inferência geográfica da Índia, é necessário conceder acesso a três recursos: o próprio perfil de inferência geográfica, o modelo de fundação (FM — Foundation Model) na região de origem e o FM em cada região de destino listada no perfil (ap-south-1 e ap-south-2). Você pode usar a política gerenciada AmazonBedrockLimitedAccess ou criar a sua própria.

O exemplo abaixo concede permissão para usar o modelo GPT-5.6 Terra pelo perfil de inferência geográfica da Índia. A região de origem é ap-south-1 e as regiões de destino são ap-south-1 e ap-south-2. Substitua <ACCOUNT> pelo ID da sua conta e duplique os recursos para in.openai.gpt-5.6-luna se a função precisar de ambos os modelos. Se você originar de Hyderabad, use o ARN do perfil de inferência de ap-south-2 no primeiro statement:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "GrantGeoCrisInferenceProfileAccess",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel*"
      ],
      "Resource": [
        "arn:aws:bedrock:ap-south-1:<ACCOUNT>:inference-profile/in.openai.gpt-5.6-terra",
        "arn:aws:bedrock:ap-south-1:<ACCOUNT>:project/default"
      ]
    },
    {
      "Sid": "GrantGeoCrisModelAccess",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel*"
      ],
      "Resource": [
        "arn:aws:bedrock:ap-south-1::foundation-model/openai.gpt-5.6-terra",
        "arn:aws:bedrock:ap-south-2::foundation-model/openai.gpt-5.6-terra"
      ],
      "Condition": {
        "StringEquals": {
          "bedrock:InferenceProfileArn": "arn:aws:bedrock:ap-south-1:<ACCOUNT>:inference-profile/in.openai.gpt-5.6-terra"
        }
      }
    },
    {
      "Sid": "AllowBearerTokenAuth",
      "Effect": "Allow",
      "Action": ["bedrock:CallWithBearerToken"],
      "Resource": "*"
    }
  ]
}

Se sua organização usa Políticas de Controle de Serviço (SCP — Service Control Policies) para bloquear regiões não utilizadas, as condições específicas de região do SCP devem permitir todas as regiões de destino listadas no perfil de inferência geográfica. Para o perfil da Índia, tanto ap-south-1 quanto ap-south-2 devem estar liberadas. Bloquear qualquer região de destino fará a inferência entre regiões falhar, mesmo que a região de origem permaneça acessível.

Configurando o Codex com GPT-5.6 no Amazon Bedrock

O Codex pode usar os perfis de inferência geográfica via Amazon Bedrock Runtime. Para isso, instale a versão mais recente do Codex CLI (codex-cli 0.149.1 ou superior). Para organizações cujo provedor de identidade é Okta, Auth0, Microsoft Entra ID, Amazon Cognito ou AWS IAM Identity Center, o repositório AWS OIDC Auth Helper fornece um helper de credenciais de exemplo.

Após configurar o provedor de identidade e o perfil AWS correspondente, crie ou atualize o arquivo ~/.codex/config.toml referenciando o perfil AWS. Consulte a referência de configuração do Codex para outras configurações suportadas:

model = "in.openai.gpt-5.6-terra"
model_provider = "amazon-bedrock-runtime"
model_reasoning_effort = "high"

[model_providers.amazon-bedrock-runtime.aws]
profile = "<AWS_OIDC_PROFILE>"
region = "ap-south-1"

Para usar na região Ásia-Pacífico (Hyderabad), defina a região como ap-south-2 no perfil AWS e na configuração do Codex. Se você já tiver credenciais AWS configuradas localmente, o Codex pode usá-las diretamente — basta apontar o provedor Amazon Bedrock Runtime para um perfil AWS e uma região da Índia, definindo o modelo como um ID de perfil de inferência geográfica da Índia.

Monitoramento e logs

Os perfis de inferência geográfica da Índia funcionam com os mesmos controles de nível de conta já utilizados para outros modelos no Amazon Bedrock. As requisições aparecem no log de invocação de modelos do Amazon Bedrock da mesma forma que requisições sob demanda. Esses logs podem ser entregues ao Amazon Simple Storage Service (Amazon S3) ou ao Amazon CloudWatch Logs.

Métricas do CloudWatch para contagem de invocações, contagem de tokens, latência, throttles e erros são publicadas por perfil de inferência. Você pode acompanhar o uso dos modelos GPT-5.6 a partir de Mumbai ou Hyderabad sem precisar correlacionar logs entre regiões. Para verificar qual região de destino processou uma determinada requisição, os eventos do CloudTrail incluem um campo additionalEventData com a chave inferenceRegion — para o perfil da Índia, esse valor será sempre ap-south-1 ou ap-south-2, fornecendo um registro auditável de que a inferência permaneceu dentro da Índia.

Próximos passos

Para começar, revise os model cards do GPT-5.6 Terra e Luna e a seção de inferência entre regiões no Guia do Usuário do Amazon Bedrock. Experimente um prompt no playground do console do Amazon Bedrock em Mumbai ou Hyderabad e, em seguida, integre os exemplos de código apresentados neste artigo.

Antes de dimensionar um workload de produção, consulte a página de preços do Amazon Bedrock para verificar as tarifas atuais do GPT-5.6. Em caso de dúvidas ou para interagir com a comunidade, o AWS re:Post é um bom lugar para buscar respostas ou postar perguntas.

Fonte

Introducing OpenAI models on Amazon Bedrock for in-country inferencing in India (https://aws.amazon.com/blogs/machine-learning/introducing-openai-models-on-amazon-bedrock-for-in-country-inferencing-in-india/)

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

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