2bSolutions • 11 de outubro de 2026
O campo pode estar preenchido e continuar errado
Imagine um sistema que recebe a mensagem fictícia “Quero duas caixas do modelo azul” e a transforma em campos de um pedido. O resultado pode conter produto, quantidade e unidade, todos no formato esperado. Ainda assim, “caixa” pode ter sido confundida com “unidade”, e “modelo azul” pode corresponder a mais de um item do catálogo.
O problema aparece quando a aplicação trata uma extração organizada como se fosse um pedido pronto. Para equipes que estão conectando IA a cadastros, formulários e operações, a decisão importante é definir o que cada campo comprova antes de utilizá-lo.
O que as saídas estruturadas resolvem
Saídas estruturadas permitem definir um esquema para a resposta do modelo. A documentação da Anthropic apresenta esse recurso para extração de dados e respostas processáveis por aplicações, mas registra limitações de compatibilidade do esquema e situações de saída incompleta ou recusa. Por isso, a integração também precisa conferir o estado da resposta antes de consumir seu conteúdo. Documentação da Anthropic.
No JSON Schema, declarar uma propriedade e exigir sua presença são decisões distintas: a lista required define quais campos devem aparecer. Um campo ausente também não equivale automaticamente a um campo com valor null. Essas diferenças precisam estar no contrato de dados e ser compatíveis com o provedor escolhido. Referência oficial do JSON Schema.
A OpenAI alerta que saídas estruturadas ainda podem conter erros. Também recomenda prever entradas incompatíveis com a tarefa, pois a tentativa de preencher o esquema pode gerar informações indevidas. Formato previsível facilita integração, mas não substitui a verificação do conteúdo. Guia da OpenAI.
Um fluxo prático para um pedido assistido
O desenho abaixo é uma proposta editorial de implementação, não um caso de cliente nem uma funcionalidade anunciada pela 2bSolutions.
Extraia uma proposta. Guarde a descrição recebida, a quantidade mencionada e a unidade explicitamente informada. Não transforme uma referência ambígua em um identificador definitivo de produto.
Confira o contrato. Verifique tipos, campos esperados e conclusão da resposta. Se houver falha, o registro permanece pendente, sem avançar para a operação.
Consulte a fonte operacional. Resolva o produto no catálogo e confira embalagem e disponibilidade no sistema responsável por esses dados. O texto do modelo não deve substituir essa consulta.
Peça somente o que falta. Se existem duas variantes azuis, apresente as alternativas. Se “caixa” não tem uma quantidade definida, esclareça a unidade antes de calcular o total.
Mostre uma revisão. Exiba os itens resolvidos, quantidades e pendências para conferência. Só depois dessa etapa o fluxo pode seguir para a ação prevista pelo produto.
Essa separação torna o comportamento visível: extrair significa propor dados; resolver significa associá-los a registros existentes; confirmar significa aceitar uma versão específica da operação.
Desenhe a ausência como parte da experiência
Uma interface que exige todos os campos preenchidos pode esconder incerteza. Uma alternativa é permitir estados como “não informado”, “precisa confirmar” e “resolvido”, com critérios claros para cada transição.
Para o exemplo das caixas, a tela pode mostrar “Quantidade: 2; unidade: caixa; produto: precisa confirmar”. Isso permite ao atendente fazer uma pergunta curta e contextualizada. Evite apresentar uma pontuação de confiança produzida pelo próprio modelo como garantia de precisão.
Também mantenha o conteúdo necessário para revisar a extração, sem espalhar mensagens completas em telas e registros onde elas não são necessárias. Defina acesso e retenção conforme a finalidade do processo.
Como testar antes de ampliar
Comece por um formulário pequeno e crie exemplos fictícios com campos ausentes, unidades ambíguas, produtos inexistentes, correções do pedido e mensagens fora do assunto. Defina antecipadamente qual saída e qual estado cada caso deveria produzir.
Conte separadamente erros de formato, valores incorretos e solicitações de esclarecimento. Uma resposta que pede a informação necessária pode ser mais adequada do que um formulário completo com um valor inventado. Revise também se a pergunta ao usuário realmente permite resolver a pendência.
A pergunta para orientar o projeto é simples: qual evidência permite que este campo deixe de ser uma sugestão e passe a ser usado pela operação?
Fontes consultadas em 11/10/2026. As páginas são documentação contínua; este texto não atribui ao dia de hoje um lançamento específico.