AWS adiciona saídas estruturadas para Claude no Amazon Bedrock

A Amazon Web Services (AWS) anunciou em 19 de outubro de 2026 que o Amazon Bedrock passou a oferecer saídas estruturadas para todos os modelos Anthropic Claude disponíveis na plataforma. Na prática, a empresa promete que chamadas compatíveis com o recurso retornem JSON conforme um esquema definido pela aplicação, tanto no endpoint bedrock-runtime quanto no bedrock-mantle. A mudança mira um problema recorrente em integrações com modelos de linguagem: texto que parece JSON, mas quebra o parser, omite um campo obrigatório ou envia um valor fora do formato esperado.

O anúncio é relevante para equipes que usam IA em processos com banco de dados, automação, classificação e agentes. Mas “JSON válido” não equivale a “informação verdadeira”: a estrutura pode ser garantida durante a geração, enquanto a qualidade factual da resposta, regras de negócio e segurança ainda exigem testes e controles fora do modelo.

O que mudou no Amazon Bedrock

Segundo a publicação técnica da AWS, o Bedrock agora aceita um JSON Schema como formato de saída para Claude. Em vez de pedir “responda em JSON” por instrução de prompt e tentar corrigir a resposta depois, a plataforma aplica decodificação restrita: durante a geração, o modelo só pode produzir tokens compatíveis com a gramática derivada do esquema.

A AWS afirma que o recurso está disponível nos dois caminhos de API: o bedrock-runtime, usado com chamadas como InvokeModel, e o bedrock-mantle, voltado a conversas com estado, inferência em segundo plano e ferramentas no servidor. Também há suporte a uso estrito de ferramentas no Mantle: ao declarar strict: true, os argumentos de uma chamada de ferramenta precisam obedecer ao esquema de entrada informado.

Por que “peça JSON” não é suficiente

Modelos de linguagem são bons em produzir textos que se parecem com JSON. Isso não impede uma vírgula a mais, uma chave inesperada, um campo ausente ou uma categoria fora da lista permitida. Em uma interface de chat, esses erros podem ser toleráveis. Em uma rotina que cadastra um lead, encaminha um chamado ou envia parâmetros a uma ferramenta, eles viram falhas de integração.

Com um esquema, a aplicação pode declarar explicitamente os campos esperados, seus tipos, itens obrigatórios, valores enumerados e a proibição de propriedades extras. Um classificador de tickets, por exemplo, pode limitar prioridade a baixa, média, alta ou urgente; um extrator de documentos pode exigir que email seja texto e solicita_demo seja booleano.

Como o mecanismo funciona

O fluxo descrito pela AWS tem quatro etapas. Primeiro, o Bedrock valida o esquema contra o subconjunto suportado do JSON Schema Draft 2020-12. Em seguida, compila uma gramática para aquele formato. Essa gramática é armazenada em cache por 24 horas por conta; por isso, a primeira chamada com um esquema novo pode ter latência adicional, e chamadas seguintes com a mesma estrutura tendem a ter menos sobrecarga. Por fim, a geração é limitada à gramática compilada.

A documentação destaca uma distinção importante: alterar a estrutura do esquema invalida esse cache, mas mudar apenas o nome ou a descrição do esquema não deveria exigir nova compilação. Para cargas repetitivas, como classificação de tickets ou extração de campos de milhares de documentos, reutilizar poucos esquemas estáveis pode ser mais eficiente do que montar uma definição nova a cada requisição.

Exemplo de aplicação com Claude no Bedrock

Em Python, a ideia é enviar o JSON Schema dentro de output_config.format ao chamar um modelo Claude pelo InvokeModel. O ponto principal é não aceitar propriedades fora da estrutura prevista:

schema = {
  "type": "object",
  "properties": {
    "categoria": {"type": "string", "enum": ["suporte", "vendas", "financeiro"]},
    "urgente": {"type": "boolean"}
  },
  "required": ["categoria", "urgente"],
  "additionalProperties": false
}

# O schema é enviado em output_config.format
# e a aplicação ainda deve tratar recusas e limite de tokens.

O exemplo resume uma regra operacional destacada pela AWS: additionalProperties precisa estar definido como false nos objetos para que a saída estruturada seja aceita. A empresa também recomenda nomes e descrições claros para os campos, uso de enum quando houver opções fechadas e testes com dados próximos dos dados reais de produção.

Limitações que não devem ser ignoradas

O recurso não é uma garantia universal. A AWS lista restrições no subconjunto de JSON Schema suportado: esquemas recursivos, referências externas e várias restrições numéricas ou de tamanho de texto não são aplicadas durante a geração. Palavras-chave como minimum, maximum, minLength e maxLength podem ser aceitas pela API sem serem efetivamente impostas. Esses limites ainda devem ser verificados pela aplicação.

Também há duas situações em que a resposta pode não chegar ao formato final esperado: uma recusa de segurança do modelo ou o encerramento por limite de tokens. Portanto, código de produção precisa conferir o motivo de parada, registrar falhas e definir uma rota de revisão humana ou retentativa controlada. Saída estruturada elimina uma classe de defeitos de serialização; não elimina alucinações, dados incompletos na fonte, permissões indevidas nem chamadas de ferramenta mal autorizadas.

Impacto prático para equipes no Brasil

Para empresas brasileiras que processam documentos em português — contratos, notas, e-mails comerciais, prontuários sob regras aplicáveis e solicitações de suporte — o ganho potencial está na previsibilidade da integração. Uma equipe pode transformar texto em registros padronizados antes de inserir dados em um CRM, encaminhar casos por prioridade ou preparar uma fila para revisão humana, sem manter uma camada extensa de reparo de JSON.

Isso não reduz a necessidade de governança. Em dados pessoais, a organização continua responsável por base legal, minimização, controle de acesso, retenção e auditoria. Em fluxos que afetam crédito, saúde, contratação ou atendimento, o JSON válido precisa ser apenas uma etapa: a decisão deve ter critérios verificáveis, trilha de auditoria e possibilidade de contestação.

Análise do NoticIA

O ponto mais relevante do lançamento não é “Claude agora responde em JSON”, algo que prompts e bibliotecas já tentavam induzir há anos. A mudança é deslocar a conformidade estrutural para a camada de inferência. Isso tende a tornar agentes e automações menos frágeis porque reduz a distância entre a intenção declarada pelo desenvolvedor e o contrato consumido pelo software.

Ao mesmo tempo, a mensagem de que não seria necessária “validação adicional” deve ser lida com precisão. Ela vale para a conformidade com parte do esquema, não para a validade semântica do conteúdo. Um agente pode preencher todos os campos corretos e ainda extrair a data errada de um contrato, classificar indevidamente um ticket ou sugerir uma ação incompatível com uma política interna. A arquitetura madura combina schema, validação de negócio, autorização de ferramentas, observabilidade e avaliação contínua.

O que fazer antes de adotar

• Comece com um caso de baixo risco, como classificação de mensagens ou enriquecimento de catálogo.
• Defina esquemas pequenos, com campos obrigatórios e listas fechadas de valores quando possível.
• Teste recusas, respostas interrompidas por max_tokens e entradas ambíguas.
• Valide no código regras que o subconjunto de schema não impõe, como faixas numéricas, tamanho e relações entre campos.
• Meça latência da primeira chamada e das chamadas com o cache de gramática já aquecido.

A disponibilidade geral da funcionalidade dá às equipes que operam Claude via Amazon Bedrock uma alternativa nativa à combinação de prompt, parser e retentativas. O resultado mais confiável será obtido por quem tratar a saída estruturada como um contrato de formato — e não como um atestado de que a IA tomou a decisão certa.